Television portal services system and method using message-based protocol

CLAIM OF PRIORITY

0001This application makes reference to, incorporates the same herein, and claims all benefit accruing under 35 U.S.C § 119 from my application TV PORTAL SERVICES SYSTEM AND METHOD USING THE MESSAGE-BASED PROTOCOL earlier field with the Korea Industrial Property Office on Jul. 4, 2003 and there duly assigned serial No. 10-2003-0045451.

BACKGROUND OF THE INVENTION

00021. Field of the Invention

0003The present invention generally relates to a television (e.g., digital television) portal services system and a method and, more particularly, to a television (TV) portal services system and a method using a message-based protocol as a framework considering service control, user management and inter-service association in implementing a home portal service.

00042. Description of the Related Art

0005In general, DTV (Digital Television) provides a chance capable of opening a service field having a new concept of a combination with data communication as well as a goal of improving picture and sound qualities of a conventional analog television.

0006Recently, related industry has been intensively attracted to a home living information/media service based on a television (TV) dedicated portal site using a high resolution of picture quality and a network, as having broad applicability.

0007A scope of the home portal service has been extended over a variety of fields including a messenger service, a multimedia service such as VOD (Video On Demand), a broadcast service, and a commerce service as well as a simple life information service, each service varying in type, dependent on their application object, advanced technique, or business characteristic. A service providing terminal and a server need a structural/technical scheme to cope with each service request properly.

SUMMARY OF THE INVENTION

0008The present invention is conceived to solve known problems existing in current television portal service systems, and to provide a television portal services system and a method using a message-based protocol, which is capable of providing a collective service from a user's system log-on (login) to each service utilization and management, a message service itself and a log-off by using a message-based protocol to incorporate respective individual services in configuring a television portal service.

0009According to an embodiment of the present invention for achieving the above object, there is provided a client terminal device for providing a television portal service, including: at least one or more service applications for performing a plurality of portal services based on a service message received from a server according to a user's request; and a messaging client module for: a) converting a service request message generated from the plurality of service applications to a message frame format through a message-based protocol to transmit to the server via a network, and b) receiving the message frame format for the service message transmitted via the server, parsing the received message frame format, and providing the parsed service message for a service application corresponding to the relevant service message of the plurality of service applications.

0010According to another embodiment of the present invention, there is provided a system for providing a television portal service, including: a messaging server module for: a) receiving a service request message frame through a message-based protocol transmitted from a client terminal via a network, parsing the received message frame and thereafter outputting the parsed service request message, and b) converting a service request and handling result message and a user informing message provided according to a request from the client terminal to the message frame through the message-based protocol, and thereafter transmitting the message frame to the client terminal via the network; and a message server for generating the relevant service request and handling message, and the user informing message according to the parsed service request message outputted from the messaging server module, and providing the messages for the messaging server module.

0011According to yet another embodiment of the present invention, there is provided a television portal services system, including: at least one or more service applications for performing a plurality of portal services based on a service message received via a network according to a user's request; a messaging client module for: a) converting a service request message generated from the plurality of service applications to a message frame format through a message-based protocol to transmit the message frame format via the network, and b) receiving the message frame format for the service message received via the network, parsing the received message frame format, and providing the parsed service message for a service application corresponding to the relevant service message of the plurality of service applications; a messaging server module for: a) parsing the service message frame through the message-based protocol received from the messaging client module via the network and thereafter outputting the parsed service request message, and b) converting a service request and handling result message and a user informing message provided according to a request from the messaging client module to a message frame through the message-based protocol, and thereafter transmitting the message frame to the messaging client module via the network; and a message server for generating the relevant service request and handling message, and the user informing message according to the parsed service request message outputted from the messaging server module, and providing the messages for the messaging server module.

0012The messaging client module of the client terminal may includes a message frame generating unit for generating the message frame corresponding to the service request message generated from the plurality of service applications to transmit the message frame to the messaging ls server module via the network; and a message parsing unit for parsing the service message frame transmitted from the messaging server module and providing the parsed service message for a service application corresponding to the relevant service, and may further include a message queue for temporarily storing the parsed service message from the messaging client module and then transferring the service message to an application corresponding to the relevant service.

0013The television portal services further comprises a FIFO (First In First Out) memory for temporarily storing the message so that the relevant message is displayed on a television screen through the relevant service application when the parsed message from the messaging client module is a message requiring a user's confirmation or an informing message to the user. The message may be displayed as an OSD (on-screen display) in a widget form in a case where a TV mode is a TV view mode, and in a message box or as an icon form using API (Application Program Interface) of OS (Operating System) in a case where the TV mode is a PC (Personal Computer) screen mode.

0014Further, the messaging server module of the server system may include: a message frame generating unit for generating a message frame corresponding to the service request and handling message, and the user informing message generated from the message server, and transmitting the generated message frame to the messaging client module via the network; and a message parsing unit for parsing the service message frame transmitted from the messaging client module and providing the parsed service message for the message server.

0015Moreover, according to the another embodiment of the present invention, there is provided, in a message-based protocol between a server terminal and a client terminal for providing a television portal service through the server and the client terminals, a message-based protocol between the server and the client terminals for providing a television portal service, which is capable of performing data transmission and reception between the server and the client terminals by producing a message type field for classifying properties of a message transmitted and received between the server and the client terminals; a service type field for classifying television portal service types; a data type field for classifying types of data transmitted and received between the server and the client terminals; a data field including actual data transmitted and received between the server and the client terminals; and a result type field for classifying message handling results, respectively, and by adding a relevant message to each produced field.

0016Meanwhile, according to another embodiment of the present invention, there is provided a method of processing a message in a client terminal to provide a television portal service, including the steps of: if service request messages are generated from a plurality of service applications according to a user's request, generating a message frame for at least one or more generated service request messages through a message-based protocol, and transmitting the generated message frame to a server via a network; receiving the message frame for response, handling and informing messages for a user request message received from the server via the network; and performing the relevant service by parsing the received message frame and by providing the parsed service message for a service application corresponding to the relevant service message of the plurality of service applications.

0017According to a further embodiment of the present invention, there is provided a method of processing a message in a server to provide a television portal service, including steps of: receiving a service request message frame through the message-based protocol transmitted from the client terminal via the network; parsing the received message frame to extract the service request message; producing a message frame for a response and handling result message to the service <b>1</b><i>s </i>request and a user informing message through a message-based protocol according to the extracted service request message; and transmitting the produced message frame to the client terminal via the network.

0018According to another embodiment of the present invention, there is provided a television portal services method, including steps of: if service request messages are generated from a plurality of service applications of a client terminal according to a user's request, generating a message frame for at least one or more generated service request messages through a message-based protocol, and transmitting the generated message frame to a server via a network; receiving the service request message frame through the message-based protocol transmitted from the client terminal via the network, and parsing the received message frame to extract the service request message; producing a message frame for a response and handling result message to the service request and a user informing message through a message-based protocol according to the extracted service request message, and then transmitting the message frame to the client terminal via the network; and performing the relevant service by parsing the message frame transmitted from the server via the network and by providing the parsed service message for a service application corresponding to the relevant service message of the plurality of service applications.

0019Here, formats of the message frame transmitted from the server and the message frame transmitted to the server have the same format structure through the same message-based protocol.

0020The formats of the message frame transmitted from the server and the message frame transmitted to the server include a message type field for classifying properties of a message transmitted and received between the server and the client terminal; a service type field for classifying television portal service types; a data type field for classifying types of data transmitted <b>15</b> and received between the server and the client terminal; a data field including actual data transmitted and received between the server and the client terminal; and a result type field for classifying message handling results.

BRIEF DESCRIPTION OF THE DRAWINGS

0021A more complete appreciation of the present invention, and many of the attendant advantages thereof, will become readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein:

0022<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a construction of an example TV portal services system;

0023<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating a construction of a TV portal services system according to the present invention;

0024<figref idref="DRAWINGS">FIG. 3</figref> is a diagram illustrating a message frame format transmitted and received between a client and a server according to the present invention;

0025<figref idref="DRAWINGS">FIG. 4</figref><i>a </i>is a diagram illustrating a data format for a message type as shown in <figref idref="DRAWINGS">FIG. 3</figref>; <figref idref="DRAWINGS">FIG. 4</figref><i>b </i>is a diagram illustrating a data format for a service type as shown in <figref idref="DRAWINGS">FIG. 3</figref>;

0026<figref idref="DRAWINGS">FIG. 4</figref><i>c </i>is a diagram illustrating an example of a data type included in a data type as shown in <figref idref="DRAWINGS">FIG. 3</figref>, and an actual transmission data format corresponding to the data type;

0027<figref idref="DRAWINGS">FIG. 4</figref><i>d </i>is a diagram illustrating an example of a data format for classification of message handling result (result type) as shown in <figref idref="DRAWINGS">FIG. 3</figref>;

0028<figref idref="DRAWINGS">FIG. 5</figref> is a diagram illustrating an operation flow upon a message receipt in the client according to the present invention;

0029<figref idref="DRAWINGS">FIG. 6</figref> is a diagram illustrating an operation flow upon message transmission from the client to the server according to the present invention;

0030<figref idref="DRAWINGS">FIG. 7</figref> is a diagram illustrating a log on/log off message flow between the client and the server according to an embodiment of the present invention;

0031<figref idref="DRAWINGS">FIG. 8</figref> is a diagram illustrating a message flow for an informing service from the server to the client according to an embodiment of the present invention;

0032<figref idref="DRAWINGS">FIG. 9</figref> is a diagram illustrating an order receipt message flow between the client and the server upon order service according to an embodiment of the present invention;

0033<figref idref="DRAWINGS">FIG. 10</figref> is a diagram illustrating a post-order-receipt cancellation message flow between the client and the server upon order service according to an embodiment of the present invention;

0034<figref idref="DRAWINGS">FIG. 11</figref> is a diagram illustrating a reservation receipt message flow between the client and the server upon reservation service according to an embodiment of the present invention;

0035<figref idref="DRAWINGS">FIG. 12</figref> is a diagram illustrating a post-reservation-receipt cancellation message flow between the client and the server upon reservation service according to an embodiment of the present invention;

0036<figref idref="DRAWINGS">FIG. 13</figref> is a diagram illustrating an EPG (electronic program guide) broadcast reservation message flow between the client and the server upon EPG service according to an embodiment of the present invention; and

0037<figref idref="DRAWINGS">FIG. 14</figref> is a diagram illustrating a VOD (video-on-demand) service message flow between the client and the server upon VOD service according to an embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

0038Hereinafter, a television portal services apparatus will be described with reference to the accompanying figures.

0039<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a construction of an example television portal service apparatus.

0040As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the television portal services apparatus consists of a service client <b>10</b> and a service server <b>20</b>. The service client <b>10</b> and the service server <b>20</b> are provided with respective service applications <b>11</b> to <b>15</b> and <b>21</b> to <b>25</b>, which perform relevant services according to respective service types.

0041Further, respective protocols <b>11</b><i>a </i>to <b>15</b><i>a </i>and <b>21</b><i>a </i>to <b>25</b><i>a</i>, which process data transmitted and received to perform respective services, are adopted between respective applications of the client <b>10</b> and the server <b>20</b>. Here, home portal services include, for example, a VOD (Video-on-Demand) service, a messenger (MSG) service, an electronic commerce service, an AAA (Authentication, Authorization, Accounting) service . . . and an EPG (Electronic Program Guide) service.

0042An Internet portal service is an aggregate of a variety of techniques from a simple WEB-based service such as an additional service to a multimedia service such as VOD. Each service is managed and controlled by entirely different protocol stacks in properties. That is, the additional service is composed of WEB contents using HTML. A commerce service, a channel control, user authentication, and VOD adopt a security protocol, a CCP (Channel Change Protocol) such as DAVIC (Digital Audio-Visual Council), a managing protocol defined in the AAA server, and a stream control protocol such as RTSP (Real Time Streaming Protocol) and iGMP (Internet Group Management Protocol), respectively. Thus, each time one service is additionally implemented, a corresponding separate software stack must be constructed.

0043It is necessary to construct a protocol stack dependent on each service type in both the service client <b>10</b> and the service server <b>20</b> in order to perform each service. For example, the VOD service will use HTTP/RTSP/iGMP <b>11</b><i>a </i>and <b>21</b><i>a</i>. The messenger, electronic commerce, AAA, and EPG services will adopt TCP/IP MSG protocols <b>12</b><i>a </i>and <b>22</b><i>a</i>, TCP/IP SSL protocols <b>13</b><i>a </i>and <b>23</b><i>a</i>, managing protocols <b>14</b><i>a </i>and <b>24</b><i>a</i>, and dedicated protocols <b>15</b><i>a </i>and <b>25</b><i>a</i>, respectively.

0044A protocol for each service will be described in further detail.

0045First, in case of RTSP (Real Time Streaming Protocol) and DSM-CC (Digital Storage Media Command and Control) protocol used in the VOD service, services such as the VOD provided over the Internet operate in a client/server form configured by a side that provides information always and a side that uses the information.

0046RTSP is a protocol for transferring multimedia information with a relatively loose temporal constraint in a client/server environment using the Internet. A client requests video and audio information with a real time characteristic to a server, and in response to this request, the server transmits the information. In transmission, pause, stop, resume, close, etc., which are basic functions of a VCR (Video Cassette Recorder), are available. Streaming is a technique for allowing continuous reproduction while maintaining a real time characteristic to a certain extent by such a manner that, when the server fragments and transmits a compressed continuous message, a receiving side does not decode/reproduce the message after receiving all of the messages but decode the message each time the receiving side receives a certain unit of the message.

0047RTSP can simultaneously control a plurality of media information streams in unicast and multicast environment and operate in various transport layer protocols including TCP (transmission control protocol) and UDP (user datagram protocol), and uses RTP/RTCP (real-time transport protocol/real-time control protocol). In order to send a control message, the RTSP performs RTP/RTCP channel setting using the reliable TCP and then causes the RTP/RTCP packet to be sent. That is, setting and releasing a session are controlled by the RTSP while actual information is transferred through the RTP.

0048The VOD service using an ATM (asynchronous transfer mode) network uses the DSM-CC (Digital Storage Media Command and Control) protocol. The DSM-CC is a protocol in an application layer for operation and control functions on a MPEG-1/2 bit stream, and is being subjected to a standardization task in a subgroup of an MPEG (Motion Picture Experts Group) standardization group. The DSM-CC is a signal protocol for a set top, a video server and a communication network, and has a main purpose of controlling the MPEG bit stream transmitted from a video storage medium, which stores the MPEG data. For the sake of this, The DSM-CC was constructed in the MPEG standardization group in 1994 and has been adopted as an international standard on June 1996 after several draft writings.

0049A session management standard of a central concentration manner is made in the DSM-CC in order to control the MPEG bit stream. That is, SRM (Session &amp; Resource Manager) manages a bandwidth for MPEG bit stream transmission with Q.2931 signaling proxy. Also, file access, directory control, and database control procedure as well as stream control are performed between the client and the server. DSM-CC describes a standard specification for MPEG bit stream control in stand-alone or heterogeneous network environment.

0050In addition, SSL (Secure Sockets Layer) protocol used in the electronic commerce service uses a manner of adding an intermediate step along with network connection setting, and of requesting security maintenance transmission options. In that connection state, data stream between the server and the client is encrypted prior to transmission, and the encrypted data stream is decrypted prior to utilization. An outgoing encrypted data is packaged by the TCP and then transferred to the Internet. An incoming encrypted data is received and thereafter is sent to an SSL layer for decryption.

0051This approach in the SSL protocol can apply SSL to any Internet application as well as WWW (World Wide Web). SSL was initially implemented under HTTP. Also, if SSL connection compromise is made between the server and the client, a resultant data communication channel becomes an individual, confirmation-acquired and reliable channel.

0052An initiation of SSL links is effected by a handshaking exchange between the server and the client. At this time, two systems exchange necessary encryption information, and support security channels. After the information exchange, an application program should be sent to a destination application program after being subjected to essential encryption needed for transmission. The destination application program performs an encryption necessary for data decryption and confirmation.

0053The SSL (Secure Sockets Layer) runs between an Internet application and a network transport layer, and encrypts the data communicated between the client and the server.

0054Meanwhile, as protocols used in the AAA service, TACACS (Terminal Access Controller Access Control System), RADIUS (Remote Access Dial-In User Service), and DIAMETER protocols can be used.

0055The TACACS is a little old authentication protocol applied to UNIX networks, allowing is a remote access server to send a user's log in password to an authentication server in order to determine whether to permit access to a given system. Since the TACACS is a non-encrypted protocol, it has poor stability as compared to subsequent TACACS+ and RADIUS protocols. A subsequent version of the TACACS is XTACACS (Extended TACACS), both of them being described in RFC (Network Working Group Request for Comments) 1492: “An Access Control Protocol, Sometimes Called TACACS”.

0056The TACACS+ is an entirely new protocol. Generally, in more recently configured or updated networks, the TACACS+ and RADIUS are substituted by previous protocols. The TACACS+ uses the TCP while the RADIUS uses the UDP.

0057Some managers recommend using the TACACS+ because the TCP is a more stable protocol. The RADIUS has both authentication and permission in one user profile, whereas the TACACS+ is divided into two tasks. TACACS and XTACACS still run in a number of old systems.

0058Recently, the most widely used AAA service is based on the RADIUS protocol. This is a protocol for a small-scale network device, which supports a few subscribers requiring server-based authentication, but is not suitable for the AAA service for communication businesses that have to <b>8</b> simultaneously support hundreds to thousands of users over various technique basis. In order to solve limitations and problems of the RADIUS protocol, present IETF (Internet Engineering Task Force) defines a diameter protocol. The diameter protocol provides various access networks and security application services, and performs authentication, authority, verification and billing processes for wired and wireless access subscribers and roaming subscribers over multiple networks.

0059As a result, comprehensive management for individual user terminals is raised as a critical technical problem to respective service providers. That is, a consistent access is needed over a television portal service to manage and control a service use right, use time and inter-service association.

0060When configuring a portal using an individual protocol stack, for a terminal, it is required to modify each service application and the relevant protocol stack in both an existing terminal and a server to provide a service as an individual application is added according to the service. Thus, there is a problem that it is difficult to cope with it flexibly even though service pool provided by PP (Preferences Profile) is configured.

0061Although this configuration maintains independence in individual service implementation, it fails to have unity in view of system configuration and to provide technical flexibility conforming to a variety of service combinations in service gateway implementation.

0062Hereinafter, a TV portal services system and a method according to preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

0063<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating a construction of a TV portal services system according to the present invention.

0064As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the TV portal services system may be composed of a client terminal <b>100</b> and a server.

0065The server may be composed of a messaging server module <b>310</b> and a message server <b>300</b>.

0066The client terminal <b>100</b> may be composed of a messaging client module <b>110</b>, an optional message queue <b>120</b>, an optional FIFO (First In First Out) <b>130</b>, and a plurality of service applications <b>140</b>-<b>200</b> for respective services.

0067Here, the service applications for respective services may consist of, but are not limited to, a DTV application <b>140</b>, an information providing service application <b>150</b>, a RVOD (real video-on-demand) service application <b>160</b>, a NVOD (near video-on-demand) service application <b>170</b>, an order delivery service application <b>180</b>, an informing service application <b>190</b> and an EPG (electronic program guide) service application <b>200</b>.

0068A message protocol is operated in a server/client structure. The messaging server module <b>310</b> is disposed in the message server <b>300</b> and the messaging client module <b>110</b> is disposed in the client terminal <b>100</b>. Here, the client terminal <b>100</b> may be a set top box or a gateway.

0069Messaging client module <b>110</b> is notified, using an IPC (Inter Process Communication), when a message to be transmitted to the sever is generated from any of the service applications <b>140</b>-<b>200</b>.

0070In response thereto, the messaging client module <b>110</b> confirms the message generated by the service applications and received via the IPC, and thereafter, produces a message frame appropriate for each generated message.

0071The produced message frame is transmitted to the messaging server module <b>310</b> through a message protocol (socket) <b>400</b>.

0072The messaging server module <b>310</b> parses the message frame transmitted from the client terminal <b>100</b> to check whether the message is requesting a service and thereafter to demand a corresponding service request to the message server <b>300</b>.

0073The message server <b>300</b> provides the messaging server module <b>310</b> with a relevant service request and handling result message in response to the service request from the client terminal <b>100</b>.

0074The messaging server module <b>310</b> parses the message provided from the message server <b>300</b> to produce a suitable message frame, and thereafter transmits the produced message frame to the messaging client module <b>110</b> in the client terminal <b>100</b> via the message protocol (socket) <b>400</b>.

0075When receiving the message generated or responded from the server, the messaging client module <b>110</b> parses the message using a parser in the messaging client module <b>110</b> to transmit it to the relevant service application <b>140</b>-<b>200</b> via the IPC (Inter Process Communication).

0076Accordingly, the relevant service application receiving the message will perform the requested service.

0077In order that the service request and handling result message, which is transmitted from the server, is provided for each application via the messaging client module <b>110</b>, the message queue <b>120</b> temporarily stores each message in a message structure for each message type by the messaging client module <b>110</b> and then provides the stored messages corresponding to respective ones of the applications, via the API (Application Program Interface), to the relevant service application <b>140</b>-<b>200</b>.

0078Also, when a message exists requiring a user's confirmation, such as in the informing service, among the messages transmitted from the server, FIFO <b>130</b> temporarily stores the relevant message so that it is displayed on a DTV screen (not shown) via the DTV application <b>140</b>. Here, a message display method includes the following: in the TV view mode, the message is displayed as an OSD (on-screen display) in a widget form, and in the PC screen mode the message is displayed in a message box or as an icon form using the API (Application Program Interface) of the OS (operating system).

0079The format structure of the message frame transmitted and received between the server and the client will be described in detail with reference to the accompanying <figref idref="DRAWINGS">FIGS. 3 and 4</figref><i>a </i>to <b>4</b><i>d. </i>

0080<figref idref="DRAWINGS">FIG. 3</figref> is a diagram illustrating a message frame format transmitted and received between the client and the server according to the present invention, <figref idref="DRAWINGS">FIG. 4</figref><i>a </i>is a diagram illustrating a data format of a message type as shown in <figref idref="DRAWINGS">FIG. 3</figref>, <figref idref="DRAWINGS">FIG. 4</figref><i>b </i>is a diagram illustrating a data format of a service type as shown in <figref idref="DRAWINGS">FIG. 3</figref>, <figref idref="DRAWINGS">FIG. 4</figref><i>c </i>illustrates an example of a data type included in a data type as shown in <figref idref="DRAWINGS">FIG. 3</figref> and an actual transmission data format corresponding to the data type, and <figref idref="DRAWINGS">FIG. 4</figref><i>d </i>illustrates an example of a data format for classification of a message handling result (result type) as shown in <figref idref="DRAWINGS">FIG. 3</figref>.

0081As shown in <figref idref="DRAWINGS">FIG. 3</figref>, the message frame format transmitted and received between the client and the server is classified into a message type field for classifying message properties, a service type field for classifying service types, a data type field for classifying data types, and a result type field for classifying actual data and message handling result to be transmitted.

0082Here, the message type information, as shown in <figref idref="DRAWINGS">FIG. 4</figref><i>a</i>, can be classified into a request (REQ) type message, a response (REP) type message and an informing (INF) type message.

0083The service type information, as shown in <figref idref="DRAWINGS">FIG. 4</figref><i>b</i>, can be classified, for example, into a log in/out service (LOG), an E-MAIL service (EML), an order service (ORD), a reservation service (RES), an alarm service (ALM) and an NVOD service (NVD). It should be apparent that there are a number of other possible services not listed here for the sake of brevity.

0084In addition, as the data type and data for the service types, as shown in <figref idref="DRAWINGS">FIG. 4</figref><i>c</i>, the LOG service includes log on (LON) data and log off (LOF) data as the data type and the EML service includes unread mail number (UMN) data as the data type.

0085The data included in the ORD service can be classified into settlement completion (STC), settlement confirmation (STF), receipt (RCP), post-receipt cancellation request (CAR), post-receipt cancellation confirmation (CAF), post-receipt cancellation handling (CAH) and order delivery (DLV) data.

0086The data included in the RES service can be classified into reservation applying (APL), reservation receipt (RCP), post-receipt cancellation request (CAR), post-receipt cancellation confirmation (CAF) and post-receipt cancellation handling (CAH) data.

0087And, the data included in the ALM service is classified into all alarm (ALL), unread mail alarm (UMA), reserved schedule alarm (RSA) and reserved program alarm (RPA) data.

0088Meanwhile, the NVD service includes channel request (CHR) data.

0089As shown in <figref idref="DRAWINGS">FIG. 4</figref><i>d</i>, the result type information is classified into success (SUC), failure (FAL) and unknown information (NUL).

0090As a result, the data transport frame format between the client and the server is transmitted in a message frame form through a message-based protocol as shown in <figref idref="DRAWINGS">FIG. 3</figref>, including each information as shown in <figref idref="DRAWINGS">FIGS. 4</figref><i>a </i>to <b>4</b><i>d</i>. That is, the message frame transmitted and received includes message type, service type, data type, data, and result type information.

0091An operation of transmitting and receiving a message between the client and the server using such a message frame format will be described with reference to the accompanying <figref idref="DRAWINGS">FIGS. 5 and 6</figref>.

0092<figref idref="DRAWINGS">FIG. 5</figref> is a diagram illustrating an operation flow upon a message receipt in the client according to the present invention, and <figref idref="DRAWINGS">FIG. 6</figref> is a diagram illustrating an operation flow upon a message transmission from the client to the server according to the present invention.

0093First, an operation in which the client receives the message transmitted from the server will be described with reference to <figref idref="DRAWINGS">FIG. 5</figref>.

0094As shown in <figref idref="DRAWINGS">FIG. 5</figref>, if each client terminal <b>100</b> connected to the network is powered on, it attempts a connection to the message server <b>300</b> via a predefined dedicated port. When the connection is not established, the client terminal again attempts the connection at several second intervals. When the connection is established between the client terminal <b>100</b> and the message server <b>300</b>, the client terminal performs a “log in” using a unique ID of the client terminal <b>100</b> and a dynamic IP number allocated from a DHCP (Dynamic Host Configuration Protocol) server. If an authentication is completed, the established connection is continuously maintained as long as no exception situations (for example, abnormality in the network or the server, etc.) are arisen.

0095If a message frame (e.g., REQORDSTF“order number”|“message”NUL: a response message to an order settlement confirmation request) is received, which is transmitted from the message server <b>300</b> via the messaging module <b>310</b>, a message parser <b>111</b> in the messaging client module <b>110</b> parses the received message, stores it in the message queue <b>120</b> temporarily, and then transfers it to the relevant service applications <b>150</b> to <b>200</b> via the IPC. Accordingly, the relevant application, which has received the message, will perform the relevant service.

0096At this time, if the received message type needs the user's confirmation request, the relevant request message is temporarily stored in the FIFO <b>130</b>, and thereafter displayed on a console, which is connected to the client terminal <b>100</b>, in which in the TV view mode, the message is displayed on the OSD in a widget form, while in the PC screen mode, it is displayed in a message box or an icon form using the API of the OS. That is, the relevant confirmation message is displayed through the DTV application or the PC application <b>140</b>.

0097Meanwhile, the following message transmission from the client terminal <b>100</b> to the message server <b>300</b> is performed. That is, as shown in <figref idref="DRAWINGS">FIG. 6</figref>, if a message to be transmitted to the message server <b>300</b> is generated from any of arbitrary service applications <b>150</b>-<b>200</b> in the client terminal <b>100</b> according to a request from the user, this message generation is notified to the messaging client module <b>110</b> using the IPC.

0098The messaging client module <b>110</b> produces, in an internal message generator <b>112</b>, a message frame (e.g., REPORDSTF“franchise code”|“order number”|−YES”SUC) for the message generated in the service applications <b>150</b> to <b>200</b>, and transmits the produced message frame to the messaging server module <b>310</b> in the server through the message protocol (socket) <b>400</b>.

0099Thus, when receiving the message frame from the client terminal <b>100</b>, the messaging server module <b>310</b> parses the received message frame and provides the parsed message frame to the message server <b>300</b>, such that a response or confirmation message to the message requested by the client terminal <b>100</b> is produced. The produced message is transmitted to the client terminal <b>100</b> through a message transmission flow as shown in <figref idref="DRAWINGS">FIG. 5</figref>.

0100Hereinafter, a message transmitting and receiving method between the client terminal <b>100</b> and the server <b>300</b> according to each service type will be described in steps with reference to the accompanying drawing.

0101<figref idref="DRAWINGS">FIG. 7</figref> is a diagram illustrating a log on/log off message flow between the client and the server according to an embodiment of the present invention.

0102First, when the client terminal <b>100</b>, e.g., a set top box is powered on, the messaging client module <b>110</b> of the client terminal <b>100</b> produces a message frame for log in to the server, and then transmits the produced log in message frame (e.g., REQLOGON“MG code”|“MG IP”NUL) to the message server <b>300</b> via the message protocol (S<b>101</b>).

0103After parsing the log in message frame transmitted from the client terminal <b>100</b> to perform authentication of the relevant client terminal <b>100</b>, the message server <b>300</b> produces a log on response message frame in the messaging server module <b>310</b> according to an authentication result to transmit the produced response message frame to the messaging client module <b>110</b> via the message protocol (socket) <b>400</b>.

0104That is, if the authentication and thus the log on of the relevant client terminal <b>100</b> is failed, the message server produces a log on failure response message frame (e.g., REPLOGON“MG code”FAL) to transmit it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>102</b>), while, if the authentication and thus log on of the relevant client terminal <b>100</b> is successful, the message server produces the log on success response message frame (e.g., REPLOGON“MG code”SUC) to transmit it to the messaging client module <b>110</b> of client terminal <b>100</b> (S<b>102</b>-<b>1</b>).

0105Thus, if the log on of the client terminal <b>100</b> is successful, the message server <b>300</b> confirms whether any informing information for the relevant client terminal <b>100</b> exists or not. If the informing information exists, the message server produces, in the messaging server module <b>310</b> of the message server <b>300</b>, an informing message frame (e.g., INFALMALL“message”NUL) for each customer to transmit it to the messaging client module <b>110</b> of the client terminal <b>100</b> via the message protocol <b>400</b> (S<b>103</b>).

0106Thus, the messaging client module <b>110</b> of the client terminal <b>100</b> parses the informing message frame transmitted from the server, and provides the parsed relevant informing message for an informing service application <b>190</b> so that the relevant informing service is performed.

0107In the operation, when the user powers off the client terminal <b>100</b>, the messaging client module <b>110</b> produces a message frame (e.g., INFLOGLOF“MG code”NUL) for the power-off to transmit it to the messaging server module <b>310</b> of the message server <b>300</b> (S<b>104</b>).

0108If the messaging server module <b>310</b> parses the log off message frame transmitted from the messaging client module <b>110</b>, and thereafter transfers the parsed log off message to the message server <b>300</b>, the message server <b>300</b> deletes the ID of the relevant client terminal <b>100</b> from a client connection list, which is managed by the message server <b>300</b>.

0109As a result, the following log on/log off service as shown in <figref idref="DRAWINGS">FIG. 7</figref> is performed. That is, when the client terminal <b>100</b> is powered on, the messaging client module <b>100</b> attempts the connection to the server, and if the connection is established, the log on procedure is performed by using the unique ID of the client terminal <b>100</b> in order to notify to the server whether various portal services are available or not.

0110However, if the client terminal <b>100</b> is powered off, the messaging client module <b>100</b> sends the log off message to the server in order to request to delete the ID of the relevant client terminal <b>100</b> from a connection list managed by the server.

0111<figref idref="DRAWINGS">FIG. 8</figref> is a diagram illustrating a message flow for an informing service from the server to the client according to an embodiment of the present invention.

0112As shown in <figref idref="DRAWINGS">FIG. 8</figref>, when any informing situation from the server <b>300</b> to the client terminal <b>100</b> exists. For example, when an e-mail informing, reserved schedule informing, or reserved program informing situation is generated, the message server <b>300</b> notifies the messaging server module <b>310</b>.

0113The messaging server module <b>310</b> then produces a message frame, such as an INFALMUMA“message”NUL message frame in case of the e-mail informing, an INFALMRSA“message”NUL message frame in case of the reserved schedule informing, or an INFALMRPA“message”NUL message frame in case of the reserved program informing, for the informing message generated from the message server <b>300</b>, and transmits it to the messaging client module <b>110</b> of the client terminal <b>100</b> through the message protocol <b>400</b> (S<b>201</b>, S<b>202</b>, S<b>203</b>, respectively).

0114The messaging client module <b>110</b> of the client terminal <b>100</b> parses the informing message frame transmitted from the server, stores each informing message temporarily in the message queue <b>120</b>, and thereafter transfers the informing message to the informing service application <b>190</b> so that the informing service is performed. Alternatively, when the user's confirmation is needed, the client module temporarily stores the informing message in the FIFO <b>130</b> and thereafter transfers the informing message sequentially to the DTV application <b>140</b> so that the informing message is displayed on the DTV screen. At this time, as described above, in the TV view mode the message is displayed on the OSD in a widget form, and in the PC screen mode it is displayed using the API of the OS in a message box or an icon form. This informing service may be used along with the EPG, order delivery, or E-MAIL service.

0115<figref idref="DRAWINGS">FIG. 9</figref> is a diagram illustrating an order receipt message flow between the client and the server upon order service according to an embodiment of the present invention.

0116As shown in <figref idref="DRAWINGS">FIG. 9</figref>, if a message for a product order is generated from the order delivery service application <b>180</b> of the client terminal <b>100</b>, the messaging client module <b>110</b> of the client terminal <b>100</b> produces the message frame for the order message and transmits it to the messaging server module <b>310</b> in the server via the message protocol <b>400</b>.

0117The messaging server module <b>310</b> parses the order message frame transmitted from the client terminal <b>100</b> and then transfers the order message to the message server <b>300</b>. Then, the message server <b>300</b> transmits an order request message to the franchise to which a relevant product is ordered according to the product order message.

0118A franchise terminal (not shown) handles the order according to the order message transmitted from the server, and thereafter provides an order handling result information to the server. The server provides the order handling result message to the client terminal <b>100</b>.

0119At this time, if an order settlement completion message from the order delivery service application <b>180</b> in the client terminal <b>100</b> for the product order is produced, the messaging client module <b>110</b> of the client terminal <b>100</b> produces a message frame (e.g., INFORDSTC“order number”NUL) for the order settlement completion message and transmits it to the messaging server module <b>310</b> via the message protocol <b>400</b> (S<b>301</b>).

0120The messaging server module <b>310</b> parses the message frame transmitted from the messaging client module <b>110</b> in the client terminal <b>100</b> and transfers the order settlement completion message to the message server <b>300</b>.

0121The message server <b>300</b> transfers an order settlement confirmation request message (OSF) to the messaging server module <b>310</b> according to the order completion message transferred from the messaging server module <b>310</b>.

0122The messaging server module <b>310</b> produces a message frame (REQORDOSF“order number”|“message”NUL) for the order settlement confirmation request message transferred from the message server <b>300</b> to transmit it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>302</b>).

0123The messaging client module <b>110</b> parses the order settlement confirmation request message frame transmitted from the server and temporarily stores the order settlement confirmation request message in the message queue to transfer it to the order delivery service application <b>180</b>.

0124Further, the messaging client module <b>110</b> parses the received message frame, and, because the relevant message is a message requiring the user's confirmation, transfers it to the DTV application <b>140</b> via the FIFO so that it is displayed on the DTV.

0125If the user completes the settlement confirmation (YES) in response to the displayed settlement confirmation message, the messaging client module <b>110</b> produces a message frame (REPORDSTF“franchise code”|“order number”|“YESSUC) for the settlement confirmation message to transmit it to the messaging server module <b>310</b> in the server (S<b>303</b>).

0126After parsing the received settlement confirmation message frame, the messaging server module <b>310</b> transfers the settlement confirmation message to the message server <b>300</b>. The message server <b>300</b> transmits the settlement confirmation message to the relevant franchise so that the order is handled.

0127After handling the order, the franchise terminal transmits an order handling result message (Receipt) to the message server <b>300</b>. The message server <b>300</b> produces the order handling informing message according to the order handling result message transmitted from the franchise and transfers it to the messaging server module <b>310</b>.

0128The messaging server module <b>310</b> produces a message frame (INFORDRCP“order number”|“message”NUL) for the order handling informing message transferred from message server <b>300</b> and transmits it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>304</b>).

0129Thus, after parsing the relevant frame and storing the parsed order handling informing message in the message queue, the messaging client module <b>110</b> transfers it to the order delivery service application <b>180</b> so that the relevant service is performed, and at the same time, to the DTV application <b>140</b> so that the order handling result message is displayed on the DTV, which allows the user to confirm the order handling result.

0130However, in S<b>302</b>, if the user selects the settlement confirmation (NO) after receiving a ls message frame (REQORDOSF“order number”|“message”NUL) for the order settlement confirmation request message transmitted from the server, the messaging client module <b>110</b> produces a frame REPORDSTF“franchise code”|“order number”|“NOSUC) for the order settlement confirmation (NO) message to transmit it to the server. Thus, the server transmits the settlement confirmation (NO) message to the franchise so that the order cancellation operation is performed.

0131The post-order-receipt cancellation service will be described with reference to <figref idref="DRAWINGS">FIG. 10</figref>.

0132<figref idref="DRAWINGS">FIG. 10</figref> is a diagram illustrating a post-order-receipt cancellation message flow between the client and the server upon order service according to an embodiment of the present invention.

0133As shown in <figref idref="DRAWINGS">FIG. 10</figref>, first, if a cancellation request message is generated from the order delivery service application <b>180</b>, the messaging client module <b>110</b> produces a message frame (INFORDCAR“franchise code”|“order number”NUL) for the cancellation request message, and transmits it to the messaging server module <b>310</b> in the server (S<b>401</b>).

0134The messaging server module <b>310</b> in the server parses the message frame transmitted from the client terminal <b>100</b> and transfers the cancellation request message to the message server <b>300</b>, which is then sent to a franchise terminal.

0135If the message server <b>300</b> receives a post-order-receipt cancellation confirmation message from the franchise terminal after transmitting the cancellation request message received from the client terminal <b>100</b>, to the relevant franchise terminal, it generates an order cancellation confirmation informing message, produces a message frame (INFORDCAF“order number”|“message”NUL) for the generated order cancellation confirmation informing message in the messaging server module <b>310</b>, and transmits it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>402</b>).

0136Furthermore, if the message server <b>300</b> receives an order cancellation handling message from the franchise terminal, it generates an order cancellation informing message to transfer the relevant message to the messaging server module <b>310</b>.

0137The messaging server module <b>310</b> produces a message frame (INFORDCAH“order number”|“message”NUL) for the order cancellation handling message to transmit it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>404</b>). The messaging client module <b>110</b> parses the received message frame, transfers the order cancellation handling message to the order delivery service application <b>180</b> to handle the relevant service, and transfers the relevant message to the DTV application <b>140</b> so that the relevant message is displayed, which enables the user to confirm the order cancellation result.

0138The foregoing is a message flow in case where the post-order-receipt cancellation request from the user exists. Hereinafter, a case will be described in which the order cancellation request from a franchise exists.

0139First, if an order cancellation request from the franchise terminal exists, the message server <b>300</b> produces an informing message for the order cancellation request transmitted from the franchise terminal and transfers the relevant message to the messaging server module <b>310</b>.

0140The messaging server module <b>310</b> produces a message frame (REQORDCAF“order number”|“message”NUL) for the franchise order cancellation informing message generated from the message server <b>300</b> to transmit it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>404</b>).

0141The messaging client module <b>110</b> parses the message frame transmitted from the messaging server module <b>310</b> and transfers the order cancellation informing message to the order delivery service application <b>180</b> to perform the relevant service. In addition, the messaging client is module <b>110</b> transfers the relevant message to the DTV application <b>140</b> so that the relevant message is displayed, which enables the user to effect an order cancellation confirmation response.

0142If the user selects the order cancellation confirmation response message “YES”, the messaging client module <b>110</b> produces a message frame (REPORDCAF“franchise code”|“order number”YESSUC) for the order cancellation confirmation response message to transmit it to the messaging server module <b>310</b> (S<b>405</b>).

0143The messaging server module <b>310</b> parses the message frame transmitted from the messaging client module <b>110</b> and transmits the relevant message, i.e., the order cancellation confirmation response message, to the franchise terminal so that the order cancellation is handled. If the order cancellation is completed, the franchise terminal transmits the order cancellation handling result message to the server.

0144In response thereto, the messaging server module <b>310</b> in the server produces a frame (INFORDCAH“order number”|“message”NUL) for the order cancellation confirmation handling informing message to transmit it to the messaging client module <b>10</b> (S<b>406</b>).

0145Meanwhile, in the step S<b>404</b>, if the user selects cancellation confirmation “NO” when the client receives the order cancellation request message as the order cancellation request message is received from the franchise, an operation of transmitting and receiving the order cancellation response message (S<b>407</b>, S<b>408</b>) is performed in the same method as the above-stated operation. Therefore, detailed explanation on the operation will be omitted.

0146Also, if the message from a franchise is received, which indicates that the order delivery handling of the product is completed, the messaging server module <b>310</b> transmits a message frame (INFORDDLV“order number”|“message”NUL) for the delivery handling informing message to the messaging client module <b>110</b> in order to complete the order delivery service operation.

0147<figref idref="DRAWINGS">FIG. 11</figref> is a diagram illustrating a reservation receipt message flow between the client and the server upon reservation service according to an embodiment of the present invention.

0148As shown in <figref idref="DRAWINGS">FIG. 11</figref>, if an order reservation receipt application from user exists, the order delivery service application <b>180</b> generates an order reservation receipt application message.

0149The thus generated order reservation receipt application message is transferred to the messaging client module <b>110</b>, the messaging client module <b>110</b> produces a message frame “INFRESAPL“franchise code”|”reservation number”NUL” for the generated order reservation receipt application message to transmit it the message server module <b>310</b> (S<b>501</b>).

0150The message server module <b>310</b> parses the message frame for the order reservation receipt application message transmitted from the client and transmits the relevant order reservation receipt application message to the relevant franchise.

0151The franchise performs an order reservation receipt according to the order reservation receipt application message transmitted from the server, and transmits an order reservation receipt handling result message to the messaging server module <b>310</b> in the server.

0152The messaging server module <b>310</b> in the server transmits, to the messaging client module <b>110</b> in the client, a message frame “INFRESRCP“reservation number”|“message”NUL for the reservation receipt handling informing message according to the order reservation receipt handling message transmitted from franchise (S<b>502</b>).

0153The messaging client module <b>110</b> parses the message frame for the reservation receipt handling informing message transmitted from the server, transfers the relevant message to the order delivery service application <b>180</b> to perform the relevant service, and transfers the relevant message to the DTV application <b>140</b> to display the order reservation handling informing message so that the user easily confirms the order reservation handling result.

0154A case will be described with reference to <figref idref="DRAWINGS">FIG. 12</figref>, in which a reservation receipt, after an order reservation receipt, is cancelled.

0155<figref idref="DRAWINGS">FIG. 12</figref> is a diagram illustrating a post-reservation-receipt cancellation message flow between the client and the server upon reservation service according to an embodiment of the present invention.

0156First, if the post-reservation-receipt cancellation request message is generated through the order delivery service application <b>180</b>, the messaging client module <b>110</b> produces a message frame “INFORDCAR“franchise code”|“reservation number”NUL” for the post-reservation-receipt cancellation request message and transmits it to the messaging server module <b>310</b> in the server (S<b>601</b>).

0157The messaging server module <b>310</b> in the server parses the message frame transmitted from the client terminal <b>100</b> and transfers post-reservation-receipt cancellation request message to the relevant franchise terminal via the message server <b>300</b>.

0158After transmitting the post-reservation-receipt cancellation request message received from the client terminal <b>100</b> to the relevant franchise terminal, if a post-reservation-receipt cancellation confirmation message is received from the franchise terminal, the message server <b>300</b> generates a reservation cancellation confirmation informing message, and in the messaging server module <b>310</b>, produces a message frame INFORDCAF“reservation number”|“message”NUL” for the generated reservation cancellation confirmation informing message to transmit it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>602</b>).

0159Furthermore, if the message server (<b>300</b>) receives a reservation cancellation handling message from the franchise terminal, it generates the reservation cancellation handling informing message to transfer the relevant message to the messaging server module <b>310</b>.

0160The messaging server module <b>310</b> produces a message frame “INFORDCAH“reservation number”|“message”NUL for the reservation cancellation handling informing message to transmit it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>603</b>).

0161The message client module <b>110</b> parses the received message frame, transfers the reservation cancellation handling informing message to the order delivery service application <b>180</b> to handle the relevant service, and transfers the relevant message to the digital television (DTV) application <b>140</b> to display the relevant message so that the user confirms the reservation cancellation result.

0162The foregoing is a message flow when a post-reservation-receipt cancellation request from a user exists. A case will be described in which the reservation receipt cancellation request from the franchise exists.

0163First, if the reservation cancellation request from the franchise terminal exists, the message server <b>300</b> produces an informing message for the reservation cancellation request transmitted from the franchise terminal to transfer the relevant message to the messaging server module <b>310</b>.

0164The messaging server module <b>310</b> produces a message frame (REQORDCAF“reservation number”|“message”NUL) for a franchise reservation cancellation informing message generated from the message server <b>300</b> to transmit it to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>604</b>).

0165The messaging client module <b>110</b> parses the message frame transmitted from the messaging server module <b>310</b>, and transfers the reservation cancellation informing message to the order delivery service application <b>180</b> to perform the relevant service. Also, it transfers the relevant message to the DTV application <b>140</b> to display the relevant message so that the user performs a reservation cancellation confirmation response.

0166If the user selects a reservation cancellation confirmation response message “YES”, the messaging client module <b>110</b> produces a message frame (REPORDCAF“franchise code”|“reservation number”YESSUC) for the reservation cancellation confirmation response message and transmits it to the messaging server module <b>310</b> (S<b>605</b>).

0167The messaging server module <b>310</b> parses the message frame transmitted from the messaging client module <b>110</b> and transmits the relevant message, i.e., the reservation cancellation confirmation response message to the franchise terminal so that the reservation cancellation is handled. If the reservation cancellation is completed, the franchise terminal transmits a reservation cancellation handling result message to the server.

0168Then, the messaging server module <b>310</b> in the server produces a frame (INFORDCAH“reservation number”|“message”NUL) for the reservation cancellation confirmation handling informing message to transmit it to the messaging client module <b>110</b> (S<b>606</b>).

0169Meanwhile, in the step S<b>604</b>, if the user selects a cancellation confirmation “NO” when the reservation cancellation request message from the franchise is received and accordingly the order cancellation request message is received by the client, transmitting and receiving operations of the order cancellation response message (S<b>607</b>, S<b>608</b>) are performed in the same method as in the above-stated operation. Thus, explanation on detailed operation therefor will be omitted.

0170Hereinafter, a message flow upon the EPG broadcast reservation will be described with reference to <figref idref="DRAWINGS">FIG. 13</figref>.

0171<figref idref="DRAWINGS">FIG. 13</figref> is a diagram illustrating an EPG broadcast reservation message flow between the client and the server upon EPG service according to an embodiment of the present invention.

0172As shown in <figref idref="DRAWINGS">FIG. 13</figref>, if the user effects a broadcast reservation application from an EPG service application <b>200</b> via an EPG screen, the messaging client module <b>110</b> of the client terminal <b>100</b> produces a message frame “INFRESCHR“reserved broadcast number”NUL” for the broadcast reservation message generated through the EPG service application <b>200</b> to transmit it to the messaging server module <b>310</b> in the server (S<b>701</b>).

0173The messaging server module <b>310</b> parses the message frame transmitted from the messaging client module <b>110</b> of the client terminal <b>100</b> to transfer the parsed message to the message server <b>300</b>.

0174The message server <b>300</b> performs a broadcast reservation for a channel requested by the user using the broadcast reservation message transmitted from the messaging server module <b>310</b>.

0175Further, the message server <b>300</b> checks a broadcast reservation time of the broadcast reserved program selected by the user and, if the relevant time is reached, the message server <b>300</b> produces a reserved program informing message to transfer it to the messaging server module <b>310</b>.

0176The messaging server module <b>310</b> produces a message frame INFALMRPA“message”NUL for the reserved program informing message from the message server <b>300</b> and transmits the produced message frame to the messaging client module <b>110</b> (S<b>702</b>).

0177The messaging client module <b>110</b> parses the message frame for the broadcast reserved program informing message transmitted from the messaging server module <b>310</b> in the server to transmit the relevant message to the EPG service application <b>200</b> so that the relevant service, i.e., a function such as a channel changeover to a channel where the reserved program is broadcast, is performed, and also to transfer the relevant service to the DTV application <b>140</b> and display the reserved program informing message, which allows the user to confirm the message.

0178That is, the EPG service is provided on a basis of the web, allowing the broadcast reservation associated with the informing service. If a broadcast to be reserved is selected on an EPG screen reservation, it is transmitted to the server in conformity with a reservation message format.

0179If the relevant time reaches after recording a broadcast reservation situation, the server informs the terminal of it via the informing service. When receiving the reservation informing message, the terminal attempts an automatic channel switchover to the relevant channel or notifies it to the DTV application <b>140</b>.

0180An operation of the VOD service via the message protocol will be described with reference to the accompanying <figref idref="DRAWINGS">FIG. 14</figref>.

0181First, if the user requests a VOD channel for viewing via the VOD service applications <b>160</b> and <b>170</b>, the messaging client module <b>110</b> produces a message frame (REQNVDCHR“channel number”NUL”) for the VOD channel request to transmit it to the messaging server module <b>310</b> (S<b>801</b>).

0182The messaging server module <b>310</b> parses the message frame for the VOD channel request transmitted from the messaging client module <b>110</b> and transfers the VOD channel request message to the message server <b>300</b>.

0183The message server <b>300</b> performs, using the VOD channel request message transferred from the messaging server module <b>310</b>, channel authentication whether the relevant channel is a <b>15</b> channel available in the client terminal <b>100</b> or not.

0184If the channel authentication is successful or failed, that is, if the relevant channel is available in the client terminal <b>100</b> or not, the message server transmits the message frame for a channel authentication response message to the client terminal <b>100</b>. If the relevant VOD service is unicast and if the authentication of the relevant channel is successful, the messaging server module <b>310</b> transmits an REPNVDCHR“channel number”SUC message frame and, adversely, if the VOD channel authentication is failed, the messaging server module <b>310</b> transmits an REPNVDCHR“channel number”FAL message frame to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>802</b>, S<b>803</b>).

0185The messaging client module <b>110</b> parses, in the parser, the frame for the response message transmitted from the server, and transfers the relevant message to the VOD service application to display it so that the user confirms the message.

0186However, in case that the VOD service is multicast, if the channel authentication is successful with the response message frame to a VOD channel request, the message server transmits an REPNVDCHR“channel number”|”multicasting IP”SUC message frame to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>804</b>). If the channel authentication is failed, the message server transmits an REPNVDCHR“channel number”|“NULFAL frame to the messaging client module <b>110</b> of the client terminal <b>100</b> (S<b>805</b>).

0187As a result, if the client terminal <b>100</b> requests a VOD channel to be viewed to the server <b>300</b> through the messaging client module <b>110</b>, the server <b>300</b> confirms whether the requested channel is a channel available for the relevant terminal or not, and sends a response message. At this time, in case the VOD service is unicast, if the client terminal receives a response indicating that is the channel is available, the VOD application receiving it through a parser of the messaging client module <b>110</b> parses the stream to display it.

0188However, if the VOD service is multicast, the server inserts a multicast group IP corresponding to the requested channel into the response message to transmit it to the client terminal <b>100</b>.

0189Accordingly, the parser of the messaging client module <b>110</b> in the client terminal <b>100</b> transfers the IP to the VOD application, and the VOD application receives and parses the stream by sending a message for joining the relevant multicast group using the IP, and displays it.

0190As a result, the TV portal services apparatus and method according to the present invention defines control messages needed for implementing several services available between the server and the client terminals. Furthermore, it suggests one service framework and message standard as shown in <figref idref="DRAWINGS">FIGS. 3 and 4</figref> to collectively manage and handle several services so that HD/SD (high definition/standard definition) broadcast reception using one terminal in a home and services such as order delivery, VOD, monitoring, and information provision using the present invention are used.

0191As described above, the TV portal services apparatus and method according to the present invention allows management and control for various service items by providing a consistent message-based framework in the TV portal service. Furthermore, it is possible to implement new applications, which were difficult to be implemented, by providing a tool for association between individual services. It results in technical efficiency in implementing the server as well as the terminal, and implementation of flexible services by standardizing the API for the TV portal service.