Abstract:
A network including a client and server may send capability determining software from the server to the client. At the client, the software determines the capability of each particular client, forms a message, and sends that message back to the server. Based on the message received as a result of the operation of the software, the server can better provide its services to the client in some embodiments.

Description:
BACKGROUND  
         [0001]    This invention relates generally to processor-based systems including personal computers, telephones, set-top boxes, and personal digital assistants, to mention a few examples.  
           [0002]    Commonly a set of networked processor-based systems may be served by a server that provides information to and receives information from a plurality of clients in the network. A server may need to determine the current characteristics of a client in the network. This may be important to determining what software can be downloaded from the server to the client or to determine what tasks the client may be called upon to perform. For example, the server may wish to know the client&#39;s processor speed, memory size, screen size, input protocols to mention a few examples.  
           [0003]    Conventionally, the assessment of client capabilities may be based on what is known as a classmark. Classmarks are hard-coded values that provide information about the capabilities of the client. The format, content and information conveyed by classmarks must be determined prior to deployment of the client itself.  
           [0004]    As a result, classmarks are not amenable to changing circumstances, conditions and hardware and software environments. The types of services being deployed by a network may evolve relatively rapidly. However, the classmark scheme relies on the assumption that all relevant capabilities may be incorporated prior to the first client shipment. As a result, the classmark scheme is relatively inflexible.  
           [0005]    Thus, there is a need for better ways to determine client capabilities in networks. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0006]    [0006]FIG. 1 is a schematic depiction of one embodiment of the present invention;  
         [0007]    [0007]FIG. 2 is a flow chart for software on a server in accordance with one embodiment of the present invention; and  
         [0008]    [0008]FIG. 3 is a flow chart for software on a client in accordance with one embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0009]    Referring to FIG. 1, a network  10  may include a server  12  coupled to a client  24  by a link  20 . The link  20  may be a wired or wireless link. Suitable wired links  20  include telephone lines, optical lines, and conventional cables. Suitable wireless links  20  include radio frequency and infrared links.  
         [0010]    While only one client  24  is illustrated, commonly a plurality of clients  24  may be coupled by one or more links  20  to the server  12 . Thus, a conventional client server relationship may be established. The client server relationship may be as a conventional local area network (LAN) in one embodiment. As another embodiment, the network may be part of a telephone network. The telephone network may be circuit-based or packet-based.  
         [0011]    Thus, in one example, the client  24  may be a particular telephone and the server  12  may be a base station. In such case, the link  20  may be a wired or wireless link depending on the type of telephone network.  
         [0012]    The server  12  may include an interface  18  that is coupled to the link  20  as well as a storage  14  that stores software  16  and  28 . Conventionally, the server  12  is processor-based, meaning that it includes at least one or more processors to implement various functions.  
         [0013]    Similarly, the client  24  is also processor-based. The client  24  may include an interface  22  to a link  20 .  
         [0014]    When the server  12  needs to determine the capabilities of the client  24 , it may run the software  16  shown in FIG. 2 in accordance with one embodiment of the present invention. Initially, the server  12  selects an appropriate client probe routine from a probe routine library as indicated in block  30 . The probe routine library may be a plurality of probe routines that may be utilized depending on the characteristics of the client  24 . Thus, the server  12  applies the information it has about the client  24  in order to assess and determine the appropriate probe routine.  
         [0015]    In one embodiment of the present invention, the classmark information may be utilized to select the appropriate probe routine. In such case, rather than using the classmark as the sole client information, the classmark is merely utilized to determine which probe routine to send to a particular client  24  as indicated in block  30 .  
         [0016]    Next, the probe routine is transferred to the client  24  over the link  20  as indicated in block  32 . The server  12  then awaits a response from the probe routine at the client  24  as indicated in block  34 . The probe routine response may then be used in one embodiment to configure the content or application to be downloaded to the client  22  as indicated in block  36 . Thus, the probe routine may be utilized to provide services that are specifically tailored to the characteristics or capabilities of a particular client  24 .  
         [0017]    Because the probe routines are stored in the storage  14  on the server  12  in accordance with one embodiment, they can be essentially continuously updated. Thus, the probe routines may be refined to better query the client  24  given the current operating circumstances, conditions, and updates to mention a few examples. As a result, the use of the probe routine may be more flexible than the classmark scheme in some situations.  
         [0018]    Turning next to FIG. 3, the probe routine software  28  running on the client  24  is initialized as indicated in block  40  in accordance with one embodiment of the present invention. Once the client software  28  is provided by the server  12  to the client  24 , it initializes on the client  24  as indicated in block  40 . The software  28  then executes on the client  24 , scanning the operating environment of the client  24  for details about device capabilities as indicated in block  42 . For example, the software  28  may examine various files including Registries on the client  24 .  
         [0019]    The software  28  then develops a capability description based on the information gleaned from the client  24  as indicated in block  44 . That information is transformed into an appropriate message to be sent from the client  24  to the server  12 . Finally, the capability message is sent by the client  24  back to the server  12  as indicated in block  46 .  
         [0020]    In one embodiment of the present invention, the software  28  may then remain resident on the client  24 . Subsequently, that same software  28  may be reactivated or, if necessary, new software or updated software may be sent from the server  12  to the client  24 .  
         [0021]    While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.