Method and apparatus for synchronizing EPG information between server and client

A method and apparatus for synchronizing EPG information between a server and a client in a digital broadcasting network are provided. The server updates synchronization files according to information which is modified after a last synchronization file is created according to the update of the server-side EPG information, creates a synchronization file according to information which is modified after the last synchronization file is created, and transfers a synchronization file to one of the clients, where the synchronization file is created first after the EPG information pieces of the clients are updated among from the synchronization files stored in the clients. Accordingly, the server and the client can be easily synchronized with each other by transferring or receiving only one file, since all synchronization files can include the latest update history by transferring only one synchronization file.

CROSS-REFERENCE TO RELATED PATENT APPLICATION

This application claims the benefit of Korean Patent Application No. 10-2005-0081999, filed on Sep. 3, 2005, in the Korean Intellectual Property Office, the disclosure of which is incorporated herein in its entirety by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Apparatuses and methods consistent with the present invention relate to data synchronization between a server and a client, and more particularly, to synchronizing EPG information between a server and a client in a digital broadcasting network.

2. Description of the Related Art

With the development of multimedia, the number of broadcasting service providers is increasing. Ever since cable broadcasting service providers have started broadcasting for niche markets where over-the-air broadcasting is not readily received, not only cable television (TV) service providers providing specialized channels of specific genres with better quality, but also satellite cable TV service providers have entered into the market. The service providers use tens to hundreds of channels. Information on the channels has to be provided to create a TV time table and to notify that the channels exist. A service provider allocates a specific channel as an electronic program guide (EPG) channel to provide the channel information. In this case, TV viewers passively observe the channel information scrolling on a TV screen. To avoid this, a method has been needed in which information on TV program is transferred through a network, and the information is stored in a client system so that the information can be immediately obtained at the request of a user.

In the case of digital broadcasting, the information is provided along with program and system information protocol (PSIP) data to be analyzed in the client system. However, the amount of information obtained in this way is small. For this reason, the information has to be provided through a network to provide larger and better information.

However, the cost to use the network and the amount of data to be transferred become excessive when the EPG information relating to many channels is processed. Therefore, an effective method of synchronizing EPG information is required.

To provide an effective personal video recorder (PVR) by using the EPG information, one to two weeks' amount of EPG information is required. Since programs scheduled to be broadcasted are frequently deleted, and new programs are frequently added, relevant information has to be updated in the client system. According to how the information is configured, communication between a server and a client is significantly affected.

FIG. 1illustrates a structure of a related art digital broadcasting system for synchronizing EPG information.

The system ofFIG. 1is disclosed in the Korean Patent No. 10-0385328. When a server administrator adds, deletes, or updates the EPG information, the server cyclically creates a synchronization file whenever the EPG information is modified. In addition, clients, each of which has different synchronization times with each other, separately receive relevant synchronization files to synchronize the EPG information. This will be now described in detail with reference toFIG. 1.

When the server administrator modifies data, an update date tracing unit101writes a modification time into a server database107along with information on which actions (insert/delete/update) have been carried out.

FIG. 2illustrates a modification history table stored in the server database107and a file to be transferred. When a server scheduler103generates an event to create a synchronization file, an update data creating unit105extracts records corresponding to a predetermined time period from the server database107to be stored in a file storing unit109. For example, if an update file is created twice a day at 10:00 and 22:00, each synchronization file is configured according to the EPG information modified between 22:01 to 09:59 and 10:01 to 21:59.

At the client-side, when it is time to update the EPG information, a PVR scheduler115generates an event therefore and requests data from the server via a downloader unit113. At the server-side, the synchronization file is transmitted through a data providing unit111, and a client system requests a retransmission of required synchronization files included in a synchronization file list. After all required synchronization files are received at the client-side, the synchronization files are stored in the file storing unit109. Then, a data update unit119reads the synchronization files and updates a PVR database121according to the content of the synchronization files.

However, in this case, the synchronization files created at the server-side include all content modified during the time period. As a result, unnecessary content is also included in the synchronization files. This causes file size to increase, thereby deteriorating file transfer efficiency.

Whenever the EPG information is modified, its modification history relating to the actions (insert/delete/update) is stored in the server database107. As a result, when data is updated or deleted, the modification history of previous data still remains. This causes a waste of resources of the server database107. Further, data may not be efficiently extracted.

For example, referring toFIG. 2, from 07:10 to 07:13, the server administrator deletes an item three times and inserts the item four times. This is the same as in the case when no modification occurs ever since the item is inserted at 07:10. Every modification history is stored in the server database in the order of a time sequence. Also, a synchronization file to be transmitted to the client system includes all the modification history.

At the client-side, when the client system has not been used for long, or the user just has purchased the client system, every synchronization file created before current data is configured is received and its database is updated according to the modified history recorded in the synchronization file. Consequently, the same process performed at the server-side has to be repeated at the client-side, thereby performing unnecessary operations.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus for effectively synchronizing EPG information between a server and a client, in which a new modification history is applied to all existing synchronization files whenever the EPG information is updated, and data relating to unnecessary EPG information is deleted from a server database after a synchronization file is created.

According to an aspect of the present invention, there is provided a method of providing synchronization files to clients so as to synchronize server-side EPG information with EPG information pieces of the clients, the method comprising: (a) updating synchronization files, that are created respectively according to the updates of the server-side EPG information, according to information which is modified after a last synchronization file is created; (b) creating a synchronization file according to information which is modified after the last synchronization file is created; and (c) transferring a synchronization file to one of the clients, where the synchronization file is created first after the EPG information of the client is updated among from the synchronization files updated in the operation (a) and the synchronization file created in the operation (b).

In addition, the method may further comprise: writing action type information into an action type field of an item modified in an EPG table whenever EPG information is updated; and initializing the action type field after the synchronization file is created in the operation (b), wherein, in the operation (a), the modified information is recognized with reference to the action type field.

The present invention also provides a computer-readable medium having embodied thereon a computer program for executing any one of the method of providing synchronizing files to clients, where the synchronization files are provided by a server to synchronize server-side EPG information with each of client-side EPG information pieces.

According to another aspect of the present invention, there is provided a server apparatus for providing synchronization files to clients so as to synchronize server-side EPG information with EPG information pieces of the clients, the apparatus comprising: a file storing unit which stores synchronization files created respectively according to the updates of the server-side EPG information; a scheduler which generates an event to create a synchronization file according to items that are modified in an EPG table after the last synchronization file among the previous synchronization files are created; an update information synchronizer which updates all previous synchronization files stored in the file storing unit according to the modified items when the event is generated, creates a synchronization file based on the modified items, and stores the synchronization file to the file storing unit; and a file transfer unit which transfers a synchronization file to one of the clients, where the synchronization file is created first after the EPG information of the client is updated among from the synchronization file stored in the file storing unit.

According to another aspect of the present invention, there is provided a method of synchronizing client-side EPG information with server-side EPG information in a digital broadcasting network, the method comprising: receiving a list of synchronization files created according to the update of the server-side EPG information; selecting a synchronization file in the list of the synchronization files, which is created first after a latest update time of the client-side EPG information, and receiving the synchronization file; and updating the EPG information by using the received synchronization file.

In addition, all of the synchronization files in the list may include a modification history of the server-side EPG information from the time of file creation up to the present.

The present invention also provides a computer-readable medium having embodied thereon a computer program for executing any one of the method of synchronizing client-side EPG information with server-side EPG information in a digital broadcasting network.

According to an aspect of the present invention, there is provided a client apparatus for synchronizing client-side EPG information with server-side EPG information in a digital broadcasting network, the apparatus comprising: a file determining unit which determines a file to be received which is included in a synchronization file list, where the file is a synchronization file created first after client-side EPG information is updated to the latest version; a file requesting unit which requests a synchronization file selected in the file determining unit to a sever; and an update unit which updates the client-side EPG information by using a synchronization file received in response to the file request.

In addition, the synchronization files in the list may reflect the recent EPG information of the server-side.

In addition, the synchronization files in the list may be created such that each file name thereof includes information on a file creation date and time.

DETAILED DESCRIPTION OF THE INVENTION

Hereinafter, the present invention will be described in detail by explaining exemplary embodiments of the invention with reference to the attached drawings.

FIG. 3is a flowchart illustrating a process of creating a server-side synchronization file according to an exemplary embodiment of the present invention.

The synchronization file stores modification history of server-side EPG in order to update client-side EPG information. The synchronization file is cyclically created and includes the latest update history. The content of the synchronization file may be written in extensible markup language (XML) format as shown inFIG. 5. According to an update history, programs may be written using <Ins>, <Upd>, and <Del> tags.FIGS. 5A and 5Bwill be described in detail later.

When a server administrator updates EPG information (operation310), a server writes action type information (i.e., insert, delete, update, etc.) to an EPG table (operation320). When a sever scheduler generates an event to generate a synchronization file, information is extracted on items which have been actually modified thereafter.

Next, it is determined whether a previously created synchronization file exists in a file storing unit for storing the synchronization file. If it does not exist, an initial synchronization file is created so that it includes all items contained in a current EPG table, and the initial synchronization file is then stored in the file storing unit (operation350). If it exists, previous synchronization files are updated according to the modified items (operation360). Thereafter, a last synchronization file is created so that it includes only the modified items (operation370). Thereafter, items deleted by the server administrator, that is, items of which action type is DEL, are deleted from a database.

Accordingly, all clients can obtain the latest EPG information by downloading only the next subsequent version of a current synchronization file regardless of the latest EPG update time of the clients, and the server no longer has to store data relating to deleted items.

FIGS. 4A to 4Billustrate EPG tables according to an exemplary embodiment of the present invention.

In the EPG table ofFIG. 4A, item5is inserted in the case when programs corresponding to items1to4already exist. When a user inserts, deletes, or updates data, it is written in the action type field. In the action field, unmodified items stay in an initial state of NULL. After the synchronization file is created, the action file is reinitialized to NULL. Thus, if the action type field is not NULL, it shows that modification has occurred at least once. In the EPG table ofFIG. 4B, the synchronization file is created according to a modification history, and then all of the action type fields are initialized to NULL.

Since the action type field is initialized after the synchronization file is created according to the modification history, when items are updated at a later time, it is possible to determine which items have been updated.

FIGS. 5Aand B illustrate source codes of synchronization files written in the xml format according to an exemplary embodiment of the present invention. InFIG. 5A, items1,4,6,9, and10are inserted. InFIG. 5B, items6,9, and10are inserted, item1is updated, and items2and4are deleted. For convenience, the synchronization files include only an ID of an item in this exemplary embodiment, but all information on the item may be included in the synchronization file in practice.

The synchronization file ofFIG. 5Ais the initial synchronization file which is the oldest synchronization file. The oldest synchronization file is transferred to a client along with other synchronization files. Further, the oldest synchronization file may be used to create reference information which is needed to apply the modification history to other synchronization files.

Later version synchronization files are created according to only the items which have been updated with respect to the initial synchronization file. Thus, when the EPG table is modified and synchronization files are then updated, the initial synchronization file is first updated according to the current EPG information. Then, the later version synchronization files are updated according to only the modification history applied to the initial synchronization file, so that all synchronization files can include the current EPG information. In the case of a newly purchased client system, or in the case when no synchronization files are stored in a client database, the latest EPG information can be obtained by just downloading the initial synchronization file. Referring toFIG. 5A, the initial synchronization file has only <Ins> tags.

FIG. 6illustrates a structure of a digital broadcasting system according to an exemplary embodiment of the present invention.

Referring toFIG. 6, a server607includes a server scheduler601, an update information synchronizer602, an update history setting unit603, a server database606, a file transfer unit605, a synchronization file manager604and a file storing unit620. A client614includes a client scheduler609, a file requesting unit610, a file determining unit611, an update unit613, and a client database612.

The server scheduler601generates an event to notify the need to create a synchronization file for items in the EPG table, the items which have been modified since the latest synchronization file was created.

In response to the event, the update information synchronizer602extracts items which have been modified during a predetermined time period from the EPG table, updates all previous synchronization files stored in a file storing unit620, creates the latest synchronization file updated according to only the modified items, and stores the latest synchronization file into the file storing unit620.

When the server administrator updates server-side EPG information, the update history setting unit603writes action type information of each item into the EPG table to be stored in the server database606. Further, the update history setting unit603initializes action type fields of the EPG table to NULL when the update information synchronizer602creates the latest synchronization file. Action type fields show which items have been updated after a new time period starts, and the update information synchronizer602recognizes modified items according to the action type field values.

In response to the request of the client614, the file transfer unit605transfers a synchronization file list or a synchronization file, and the server database606stores the EPG information.

The synchronization file manager604deletes old synchronization files from the server database606. However, since the initial synchronization file has to exist all the time, the content of the initial synchronization file has to be copied to a second oldest file stored in the file storing unit620prior to the deletion the initial synchronization file. This will be described in detail later.

When it is time for the client614to update the EPG information, the client scheduler609generates an event. Then, the file requesting unit610requests the synchronization file list from the server607by sending a request to the server607. The file determining unit611determines the synchronization file to be received which is included in the synchronization file list, where the synchronization file is a synchronization file created first after the client-side EPG information has been updated to the latest version. Then, the file requesting unit610requests the server607to transfer the synchronization file determined by the file determining unit611.

The update unit613updates the client-side EPG information according to the received synchronization file. The client database612stores the updated EPG information. The client scheduler609generates an event to download the synchronization file for synchronizing the EPG information.

As described above, the client614can synchronize its EPG information with the EPG information of the server607by downloading a next subsequent version of a current synchronization file. Thus, when requesting the synchronization file that is the next subsequent version, the client614has to know not only the version of the synchronization file currently stored in the client614but also the version of the synchronization file stored in the server607. Also, the server607has to know the version of the synchronization file stored in the server607. For this reason, when the server607generates the synchronization file, the data and time of file creation may be included in a file name.

FIG. 7illustrates a structure of an update information synchronizer according to an exemplary embodiment of the present invention.

Referring toFIG. 7, an update information synchronizer710includes a first synchronizer711, an extractor712, and a second synchronizer713. The extractor712extracts modified items from a server database706according to the action type field value as described above. The first synchronizer711updates an initial synchronization file by using the extracted items. Not all of the items extracted by the extractor712are used in updating the initial synchronization file, in practice. This will be described in detail later with reference toFIGS. 8 and 12. The second synchronizer713updates the rest of the synchronized files according to items which are used in updating the initial synchronization file, in practice.

FIG. 8is a flowchart of a process of the first synchronizer711according to an exemplary embodiment of the present invention.

When items modified by the extractor712are extracted, the first synchronizer711refers to the action type fields of each item (operation801) and determines whether a field value thereof is UPD (operation802). If it is UPD, whether an ID exists within the <Ins> or <Upd> tags in the initial synchronization file (operation805) is checked. If it exists, the content of the file is updated (operation807). If it does not exist, the action type fields of the extracted items are modified to INS (operation808) to be inserted within the <Ins> tag in the initial synchronization file (operation811). For example, if one item is inserted when the synchronization file is created and then the synchronization file is updated, the action type field of the item extracted by the extractor712indicates UPD. However, the initial synchronization file created according to only its previous version synchronization file does not even recognize that the item has been inserted. Thus, the initial synchronization file recognizes this as INS instead of UPD.

If the action type field indicates INS (operation804), the content of the ID is inserted within the <Ins> tag of the initial synchronization file (operation811). In order to create reference information to be used to update the rest of the synchronization files, the extracted items are modified at the same time the initial synchronization file is updated. Hereinafter, the reference information will be referred to as update reference information.

If the initial synchronization file does not exist when the aforementioned operations are performed, the content of the initial synchronization file may be referred to. Alternatively, every operation for modifying the initial synchronization file may be treated as an error or be cancelled.

FIG. 9is a flowchart of a process of the second synchronizer713according to an exemplary embodiment of the present invention.

As described above, the second synchronizer713updates the rest of the synchronization files instead of the initial synchronization file.

When the first synchronizer711creates the update reference information, the action type field of the update reference information is referred to (operation901). Thereafter, if the action type field value is UPD (operation902), whether an ID exists within the <Ins> or <Upd> tags in a file to be transferred (operation905) is checked. If the ID exists, the content of the ID is updated (operation907). If the ID does not exist, the ID is inserted within the <Upd> tag of the synchronization file (operation908).

FIGS. 10Ato B are flowcharts of a process of creating the synchronization file in the server according to an exemplary embodiment of the present invention.

When the EPG information is updated in the server (operation1001), the current action type is written on the action type field of the EPG table to be stored in the database.

When it is time to create the synchronization file and thus the server scheduler generates an event therefore (operation1003), the update information synchronizer updates the synchronization files according to the modification history of the EPG table. For this, the action type field of the EPG table is first referred to from the database to extract items which are not NULL (operation1004). Next, it is determined whether the synchronization file exists (operation1005). If it exists, the update reference information is created at the same time the initial synchronization file is updated as described above (operation1007). If it does not exist, the initial synchronization file is created so that all items of the current EPG table are inserted into the initial synchronization file (operation1013). Thereafter, the rest of the synchronization files are all updated (operations1008to1012). If the last modification history is applied to all of the synchronization files, and the synchronization file configured according to only the last modification history is created (operation1013), the items of which the action field value in the EPG table is DEL are completely deleted from the database, and all of the action type field values of the EPG table are initialized to NULL.

FIG. 11illustrates a process of creating a synchronization file according to an exemplary embodiment of the present invention.

The server administrator inputs data to update EPG information (operation S10). Then, according to the input data, the update history setting unit writes action type information of each item to action type fields of an EPG table.FIG. 11shows an EPG table1130with fields for ID, Action, Channel Number (“ChNum”), Start Time (“S TIME”), End Time (“E TIME”) and TITLE. There are no inserted items in the first EPG table1130. At a later time, four items are inserted in an EPG table1140to reflect the four items in the EPG1145. In this case, four items are modified, and the action type thereof is INS.

When the scheduler generates an event to create the synchronization file (operation S40), the update information synchronizer extracts the modified items according to the action type field of the EPG table (operation S50). In order to create the update reference information, the update information synchronizer loads the initial synchronization file to a memory (operation S60). Since the initial synchronization file does not exist in this time, an initial synchronization file1100is created in which four items are inserted (operation S70). Up to now, update reference information1110is the same to the items extracted in operation S50. When the synchronization file is created, the update information synchronizer initializes all of the action type fields of an EPG table1150to NULL (operations S90).

FIG. 12illustrates a process of creating a synchronization file according to another exemplary embodiment of the present invention.

The process of creating the synchronization file will be now described. An EPG table1240contains five items to reflect the five items on the EPG1245. In addition, an initial synchronization file1220and a synchronization file1260exist. In this case, items of ID2and ID3are all replaced by ID6, ID5is replaced by ID7, ID1is updated, and ID8is inserted and then deleted. In other words, the programming referred to as ID2, which was listed to run between 10:00 and 11:00, and ID3, which was listed to run between 11:00 and 12:00, are replaced by ID6, which is listed to run between 10:00 and 12:00, as shown in the EPG1245. Furthermore, the programming referred to as ID5, which is listed to run between 13:00 and 14:00, is replaced by ID7which runs between 13:00 and 15:00, as shown in the EPG1245.

First, the server administrator modifies EPG information in the same way as described above. As a result, each item of an EPG table1250is modified. Update reference information1210is extracted to be applied to the initial synchronization file1220, thereby creating an updated initial synchronization file1230. Newly inserted ID6and ID7are inserted within the <Ins> tag of the initial synchronization file1220. Since ID1already exists within the <Ins> tag, the updated content is overwritten. When deleting, ID2,3, and5are deleted since they exist within the <Ins> tag, but ID8is not deleted since it does not exist within any tags. Therefore, the content of ID8is deleted from the extracted items to generate update reference information1203.

The previous synchronization files are updated according to the created update reference information1203. Referring toFIG. 12, a synchronization file1270is updated by using the previous synchronization file1260. That is, ID5is deleted from the <Ins> tag, and the rest of items are inserted within relevant tags. After the first synchronization file and the previous synchronization file are updated, a last synchronization file1290is created which contains only the update reference information. As described above, each synchronization file may include a file creation date and time so as to know the order of file creation.

When file creation and update are completed with respect to the synchronization files, data corresponding to items of which the action type field values are DEL is deleted from the EPG table1250, and the action type fields are initialized to NULL (operation1280).

FIG. 13is a flowchart of a process of the synchronization file manager604according to an exemplary embodiment of the present invention.

As time elapses, old synchronization files need to be deleted starting from the oldest synchronization file, since the content of the old files become the same with each other over time. For example, if a valid time period of EPG information is set to one week, synchronization files which have been created more than one week ago are deleted. In this case, as describe above, the initial synchronization file has to exist all the time due to the characteristics of the synchronization system of the present invention. Thus, a later version synchronization file needs to be configured to be the new initial synchronization file prior the deletion of the initial synchronization file. The later version synchronization file is the second oldest file, following the first synchronized file. Hereinafter, the later version synchronization file will be referred to as a preliminary synchronization file.

When the scheduler generates an event to delete the initial synchronization file after a predetermined time elapses (operation1310), the initial synchronization file and the preliminary synchronization file are loaded in a memory (operation1320). Next, the content written within the <Upd> and <Del> tags in the preliminary synchronization file is all deleted (operation1330). Thereafter, the content of the <Ins> tag of the initial synchronization file and the preliminary synchronization file are compared with each other, and IDs which exist only in the initial synchronization file are inserted within the <Ins> tag of the preliminary synchronization file (operation1340). Thereby, the preliminary synchronization file has content indicating that all of the items included in the current EPG information have to be inserted. Thereafter, the initial synchronization file is deleted, and the file name of the modified preliminary synchronization file is determined to be the same as the initial synchronization file (operation1350).

FIG. 14illustrates a structure of a client1414according to an exemplary embodiment of the present invention.

Referring toFIG. 14, the client1414includes a client scheduler1409, a file requesting unit1410, a file determining unit1411, a database (DB)1412, and an update unit1413.

The client scheduler1409generates an event to update the EPG information after a predetermined time elapses. The file determining unit1411determines a synchronization file to be received which is included in the list of synchronization files received from the server607through the file requesting unit1410. For this, a system update time has to be stored in the client1414whenever the EPS information is updated in the DB1412. When the synchronization file to be received is determined at a later time, the system update time is referred to so that the synchronization file to be received can be determined to be a file created right after the system update time among from the server-side synchronization files. This is because the file contains all content updated from when the client1414updates the EPG information up to the present. As described above, when the server-side synchronization file is created, the synchronization file name includes the file creation date and time. The synchronization file name may be “Update.20050531.10.epg”, which indicates that the synchronization file was created at 2005, May, 31, 10:00 am. The file determining unit1411can select a required synchronization file according to the file name.

The file requesting unit1410requests the server607to transfer the synchronization file selected by the file determining unit1411. In response to the request, the update unit1413updates the EPG information stored in the DB1412by using the received synchronization file.

FIG. 15is a flowchart of a process of the synchronization file manager604according to another exemplary embodiment of the present invention.

The client scheduler1409generates an event to update the EPG (operation1510). Then, the synchronization file list is requested from and received from the server607(operation1520). To determine the synchronization file to be received in the synchronization file list, a last update time stored in the DB1412is referred to (operation1530). The synchronization file created first after the last EPG update time has elapsed, is selected (operation1540). When the synchronization file is selected, the file creation date and time included in the file name are referred to.

Accordingly, in a digital broadcasting network of the present invention, in the server aspect, a storage space can be saved since unnecessary data is not stored after EPG information is updated. In the network aspect, network resources required to transfer a synchronization file can be saved since the file size is reduced according to only a last update state of the EPG information without having to include all update history when the synchronization file is created in a server. In the client aspect, client-side EPG information can be easily synchronized with sever-side EPG information by downloading only one synchronization file created first after the currently stored last synchronization file was created regardless of when the latest EPG information was updated.

Meanwhile, the exemplary embodiments of the present invention can be written as computer programs and can be implemented in general-use digital computers that execute the programs using a computer readable recording medium. Examples of the computer readable recording medium include magnetic storage media (e.g., ROM, floppy disks, hard disks, etc.) and optical recording media (e.g., CD-ROMs, or DVDs).