1. Field of the Invention
The present invention relates generally to a home network system and, in particular, to an event-processing method and system for efficiently re-delivering notification events preserved by a Remote User Interface Server (RUIS) to Remote User Interface Clients (RUICs) in a home network supporting a Remote User Interface (RUI).
2. Description of the Related Art
Several industrial standardization organizations such as Digital Living Network Alliance (DLNA), Home Audio-Video Interoperability (HAVi), and Universal Plug and Play (UPnP) are conducting research on technologies for enhanced home networks.
RUI technology is one of the promising technologies for enhancing operability of home network systems. Typically, RUI technology is implemented based on a client-server architecture in which an RUIC downloads a User Interface (UI) from an RUIS in order for a user to control the RUIC via the UI.
FIG. 1 is a signaling diagram illustrating operations of network entities for delivering a 3rd party notification event in a conventional home network.
Referring to FIG. 1, if a notification event to be delivered to a user is detected while a UI session with an RUIC 10 is released, an RUIS 20 multicasts the notification event within the home network in step S101. For example, the notification event can be transmitted in the General Event Notification Architecture (GENA) format. The notification event can be received by any of the clients included in the home network, including the RUIC 20.
After receiving the notification event, the RUIC 10 requests a notification page from the RUIS 20 for and displays the RUI, corresponding to the notification event, received from the RUIS 20 in step S103. For example, the RUIC 10 requests the notification page from the RUIS 20 using “http-get” with a Uniform Resource Locator (URL) contained in the notification event.
In some situations, however, there may not be an RUIC to receive the notification event transmitted by the RUIS 20. In this case, the RUIS 20 does not receive a notification page request at step S103.
In FIG. 1, steps S105 to S113 are illustrated under the assumption that no RUIC exists (e.g., the RUIC 10 is powered off) in steps S101 and S103.
In step S105, if it is determined that there is no RUIC to receive the notification event, i.e., a notification page request is not received in step S103, the RUIS 20 saves the notification page. Thereafter, if the RUIC 10 enters the network again, e.g., powers on, it notifies the RUIS 20 of its network entry in step S107.
Upon detecting the network entry of the RUIC 10, the RUIS 20 multicasts all of the saved notification events in step S109. If the notification events are received, the RUIC 10 requests the notification page from the RUIS 20 in step S111, and the RUIS 20 transmits the requested notification page to the RUIC 10 and discards the saved notification page in step S113.
This conventional notification event delivery method, wherein the RUIS stores the notification event for an absent RUIC, until its network entry, has a number of problems.
First, the RUIS cannot identify an RUIC requesting a notification page among multiple RUICs, when the RUIS is required to retransmit a stored notification event. FIG. 2 is a diagram illustrating such a problematic situation.
Referring to FIG. 2, when multiple RUICs 11, 12, and 13 are included in the network, any of the RUICs 11, 12, and 13 can request a notification page from the RUIS 20. Currently, however, the RUIS 20 cannot identify which of the RUICs 11, 12, and 13 has requested for the notification page, when it needs to transmit the stored notification event (e.g., after receiving a network entry notification in step S201 or after receiving a notification page request in step S205). Accordingly, the RUIS 20 has to transmit the notification event in multicast mode in step S203, in order for all of the RUICs 11, 12, and 13 to receive the notification event.
Second, when an RUIC enters a network, it cannot request the RUIS 20 for a specific notification event among the notification events saved therein. For example, when a user has been absent for a long time, a plurality of notification events might be stored in the RUIS 20. Thereafter, when the user's RUIC enters the network after the long absence, all of the large number of notification events are transmitted in the home network, which makes it difficult for the user to find a specific notification event.
Third, in the conventional methods, the RUIS 20 will delete the stored notification page when the notification page is requested by an RUIC, as illustrated in step S113 of FIG. 1, in order to prevent the same notification event from being retransmitted repeatedly, even after the RUIC has already received the notification event. However, in this scenario, if the stored notification page is deleted by a device receiving the notification event, other RUICs cannot receive this notification page.
Additionally, there can also be a situation where an RUIC would like to recheck a notification event that has been checked already. However, because the notification event was deleted after the first delivery, is a conventional method cannot support the rechecking of the notification event that was already delivered.
USPTO Backgrounds
USPTO Backgrounds