WO2006004378A1

WO2006004378A1 - Event interfacing method and apparatus between applications and a library of a master on home network

Info

Publication number: WO2006004378A1
Application number: PCT/KR2005/002164
Authority: WO
Inventors: Tong Hyon Kim; Jin Sung Park; Jin Young Kim; Jin Ho Son; Hu Soon Choi
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2004-07-07
Filing date: 2005-07-06
Publication date: 2006-01-12
Anticipated expiration: 2007-01-07

Abstract

The present invention relates to method and apparatus for interfacing between various applications operated on a home network and a library to ensure their compatibility. In an event processing method of the present invention, an application calls a function routine of a library that will conduct registration of an event processing function for a connected device on a home network while delivering identifying information of the connected device and the event processing function to the library through input arguments of the function routine, and the library registers the device identifying information and the event processing function. Afterwards, if an event occurs from the connected device, the library calls the registered function to the application with input arguments carrying information about the event, and the called function conducts operations predefined for the event.

Description

D E S C R I P T I O N

EVENT INTERFACING METHOD AND APPARATUS BETWEEN APPLICATIONS AND A LIBRARY OF A MASTER ON HOME

NETWORK

1. Technical Field

The present invention relates to a method and apparatus for interfacing between programs such as control applications executing on a home network server and a library for accessing remote devices . 2. Background Art

As the number of electronic appliances used in a home increases, the need for an effective method for controlling the electronic appliances in a centralized manner is also increasing. As a result, home networks based on LAN or power line communications are proposed.

The electronic appliances existing on a home network may be manufactured by different manufacturers. If manufacturers are different, libraries that come with electronic products for supporting access to home networks can also be different. Different libraries require different interfacing with application programs such as control programs .

If interfacing methods are different, compatibility of application programs is not guaranteed because applications can only execute on devices having the specific library on which the applications are based. As a consequence, the library developer is one factor that should be considered when application programs are purchased.

3. Disclosure of the Invention

It is an object of the present invention to provide a standard interfacing method that guarantees compatibility between various applications and libraries for home networks .

The present invention provides a method for obtaining the list of home network devices .

The present invention provides a method for obtaining detailed information about a home network device.

The present invention provides a method and apparatus for modifying the list of home network devices (e.g., deletion or addition of a device) .

The present invention provides a driving procedure between an application and library of a home network master (server) .

The present invention provides a method for notifying changes in a home network device.

The present invention provides a method for monitoring the status of home network devices individually.

The present invention provides a method for controlling home network devices individually.

The present invention provides a method for command synchronization between an application and library of a home network server.

The present invention provides a method for setting the home code, which is a unique identifier of a network, when a home network is set up.

The present invention provides a method for setting or modifying the address of a home network device.

The present invention provides a method for setting operation options of a home network device (e.g., alive status reporting period, time, event reporting activation, etc) .

4. Brief Description of the Drawings In the drawings:

FIG. 1 illustrates a brief diagram of a home network in which the present invention may be advantageously embodied;

FIG. 2 illustrates a flow diagram showing the steps executed during startup of the devices shown in FIG. 1; FIG. 3a illustrates a flow diagram showing the procedure for the library in FIG. 1 to handle events individually; FIG. 3b illustrates a flow diagram showing the procedure for the library in FIG. 1 to handle events in an integrated manner;

FIG. 4 illustrates the structure for commands exchanged between the application and library for monitoring/modifying/controlling home network devices individually;

FIGS. 5a through 5c illustrates flow diagrams for the library to set a home code in each of the home network devices; and

FIG. 6 illustrates a flow diagram for assigning address to a device on the home network.

5. Best Mode for Carrying Out the Invention

In order that the invention may be fully understood, preferred embodiments thereof will now be described with reference to the accompanying drawings.

FIG. 1 is a brief diagram showing a home network comprising a server and controlled devices in accordance with the present invention. The server in accordance with the present invention comprises a user application 100 (e.g., a home network management program) , a library 110 including functions and execution routines required for accessing a home network, and a physical interface 120 for accessing a physical network 200 (e.g., power lines or LAN cables) . The library is also called LnCP (living network control protocol) library. The home network shown in FIG. 1 includes remote devices 301, and 302 controlled by the server. The state of the devices is monitored, modified, and/or controlled by the execution routines of the library 110. Commands for such operations are called by the user application 100 (referred to as control application hereinafter) via the API defined by the library 110, which will be described in detail.

First, the method in which the server finds active devices on the home network is described.

To obtain the list of devices connected to the home network, the control application 100 calls the following function of the library 110 get_active_device_list (&active_device_list) . The library 110 then passes the information on the active devices on the home network via the input argument (i.e., active_device_list) . The information includes the total number of active devices and the list of devices. Information on each device is defined as follows: typedef struct device { device_descriptor_t dd; device_type_t device_type; device_mode_t device__mode; } device_t.

The information on each device includes a protocol index, device descriptor information, and device type and mode. The type specifies the type of the device (e.g., refrigerator or washing machine) . The mode indicates whether the device is a master- or a slave.

When passing the information on active devices to the control application 100, the library 110 allocates its internal memory for each active device.

If the active devices are not used any more, the control application 100 removes the list of active devices to release the memory allocated for the active devices by calling the following function release_active_device_list (&active_device_list) . The following description elaborates the way in which the server obtains more detailed information on an active device ^• existing on the home network. The control application 100 can obtain more detailed information on a device by calling the following function get_device_info_by_dd(device_descriptor_t dd, device_info_t *ret_entry) , wherein ' dd' is a device descriptor that uniquely identifies the device on the home network. Detailed information on the device specified by ' dd' is returned by the library 110 via the input argument ret_enty, which is a pointer to a data structure defined as typedef struct device_info{ device_descriptor_t dd; unsigned short address; device_type_t device_type; char model [MAX_MODEL_NAME_LEN] ; unsigned char location;

} device_info_t; wherein ' address' is a value obtained by a combination of the type and serial number of the device, ' model' is a text describing the model name, and ' location' is information indicative of the physical location of the device (e.g., living room or bed room) .

After obtaining information on a specific device in the aforementioned way, the control application 100 calls appropriate functions of the library 110 to execute user- required commands. If it is determined that the attained information is not necessary, the control application 100 calls a function of the library 110 to release the memory that the library 110 allocated for the device, thereby allowing the memory to be used for other purposes.

The way in which the control application 100 deals with the case where a device is removed from the home network will now be described. The control application 100 registers the event that occurs when a device is removed (i.e., device removal event) and the callback function to be executed when the event occurs in the library 110 by calling the following function: add_sys_event__func_entry(EVT_SYSTEM_PLUG_OUT, plugout_event_handler) .

If an event of EVT_STSTEM_PLUG_OUT (value assigned to plug-out event) occurs on the home network, the library 110 executes the registered callback function

(plugout_event__handler) . In this case, the library 110 passes the device descriptor or protocol index value to the callback function via the input argument dd, i.e., the library 110 calls the following function plugout_event_handler (sys_event_value_t dd) , which removes the specified device from the list of active devices .

If the control application 100 does not want to receive the device removal event after the removal event is registered in the library 110, the control application 100 removes the registered event and callback function by calling the following function del_sys_event_func_entry(EVT_SYSTEM_PLUG__OUT, plugout_event_handler) , wherein the event and the callback function to be removed are given as the input arguments to the function.

When a device that was registered on the network but has not been connected to the network is connected to the network again, the device can be added in much the same way as the device removal event and its associated callback function are registered. In this case, however, the event is not EVT_SYSTEM_PLϋG_OUT but EVT_SYSTEM_ACTIVE_DEVICE_ADD and the associated callback function notifies the user that the device is added or executes required tasks to add the device.

For a normal operation of the control application and library in the server shown in FIG. 1, function calls and information exchange between the control application 100 and the library 110 should be conducted according to a predefined procedure.

FIG. 2 is a flow diagram showing the required procedure. When executed, the control application 100 first loads the user interface (S21) and makes a request for initialization of the library 110 (S22) . Information (e.g., communication port, port baudrate, etc.) on the devices to be controlled is passed to the library 110 when the request is made. The control application 100 then finds active devices and makes a request for initialization of the devices as mentioned earlier (S23) . Subsequently, the control application 100 registers events (e.g., plug-in event or plug-out event) and event handlers

(callback functions) to handle the events (S24) . When a system event occurs after all the necessary steps are completed, the LnCP library 110 calls the callback function associated with the registered system event to deal with the event (S25) .

If necessary, the control application 100 may remove a registered event and its callback function by calling function to remove.

The method for notifying changes in device status will now be described. Devices supporting access to a home network are equipped with the function of generating status events when the status of the device changes (e.g., changes in power status, operation status, operating temperature, operating mode, selected course, etc) . Status events are divided into 5 categories according to the cause of the occurrence of the events, which are user events that occurs when the user makes a request to a device via keys, etc, periodic events that occurs periodically (e.g., receipt of periodic alive notification message) , status-changed events that occur when the status of a device (e.g., temperature, humidity, or washing course) changes, error events that occur in the case of errors in a device, and external events that occur at the request of external devices such as web servers (e.g., communication requests from remote devices when a network manager works as the home server) .

Events allow efficient and convenient management of devices in that users are notified of changes in the home network status automatically without the need for requesting the status of the home network.. Events are especially useful in the case of a malfunction or operation error of a device in which case the error can be notified instantaneously via events . When a device generates an event, the device passes an event code for indicating the type of the event and an event value, which is the value of the status at which the event is generated.

To handle generated events, the control application 100 first registers the event callback function to deal with the event. There are two types in dealing with events. One type is that one callback function deals with only one event and the other type is that one callback function handles every event.

In the case where one callback function handles only one event, the control application 100 registers the callback function defined as typedef void(*user_event_func_t) (event_valuel_t event_value) along with device descriptor ' dd' and event code ' ec' in the library 110 by calling the function int add_event_handler (device_descriptor_t dd, event_code_t ec, user_event_func_t uefunc) , where ' ec' is the event type that the library 110 will report and ' ue'func' is the pointer to the callback function.-

The library 110 registers the input arguments as linked each other to the function in a hash table. If a packet is parsed by an event processing module, the library 110 examines if there is an error in the parsed packet. If there is no error, the library 110 determines if the packet is an event packet.

If it is determined that the packet is an event packet, the library 110 searches its hash table for the device descriptor and event code associated with the event based on the information on the device that generated the event and the event code and calls the associated callback function using the registered function pointer uefunc (301 in FIG. 3a) . When calling the callback function via ' uefunc' , the library 110 passes ' event_value' as the input argument to the function. ^Λevent__value' is the value of the status at which the event is generated. The control application 100 notifies the user of the occurrence of the event or performs predefined operations depending on the value.

In the case where one event handler handles every event, the control application 100 registers the callback function defined as typedef void (*user_all_event_func_t) (unsigned short device_addr, unsigned char size, unsigned char *event_data) in the library 110 by calling the function int add all event handler (user all event func t func) . The hash table in which the callback function that handles every event is registered may be different from the hash table in which callback functions that handles only one event are registered. Once the callback function is registered in the library 110, the library 110 always executes the callback function via function pointer ' func' whenever an event is generated by a device on the network (302 in FIG. 3b) . When calling the callback function, the library 110 provides ' device_addr' and ' event_data' as the input arguments to the callback function so that the device that generated the event and the event type can be identified. The ' device_addr' is information (e.g., type and serial number) for uniquely identifying the device on the home network. The ' event_data' is a pointer value that ^' points to location of the event code and value.

The called routine in the control application 100 identifies the device that generated the event based on the information passed as input arguments and handles the event ^' accordingly. The way in which the control application 100 controls devices individually by calling routines of the library 110 will now be described.

The control application 100 needs the following information in order to call device control functions of the library 110.

The control application 100 should know the ID of the ^■ device to control (device descriptor) and the code of the command to execute. The command code may be provided internally by the library 110. Also, the control application 100 should provide information required for device control via input arguments (e.g., POWERJDN or POWERjDFF in the case of power control of a washing machine)

When calling device control routines, it is necessary to set the command mode for specifying whether to receive acknowledgment after executing the routine (synchronous mode and asynchronous mode) and command options for specifying the maximum waiting time until the acknowledgement is received in the synchronous mode.

If a device control function is called with necessary information stored in the arguments, the library 110 calls its internal function control_device () with storing the arguments, including the command options, in a structure of command_t type defined in FIG. 4.

The structure command__t defined in FIG. 4 includes variables of ' cc' , ' args' of command_args_t (401) type, rets' (string) of command_eret_t type (402), and ' option' of command_option_t type. The variables ' cc' which represents the command code, ' args' which is the string of input arguments, and ' option' are determined depending on the user input. The var_arg field in the command__args_t structure (401) and var_ret field in the command_ret__t structure (402) are pointers to the command and response, respectively.

After registering a function for handling the response with the address of the device to control and command code as the key, the internal function control_device () generates a protocol packet to control the device and passes the protocol packet to the device 301 or 302 via the physical interface 200

If a response is received from the device after the ^: transmission of the packet, the function control_device () calls the function registered to handle the response. If necessary information is contained in the response from the device, the function control_device () stores the information in a structure of command_t type and returns the structure. The device control function interprets the information contained in the command_t structure and returns the information and control result to the control application 100 via output parameters of the function, which completes the individual device control operation requested by the control application 100.

The way in which the control application 100 monitors the status of individual devices by calling routines of the library 110 will now be described.

The method for status monitoring of individual devices is the same as the above method for control of individual devices except for the following parts.

Since device monitoring functions require a response from the device as the result of the execution, the functions always operate in ' synchronous' mode and thus need to specify a timeout. The command mode and timeout are given as a command option defined as follows: typedef struct command_option { unsigned char async; unsigned long wait_time; // unit: sec } command_option_t;

The variable ' async' has a value of either SYNC_COMMAND or ASYNC_COMMAND (0 or 1) . SYNC_COMMAND means that the control application 100 will wait for the response to the command that it issued. ASYNC_COMMAND means that the control application 100 will not wait for the response to the command.

If the variable ' async' is set to SYNC_COMMAND, the control application 100 will wait for the response during the time interval stored in the variable ' wait__time' . If a response is received before the timeout occurs, the command is completed normally. Otherwise, the control application 100 executes commands to deal with TIME_OUT event. If the variable async' is set to ASYNC_COMMAND, the variable ' wait_time' is simply ignored.

To allow the control application 100 and the library 110 to share the command options, a command_option_t type pointer variable may be declared as a global variable as follows: static command_option_t *func_option.

Because the control application 100 can call more than one function of the library 110 simultaneously, it is also possible to add a variable for storing the command code to the command_option structure as follows: typedef struct command_option { unsigned char ccc; // command code unsigned char async; unsigned long wait_time; // unit: seconds

} command_option_t;

Though a variable of the command_option_t type defined above is declared as global, the control application 100 and library 110 can execute appropriately according to synchronous or asynchronous mode because the code of the command to be executed is contained in the structure. The method to initialize the home network and to modify settings will now be described in detail. The initialization method will be described first.

To construct a home network, a home code is used. The home code is a unique code that identifies the home network ^' from other networks and a home network device can only communicate with other devices having the same home code. The control application 100 can set the home code by calling the following function int set_home_code () ; of the library 110.

If the function set_home_code () is called, the library 110 executes the steps shown in FIG. 5a. The library 110 broadcasts a message that accompanies a response from devices (e.g., a message requesting the device name) through the physical network 200 (S51) . The message uses the home code set in the physical interface 120. If there is a response to the ^• message (S52) and the message is aimed to add a device to the network, the library 110 broadcasts another message for setting the home code (S56) . If the message is not aimed to add a device in S52, the library 110 issues a command for generating a home code to the physical interface 120 (e.g., powerline modem) (S53) and then broadcasts another message that accompanies a response (e.g., a name requesting message) through the network again (S54) . If there is a response to the message (S55) , it indicates that the home code has been already used and therefore the library 110 performs the steps to generate a home code again (S53 and S54) . If there is no response, the library 110 broadcasts a message for setting the created home code through the home network (S56) . As a result, even though a plurality of electronic appliances are connected to the home network through the power line, the electronic appliances can communicate with each other with no disturbance from external home networks due the home code uniquely assigned to the home network.

FIG. 5b is a flow diagram for determining if the home network is set up for the first time or a new device gets connected to the existing home network in the above procedure.

The method for setting the home code differs depending on whether the home network is set up for the first time or a new device gets added to an existing home network. If there is a response to the message for requesting the device name (S503 and S504), it is determined that a new device gets added to an existing home network (S506) . If there is no response until the message is broadcast three times, for example, it is determined that the home network is set up for the first time (S505) . FIG. 5c is a flow diagram showing the steps S53 through S55 shown in FIG. 5a in more detail. In the case where a home network is installed for the first time, the present method according to this invention commands the physical interface 120 (e.g., home network modem) to create a new home code (S511) and broadcasts the created home code so that modems for other home networks can set the home code after making sure that the created home code does not conflict with home codes of other home networks. The decision for determining whether there is a conflict with the created home code can be made by broadcasting a name requesting packet (S513) . The handler for handling the response to the name requesting packet is registered in a table before the packet is broadcast (S512) . If a response is received, the response is handled by the handler (S515) . If there is no response (S514), it is determined that there is no conflicting home code on the network. As described above, if there is no response until the message is broadcast three times, a message for setting the home code is broadcast (S56) . If a response is received, it implies that the home code has already been used. The library 110, therefore, broadcasts a clear command to the modem to clear the created home code (S515) and commands the modem to generate a home code again (S511)

The function for clearing the home code is as follows: int clear_home_code () .

This function clears the home code set in the home network modem by transmitting a command packet for clearing the home code to the home network modem connected to the master.

The above procedure for creating/clearing a home code is repeated until a unique home code is obtained. In the case where a new device is added to an existing home network, the home code of the home network is broadcast so that the home code can be set in the home network modem of the new device (S56) .

When setting the home code, it is also possible to set a user-defined home code instead of the home code that the library 110 generates. Registering a user-defined home code can be done by calling the following function int push_home_code (unsigned long home_code) of the library 110. If the function is called, the library 110 broadcasts the home_code, which is the input argument to the function, so that the code can be set in the modem of each of the devices 301 and 302.

Each home network device needs a unique address for communication. The library 110 allows the control application 100 to assign addresses to the network devices easily by providing routines required for assigning addresses.

A device which wants to join the home network broadcasts a plug-in notification message in order to obtain a unique address, (Sβl) . The library 110 of the master that receives the plug-in notification message assigns an address to the device after processing the message.

To do this, the library 110 registers a handler for the plug-in notification message in its response function hash table before processing the plug-in notification packet.

If a plug-in notification packet is received, the handler for the plug-in notification packet finds out the type of the device that transmits the packet and searches its database for an unused address based on the device type (S62) . If an unused address is found, the handler passes the address via an argument to the address change command (S63) . The address change command is given as follows: int change_address (old_addr, new_addr) ; The arguments to function change_address ( ) are the current address and a new address that will be used instead of- the current address. If the device is a new device connected to the home network for the first time, ' old_addr' is a default address (e.g., usually 0) . The function change_address () returns a value indicative of whether the address change operation is successful or not.

The device that receives the address change command sets the passed address as its address and transmits a response. If the function change_address () receives the response, the function stores the address in its database (S64) because it means that the address change operation is successful. In addition, the function sends a DB update command to inform other network managers that a new device is registered (S65) .

After changing the device address, the library 110 makes requests for additional information to the device that sets the new address (Sββ and S67) and stores the received information in the database. For example, the library 110 finds whether the device is a master or a slave by sending device search command (Sββ) and obtains the model name thereof using model request command (S67) .

The method in which a master device sets up options of ^■ devices connected to the home network during initialization will now be described.

The library 110 of a master device of the home network should check which devices are connected to the network and which devices are active. To this end, the library 110 requests each of the devices to periodically send a message • indicating that the device is active. The message is called alive" message. When the control application 100 of the master initializes the network, the control application 100 notifies the period of " alive" message of the devices. The library 110 therefore knows which devices are active because . it receives periodical " alive" messages from active devices.

The function of the library 110 which the control application 100 calls to set the period, inputted from a user or operator, of the " alive" message is as follows: int set_alive__message_interval (time) ;

When the function is called, the library 110 passes the. value of the variable ' time' , which is the period of the " alive" message, to each of the devices on the home network so that the devices send the " alive" message periodically with the period afterwards .

It is possible to set current time in devices equipped with the function of keeping track of time. To set time in such devices, the control application 100 calls the following function int set_clock (hour,min,sec) ; of the library 110.

When the function is executed, the library 110 generates a packet containing the values of the variables ' hour' , minute' , and ' second' and transmits the packet to the devices. Also, the library 110 informs the control application 100 of the result via the return value based on responses from the devices . The home network devices notify changes in the status to other devices and master devices through events. The control application 100 can enable or disable the status notification function through the library 110. To enable the status notification function, the control application 100 calls function int event_enable (enable) ; of the library 110.

If the function event_enable () is called, the library 110 sends a command for enabling or disabling the status notification function to a corresponding device based on the input argument. Receiving a response to the command, the library 110 returns a value corresponding to the response to the control application 100.

If the interface between control applications and libraries is standardized, users can enjoy more freedom in purchasing electronic appliances for constructing a home network because compatibility is guaranteed for electronic appliances without regard to manufacturers thereof. The standardization also helps manufacturers reduce the cost for device development and warranty service.

While the invention has been disclosed with respect to a limited number of embodiments, those skilled in the art, having the benefit of this disclosure, will appreciate numerous modifications and variations therefrom. It is intended that all such modifications and variations fall within the spirit and scope of the invention.

Claims

C LAI M S

1. A method for exchanging commands and/or responses between an application and a library of a device managing a home network, comprising the steps of: (a) calling, conducted by the application, a library function for registering a function for handling an event generated by a device connected to the home network, with information for identifying the device and the function for handling the event as arguments to the library function; and ^' (b) registering, conducted by the library, the information for identifying the device and the function for handling the event, and if the event is generated by the device, calling the registered function of the application with information on the event as an argument to the function.

2. The method set forth in claim 1, wherein the information on the event includes information for identifying type of the event and a value of state that caused the event.

3. The method set forth in claim 1, further comprising the step of: (c) performing, conducted by the registered function called at step (b) , a predefined operation based on the information on the event.

4. The method set forth in claim 1, wherein if an event packet is received from a device, the library examines if the packet has no error and calls the registered application function associated with the event if it is determined that the packet has no error.

5. A method for exchanging commands and/or responses between an application and a library of a device managing a home network, comprising the steps of:

(a) calling, conducted by the application, a library function for registering a function for handling all events generated by devices connected to the home network, with the • function for handling all events as an argument to the library function; and (b) registering, conducted by the library, the function for handling all events, and if an event is generated by a device on the home network, calling the registered function of the application with information on the event as an argument to the function.

6. The method set forth in claim 5, wherein the information on the event includes information for identifying type of the event and information for identifying the device that generated the event.

7. The method set forth in claim 6, further comprising the step of:

(c) performing, conducted by the registered function called at step (b) , a predefined operation based on the information for identifying type of the event and information for identifying the device that generated the event

8. The method set forth in claim 5, wherein the library registers the function for handling all events in a table, which is different from another table in which functions for ^■ handling individual events are registered.

9. The method set forth in claim 5, wherein if an event packet is received from a device, the library examines if the packet has no error and calls the registered application function if it is determined that the packet has no error.

10. An apparatus for managing devices connected to a home network, comprising: a library for exchanging information with the devices; and an application for calling a library function for registering a function for handling a status event generated by the devices, with information for identifying a device and a function for handling a specific event as arguments to the library function, wherein the library registers information for identifying the device and the function for handling the specific event passed via the arguments.

11. The apparatus set forth in claim 10, further comprising a packet parsing module for receiving packets carrying events generated by the devices, wherein if a packet parsed by the packet parsing module has no error the library calls the registered application function with information on the event carried by the packet as an argument to the function.

12. The apparatus set forth in claim 11, wherein the information on the event includes information for identifying type of the event and a value of the state that caused the event.

13. The apparatus set forth in claim 11, wherein the called application function performs a predefined operation based on the information on the event.

14. An apparatus for managing devices connected to a home network, comprising: a library for exchanging information with the devices; ' and an application for calling a library function for registering a function for handling all status events generated by the devices, with the function for handling all events as an argument to the library function, wherein the library registers the function for handling- all events passed via the argument.

15. The apparatus set forth in claim 14, further comprising a packet parsing module for receiving packets carrying events generated by the devices, wherein if a packet parsed by the packet parsing module has no error the library calls the registered application function with information on the event carried by the packet as an argument to the function,

16. The apparatus set forth in claim 15, wherein the information on the event includes information for identifying type of the event and information for identifying the device that generated the event.

17. The apparatus set forth in claim 16, wherein the called application function performs a predefined operation based on the information for identifying type of the event and information for identifying the device that generated the event.

18. The apparatus set forth in claim 14, wherein the library registers the function for handling all events in a table, which is different from another table in which functions for handling individual events are registered.