Abstract:
A method and system for a server-client communication in a network, is provided. The method includes, at a server: (1) requesting a client to establish an initial connection for discovery, including: generating a discovery beacon for requesting the initial connection, and transmitting the discovery beacon in the network; and (2) requesting the discovered client to establish a further connection for updates, including: generating at least one of an update beacon for requesting the further connection and an event for triggering the further connection, and transmitting the at lease one of the update beacon and the event in the network. The method includes, at a client: for discovery, detecting a discovery beacon from a server for establishing an initial connection, and establishing the initial connection, and for updates, detecting at least one of an update beacon from the server for establishing a further connection and an event for establishing the further connection, and establishing the further connection. A server system includes: an invitation unit for generating and transmitting a discovery beacon for discovering a new client in a network, and generating and transmitting at least one of an update beacon and an event for updating the discovered client in the network; and an administration unit for administering the discovered client, including at least one of: assigning the discovered client to a group; and assigning the server to the client to allow the client to respond to the discovery and update beacons from the assigned server. A client system includes: a beacon client for detecting an invitation beacon from a server, the invitation beacon including a discovery beacon for discovery and an update beacon for updates; an event identifier for detecting an event for the updates; a primary connection client for establishing an initial connection in response to the discovery beacon and establishing a further connection in response to at least one of the update beacon and the event.

Description:
FIELD OF INVENTION 
       [0001]    The present invention relates to a server-client network architecture, more specifically to a method and system for inviting connections from servers to clients. 
       BACKGROUND OF THE INVENTION 
       [0002]    Wireless networks can provide various services to users in a network. Such services include, for example, updating components of client terminals (e.g., installation of applications or software products). Conventionally, it is required to initiate announcement beacons from each client terminal to get a contact with a server and receive the services from the server. However, such client initiating announcement beacons would increase traffic in the network. In addition, it is difficult to manage a group of clients from the server. 
         [0003]    Therefore, there is a need to discovering and updating client terminals remotely and cost-effectively, without increasing the network traffic. Further, it is desirable that a group of clients are remotely and cost-effectively managed. 
       SUMMARY OF THE INVENTION 
       [0004]    It is an object of the invention to provide a server-client network architecture that obviates or mitigates at least one of the disadvantages of existing systems. 
         [0005]    According to an aspect of the present invention there is provided a method which includes, at a server: (1) requesting a client to establish an initial connection for discovery, including: generating a discovery beacon for requesting the initial connection, and transmitting the discovery beacon in the network; and (2) requesting the discovered client to establish a further connection for updates, including: generating at least one of an update beacon for requesting the further connection and an event for triggering the further connection, and transmitting the at lease one of the update beacon and the event in the network. 
         [0006]    According to another aspect of the present invention there is provided a method which includes, at a client: for discovery, detecting a discovery beacon from a server for establishing an initial connection, and establishing the initial connection, and for updates, detecting at least one of an update beacon from the server for establishing a further connection and an event for establishing the further connection, and establishing the further connection. 
         [0007]    According to a further aspect of the present invention there is provided a server system includes: an invitation unit for generating and transmitting a discovery beacon for discovering a new client in a network, and generating and transmitting at least one of an update beacon and an event for updating the discovered client in the network; and an administration unit for administering the discovered client, including at least one of: assigning the discovered client to a group; and assigning the server to the client to allow the client to respond to the discovery and update beacons from the assigned server. 
         [0008]    According to a further aspect of the present invention there is provided a client system includes: a beacon client for detecting an invitation beacon from a server, the invitation beacon including a discovery beacon for discovery and an update beacon for updates; an event identifier for detecting an event for the updates; a primary connection client for establishing an initial connection in response to the discovery beacon and establishing a further connection in response to at least one of the update beacon and the event. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0009]    These and other features of the invention will become more apparent from the following description in which reference is made to the appended drawings wherein: 
           [0010]      FIG. 1  is a block diagram showing a network system in accordance with an embodiment of the present invention; 
           [0011]      FIG. 2  is a schematic diagram showing a server and a client in the network system of  FIG. 1 ; 
           [0012]      FIG. 3  is a schematic diagram showing an invitation beacon from the server; 
           [0013]      FIG. 4  is a schematic diagram showing an example of a discovery process in the network of  FIG. 2 ; 
           [0014]      FIG. 5  is a schematic diagram showing an example of an update process in the network of  FIG. 2 ; and 
           [0015]      FIG. 6  is a schematic block diagram showing an example of the server and the client of  FIG. 2 . 
       
    
    
     DETAILED DESCRIPTION 
       [0016]    One or more currently preferred embodiments have been described by way of example. It will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the invention as defined in the claims. 
         [0017]    Referring to  FIG. 1 , a network system in accordance with an embodiment of the present invention is described. The network system  10  of  FIG. 1  forms a closed network where at least one server remotely discovers and manages at least one client terminal. The network system  10  has a terminal discovery mechanism for discovering new client terminals in the network and providing an initial deployment to the newly discovered client terminals, and an update mechanism for updating the discovered client terminals. These mechanisms are initiated by invitation beacons from the servers. The network system  10  applies a one sender/many listener scheme, which reduces the network usage. 
         [0018]    In  FIG. 1 , two servers  4   a  and  4   b  and three client terminals  6   a ,  6   b  and  6   c  are illustrated. However, the number of the servers and client terminals in the network may vary. The network may be a wireless network or a wired network. The client terminals  6   a ,  6   b  and  6   c  may be mobile terminals. In the description, the term “server” and “host” are used interchangeably. In the description, the term “client”, “terminal ” and “client terminal” are used interchangeably. In the description, the term “administrator”, “operator” and “user” may be used interchangeably. 
         [0019]    The invitation beacons include a discovery beacon. The discovery beacon requests a client terminal (e.g.,  6   c ) to establish an initial connection with a server (e.g.,  4   a ) in the network. The discovery beacon provides the means to send the connection information for a more advanced connection (for updates) to client terminals remotely. Through the initial connection, information on the client terminals may be provided to the server. 
         [0020]    The invitation beacons include an update beacon. The update beacon requests the discovered client terminal (e.g.,  6   c ) to establish a further (advanced) connection to a server (e.g.,  4   a  or  4   b ) in the network, for updates. The discovered client terminal may establish the advanced connection with a server in response to some events identified by that client terminal. Using the advanced connection, the server may provision and configure the discovered client terminals. 
         [0021]    When the client terminals are discovered initially, they are identified as the “unassigned group” in the server. Each discovered client terminal in the unassigned group is assigned to one or more groups. Once the client terminal is assigned to the respective group(s), then the client terminal is updated on a group basis. The client terminal in a group may be moved to another group by sending a new discovery beacon or an update beacon to the former group. 
         [0022]    The arrangement of a group allows one or more discovered client terminals to be targeted for updates. In one example, the group can be used as a functional unit that ties a set of components (e.g., files) or data to a set of client terminals. In this example, a set of components is downloaded to the client terminals in a group. One component may be assigned to zero to many groups. A set of the client terminals in the group may exchange data with the server. 
         [0023]    Using the server, an administrator manages the group (e.g., creating groups, modifying groups, and deleting groups), and the invitation beacons (e.g., transmitting the beacons, stopping the beacons), components and data transferred to the client terminals. 
         [0024]    In one example, a server transmits a discovery beacon and provides, to a client terminal, a locator of that server or another server to establish an initial connection and/or an advanced connection. A DNS address (for example, www.example.com) may be provided to the client terminals as the locator of a server, without providing a statically assigned IP address. 
         [0025]    The locator of a server may include URL identifying a specific web server. In one example, the URL may be provided to the client terminal through the discovery beacon only. The network system  10  can support any current or future security mechanism over IP as this is the responsibility of the connection referenced by the URL in the discovery beacon, not the beacon itself. 
         [0026]    Referring to  FIG. 2 , the network system  10  of  FIG. 1  is described in detail. In the network system  10 A of  FIG. 2 , a server  20  and a client terminal  40  are illustrated. The server  20  corresponds to each of the servers  4   a  and  4   b  of  FIG. 1 . The client terminal  40  corresponds to each of the client terminals  6   a ,  6   b  and  6   c  of  FIG. 1 . It would be appreciated by one of ordinary skill in the art that the network system  10 A may include more than one server  20  and more than one client terminal  40 . 
         [0027]    The server  20  includes a visual user interface (GUI)  22 , a database  24 , and a Web service module  26 . It would be appreciated by one of ordinary skill in the art that the server  20  may contain additional functions/elements/mechanisms other than those illustrated in  FIG. 2 . The server  20  communicates with the client terminal  40  through various interfaces including, for example, but not limited to, wireless connections via a secure or non-secure WLAN, WWAN or BlueTooth. 
         [0028]    The GUI  22  supports various functionalities, for example, client terminal and group maintenance, beacon configuration including start/stopping a beacon thread  28 , and component/data maintenance. 
         [0029]    The discovery and update beacon messages are transmitted from the beacon thread  28 . The beacon port is unidirectional from the server  20  to the client terminal  40  only. There is no client response on the beacon port. 
         [0030]    Using the GUI  22 , the user manages transmitting/stopping discovery beacons and update beacons. The beacons may be multicasted or broadcasted. The discovery beacon may be sent out periodically until that action is stopped by the server  20 . The update beacon may be sent out periodically until that action is stopped by the server  20  or all the targeted (group) client terminals take an action in response to the update beacon. Each beacon has a server ID identifying a beacon owner, i.e., a server as described below (e.g., Site ID of  FIG. 3 ). 
         [0031]    Once the client terminal  40  responds to the discovery beacon, it is added into a management list in the database  24 . The client terminal  40  may transfer, to the web service module  26 , information on that client terminal, including, for example, its serial number, operating system, device model number, terminal ID, IP addresses, or terminal name so that the discovered client terminal is uniquely identified by any of these information elements. 
         [0032]    The database  24  stores various information/data. Entities of the database  24  include, for example, but not limited to, a terminal and a group managed by the server  20  and component/data for updates. The database  24  is read or updated via the GUI  22  and the Web service module  26 . 
         [0033]    The Web service module  26  provides various Web services to the client terminal  40 . The server  20  acts as a Web server ( 26 ) whose location is identified by URL. The client terminal  40  locates the Web service  26  of the server  20  or another server, using the URL provided from the server  20 . 
         [0034]    In one example, the URL may be provided only through the discovery beacon from the server  20 . In this example, the client terminal  40  establishes initial and advanced connections, using the URL in the discovery beacon. 
         [0035]    In another example, a new URL may be provided after the establishment of the initial connection with the server, by sending another discovery beacon with the new URL. The client terminal  40  responds to the new discovery beacon that matches the server ID of the initial discovery beacon. 
         [0036]    In  FIG. 2 , the client terminal  40  connects to the Web service module  26  of the server  20  in response to the beacons from the server  20 . However, in a further example, the URL may be directed to another server, other than the server  20 . In this example, the client terminal  40  will not respond to the server  20 . 
         [0037]    The client terminal  40  includes a beacon client  42 , a primary connection client  44 , a repository  46 , and an event identifier  48 . It would be appreciated by one of ordinary skill in the art that the client terminal  40  may contain additional functions/elements/mechanisms other than those illustrated in  FIG. 2 . 
         [0038]    The beacon client  42  detects the invitation beacons from the server  20  and invokes a primary connection client  44 . The beacon client  42  includes a beacon listener that is always active and is responsible for launching the primary connection client  44  when a beacon requests the client terminal  40  to establish a connection with a server. 
         [0039]    The client terminal  40  establishes a connection with the web server identified by the URL, through the primary connection client  44 . For updates, the client terminal  40  may reuse a previously used server URL. The URL may be stored in the repository  46 . 
         [0040]    The event identifier  48  detects some events and launches the primary connection client  44 . The events identified by the event identifier  48  may include, for example, but not limited to, a scheduled event (alarm), a docking event, power on etc. The scheduled event may be set by the client terminal  40  or the server  20 . For example, an updating period is assigned by the server  20  once the client terminal  40  is discovered, so that the client terminal  40  connects back to the server  20  at a certain timing. The scheduled event is detected, for example, by a timer in the event identifier  48 . 
         [0041]    Referring to  FIG. 3 , the invitation beacon sent out from the beacon thread  28  is described in detail. The invitation beacon has, for example, the following format: a header, a message ID, Site ID size, Site ID, Group ID size, Group ID, URL size, and URL. 
         [0042]    The message ID is an identifier of the beacon. This is used to prevent the client terminal ( 40  of  FIG. 2 ) from acting on same beacon more than once. When a beacon (discovery, update beacon) is created it is assigned a message ID. For example, this beacon with the message ID is sent out periodically while more client terminals power up. The client terminal will ignore a beacon if it has the same message ID as the last beacon it received. 
         [0043]    The Site ID defines the Site ID for the server ( 20  of  FIG. 2 ). A different server has a different Site ID. The Site ID is assigned to all new and unassigned client terminals upon initial contact. Once assigned, the client terminal respond to both discovery and update beacons that have the same Site ID. The Site ID can be used to prevent a discovered client terminal from responding to another server and prevent any client terminal from responding a second time to a repeated discovery beacon. A client terminal that has never received a discovery beacon may have a blank Site ID. A client terminal without the site name set will respond to any site name. The Site ID size defines the size of the Site ID, and is used, for example, for data integrity checking. 
         [0044]    The Group ID defines a group of client terminals and is assigned by the server. This has a specific value (e.g., empty) for the discovery beacons. It is used to force an update for a specific group of client terminals. The Group ID size defines the size of the Group ID of the server  20  and is used, for example, for data integrity checking. 
         [0045]    The URL specifies the URL to be connected during discovery. This has a specific value (e.g., zero) for non-discovery beacons (e.g., update beacon). No data is sent for non-discovery beacon messages. The client terminal may re-use the same URL for updates. The URL size specifies the size of the URL, and is used, for example, for data integrity checking. 
         [0046]    When discovering a new client terminal, the Site ID is likely to remain constant while the URL may change as a new discovery beacon having the new URL may be provided to the client terminal from the same server. 
         [0047]    The Site ID provides a mechanism for identifying the server to which the client terminal responds in a way other than the URL. The Site ID also can be used to allow multiple servers to exist on a single network. 
         [0048]    IP address may be configured on a beacon to which the beacon will be sent. The IP address may be one of a global broadcast, subnet broadcast, multicast, or specific IP address. 
         [0049]    Referring to  FIG. 4 , one example of a client discovery process using the discovery beacon is described in detail. In  FIG. 4 , “ 40 A” corresponds to the client terminal  40  of  FIG. 2 . One of ordinary skill in the art would appreciate that the client terminal  40 A includes functionalities/elements not illustrated in  FIG. 4 . The server  20  initiates a discovery beacon and sends it out to discover new client terminals (or group). 
         [0050]    The client terminal  40 A includes a beacon listener  100 . The beacon listener  100  is in the beacon client  42  of  FIG. 2 . A beacon sent out by the server  20  is detected by the beacon listener  100 . 
         [0051]    It is assumed that the client terminal  40 A does not have a configured Group ID(s) at step  102 . The client terminal  40 A checks whether this beacon is to discover a new client terminal. In one example, if the Group ID size in the beacon is, for example, zero, it is determined that the detected beacon is a discovery beacon. 
         [0052]    If the client terminal  40 A having no configured Group ID determines that the detected beacon is not a discovery beacon, it ignores the detected beacon ( 104 ). In addition, if the client terminal  40 A has already responded to the same beacon, it ignores the detected beacon ( 104 ). This is done by comparing the message ID for the detected beacon to the message ID of the last discovery beacon. 
         [0053]    If the client terminal  40 A having no configured Group ID determines that the detected beacon is a discovery beacon, it invokes a primary connection client ( 110 ) with the URL from the beacon provided as a command line argument ( 106 ). The primary connection client  110  corresponds to the primary connection client  44  of  FIG. 2 . The URL is provided as an argument to the primary connection client so that it may connect to the server  20 . 
         [0054]    Full path is stored in the registry in the client terminal  40 A (e.g.,  46  of  FIG. 2 ). The client terminal  40 A stores information extracted from the discovery beacon for next connection for updates ( FIG. 5 ). 
         [0055]    The client terminal  40 A establishes an initial connection to the URL provided in the discovery beacon ( 106 ). Once the server  20  receives the connection, the client terminal  40 A is discovered. The server  20  is now aware of the client terminal  40 A ( 108 ). Data can be exchanged between the server  20  and the client terminal  40 A ( 108 ). The client terminal  40 A may make a call to the URL to transfer, to the server, information such as serial number, model, OS, etc. 
         [0056]    After step  106 , the server  20  assigns the client terminal  40 A to a group(s) identified by Group ID(s). This is done, for example, based on terminal type and operational system (OS) version of the client terminal  40 A. The server  20  sends the Group ID(s) to the client terminal at step  108 . The server  20  may assign the permanent server URL used for future connections. The server  20  may assign the update schedule (e.g., update period) for connecting back to the server  20  (e.g.,  48  of  FIG. 2 ,  130  of  FIG. 5 ). The server  20  may send the update schedule and permanent server URL to the client terminal at step  108 . Additional components are then installed or updated to the protocol defined in the primary connection client  110 . 
         [0057]    In  FIG. 4 , the client terminal  40 A connects to the server  20 . However, the URL provided by the server  20  may be directed to another server. 
         [0058]    The client terminal  40 A may detect another new discovery beacon from the server  20 , which has a new URL. Once the client terminal  40 A detects the new discovery beacon, the client terminal  40 A will establish a connection with the new URL and obtain a Group ID(s). 
         [0059]    If the client terminal  40 A has been already discovered in the network at step  102 , the client terminal  40 A has a configured Group ID at step  102 . If the client terminal  40 A has a configured Group ID at step  102  and the detected beacon is a discovery beacon, the discovery beacon may be ignored at step  104 . 
         [0060]    Referring to  FIG. 5 , one example of a client update process using the update beacon is described in detail. In  FIG. 5 , “ 40 B” refers to a client terminal that corresponds to the client terminal  40  of  FIG. 2 . One of ordinary skill in the art would appreciate that the client terminal  40 B includes functionalities and elements not illustrated in  FIG. 5 . The server  20  transmits an update beacon to update discovered client terminals in a group. 
         [0061]    In  FIG. 5 , a connection between the server  20  and the client terminal  40 B is established either by the beacon listener  100  receiving an update beacon or a scheduled update alarm  130  occurring. The scheduled update alarm  130  is occurred and identified by, for example, the event identifier  48  of  FIG. 2 . The update beacon sent out by the server  20  is detected by the beacon listener  100 . 
         [0062]    It is assumed that the client terminal  40 B has been discovered by the server  20  through the discovery process ( FIG. 4 ) and the client terminal  40 B has a configured Group ID(s) at step  112 . The client terminal  40 B checks whether this beacon is an update beacon for this client terminal from the server  20 . In one example, this is determined by checking Site ID and Group ID in the detected beacon whether the Site ID and Group ID in the beacon are the same as those assigned to the client terminal  40 B. 
         [0063]    If the detected beacon is not an update beacon for this client terminal, it ignores the detected beacon ( 114 ). If the client terminal  50 B has already responded to the same beacon, it ignores the detected beacon ( 114 ). 
         [0064]    If the client terminal  40 B determines that the detected beacon is an update beacon for this client terminal, it invokes the primarily connection client ( 110 ) with the previously configured URL ( 116 ). The primary connection client ( 110 ) is launched without a server URL. The client terminal  40 B re-uses a previously used server URL. Also the primary connection client ( 110 ) is invoked based on the scheduled update alarm  130 . The server  20  and the primary connection client ( 110 ) exchange data and any required updates will be applied. 
         [0065]    If the client terminal  40 B has not been discovered in the network at step  112 , the client terminal  40 B does not have a configured Group ID(s) at step  112 . If the client terminal  40 B does not have a configured Group ID at step  112  and the detected beacon is an update beacon, the update beacon may be ignored at step  114 . 
         [0066]    In the above example, the discovery process of  FIG. 4  and the update process of  FIG. 5  are illustrated separately. However, it would be appreciated by one of ordinary skill in the art that the discovery process of  FIG. 4  and the update process of  FIG. 5  may be integrated or executed parallelly. 
         [0067]      FIG. 6  illustrates one example of the network system  10  of  FIG. 2 . The network system  10 A of  FIG. 6  includes a server  120  and a client terminal  150 . The server  120  of  FIG. 6  corresponds to the server  20  of  FIG. 2 . The client terminal  150  of  FIG. 2  corresponds to each of the client terminal  40  of  FIG. 2 . 
         [0068]    A visual User Interface (GUI)  130  in the server  120  corresponds to GUI  22  of  FIG. 2 , and supports various functionalities, for example, client terminal and group maintenance, component maintenance, beacon configuration including start/stopping a beacon thread  132 . A database  140  in the server  120  corresponds to the database  24  of  FIG. 2  and is used to manage the network, including, for example, but not limited to, client terminals, groups components or data transmitted to the client terminal  150 . A Web service module  142  in the server  120  corresponds to the Web service module  26  of  FIG. 2 , and provide various services to the client terminals. 
         [0069]    A beacon client  160  in the client terminal  150  corresponds to the beacon client  42  of  FIG. 2 . The beacon client  160  detects the invitation beacons from the server  120  and launches a downloader  170  for connections with the server. The beacon client  160  includes a beacon listener that is always active and is responsible for launching the downloader  170  when a beacon indicates that that client terminal  150  should connect to the server  120 . 
         [0070]    The downloader  170  is responsible for connecting to the server  120  (e.g., replying to the discovery beacon and the update beacon), exchanging data with the server  120 , and downloading components from the server  120  according to the instructions of the server  120 . The downloader  170  uses the URL specified in the discovery beacon to establish an initial connection with the server  120 . The downloader  170  synchronizes with the server  120  via Web services  142 . The components and data from the server  120  may be transferred to a repository  172 . 
         [0071]    The event identifier  162  of the client terminal  150  detects some events, which include, for example, but not limited to, a scheduled event (alarm), a docking event, power on etc. The event identifier  162  launches the downloader  170  when detecting the events. The scheduled event may be set by the client terminal  150  or the server  120 . For example, an updating period is assigned by the server  120  so that the client terminal  150  connects back to the server  120  at a certain timing. The scheduled event is detected, for example, by a timer in the event identifier  162 . 
         [0072]    When the downloader  170  finishes the downloading, the downloader  170  may launch an installer  180  for installing components downloaded. The installer  180  is responsible for doing the actual component install and reporting progress to the server  120 . This involves copying files, launching setup to execute installation scripts, and performing post install actions. The installer  180  processes downloaded commends and reports success/failure via the Web services  142  on a component by component basis. When completed, it transfers the details install log file for the terminal  150  back to the server  120  through the Web services  142 . The installer  180  updates a registry component  182  that contains configuration information. 
         [0073]    One of ordinary skill in the art would appreciate that the server  120  includes functionalities and elements not illustrated in  FIG. 6 . One of ordinary skill in the art would appreciate that the client terminal  150  includes functionalities and elements not illustrated in  FIG. 6 .