US8452903B2 - Mobile computing device capabilities for accessories - Google Patents

Abstract

Embodiments disclosed herein provide for capability identification for accessories coupled with a mobile computing device. During capability identification an accessory can request capability information from a mobile computing device. In some embodiments, the accessory can specifically request capability information associated with a specific lingo. In response, the mobile computing device can respond with a message that indicates the capabilities of the mobile computing device that are supported. In some embodiments, the capabilities can be those capabilities associated with the specified lingo. In some embodiments, if the mobile computing device does not support a lingo, then the mobile computing device can respond to the request from the accessory with a negative acknowledgement.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a Continuation-In-Part of U.S. patent application Ser. No. 12/405,077, entitled “Accessory Identification for Mobile Computing Devices”, filed on Mar. 16, 2009, and assigned to the assignee of the present application.

BACKGROUND

The present disclosure relates generally to communication between an accessory and a mobile computing device and in particular to identification routines, schemes and/or processes between an accessory and a mobile computing device.

Mobile computing devices (MCDs) have become ubiquitous. Various companies have created MCDs, such as the iPhone™, iPod Touch™, various Blackberry® devices, and smart phones compatible with Google's Android™ platform, to name a few. MCDs often include web browsers, word processors, email applications, maps, telephone services, games, audio applications, video applications, etc. Moreover, accessories have also been created for use with MCDs. Such accessories can communicate with an MCD using one or more connectors and/or ports. Such accessories can be used to control features of the MCD or used by the MCD to interact with users and/or the environment. Often the accessories and the MCD use a communication protocol provided by the developers of the MCD for interaction between the two.

BRIEF SUMMARY

According to various embodiments, identification and/or initialization schemes and processes are provided between an accessory device and an MCD. The accessory device, for example, can request lingo version information and/or MCD capability information from the MCD. If the MCD returns the lingo version information and/or capability information, this information can be used by the accessory to determine the lingoes the accessory can use during communication with the MCD, and the accessory can identify such lingoes to the MCD. In particular, in some embodiments, subsequent communication between the accessory and the MCD can be limited to only those lingoes identified to the MCD by the accessory. In some embodiments, the accessory might not re-identify itself or request the use of new or different lingoes after initialization and/or identification. The accessory can also communicate accessory capability information, accessory preference information, accessory information, accessory protocol information, preferred application information, etc. during initialization and/or identification. In some embodiments, the accessory can also communicate with the MCD using accessory protocols identified by the accessory during initialization and/or identification. Various modifications, sequencing, enhancements are also be provided.

Various embodiments of the invention provide for capability identification for accessories coupled with a mobile computing device. During capability identification an accessory can request capability information from a mobile computing device. In some embodiments, the accessory can request capability information associated with a specific lingo. In response, the mobile computing device can respond with a message that indicates the capabilities of the mobile computing device that are supported. In some embodiments, the capabilities can be those capabilities associated with the specified lingo. In some embodiments, if the mobile computing device does not support a lingo, then the mobile computing device can respond to the request from the accessory with a negative acknowledgement. Various lingoes and/or capabilities can be used in conjunction with embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of an accessory coupled with an MCD according to one embodiment.

FIG. 2 shows a block diagram of an accessory wirelessly communicating with an MCD according to one embodiment.

FIG. 3 shows a block diagram of a mobile computing device (MCD) and an accessory device coupled together according to one embodiment.

FIG. 4 is a diagram showing commands that can be sent to and from an accessory coupled with an MCD during an identification scheme according to some embodiments.

FIG. 5 shows an example of tokens that can be used by an accessory to provide the commands shown inFIG. 4 in communication with an MCD during identification according to some embodiments.

FIG. 6 shows a flowchart of an identification scheme according to some embodiments.

FIG. 7 shows a flowchart of an identification scheme at an accessory according to some embodiments.

FIG. 8 shows a flowchart of an identification scheme at an MCD according to some embodiments.

FIG. 9 shows a chart of messages being passed between an accessory and a mobile computing device using transaction identifiers according to some embodiments.

FIG. 10 shows a flowchart for identifying capabilities of a mobile computing device using an accessory device according to some embodiments.

DETAILED DESCRIPTION

Embodiments disclosed herein are directed toward identification processes between an accessory and an MCD. In some embodiments, the accessory can identify the lingoes and/or protocols the accessory can use while coupled with the MCD. Subsequent communication between the two devices can be restricted to only the lingoes and/or protocols identified by the accessory.

In some embodiments, an accessory can request lingo version information and/or capability information from the MCD. The accessory can then determine the lingoes and/or protocols the accessory can use during communication while coupled with the MCD based at least in part on the lingo version(s) supported by the MCD and/or the capabilities of the MCD.

In some embodiments, an accessory can also send various message that can indicate accessory information, accessory capabilities, accessory preferences, accessory protocol information, preferred application information, etc. Moreover, transaction IDs can be included with the tokens, messages, commands, and/or data sent between the accessory and the MCD.

In some embodiments, an accessory can also send a request to the MCD for capabilities of the MCD. In some embodiments, a request can be made for capabilities supported by the MCD for different lingoes. In response, the MCD can send an indication of the supported capabilities. The indication, for example, can be made using a bitmask with each bit indicating whether a capability is supported or not.

The term “token” as used throughout this disclosure refers to a code-value pair. In particular, the code can be a bit string that identifies information type and the value can contain the actual information. The code, for example, can be a 2-byte code that identifies the token and the related value. The value can have a fixed or variable length. In some embodiments, a variable length token can include an identification of the length of the token. An accessory and/or an MCD can parse the value based on the associated code. A token can be communicated to and/or from an accessory to an MCD in one or more packets. Thus, a single packet can include the code and all of the value, or two or more packets can include the value with the first packet including the code and/or an identification of the length.

FIG. 1 shows anMCD102 coupled with anaccessory device113.Cable111 is used to coupleMCD102 withaccessory device113.Cable111 can includeconnector108 to connect withMCD102 andconnector110 to connect withaccessory device113.FIG. 2 showsaccessory device113 wirelessly coupled withMCD102.

MCD102 can be any type of mobile computing/communication device; for example, an iPod Touch™, iPhone™, Android compatible device, and/or a Blackberry device can also be used. Furthermore, any of various media players can also be used, for example, an iPod®, Zune, a Sada, or other media player. Moreover,MCD102 can provide media player capability, networking, web browsing, email, word processing, data storage, application execution, and/or any other computing or communication functions.Accessory113 can be an external speaker dock; multimedia device; consumer electronic device; test instrument; home appliance (e.g., refrigerator or dishwasher); speaker(s); exercise equipment; security system; home or office automation system; camera; keyboard; measurement device; external video device; medical device (e.g., glucose monitor or insulin monitor); point of sale device; automobile; automobile accessory (e.g., car stereo system or car navigation system); radio (e.g., FM, AM and/or satellite); entertainment console on an airplane, bus, train, or other mass transportation vehicle; etc. Any type of device that can be used in conjunction with an MCD can be used as an accessory device.

FIG. 3 shows a block diagram ofMCD103 coupled withaccessory112 according to some embodiments.MCD103 can includeprocessor230,storage device225, user interface (UI)235, and accessory input/output (I/O)interface205.Processor230, in some embodiments, can execute various software programs or applications (Apps)226 stored instorage device225.Processor230 can interact withaccessory112 through I/O interface205 and/or with a user throughuser interface235. In some embodiments,processor230 can execute an application stored instorage device225 that requires input/output from either or both ofuser interface235 and/oraccessory112.Storage device225 can include other information including digital media, documents, tables, working memory, applications, various lookup tables, etc. For example,storage device225 can include a protocol table227 that specifies protocols that applications can use to communicate with an accessory device.Storage device225 can be implemented, for example, using disk, flash memory, or any other non-volatile storage medium.

User interface235 can include input controls, such as a touch pad, touch screen, scroll wheel, click wheel, dial, button, keypad, microphone, or the like, as well as output devices, such as video screen, indicator lights, speakers, headphone jacks or the like, together with supporting electronics (e.g., digital-to-analog or analog-to-digital converters, signal processors, video processors, etc). A user can operate the various input controls ofuser interface235 to invoke the functionality ofMCD103 and can view and/or hear output fromMCD103 viauser interface235.

Signals can be communicated betweenMCD103 andaccessory112 usingconnection211 that can include any wired and/or wireless communications protocol or set of protocols. Wired connections can be connector-to-connector or using intervening cables (e.g. as shown inFIG. 1). Any number of communication paths can be used. They can be separate paths or various subsets can be multiplexed onto a common path. Different embodiments can have fewer or more signal paths. In some embodiments, the set of communication paths can be provided by a multi-pin connector. In some embodiments, some signals can have dedicated pins and others can share one or more pins. In other embodiments,connection211 can be implemented using a wireless protocol such as Bluetooth or WiFi.

Connection211 can be part of a larger I/O interface, which can include components for communicating with elements other thanaccessory112, such as one or more host computers or one or more networks. The I/O interface can include, for example, one or more peripheral interfaces, such as USB, IEEE 1394 (Firewire), and Bluetooth (a short-range wireless communication standard developed by the Bluetooth SIG and licensed under the trademark Bluetooth®). The I/O interface can also or alternatively include one or more wired networking interfaces (e.g., Ethernet) or wireless networking interfaces (e.g., Wi-Fi adhering to one of the 802.11 family standards, digital mobile phone technologies). In some embodiments (possibly the same as those above, but possibly different embodiments) the I/O interface can have the ability to coupleMCD103 with a source of data, such as media assets, applications, data, commands, functions, etc., (e.g., via a wireless connection to the Internet) so that the MCD can obtain such data without connecting to a host computer.

Accessory I/O interface205 can allowMCD103 to communicate with various accessories. Accessory I/O interface205 includes at least one communication port.MCD103 can also include anauthentication manager206, which can communicate withauthentication controller280 of the accessory to authenticate and provide privileges (or permissions) to an accessory.Authentication manager206 can perform cryptography functions in conjunction with the authentication controller. In some embodiments, such cryptography functions include public-private key cryptography.

Accessory I/O interface205 can support connections to various accessories, such as an external speaker dock; multimedia device; consumer electronic device; test instrument; home appliance (e.g., refrigerator or dishwasher); speaker(s); exercise equipment; security system; home or office automation system; camera; keyboard; measurement device; external video device; medical device (e.g., glucose monitor or insulin monitor); point of sale device; automobile; automobile accessories (e.g., car stereo system or car navigation system); radio (e.g., FM, AM and/or satellite); entertainment console on an airplane, bus, train, or other mass transportation vehicle; etc. In one embodiment, accessory I/O interface205 includes a 30-pin connector corresponding to the connector used on iPod® products manufactured and sold by Apple Inc. Alternatively or additionally, accessory I/O interface205 can include a wireless interface, such as, for example, Bluetooth, wireless personal area network, or WiFi interfaces. It is to be understood that accessory I/O interface205 can be any interface, whether wired or wireless, or a combination thereof, that enables communication of signals therethrough.

In some embodiments,MCD103 can also use accessory I/O interface205 to communicate with a host computer (not explicitly shown) that executes an asset management program (for example, iTunes® or the Microsoft application and/or music store) that can provide access to media and/or applications. The asset management program can enable a user to add media assets and/or applications toMCD103 and/or remove media assets and/or applications fromMCD103. The user can update metadata associated with media assets and applications onMCD103. In some embodiments, the user can also interact with the asset management program to create and update playlists and/or applications as well as other documents. In one embodiment, the host computer maintains a master database of media assets and/or applications and can access other databases through the Internet (including associated metadata and playlists). The asset management program can synchronize the master database with the database maintained onstorage device225 ofMCD103 automatically wheneverMCD103 connects to the host computer.

Accessory112 can includecontroller260,user interface255, MCD I/O interface250,memory265, andmedia output device270. Accessories can include accessoryspecific hardware275. Accessoryspecific hardware275 can include, for example, probes, motors, actuators, receivers for broadcast signals, user interfaces, sensors, interfaces, glucose monitors, interfaces with electronic devices, sensors, detectors, or any other device.Controller260 can include, e.g., a microprocessor or microcontroller executing program code to perform various functions, such as digital audio decoding, analog or digital audio and/or video processing, controlling operation of any included test probes, meters, receivers, actuators, motors, user interfaces, and the like.User interface255 can include input controls, such as a touch pad, touch screen, scroll wheel, click wheel, dial, button, keypad, microphone, probes, etc., as well as output devices, such as a video screen, indicator lights, speakers, headphone jacks or the like, together with supporting electronics (e.g., digital-to-analog or analog-to-digital converters, signal processors or the like). Alternatively, output components ofuser interface255 can be integrated withmedia output device270. A user can operate the various input controls ofuser interface255 to invoke the functionality ofaccessory112 and can view and/or hear output fromaccessory112 viauser interface255. In addition, in some embodiments, a user can operateMCD103 viauser interface255.

MCD I/O interface250 can allowaccessory112 to communicate with MCD103 (or another MCD). In some embodiments, MCD I/O interface250 is configured to connect to a specific port ofMCD103, whether wired or wireless.

Memory265 can be implemented using any type of memory that can store program code forcontroller260 and/or store data.Memory265 can include volatile and/or nonvolatile memory that can provide storage for various information, for example, including information obtained fromMCD103. For example, in some embodiments,accessory112 can obtain user input, data, metadata and/or status information fromMCD103. Any or all of this information can be stored inmemory265. Caching of information obtained fromMCD103 byaccessory112 is optional; where used, caching can help speed up performance ofaccessory112 by avoiding repeated requests for information fromMCD103.

Media output device270, which can be implemented, e.g., as one or more integrated circuits, provides the capability to output various types of media. For example,media output device270 can include a display screen or a driver circuit and connector for an external display screen, thereby enabling video and/or still images to be presented to a user. Additionally or instead,media output device270 can also include one or more speakers or driver circuits and connectors for external speakers, thereby enabling audio to be presented to a user. In one embodiment,controller260 can receive media content signals fromMCD103 via an MCD I/O interface250 and can provide the signals with or without further processing tomedia output device270;media output device270 can transform the signals as appropriate for presentation to the user.

Accessory112 can be any accessory capable of being used with a mobile computing device. Examples of accessories implementing blocks shown inaccessory112 include, e.g., an external speaker dock; multimedia device; consumer electronic device; test instrument; home appliance (e.g., refrigerator or dishwasher); speaker(s); exercise equipment; security system; home or office automation system; camera; keyboard; measurement device; external video device; medical device (e.g., glucose monitor or insulin monitor); point of sale device; automobile; automobile accessories (e.g., car stereo system or car navigation system); radio (e.g., FM, AM and/or satellite); entertainment console on an airplane, bus, train, or other mass transportation vehicle; etc. In one embodiment, MCD I/O interface250 includes a 30-pin connector that mates with the connector used on iPod® or iPhone™ products manufactured and sold by Apple Inc. MCD I/O interface250 can also include other types of connectors, e.g., Universal Serial Bus (USB) or FireWire connectors. Alternatively or additionally, MCD I/O interface250 can include a wireless interface, such as Bluetooth, personal wireless area network, and/or WiFi. It is to be understood that MCD I/O interface250 can be any interface, whether wired or wireless, or a combination thereof, that enables communication of signals therethrough.

Accessory I/O interface205 ofMCD103 and MCD I/O interface250 ofaccessory112 allowMCD103 to be connected toaccessory112 and subsequently disconnected fromaccessory112. As used herein,MCD103 andaccessory112 are “connected” whenever a communication channel between accessory I/O interface205 and MCD I/O interface250 is open and are “disconnected” whenever the communication channel is closed. Connection can be achieved by physical attachment (e.g., between respective mating connectors ofMCD103 and accessory112), by an indirect attachment such as a cable, or by establishing a wireless communication channel. Similarly, disconnection can be achieved by physical detachment, disconnecting a cable, powering downaccessory112 orMCD103, or closing the wireless communication channel. Thus, a variety of communication channels can be used, including wired channels such as USB, FireWire, or universal asynchronous receiver/transmitter (“UART”), or wireless channels such as Bluetooth, WiFi, infrared, or the like. In some embodiments, multiple communication channels between an MCD and an accessory can be open concurrently, or an MCD can be connected to multiple accessories, with each accessory using a different communication channel.

Regardless of the particular communication channel, as long asMCD103 andaccessory112 are connected to each other, the devices can communicate by exchanging commands and data according to a protocol. The protocol defines a format for sending messages betweenMCD103 andaccessory112. For instance, the protocol can specify that each message is sent in a packet with a header and an optional payload. The header can provide basic information such as a start indicator, length of the packet, and a command to be processed by the recipient, while the payload provides any data associated with the command; the amount of associated data can be different for different commands, and some commands can provide for variable-length payloads. The packet can also include error-detection or error-correction codes as known in the art. In various embodiments, the protocol can define commands to indicate an action to be taken by the recipient, commands to signal completion of a task, commands to change the state of the MCD or accessory, commands to initiate the occurrence of an error, and/or commands to identify the nature of the associated data. In some embodiments, the commands can be defined such that any particular command is valid in only one direction.

The protocol can define a number of “lingoes,” where a “lingo” refers generally to a group of related commands that can be supported (or unsupported) by various classes of accessories. In one embodiment, a command can be uniquely identified by a first byte identifying the lingo to which the command belongs and a second byte identifying the particular command within the lingo. Other command structures can also be used. It is not required that all accessories, or all MCDs to which an accessory can be connected, support every lingo defined within the protocol or every command of a particular lingo (for instance, different devices might use different versions of a given lingo).

In some embodiments, every accessory and every MCD can be designed to interoperate with each other to support at least a “general” lingo that includes commands common to all such devices. The general lingo can include commands enabling the MCD and the accessory to identify themselves to each other and to provide at least some information about their respective capabilities, including which (if any) other lingoes each supports and which capabilities of the other device each intends to use while connected. Examples of such commands are described below.

The general lingo can also include authentication commands that the MCD can use to verify the purported identity and capabilities of the accessory (or vice versa), and the accessory (or MCD) can be blocked from invoking certain commands or lingoes if the authentication is unsuccessful.

According to some embodiments,accessory112 can includeauthentication controller280 that is used to authenticateaccessory112 withMCD103 and receive privileges and/or permissions therefrom. In other embodiments,accessory112 might not include an authentication controller, in which case,accessory112 would not be able to authenticate itself and receive privileges fromMCD103.

It will be appreciated that the system configurations and components described herein are illustrative and that variations and modifications are possible. The MCD and/or accessory can have other capabilities not specifically described herein.

Whileaccessory112 andMCD103 are described inFIG. 3 with reference to particular blocks, it is understood that the blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. Further, the blocks need not correspond to physically distinct components.

FIG. 4 is achart400 showing an example of identification messages and/or acknowledgements that can be passed between an accessory and a portable computing device during identification routines. In some embodiments, some or all of these messages and/or acknowledgements can be passed using tokens or commands. In some embodiments, the routine can be referred to as a device identification sequence (DIS). As shown, a DIS can begin with aStart DIS command402 being sent from the accessory to the MCD. StartDIS command402 indicates the beginning of the DIS. The command puts the MCD on alert to expect messages consistent with DIS until an End DIS command is received. In some embodiments, an acknowledgement from the MCD is not required forStart DIS402; however, an acknowledgement can be sent by the MCD to the accessory, for example, indicating that the MCD is ready for the next command as shown atblock403.

In some embodiments, during DIS the accessory can send request404 to the MCD requesting a response that indicates the lingo version (or versions) supported by the MCD. The MCD can then return amessage406 indicating the lingo version (or versions) supported by the MCD. The accessory can also sendrequest408 to the MCD requesting the capabilities of the MCD, whereupon the MCD can respond withreturn message410 indicating the capabilities of the MCD. In some embodiments, returnmessage410 can include a bitmask where the state of each bit can indicate whether a specific capability is supported or not supported. These capabilities can include, for example, whether the MCD supports analog line-in, analog line-out, analog video-in, analog video-out, digital audio out, digital audio in, digital video in, digital video out, speakerphone, communication with MCD operating system application, etc.

Usable lingoes message412, which can be sent to the MCD from the accessory, can include an identification of a set of usable lingoes that the accessory can use during communication with the MCD. In some embodiments, the lingoes message can include a bitmask where the state of each bit can indicate whether a specific lingo is supported or not supported. The set of usable lingoes can be determined based in part on the received capabilities of the MCD and/or the supported lingo versions of the MCD. This identification of a set of usable lingoes can be sent, for example, using a lingo token that can include an indication of the lingoes as the token's value. In response, the MCD can send anoptional acknowledgment message414. In some embodiments, the accessory's subsequent (i.e., post DIS) communication with the MCD can be limited to only those lingoes that were identified by the lingo token, and this limitation can persist until the accessory is disconnected from the MCD or until the MCD and/or the accessory are rebooted. Thus, if the accessory sends a command using a lingo that was not included in the set of usable lingoes, the MCD can ignore the command or return an error message. Thus, the accessory pushes the set of usable lingoes to the MCD without previously having the MCD request these lingoes. Moreover, the set of usable lingoes is established at the outset of a communication session rather than incrementally. In some embodiments, the usable lingo information (and other DIS information disclosed herein) is sent to the MCD prior to authentication processes between the MCD and the accessory.

The lingoes in the set of usable lingoes can be chosen based at least in part on the lingo version (or versions) supported by the MCD. For example, if the MCD does not support a particular lingo, it can be omitted from the set of usable lingoes. Furthermore, the set of usable lingoes can depend on the capabilities of the MCD. For example, if the MCD does not support video input, lingoes associated with video input can be omitted from the set of usable lingoes. Various other lingoes associated with other capabilities can be included or excluded from the usable lingoes list depending on the capabilities of the MCD.

In some embodiments,accessory capabilities message416 can also be sent indicating the usable capabilities of the MCD supported by the accessory. In some embodiments, accessory capabilities can be sent using an accessory capabilities token. In some embodiments, accessory capabilities can be sent as a bitmask where the state of each bit can indicate whether a capability is supported. For example, capabilities can include whether the accessory supports analog line-in to the MCD, analog line-out from the MCD, analog video-in to the MCD, analog video-out from the MCD, digital audio out from the MCD, digital audio in to the MCD, digital video in to the MCD, digital video out from the MCD, speakerphone, communication with MCD operating system application, etc.Acknowledgement message418 can optionally be sent from the MCD indicating that theaccessory capabilities message416 was received. In some embodiments, if the accessory indicates that an capability is not supported, then the MCD can turn off the capability.

In some embodiments,accessory preferences message420 can also be sent indicating the accessory's initial preference for the MCD capabilities supported by the MCD and/or the accessory. Accessory preferences, in some embodiments, can be sent using an accessory preferences token. In some embodiments, accessory preferences can be sent as a bitmask where the state of each bit can indicate whether a capability is supported.Accessory preferences message420 can include a bitmask with each bit indicating an initial state of a predefined preference for an MCD capability. For instance, capabilities can have two or more states, and these preferences can indicate the initial state of one or more capability. For example, if theaccessory capabilities message416 indicated that the accessory supports video input to the MCD, thenaccessory preferences message420 can indicate whether video input to the MCD is originally in the “ON” state or the “OFF” state. The state of a capability can be changed during operation regardless of the state indicated inaccessory preferences message420. In some embodiments, theaccessory preferences message420 can set the desired initial state (for example, “ON” or “OFF”) of the MCD capabilities such as analog line-in to the MCD, analog line-out from the MCD, analog video-in to the MCD, analog video-out from the MCD, digital audio out from the MCD, digital audio in to the MCD, digital video in to the MCD, digital video out from the MCD, speakerphone, communication with MCD operating system application, etc. Some capabilities can have more than two states; in such embodiments the state can be indicated accordingly.Acknowledgment message422 can optionally be sent from the MCD to the accessory indicating theaccessory preferences message420 was received.

In some embodiments,accessory protocol message424 can also be sent indicating one or more accessory protocols that the accessory can use to communicate with the MCD and/or an application executing at the MCD. For example, a developer and/or manufacturer of an accessory can provide an application that can be used to interoperate with the accessory. The application can require exchange of information in formats not available using the lingoes and/or protocols of the MCD. To allow such information exchange between the accessory and the application, an accessory-specific protocol can be used.Accessory protocol message424 can be used to indicate whether one or more accessory-specific protocols are supported.Acknowledgment message426 can optionally be sent to acknowledge receipt of theaccessory protocol message424.

In some embodiments,accessory protocol message424 can indicate an accessory-specific protocol using a reverse domain name convention. Conventional domain names provide, from left to right, lower level domains to top level domains. For example, in the domain name: “help.example.com”, the term “com” is the top level domain and the term “example” is a lower level domain, and the term “help” is the lowest level domain. As another example, the domain name “mac.apple.com” from left to right specifies the lowest level domain “mac”, the middle domain “apple”, and the top level domain “com”. Reverse domain names on the other hand would provide “com.apple.mac”.

The reverse domain name convention can be used to specify accessory protocols used by a specific company associated with the domain name. That is, the reverse domain name “com.company1.accessory1” specifies that the “accessory1” protocol is associated with the company “company1”. Thus, in general, a company that manufactures and/or sells accessories can implement a protocol using the reverse domain name convention, where the first portion of the reverse domain name references the company (“com.company1”) and can be associated with the company's Internet domain name. The second portion of the reverse domain name (“accessory1”) specifies a specific protocol. Because most companies are associated with a domain name, a reverse domain name convention allows companies to distinguish applications and/or protocols and/or accessories from those of other companies by naming their protocols with their reverse domain name. This convention, allows companies to independently name their protocols without concern for the naming convention of other companies. Moreover, if there is a conflict between two companies using the same naming convention, a simple check of the domain name should determine which company has rights to the naming convention.

In some embodiments, preferredapplication message428 can also be sent to the MCD indicating a preferred application for use with the accessory. A preferred application identifier can be used to indicate an application that uses one of the supported accessory protocols and that can be downloaded and/or executed on the MCD. Thus, when an accessory couples with an MCD that does not include an application that has the capability to communicate with the accessory, preferred application identifier can point the MCD to a web page or other network location (such as the iTunes® store) from which a preferred application can be downloaded.Acknowledgment message430 can optionally be sent from the MCD to the accessory indicating thepreferred application message428 was received.

FIG. 4 shows a number of optional acknowledgement messages that can be sent from the MCD to the accessory. These acknowledgements can be sent after a complete request, message and/or token is received or they can be sent after each packet that comprises the request, message and/or token is received. As will be discussed later, these acknowledgements can also include a transaction ID. In some embodiments, an acknowledgement is sent only when an error occurs. Accordingly, in such embodiments, it can be assumed that the command, request, and/or message was received without an error if no acknowledgement is sent.

FIG. 5 shows an example of a table500 showing some of the various tokens (code-value pairs) that an accessory can communicate to an MCD during identification in some embodiments. This information can include an identify token whose value can include a bitmask that identifies which of the lingoes as specified by the MCD protocol are usable by the accessory. An accessory capabilities token can include a string that specifies various MCD capabilities that are usable by the accessory. These capabilities can include, e.g., whether the accessory supports analog line-in to the MCD, analog line-out from the MCD, analog video-in to the MCD, analog video-out from the MCD, digital audio out from the MCD, digital audio in to the MCD, digital video in to the MCD, digital video out, speakerphone, communication with MCD operating system application, etc.

An accessory preferences token can include various preferences for the initial state of the capabilities specified in the accessory capabilities token. For example, the accessory preferences token can indicate whether the analog line-in to the MCD should initially be “ON” or “OFF” state, whether the analog line-out from the MCD should initially be “ON” or “OFF” state, whether the analog video-in to the MCD should initially be “ON” or “OFF” state, whether the analog video-out from the MCD should initially be “ON” or “OFF” state, whether the digital audio out from the MCD should initially be “ON” or “OFF” state, whether the digital audio in to the MCD should initially be “ON” or “OFF” state, whether the digital video in to the MCD should initially be “ON” or “OFF” state, whether the digital video out should initially be “ON” or “OFF” state, and/or whether the speakerphone should initially be “ON” or “OFF” state. In some embodiments, preferences can include whether the microphone should operate at full duplex, at half duplex, with noise cancellation, without noise cancellation, with stereo input and/or with mono input. In some embodiments, the preferences can also indicate the preferences for video out put such as refresh rate, picture size, format, sound quality, volume, etc. In some embodiments, preference can be sent for location data such as whether the location data is sent synchronously, asynchronously, when there are changes, a change threshold, etc.

An accessory information token can provide accessory information items, such as accessory name, accessory firmware version, accessory hardware version, accessory manufacturer, accessory model number, accessory serial number, etc. In some embodiments, other accessory information items can be included and/or some of those shown can be excluded.

The accessory can also send one or more protocol tokens. Each protocol token can include a protocol index and/or a protocol string. Any number of protocol tokens can be sent. The protocol index can be a unique integer that is assigned by the accessory and that can be associated with a specific protocol string. The protocol string can be a string, for example, in reverse domain name format, specifying an accessory protocol that can be used for communication between the accessory and the MCD. A preferred application token can include an identifier (e.g., URL) for locating a preferred application associated with one of the accessory protocols specified in the protocol token. Preferred application information can be used to specify an application that uses one of the above specified protocol strings and that can be downloaded and/or executed on the MCD. Thus, when an accessory couples with an MCD that does not include an application that has the capability to communicate with the accessory, preferred application information can point the MCD to a web page or other network location (such as the iTunes® store) from which a preferred application can be downloaded.

FIG. 6 shows a flowchart of anidentification process600 according to some embodiments. Any block, step and/or function shown inFIG. 6 can be excluded or placed in a different order. For example, any of the sending and/or receiving of acknowledgements can be included or excluded as described above.

The process starts at block602 where it is determined whether an accessory is coupled with an MCD atblock604. If so, a DIS start command can be sent atblock606. The DIS start command puts the MCD on alert that data consistent with identification follows. In some embodiments, the MCD can send an acknowledgement that the DIS start command has been received.

The accessory can query the MCD for lingo version (or versions) information atblock608 that indicates the version (or versions) of various lingoes that are supported by the MCD. A command can be sent to the MCD requesting the supported lingo version (or versions) information. In some embodiments, the accessory can wait until the MCD sends a message indicating the version (or versions) of lingoes supported by the MCD. If the accessory does not receive lingo version information atblock610, then the accessory can return to block608 and again request lingo version information. In some embodiments, an accessory can wait a set period of time before requesting lingo version information again.

When lingo version or version information is received atblock610, the accessory can request capability information from the MCD atblock612 that indicates the capabilities of the MCD. A command can be sent to the MCD requesting the capabilities of the MCD. In some embodiments, the accessory can wait until the MCD sends a message indicating the capabilities supported by the MCD. If the accessory does not receive capabilities information atblock614, then the accessory can return to block612 and again request capabilities information. In some embodiments, the accessory can wait a set period of time before returning to block612.

When MCD capabilities information is received atblock614, the accessory can send an identify message atblock616. In some embodiments, the identify message can correspond to and/or include the identify token shown inFIG. 5 and/or the usable lingoes message described in conjunction withblock412 inFIG. 4. The identify message, for example, can include an indication of one or more of the lingoes actually supported by the accessory. In some instances, the accessory can identify every lingo it supports, but in other cases, an accessory might identify fewer than all supported lingoes. In some embodiments, the lingoes identified in the identify command are the only lingoes the accessory will be allowed to use while communicating with the MCD. If the accessory does not include an indication of a lingo in the identify command, the MCD can reject any commands of that lingo the accessory subsequently sends. In some embodiments, the accessory can determine the list of lingoes that it might use to communicate with the MCD based in part on the lingo version information received from the MCD and/or the capabilities of the MCD. For example, the accessory can exclude lingoes for which desired features are not present in the lingo version identified by the MCD. Moreover, the accessory can also exclude lingoes that require MCD capabilities that were not identified by the MCD. Thus, in some embodiments, the set of usable lingoes can depend on the lingo version information received from the MCD and/or on the MCD capabilities information received from the MCD.

An accessory capabilities message can be sent atblock620. In some embodiments, the accessory capabilities message can correspond to and/or include the accessory capabilities token shown inFIG. 5 and/or the accessory capabilities message described in conjunction withblock416 ofFIG. 4. The accessory capabilities message can indicate the capabilities of the accessory, for example, whether the accessory is capable of supporting analog line-in to the MCD, analog line-out from the MCD, analog video-in to the MCD, analog video-out from the MCD, digital audio out from the MCD, digital audio in to the MCD, digital video in to the MCD, digital video out, speakerphone, communication with MCD operating system application, etc.

An accessory information message can be sent atblock624. In some embodiments, the accessory information message can correspond to the accessory information token inFIG. 5. The accessory information message can specify accessory information such as, for example, accessory name, accessory firmware version, accessory hardware version, accessory manufacturer, accessory model number, and/or accessory serial number.

An accessory preferences message can be sent atblock627. In some embodiments, the accessory information message can correspond to accessory information token inFIG. 5 and/or the accessory preferences described in conjunction withblock420 ofFIG. 4. The accessory preferences message can indicate the preferences of the capabilities sent atblock620. For example, the preferences can indicate whether any or all of the capabilities are to initially be in the “ON” or “OFF” state. In some embodiments, the capabilities can have more than one state, and the preferences can indicate the desired initial state accordingly.

An accessory protocol message can be sent at block630. In some embodiments, the accessory protocol message can correspond to and/or include the accessory protocol token shown inFIG. 5 and/or the accessory protocols described in relation to block424 ofFIG. 4. The accessory protocol message can provide an indication of an accessory protocol or protocols that can be supported by the accessory. The accessory protocol message, for example, can indicate accessory protocols using a reverse domain name convention and can also provide an accessory protocol identifier that is uniquely related to each indicated accessory protocol.

A preferred application message can be sent atblock634. In some embodiments, the preferred application message can correspond with the preferred application token inFIG. 5 and/or the preferred application identifier discussed in relation to block428 ofFIG. 4. The preferred application message can identify an application, such as a preferred application, that can be used at the MCD in conjunction with the accessory. Moreover, the preferred application message can also indicate a URL, link, address, etc. where the preferred application can be downloaded. Thus, if the MCD does not include an application that supports the protocols identified in the accessory protocol message or that does not support the accessory, then the application identified in the preferred application identifier can be downloaded and executed.

An end identify message can be sent atblock642. The end identify message can be used to signal the end of the identification sequence. An acknowledgement can optionally be received after the end identify message.

In some embodiments, after the end identify message has been received at the MCD atblock646 the MCD can send a full identification message to the accessory. The full identification message can confirm receipt of each of the messages and/or tokens received during the identification process and/or can provide an indication that each of the received messages and/or tokens received. In some embodiments, the full identification message can confirm that each of the messages, commands and/or tokens received from the accessory were successfully parsed and/or executed at the MCD.

In some embodiments, after the identification sequence shown inFIG. 6 has been completed the accessory can authenticate itself with the MCD using any authentication scheme. Thereafter the accessory and the MCD can communicate using any of the lingoes identified inblock616. In addition if accessory identifies an accessory protocol at block630, the accessory and MCD can use the protocols so identified.

In some embodiments, when an accessory sends a message, the accessory can wait until an acknowledgement message is received. For example, an acknowledgement can follow some or all the packets that make up a message. In some embodiments, the accessory can time-out if an acknowledgement message is not received within a set time frame. In other embodiments if an acknowledgement message is not received, the process can return back to the previous step in the process. In yet other embodiments, the process can wait a specified period of time for an acknowledgement before moving on to the next block. In some embodiments, the MCD can send an negative acknowledgement only when there is an error in the message.

In some embodiments, the identify message sent atblock616 and/or the accessory capabilities message sent atblock620 must be sent in the order shown inFIG. 6. That is, in some embodiments, the identify message sent atblock616 and/or the accessory capabilities message sent atblock620 must be sent after the capabilities message is received from the MCD atblock614. Moreover, in some embodiments, the accessory info message, the accessory preferences message, the accessory protocol message, and/or the preferred applications message (seeblocks624,627,630,634) can be sent in any order and/or omitted. In other embodiments, the messages described in conjunction with the blocks depicted inFIG. 6 can be sent in any order.

FIG. 7 shows another flowchart of anidentification process700 according to some embodiments. Identification of the accessory begins atblock705. A start DIS command can be sent atblock710 indicating the beginning of identification. Identification information can be sent atblock715 using a send DIS information command. Identification information can include accessory name, accessory model number, accessory serial number, accessory type, accessory supported lingoes, accessory capabilities, accessory preferences, accessory protocols, preferred application identifier, accessory microphone capabilities, etc. Moreover, some identification information can be sent singularly as shown inFIG. 6 and/orFIG. 5. Various tokens, messages, and/or commands can be used to send identification information. For example, the tokens shown inFIG. 5 can be used to send identification information.

Atblock715 the accessory can send a DIS information command to provide some or all of its identification information to the MCD. Identification information sent atblock715 can include, e.g., accessory name, accessory model number, accessory serial number, accessory type, accessory supported lingoes, accessory capabilities, accessory preferences, accessory protocols, preferred application identifier, accessory microphone capabilities, etc. For example, in one embodiment, the identification information can be structured into tokens as shown inFIG. 5 and/or can be represented as a sequence of bytes. If the protocol for communication between the accessory and the MCD specifies that information is to be communicated as command packets (e.g., as described above), the identification information can be sent using one or more packets. Each packet can include a command code. In each packet the command code can be the same command code corresponding to a “DIS_Info” command, and the payload can contain a portion of the identification information. For example depending on the packet length supported by the protocol, a DIS_Info command packet can include all of the identification information or any portion thereof, such as a single token, some of the tokens, or a portion of a token. In some embodiments, the MCD can respond with an acknowledgement to confirm receipt of each DIS-Info command (or a negative acknowledgement to indicate packet error).

Once a DIS information command has been sent, if there is more identification information to be sent as determined atblock725, then process700 can return to block715 to send more identification information. If there is no more identification information to be sent, the process moves on to block730 by sending an end DIS message. An ACK DIS message can then be received atblock735 prior to ending atblock740. The ACK DIS message can include confirmation of the received identification information and/or that the received identification information was properly parsed. Whileprocess700 ends atblock740, the accessory can continue to communicate with the MCD, for example, by proceeding with authentication processes and/or using the lingoes specified in the identification information to communicate with the MCD.Process700 can include other actions; for example, generating information to be sent and/or requesting information from the MCD.

FIG. 8 shows a flowchart of anidentification process800 that can be performed by an MCD according to some embodiments.Process800 begins atblock850. A start DIS command is received from an accessory atblock855 indicating the beginning of a device identification sequence, and a next command from the accessory can be received atblock860. During the DIS sequence in some embodiments, the MCD responds only to DIS information commands and requests for information about the MCD such as lingo versions and MCD capabilities as described above. Accordingly, atblock865, the MCD can determine whether the next command is an End DIS command. If not, atblock866, the MCD can determine whether the next command is a DIS information command containing all or part of the identification information (e.g., as described above). When a DIS information command is received, the MCD can check for errors (e.g., packet transmission errors) atblock867. In some embodiments, MCD can send a message to the accessory confirming receipt of the DIS information command; in other embodiments, MCD does not send a response to a DIS information command unless an error occurs. If there are no errors, the MCD can simply store the received DIS information, e.g., in volatile or non-volatile memory. After checking for errors atblock867, processing returns to block860 to await the next command from the accessory.

If, atblock866, the command is not a DIS information command, then atblock868, it is determined whether the next command is a request for MCD information, e.g., a request for lingo version information and/or MCD capabilities information as described above. If so, then atblock869, the MCD returns a response to the accessory with the requested information and processing returns to block860 to await the next command from the accessory

Block870 is reached if a command other than a request for MCD information, a DIS information command or an End DIS command is received during the DIS. In some embodiments, the MCD can send an error message to the accessory atblock870 to indicate that the command is invalid; processing can return to block860 to await the next command from the accessory.

Process800 can continue to receive and respond to DIS-related commands until such time as an End DIS command is detected atblock865. The accessory can send any number of DIS information commands and any number of requests for information, and the commands and requests need not be sent in any particular order. DIS information can be collected and stored (e.g., in memory) until an End DIS command is received.

Once an End DIS command is detected atblock865, the MCD can parse the received DIS information atblock872. As noted above, the DIS information can be sent using one or more DIS information commands, and parsing can include processing the totality of DIS information extracted from all of the received DIS information commands. In one embodiment, the DIS information can be structured by the accessory in an arrangement similar to an XML dictionary with key-value pairs, and parsing atblock872 can leverage known techniques to separate the information into tokens (code-value pairs) and to determine the content of each token.

In some embodiments, some or all of the tokens can be fixed-length tokens and the code portion of the token can also be fixed length (e.g., one or two bytes). During parsing atblock872, the MCD can read the code portion of the token and determine the token length based on the code. In other embodiments, some or all of the tokens can be variable-length and the token can include length information in addition to the code-value pair. For example, the token can be structured such that a fixed-length code (e.g., one or two bytes) occupies the first position, followed by a length indicator (e.g., one byte). The MCD can read the code and the length indicator, then extract a token based on the length indicator.

Once the identification information has been parsed atblock872, the MCD can set its initial operating state in accordance with the DIS information atblock873. For example, the MCD can deliver the values associated with various tokens to specific processors, processing objects, modules or the like that can extract parameter settings, etc., or the MCD can write certain values directly to an appropriate control and status register that controls operation of a processor, processing object, module, logic circuit, or the like. For example, in one embodiment the Lingoes token can contain a bitmask where each bit maps to a different lingo and the state of the bit (“1” or “0”) indicates whether the lingo is usable. In another embodiment, the Lingoes token can include a list of the usable lingo names. In either case, the MCD can deliver the information to a protocol manager that read the bits or list of names and enables or disables each lingo accordingly. As another example, a preferences token can include a bitmask that identifies whether specific capabilities and/or preferences should initially be enabled or not; for instance, bits can be assigned to audio line-in, audio line-out, video in, video out, and so on. The MCD can deliver this bitmask, e.g., to an audio and/or video processor that controls signal routing.

The MCD can also prepare and send an ACK DIS message to the accessory atblock875. The ACK DIS message can include confirmation of the received identification information and/or that the received identification information was properly parsed. If the information did not parse properly, the ACK DIS message can indicate the error condition.Process800 can end atblock880, and the MCD and accessory can thereafter communicate and interoperate on the basis of the information supplied. For example, the MCD can limit the accessory to using only lingoes that were identified in the identification information.

It will be appreciated that the identification processes described herein are illustrative and that variations and modifications are possible. Steps described as sequential may be executed in parallel, order of steps may be varied, and steps may be modified, combined, added or omitted. Any amount of accessory-identification information may be sent, and the amount of such information is not constrained. The accessory can send information in any order and in some embodiments is not required to send all types of information that may be supported by the identification protocol. In some embodiments, rather than using repeated instances of a DIS information command to send all identification information, a number of different commands can be defined and associated with different types of identification information. Further, in some embodiments, the MCD can parse identification information as it is received rather than waiting for the accessory to signal the end of the identification sequence. In some embodiments, after the accessory signals the end of the identification sequence, the MCD can reject any attempt by the accessory to reidentify or to add to or alter any of the previously provided identification information until such time as the accessory disconnects and reconnects. Thus, the identification sequence can define communication parameters associated with a session between an MCD and an accessory.

In some embodiments, transaction IDs can be utilized to facilitate matching messages, commands, requests, and/or tokens with received responses, acknowledgements, data, etc. In some embodiments, the transaction ID can comprise a two byte field that is added to packets being sent to and from the accessory. The transaction ID can be included in the header, payload, or tail of a packet. When an accessory communicates on multiple ports, an independent transaction ID counter can be used on each port. Every new or retried command at each port can receive an incremented transaction ID. If a response is spread over multiple packets, then each packet can include the same transaction ID. Moreover, requests from the MCD to the accessory can include a transaction ID generated by the MCD and an accessory can respond by sending a response with the same transaction ID.

For example, a message can be sent from the accessory to the MCD requesting lingo version information with a first transaction ID. The response can then include the first transaction ID indicating that the response is tied to the message requesting lingo versions. If, for some reason, the response is not received at the accessory, the accessory can resend the lingo version request. In doing so, the accessory can include a second transaction ID. When the MCD responds to the resent request, it can include the second transaction ID. If, for some reason, the MCD responds to the first request after the second request has been sent, the first response can be ignored because it does not include the proper transaction ID.

Moreover, acknowledgments can include a transaction ID to indicate what message the MCD is acknowledging.FIG. 9 shows an example of commands being passed between an accessory and an MCD using transaction IDs according to some embodiments. Any number and/or types of commands, messages, packets, etc. can be sent and/or received with transaction IDs as described above.

InFIG. 9 aStart DIS message902 is sent from the accessory to the MCD with transaction ID 0x0001. In response, anacknowledgement903 is returned with the same transaction ID indicating that the acknowledgement is sent in response toStart DIS message902.Accessory capabilities message904 can be sent to the MCD from the accessory with transaction ID 0x0002. In this example anegative acknowledgement906 is sent indicating missing data, byte errors, with the same transaction ID 0x0002. Accordingly, the accessory resends anaccessory capabilities message908 to the MCD with a new transaction ID 0x0003. Anacknowledgment910 is returned by the MCD with the same transaction ID 0x0003. Followingacknowledgement910, the MCD and/or accessory can exchange other messages and/or commands not shown in the figure.

AnEnd DIS message912 is sent to the MCD with transaction ID 0x0004. However, for whatever reason, the MCD does not acknowledge receipt of the End DIS message. The accessory can then resend the End DIS message913 with transaction ID 0x0005. Areturn acknowledgement914, for example, with status information, can be sent from the MCD and received at the accessory with transaction ID 0x0005. The accessory and MCD can continue with the DISprocedure following block914 using transaction IDs as indicated.

At some later point, get authentication information message916 can be sent from the MCD to the accessory with a new transaction ID 0x0001, because it is being sent from the MCD to the accessory. A returnauthentication information message918 can be sent from the accessory to the MCD with the same transaction ID 0x0001. The messages described in conjunction withFIG. 9 can be sent as tokens. For example the tokens can include the values described in the table shown inFIG. 5.

In some embodiments, an accessory can request capabilities information from an MCD. In response, the MCD can respond by identifying the capabilities supported or negatively acknowledge the request indicating such requests are unsupported. Requests can be made for different lingoes and/or different supported features. In some embodiments, the accessory can request capabilities information from an MCD prior to a device identification sequence, during a device identification sequence, or after a device identification sequence. Moreover, capabilities request can occur at any time while an accessory is coupled with an MCD. For example, a capabilities request can occur prior to accessing certain capabilities.

MCDs can support any number of commands of a lingo and can be configured to provide various capabilities. Moreover, some MCDs can support a limited subset of lingoes and/or provide a limited number of capabilities. It can be useful for an accessory to know which lingoes are supported by the MCD and/or what features the MCD is capable of Thus, some embodiments can allow an accessory to request capabilities information from an MCD.FIG. 10 shows a flowchart of aprocess1000 that an accessory can use to request capabilities information from an MCD.

FIG. 10 starts atblock1002. At block1004, the accessory can determine whether it is coupled with an MCD.Process1000 can remain at block1004 until the accessory is coupled with the MCD. Atblock1006, the accessory can send a request to the MCD for capabilities of the MCD associated with a specified lingo. For example, the accessory can require capability information from the MCD for one or more lingoes to determine how to interoperate with the MCD. As another example, future accessories can support advanced capabilities, by requesting capabilities information the accessory can determine if the advanced features are supported by the MCD. In some embodiments, a command such as the GetCapabilties command can be used atblock1006. A request can be sent before or after authentication and/or before or after identification of the accessory with the MCD. Capabilities for any type and/or any number of lingoes can be requested usingprocess1000. Furthermore, in some embodiments, capabilities for any number of features and/or commands can be requested.

If a negative acknowledgement (NACK) is received atblock1008, it could mean one of two things: the MCD does not support sending capabilities information in response to a request from an accessory or the lingo specified inblock1006 is not supported. Thus, atblock1010 the accessory can determine whether the NACK indicates that the request is unsupported or whether the lingo associated with the request is unsupported. If the request is unsupported, then process1000 can end atblock1018. If the lingo is not supportedprocess1000 can move to block1014. In some embodiments, if a NACK is returned in response to a request for capabilities of a general lingo atblock1006, then the NACK indicates that the requests for capabilities are not supported. Furthermore, if a NACK is returned in response to any other lingo atblock1006, then the NACK indicates that the lingo specified in the request is unsupported. In other embodiments, if the NACK returns the lingo associated with the request sent inblock1006, then the NACK indicates that the lingo is unsupported andprocess1000 can move to block1014. If the NACK does not indicate a lingo then the request is unsupported andprocess1000 can end atblock1018.

For example, a GetCapabilities command can be sent from the accessory to the MCD. This command can include the lingo for which capabilities are sought. Upon receiving the GetCapabilities command the MCD can determine whether it supports (e.g., recognizes) the GetCapabilities command. If not, then MCD can send a NACK, which can be received at the accessory atblock1008. If the GetCapabilities command is supported, then the MCD can identify the capabilities of the MCD by sending a RetCapabilities command that indicates the lingo and/or the associated supported capabilities atblock1012. For example, the RetCapabilities command can include a bitmask and each bit within the bitmask can be associated with a specific capability. Thus, for example, the MCD can send a bitmask with bits asserted that are associated with supported capabilities. Thus, the accessory, upon receipt of the command, can know which capabilities are supported by noting which bits are or are not asserted within the bitmask. The command can also include an indication of the associated lingo. Specific examples of lingoes and capabilities associated therewith are described below.

If capability information for other lingoes is needed and/or desired by the accessory atblock1014, then another lingo is selected atblock1016 and a request for the capabilities associated with this lingo can be requested atblock1006. If, however, the capabilities associated with other lingoes are not requested thenprocess1000 ends atblock1018. In some embodiments, the accessory can request lingo-capability information at anytime while connected with a mobile communication device. In other embodiments, an MCD can reject a request unless an accessory is in an appropriate state (e.g., before or during DIS).

Capabilities for various lingoes can be requested by an accessory. For example, these lingoes can include any of the following: a general lingo, a microphone lingo, a remote control lingo, a remote display lingo, a remote user interface lingo, a location lingo, a storage lingo, a wireless communication lingo, a video lingo, an audio lingo and/or any other type of lingo.

In some embodiments, general MCD capabilities can be associated with a general lingo. Such capabilities can be requested by an accessory and a corresponding response can be returned by the MCD. The general capabilities can include, for example, simple video output capabilities (e.g., whether video output is available, and if so the channel video output is available on), video signal format capabilities (e.g., NTSC, PAL, etc.), video signal type capabilities (e.g., composite video output, S-video output, component video output, etc.), closed caption capabilities, video aspect ratio capabilities (e.g., fullscreen, widescreen, etc.), video resolution capabilities, subtitle capabilities, alternate audio channel capabilities (e.g., whether audio is available on a channel separate from the video signal, and if so, the audio channel), etc. In some embodiments, these video capabilities can also be associated with other lingoes.

In some embodiments, communication capabilities can be associated with a communication lingo and can include communication protocol capabilities (e.g., whether other communication protocols are supported, whether application specific communication protocols are supported, etc.), notifications capabilities (e.g., whether the MCD supports sending the accessory notifications regarding communications at the MCD), wireless communication capabilities (e.g., whether the MCD supports WiFi, cell radio, Bluetooth, etc., and whether the MCD can allow the accessory to access to the wireless communication), and high power capabilities. For example, in response to a request from an accessory for capabilities associated with a general lingo, the MCD can return a message with bits asserted in a bitmask that can indicate that NTSC video format is supported, closed captioning is supported and WiFi communication is supported by the MCD. Any other combination can also be specified.

In some embodiments, capabilities associated with a microphone can be requested by the accessory. The capabilities associated with a microphone can include, for example, duplex support capabilities, voice processing capabilities, remote headphone capabilities, remote microphone capabilities, mono/stereo capabilities, etc. In some embodiments, a microphone lingo can be associated with these capabilities.

In some embodiments, capabilities associated with various types of media can be requested by the accessory and can include whether the accessory can control the presentation of audio media, video media, image media, sports media, microphones, and/or a radio (e.g., WiFi, Bluetooth, cell radio, etc.). For example, audio media control can indicate whether the accessory can control playback of audio media. In some embodiments, capabilities associated with volume control can be requested by the accessory and can be associated with capabilities such as whether the accessory can provide local and/or absolute volume control.

In some embodiments, capabilities related to location services can be requested by the accessory, these capabilities can include, for example, whether the MCD can support sending GPS data to the accessory and/or whether the MCD can support receiving GPS data from the accessory. In other embodiments, capabilities of the MCD can include whether the MCD can support sending and/or receiving ephemeris data. These capabilities, for example, can be associated with a location lingo.

While examples of some specific lingoes and capabilities have been disclosed, other lingoes and/or capabilities can be used without limitation. Moreover, capabilities described above in association with a specific lingo or as part of a group of capabilities can be associated with any other lingo and/or in any other group of capabilities without limitation.

While the invention has been described with respect to specific embodiments, those skilled in the art will recognize that numerous variations, modifications and/or combinations are possible. Tokens can be sent in any order, as long as the association of a token's code and value is maintained. In some embodiments, a token can be split between multiple packets. In some embodiments, a token code can be sent in a first packet along with a first portion of the token value within the payload of a packet. A second packet can include the remainder of the token value in the payload of the packet. In some embodiments, the payload of the second packet can also include the token code followed by the token value. In some embodiments, the token code is not included within the payload of the packet or packets following the first packet. In some embodiments, the token value can be segmented and sent with more than two packets. In some embodiments, a token value can be sent within a single packet. The packet header, in some embodiments, can identify the length of the packet such that the length of the payload includes the length of the token code and the token value. Moreover, the tokens shown inFIG. 5 can be sent in any order. In some embodiments, one token can be sent. In some embodiments, only two of the tokens shown inFIG. 5 can be sent.

Circuits, logic modules, processors, and/or other components can be described herein as being “configured” to perform various operations. Those skilled in the art will recognize that, depending on implementation, such configuration can be accomplished through design, setup, interconnection, and/or programming of the particular components and that, again depending on implementation, a configured component might or might not be reconfigurable for a different operation. For example, a programmable processor can be configured by providing suitable executable code; a dedicated logic circuit can be configured by suitably connecting logic gates and other circuit elements; and so on.

While the embodiments described above can make reference to specific hardware and software components, those skilled in the art will appreciate that different combinations of hardware and/or software components can also be used and that particular operations described as being implemented in hardware might also be implemented in software or vice versa.

Computer programs incorporating various features can be encoded on various non-transitory computer-readable medium; suitable media include magnetic disk or tape, optical storage media, such as compact disk (CD) or digital versatile disk (DVD), flash memory, and the like. Computer-readable storage media encoded with the program code can be packaged with a compatible device or provided separately from other devices. In addition program code can be encoded and transmitted via wired optical, and/or wireless networks conforming to a variety of protocols, including the Internet, thereby allowing distribution, e.g., via Internet download.

While various specific embodiments have been described herein, it will be appreciated that all modifications, equivalents, and/or combinations are within the scope of the following claims.

Claims (19)

What is claimed is:

1. A method of communication between an accessory and a mobile computing device using tokens, the method comprising:

establishing, by the accessory, communication with the mobile computing device;

sending, by the accessory, a message to the mobile computing device requesting information about the mobile computing device;

receiving, by the accessory, a plurality of tokens from the mobile computing device in response to the message, wherein each token includes (i) a portion of the information about the mobile computing device and (ii) a code identifying a type for the portion of the information about the mobile computing device, wherein at least one of the plurality of tokens comprises information about capabilities supported by the mobile computing device;

parsing, by the accessory, the plurality of tokens to determine the at least one token;

analyze the at least one token to determine information about the capabilities supported by the mobile computing device; and

interacting, by the accessory, with the mobile computing device using the capabilities supported by the mobile computing device.

2. The method according toclaim 1 wherein the message sent to the mobile computing device includes a request for providing capabilities related to a specific lingo and the at least one token received from the mobile computing device includes information about capabilities supported by the mobile computing device that are related to the specific lingo.

3. The method according toclaim 2 wherein the accessory requests capabilities information related to more than one lingo.

4. The method according toclaim 1 wherein the at least one token received from the mobile computing device includes a bitmask with each bit representing whether a specific capability is supported by the mobile computing device.

5. The method according toclaim 1 wherein the capabilities include video formatting capabilities.

6. The method according toclaim 5 wherein the video formatting capabilities include one or more capabilities from a group consisting of video output, NTSC video format, PAL video format, composite video out, S-video video out, NTSC connection, closed captioning, full screen video aspect ratio, widescreen video aspect ratio, and subtitles.

7. The method according toclaim 1 wherein the capabilities include one or more capabilities from a group of capabilities consisting of line out usage, video output, cross-transport authentication, mobile computing device protocols, notifications, duplex support, audio media control, video media control, image media control, sports media control, GPS data output, and volume control.

8. An accessory device comprising:

a communication interface configured to communicate with a mobile computing device; and

control logic coupled with the communication interface, the control logic being configured to:

send messages to and receive messages from the mobile computing device via the communication interface,

send a request for providing information about the mobile computing device;

receive a response, including one or more tokens, from the mobile computing device, wherein each of the one or more tokens includes (i) a portion of the information about the mobile computing device and (ii) a code identifying type of the portion of information included in the token, and at least one token includes information about the capabilities of the mobile computing device;

parse the one or more tokens to identify the at least one token that includes information about the capabilities of the mobile computing device; and

analyze the at least one token to determine capabilities supported by the mobile computing device.

9. The accessory device according toclaim 8 wherein the control logic is further configured to interact with the mobile computing device using at least one of the supported capabilities.

10. The accessory device according toclaim 8 wherein the control logic is further configured to receive a negative acknowledgement when the mobile computing device does not support the request for providing information about the mobile computing device.

11. The accessory device according toclaim 8 wherein the capabilities include one or more capabilities of the mobile computing device from a group consisting of wireless capabilities, microphone capabilities, remote control by the accessory capabilities, video capabilities, audio capabilities, and location capabilities.

12. The accessory device according toclaim 8 wherein the lingo is selected from the group of lingoes consisting of a general lingo, a microphone lingo, a remote control lingo, a remote display lingo, a remote user interface lingo, a location lingo, a storage lingo, a wireless communication lingo, a video lingo, and an audio lingo.

13. A method comprising:

establishing a communication session between an accessory and a mobile computing device;

receiving, by the mobile computing device from the accessory, a plurality of tokens including information about the accessory and a request for capabilities associated with a specific lingo; wherein each token includes a code identifying type of information included in the token and a value providing the actual information;

parsing, by the mobile computing device, the plurality of tokens to determine a token that includes the request for capabilities associated with the specific lingo;

in the event that the mobile computing device supports the specified lingo, sending, by the mobile computing device, a capabilities message to the accessory, in response to the request, indicating the capabilities of the mobile computing device associated with the specified lingo; and

in the event that the mobile computing device does not support the specified lingo, sending, by the mobile computing device, a negative acknowledgment to the accessory.

14. The method according toclaim 13 wherein the capabilities message includes a bitmask and wherein each bit in the bitmask indicates whether a specific capability is supported by the mobile computing device.

15. The method according toclaim 13 wherein the lingo is selected from the group of lingoes consisting of a general lingo, a microphone lingo, a remote control lingo, a remote display lingo, a remote user interface lingo, a location lingo, a storage lingo, a wireless communication lingo, a video lingo, and an audio lingo.

16. A mobile computing device comprising:

a communication interface configured to communicate with an accessory; and

control logic coupled with the communication interface, the control logic being configured to:

send messages to and receive messages from the accessory via the communication interface;

receive one or more tokens from the accessory, wherein the one or more tokens include authentication information for the accessory and a request from the accessory for providing supported capabilities of the mobile computing device associated with a specific lingo; wherein each token includes (i) a code identifying type of information included in the token and (ii) the actual information;

parsing the one or more tokens to determine a token that includes the request; and

in the event that the mobile computing device supports the specified lingo the control logic is further configured to send, in response to the request, a bitmask from the mobile computing device to the accessory that specifies capabilities associated with the specified lingo that are supported by the mobile computing device; and

in the event that the mobile computing device does not support the specified lingo the control logic is configured to send a negative acknowledgement to the accessory.

17. The mobile computing device according toclaim 16 wherein the control logic is further configured to interact with the accessory using the specified lingo.

18. A non-transitory computer-readable medium containing program instructions that, when executed by a controller within a mobile communication device, causes the controller to execute a method of communicating capabilities information between a mobile communication device and an accessory, the method comprising:

receiving one or more tokens from the accessory, the one or more tokens including identifying information of the accessory and a request for providing capabilities information of the mobile communications device; wherein each token includes (i) a code identifying type of information included in the token and (ii) a value providing the information;

parsing the one or more tokens to identify a token that includes the request; and

sending a data string comprising a bitmask identifying the capabilities supported by the mobile communication device in response to the request.

19. The non-transitory computer-readable medium according toclaim 18 wherein the request for capabilities comprises a request for capabilities associated with a specific lingo.

Images