Abstract:
The present invention relates generally to wireless networking, and more particularly to methods and apparatuses for providing flexible WiFi docking with minimal overhead. According to certain aspects, embodiments of the invention include methods and apparatuses that allow a WD to select peripherals in a configuration that is useful for the WD from a Topology point of view. According to certain other aspects, embodiments of the invention include methods and apparatuses that allow peripherals to be used as part of the Docking Session, but does not require using all the peripherals all the time. According to certain additional aspects, embodiments of the invention include methods and apparatuses that allow for dynamically switching the use of peripherals with minimal overhead. According to still further additional aspects, embodiments of the invention include methods and apparatuses for signaling user authentication functionality for certain peripherals to be used in a docking session.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit under 35 USC 119(e) of prior co-pending U.S. Provisional Patent Application No. 61/943,110, filed Feb. 21, 2014, and U.S. Provisional Patent Application No. 61/944,411, filed Feb. 25, 2014, each of which is hereby incorporated by reference in its entirety. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates generally to wireless networking, and more particularly to methods and apparatuses for providing flexible WiFi docking with minimal overhead. 
       BACKGROUND OF THE INVENTION 
       [0003]    Currently, the WiFi Docking program in the WiFi Alliance is defining a set of protocols between a Wireless Dockee (WD) and Wireless Docking Center (WDC) to facilitate WiFi docking. In general, WiFi docking allows a roaming WiFi device to access peripherals such as printers or displays that are connected either wired or wirelessly in a WiFi network. One goal of the WiFi docking program of the WiFi Alliance is to not require any changes on the peripheral side to allow for current WiFi peripherals to be used for docking. 
         [0004]    As part of a docking session setup, a WDC provides the following to the WD: (1) A list of peripherals that are available and with which the WD can have a docking session facilitated by the WDC; (2) The state of each peripheral is signalled to the WD as: (a) Available, (b) Occupied, (c) Sleep, (d) Disconnected, or (e) Unpaired; and (3) A single sign-on facility for a WD to facilitate security setup with the peripherals, which allows the WDC to facilitate security setup between WD and the peripherals. 
         [0005]    Once the WD selects a “Peripheral,” the WDC expects that the peripheral is in the state “Available” for use by the WD during the docking session. This will also allow for user experience a WD would expect from the peripherals offered by WDC. However, this would mean the WDC should have already set up a link with the selected peripheral, thereby constraining the use of the selected peripheral by other devices in the environment. 
         [0006]    For example, if a printer device is offered by the WDC as a peripheral, then the printer should be already configured to connect to the WDC, as an example via WiFi Direct (possibly using persistent connection). The peripheral should also be available for use immediately once the WD picks the peripheral. 
         [0007]    More particularly, in a home environment, a WD device would like to use the printer via the WDC if it is already docked to allow for better power saving (i.e. there is no need to establish connection with the printer separately). But if the WD selects the peripheral, and it doesn&#39;t use it, then the peripheral cannot be used by another device (i.e. it cannot be part of another WiFi Direct Group, until and unless the printer creates a Group). The trade off in this scenario is providing a consistent docking experience (i.e. connectivity and use of peripherals) and also at the same time allowing autonomy for peripherals to be used flexibly (i.e. not constrained because they are used in docking environment). 
         [0008]    Conventionally, either the peripheral was part of the docking session or removed from the docking session. This increases the overhead (i.e. the WD has to keep adding and removing the peripheral) and doesn&#39;t allow for a WD to dynamically switch the use of a peripheral. 
         [0009]    Accordingly there remains a need in the art for a solution addresses the problem above among others. 
       SUMMARY OF THE INVENTION 
       [0010]    The present invention relates generally to wireless networking, and more particularly to methods and apparatuses for providing flexible WiFi docking with minimal overhead. According to certain aspects, embodiments of the invention include methods and apparatuses that allow a WD to select peripherals in a configuration that is useful for the WD from a topology point of view. According to certain other aspects, embodiments of the invention include methods and apparatuses that allow peripherals to be used as part of the docking session, but does not require that all the peripherals are used all the time. According to certain additional aspects, embodiments of the invention include methods and apparatuses that allow for dynamically switching the use of peripherals with minimal overhead. According to still further additional aspects, embodiments of the invention include methods and apparatuses for signaling user authentication functionality for certain peripherals to be used in a docking session. 
         [0011]    In accordance with these and other aspects, a method embodiments of the invention includes initiating a WiFi docking session between a WiFi Dockee (WD) and a WiFi Docking Station (WDC); providing a list of peripherals that are accessible by the WDC to the WD, wherein one of the peripherals is in a first state; and allowing the WD to select the one peripheral to include in the WiFi docking session in a second state that is different than the first state. 
         [0012]    In additional furtherance of the above and other aspects, a method according to embodiments of the invention includes initiating a WiFi docking session between a WiFi Dockee (WD) and a WiFi Docking Station (WDC); providing a list of peripherals that are accessible by the WDC to the WD; allowing the WD to select one of the peripherals to include in the WiFi docking session along with user authentication credentials; and determining, by the WDC, whether to accept the selection based on the user authentication credentials. 
         [0013]    In yet additional furtherance of the above and other aspects, a system according to embodiments of the invention includes a WiFi Dockee (WD); a WiFi Docking Station (WDC); a plurality of peripherals that are accessible by the WDC, wherein one of the peripherals is in a first state; and a signaling protocol between the WD and the WDC that allows the WD to select the one peripheral to include in a WiFi docking session between the WD and WDC in a second state that is different than the first state. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    These and other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures, wherein: 
           [0015]      FIG. 1  is a block diagram illustrating an example docking environment according to embodiments of the invention; 
           [0016]      FIG. 2  is a diagram illustrating example signaling for implementing peripheral state and switching functionality according to embodiments of the invention; and 
           [0017]      FIG. 3  is a diagram illustrating example signaling for implementing user authentication functionality for a docking session according to embodiments of the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0018]    The present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention to a single embodiment, but other embodiments are possible by way of interchange of some or all of the described or illustrated elements. Moreover, where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Embodiments described as being implemented in software should not be limited thereto, but can include embodiments implemented in hardware, or combinations of software and hardware, and vice-versa, as will be apparent to those skilled in the art, unless otherwise specified herein. In the present specification, an embodiment showing a singular component should not be considered limiting; rather, the invention is intended to encompass other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein. Moreover, applicants do not intend for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration. 
         [0019]    The present invention will be described below in conjunction with embodiments compatible with standards such as those of the WiFi Alliance Docking Program. However, the invention is not limited to these embodiments, and the principles of the invention can be extended using other standards or proprietary or other wireless environments such as wireless PAN networks built on Zigbee, car docking technologies, etc. 
         [0020]      FIG. 1  is a block diagram illustrating aspects of an example docking environment according to embodiments of the invention. 
         [0021]    In the example, a “Dockee”  102  (i.e. WD) is the device that is being docked to a “Docking Station” device  104  (i.e. WDC). Both the WD  102  and the WDC  104  are connected to a Wi-Fi Infrastructure (e.g. a wireless home network provided by a Wi-Fi access point (i.e. Wi-Fi AP  106 ) connected to the Internet via a cable, DSL or other modem  108 ) via links “B” and “F” respectively, in addition to being directly linked together via link “A”. Some peripherals are also connected to the Wi-Fi AP  106  (e.g. printer  110  connected via link “E”). Peripherals can be connected to WDC  104  over wired connections (e.g. display  116  connected via link “I”), or via wireless technologies other than Wi-Fi (e.g. Bluetooth keyboard  114  connected via link “H”), in addition to Wi-Fi connections (e.g. scanner  112  connected via link “G”). 
         [0022]    In embodiments, the “Dockee” device WD  102  is typically included in any portable device (e.g. iPhone or similar smartphone, iPad or similar tablet computer, smart watch, laptop or notebook computer, etc.) that has built-in WiFi (i.e. IEEE 802.11) and possibly other wireless (e.g. Bluetooth) transceiver capabilities, as well as WD (i.e. per the WiFi Alliance Docking Program) functionality such as those provided in chipsets and associated firmware from manufacturers such as CSR. Those skilled in the art will be able to implement the Dockee functionality of the invention by adapting such chipsets and/or firmware after being taught by the present examples. In an example where WD  102  is implemented in a computer running Windows OS, WD  102  can further include application and/or driver software running under Windows that allows a user to interact and control certain WD  102  functions such as selecting peripherals to include in a docking session, setting up profiles to select peripherals based on the environment (e.g. home, enterprise, etc.), etc. Similar user interface functionality can be included in other types of devices where WD  102  is implemented. It should be noted that, to be capable of supporting functionalities such as WiFi Direct, Miracast Service, etc., a software driver will typically be required along with specific hardware. For example, to be certified by the WiFi Alliance, particular driver and hardware capabilities associated with WD functionality are required to be supported by the device. However, such implementation specific details will be omitted here for sake of clarity of the invention. 
         [0023]    In embodiments, the “Docking Station” device WDC  104  is either a standalone device (e.g. a device similar to a wired docking system), a peripheral device (e.g. display screen) that has integrated WiFi (i.e. IEEE 802.11) and WDC (i.e. per the WiFi Alliance Docking Program) functionality, or it can be a device such as a laptop/desktop computer that can allow a dockee to use its built-in peripherals (e.g. built-in monitor) or peripherals connected to it either by wired connection (e.g. USB, HDMI, DVI, etc.) or wirelessly (e.g. Bluetooth, WiFi, WiFi Direct, etc.). In embodiments, WDC functionality is implemented by chipsets and associated firmware from manufacturers such as CSR. Those skilled in the art will be able to implement the principles of the invention by adapting such chipsets and/or firmware after being taught by the present examples. Moreover, similar to WD  102 , to be capable of supporting functionalities such as WiFi Direct, Miracast Service, etc., a software driver will typically be required along with specific hardware for WDC functionality. 
         [0024]    The peripherals (i.e. PFs) available for a docking session (i.e. potentially belonging to a logical group called a Wireless Docking Environment (WDN)) in this example include: a WiFi printer  110  connected to WD  102  via a WiFi Direct link “D” or via the WDC  104  and WiFi infrastructure (links “E” and “F”); a display  116  connected via wired (e.g. USB, HDMI, etc.) interface (i.e. link “I”) to WDC  104 ; a WiFi scanner  112  connected to WDC  104  via a WiFi Direct link “G”; and a keyboard  114  connected to both WD  102  and WDC  104  via Bluetooth links “C” and “H” respectively. It should be apparent that these are examples only and that many other types of peripheral devices can be used. 
         [0025]    It should be noted that other types of peripherals can be included in a docking session in addition to, or alternatively to, the peripherals shown in  FIG. 1 . For example, certain additional peripherals connected via WiFi AP  106  and/or router  108  can also be included in a docking session. Those skilled in the art will understand how to extend the principles of the invention to these other types of connections after being taught by the present examples. Moreover, the specific signaling for allowing a WD to actually communicate with and access the functionality of specific peripherals are known to those skilled in the art and details thereof will be omitted here for clarity of the invention. 
         [0026]    In this example, the current version of the Wireless Docking Technical Specification (e.g. Version 0.26, hereinafter “[1]” or “the standard,” the contents of which are incorporated herein by reference) allows WD  102  to use all the peripherals described above as part of its docking session with WDC  104 . However, according to embodiments of the invention, WD  102  might not choose all the peripherals at the same time and also not connect to them via the same topology (e.g. Direct/Relay as defined in [1]). In [1], the possible states of the peripherals are defined by the following structure: 
         [0000]    
       
         
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;xsd:simpleType name=“peripheralFunctionState”&gt; 
               
             
          
           
               
                   
                 &lt;xsd:restriction base=“xsd:string”&gt; 
               
             
          
           
               
                   
                 &lt;xsd:enumeration value=“available”/&gt; 
               
               
                   
                 &lt;xsd:enumeration value=“occupied”/&gt; 
               
               
                   
                 &lt;xsd:enumeration value=“sleep”/&gt; 
               
               
                   
                 &lt;xsd:enumeration value=“disconnected”/&gt; 
               
               
                   
                 &lt;xsd:enumeration value=“unpaired”/&gt; 
               
             
          
           
               
                   
                 &lt;/xsd:restriction&gt; 
               
             
          
           
               
                   
                 &lt;/xsd:simpleType&gt; 
               
               
                   
                   
               
             
          
         
       
     
       Where: 
       [0000]    
       
         
           
             ‘available’—The peripheral function is available for use. 
             ‘occupied’—The peripheral function is occupied. 
             ‘sleep’—The peripheral function needs to be woken up to be used. 
             ‘disconnected’—The peripheral function has been disconnected. This is more relevant for Wired Peripherals. 
             ‘unpaired’—The peripheral function is no longer paired with the WDC. 
           
         
       
     
         [0032]    The states of all the peripherals available for a docking session are advertised by the WDC  104  when WD  102  engages in a discovery session with WDC  104 . However, the present inventors recognize at least the following issues with some versions of the standard. 
         [0033]    For example, there is no option for WD  102  to select a peripheral and explicitly ask for that peripheral to be used in a certain “State”. For example, a peripheral that is “Unpaired’ with WDC  104  cannot be requested by WD  102  to be paired and used in a docking session for WD  102 . Also, if WD  102  wants to add a peripheral but does not need to use it except for limited times (e.g. a Printer), and if WDC  104  advertises that the peripheral is available, there is no way to make the peripheral part of WD  102 &#39;s WDN and also allow other WD&#39;s to use it while it is not needed. 
         [0034]    Along the same lines, WDC  104  cannot know the state in which WD  102  desires a peripheral to be in. The present inventors have determined that it would be desirable to have signaling (i.e., a WD can ask for the “state” to be set in specific manner), that would allow the WDC to provide the peripheral in the required “State” (as desired by the WD), otherwise the peripheral is still selected in the “State” that the WDC can offer to WD. 
         [0035]    To address these and other issues, embodiments of the invention implement new behaviour and functionality at WDC  104  and WD  102 . First, WD  102  can select/signal the “State” of the peripheral that it so desires to include in the WDN. In embodiments, the allowed “State” selections of the Peripheral are: (1) Available; (2) Disconnected (not using now but can use it later); and (3) Unpaired. Second, the WD  102  can also signal in the peripheral selection to WDC  104  if it still wants to include the peripheral in its docking session, even if the WDC  104  is not able to provide it in the state it so desires. 
         [0036]      FIG. 2  is a diagram illustrating an example signaling between a WD and WDC to implement this new behavior and functionality according to embodiments of the invention. This signaling will be described in an example implementation of the invention in a wireless system according to the WiFi Docking Alliance standards. However, the invention is not limited to this example. Moreover, it should be apparent that in this and other implementations, that many additional signaling and functionality may be possible. However, details thereof will be omitted here for sake of clarity of the invention. 
         [0037]    First, in S 202 , in a discovery session, WD  102  seeks a docking service with WDC  104 . This can be done in a conventional manner, through a SeekService method, for example. 
         [0038]    In response, in S 204  WDC  104  advertises the PFs available for a docking session using a conventional method such as an AdvertiseService. This list can further include the individual IDs of the PFs and the states of the PFs as set forth above. 
         [0039]    Next, in S 206 , perhaps in response to a user request of a device implementing the WD  102 , the WD  102  requests a docking session with WDC  104 . This can be done, for example, using a conventional CreateDockingSession method, for example. In this example, in S 208 , WDC  104  returns a DockingSessionId, which is a unique identification string of the docking session, and can be a random string generated by the WDC  104 . 
         [0040]    Next, according to embodiments of the invention, in S 210  WD  102  signals the peripherals it wants to use, as well as the states it wants them in. 
         [0041]    The current peripheral selection functionality in an example implementation according to the standard defined in [ 1 ] is signalled as: 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 PfSelection( ) 
                 DockingSessionId - IN 
               
               
                   
                   
                 PfSelectionStyle - IN 
               
               
                   
                   
                 PfSelectionList - IN 
               
               
                   
                   
                 DetailedPfInfoList - OUT 
               
               
                   
                   
                 NewEventSubURL - OUT 
               
               
                   
                   
               
             
          
         
       
     
         [0042]    In this example implementation, the WD  102  identifies its docking session using the ‘DockingSessionId’ action argument, and its desired set of PFs by either: a) setting the value of the ‘PfSelectionStyle’ action argument to “all” to indicate accepting the default WDN, or b) setting the value of the ‘PfSelectionStyle’ action argument to “specific”, and including a list of PF IDs in the ‘PfSelectionList’ action argument. 
         [0043]    However, the present inventors recognize that in the existing standard [1], there is no provision for any signaling from the WD  102  regarding the state in which the WD  102  would want to include any peripherals for a docking session. To allow the flexibility of the present invention, example embodiments include alternative or additional signaling from WD  102  to WDC  104  in S 210  as follows. 
         [0044]    When setting the value of the ‘PfSelectionStyle’ action argument to “specific”, along with including a list of PF IDs in the ‘PfSelectionList’ action argument, in embodiments the WD  102  also includes for each of the peripherals: (1) the state of the peripheral in which the WD  102  desires to use the peripheral (e.g. include a parameter “State” which is of type “PeripheralFunctionStateType”); and (2) an indication whether the peripheral should be included in the docking session only in the “State” signaled or whether it can it be included even if it is not available in the requested “State” (e.g. include a parameter “RequiredState” which can be of type Boolean). Note that the content of this field is used only for peripherals whose desired state (e.g. the included “State” parameter) is signaled to be “Available”. If the State is any other value other than “Available” this field can be ignored and the peripheral is included as part of the docking session. 
         [0045]    It should be apparent that many variations can be made to the above signaling to achieve the same or similar effect, and the invention is not limited to this example. Similar capability can be provided when using the selection style (PfSelectionStyle) to ‘all” i.e., including all the offered peripherals by WDC  104  to the docking session. 
         [0046]    The WDC  104  can work on providing the peripherals in the states that are requested by the WD  102 . However, it is not likely to be successful for all peripherals. In S 212 , the WDC  104  signals back to the WD  102  the “State” of the peripherals that it is finally able to provide. In embodiments, this information is included either in or as an additional field to “DetailedPfInfoList—OUT” data that is included in the response from the WDC  104  to the WD  102  for the WD  102 &#39;s PfSelection Request in S 210 . But if the WD  102  signals to the WDC  104  that it wants to include the peripheral irrespective of its preferred status in the docking session, the WDC  104  does the following: (1) It includes the peripheral in the docking session of the WD  102 ; and (2) If the WD  102  has signalled the Preferred State of the peripheral as “Available” but the WDC  104  is not able to provide it in “Available” state, the WDC  104  will continue monitoring the peripheral and once it can provide the peripheral to WD  102  in the state it so desires it updates the peripheral information to the WD  102  with the updated State (not shown in  FIG. 2 ). 
         [0047]    In embodiments, S 212  can also include a Rejection of any or all of the peripherals included in the PfSelection Request in S 210 . In addition, this rejection can include a reason why the request was rejected, such as if user authentication is required, insufficient resources (e.g. memory or bandwidth), usage conflict, etc. In embodiments, this can be included in OUT data of a PfSelection Request returned by the WDC  104 . 
         [0048]    As further shown, in S 214 , during a docking session WD  102  can choose to deselect a peripheral. This functionality already exists in [1]. However, embodiments of the invention further allow WD  102  in S 214  to further signal the “State” to either “Unpaired or Disconnected” but not remove the peripheral from its Docking Session. For example, the Deselect Procedure can be adapted to include the “State” information of the Peripheral that is signalled to the WDC  104  during the “PF De-Selection Procedure”. As such, the peripheral information, if it includes the “State” information, then the WD  102  is asking for a change in State of the peripheral. This would also leave up to the WDC  104  implementation whether to remove the ASP session between the WDC  104  and the peripheral. If the WDC  104  chooses to leave the ASP session (i.e. persistent connection), then the WDC  104  can re-establish the session between the WDC  104  and the peripheral for the use of WD  102  fairly quickly. If the signalling in S 214  does not include the “State” information, then the WD  102  is asking to remove the peripheral, as currently exists in [1]. 
         [0049]    In alternative implementations of S 214 , the WD  102  can signal the state of the desired peripherals included in its docking session explicitly as a separate UpNP message exchange “Update Peripheral State use for Docking”. 
         [0050]    In still further alternative implementations of S 214 , embodiments of the invention adapt the existing WD Specific WDN Create/Modify/Delete Procedure to allow WD  102  not just include or delete a peripheral but also include the “State” of the peripheral that is desired to be included as part of the docking session. This functionality is realized by the following two functions: 
         [0051]    1) WDN Create 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 WdnCreate( ) 
                 PfSelectionStyle - IN 
               
               
                   
                   
                 PfSelectionList - IN 
               
               
                   
                   
                 WdnId - OUT 
               
               
                   
                   
               
             
          
         
       
     
         [0052]    2) WDN Modify 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 WdnCreate( ) 
                 PfSelectionStyle - IN 
               
               
                   
                   
                 PfSelectionList - IN 
               
               
                   
                   
                 WdnId - OUT 
               
               
                   
                   
               
             
          
         
       
     
         [0053]    The changes to the “PfSelectionList” described above can be applied to these functions as well to realize the proposed flexibility in WD  102  selecting the peripherals for the docking session (i.e. the peripherals selected constitutes a WDN). Note that when modifying peripherals, it is possible to include only the peripherals that are either added to the docking session, or removed from the docking session or peripherals with a change in “State”. It is not required to include all the peripherals that are part of the docking session. 
         [0054]    In additional or alternative embodiments, the docking functionality of the present invention allows the use of peripherals based on the level of authorization each user has. 
         [0055]      FIG. 3  is a diagram illustrating an example signaling between a WD and WDC to implement this new behavior and functionality according to embodiments of the invention. This signaling will be described in an example implementation of the invention in a wireless system according to the WiFi Docking Alliance standards. However, the invention is not limited to this example. Moreover, it should be apparent that in this and other implementations, that many additional signaling and functionality may be possible. However, details thereof will be omitted here for sake of clarity of the invention. It should be further noted that this functionality can be included together with, or separately from, the peripheral state functionality described in connection with  FIG. 2 . 
         [0056]    First in S 302  (typically after similar signaling described in connection with S 202  to S 208  of  FIG. 2 ), WD  102  will use the docking session ID that is provided to WD  102  by WDC  104 , along with the credentials (e.g. User Type and Passpharase) to authenticate the user. In embodiments, the user authentication is realized by the following example method: 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 UserTypeAuth( ) 
                 DockingSessionId - IN 
               
               
                   
                   
                 UserType - IN 
               
               
                   
                   
                 PassPhraseDigest - IN 
               
               
                   
                   
               
             
          
         
       
     
         [0057]    In S 303 , WDC  104  responds whether the user is authorized to use the peripherals the user has requested to use. 
         [0058]    Based on the provided user authentication (e.g. from preset methods such as providing Guest access via a preset passphrase that is provided to the user if allowed to use the system/peripherals), WDC  104  can grant access to various peripherals that are offered to the WD  102  by WDC  104 . This functionality can be realized by WDC  104  using the following example method: 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 GetPfInfo( ) 
                 QueryInput - IN 
               
               
                   
                   
                 PfInfoList - OUT 
               
               
                   
                   
               
             
          
         
       
     
         [0059]    In this example, in S 304  WD  102  uses the ‘GetPfInfo’ action and supplies as an input argument ‘QueryInput’, through which the WD  102  indicates which PF information it is interested in. To support this, the WDC  104  at a minimum is able to understand the following QueryInput values: (1) /WDC/pfInfo/ (to select that the WD wants to receive the PF Info for all PFs managed by the WDC  104 ), and (2) /WDC/pfInfo/#/state=“available” (to select that the WD  102  wants to receive the PF Info for only PFs managed by the WDC  104  with status “available”). 
         [0060]    If the WDC  104  accepts the request, in S 306  the WDC  104  sends a UPnP Action Response message to the WD  102  with the actionNameResponse set to “GetPfInfo”, and with output argument ‘PfInfoList’ containing the information of the list of PFs matching the requested query input received through argument ‘QueryInput’. 
         [0061]    If the WDC  104  rejects the request, in S 306  the WDC sends a UPnP Action Response message to the WD  102  with the ‘errorCode’ field set to a proper value. 
         [0062]    Additionally or alternatively to the signaling described above in S 304  and S 306 , it is possible that the WDC  104  would like to limit the amount of information provided based on the “User Level Access” that a given WD  102  is allowed to have (e.g. based on its authentication). This can be realized by one or more of the following methods. 
         [0063]    In one example, alternatively to signaling described in S 304 , in S 308  the WD  102  in QueryInput signals to WDC  104  that it would like to limit the response to the peripherals that meet the Query Input criteria (e.g. all or State Available . . . etc), and the peripherals to which it has “Access to” based on its authentication (e.g. a Boolean Variable: 0=no limitation, 1=limit to User Authentication allowed Peripherals). Accordingly, alternatively to signaling in S 306 , in S 310  the WDC  104  in PfInfolist can limit the peripherals that the WD has access to. If there is no need for a “User Level Authentication” based access to the Peripehrals, the WDC  104  ignores the signaling from WD  102  about the “access based limitation”. 
         [0064]    In another example, alternatively to signaling in S 306  or S 310 , in response to an peripheral access limitation request in S 312 , in S 314  the WDC  104  in the PfInforList (Peripheral Information List), along with the “State” of the Peripheral, also includes a Parameter “Access Level” to signal to the WD  102  if it is allowed to use the peripheral or not. An example implementation can be an “Access Level” parameter (e.g. a Boolean (0 or 1 value) variable with “1” indicating that the WD  102  can access the peripheral, “0” indicating that the peripheral cannot be used (or) cannot be used with the current level of access rights that are allowed for the WD  102 ). 
         [0065]    According to certain aspects of the invention, without the knowledge of the limitation on the use of a peripheral for the WD  102 , once the WD  102  makes a selection of such a peripheral, the WDC  104  can choose to not include the peripheral in the docking session. This results in WD  102  not knowing why the peripheral is not included in the docking session and this can result in the WD  102  making repeated attempts to select the peripheral. Allowing for the signaling to limit the peripherals to “User Authentication” requirements limits the amount of data exchange and also limits the WD  102  from selecting a peripheral that it is not allowed to use. This can help in power saving at the WD  102 . 
         [0066]    Although the present invention has been particularly described with reference to the preferred embodiments thereof, it should be readily apparent to those of ordinary skill in the art that changes and modifications in the form and details may be made without departing from the spirit and scope of the invention. It is intended that the appended claims encompass such changes and modifications.