KR20100102231A - 통보 시스템, 통보 에이전트 및 복수의 에이전트로부터 사용자 장치에 통보들을 전송하는 방법 - Google Patents

Abstract

네트워크를 통해, 적어도 2개의 상이한 프로토콜을 사용하여 복수의 소스로부터 사용자 장치(UE)에 통보를 제공하는 통보 시스템은 UE에 대해 지정되는 복수의 통보 소스로부터 통보를 수신하도록 구성되는 통보 에이전트를 포함하는데, 이 통보 에이전트는 각 소스의 프로토콜에 따라 복수의 프로토콜을 사용하여 통보를 수신하고 하나의 프로토콜을 사용하여 UE와 통보를 통신하여 UE 외부의 통보의 핵심 처리를 이동시키는 수단을 포함한다.

Description

통보 시스템, 통보 에이전트 및 복수의 에이전트로부터 사용자 장치에 통보들을 전송하는 방법{CONVERGED INFORMATION SYSTEMS}

본 특허 출원은 통합 정보 시스템 분야에 관한 것이다. 특히 많은 상이한 프로토콜을 사용하여 데이터 타입을 수신하고 통신하기 위해 사용자 장치(user equipment : UE)가 사용되는 시스템 분야에 관한 것이다.

IPTV(Internet Protocol TV)의 사용자들은 많은 상이한 정보 통신 기술을 사용하길 원할 수 있다. 예를 들어 SMS, MMS, IMS(IP multimedia sub-system), IMS-IM, VOIP call, RSS, 이메일, calendar function, MSN이나 Google Talk와 같은 인스턴트 메시징 서비스(instant messaging service), 인터넷 통보(internet notification)와 많은 다른 유형의 서비스들이 있다. 이들은 일반적으로 모두 상이한 프로토콜을 포함한다. 오퍼레이터들은 IPTV 사용자들에게 위의 통보 소스(notification source)들의 일부나 전부로부터의 통보와 동시에 동작하는 기능성을 제공하는데 점차 관심을 기울이고 있다. 즉, 사용자가 특정의 프로토콜을 사용하는 요청이나 전송을 알아냈을 때, 사용자들은 통보를 받고 이를 어떻게 처리할지를 사용자에게 선택할 수 있도록 하는 기능성이 사용자 장치에 제공된다. 이런 애플리케이션들은 일반적으로 ‘통합 서비스’라고 지칭되고 이들은 기존의 IPTV(방송 TV, 주문형 컨텐츠나 주문형 비디오 VOD와 같은)에 추가되는 가치 있는 서비스이다.

유사하게 사용자들은 이상적으로 그들의 라이프스타일에 적응 할 수 있는 멀티미디어 서비스와 통신 경험을 선호한다. 예를 들어, 사용자들은 TV 스크린에서 높은 우선권을 가지는 이메일, ‘친구 목록(buddy list)’에 등록된 사람으로부터의 SMS 메시지나 호출에 대한 통보를 받고 적합한 응답 동작을 수행하길 원한다.

사용자 장치에 그러한 통합 서비스를 제공하는 현존하는 방법들은 통보 소스부터 사용자 장치까지의 게이트웨이를 사용하고 개개의 통신 타입(SMS, 이메일, VOIP, 달력 기능성 등)에 특정 통보 처리 로직을 포함하는 별도의 통보 클라이언트가 사용자 장치에 제공되도록 요구한다. 예를 들어, IMS VOIP : IP 멀티미디어서브시스템 인터넷전화(session initiation protocol : 접속 설정 프로토콜) 요청을 IP서브시스템에 전달하기 위해 IMS VOIP 통보를 IPTV 사용자 장치에 전달하는 데에 게이트웨이가 사용된다. 이 게이트웨이는 요청 통보를 SIP를 사용하는 그 IPTV 사용자 장치에 전달할 수 있고 사용자 장치의 내장 클라이언트(built in client on the UE)가 응답 동작을 제공한다. 통상, 가능한 옵션은 음성 메시지 녹음 장치로의 재지정(redirect to voicemail), 발신자에 대한 더 많은 정보를 요청, 거부(deny), 응답(answer) 등을 포함한다.

또 다른 예는 이메일 통보이다. 입력 이메일들의 통보들은 POP3, IMAP, SMTP 등과 같은 이메일 프로토콜에 의해 직접적으로 또는 게이트웨이를 거쳐 사용자 장치의 사용자에게 전달되고 사용자 장치의 상이한 내장(in built) 클라이언트는 응답 동작들을 제공한다. 대개 답장, 본문 읽기, 무시 등이다. 응답에 따라 클라이언트는 POP3, IMAP 등을 사용하여 이메일의 텍스트를 인출한다.

이런 기존의 접근법이 가지는 주된 문제는 그것이 각 통보 소스에 대한 특정 프로토콜과 통보 처리 로직(notification processing logic)을 포함하는 특수화된 사용자 장치 클라이언트(specialised UE client)를 요구한다는 것이다. 이런 클라이언트는 사용자 장치 자체에서 제공되어야만 한다. 이것은 다음과 같은 한계를 가진다.

새로운 사용자 장치 클라이언트는 새로운 통보 소스(예를 들어, 이메일, SMS)을 지원하도록 요구되고 이것은 매체(medium)의 고축적 전개(higher scale deployment)에 비용-효율적(cost efficient)이지 않으며,

새로운 통보 소스들을 지원하기 위해 사용자 장치에 새로운 통보 처리 로직이 요구되고,

사용자 장치에의 부가적인 처리 로직은 초과 처리 전력과 하드웨어를 요구하며, 이것은 비용을 증가시키고

다중 통보 클라이언트와 다른 애플리케이션들 사이의 조정(arbitration) 또한 비용을 증가시킨다. 그리고

그래픽 유저 인터페이스(graphic user interface)가 커스텀화될 때, 각각의 클라이언트의 커스텀화가 요구되고, 이것은 다시 비용을 증가시킨다.

또한, 기존의 사용자 장치에 새로운 서비스를 추가하는 것도 어렵다.

그러한 통보 방법(notification method)은 ES 20239 10-3 'Open Service Access'(OSA) 'parlay X-web services Part 3 : Call Notification'에서 표준화되어 있다. 여기서, 클라이언트 애플리케이션은 특정한 통보 소스를 등록해야 하고 통보 처리 로직을 구현해야만 한다.

본 발명은 다중 통보 소스로부터 통보와 응답 동작을 사용자 장치 장치(a UE device)에 구현하는 향상된 방법을 제공하기 위한 시도에서, 그리고 새로운 통보 소스와 타입의 새롭고 간편한 추가(new easy addition)를 가능케 하는 시스템을 제공하기 위한 시도로부터 시작되었다.

본 발명에 따르면, 적어도 두 개의 상이한 프로토콜을 사용하는 복수의 소스로부터 네트워크를 통해 사용자 장치에 통보를 제공하는 통보 시스템이 제공되며, 이것은 전술한 사용자를 위해 의도된 복수의 통보 소스로부터 통보를 수신하기 위해 배치된 통보 에이전트와, 개개의 소스들의 프로토콜에 따른 복수의 프로토콜을 사용하는 통보들을 수신하고 공통된 프로토콜을 사용하는 사용자 장치에 통보를 제공하기 위한 수단을 포함하는 통보 에이전트로 구성된다.

통보 에이전트는 가급적 추가적인 데이터를 하나 이상의 파라미터를 나타내는 통보로 패키지한다(package). 그 파라미터들에는 하나 또는 그 이상의 메타데이터, 응답 동작, 허용된 기능이 있을 수 있는데, 다른 말로 '{NAMF}'('{notification, action, metadata, function}' 패키지라고 지칭된다.

{NAMF}는 별도로, 함께 또는 다른 방법으로 통보 에이전트로부터 클라이언트인 사용자 장치로 전달될 수 있다. 이들은 선택에 따라 IPTV AS를 경유하여 전송된다.

이 시스템은 추가적으로 초기 처리를 위한 플러그 가능한 처리 로직을 포함한다.

또 다른 측면으로서, 본 발명은 상이한 본래의 프로토콜을 가지는 복수의 에이전트들로부터 네트워킹을 통하여 사용자 장치에 통보를 전송하는 방법을 추가적으로 제공하는데, 이 방법은 그들 본래의 프로토콜을 사용하는 복수의 에이전트로부터 통보를 수신하고 이 통보들을 단일한 프로토콜을 사용하는 사용자 장치에 전달하기에 적합한 통보 에이전트를 제공하는 단계를 포함한다.

사용자 장치의 통보 클라이언트는 통보가 수신되었다는 사실을 사용자에게 표시하고, 만약 적합하다면 사용자가 동작을 선택할 수 있도록 일정 범위의 가능한 동작들을 사용자에게 보여주도록 배치될(arranged) 수 있다. 만약 적합하다면, 사용자는 후속의 처리를 위해 통보 동작 에이전트(notification action agent)에게 선택된 동작을 돌려보낼 수 있다.

본 발명은 특정 프로토콜을 각각 사용하는 복수의 소스들(sources)로부터 통보를 받고, 공통 프로토콜을 사용하는 사용자 장치에 통보를 제공하기 위한 수단을 포함하는 통보 에이전트를 추가적으로 제공한다.

본 발명은 하나 이상의 새로운 특징들이나 본 명세서에서 공개 및/또는 청구된 특징들의 조합을 포함하는 통보 시스템이나 에이전트를 추가적으로 제공한다.

본 발명의 실시예들은 첨부된 도면과 관련하여 단지 예로서 설명될 것이다.
도 1은 통보 시스템을 도시하고 있다.
도 2는 데이터 흐름을 도시하고 있다.
도 3은 데이터 패키지(data package)를 도시하고 있다.
도 4는 사용자 장치에의 스크린 표시를 도시하고 있다.
도 5는 또 다른 스크린 표시를 도시하고 있다.
도 6은 최초 스크린 표시를 도시하고 있다.

이제 도 1을 참조하면, 다양한 소스들로부터 통보를 받을 수 있도록 사용자 장치(1)를 인에이블시키기 위해 일반화된 시스템이 보인다. STB는 물론 디스플레이와 일체화될 수 있음에도 불구하고 이 경우에서 사용자 장치(1)는 디스플레이(3)에 연결된 셋톱박스(2)를 포함하는 IPTV 장치이다. 이와 달리, 사용자 장치는 휴대 전화, PDA, 소형 단말기(handheld terminal) 또는 그 외의 장치가 될 수 있다. 관련 장치로 통신이 어드레싱 될 수 있도록 특정 사용자가 언제든지 그의 이동 장치나 셋톱 박스나 다른 장치를 사용하고 있는지를 표시할 수 있는 (본 발명의 일부를 이루지 않는) 수단이 제공될 수 있다.

이것은 어느 적절한 통신 채널(이를테면, 폐쇄 IP 네트워크, 개방 인터넷, 또는 GPRS, UMTS나 그 외의 무선 또는 고정 라인 채널을 사용하는 무선 채널)에 의해, 또는 이들의 조합, 또는 네트워크상 적절한 위치에서 제공되는 ‘미들웨어’를 원격 조종하는 그 외의 수단에 의해 연결되고, 이것은 통보 에이전트(4)를 포함한다. 통보 에이전트(4)는 일련의 게이트웨이로부터 데이터를 수신할 수도 전송할 수도 있고, 이메일(5), MMS/SMS 서비스(6), 인터넷(7), VOIP 서비스(8), IMS VOIP 서비스(9)와 많은 그 외 타입의 서비스(10)을 포함하는 다양한 통신 서비스로 전송할 수도 있다. 이들은 많은 상이한 프로토콜과 잘 통신할 수 있다. 예를 들어, IMS VOIP와 다른 데이터 소스들이 유사하거나 그 외의 프로토콜을 사용할 수 있듯이, 이메일은 SMTP 또는 POP3, IMAP, SMPP를 사용하여 통신되고, 인터넷과의 통신은 HTTP/XML을 사용하고, VOIP는 SIP(접속 설정 프로토콜)을 사용할 수 있다.

통보 에이전트(4)는 다중 통보 소스(5에서 10)로부터 통보를 수집/수신하도록 배치되어(arranged) 있다. 확장성을 위해 다중의 에이전트가 사용될 수 있다는 점을 유의하자. 예를 들어, 입력되는 접속 설정 프로토콜(incoming SIP)을 위한 수동 청취 모드(passive listening mode)나 인터넷 업데이트를 위한 능동 풀 모드(active pull mode), 그 외의 다른 기능과 같은 상이한 모드들이 사용될 수 있다. 수신 통보들(incoming notifications)은 개개의 표준 인터페이스를 거쳐 다양한 통보 서비스들에 수신된다. 이것은 도 1의 단계 A에서 볼 수 있다. 통보 에이전트(4)는 통보를 처리하고 그것을 단일한 통보 포맷/프로토콜로 바꾸는 기능성을 포함한다. 또한 통보 에이전트(4)는 메타데이터와 응답 동작, 프리젠테이션 특성, 허용된 기능들을 패키지하고 이들은 ‘{통보, 동작, 메타데이터, 기능}’ 즉 {NAMF} 패키지라 지칭된다. 통상적인 패키지는 패키지(5)가 통보(N)과 가능한 동작(A)의 범위, 메타데이터(M), 기능(F)을 포함하고 이 패키지가 사용자 장치(1)로 전송되는 도 3에서 개략적으로 볼 수 있다. 추가적으로는 이하에서 기술될 것이다.

도 1은 외부의, 플러그 가능한 로직 장치인 다수의 통보 처리 로직 유닛(6)을 보여준다. 통보 에이전트는 초기 처리를 위해 다중 정보 소스(multiple information source) (5 내지 10)으로부터 수신된 통보들을 통보 프로젝트 로직 장치(6)로 전달하고 이것은 도 1의 단계 B로서 도시되어 있다.

일단 통보 에이전트가 {NAMF}를 패키지하면, 단계 C에서 이들은 사용자 장치로 보내진다. 이들은 도 3에 나타난 바와 같이 패키지로서 함께 전달될 수도, 또는 별개로 전달될 수도 있고 실제의 전송 구현/프로토콜(actual transport implementation/protocol)이 적절한 것일 수도 있다. 사용자 장치는 통보와 다양한 옵션/동작(options/actions)을 디스플레이(3)를 통해 사용자에게 보여준다. 선택에 따라 통보는 IPTV AS를 경유하여 전달될 수도 있다. 이용 가능한 다양한 옵션들이 사용자에게 표시되고 그 중 하나를 선택할 수 있다. 사용자가 원하는 동작을 선택한 후에 사용자 장치는 선택된 동작을 통보 에이전트에게 다시 전달한다.[단계 D] 통보 에이전트는 그 후 선택된 동작을 처리하거나 그것을 관련된 플러그 가능한 통보 처리 로직(6)에 전달한다. 선택에 따라 새로운 통보와 동작 선택이 다시 사용자 장치로 전달되도록 요청된다. 그러면 통보 에이전트는 새로운 NAMF를 생성하고 이것을 STB에 전달한다. 추가적인 반복이 필요하면 단계 B와 C, D가 문자 그대로 반복된다.

만약 원래의 통보 소스(5부터 10)에 응답이 필요하다면, 통보 에이전트(4)는 그 통보가 원래 수신되었던 표준(본래의) 통보 서비스 인터페이스를 거쳐 응답을 전달한다.[단계 E]

도 2는 데이터의 흐름을 개략적으로 도시한다. 다양한 에이전트(이 경우 이메일(5)과 인터넷(7), VOIP(8), 세 개의 에이전트가 오직 예시로서 보인다)로부터의 통보가 통보 에이전트(4)에 수신된다. 이것은(통보 에이전트를 가리킴) 통보들을 단일 통보 포맷/신호 프로토콜로 전환한다. 이것은(통보 에이전트를 가리킴) {NAMF} 패키지를 생성하고 이를 사용자 장치(1)로 전송한다. 그러면 사용자 장치(1)는 통보와 어떤 사용가능한 옵션들을 표시하고 사용자는 옵션을 선택한다. 그러면 이것은 단계 D에서 통보 에이전트(4)로 다시 전송된다. 만약 원래의 에이전트에 추가적인 통신 데이터 전송이 요구되면 상기의 과정(this)이 발생하고, 그렇지 않으면 통보 에이전트는 어쩌면 통보 처리 로직(6)(도 2에서 명료하게 보이진 않지만)을 경유하여 단계 C2에서 추가적인 {NAMF}를 사용자 장치로 다시 전송할 수 있다. 통보 에이전트(4)와 사용자 장치 사이의 모든 통신은 단일한 프로토콜, 단일한 통신 수단을 통해 수행되고, 그러므로 통보 처리 로직은 이제 더 이상 사용자 장치 자체에서는 요구되지 않는다. 그것은 모두 통보 에이전트(4)에서 수행된다. 이런 이유로 다중의 통보 소스들이 지원될 수 있다. 사실은, 사용자 장치에 어떤 업그레이드나 수정 없이, 최근 생겨난 새로운 통보 소스들(예컨대 이메일, SMS 등 다른 소스들)을 포함하기 위해 가상의 무제한 확장이 미들웨어 기반의 통보 에이전트(4)에 추가될 수 있다.

보다 일반적인 용어로는, 미들웨어에 있는 공통의 통보 에이전트(NA4)는 다중의 통보 소스들로부터 통보를 수집하고 수신한다. 이 에이전트는 통보를 수신하고 처리하고 통보들을 통일된 방식으로 메타데이터이나 응답 동작, 프리젠테이션 특성, 허용된 기능, 그 외 파라미터들, 기능성과 함께 패키지하고 이 패키지는 단일한 통보 채널을 통해 사용자 장치로 전송된다. 그러므로 사용자 장치는 패키지 프리젠테이션 특성을 사용하여 소스(5부터 10)의 본성과는 독립적인 사용자 장치의 통일된 룩 앤 필(look and feel)을 사용하여 통보들을 사용자에게 보여준다.

전송된 실제의 {NAMF} 패키지가 예시로서 도 3에서 보인다. 기본적인 통보뿐만 아니라, 기술된 대로 다양한 다른 정보가 패키지 된다. 이것(다양한 다른 정보를 가리킴)은 동작(A)을 포함할 수 있다. 예를 들어, 통보가 이메일에 관련된다면, ‘통보’는 오직 이메일의 제목을 포함한다. ‘동작’은 읽기(READ), 저장(SAVE), 본문 가져오기(GET BODY), 무시(IGNORE) 등과 같이 사용자가 취할 수 있는 다양한 동작을 포함한다. ‘기능’은 사용자 장치(예를 들어 셋톱박스)에 스크린 상의 위치와 표시 주기, 크기/색, 선택 가능한 가상 버튼 등을 포함하여 대상과 다양한 동작을 어떻게 표시할지를 명령한다. 다양한 유형의 ‘메타데이터’ 또한 포함될 수 있고 다른 기능이나 데이터도 물론 포함될 수 있다. 기능(F)은 예시로서 디스플레이에 버튼의 모양과 같은 다양한 옵션들을 어떻게 표시할 것일지 뿐만 아니라 디스플레이에 그러한 버튼들을 물리적으로 어디에 배치할 것인가를 포함하고, 또한 만약 그 때에 사용자가 IPTV나 다른 컨텐츠를 보고 있다면 이미 표시되어 있는 그 컨텐츠를 어떻게 처리할 것인지도 포함한다. 예를 들어, 통보와 다양한 기능들이 기존의 디스플레이의 위에 오버레이 될 것인지 아니면 기존의 디스플레이 대신에 표시될 것인지, 또는 비디오 컨텐츠의 경우 통보가 표시되는 동안 기존의 디스플레이가 계속될 수 있도록 허용되어야 하는지, 또는 빈 화면이 표시되거나 화면이 정지되어야 하는지에 관한 정보가 포함된다. 많은 다른 유형의 정보가 전송될 수 있다. 또한 그 정보는 통보가 더 이상 스크린 상에 표시되지 않을 때 비디오 컨텐츠가 그것이 멈추었던 곳부터(즉 일시정지 기능) 자동으로 재시작될 수 있도록 비디오 컨텐츠를 자동적으로 저장하라는 명령을 포함할 수 있다.

전송될 수 있는 다른 요소들은 예컨대 우선순위 정보와 관련된다. 예를 들어, 이것은 만약 어떤 메시지가 사용자의 친구 목록에 있는 사람이나 다른 이유로서 큰 우선순위가 부여된 사람으로부터 비롯된 것이라면, 그 메시지는 더 눈에 잘 띄도록 표시되거나 어쩌면 이미 표시되어 있는 다른 메시지보다 우선적으로 표시되거나 다른 프리젠테이션 특성을 바꿀지도 모른다는 것을 의미한다. 메시지가 사용자의 자녀로부터 와서 사용자가 그 메시지를 매우 긴급하게 보아야 할 필요가 있을 지도 모른다. 많은 다른 유형의 로직이 자명하다.

도 4 내지 6은 디스플레이의 예시를 보여준다. 도 4에서는 비디오(10)가 디스플레이(3)에 표시되고 있다. 처리 로직과 통보와 함께 받은 명령에 적용을 받아 통보가 발생하면 비디오 영상 위에 오버레이 되는 방식으로 화면에 표시된다. 이 경우 정보는 이메일 형태이고 이메일의 제목이 첫 번째 박스(11)에 표시된다. 다수의 동작 버튼들(12a와 12b, 12c)도 비디오 영상 위를 덮으며 표시된다. 12a는 본문 가져오기, 12b는 삭제, 12c는 저장 등으로 표기될 수 있다. 물론 3개 이상 또는 이하의 버튼이 있을 수 있다. 사용자는 키보드나 다른 입력 수단을 사용하여 원격 제어로 1번 버튼(예컨대)을 선택하거나 터치스크린을 사용하여 직접 터치함으로써, 또는 원격 제어 포인터를 사용하거나 다른 수단으로 12a 버튼을 선택할 수 있다.

만약 사용자가 ‘12a 대상(subject) 가져오기’를 선택하면 이 메시지는 통보 에이전트에게 그리고 다시 이메일 소스(5)(도 1)로 다시 전달된다. 그러면 대상(subject)이 입수되어 다시 사용자 장치로 전송된다. 도 6은 본문(또는 전체 메시지)이 박스 13에 또 다른 옵션들과 함께 표시되는 후속 디스플레이를 도시하고 있다. 이들은 예컨대 박스 14a에 ‘삭제’와 박스 14b에 ‘답장’으로 표기될 수 있다. 물론 많은 다른 옵션들도 가능하고 두 개 이상 또는 이하의 대응 버튼이 있을 수도 있다.

도 4 내지 6까지의 실시예들은 물론 개략적이고 메시지가 이메일인 경우의 전형적인 사례이다. 다른 타입의 통보와 표시는 다른 타입의 데이터에 적합할 것이다.

예를 들어 컨텐츠 공유의 시나리오가 있을 수 있다. 이 경우 새로운 사용자 제작 콘텐츠가 업로드 에이전트(10)에 의해 업로드된 것을 통보 에이전트(4)가 감지한다. 에이전트는 ‘Fred로부터 새로운 컨텐츠를 받았습니다’라는 취지의 통보를 컨텐츠 발신자의 ‘친구들(buddies)’에게 생성한다. 이는 도 5의 제목 상자(11)에 들어가는 통보일 수 있다. 이때 가능한 동작은 ‘기술 읽기(READ DESCRIPTION)', '나중에 보기’, ‘바로 보기’, ‘무시하기’, ‘Fred에게 문자 보내기’가 될 수 있다. 사용자 장치는 ‘Fred로부터 새로운 컨텐츠를 받았습니다’라는 통보를 디스플레이 상의 표준 룩 앤 필에 표시하고 다양한 동작들을 오버레이 한다. 동작의 위치 지정은 통보로부터 받은 패키지에 의해 결정되거나 사용자 장치 상에 사전 결정된 규칙들에 따라 결정된다.

사용자가 ‘나중에 보기’를 선택한다면 사용자 장치는 그 동작을 통보 에이전트에게 전달한다. 그러면 에이전트는 나중에 보기 위해 컨텐츠를 캐쉬에 저장하는 컨텐츠 이동을 개시한다. 그러면 ‘오후 5시에 보기 위해 컨텐츠가 준비될 것입니다. 동작 없음.’이라는 새로운 통보가 생성될 수 있다.

전술한 바와 같이, 사용자 장치에는 특정 컨텐츠 지각 클라이언트나 어떤 처리 로직도 필요치 않다.

또 다른 시나리오는 IPTV 시스템에 수신된 이메일과 관련된다. 통보 에이전트(4)는 새로운 이메일이 수신된 것을 감지한다. 에이전트는 IPTV 사용자 장치에 ‘메일을 받았습니다’라는 통보를 발생시킨다. 동작은 ‘읽기’, ‘답장’, ‘무시’가 있다. 사용자 장치는 통보를 표준 룩 앤 필에 표시하고 다양한 동작들을 오버레이 한다. 사용자는 이 예에서 ‘읽기’를 선택한다. 사용자 장치는 이 동작을 통보 에이전트에게 전달한다. 그러면 에이전트는 IMAP, POP3와 같은 적절한 이메일 프로토콜을 사용하여 이메일 본문을 인출한다. 그러면 메일의 본문과 새로운 동작들의 세트를 포함한 통보가 발생한다. 이런 순환이 계속된다. 또 다시 이 예에서도 사용자 장치에 어떤 특정 이메일 처리(POP3, IMAP, SMTP 등의) 클라이언트나 어떤 처리 로직도 요구되지 않는다.

또 다른 시나리오는 IPTV SMS 통보와 관련된다. 전술한 시나리오와 유사한 데이터 흐름이 발생하지만, ‘읽기’ 동작은 통보 프록시(notification proxy)로부터 SMPP(short message peer-to-peer protocol)로서 SMS 서버로 트리거(trigger)된다. 다시, 어떤 SMPP 클라이언트나 어떤 처리 로직도 사용자 장치 자체에는 요구되지 않는다.

많은 변화가 가능하다. 예를 들어 낮은 우선순위를 가지는 메시지가 수신되면 사용자가 보고 있는 TV 프로그램(예컨대 축구 게임)이 끝난 후에 이것이 전달되도록 통보 프리젠테이션(notification presentation)이 적용된다. 또는 그 축구 게임에 오버레이 되지만 눈에 덜 띄는 방식으로 표시된다.

본 발명은 사용자 장치로부터 통보 처리 로직을 제거한다. 이것은 공통되고 비용 효율적인 방법을 통해 다중 통보 소스가 지원될 수 있도록 한다. 그것은 또한 사용자 장치 업그레이드나 변경에 따라 미들웨어(즉, 서버나 기반구조 수준)에 추가되는 새로운 통보 소스들을 포함하는 사실상 무제한의 확장을 허용한다. 이것은 대단히 비용효율적이고 또한 ‘픽 앤 믹스(pick and mix)' 통합 서비스가 오퍼레이터 요구에 따라 가능하도록 만들 수 있다.

사용자 장치는 다중 통보 클라이언트와 다른 애플리케이션들 사이의 어떤 조정을 갖도록 요구되지 않는다. 또한 사용자 장치는 모든 통보에 대해 공통된 룩 앤 필을 사용할 수 있기 때문에 각 클라이언트에게 어떤 그래픽 사용자 인터페이스 커스터마이제이션(GUI customization)도 요구되지 않는다.

그러므로 통보의 핵심 처리(core processing of notifications)는 사용자 장치로부터 옮겨지고 대신에 통보 에이전트(그리고/또는 외장 플러그 가능한 로직에 의해)에서 수행된다. 사용자는 단지 응답을 선택할 필요가 있을 뿐이다.

Claims (17)

1. 적어도 두 개의 상이한 프로토콜을 사용하는 복수의 소스로부터 네트워크를 통해 사용자 장치(UE)에 통보를 제공하는 통보 시스템으로서,
   상기 복수의 통보 소스로부터 사용자로의 통보를 수신하도록 구성되는 통보 에이전트(a notification agent)를 포함하되,
   상기 통보 에이전트는, 개개의 소스들의 프로토콜에 따른 복수의 프로토콜을 사용하여 통보를 수신하고, 공통 프로토콜을 사용하여 상기 사용자 장치에 통보를 제공하기 위한 수단을 포함하는
   통보 시스템.
   
2. 제 1 항에 있어서,
   상기 통보 에이전트는, 각 통보와 함께 기본 통보 데이터를 초과하는 추가적인 정보를 상기 사용자 장치에 제공하는
   통보 시스템.
   
3. 제 2 항에 있어서,
   상기 사용자 장치에 제공되는 상기 정보는, 하나 이상의 통보와 동작, 메타데이터, 기능({NAMF} 데이터)을 포함하는
   통보 시스템.
   
4. 제 2 항에 있어서,
   상기 데이터는, 사용자가 상기 통보에 응답하여 선택하기 원하는 하나 이상의 동작을 나타내는 데이터를 포함하는
   통보 시스템.
   
5. 제 4 항에 있어서,
   상기 데이터는, 상기 통보의 위치지정 및/또는 디스플레이를 나타내는 데이터를 포함하는
   통보 시스템.
   
6. 제 1 항에 있어서,
   사용자 장치로부터의 응답이 상기 공통 프로토콜을 통해 상기 통보 에이전트로 전송되게 하고, 적합한 경우에는, 개개의 프로토콜을 통해 상기 통보 에이전트로부터 상기 원래의 소스로 전송되도록 허용하는 수단을 포함하는
   통보 시스템.
   
7. 제 1 항에 있어서,
   상기 통보 에이전트로부터 상기 사용자 장치에 제공된 상기 데이터는, 상기 원래의 에이전트로부터의 상기 통보의 상기 프로토콜 및 룩 앤 필(look and feel)과 무관하게, 공통 룩 앤 필을 사용하여 표시되는 포맷인
   통보 시스템.
   
8. 제 1 항에 있어서,
   플러그 가능한 로직 요소(pluggable logic elements)들을 포함하는
   통보 시스템.
   
9. 제 1 항에 있어서,
   통보 프리젠테이션 및/또는 타이밍은 조건 및/또는 상태에 따라 조정되는
   통보 시스템.
   
10. 제 1 항에 있어서,
    통보 처리가 상기 통보 에이전트에서 내부적으로 및/또는 상기 통보 에이전트로 '플러그 가능한' 로직을 처리함으로써 수행되는
    통보 시스템.
    
11. 각각 특정 프로토콜을 사용하여 복수의 소스들로부터 통보들을 수신하고 공통 프로토콜을 사용하여 사용자 장치에 통보를 제공하기 위한 수단을 포함하는
    통보 에이전트.
    
12. 제 11 항에 있어서,
    상기 통보 에이전트는, {NAMF} 데이터를 상기 사용자 장치에 제공하는
    통보 에이전트.
    
13. 상이한 본래의 프로토콜을 가지는 복수의 에이전트로부터의 통보를 네트워크를 통해 사용자 장치에 전송하는 방법으로서,
    복수의 에이전트들로부터 이들 본래의 프로토콜을 사용하여 통보를 수신하고 이들 통보를 하나의 프로토콜을 사용하여 상기 사용자 장치에 전달하도록 구성되는 통보 에이전트를 제공하는 단계를 포함하는
    복수의 에이전트로부터 사용자 장치에 통보들을 전송하는 방법.
    
14. 제 13 항에 있어서,
    상기 통보 에이전트는, 상기 통보와 함께 추가 데이터를 상기 사용자 장치에 전송하는
    복수의 에이전트로부터 사용자 장치에 통보들을 전송하는 방법.
    
15. 제 14 항에 있어서,
    상기 추가 데이터는, 하나 이상의 {NAMF} 데이터를 포함하는
    복수의 에이전트로부터 사용자 장치에 통보들을 전송하는 방법.
    
16. 제 15 항에 있어서,
    상기 통보 에이전트로부터 상기 사용자 장치로 제공된 상기 데이터는, 상기 원래의 에이전트로부터의 상기 통보의 상기 프로토콜 및 룩 앤 필과 무관하게, 공통 룩 앤 필을 사용하여 디스플레이되는 포맷인
    복수의 에이전트로부터 사용자 장치에 통보들을 전송하는 방법.
    
17. 제 13 항에 있어서,
    상기 통보는, 상기 하나의 프로토콜을 사용하여, 사용자 장치에 의해 수신되어 상기 사용자가 선택하고 응답할 수 있는 일련의 선택 가능한 동작과 함께 상기 UE의 상기 사용자에게 디스플레이되며,
    복수의 에이전트의 본래의 프로토콜을 사용하여 이들과 통신하는 상기 통보 에이전트에 디스플레이되어, 추가 데이터를 입수하거나 상기 사용자 선택에 의해 결정되는 응답을 제공하는
    복수의 에이전트로부터 사용자 장치에 통보들을 전송하는 방법.

Images