Abstract:
In the case of a universal serial bus (USB) connection, a host detects a connection of a peripheral to the host via a USB interface of the host. The host then generates an informative command, which includes information on capabilities of the host. This informative command is provided for transmission via the USB interface to the peripheral. The peripheral receives the informative command and may for instance evaluate the included information for selecting a suitable USB mode that is to be entered or for deciding on becoming a host itself. Alternatively or in addition, the host may generate a request command for retrieving information on all classes offered in all USB modes of a peripheral.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention relates to methods, to processing arrangements, to devices, to systems, to software program codes and to software program products supporting universal serial bus (USB) connections. 
       BACKGROUND OF THE INVENTION 
       [0002]    The document “Universal Serial Bus Specification”, Revision 2.0, Apr. 27, 2000 by Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC and Philips defines an industry-standard USB, which enable an easy to use connection between a personal computer (PC) acting as a host and another device acting as a PC peripheral. Host and peripheral may be interconnected by a USB cable. The host is responsible for initiating all data transactions between host and peripheral, while the peripheral responds to bus requests from the host. 
         [0003]    According to the USB specification, a host obtains information about the functions supported by a peripheral during an enumeration process. When connecting a peripheral to a host, the peripheral will announce in this enumeration process more specifically all USB classes and interfaces it provides in its current USB mode. The term USB mode is used in the present document to define a state of a device in which it supports a predetermined set of USB classes and/or interfaces. A class identifies a function provided by the peripheral, for example a keyboard function, a printer function or a mass storage function, etc. A composite or compound peripheral may provide a plurality of different classes. Thus, in different USB modes of the peripheral, the host may access different functions of the peripheral. An interface is a related set of endpoints that present a single feature or function of the peripheral to the host. The protocol used to communicate with this related set of endpoints and the purpose of each endpoint within the interface may be specified as part of a device class or vendor-specific definition. A mobile phone with three different USB modes, for example, may support in a first USB mode “Mode 1” a Wireless Mobile Communication (WMC) OBject EXchange (OBEX) interface, a MODEM interface, and some proprietary interfaces. It may further support in a second USB mode “Mode 2” only an Mass Storage Class (MSC) interface. It may further support in a third USB mode “Mode 3” only a Still Image Capture Device (SICD) interface, for instance as a base for Picture Transfer Protocol (PTP) and PictBridge or Media Transfer Protocol (MTP). 
         [0004]    It is a disadvantage of the USB standard that the peripheral only announce the classes and interfaces that are supported in the current USB mode of the peripheral. The host may only detect other functions of a peripheral by starting the connection setup again. In the scope of this new setup, the peripheral may then possibly announce another set of classes in a new enumeration process. In an alternative approach for detecting additional classes of a peripheral, a user query may be used. In such a user query, a user may be asked which function of the peripheral should be used, and this function is then announced to the host on the USB bus. 
         [0005]    In the USB specification, a device can moreover be only a host or only a peripheral. The fixed role of a device can also be identified by its connector, as USB cables have different plugs on their two ends. A host has more specifically a Standard A receptacle and a peripheral has more specifically a Standard B receptacle. This approach is well suited for a computer environment, which USB was originally designed for. Here, the PC is always the host, and devices that are connected to the PC are always peripherals. Peripherals provided with a USB interface could also benefit from an interaction among each other, though. 
         [0006]    A more flexible use of a USB connection is enabled by the “On-The-Go Supplement to the USB 2.0 Specification”, Revision 1.0a, Jun. 23, 2003. The USB On-The-Go (OTG) additions to the USB standard allow USB connectivity for devices, which do not have such a clear host or peripheral role as a PC and a memory card reader. Dual-role devices typically perform multiple functions, like a mobile phone, a personal digital assistant (PDA), or a digital camera. For example, a mobile phone might have to be a peripheral providing a class “mass storage” when connected to a PC, while it might have to be a host when connected to a printer or an external keyboard etc. 
         [0007]    Based on the USB-OTG, a clear host device may have a Standard-A receptacle or a Mini-A receptacle, while a clear peripheral device may have a Standard-B receptacle or a Mini-B receptacle. In addition an OTG device has a Mini-AB receptacle, the latter enabling a connection of either a Mini-A plug for hosts or a Mini-B plug for peripherals. An OTG device must further support a limited host capability and a specified Host Negotiation Protocol (HNP). In USB-OTG, the respective role of the involved devices is thus assigned by the USB cable as well. However, if the connected devices are OTG devices, a role switch can be performed after the connection has been established based on the HNP. 
         [0008]    Still, if a user connects two USB-OTG devices, the only function or set of functions that can be performed is the one that is associated to the class or the set of classes announced by the device to which the peripheral role was assigned by the way the user connected the USB cable. If the user desires to make use of a different function or set of functions, he/she may trigger a “disconnect-reconnect”, for example by means of a user input through a user interface, hoping that the peripheral would announce a second class or set of classes. Alternatively, the user might cause a “role switch” based on the HNP, hoping that the former host would then announce the desired class or set of classes in the peripheral role. 
       SUMMARY OF THE INVENTION 
       [0009]    It is an object of the invention to improve the usability of USB connections between two devices. It is in particular an object of the invention to improve the user experience during a USB connection. 
         [0010]    A first method is proposed for a host side of a USB connection. The method comprises generating at a host, which is connected via a USB interface of the host to a peripheral, an informative command, the informative command including information on capabilities of the host. The method further comprises providing the informative command for transmission via the USB interface to the peripheral. 
         [0011]    Moreover, a first processing arrangement is proposed, which is adapted to generate an informative command, the informative command including information on capabilities of a host, which is connected via a USB interface of the host to a peripheral. The first processing arrangement is further adapted to provide the command for transmission via the USB interface to the peripheral. 
         [0012]    It has to be noted that this processing arrangement can be implemented in hardware and/or in software. It could comprise for instance software program code that is executed by a processing unit or a chip or chipset comprising a circuit, which realizes corresponding functions. 
         [0013]    Moreover, a first device is proposed, which comprises a USB interface enabling the device to act as a host in a USB connection with another device acting as a peripheral, and which comprises the proposed first processing arrangement. 
         [0014]    Moreover, a first software program code is proposed, which is adapted to realize the steps of the proposed first method when being executed by a processing unit of a host. 
         [0015]    Moreover, a first software program product is proposed, in which the proposed first software program code is stored in a readable memory. Such a software program product can be for instance a separate storage device or a memory that is to be implemented in a device providing the host functionality. 
         [0016]    In addition, a second method is proposed for a peripheral side of a USB connection. The second method comprises receiving at a peripheral an informative command from a host including information on capabilities of the host, the peripheral being connected via a USB interface of the peripheral to the host. 
         [0017]    Moreover, a second processing arrangement is proposed, which is adapted to receive at a peripheral an informative command from a host including information on capabilities of the host, the peripheral being connected via a USB interface of the peripheral to the host. The received information may be used by the processing arrangement as a basis for a decision. 
         [0018]    Moreover, a second device is proposed, which comprises a USB interface enabling the device to act as a peripheral in a USB connection with another device acting as a host, and which comprises the proposed second processing arrangement. 
         [0019]    Moreover, a second software program code is proposed, which is adapted to realize the steps of the proposed second method when being executed by a processing unit of a peripheral. 
         [0020]    Moreover, a second software program product is proposed, in which the proposed second software program code is stored in a readable memory. Such a software program product can be for instance a separate storage device or a memory that is to be implemented in a device providing the peripheral functionality. 
         [0021]    Finally, a system is proposed, which comprises the proposed first device and a further device acting as a peripheral. 
         [0022]    The invention proceeds from the consideration that it would be beneficial if the peripheral knew the USB functions supported by the host device. It is therefore proposed that a host that is linked by a USB connection to a peripheral informs the peripheral about its capabilities. These capabilities can relate to services that may be requested by the host as well as to services that may be provided by the host when acting as a peripheral. 
         [0023]    It is an advantage of the invention that the peripheral automatically obtains knowledge about the USB capabilities of the host. This enables the peripheral for example to select a USB mode, which fits best to the requirements of the host. Further, it enables the peripheral for example to decide whether it may be interested in switching the roles of host and peripheral in order to take advantage of USB services offered by the current host. 
         [0024]    The host may generate the indicated informative command for example upon detection of a connection to a peripheral, but equally independently of a detection of such a connection. The host may detect a connection when it is new or at any other time. 
         [0025]    The information on capabilities of the host included in the informative command may comprise an indication of at least one class supported in at least one USB mode of the host and/or an indication of at least one interface offered for at least one USB mode of the host. Advantageously, all classes and all interfaces in all USB modes of the host are indicated in the informative command, in order to provide comprehensive information to the peripheral. 
         [0026]    Conventionally, a host is also not able to select a USB mode that is to be entered by the peripheral. Since the host is not aware of the classes and interfaces the peripheral may support when operating in other USB modes than the current USB mode, a USB mode selection can only be done on peripheral side but never on host side. That is, the host is not able to force the peripheral into a particular USB mode. 
         [0027]    According to an embodiment of the invention, in contrast, the host may generate in addition a request command. The request command may be used for retrieving an indication of all classes, and optionally all interfaces, offered in all USB modes of the peripheral. The request command may then equally be provided for transmission via the USB interface to the peripheral. 
         [0028]    On the host side, this allows forcing the peripheral into a particular USB mode, which may suit best for the capabilities or the current USB mode or the current requirements of the host. The host may select to this end a desired USB mode of the peripheral based on the retrieved indication of all classes offered in all USB modes of the peripheral. The host may then generate a set command for forcing the peripheral into a selected USB mode and provide the set command for transmission via the USB interface to the peripheral. The peripheral might confirm whether it received a set command and/or whether it entered an indicated USB mode by a corresponding message to the host. 
         [0029]    The informative command, the request command and the set command are advantageously generated at the host before a get command is generated at the host for obtaining information on at least one class offered by the peripheral in a current USB mode of the peripheral. Such a get command can be for instance a standard Get Device Descriptor command. If the peripheral does not obtain an informative command, a request command or a set command before it receives the Get Device Descriptor command, it will know that these commands are not supported at the host side or at least not used for a current USB session. The peripheral may then act in a conventional manner upon receipt of the get command. 
         [0030]    It has to be noted, though, that there is no restriction at all when to use the informative command, the request command and the set command. They can be used at any other time as well. Still, when sending them before any other USB command, the peripheral can directly show the new configuration, which might prevent the necessity of a disconnect and connect operation. 
         [0031]    The informative command, the request command and the set command can but do not have to be vendor specific commands. 
         [0032]    Conventionally, a peripheral is not aware which classes and interfaces a host supports. If the peripheral knows the classes, which are supported by the host, in contrast, it may enter a supported USB mode automatically and enumerate the classes and interfaces in the supported USB mode without user interaction. Alternatively or in addition, the peripheral could enumerate the provided USB modes which fit best to the classes supported by the host. For example, if a common functionality between two devices is “mass storage”, the devices could easily detect a feasible combination. If one of the devices supports in addition only a “printing” class, and the other device supports in addition only an “input device” class, moreover no other suitable combinations can be found. Consequently, the correct combination could be detected at the peripheral by a simple logic and a user does not have to be bothered with selecting a function. 
         [0033]    According to an embodiment of the invention, the peripheral has several options for selecting a USB mode that is to be entered. The USB mode may be selected based on the received information on capabilities of the host. There may be for instance exactly one USB mode of the peripheral, which is suited to offer a useful service to the particular host. The USB mode may further be selected based on a set command from the host for forcing the peripheral into a particular USB mode. These options for an automatic selection improve the user experience, as they limit the need for a user input. If the peripheral is not able to select a particular USB mode automatically, it can still take some action to let the user decide to select a USB mode. In this case, the USB mode may be selected based on the user input. 
         [0034]    The invention can be employed for any device supporting USB. The host may be a device, which can only assume the role of a host, and the peripheral may be a device, which can only assume the role of a peripheral. Alternatively, at least one of the host and the peripheral could be an OTG device, to which the role of a host or of a peripheral can be assigned. It is to be understood that in this case, all functions described for the end of a host could be implemented in addition at the end of an OTG peripheral and that all functions described for the end of a peripheral could be implemented in addition at the end of an OTG host. 
         [0035]    Conventionally, a role switch between a host and a peripheral is rendered difficult by the fact that the USB standard does not enable the current peripheral to obtain knowledge about the capabilities of the current host, neither for the services it may request in its host-role nor for the services it may offer in a peripheral-role. 
         [0036]    According to an embodiment of the invention, in contrast, the current peripheral may further determine whether to become a host based on the received information on capabilities of the current host. 
         [0037]    In one embodiment of the invention, the proposed service discovery is defined in the form of a protocol. 
         [0038]    It is to be understood that all described functions can be implemented in the proposed system, processing arrangements, devices, software program codes and software program products. 
         [0039]    The supported classes on host side and on peripheral side can comprise any class that is suited for supporting a service over a USB connection, like a keyboard class or another input device class, a printer class, for instance a PictBridge class enabling a digital camera to print an image directly via a printer, a SICD class or another imaging class, a mass storage class, an audio or video output class, etc. 
         [0040]    It is further to be understood that the USB connection between a host and a peripheral could be a connection via a USB cable, but it could also be some kind of a wireless connection which provides an access to the USB of the peripheral on the one hand and to the USB of the host on the other hand. 
         [0041]    For a second aspect of the invention, a method is proposed, which comprises generating at a host, which is connected via a USB interface of the host to a peripheral, a request command, the request command retrieving information on all classes offered in all USB modes of the peripheral. The method further comprises providing the request command for transmission via the USB interface to the peripheral. 
         [0042]    For the second aspect of the invention, moreover a processing arrangement is proposed, which is adapted to generate at a host, which is connected via a USB interface of the host to a peripheral, a request command, the request command retrieving information on all classes offered in all USB modes of the peripheral. This processing arrangement is further adapted to provide the request command for transmission via the USB interface to the peripheral. 
         [0043]    For the second aspect of the invention, moreover a device is proposed, which comprises a USB interface enabling the device to act as a host in a USB connection with another device acting as a peripheral, and which comprises the processing arrangement proposed for the second aspect of the invention. 
         [0044]    For the second aspect of the invention, moreover a software program code is proposed, which is adapted to realize the steps of the method proposed for the second aspect of the invention when being executed by a processing unit of a host. 
         [0045]    For the second aspect of the invention, moreover a software program product is proposed, in which the software program code proposed for the second aspect of the invention is stored in a readable memory. Such a software program product can be for instance a separate storage device or a memory that is to be implemented in a device providing the host functionality. 
         [0046]    For the second aspect of the invention, finally a system is proposed, which comprises the device proposed for the second aspect of the invention and a further device acting as a peripheral. 
         [0047]    The request command can thus be generated as well independently from the generation of an informative command. 
         [0048]    In one embodiment of the second aspect of the invention, the host may select a desired USB mode of the peripheral based on the retrieved information on all classes offered in all USB modes of the peripheral. The host may then generate a set command for forcing the peripheral into a selected USB mode, and provide the set command for transmission via the USB interface to the peripheral. 
         [0049]    It is to be understood that the method, the processing arrangement, the device, the software program code, the software program product and the system of the second aspect of the invention can be implemented in accordance with or be combined with any embodiment presented for the first aspect of the invention. 
     
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0050]    Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings. 
           [0051]      FIG. 1  is a schematic diagram of a system according to an embodiment of the invention; and 
           [0052]      FIG. 2  is an exemplary message flow chart in the system of  FIG. 1 . 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0053]      FIG. 1  is a schematic diagram of a system which enables an improved usability of USB connections between two devices in accordance with an exemplary embodiment of the invention. 
         [0054]    The system comprises a first device  10 , which may be for instance a mobile terminal, and a second device  20 , which may be for instance a digital camera. It is to be understood that the devices  10 ,  20  could be various other types of devices as well, like a PDA or a PC, etc. 
         [0055]    The mobile terminal  10  comprises a CPU  11 . The CPU  11  is connected to a user interface  12  of the mobile terminal  10 , including for instance a display and a keypad, etc. The CPU  11  is further connected via a USB  13  to a USB interface  14  of the mobile terminal  10 , by way of example a Mini-AB receptacle. The CPU  11  is moreover connected to a memory  15  of the mobile terminal  10 . 
         [0056]    The CPU  11  is adapted to execute various software program codes implemented in the mobile terminal  10 . These software program codes may be stored for example in the memory  15 , which can be accessed by the CPU  11 . The memory  15  may comprise for instance a USB-OTG software program code  16  for execution by the CPU  11 . The USB-OTG software program code  16  is responsible for managing any USB connection of the mobile terminal  10  to another device. The USB-OTG software program code  16  includes to this end a connection detector portion  17 , a vendor specific command manager portion  18 , a standard control and data flow manager portion  19  and other conventional USB-OTG software program code portions (not shown). 
         [0057]    It is to be understood that the mobile terminal  10  comprises various other components not shown. 
         [0058]    The digital camera  20  comprises a user interface  22  including a display and associated buttons, etc. Moreover, the digital camera  20  comprises as well a USB interface  24 , by way of example a Mini-AB receptacle. The USB interface  24  is connected via a USB  23  to a chipset  21  or a chip. The chipset  21  realizes the same functions as the portions of the USB-OTG software program code  16 . The chipset  21  comprises to this end a USB-OTG processing circuit  26  with a connection detector portion  27 , a vendor specific command manager portion  28 , a standard control and data flow manager portion  29  and other conventional USB-OTG processing components (not shown). It is to be understood that alternatively, the digital camera  20  could equally comprise a CPU and a memory corresponding to those of the mobile terminal  10 . The different implementation was only selected for illustrating that the invention may be implemented in different ways. 
         [0059]    The chipset  21  is also linked directly or indirectly to the user interface  22 . 
         [0060]    It is to be understood that the digital camera  20  comprises various other components not shown. 
         [0061]    An operation according to an embodiment of the invention in the system of  FIG. 1  will now be described with reference to the message flow chart of  FIG. 2 . 
         [0062]    The chart of  FIG. 2  presents the message flow between a host depicted on the left hand side and a peripheral depicted on the right hand side. It has to be noted that the Figure presents only the USB transaction level, not the associated data, which is transmitted via the USB. The normal USB flow is token packet, optional data packet and handshake packet. 
         [0063]    At first, a USB connection is established between the mobile terminal  10  and the digital camera  20  (step  101 ). The connection can be established for instance by means of a cable, where the mobile terminal  10  is defined to be a host by connecting a Mini-A plug of the cable to the Mini-AB receptacle  14 , and where the digital camera  20  is defined to be a peripheral by connecting a Mini-B plug of the cable to the Mini-AB receptacle  24 . 
         [0064]    The connection detector portion  27  of the digital camera  20  detects the USB connection and the assigned role of a peripheral, and sets the pull up resistors associated to the USB to enable a host to detect the peripheral (step  102 ). 
         [0065]    The connection detector portion  17  of the mobile terminal  10  detects the USB connection and the assigned role of a host, and detects the digital camera  20  as a peripheral due to the set pull up resistors (step  103 ). 
         [0066]    The vendor specific command manager  18  then generates a first VENDOR_SPECIFIC command, which comprises an indication of all classes and all interfaces that are supported in all USB modes of the mobile terminal  10 . Advantageously, this informative command is sent in the beginning, but it has to be noted that it could also be sent at any later point of time. The informative command is transmitted via the USB  13 , the Mini-AB receptacle  14  and the cable connection to the digital camera  20  (step  104 ). Thereby the mobile terminal  10  advertises its own USB capabilities to the digital camera  20 . 
         [0067]    The digital camera  20  receives the informative command via the Mini-AB receptacle  24  and forwards it via the USB  23  to the chipset  21 . Based on the indication in the informative command, the digital camera  20  knows now what classes and interfaces the mobile terminal  10  supports. In the chipset  21 , a mode selection logic of the vendor specific command manager portion  28  detects which one of the USB modes of the digital camera  20  fits best to the USB capabilities of the mobile terminal  10 . The vendor specific command manager portion  28  further takes care that the received command is acknowledged (not shown) and that the digital camera  20  is set to the selected USB mode (step  105 ). Such a selection may not be possible, in case the indicated USB functionalities of the host  10  are suited to make use of several USB modes of the peripheral  20 , or in case the peripheral  20  does not provide any USB functions for the specific kind of host  10 . In the present case, for instance, the mobile terminal  10  might support a “print mode” for requesting a connected peripheral printer to provide a printout, and an “internal mass storage mode” enabling some host to access a mass storage of the mobile terminal  10 . The digital camera  20  might equally support an “internal mass storage mode” enabling some host, like a PC, to access a mass storage of the digital camera  20 , and an “external mass storage mode” for requesting image data to be stored in some peripheral offering a mass storage. Thus, the digital camera  20  might not detect any USB mode in which it could offer some function to the mobile terminal  10 . It is to be understood, however, that the mobile terminal  10  and the digital camera could be adapted to enter one or more other USB modes, in which the digital camera  20  could offer some function to the mobile terminal  10 . 
         [0068]    The vendor specific command manager portion  18  further generates a second VENDOR_SPECIFIC command for retrieving all classes and all interfaces that are supported in all USB modes of the digital camera  20 . This request command is transmitted via the USB  13 , the Mini-AB receptacle  14  and the cable to the digital camera  20  (step  106 ). 
         [0069]    The digital camera  20  receives the request command via the Mini-AB receptacle  24  and forwards it via the USB  23  to the chipset  21 . In the chipset  21 , the vendor specific command manager portion  28  takes care that the requested information can be retrieved by the mobile terminal  10 . 
         [0070]    The mobile terminal  10  discovers in this way all classes and all interfaces in all USB modes supported by the digital camera  20 , not only the services that are provided in a current USB mode of the digital camera  20 . 
         [0071]    The vendor specific command manager portion  18  may now determine, based on the received information about the functionalities of the digital camera  20 , which USB mode of the digital camera  20  is suited best for current requirements of the mobile terminal  10  on USB services. In case such a USB mode can be determined, the vendor specific command manager portion  18  further generates a third VENDOR_SPECIFIC command for forcing the USB mode of the digital camera  20  to enter this specific USB mode (step  107 ). This set command is equally transmitted via the USB  13 , the Mini-AB receptacle  14  and the cable to the digital camera  20  (step  108 ). 
         [0072]    The digital camera  20  receives the set command as well via the Mini-AB receptacle  24  and forwards it via the USB  23  to the chipset  21 . In the chipset  21 , the mode selection logic of the vendor specific command manager portion  28  takes care that the digital camera  20  is set to the USB mode requested in the set command (step  109 ). The vendor specific command manager portion  28  further generates a VENDOR_SPECIFIC message with corresponding status information about the set USB mode, which is transmitted reversely compared to the set command to the mobile terminal  10  (step  110 ). 
         [0073]    In case no set command is received, the mode selection logic of the vendor specific command manager portion  28  may take care that a default USB mode is entered. It has to be noted, though, that also other approaches could be implemented for the case that no set command is received, but they might require a change of the tests for qualification defined in the USB specification. In  FIG. 2 , it is indicated for example that in case no set command is received after a predetermined time and no USB mode has been selected in step  105 , the mode selection logic of the vendor specific command manager portion  28  take care that a USB mode or service selection menu is presented to the user on the display of the user interface  22  of the digital camera  20 . The user may select a desired USB mode by entering a command via the buttons of the user interface  22  (step  111 ). 
         [0074]    The USB mode or modes in all vendor specific commands can be identified simply by a unique number to distinguish the class sets. 
         [0075]    Once the mobile terminal  10  has forced the digital camera  20  to a desired USB mode—or in case no setting of a USB mode is desired, once the mobile terminal  10  has discovered all USB functions offered by the digital camera  20 —, the system proceeds with the standard USB operation (step  120 ). 
         [0076]    That is, the standard control and data flow manager portion  19  of the mobile terminal  10  generates a Get Device Descriptor command, which is transmitted to the digital camera  20  (step  121 ). 
         [0077]    When the Get Device Descriptor command is sent from the mobile terminal  10  to the digital camera  20 , the discovery phase according to the invention is terminated. It is to be understood that the order of the generation and transmission of VENDOR_SPECIFIC commands used for this discovery process can be selected freely. Advantageously, they are completed before the Get Device Descriptor command is transmitted, though. 
         [0078]    Upon receipt of the Get Device Descriptor command, the standard flow manager portion  29  of the digital camera  20  returns the descriptor for the entered USB mode, including the classes and interfaces supported in this USB mode (step  122 ). A descriptor is a data structure with a defined format, which is used by USB peripherals for reporting their attributes. The standard control and data flow manager  19  may then proceed with the desired data exchange. 
         [0079]    If no discovery by means of VENDOR_SPECIFIC commands has been carried out by the mobile terminal  10  before the Get Device Descriptor command is received from the mobile terminal  10 , the digital camera  20  can execute a default behavior, which may correspond to the standardized USB behavior. 
         [0080]    It is to be noted that the operation described so far could also be carried out by a host having a Standard A or a Mini-A receptacle and a peripheral having a Standard B or a Mini-B receptacle. In the case, the USB-OTG software  16  or USB-OTG processing circuit  26  could be a general USB software  16  or USB processing circuit  26  realizing the described functions. 
         [0081]    The Mini-AB receptacles  14 ,  24  are required for the case that host and peripheral are to be able to switch their role. 
         [0082]    The digital camera  20  could take the role of a host and the mobile terminal  10  could take the role of a peripheral from the very beginning by reversing the connection between the Mini-AB receptacles, that is, by connecting the Mini-A plug of the cable to the digital camera  20  and the Mini-B plug to the mobile terminal  10 . In this case, the steps  103  to  122  described with reference to  FIG. 2  would simply be carried out with switched roles by mobile terminal  10  and digital camera  20 . 
         [0083]    Alternatively, the initial roles could be switched without reversing the cable connection. 
         [0084]    In case the mobile terminal  10  does not want to make use of any USB service offered by the digital camera  20  or in case the mobile terminal  10  has completed making use of such a USB service, the digital camera  20  will detect that there is no more ongoing activity on the USB  23 . After a predetermined time during which the USB  23  has been idle, the digital camera  20  may decide that it could make use of a USB service offered by the mobile terminal  10 . To this end, the digital camera  20  may present the indicated capabilities of the mobile terminal  10  to the user via the display of the user interface  22  and enable a selection of a desired service via the buttons of the user interface  22 . Upon a user selection, the role of host and peripheral may then be switched in accordance with the Host Negotiation Protocol described in the above mentioned On-The-Go Supplement to the USB 2.0 Specification, starting off with the digital camera  20  turning off its pull-up registers (steps  130 ,  131 ). 
         [0085]    In case there is a reset of the USB connection or in case a new USB address is set for one of the devices  10 ,  20 , the same operations may be carried out as for a new connection (steps  101 - 130 ). 
         [0086]    On the whole, it becomes apparent that the presented embodiment of the invention enables host and peripheral of a USB connection to obtain knowledge of the entire USB capabilities of one another during the first connection setup or after a change in the connection, which may be hidden without the described discovery procedure. As a result, the peripheral may be enabled to select a suitable USB mode automatically and/or the host may be enabled to force the peripheral to enter a suitable USB mode. The need for a user action can thus be minimized, which also prevents unsuitable user selections, resulting in better ergonomic device design. Specifically for USB- OTG, an initial peripheral is further able to evaluate the capabilities of the initial host. 
         [0087]    While the informative command, the request command, the set command and the confirmation message have been indicated to be vendor specific messages, it is to be understood that they could equally be standardized messages. 
         [0088]    It is to be noted that the described embodiment constitutes only one of a variety of possible embodiments of the invention.