KR100501332B1 - 메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공시스템 및 그 방법 - Google Patents

메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공시스템 및 그 방법 Download PDF

Info

Publication number
KR100501332B1
KR100501332B1 KR10-2003-0045451A KR20030045451A KR100501332B1 KR 100501332 B1 KR100501332 B1 KR 100501332B1 KR 20030045451 A KR20030045451 A KR 20030045451A KR 100501332 B1 KR100501332 B1 KR 100501332B1
Authority
KR
South Korea
Prior art keywords
message
service
server
data
request
Prior art date
Application number
KR10-2003-0045451A
Other languages
English (en)
Other versions
KR20050003921A (ko
Inventor
김영집
성기연
강승미
한영섭
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR10-2003-0045451A priority Critical patent/KR100501332B1/ko
Priority to US10/871,275 priority patent/US20050005306A1/en
Priority to CNB2004100621785A priority patent/CN1312893C/zh
Publication of KR20050003921A publication Critical patent/KR20050003921A/ko
Application granted granted Critical
Publication of KR100501332B1 publication Critical patent/KR100501332B1/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/475—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4753—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for user identification, e.g. by entering a PIN or password
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/488—Data services, e.g. news ticker
    • H04N21/4882—Data services, e.g. news ticker for displaying messages, e.g. warnings, reminders
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8193—Monomedia components thereof involving executable data, e.g. software dedicated tools, e.g. video decoder software or IPMP tool
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends

Abstract

본 발명에 따른 메시지 기반 프로토콜을 이용한 TV 포탈 서비스 제공장치 및 그 방법은, TV 포털 서비스에 있어서 일관성 있는 메시지 기반의 프레임워크를 제공함으로서 다양한 서비스 항목에 대한 관리와 제어가 가능하도록 한다. 또한 개별 서비스 사이의 연동을 위한 도구를 제공함으로서 기존에는 구현이 곤란하던 새로운 어플리케이션의 구현이 가능하며, 이는 단말 뿐만 아니라 서버의 구현에 있어서도 기술적인 효율성은 물론이고 TV 포털 서비스에 대한 API를 규격화함으로서 융통성 있는 서비스 구현이 가능한 것이다.

Description

메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공 시스템 및 그 방법{TV PORTAL SERVICES SYSTEM AND METHOD USING THE MESSAGE-BASED PROTOCOL}
본 발명은 TV(Television: 예를 들면 DTV) 포탈 서비스 제공 시스템 및 그 방법에 관한 것으로서, 특히 홈 포털 서비스의 구현에 있어서 서비스 제어, 사용자 관리 및 서비스간 연동을 고려한 프레임워크로서의 메시지 기반 프로토콜을 이용한 TV 포탈 서비스 제공 시스템 및 그 방법에 관한 것이다.
일반적으로, DTV(Digital Television)는 기존의 아날로그 TV의 화질 및 음향의 질을 향상시키는 방향으로 뿐만 아니라 데이터 통신과의 결합이라는 새로운 개념의 서비스 분야를 열 수 있는 기회를 제공하고 있다.
고해상도의 화질과 네트워킹을 이용하여 TV 전용의 포털 사이트를 기반으로 한 홈 리빙 정보/미디어 서비스는 그 응용 가능성이 큰 것으로 최근 업계의 관심을 집중시키고 있다.
홈 포털 서비스는 단순 생활정보 서비스뿐만 아니라 메신저, VOD 등의 멀티미디어 서비스, 방송서비스, 상거래 서비스에 이르기까지 다양한 분야에 걸쳐서 그 범위를 확장하고 있다. 이러한 서비스들은 그 적용대상 혹은 기술의 진보, 사업의 특성에 따라서 다양한 형태를 가지게 되며, 서비스를 제공하는 단말과 서버는 이러한 요구에 적절히 대응하기 위한 구조적/기술적 방안을 강구하는 것이 필요하다 하겠다.
이하, 첨부한 도면을 참조하여 종래 기술에 따른 TV 포탈 서비스 장치에 대하여 살펴보기로 하자.
도 1은 종래 기술에 따른 TV 포탈 서비스 장치의 블록 구성을 나타낸 도면이다.
도 1에 도시된 바와 같이, TV 포탈 서비스 장치는, 서비스 클라이언트(10) 및 서비스 서버(20)로 구성되고, 서비스 클라이언트(10)와 서비스 서버(20)에는 각 서비스의 종류에 따라 해당 서비스를 수행하는 각각의 어플리케이션(11 - 15, 21-25)이 구성된다.
또한, 서버(20)와 클라이언트(10)간의 각 어플리케이션간에는 각각의 서비스를 수행하기 위해 송수신되는 데이터를 처리하는 각각의 프로토콜(11a - 15a, 21a -25a)이 채용되고 있다. 여기서, 홈 포탈 서비스의 종류를 보면, VOD 서비스, 메신저(Messanger) 서비스, 상거래 서비스, AAA(Authentication, Authorization, Accounting)서비스, EPG(Electronic Program Guide)서비스 등이 있다.
인터넷 포털 서비스는 부가서비스와 같은 단순 WEB 기반 서비스에서부터 VOD와 같은 멀티미디어 서비스에 이르기까지 다양한 기술분야의 집합체라 할 수 있다. 기존에는 각각의 서비스는 그 특성상 완전히 다른 프로토콜 스택에 의하여 관리/제어되어 지고 있다. 즉 부가서비스의 경우에는 HTML을 사용하는 웹 컨텐츠로 구성하고, 상거래 서비스의 경우에는 security protocol, 채널제어는 DAVIC 등의 CCP (Channel Change Protocol), 사용자 인증은 AAA 서버에서 정의된 관리 프로토콜, VOD의 경우에는 RTSP, iGMP 등의 스트림 제어 프로토콜을 채용하고 있다. 따라서 하나의 서비스가 추가 구현될 때마다 그에 해당하는 별도의 소프트웨어 스택을 구성해야 하는 것이다.
이러한 각각의 서비스를 수행하기 위해서는 각 서비스 종류에 따른 프로토콜 스택을 클라이언트(10)와 서버(20)측 모두에 구성하여야 하는데, 예를 들면, VOD 서비스의 경우 HTTP/RTSP/iGMP(11a, 21a)를 사용하고, 메신저 서비스의 경우 TCP/IP MSG 프로토콜(12a, 22a), 상거래 서비스의 경우 TCP/IP SSL 프로토콜(13a, 23a), AAA 서비스의 경우 관리 프로토콜(Managing Protocol)(14a, 24a), EPF 서비스의 경우 데디케이티드 프로토콜(Dedicated Protocol)를 채용하게 되는 것이다.
상기한 각 서비스별 프로토콜에 대하여 좀 더 상세하게 설명해 보기로 하자.
먼저, VOD 서비스의 경우 사용되는 RTSP(Real Time Streaming Protocol ), DSM-CC(Digital Storage Media Command and Control) 프로토콜을 보면, 인터넷 상에서 제공되는 VOD (Video On Demand)와 같은 서비스는 항상 정보를 제공하는 측과 이용하는 측으로 구성되는 클라이언트/서버 형태로 동작한다.
RTSP는, 인터넷을 이용하는 클라이언트/서버 환경에서 시간적 제약 조건이 비교적 느슨한 멀티미디어 정보를 전달하기 위한 프로토콜이다. 클라이언트는 서버에게 실시간 특성을 갖는 영상이나 음성 정보를 요청하고, 이 요청에 의해 서버가 정보를 전송하는 방식으로 동작한다. 전송 도중에 VCR (Video Cassette Recorder)의 기본 기능인 Pause, Stop, Resume, Close 등이 가능하다. 스트리밍(Streaming)이란, 서버측에서 압축된 연속적인 메시지를 패킷으로 잘라 전송하면, 수신측에서는 메시지 전체를 수신한 다음 복호/재생하는 것이 아니라, 어떤 일정한 단위의 메시지가 수신될 때마다 복호함으로써 실시간 특성을 어느 정도 유지하면서 연속적인 재생을 가능하게 해주는 기술이다.
RTSP는 유니캐스트(Unicast), 멀티캐스트(Multicast) 환경에서 복수개의 미디어 정보 스트림을 동시 제어할 수 있고, TCP와 UDP를 포함하는 다양한 수송계층 프로토콜에서 동작할 수 있으며, RTP/RTCP를 사용한다. RTSP는 제어 메시지 전송을 위해서 신뢰성 있는 TCP를 사용하여 RTP/RTCP 채널 설정을 한 다음, RTP/RTCP 패킷이 전달 되도록 한다. 즉, 세션의 설정과 해제는 RTSP에 의해 제어되고, 실제의 정보는 RTP를 통해 전달된다.
ATM 망을 이용한 VOD 서비스의 경우 DSM-CC 프로토콜을 사용한다. DSM-CC는 MPEG-1/2의 비트 스트림을 위한 연산과 제어 기능에 대한 응용 계층의 프로토콜로 MPEG 표준화 그룹의 서브 그룹에서 표준화 작업이 진행 중이다. 이 DSM-CC는 셋탑과 비디오 서버, 그리고 통신망의 신호 프로토콜로 MPEG 데이터를 저장한 비디오 자장 매체로부터 전송되는 MPEG 비트 스트림을 제어하는 것이 주 목적이다. 이를 위해 1994년 MPEG 표준화 그룹 내부에서 결성되어 수 차례의 초안 작성을 거쳐 1996년 6월 국제 표준으로 채택되었다.
MPEG 비트 스트림을 제어하기 위해 DSM-CC에서 중앙 집중 형태로 세션 관리에 대한 표준을 제정하고 있다. 즉, 세션 및 자원 관리자(SHM: Session & Resource Manager)가 Q.2931 시그널링의 프록시(proxy)로 MPEG 비트 스트림 전송을 위한 대역폭을 관리한다. 그리고 클라이언트와 서버사이에 스트림 제어를 비롯한 파일 접근 및 디렉토리 제어, 그리고 데이터베이스 제어 절차를 수행한다. DSM-CC은 다음과 같은 특징의 단일 시스템(stand-alone) 또는 이질 통신망(heterogeneous network)환경에서 MPEG 비트 스트림 제어를 위한 표준 사양을 기술하고 있다.
그리고, 전자상거래 서비스에 이용되는 SSL(Secure Sockets Layer) 프로토콜은, 네트워크 연결 설정과 더불어 중간 단계를 추가하고, 보안 유지 전송 옵션들을 요구하는 방식을 취한다. 그 연결 상태에서 서버와 클라이언트간의 데이터 흐름은 전송에 앞서 암호화되고 수신측 시스템에서 이용하기 전에 해독된다. 외부로 나가는 암호화된 데이터는 TCP에 의해 포장돼서 인터넷으로 간다. 내부로 들어오는 암호화된 데이터는 수신된 후 해독을 위해 SSL 계층으로 보내진다.
SSL 프로토콜의 이러한 접근법으로 WWW뿐만 아니라 어떤 인터넷 애플리케이션에도 SSL을 적용시킬 수 있다(하지만 SSL은 처음에 HTTP하에서만 구현되었다). 또 서버와 클라이언트간에 SSL 연결 타협이 이루어지면, 그 결과인 데이터 통신 채널은 개인적이고 확인을 득한, 신뢰할 만한 채널이 된다.
SSL 링크들의 개시는 서버와 클라이언트간의 핸드쉐이킹 교환으로 이루어진다. 이때 두 시스템은 필요한 암호 정보를 교환, 보안 채널을 지원한다. 정보 교환 후 애플리케이션 프로그램은 반드시 전송에 필요한 암호 조치들을 취한 후에 행선지 애플리케이션 프로그램에 보내야 한다. 행선지 애플리케이션 프로그램은 데이터를 해독하고 확인하는 데 필요한 암호 조치를 취한다.
SSL은 인터넷 애플리케이션과 네트워크 트랜스포트 레이어 사이에서 작용하면서, 클라이언트와 서버 사이에 오고 가는 데이터를 암호화한다
한편, AAA 서비스에 사용되는 프로토콜로는 TACACS (Terminal Access Controller Access Control System) , RADIUS (Remote Access Dial-In User Service) , DIAMETER protocol이 사용될 수 있다.
TACACS는 유닉스 네트웍에 적용되는 다소 오래된 인증 프로토콜로서, 주어진 시스템에 대해 액세스를 허용할 것인지를 결정하기 위하여, 원격 액세스 서버가 사용자의 로그인 패스워드를 인증 서버에 전달할 수 있게 해준다. TACACS는 암호화되지 않은 프로토콜이므로, 그 이후에 나온 TACACS+와 RADIUS 프로토콜에 비해 안전성이 떨어진다. TACACS의 다음 버전은 XTACACS (Extended TACACS)이며, 둘 모두 RFC 1492에 기술되어 있다.
TACACS+는 전적으로 새로운 프로토콜이다. 보다 최근에 만들어졌거나 갱신된 네트웍에서는, 일반적으로 TACACS+와 RADIUS기 이전의 프로토콜들을 대체하였다. TACACS+은 TCP를 사용하며, RADIUS는 UDP를 사용한다.
일부 관리자들은 TCP가 보다 안정적인 프로토콜이라는 이유를 들어, TACACS+를 사용할 것을 권고하고 있다. RADIUS가 인증과 허가를 하나의 사용자 프로필 내에 모두 가지고 있는데 반하여, TACACS+는 두 개의 작업으로 나눈다. TACACS와 XTACACS는 많은 오래된 시스템에서 아직도 운영되고 있다.
현재 가장 널리 사용되고 있는 AAA 서비스는 RADIUS 프로토콜을 기반으로 하고 있다. 이는 단지 서버 기반의 인증이 필요한 소수 가입자들을 지원하는 소규모 망 장치를 위한 프로토콜로서, 다양한 기술 기반 위에서 동시에 수백~수천의 사용자를 지원해야만 하는 통신 사업자들을 위한 AAA 서비스에는 적합하지 않다. 이러한 RADIUS 프로토콜의 한계와 문제점을 해결하기 위하여 현재 IETF에서는 Diameter 프로토콜을 제정하고 있다. Diameter 프로토콜은 다양한 엑세스망과 다양한 보안 응용서비스를 제공하며, 다중 네트워크를 대상으로 유무선 엑세스 가입자와 로밍 가입자에 대한 인증, 권한검증 그리고 과금 처리를 수행한다.
결국, 상기한 각 서비스 제공자는 개별 사용자 단말에 대한 종합적인 관리가 중요한 기술적인 문제로 대두된다. 즉 서비스 사용의 통계, 특정 서비스 사용권한, 사용시간 및 개별 서비스간 연동 등에 대한 관리 및 제어를 위해서는 TV 포털 서비스 전반에 걸친 일관된 접근이 필요하다.
개별 프로토콜 스택을 사용하여 포털을 구성하는 경우에는 단말의 경우, 서비스에 따른 개별 어플리케이션이 추가됨에 서비스를 위해서는 기존의 단말과 서버에 모두 각 서비스 어플리케이션과 해당 프로토콜 스택이 수정되어야 한다. 따라서 PP가 제공하는 서비스 풀 (pool)이 구성되어 있는 경우라고 할지라도 이에 대한 유연성 있는 대응이 곤란하다는 문제점을 안고 있다.
이러한 구성은 개별 서비스 구현에 있어서는 독립성을 유지할 수는 있으나, 시스템 구성의 면에서는 통일성을 갖지 못하고 서비스 게이트웨이의 구현에 있어서 다양한 서비스 조합에 따르는 기술적인 유연성을 제공하지 못하고 있는 실정이다.
따라서, 본 발명은 상기한 종래 기술에 따른 제반 문제점을 해결하기 위하여 안출한 것으로, 본 발명의 목적은, TV 포털 서비스를 구성하는데 있어 각 개별 서비스를 통합하기 위한 메시지 기반 프로토콜를 사용하여 사용자의 시스템 로그온에서부터 각 서비스의 사용 및 관리, 메시지 자체 서비스, 그리고 로그오프에 이르는 종합적인 서비스를 제어할 수 있는 메시지 기반 프로토콜을 이용한 TV 포탈 서비스 제공 시스템 및 그 방법을 제공함에 있다.
상기한 목적을 달성하기 위한 본 발명의 일 실시예에 따르면, 사용자의 요구에 따라 서버로부터 수신된 서비스 메시지에 따라 다수의 포탈 서비스를 수행하는 적어도 하나 이상의 서비스 어플리케이션; a) 상기 다수의 서비스 어플리케이션으로부터 발생되는 서비스 요구 메시지를 메시지 기반 프로토콜을 통한 메시지 프레임 포맷으로 변환하여 네트워크를 통해 상기 서버로 전송하고, b) 상기 서버로부터 전송되는 서비스 메시지에 대한 메시지 프레임 포맷을 수신하고, 수신된 메시지 프레임 포맷을 파싱하여 파싱된 서비스 메시지를 상기 다수의 서비스 어플리케이션중 해당 서비스 메시지에 상응하는 서비스 어플리케이션으로 제공하는 메시징 클라이언트 모듈을 포함하는 TV 포탈 서비스를 제공하기 위한 클라이언트 단말장치를 제공한다.
또한 본 발명의 다른 실시예에 따르면, a) 클라이언트 단말로부터 네트워크를 통해 전송되는 메시지 기반 프로토콜을 통한 서비스 요청 메시지 프레임을 수신하여 수신된 메시지 프레임을 파싱한 후, 파싱된 서비스 요청 메시지를 출력하고, b) 클라이언트 단말의 요구에 따라 제공되는 서비스 요구 및 처리 결과 메시지, 사용자 알림 메시지를 메시지 기반 프로토콜을 통해 메시지 프레임으로 변환한 후, 네트워크를 통해 클라이언트 단말로 전송하는 메시징 서버 모듈; 상기 메시징 서버 모듈로부터 출력되는 파싱된 서비스 요청 메시지에 따른 해당 서비스 요구 및 처리 메시지와, 사용자 알림 메시지를 생성하여 상기 메시징 서버 모듈로 제공하는 메시지 서버를 포함하는 TV 포탈 서비스를 제공하기 위한 서버 시스템을 제공한다.
또한, 본 발명의 또 다른 실시예에 따르면, 사용자의 요구에 따라 네트워크를 통해 수신된 서비스 메시지에 따라 다수의 포탈 서비스를 수행하는 적어도 하나 이상의 서비스 어플리케이션; a) 상기 다수의 서비스 어플리케이션으로부터 발생되는 서비스 요구 메시지를 메시지 기반 프로토콜을 통한 메시지 프레임 포맷으로 변환하여 네트워크를 통해 전송하고, b) 상기 네트워크를 통해 수신되는 서비스 메시지에 대한 메시지 프레임 포맷을 수신하고, 수신된 메시지 프레임 포맷을 파싱하여 파싱된 서비스 메시지를 상기 다수의 서비스 어플리케이션중 해당 서비스 메시지에 상응하는 서비스 어플리케이션으로 제공하는 메시징 클라이언트 모듈; a) 상기 메시징 클라이언트 모듈로부터 네트워크를 통해 수신되는 메시지 기반 프로토콜을 통한 서비스 메시지 프레임을 파싱한 후, 파싱된 서비스 요청 메시지를 출력하고, b) 상기 메시징 클라이언트 모듈의 요구에 따라 제공되는 서비스 요구 및 처리 결과 메시지, 사용자 알림 메시지를 메시지 기반 프로토콜을 통해 메시지 프레임으로 변환한 후, 네트워크를 통해 상기 메시징 클라이언트 모듈로 전송하는 메시징 서버 모듈; 상기 메시징 서버 모듈로부터 출력되는 파싱된 서비스 요청 메시지에 따른 해당 서비스 요구 및 처리 메시지와, 사용자 알림 메시지를 생성하여 상기 메시징 서버 모듈로 제공하는 메시지 서버를 포함하는 TV 포탈 서비스 제공 시스템을 제공한다.
상기 클라이언트 단말의 메시징 클라이언트 모듈은, 상기 다수의 서비스 어플리케이션으로부터 발생되는 서비스 요청 메시지에 상응하는 메시지 프레임을 생성하여 상기 네트워크를 통해 메시징 서버 모듈로 전송하는 메시지 프레임 발생부; 상기 메시징 서버 모듈로부터 전송되는 서비스 메시지 프레임을 파싱하여 파싱된 서비스 메시지를 해당 서비스에 상응하는 서비스 어플리케이션으로 제공하는 메시지 파싱부를 포함할 수 있으며, 상기 메시징 클라이언트 모듈로부터 파싱된 서비스 메시지를 일시 저장하였다가 해당 서비스에 상응하는 어플리케이션으로 전달하는 메시지 큐를 더 포함할 수 있다.
상기 메시징 클라이언트 모듈로부터 파싱된 메시지가 사용자의 확인이 필요한 메시지이거나, 사용자에게 알림 메시지인 경우, 해당 메시지를 해당 서비스 어플리케이션을 통해 TV 화면상에 디스플레이할 수 있도록 메시지를 일시 저장하는 FIFO 를 더 포함하고, 상기 메시지의 디스플레이는, 상기 TV 모드가 TV 시청모드인 경우, OSD상에 위젯(Widget)형태로 디스플레이하고, TV 모드가 PC 화면 모드인 경우에는 OS의 API를 이용하여 메시지 박스 또는 아이콘 형태로 디스플레이할 수 있다.
또한, 서버 시스템의 메시징 서버 모듈은, 상기 메시지 서버로부터 발생되는 서비스 요구 및 처리 메시지, 사용자 알림 메시지에 상응하는 메시지 프레임을 생성하여 생성된 메시지 프레임을 네트워크를 통해 상기 메시징 클라이언트 모듈로 전송하는 메시지 프레임 발생부; 상기 메시징 클라이언트 모듈로부터 전송되는 서비스 메시지 프레임을 파싱하여 파싱된 서비스 메시지를 상기 메시지 서버로 제공하는 메시지 파싱부를 포함할 수 있다.
또한, 본 발명의 또 다른 실시예에 따르면, 서버와 클라이언트 단말을 통해 TV 포탈 서비스 제공을 위한 서버와 클라이언트 단말간의 메시지 기반 프로토콜에 있어서, 서버와 클라이언트 단말간에 송수신되는 메시지의 특성을 구분하기 위한 Message Type 필드; TV 포탈 서비스 종류를 구분하기 위한 Service Type 필드; 서버와 클라이언트 단말간에 송수신되는 데이터 종류를 구분하기 위한 Data Type 필드; 서버와 클라이언트 단말간에 송수신되는 실제 데이터를 포함하는 Data 필드; 메시지 처리 결과를 구분하기 위한 Result Type 필드를 각각 생성하고, 생성된 각각의 필드에 해당하는 메시지를 부가하여 상기 서버와 클라이언트 단말간의 데이터 송수신을 수행할 수 있도록 한 TV 포탈 서비스 제공을 위한 서버와 클라이언트 단말간의 메시지 기반 프로토콜을 제공한다.
한편, 본 발명의 또 다른 실시예에 따르면, 사용자의 요구에 따라 다수의 서비스 어플리케이션으로부터 서비스 요구 메시지가 발생되는 경우, 발생된 적어도 하나 이상의 서비스 요구 메시지에 대한 메시지 프레임을 메시지 기반 프로토콜을 통해 생성하고, 생성된 메시지 프레임을 네트워크를 통해 서버로 전송하는 단계; 상기 서버로부터 네트워크를 통해 수신되는 사용자 요구 메시지에 대한 응답 , 처리, 알림 메시지에 대한 메시지 프레임을 수신하는 단계; 상기 수신된 메시지 프레임을 파싱하여 파싱된 서비스 메시지를 상기 다수의 서비스 어플리케이션중 해당 서비스 메시지에 상응하는 서비스 어플리케이션으로 제공하여 해당 서비스를 수행하는 단계를 포함하는 TV 포탈 서비스 제공을 위한 클라이언트 단말에서의 메시지 처리 방법을 제공한다.
또한, 본 발명의 또 다른 실시예에 따르면, 클라이언트 단말로부터 네트워크를 통해 전송되는 메시지 기반 프로토콜을 통한 서비스 요청 메시지 프레임을 수신하는 단계; 상기 수신된 메시지 프레임을 파싱하여 서비스 요청 메시지를 추출하는 단계; 상기 추출된 서비스 요청 메시지에 따라 서비스 요구에 대한 응답 및 처리 결과 메시지, 사용자 알림 메시지에 대한 메시지 프레임을 메시지 기반 프로토콜을 통해 생성하는 단계; 상기 생성된 메시지 프레임을 네트워크를 통해 클라이언트 단말로 전송하는 단계를 포함하는 TV 포탈 서비스를 제공하기 위한 서버에서의 메시지 처리 방법을 제공한다.
또한, 본 발명의 또 다른 실시예에 따르면, 사용자의 요구에 따라 클라이언트 단말의 다수 서비스 어플리케이션으로부터 서비스 요구 메시지가 발생되는 경우, 발생된 적어도 하나 이상의 서비스 요구 메시지에 대한 메시지 프레임을 메시지 기반 프로토콜을 통해 생성하고, 생성된 메시지 프레임을 네트워크를 통해 서버로 전송하는 단계; 상기 클라이언트 단말로부터 네트워크를 통해 전송되는 메시지 기반 프로토콜을 통한 서비스 요청 메시지 프레임을 수신하고, 수신된 메시지 프레임을 파싱하여 서비스 요청 메시지를 추출하는 단계; 상기 추출된 서비스 요청 메시지에 따라 서비스 요구에 대한 응답 및 처리 결과 메시지, 사용자 알림 메시지에 대한 메시지 프레임을 메시지 기반 프로토콜을 통해 생성한 후, 네트워크를 통해 클라이언트 단말로 전송하는 단계; 상기 네트워크를 통해 서버로부터 전송되는 메시지 프레임을 파싱하여 파싱된 서비스 메시지를 상기 다수의 서비스 어플리케이션중 해당 서비스 메시지에 상응하는 서비스 어플리케이션으로 제공하여 해당 서비스를 수행하는 단계를 포함하는 TV 포탈 서비스 제공 방법을 제공한다.
여기서, 상기 서버로부터 전송되는 메시지 프레임과 서버로 전송되는 메시지 프레임 포맷은 동일 메시지 기반 프로토콜을 통한 동일한 포맷 구조를 갖는다.
상기 서버로부터 전송되는 메시지 프레임과 서버로 전송되는 메시지 프레임 포맷은, 메시지의 특성을 구분하기 위한 Message Type 필드; 서비스 종류를 구분하기 위한 Service Type 필드 ; 데이터 종류를 구분하기 위한 Data Type필드 ; 전송하고자 하는 실제 데이터를 포함하는 Data 필드 ; 메시지 처리 결과를 구분하기 위한 Result Type 필드를 포함한다.
이하, 본 발명에 따른 TV 포탈 서비스 제공 시스템 및 그 방법에 대한 바람직한 실시예를 첨부한 도면을 참조하여 상세하게 살펴보기로 하자.
도 2는 본 발명에 따른 TV 포탈 서비스 제공 시스템에 대한 블록 구성을 나타낸 도면이다.
도 2에 도시된 바와 같이, TV 포탈 서비스 제공 시스템은, 클라이언트 단말(100)과, 서버로 구성될 수 있다.
서버는, 메시징 서버 모듈(310)과, 메시지 서버(300)로 구성될 수 있다.
클라이언트 단말(100)은, 메시징 클라이언트 모듈(110), 메시지 큐(120), FIFO(First In First Out)(130) 및 각 서비스에 대한 어플리케이션(140-200)으로 구성될 수 있다. 여기서, 각 서비스에 대한 어플리케이션은, DTV 어플리케이션(140), 정보 제공 서비스 어플리케이션(150), RVOD 서비스 어플리케이션(160), NVOD 서비스 어플리케이션(170), 주문배달 서비스 어플리케이션(180), 알림 서비스 어플리케이션(190) 및 EPG 서비스 어플리케이션(200)으로 구성될 수 있다.
메시지 프로토콜은 서버/클라이언트 구조로 운용되며, 메시징 서버 모듈(310)은 메시지 서버(310)에, 메시징 클라이언트 모듈(110)은 클라이언트 단말(100)에 설치된다. 여기서, 클라이언트 단말로는 셋탑박스 또는 게이트웨이가 될 수 있다.
각 서비스 어플리케이션(140 - 200)으로부터 서버에 전송할 메시지가 발생되면 IPC(Inter Process Communication)를 이용하여 메시징 클라이언트 모듈(110)로 메시지 발생 여부를 통보한다.
그러면, 메시징 클라이언트 모듈(100)은 IPC를 통해 수신되는 각 서비스 어플리케이션에서 발생된 메시지를 확인한 후, 발생된 메시지에 대한 적절한 메시지 프레임을 생성하게 된다.
이렇게 생성된 메시지 프레임은 메시지 프로토콜(400)을 통해 메시징 서버 모듈로(310) 전송된다.
메시징 서버 모듈(310)은 클라이언트 단말(100)로부터 전송되는 메시지 프레임을 분석하여 해당 메시지가 어떠한 서비스의 요청을 위한 메시지인지를 파악한 후, 그에 상응하는 서비스 요청을 메시지 서버(300)로 요구하게 되는 것이다.
메시지 서버(300)는 클라이언트 단말(100)의 서비스 요구에 따라 해당 서비스 요구 및 처리 결과 메시지를 메시징 서버 모듈(310)로 제공한다.
메시징 서버 모듈(310)은 메시지 서버(300)로부터 제공되는 메시지를 분석하여 적절한 메시지 프레임을 생성한 후, 소켓(400)을 통해 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다.
메시징 클라이언트 모듈(110)은 서버측으로부터 발생 또는 응답된 메시지가 수신되면, 메시징 클라이언트 모듈(110)내의 파서(Parser)를 통해 메시지를 분석하고 해당되는 서비스 어플리케이션으로 IPC를 통해 전송하게 되는 것이다.
따라서, 메시지를 수신한 해당 서비스 어플리케이션은 해당하는 서비스를 수행하게 되는 것이다.
메시지 큐(120)는 서버측으로부터 전송되는 서비스 발생 또는 응답 메시지가 메시징 클라이언트 모듈(110)을 통해 각 어플리케이션으로 제공되기 위해 메시징 클라이언트 모듈(110)에 의해 각 메시지 타입별 메시지 구조로 일시 저장되었다가 API를 통해 각 어플리케이션으로 제공되는 것이다.
그리고, FIFO(130)는 서버측에서 전송된 메시지중 알림 서비스와 같은 사용자의 확인이 필요한 경우 해당 메시지를 일시 저장하였다가 DTV 어플리케이션을 통해 DTV화면에 표시하게 되는 것이다. 여기서, 메시지 표시 방법으로는 TV 시청모드에서는 OSD상에 위젯(Widget)형태로, PC 화면 모드에서는 OS의 API를 이용하여 메시지 박스 또는 아이콘 형태로 표시하게 되는 것이다.
상기한 서버와 클라이언트간의 송수신되는 메시지 프레임의 포맷 구조에 대하여 첨부한 도 3 및 도 4a-d 를 통해 상세하게 설명해 보기로 하자.
도 3은 본 발명에 따른 클라이언트와 서버간에 송, 수신되는 메시지 프레임 포맷을 나타낸 도면, 도 4a는 도 3에 도시된 메시지 타입(Message Type)에 대한 데이터 포맷을 예시한 도면, 도 4b는 도 3에 도시된 서비스 타입(Service Type)에 대한 데이터 포맷을 예시한 도면, 도 4c는 도 3에 도시된 데이터 타입에 포함되는 데이터 종류(Data Type)와, 데이터(Data) 종류에 상응하는 실제 전송 데이터 포맷의 일 예를 나타낸 도면, 도 4d는 도 3에 도시된 메시지 처리 결과(Result Type)의 구분에 대한 데이터 포맷의 일예를 나타낸 도면이다.
도 3에 도시된 바와 같이, 클라이언트와 서버간에 송수신되는 메시지 프레임 포맷은 메시지 특성을 구분하기 위한 Message Type, 서비스 종류를 구분하기 위한 Service Type, 데이터 종류를 구분하기 위한 Data Type, 전송하고자 하는 실제 Data 및 메시지 처리 결과를 구분하기 위한 Result Type 필드로 구분될 수 있다.
여기서, Message Type 정보로는, 도 4a에 도시된 바와 같이, 요청(REQ), 응답(REP) 및 알림(INF)으로 구분될 수 있으며, Service Type 정보로는 도 4b에 도시된 바와 같이, 로그 인/아웃 서비스(LOG), E-MAIL 서비스(EML), 주문 서비스(ORD), 예약 서비스(RES), 알람 서비스(ALM), NVOD 서비스(NVD) 서비스로 구분될 수 있다.
또한, 서비스 종류에 대한 Data Type 및 Data는 도 4c에 도시된 바와 같이, LOG 서비스에서 데이터 종류로는 로그 온(LON:Log ON) 및 로그 오프(LOF:Log OFF)데이터가 존재하고, EML 서비스에는 미 확인 메일 건수(UMN:Unread Mail Number) 데이터가 존재한다.
또한, ORD 서비스에 포함되는 데이터로는 결제 완료(STC:Settlement Completion)), 결제 확인(STF:Settlement Comfirmation), 접수(RCP: Receipt), 접수 후 취소 요청(CAR:Cancellation Request), 접수 후 취소 확인(CAF : Cancellation Comfirmation), 접수 후 취소 처리(CAH:Cancellation Handling) 및 주문 배달(DLV : Delivery) 데이터로 구분될 수 있다.
또한, RES 서비스에 포함되는 데이터는 예약 신청(APL:Apply), 예약 접수(RCP: Receipt), 접수 후 취소 요청(CAR:Cancellation Request), 접수 후 취소 확인(CAF : Cancellation Comfirmation), 접수 후 취소 처리(CAH:Cancellation Handling) 데이터로 구분될 수 있으며, ALM 서비스에는 전체 알람(ALL:All Alarm), 미확인 메일 알람(UMA:Unread Mail Alarm), 예약 일정 알람(RSA:Reserved Schedule Alarm) 및 예약 발송 알람(RPA:Reserved Program Alarm) 데이터로 구분된다. 한편, NVD 서비스에는 채널 요청(CHR:Channel Request) 데이터가 포함된다.
그리고, 도 4d에 도시된 바와 같이, Result Type 정보로는 성공(SUC:Success)), 실패(FAL:Failure) 및 알 수 없는 정보(NUL:Null)로 구분된다.
결국, 클라이언트와 서버간의 데이터 전송 프레임 포맷은 도 4a 및 도 4d에 도시된 각 정보를 포함하는 도 3과 같은 미시지 기반 프로토콜을 통한 메시지 프레임 형태로 전송된다. 즉, 송수신되는 메시지 프레임은, Message Type, Service Type, Data Type, Data, Result Type 정보를 포함하는 것이다.
이와 같은 메시지 프레임 포맷을 이용하여 클라이언트와 서버간의 메시지 송수신 동작에 대하여 첨부한 도 5 및 도 6을 참조하여 설명해 보기로 한다.
도 5는 본 발명에 따른 클라이언트에서 메시지 수신시 동작 흐름을 나타낸 도면이고, 도 6은 본 발명에 따른 클라이언트에서 서버로 메시지 전송시 동작 흐름을 나타낸 도면이다.
먼저, 도 5를 참조하여 서버로부터 전송되는 메시지를 클라이언트에서 수신하는 동작에 대하여 살펴보자.
도 5에 도시된 바와 같이, 네트워크에 연결되어 있는 각 클라이언트 단말(100)에 전원이 인가되면, 기 정의된 전용 포트를 통해 메시지 서버(300)에 접속을 시도하고, 접속이 이루어지지 않을 경우 수초 간격으로 접속을 재 시도한다. 클라이언트 단말(100)과 메시지 서버(300)간에 접속이 이루어지면 클라이언트 단말(100)의 고유 ID와 DHCP 서버로부터 할당받은 유동 IP를 사용하여 "로그인"을 수행하고, 인증이 완료되면, 예외 경우(예를 들면, 네트워크의 이상, 서버 이상 등)가 발생하지 않는 한 계속적으로 접속을 유지하게 되는 것이다.
만약, 메시지 서버(300)로부터 메시징 모듈(310)를 통해 전송되는 메시지 프레임(예를 들면, REQORDSTF"주문번호"ㅣ"메시지"NUL: 주문 결제 확인 요청에 대한 응답메시지)이 수신되면, 메시징 클라이언트 모듈(110)의 메시지 파서(Message Parser:111)에서 수신된 메시지를 분석하여(Parsing) 메시지 큐(120)에 일시 저장한 후, IPC를 통해 해당되는 서비스 어플리케이션(140 - 200)으로 전달한다. 따라서, 메시지를 수신한 해당 어플리케이션은 해당하는 서비스를 수행하게 되는 것이다.
이때, 수신된 메시지 종류가 사용자의 확인 요청이 필요한 경우 해당 요청 메시지를 FIFO(130)에 일시 저장한 후, 클라이언트 단말(100)에 연결된 콘솔(Console)에 표시하게 되는데, 이의 표시 방법으로 TV 시청모드에서는 OSD상에 위젯(Widget)형태로, PC 화면 모드에서는 OS의 API를 이용하여 메시지 박스 또는 아이콘 형태로 표시하게 되는 것이다. 즉, DTV 어플리케이션 또는 PC 어플리케이션(140)를 통해 해당 확인 메시지를 디스플레이하게 된다.
한편, 클라이언트 단말(100)로부터 메시지 서버(300)로의 메시지 전송은 도 5에 도시된 바와 같이, 사용자의 요구에 의해 클라이언트 단말(100)의 임의의 서비스 어플리케이션(140-200)에서 메시지 서버(300)측으로 전송할 메시지가 발생되면, 발생된 메시지는 IPC를 이용하여 메시징 클라이언트 모듈(110)로 메시지 발생 여부를 통보하게 된다.
메시징 클라이언트 모듈(110)은 내부의 메시지 발생기(Message Generator:112)를 통해 서비스 어플리케이션(140-200)에서 발생한 메시지에 대한 메시지 프레임(예를 들면, REPORDSTF"가맹점코드"┃"주문번호"┃"YES"SUC)을 생성하여 메시지 프로토콜(400)통해 서버측의 메시징 서버 모듈(310)로 전송한다.
따라서, 메시징 서버 모듈(310)은 클라이언트 단말(100)로부터 메시지 프레임이 수신되면, 수신된 프레임을 분석하여 분석된 메시지를 메시지 서버(300)로 제공하여 클라이언트 단말(100)이 요구한 메시지에 대한 응답 또는 확인 메시지를 생성하게 되는 것이다. 이렇게 생성된 메시지는 도 5에 도시된 메시지 전송 흐름을 통해 클라이언트 단말(100)로 전송되게 되는 것이다.
이하, 첨부한 도면을 참조하여 각 서비스종류에 따라 클라이언트 단말(100)과 서버간의 메시지 송,수신 방법에 대하여 단계적으로 살펴보기로 하자.
도 7은 본 발명의 일 실시예에 따른 클라이언트와 서버간의 로그온/오프 메시지 흐름을 나타낸 도면이다.
먼저, 클라이언트 단말(100) 예를 들면, 셋탑박스의 전원을 온(ON)하면, 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)에서는 서버로의 로그 인을 위한 메시지 프레임을 생성한 후, 생성된 로그인 메시지 프레임(예를 들면, REQLOGON"MG코드"┃"MG 아이피"NUL)을 메시지 프로토콜을 통해 메시지 서버(300)으로 전송한다(S101).
메시지 서버(300)에서는 클라이언트 단말(100)로부터 전송되는 로그인 메시지 프레임을 분석하여 해당 클라이언트 단말(100)의 인증을 수행한 후, 인증 결과에 따라 메시징 서버 모듈(310)을 통해 로그 온 응답 메시지 프레임을 생성하여 메시지 프로토콜(400)을 통해 메시징 클라이언트 모듈(110)로 전송하게 되는 것이다.
즉, 해당 클라이언트 단말(100)의 인증이 실패되어 로그 온이 실패한 경우, 로그온 실패 응답 메시지 프레임(예를 들면, REPLOGON"MG코드"FAL)을 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송하고(S102), 해당 클라이언트 단말(100)의 인증을 통한 로그 온이 성공된 경우, 로그온 성공 응답 메시지 프레임(예를 들면, REPLOGON"MG코드"SUC)을 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S102-1).
이와 같이 클라이언트 단말(100)이 로그 온이 성공한 경우, 메시지 서버(300)는 해당 클라이언트 단말(100)에 대한 알림 정보를 확인하고, 알림 정보가 존재하는 경우 메시징 서버 모듈(310)를 통해 고객별 알림 메시지 프레임(예를 들면, INFALMALL"메시지"NUL)을 생성하여 메시지 프로토콜을 통해 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S103).
따라서, 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)에서는 서버로부터 전송되는 알림 메시지 프레임을 분석하고, 분석된 해당 알림 메시지를 알림 서비스 어플리케이션(190)으로 제공하여 해당 알림 서비스를 수행하도록 한다.
이와 같은 동작중에 사용자가 클라이언트 단말(100)의 전원을 오프한 경우, 메시징 클라이언트 모듈(110)에서는 전원 오프에 대한 메시지 프레임(예를 들면, INFLOGLOF"MG코드"NUL)을 생성하여 메시징 서버 모듈(310)로 전송한다(S104).
메시징 서버 모듈(310)은 메시징 클라이언트 모듈(110)로부터 전송되는 로그 오프 메시지 프레임을 분석한 후(Parsing), 분석된 로그 오프 메시지를 메시지 서버(300)로 전달하면, 메시지 서버(300)는 자신이 관리하는 클라이언트 접속 리스트에서 해당 클라이언트 단말(100)의 ID를 삭제한다.
결국, 도 7에 도시된 로그 온/로그 오프 서비스는, 클라이언트 단말(100)이 파워 온되는 경우, 메시징 클라이언트 모듈(100)은 서버로 접속을 시도하고, 접속이 되면, 클라이언트 단말(100)의 고유 ID를 이용하여 로드온 과정을 거침으로써, 각종 포털 서비스의 가능 여부를 서버에 통보한다.
그러나, 클라이언트 단말(100)의 파워가 오프된 경우 로그 오프 메시지를 서버측에 전송하여 서버에서 관리하는 접속 리스트에서 해당 클라이언트 단말(100)의 ID를 삭제시키도록 요청한다.
도 8은 본 발명의 일 실시예에 따른 서버에서 클라이언트로 알림 서비스에 대한 메시지 흐름을 나타낸 도면이다.
도 8에 도시된 바와 같이, 서버측(300)에서 클라이언트 단말(100)로 알림 상황, 예를 들면, E-Mail 알림, 예약 일정 알림, 예약 프로그램 알림 상황이 발생하였을 경우 메시지 서버(300)는 메시징 서버 모듈(310)로 이를 통보한다.
메시징 서버 모듈(310)은 메시지 서버(300)로부터 발생되는 알림 메시지에 대한 메시지 프레임 예를 들면, E-Mail 알림인 경우 "INFALMUMA"메시지"NUL" 메시지 프레임을 생성하고, 예약 일정 알림인 경우, INFALMRSA"메시지"NUL" 메시지 프레임을 생성하며, 예약 프로그램 알림인 경우 INFALMRPA"메시지"NUL" 메시지 프레임을 생성하여 메시지 프로토콜을 통해 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S201, S202, S203).
클라이언트 단말(100)의 메시징 클라이언트 모듈(110)에서는 서버로부터 전송되는 알림 메시지 프레임을 분석(Parsing)하여 각각의 알림 메시지를 메시지 큐(120)에 일시 저장한 후, 알림 서비스 어플리케이션(190)으로 전달하여 알림 서비스를 수행하거나, 사용자의 확인이 필요한 경우 FIFO(130)에 일시 저장한 후, 순차적으로 DTV 어플리케이션(140)으로 전달되어 DTV 화면에 디스플레이되게 된다. 이때, 디스플레이 방법으로는 상기한 바와 같이, TV 시청모드에서는 OSD상에 위젯 형태로 디스플레이하고, PC 화면 모드에서는 OS 의 API를 이용하여 메시지 박스 또는 아이콘 형태로 디스플레이한다. 이러한 알림 서비스는 EPG나 주문 배달, E-MAIL 서비스와 함께 사용될 수 있다.
도 9는 본 발명의 일 실시예에 따른 주문 서비스시 클라이언트와 서버간의 주문 접수 메시지 흐름을 나타낸 도면이다.
도 9에 도시된 바와 같이, 클라이언트 단말(100)의 주문 배달 서비스 어플리케이션(180)에서 상품을 주문하기 위한 메시지가 발생되면, 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)에서는 주문 메시지에 대한 메시지 프레임을 생성하여 메시지 프로토콜을 통해 서버측의 메시징 서버 모듈(310)로 전송한다.
메시징 서버 모듈(310)은 클라이언트 단말(100)로부터 전송된 주문 메시지 프레임을 분석한 후, 주문 메시지를 메시지 서버(300)로 전달한다. 그러면 메시지 서버(300)는 상품 주문 메시지에 따라 해당 상품을 주문하기 위한 가맹점으로 주문 요청 메시지를 전송한다.
가맹점 단말은 서버로부터 전송되는 주문 메시지에 따라 주문을 처리한 후, 주문 처리 결과 정보를 서버측으로 제공하고, 서버측은 주문 처리 결과 메시지를 클라이언트 단말(100)로 제공하게 되는 것이다.
이때, 상품 주문을 위해 클라이언트 단말(100)의 주문 배달 서비스 어플리케이션(180)으로부터 주문 결제 완료 메시지가 생성되면, 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)에서 주문 결제 완료 메시지에 대한 메시지 프레임(예를 들어, INFORDSTC"주문번호"NUL)을 생성하여 메시지 프로토콜을 통해 메시징 서버 모듈(310)로 전송한다(S301).
메시징 서버 모듈(310)은 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로부터 전송되는 메시지 프레임을 분석하여 주문 결제 완료 메시지를 메시지 서버(300)로 전달한다.
메시지 서버(300)는 메시징 서버 모듈(310)로부터 전달되는 주문 완료 메시지에 따라 주문 결제 확인 요청 메시지를 메시징 서버 모듈(310)로 전달한다.
메시징 서버 모듈(310)은 메시지 서버(300)로부터 전달되는 주문 결제 확인 요청 메시지에 대한 메시지 프레임(REQORDOSF"주문번호"┃"메시지"NUL)을 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송하게 되는 것이다(S302).
메시징 클라이언트 모듈(110)은 서버로부터 전송되는 주문 결제 확인 요청 메시지 프레임을 파싱하여 주문 결제 확인 요청 메시지를 메시지큐에 일시 저장되었다가 주문 배달 서비스 어플리케이션(180)으로 전달된다.
또한, 메시징 클라이언트 모듈(110)은 수신된 메시지 프레임을 파싱하여 해당 메시지는 사용자의 확인이 필요한 메시지이기 때문에 FIFO를 통해 DTV 어플리케이션(140)으로 전달되어 DTV에 디스플레이되게 되는 것이다.
디스플레이된 결제 확인 메시지에 따라 사용자가 결제 확인(YES)을 한 경우, 메시징 클라이언트 모듈(110)에서는 결제 확인(YES) 메시지에 대한 메시지 프레임(REPORDSTF"가맹점코드"┃"주문번호"┃"YESSUC)을 생성하여 서버측의 메시징 서버 모듈(310)로 전송한다(S303).
메시징 서버 모듈(310)은 수신된 결제 확인(YES)메시지 프레임을 파싱한 후, 결제 확인 메시지를 메시지 서버(300)로 전달하고, 메시지 서버(300)는 결제 확인(YES)메시지를 해당 가맹점으로 전송하여 주문을 처리하게 되는 것이다.
주문을 처리한 후, 가맹점 단말은 주문 처리 결과 메시지를 메시지 서버(300)로 전송하고, 메시지 서버(300)는 가맹점으로부터 전송되는 주문 처리 결과 메시지에 따른 주문 처리 알림 메시지를 생성하여 메시징 서버 모듈(310)로 전달한다.
메시징 서버 모듈(310)은 메시지 서버(300)로부터 전달되는 주문 처리 알림 메시지에 대한 메시지 프레임(INFORDRCP"주문번호"┃"메시지"NUL)을 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S304).
따라서, 메시징 클라이언트 모듈(110)은 해당 프레임을 파싱하여 파싱된 주문 처리 알림 메시지를 메시지 큐에 저장한 후, 주문 배달 서비스 어플리케이션(180)으로 전달하여 해당 서비스를 수행함과 동시에 DTV 어플리케이션(140)으로 전달되어 주문 처리 결과 메시지를 DTV에 디스플레이시켜 사용자가 주문 처리 결과를 확인할 수 있도록 한다.
그러나, 상기 S302단계에서 서버측으로부터 주문 결제 확인 요청 메시지에 대한 메시지 프레임(REQORDOSF"주문번호"┃"메시지"NUL)이 전송되어 사용자가 결제 확인(NO)을 선택한 경우, 메시징 클라이언트 모듈(1100에서는 주문 결제 확인(NO) 메시지에 대한 프레임(REPORDSTF"가맹점코드"┃"주문번호"┃"NOSUC)을 생성하여 서버측으로 전송하게 된다. 따라서, 서버측에서는 가맹점으로 결제 확인(NO)메시지를 전송하여 주문 취소 동작을 수행하게 되는 것이다.
그러면, 도 10을 참조하여 주문 접수 후 취소 서비스에 대하여 살펴보자.
도 10은 본 발명의 일 실시예에 따른 주문 서비스시 클라이언트와 서버간의 주문 접수 후 취소 메시지 흐름을 나타낸 도면이다
도 10에 도시된 바와 같이, 먼저 주문 배달 서비스 어플리케이션(180)을 통해 주문 접수 후 취소 요청 메시지가 발생되면, 메시징 클라이언트 모듈(110)에서는 주문 접수 후 취소 요청 메시지에 대한 메시지 프레임(INFORDCAR"가맹점코드"┃"주문번호"NUL)을 생성하여 서버측의 메시징 서버 모듈(310)로 전송한다.(S401).
서버측의 메시징 서버 모듈(310)에서는 클라이언트 단말(100)로부터 전송되는 메시지 프레임을 파싱하여 주문 접수 후 취소 요청 메시지를 메시지 서버(300)로 전달한다.
메시지 서버(300)는 클라이언트 단말(100)로부터 수신한 주문 접수 후 취소 요청 메시지를 해당 가맹점 단말로 전송한 후, 가맹점 단말로부터의 주문 접수 후 취소 확인 메시지가 수신되는 경우, 주문 취소 확인 알림 메시지를 발생하고, 발생된 주문 취소 확인 알림 메시지에 대한 메시지 프레임(INFORDCAF"주문번호"┃"메시지"NUL)을 메시징 서버 모듈(310)에서 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S402).
또한, 메시지 서버(300)는 가맹점 단말로부터 주문 취소 처리 메시지가 수신되면, 주문 취소 알림 메시지를 발생하여 메시징 서버 모듈(310)로 해당 메시지를 전달한다.
메시징 서버 모듈(310)은 주문 취소 알림 메시지에 대한 메시지 프레임(INFORDCAH"주문번호"┃메시지"NUL)을 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S404). 메시지 클라이언트 모듈(110)은 수신된 메시지 프레임을 파싱하여 주문 취소 처리 알림 메시지를 주문 배달 서비스 어플리케이션(180)으로 전달하여 해당 서비스를 처리하고, DTV 어플리케이션(140)으로 해당 메시지를 전달하여 사용자로 하여금 주문 취소 결과를 확인할 수 있도록 해당 메시지를 디스플레이한다.
이상은 사용자로부터 주문 접수 후 취소 요청이 있는 경우의 메시지 흐름이고, 만약, 가맹점으로부터 주문 취소 요청이 있는 경우에 대하여 살펴보자.
먼저, 가맹점 단말로부터 주문 취소 요청이 있는 경우, 메시지 서버(300)는 가맹점 단말로부터 전송된 주문 취소 요청에 대한 알림 메시지를 생성하여 메시징 서버 모듈(310)로 해당 메시지를 전달한다.
메시징 서버 모듈(310)은 메시지 서버(300)로부터 발생한 가맹점 주문 취소알림 메시지에 대한 메시지 프레임(REQORDCAF"주문번호"┃"메시지"NUL)을 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S404).
메시징 클라이언트 모듈(110)은 메시징 서버 모듈(310)로부터 전송되는 메시지 프레임을 파싱하여 주문 취소 알림 메시지를 주문 배달 서비스 어플리케이션(180)으로 전달하여 해당 서비스를 수행하고, 또한 해당 메시지를 DTV 어플리케이션(140)으로 전달하여 사용자로 하여금 주문 취소 확인 응답을 할 수 있도록 해당 메시지를 디스플레이하게 되는 것이다.
만약, 사용자가 주문 취소 확인 응답 메시지 'YES"를 선택한 경우, 메시징 클라이언트 모듈(110)에서는 주문 취소 확인 응답 메시지에 대한 메시지 프레임(REPORDCAF"가맹점코드"┃"주문번호"YESSUC)을 생성하여 메시징 서버 모듈(310)로 전송한다(S405).
메시징 서버 모듈(310)은 메시징 클라이언트 모듈(10)로 부터 전송되는 메시지 프레임을 파싱하여 해당 메시지 즉, 주문 취소 확인 응답 메시지를 가맹점 단말로 전송하여 주문 취소를 처리하도록 한다. 주문 취소가 완료되면, 가맹점 단말은 서버측으로 주문 취소 처리 결과 메시지를 전송하게 된다.
그러면, 서버측의 메시징 서버 모듈(310)은 주문 취소 확인 처리 알림 메시지에 대한 프레임(INFORDCAH"주문번호"┃"메시지"NUL)을 생성하여 메시징 클라이언트 모듈(110)로 전송하게 되는 것이다(S406).
한편, 상기 S404단계에서 가맹점으로부터의 주문 취소 요청 메시지가 수신되어 클라이언트 측으로 주문 취소 요청 메시지가 수신되는 경우, 사용자가 취소 확인 "NO"를 선택한 경우도 마찬가지로 상기한 동작과 동일한 방법으로 주문 취소 응답 메시지의 송, 수신 동작(S407, S408)이 이루어지기 때문에 그 상세 동작에 대하여 그 설명을 생략하기로 한다.
그리고, 주문이 확정되어 가맹점으로부터 주문 상품에 대한 배달 처리가 완료되었음을 알리는 메시지가 수신되는 경우, 메시징 서버 모듈(310)에서는 배달 처리 알림 메시지에 대한 메시지 프레임(INFORDDLV"주문번호"┃"메시지"NUL)을 메시징 클라이언트 모듈(110)로 전송함으로써, 주문 배달 서비스 동작이 완료되게 되는 것이다.
도 11은 본 발명의 일 실시예에 따른 예약 서비스시 클라이언트와 서버간의 예약 접수 메시지 흐름을 나타낸 도면이다.
도 11에 도시된 바와 같이, 사용자로부터 주문 예약 접수 신청이 있는 경우, 주문 배달 서비스 어플리케이션(180)에서 주문 예약 접수 신청 메시지가 발생한다.
이렇게 발생된 주문 예약 접수 신청 메시지는 메시징 클라이언트 모듈(110)로 전달되고, 메시징 클라이언트 모듈(110)에서는 상기 발생된 주문 예약 접수 신청 메시지에 대한 메시지 프레임 "INFRESAPL"가맹점코드"┃"예약번호"NUL"을 생성하여 메시지 서버 모듈(310)로 전송한다(S501).
메시지 서버 모듈(310)은 클라이언트로부터 전송된 주문 예약 접수 신청 메시지에 대한 메시지 프레임을 파싱하여 해당 주문 예약 접수 신청 메시지를 해당 가맹점으로 전송한다.
가맹점은 서버로부터 전송되는 주문 예약 접수 신청 메시지에 따라 주문 예약 접수를 수행하고, 주문 예약 접수 처리 결과 메시지를 서버측의 메시징 서버 모듈(310)로 전송한다.
서버측의 메시징 서버 모듈(310)은 가맹점으로부터 전송되는 주문 예약 접수 처리 메시지에 따라 예약 접수 처리 알림 메시지에 대한 메시지 프레임 "INFRESRCP"예약번호"┃"메시지"NUL을 클라이언트측의 메시징 클라이언트 모듈(110)로 전송한다(S502).
메시징 클라이언트 모듈(110)은 서버측으로부터 전송되는 예약 접수 처리 알림 메시지에 대한 메시지 프레임을 파싱하여 해당 메시지를 주문 배달 서비스 어플리케이션(180)으로 전달하여 해당 서비스를 수행하고, 해당 메시지를 DTV 어플리케이션(140)으로 전달하여 주문 예약 처리 알림 메시지를 디스플레이함으로써, 사용자가 주문 예약 처리 결과를 용이하게 확인할 수 있도록 한다.
이와 같이 주문 예약 접수 후 예약 접수를 취소하는 경우에 대하여 도 12를 참조하여 설명해 보기로 하자.
도 12는 본 발명의 일 실시예에 따른 예약 서비스시 클라이언트와 서버간의 예약 접수 후 취소 메시지 흐름을 나타낸 도면이다.
먼저, 주문 배달 서비스 어플리케이션(180)을 통해 예약 접수 후 취소 요청 메시지가 발생되면, 메시징 클라이언트 모듈(110)에서는 예약 접수 후 취소 요청 메시지에 대한 메시지 프레임 "INFORDCAR"가맹점코드"┃"예약번호"NUL"을 생성하여 서버측의 메시징 서버 모듈(310)로 전송한다.(S601).
서버측의 메시징 서버 모듈(310)에서는 클라이언트 단말(100)로부터 전송되는 메시지 프레임을 파싱하여 예약 접수 후 취소 요청 메시지를 메시지 서버(300)로 전달한다.
메시지 서버(300)는 클라이언트 단말(100)로부터 수신한 예약 접수 후 취소 요청 메시지를 해당 가맹점 단말로 전송한 후, 가맹점 단말로부터의 예약 접수 후 취소 확인 메시지가 수신되는 경우, 예약 취소 확인 알림 메시지를 발생하고, 발생된 예약 취소 확인 알림 메시지에 대한 메시지 프레임 INFORDCAF"예약번호"┃"메시지"NUL"을 메시징 서버 모듈(310)에서 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S602).
또한, 메시지 서버(300)는 가맹점 단말로부터 예약 취소 처리 메시지가 수신되면, 예약 취소 처리 알림 메시지를 발생하여 메시징 서버 모듈(310)로 해당 메시지를 전달한다.
메시징 서버 모듈(310)은 예약 취소 처리 알림 메시지에 대한 메시지 프레임 "INFORDCAH"예약번호"┃메시지"NUL을 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S603). 메시지 클라이언트 모듈(110)은 수신된 메시지 프레임을 파싱하여 예약 취소 처리 알림 메시지를 주문 배달 서비스 어플리케이션(180)으로 전달하여 해당 서비스를 처리하고, DTV 어플리케이션(140)으로 해당 메시지를 전달하여 사용자로 하여금 예약 취소 결과를 확인할 수 있도록 해당 메시지를 디스플레이한다.
이상은 사용자로부터 예약 접수 후 취소 요청이 있는 경우의 메시지 흐름이고, 만약, 가맹점으로부터 예약 접수 취소 요청이 있는 경우에 대하여 살펴보자.
먼저, 가맹점 단말로부터 예약 취소 요청이 있는 경우, 메시지 서버(300)는 가맹점 단말로부터 전송된 예약 취소 요청에 대한 알림 메시지를 생성하여 메시징 서버 모듈(310)로 해당 메시지를 전달한다.
메시징 서버 모듈(310)은 메시지 서버(300)로부터 발생한 가맹점 예약 취소 알림 메시지에 대한 메시지 프레임(REQORDCAF"예약번호"┃"메시지"NUL)을 생성하여 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송한다(S604).
메시징 클라이언트 모듈(110)은 메시징 서버 모듈(310)로부터 전송되는 메시지 프레임을 파싱하여 예약 취소 알림 메시지를 주문 배달 서비스 어플리케이션(180)으로 전달하여 해당 서비스를 수행하고, 또한 해당 메시지를 DTV 어플리케이션(140)으로 전달하여 사용자로 하여금 예약 취소 확인 응답을 할 수 있도록 해당 메시지를 디스플레이하게 되는 것이다.
만약, 사용자가 예약 취소 확인 응답 메시지 'YES"를 선택한 경우, 메시징 클라이언트 모듈(110)에서는 예약 취소 확인 응답 메시지에 대한 메시지 프레임(REPORDCAF"가맹점코드"┃"예약번호"YESSUC)을 생성하여 메시징 서버 모듈(310)로 전송한다(S605).
메시징 서버 모듈(310)은 메시징 클라이언트 모듈(10)로 부터 전송되는 메시지 프레임을 파싱하여 해당 메시지 즉, 예약 취소 확인 응답 메시지를 가맹점 단말로 전송하여 예약 취소를 처리하도록 한다. 예약 취소가 완료되면, 가맹점 단말은 서버측으로 예약 취소 처리 결과 메시지를 전송하게 된다.
그러면, 서버측의 메시징 서버 모듈(310)은 예약 취소 확인 처리 알림 메시지에 대한 프레임(INFORDCAH"예약번호"┃"메시지"NUL)을 생성하여 메시징 클라이언트 모듈(110)로 전송하게 되는 것이다(S606).
한편, 상기 S604단계에서 가맹점으로부터의 예약 취소 요청 메시지가 수신되어 클라이언트 측으로 주문 취소 요청 메시지가 수신되는 경우, 사용자가 취소 확인 "NO"를 선택한 경우도 마찬가지로 상기한 동작과 동일한 방법으로 주문 취소 응답 메시지의 송,수신 동작(S607, S608)이 이루어지기 때문에 그 상세 동작에 대하여 그 설명을 생략하기로 한다.
이하, 도 13을 참조하여 EPG 방송 예약시 메시지 흐름에 대하여 살펴보자.
도 13은 본 발명의 일 실시예에 따른 EPG 서비스시 클라이언트와 서버간의 EPG 방송 예약 메시지 흐름을 나타낸 도면이다.
도 13에 도시된 바와 같이, 사용자로부터 EPG 서비스 어플리케이션(200)을 통한 EPG 화면을 통해 방송 예약 신청을 하는 경우, 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)에서는 EPG 서비스 어플리케이션(200)을 통해 발생한 방송 예약 메시지에 대한 메시지 프레임 "INFRESCHR"예약방송번호"NUL"을 생성하여 서버측의 메시징 서버 모듈(310)로 전송한다(S701).
메시징 서버 모듈(310)은 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로부터 전송되는 메시지 프레임을 파싱하여 메시지 서버(300)로 전달한다.
메시지 서버(300)는 메시징 서버 모듈(310)로부터 전송되는 방송 예약 메시지를 이용하여 사용자가 요구한 채널에 대한 방송예약을 수행하게되는 것이다.
또한, 메시지 서버(300)는 사용자가 선택한 방송 예약 프로그램의 방송 예약 시간을 체크하여 해당 시간이 되는 경우 예약 프로그램 알림 메시지를 생성하여 메시징 서버 모듈(310)로 전달한다.
메시징 서버 모듈(310)은 메시지 서버(300)로부터 제공되는 예약 프로그램 알림 메시지에 대한 메시지 프레임 INFALMRPA"메시지"NUL을 생성하여 메시징 클라이언트 모듈(110)로 전송한다(S702).
메시징 클라이언트 모듈(110)은 서버측의 메시징 서버 모듈(310)로부터 전송되는 방송 예약 프로그램 알림 메시지에 대한 메시지 프레임을 파싱하여 해당 메시지를 EPG 서비스 어플리케이션(200)으로 전송하여 해당 서비스 즉, 예약 프로그램이 방송되는 채널로 채널 변경등의 기능을 수행하도록 하고, 해당 서비스를 또한 DTV 어플리케이션(140)으로 전달하여 사용자가 확인할 수 있도록 예약 프로그램 알림 메시지를 디스플레이한다.
즉, EPG 서비스는 웹 기반으로 제공되는데, 알림 서비스와 연계하여 방송 예약이 가능해진다. EPG 화면에서 예약하고 싶은 방송을 선택하면, 예약 메시지 포맷에 맞추어 서버에게 이를 전송한다.
서버는 방송 예약 상황을 기록해 두었다가 해당 시간이 되면 알림 서비스를 통해 단말에게 이를 알려준다. 단말은 예약 알림 메시지를 받으면 해당 채널로 자동 채널 변경을 시도하거나, UI 로 알려줄 수 있는 것이다.
메시지 프로토콜을 통한 VOD 서비스의 동작에 대하여 첨부한 도 14를 참조하여 살펴보자.
먼저, 사용자가 VOD 서비스 어플리케이션(160, 170)을 통해 시청하고자 하는 VOD채널을 요청하면, 메시징 클라이언트 모듈(110)에서는 VOD 채널 요청에 대한 메시지 프레임(REQNVDCHR"채널번호"NUL")을 생성하여 메시징 서버 모듈(310)로 전송한다(S801).
메시징 서버 모듈(310)은 메시징 클라이언트 모듈(110)로부터 전송되는 VOD 채널 요청에 대한 메시지 프레임 파싱하여 VOD 채널 요청 메시지를 메시지 서버(300)로 전달한다.
메시지 서버(300)는 메시징 서버 모듈(310)로부터 전달되는 VOD 채널 요청 메시지를 이용하여 해당 채널이 클라이언트 단말(100)에서 사용 가능한 채널인지 채널 인증을 수행한다.
만약 채널 인증이 성공 또는 실패된 경우 즉, 해당 채널이 클라이언트 단말(100)에서 사용 가능한 채널 또는 가능하지 않는 채널인 경우, 채널 인증 응답 메시지에 대한 메시지 프레임을 클라이언트 단말(100)로 전송하게 되는데, 만약 해당 VOD 서비스가 유니캐스트(Unicast)인 경우 그리고 해당 채널의 인증이 성공되는 경우에는 메시징 서버 모듈(310)에서는 REPNVDCHR"채널번호"SUC 메시지 프레임을, 반대로 VOD 채널 인증에 실패한 경우에는 REPNVDCHR"채널번호"FAL 메시지 프레임을 클라이언드 단말(100)의 메시징 클라이언트 모듈(110)로 전송하게 된다(S802, S803).
메시징 클라이언트 모듈(110)은 서버로부터 전송되는 응답 메시지에 대한 프레임을 파서를 통해 파싱한 후, 해당 메시지를 VOD 서비스 어플리케이션으로 전달하여 사용자가 이를 확인할 수 있도록 디스플레이한다.
그러나, VOD 서비스가 멀티캐스트(Multicast)인 경우에는 VOD 채널 요청에 대한 응답 메시지 프레임으로 채널 인증이 성공된 경우, REPNVDCHR"채널번호"┃"멀티캐스팅 IP"SUC 메시지 프레임을 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송하고(S804), 채널 인증이 실패한 경우, REPNVDCHR"채널번호"┃"NULFAL프레임을 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)로 전송하는 것이다(S805).
결국, 클라이언트 단말(100)에서 메시징 클라이언트 모듈(110)을 통해 시청하고자 하는 VOD 채널을 서버에 요청하면, 서버에서는 요청된 채널이 해당 단말에서 사용 가능한 채널인지 확인하여 응답 메세지를 보내준다. 이때, VOD 서비스가 유니캐스트인 경우, 클라이언트 단말은 사용 가능한 채널이라는 응답을 받으면 메시징 클라이언트 모듈(110)의 파서(Parser)를 통해 이를 전달받은 VOD 어플리케이션이 스트림을 파싱하여 보여준다.
그러나, VOD 서비스가 멀티캐스트인 경우, 서버는 응답 메시지 안에 요청한 채널에 해당하는 멀티캐스트 그룹 IP(Multicast Group IP)를 넣어서 클라이언트 단말(100)에 전송한다.
따라서, 클라이언트 단말(100)의 메시징 클라이언트 모듈(110)의 파서는 이 IP를 VOD 어플리케이션에게 넘겨주고, VOD 어플리케이션은 이 IP를 가지고 해당 멀티캐스트 그룹에 조인(JOIN)하는 메시지를 보내 스트림을 수신하고 파싱하여 보여주는 것이다.
결국, 본 발명에 따른 TV 포탈 서비스 제공장치 및 그 방법은, 서버와 클라이언트 단말간에 이용 가능한 여러 서비스를 구현하기 위해 필요한 제어 메시지를 정의한 것으로, 댁내에서 단말 한대로 HD/SD 급 방송 수신은 물론, 본 발명을 이용해 주문배달/VOD/모니터링/정보제공 등의 서비스를 이용할 수 있도록 여러 가지 서비스를 일괄적으로 관리하고 처리하기 위해 도 3, 4에 도시된 바와 같은 하나의 서비스 프레임워크와 메시지 규격을 제안한 것이다.
상기한 바와 같은 본 발명에 따른 TV 포탈 서비스 제공장치 및 그 방법은, TV 포털 서비스에 있어서 일관성 있는 메시지 기반의 프레임워크를 제공함으로서 다양한 서비스 항목에 대한 관리와 제어가 가능하도록 한다. 또한 개별 서비스 사이의 연동을 위한 도구를 제공함으로서 기존에는 구현이 곤란하던 새로운 어플리케이션의 구현이 가능하다. 이는 단말뿐 만 아니라 서버의 구현에 있어서도 기술적인 효율성은 물론이고 TV 포털 서비스에 대한 API를 규격화함으로서 융통성 있는 서비스 구현이 가능한 것이다.
도 1은 종래 기술에 따른 TV 포탈 서비스 제공 시스템의 블록 구성을 나타낸 도면.
도 2는 본 발명에 따른 TV 포탈 서비스 제공 시스템에 대한 블록 구성을 나타낸 도면.
도 3은 본 발명에 따른 클라이언트와 서버간에 송, 수신되는 메시지 프레임 포맷을 나타낸 도면.
도 4a는 도 3에 도시된 메시지 타입(Message Type)에 대한 데이터 포맷을 예시한 도면.
도 4b는 도 3에 도시된 서비스 타입(Service Type)에 대한 데이터 포맷을 예시한 도면.
도 4c는 도 3에 도시된 데이터 타입에 포함되는 데이터 종류(Data Type)와, 데이터(Data) 종류에 상응하는 실제 전송 데이터 포맷의 일 예를 나타낸 도면.
도 4d는 도 3에 도시된 메시지 처리 결과(Result Type)의 구분에 대한 데이터 포맷의 일 예를 나타낸 도면.
도 5는 본 발명에 따른 클라이언트에서 메시지 수신시 동작 흐름을 나타낸 도면.
도 6은 본 발명에 따른 클라이언트에서 서버로 메시지 전송시 동작 흐름을 나타낸 도면.
도 7은 본 발명의 일 실시예에 따른 클라이언트와 서버간의 로그온/오프 메시지 흐름을 나타낸 도면.
도 8은 본 발명의 일 실시예에 따른 서버에서 클라이언트로 알림 서비스에 대한 메시지 흐름을 나타낸 도면.
도 9는 본 발명의 일 실시예에 따른 주문 서비스시 클라이언트와 서버간의 주문 접수 메시지 흐름을 나타낸 도면.
도 10은 본 발명의 일 실시예에 따른 주문 서비스시 클라이언트와 서버간의 주문 접수 후 취소 메시지 흐름을 나타낸 도면.
도 11은 본 발명의 일 실시예에 따른 예약 서비스시 클라이언트와 서버간의 예약 접수 메시지 흐름을 나타낸 도면.
도 12는 본 발명의 일 실시예에 따른 예약 서비스시 클라이언트와 서버간의 예약 접수 후 취소 메시지 흐름을 나타낸 도면.
도 13은 본 발명의 일 실시예에 따른 EPG 서비스시 클라이언트와 서버간의 EPG 방송 예약 메시지 흐름을 나타낸 도면.
도 14는 본 발명의 일 실시예에 따른 VOD서비스시 클라이언트와 서버간의 VOD 서비스 메시지 흐름을 나타낸 도면.
*도면의 주요 부분에 대한 부호의 설명*
100 : 클라이언트 단말 110 : 메시징 클라이언트 모듈
120 : 메시지 큐 130 : FIFO
140 : DTV 어플리케이션 150 : 정보 제공 서비스 어플리케이션
160 : RVOD 서비스 어플리케이션 170 : NVOD 서비스 어플리케이션
180 : 주문배달 서비스 어플리케이션 190 : 알림 서비스 어플리케이션
200 : EPG 서비스 어플리케이션 300 : 메시지 서버
310 : 메시징 서버 모듈

Claims (24)

  1. TV 포탈 서비스 제공 시스템에 있어서,
    사용자의 요구에 따라 네트워크를 통해 수신된 서비스 메시지에 따라 다수의 포탈 서비스를 수행하는 적어도 하나 이상의 서비스 어플리케이션;
    a) 상기 다수의 서비스 어플리케이션으로부터 발생되는 서비스 요구 메시지를 메시지 기반 프로토콜을 통한 메시지 프레임 포맷으로 변환하여 네트워크를 통해 전송하고,
    b) 상기 네트워크를 통해 수신되는 서비스 메시지에 대한 메시지 프레임 포맷을 수신하고, 수신된 메시지 프레임 포맷을 파싱하여 파싱된 서비스 메시지를 상기 다수의 서비스 어플리케이션중 해당 서비스 메시지에 상응하는 서비스 어플리케이션으로 제공하는 메시징 클라이언트 모듈;
    a) 상기 메시징 클라이언트 모듈로부터 네트워크를 통해 수신되는 메시지 기반 프로토콜을 통한 서비스 메시지 프레임을 파싱한 후, 파싱된 서비스 요청 메시지를 출력하고,
    b) 상기 메시징 클라이언트 모듈의 요구에 따라 제공되는 서비스 요구 및 처리 결과 메시지, 사용자 알림 메시지를 메시지 기반 프로토콜을 통해 메시지 프레임으로 변환한 후, 네트워크를 통해 상기 메시징 클라이언트 모듈로 전송하는 메시징 서버 모듈;
    상기 메시징 서버 모듈로부터 출력되는 파싱된 서비스 요청 메시지에 따른 해당 서비스 요구 및 처리 메시지와, 사용자 알림 메시지를 생성하여 상기 메시징 서버 모듈로 제공하는 메시지 서버를 포함하는 TV 포탈 서비스 제공 시스템.
  2. 제1항에 있어서,
    상기 적어도 하나 이상의 서비스 어플리케이션은,
    주문배달 서비스 어플리케이션, VOD 서비스 어플리케이션, 정보 제공 서비스 어플리케이션, 알림 서비스 어플리케이션, EPG 서비스 어플리케이션, DTV 서비스 어플리케이션 중 적어도 하나 이상을 포함하는 TV 포탈 서비스를 제공 시스템.
  3. 제1항에 있어서,
    상기 메시지 기반 프로토콜을 통한 메시지 프레임 포맷은,
    서버와 클라이언트 단말간에 송수신되는 메시지의 특성을 구분하기 위한 Message Type 필드;
    TV 포탈 서비스 종류를 구분하기 위한 Service Type 필드;
    서버와 클라이언트 단말간에 송수신되는 데이터 종류를 구분하기 위한 Data Type 필드;
    서버와 클라이언트 단말간에 송수신되는 실제 데이터를 포함하는 Data 필드;
    메시지 처리 결과를 구분하기 위한 Result Type 필드 포함하는 TV 포탈 서비스 제공 시스템.
  4. 제3항에 있어서,
    상기 메시지의 특성을 구분하기 위한 Message Type 정보는,
    요청정보(REQ), 응답정보(REP) 및 알림정보(INF)중 적어도 하나의 정보를 포함하는 TV 포탈 서비스를 제공 시스템.
  5. 제3항에 있어서,
    상기 서비스 종류를 구분하기 위한 Service Type 정보는,
    로그 인/아웃 서비스(LOG) 정보, E-MAIL 서비스(EML) 정보, 주문 서비스(ORD) 정보, 예약 서비스(RES) 정보, 알람 서비스(ALM) 정보, VOD 서비스(NVD) 서비스 정보중 적어도 하나의 서비스 정보를 포함하는 TV 포탈 서비스 제공 시스템.
  6. 제3항에 있어서,
    상기 데이터 종류를 구분하기 위한 Data Type 정보는,
    로그 데이터(LOG), 알람 데이터(ALM), 주문 데이터(ORD), 예약 데이터(RES), 이메일 데이터(EML), VOD 데이터(NVD)중 적어도 하나의 데이터를 포함하는 TV 포탈 서비스 제공 시스템.
  7. 제3항 또는 제6항에 있어서,
    상기 Data Type 정보 중 LOG에 상응하는 실제 Data는,
    로그 온(LON:Log ON) 및 로그 오프(LOF:Log OFF)데이터를 포함하는 TV 포탈 서비스 제공 시스템.
  8. 제3항 또는 제6항에 있어서,
    상기 Data Type 정보 중 EML Data Type의 Data는,
    미 확인 메일 건수(UMN:Unread Mail Number) 데이터를 포함하는 TV 포탈 서비스 제공 시스템.
  9. 제3항 또는 제6항에 있어서,
    상기 Data Type 정보 중 ORD Data Type의 Data는,
    결제 완료(STC:Settlement Completion), 결제 확인(STF:Settlement Comfirmation), 접수(RCP: Receipt), 접수 후 취소 요청(CAR:Cancellation Request), 접수 후 취소 확인(CAF : Cancellation Comfirmation), 접수 후 취소 처리(CAH:Cancellation Handling), 주문 배달(DLV : Delivery) 데이터 중 적어도 하나의 정보를 포함하는 TV 포탈 서비스 제공 시스템.
  10. 제3항 또는 제6항에 있어서,
    상기 Data Type 정보 중 RES Data Type의 Data는,
    예약 신청(APL:Apply), 예약 접수(RCP: Receipt), 접수 후 취소 요청(CAR:Cancellation Request), 접수 후 취소 확인(CAF : Cancellation Comfirmation), 접수 후 취소 처리(CAH:Cancellation Handling) 데이터 중 적어도 하나의 데이터를 포함하는 TV 포탈 서비스 제공 시스템.
  11. 제3항 또는 제6항에 있어서,
    상기 Data Type 정보 중 ALM Data Type의 Data는,
    전체 알람(ALL:All Alarm), 미확인 메일 알람(UMA:Unread Mail Alarm), 예약 일정 알람(RSA:Reserved Schedule Alarm), 예약 발송 알람(RPA:Reserved Program Alarm) 데이터 중 적어도 하나의 데이터를 포함하는 TV 포탈 서비스 제공 시스템.
  12. 제3항 또는 제6항에 있어서,
    상기 Data Type 정보 중 NVD Data Type의 Data는,
    채널 요청(CHR:Channel Request) 데이터를 포함하는 TV 포탈 서비스 제공 시스템.
  13. 제3항에 있어서,
    상기 Result Type 정보는,
    성공(SUC:Success), 실패(FAL:Failure), 알 수 없는 정보(NUL:Null)를 포함하는 TV 포탈 서비스 제공 시스템.
  14. 제1항에 있어서,
    상기 메시징 클라이언트 모듈은,
    상기 다수의 서비스 어플리케이션으로부터 발생되는 서비스 요청 메시지에 상응하는 메시지 프레임을 생성하여 상기 네트워크를 통해 메시징 서버 모듈로 전송하는 메시지 프레임 발생부;
    상기 메시징 서버 모듈로부터 전송되는 서비스 메시지 프레임을 파싱하여 파싱된 서비스 메시지를 해당 서비스에 상응하는 서비스 어플리케이션으로 제공하는 메시지 파싱부를 포함하는 TV 포탈 서비스 제공 시스템.
  15. 제1항에 있어서,
    상기 메시징 클라이언트로부터 파싱된 서비스 메시지를 일시 저장하였다가 해당 서비스에 상응하는 어플리케이션으로 전달하는 메시지 큐를 더 포함하는 TV 포탈 서비스 제공 시스템.
  16. 제1항에 있어서,
    상기 메시징 클라이언트 모듈로부터 파싱된 메시지가 사용자의 확인이 필요한 메시지이거나, 사용자에게 알림 메시지인 경우, 해당 메시지를 해당 서비스 어플리케이션을 통해 TV 화면상에 디스플레이할 수 있도록 메시지를 일시 저장하는 FIFO 를 더 포함하는 TV 포탈 서비스 제공 시스템.
  17. 제16항에 있어서,
    상기 메시지의 디스플레이는, 상기 TV 모드가 TV 시청모드인 경우, OSD상에 위젯(Widget)형태로 디스플레이하고, TV 모드가 PC 화면 모드인 경우에는 OS의 API를 이용하여 메시지 박스 또는 아이콘 형태로 디스플레이하는 TV 포탈 서비스 제공 시스템.
  18. 제1항에 있어서,
    상기 메시징 서버 모듈은,
    상기 메시지 서버로부터 발생되는 서비스 요구 및 처리 메시지, 사용자 알림 메시지에 상응하는 메시지 프레임을 생성하여 생성된 메시지 프레임을 네트워크를 통해 상기 메시징 클라이언트 모듈로 전송하는 메시지 프레임 발생부;
    상기 메시징 클라이언트 모듈로부터 전송되는 서비스 메시지 프레임을 파싱하여 파싱된 서비스 메시지를 상기 메시지 서버로 제공하는 메시지 파싱부를 포함하는 TV 포탈 서비스 제공 시스템.
  19. TV 포탈 서비스 제공 방법에 있어서,
    사용자의 요구에 따라 클라이언트 단말의 다수 서비스 어플리케이션으로부터 서비스 요구 메시지가 발생되는 경우, 발생된 적어도 하나 이상의 서비스 요구 메시지에 대한 메시지 프레임을 메시지 기반 프로토콜을 통해 생성하고, 생성된 메시지 프레임을 네트워크를 통해 서버로 전송하는 단계;
    상기 클라이언트 단말로부터 네트워크를 통해 전송되는 메시지 기반 프로토콜을 통한 서비스 요청 메시지 프레임을 수신하고, 수신된 수신된 메시지 프레임을 파싱하여 서비스 요청 메시지를 추출하는 단계;
    상기 추출된 서비스 요청 메시지에 따라 서비스 요구에 대한 응답 및 처리 결과 메시지, 사용자 알림 메시지에 대한 메시지 프레임을 메시지 기반 프로토콜을 통해 생성한 후, 네트워크를 통해 클라이언트 단말로 전송하는 단계;
    상기 네트워크를 통해 서버로부터 전송되는 메시지 프레임을 파싱하여 파싱된 서비스 메시지를 상기 다수의 서비스 어플리케이션중 해당 서비스 메시지에 상응하는 서비스 어플리케이션으로 제공하여 해당 서비스를 수행하는 단계를 포함하는 TV 포탈 서비스 제공 방법.
  20. 제19항에 있어서,
    상기 서버로부터 전송되는 메시지 프레임과 서버로 전송되는 메시지 프레임 포맷은 동일 메시지 기반 프로토콜을 통한 동일한 포맷 구조를 갖는 TV 포탈 서비스 제공 방법.
  21. 제19항에 있어서,
    상기 서버로부터 전송되는 메시지 프레임과 서버로 전송되는 메시지 프레임 포맷은,
    서버와 클라이언트 단말간에 송수신되는 메시지의 특성을 구분하기 위한 Message Type 필드;
    TV 포탈 서비스 종류를 구분하기 위한 Service Type 필드;
    서버와 클라이언트 단말간에 송수신되는 데이터 종류를 구분하기 위한 Data Type 필드;
    서버와 클라이언트 단말간에 송수신되는 실제 데이터를 포함하는 Data 필드;
    메시지 처리 결과를 구분하기 위한 Result Type 필드를 포함하는 TV 포탈 서비스 제공 방법.
  22. 제19항에 있어서,
    상기 해당 서비스를 수행하는 단계에서,
    상기 파싱된 서비스 메시지를 메시지 큐에 일시 저장하였다가 해당 서비스에 상응하는 어플리케이션으로 전달하는 TV 포탈 서비스 제공 방법.
  23. 제19항에 있어서,
    상기 해당 서비스를 수행하는 단계에서,
    상기 파싱된 메시지가 사용자의 확인이 필요한 메시지이거나, 사용자에게 알림 메시지인 경우, 해당 메시지를 해당 서비스 어플리케이션을 통해 TV 화면상에 디스플레이할 수 있도록 메시지를 FIFO에 일시 저장하였다가 순차적으로 해당 어플리케이션으로 전달하는 TV 포탈 서비스 제공방법.
  24. 제23항에 있어서,
    상기 메시지의 디스플레이는, 상기 TV 모드가 TV 시청모드인 경우, OSD상에 위젯(Widget)형태로 디스플레이하고, TV 모드가 PC 화면 모드인 경우에는 OS의 API를 이용하여 메시지 박스 또는 아이콘 형태로 디스플레이하는 TV 포탈 서비스 제공방법.
KR10-2003-0045451A 2003-07-04 2003-07-04 메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공시스템 및 그 방법 KR100501332B1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR10-2003-0045451A KR100501332B1 (ko) 2003-07-04 2003-07-04 메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공시스템 및 그 방법
US10/871,275 US20050005306A1 (en) 2003-07-04 2004-06-21 Television portal services system and method using message-based protocol
CNB2004100621785A CN1312893C (zh) 2003-07-04 2004-07-02 使用基于消息的协议的电视入口服务系统及方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR10-2003-0045451A KR100501332B1 (ko) 2003-07-04 2003-07-04 메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공시스템 및 그 방법

Publications (2)

Publication Number Publication Date
KR20050003921A KR20050003921A (ko) 2005-01-12
KR100501332B1 true KR100501332B1 (ko) 2005-07-18

Family

ID=33550298

Family Applications (1)

Application Number Title Priority Date Filing Date
KR10-2003-0045451A KR100501332B1 (ko) 2003-07-04 2003-07-04 메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공시스템 및 그 방법

Country Status (3)

Country Link
US (1) US20050005306A1 (ko)
KR (1) KR100501332B1 (ko)
CN (1) CN1312893C (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100627180B1 (ko) 2004-08-13 2006-09-25 손호석 셋탑박스에서 양방향 tv 포털 서비스를 위한 통합 리모콘 제어 시스템 및 방법
KR100703717B1 (ko) 2004-12-06 2007-04-06 한국전자통신연구원 프로세서간 통신을 이용한 프로그램간 연동 방법

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005022344A2 (en) * 2003-08-29 2005-03-10 Opentv, Inc. Targeted content broadcast and reception system
ES2470976T3 (es) 2003-09-12 2014-06-24 Open Tv, Inc. Método y sistema para controlar la grabación y reproducción de aplicaciones interactivas
US7716363B1 (en) * 2004-02-10 2010-05-11 Cisco Technology, Inc. Method and apparatus of providing zero configuration single source multicasting reporting
US20060200578A1 (en) * 2005-02-23 2006-09-07 Sherer W P Avalanche control for video on demand session setup
US7774402B2 (en) 2005-06-29 2010-08-10 Visa U.S.A. Adaptive gateway for switching transactions and data on unreliable networks using context-based rules
CN100514967C (zh) 2005-07-12 2009-07-15 华为技术有限公司 一种呼叫中心平台及其获取接口调用信息的方法
KR100755845B1 (ko) * 2005-12-29 2007-09-07 엘지전자 주식회사 프로그램 안내 정보 서비스를 위한 방법 및 이동형 방송 수신기
CN100403799C (zh) * 2006-04-11 2008-07-16 华为技术有限公司 一种实现iptv应用控制的系统和方法
WO2008019595A1 (fr) * 2006-08-11 2008-02-21 Shanda Computer (Shanghai) Co., Ltd. Système d'internet par la télévision et de divertissement interactif, procédé correspondant, boîtier d'ordinateur et boîtier de télévision
US8683510B1 (en) 2007-03-26 2014-03-25 At&T Mobility Ii Llc IP-based television messaging services
KR101128523B1 (ko) 2007-04-25 2012-03-27 삼성전자주식회사 사용자 일정 관리 장치 및 방법
US8863151B2 (en) * 2007-08-15 2014-10-14 Red Hat, Inc. Securing inter-process communication
KR100946824B1 (ko) * 2007-10-31 2010-03-09 (주)피엑스디 디지털 방송 위젯 시스템 및 위젯 출력 방법
CN102196307B (zh) * 2010-03-18 2013-01-23 北京国微集成技术有限公司 对象传递装置和对象传递方法
US8543508B2 (en) 2010-07-09 2013-09-24 Visa International Service Association Gateway abstraction layer
US8970668B2 (en) * 2010-11-29 2015-03-03 Verizon Patent And Licensing Inc. High bandwidth streaming to media player
CN102262672A (zh) * 2011-08-09 2011-11-30 鸿富锦精密工业（深圳）有限公司 电子装置及其信息交互方法
WO2014071222A1 (en) * 2012-11-02 2014-05-08 Iteris, Inc. Universal interface for communication of traffic signal priority between mass transit vehicles and intersection signal controllers for priority request and control
USD766322S1 (en) * 2014-07-29 2016-09-13 Secugraph Inc. Display screen with icon
KR101632835B1 (ko) 2015-04-14 2016-06-23 엘에스산전 주식회사 Plc 시스템의 프로토콜 자동 설정 방법
CN106685915A (zh) * 2016-10-28 2017-05-17 努比亚技术有限公司 移动终端与服务器安全通信的方法、服务器及移动终端

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5373288A (en) * 1992-10-23 1994-12-13 At&T Corp. Initializing terminals in a signal distribution system
US6771316B1 (en) * 1996-11-01 2004-08-03 Jerry Iggulden Method and apparatus for selectively altering a televised video signal in real-time
PL186325B1 (pl) * 1997-03-21 2003-12-31 Canal Plus Sa Układ warunkowego dostępu do systemu telewizyjnego
US6049539A (en) * 1997-09-15 2000-04-11 Worldgate Communications, Inc. Access system and method for providing interactive access to an information source through a networked distribution system
US20040123324A1 (en) * 2000-03-07 2004-06-24 Sazzad Sharif M. Methods and apparatus for providing video services such as Video-on-Demand, news and advertising services
US7017175B2 (en) * 2001-02-02 2006-03-21 Opentv, Inc. Digital television application protocol for interactive television
GB2377336B (en) * 2001-07-04 2005-07-20 Digital Video Networks Ltd A system and method for transmission of data
GB0121776D0 (en) * 2001-09-07 2001-10-31 Pace Micro Tech Plc Television system and method of use thereof

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100627180B1 (ko) 2004-08-13 2006-09-25 손호석 셋탑박스에서 양방향 tv 포털 서비스를 위한 통합 리모콘 제어 시스템 및 방법
KR100703717B1 (ko) 2004-12-06 2007-04-06 한국전자통신연구원 프로세서간 통신을 이용한 프로그램간 연동 방법

Also Published As

Publication number Publication date
CN1578277A (zh) 2005-02-09
CN1312893C (zh) 2007-04-25
KR20050003921A (ko) 2005-01-12
US20050005306A1 (en) 2005-01-06

Similar Documents

Publication Publication Date Title
KR100501332B1 (ko) 메시지 기반 프로토콜을 이용한 티브이 포탈 서비스 제공시스템 및 그 방법
US8542682B2 (en) Systems and methods for media distribution
US6973667B2 (en) Method and system for providing time-shifted delivery of live media programs
US8181209B2 (en) Methods and apparatus for providing video on demand and network PVR functions using IP streaming
US11457257B2 (en) Systems and methods for generating concatenated transport streams from adaptive media streams
US8843599B2 (en) Storing and synchronizing media device information
EP1919113A2 (en) Time-shifted broadcast delivery
US8817095B2 (en) Locally originated IPTV programming
US8885823B2 (en) Method and apparatus for delivering encrypted on-demand content without use of an application defined protocol
US20100153995A1 (en) Resuming a selected viewing channel
US8601115B2 (en) Providing state information and remote command execution in a managed media device
US20110321062A1 (en) Capturing events from and providing targeted messages to a digital media device
US8555312B2 (en) Multimedia channel sharing
JP2004504765A (ja) 安全なパケット・ベースのデータ・ブロードキャスティング・アーキテクチャ
KR20040007409A (ko) 멀티미디어 다중방송 콘텐츠의 자격 통제 메시지 및 자격관리 메시지 배포 방법
US20100146529A1 (en) Incident reporting in a multimedia content distribution network
US8239898B2 (en) Multimedia channel sharing across access network boundaries
US10425390B2 (en) Media storage and playback of encrypted content
US20120011557A1 (en) Bandwidth and server resource savings through use of legacy client capability in a remote user interface system
US8315506B2 (en) Home telepresence with content insertion
US9232284B2 (en) Method and system for sharing resources for setup boxes (STB) in a home network
EP1596598A2 (en) System for the transmission and reception of radio or television data
US20080141324A1 (en) Iptv supplementary service control system and method
US9538259B1 (en) Messaging between set top box and head end systems
US20110016222A1 (en) Network element for enabling a user of an iptv system to obtain media stream from a surveillance system and corresponding method

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20080604

Year of fee payment: 4

LAPS Lapse due to unpaid annual fee