KR20180100394A

KR20180100394A - 이벤트 등록 및 통보

Info

Publication number: KR20180100394A
Application number: KR1020187022383A
Authority: KR
Inventors: 사친 지. 데시판데
Original assignee: 샤프 가부시키가이샤
Priority date: 2016-02-04
Filing date: 2017-02-02
Publication date: 2018-09-10
Also published as: MX2018009105A; CA3011896A1; KR102160585B1; CN108886636A; US20190069028A1; WO2017135388A1

Abstract

이벤트 등록 및 통보를 생성, 전송, 제공, 및/또는 수신하기 위한 시스템.

Description

이벤트 등록 및 통보

본 발명은 일반적으로, 이벤트 등록, 통보 및 시그널링에 관한 것이다.

방송 서비스는 방송 수신기를 갖는 모든 사용자에 의해 수신될 수 있다. 방송 서비스는, 오디오만 전달하는 라디오 방송 서비스와, 오디오, 비디오 및 데이터를 전달하는 멀티미디어 방송 서비스의 2가지 범주로 대략 나눌 수 있다. 이러한 방송 서비스는 아날로그 서비스로부터 디지털 서비스로 발전했다. 최근에는 (케이블 방송 시스템, 위성 방송 시스템, 인터넷 기반 방송 시스템, 케이블 네트워크, 인터넷 및/또는 위성 모두를 이용한 하이브리드 방송 시스템 등의) 다양한 유형의 방송 시스템이 고속 데이터 서비스와 함께 고품질의 오디오 및 비디오 방송 서비스를 제공한다. 또한, 방송 서비스는, 개개의 컴퓨터 및/또는 컴퓨터 그룹 및/또는 하나 이상의 모바일 통신 디바이스로 향하는 오디오, 비디오 및/또는 데이터를 전송 및/또는 수신하는 것을 포함한다.

보다 전통적인 고정 수신 디바이스 외에, 모바일 통신 디바이스도 이러한 서비스를 지원하도록 유사하게 구성된다. 이렇게 구성된 모바일 디바이스는, 모바일 전화와 같이, 이동 중에도 사용자가 이러한 서비스를 이용할 수 있게 해왔다. 멀티미디어 서비스에 대한 요구가 증가함에 따라, 모바일 통신 및 일반 유선 통신 양쪽 모두를 위한 다양한 무선/방송 서비스가 가능하게 되었다. 또한, 이러한 컨버전스는 상이한 유선 및 무선 방송 서비스들 위한 환경을 통합했다.

ATSC(Advanced Television Systems Committee)는, 지상파, 케이블 및 위성 네트워크를 통한 디지털 텔레비전 전송을 위해 Advanced Television Systems Committee에 의해 개발된 표준 세트를 포함한다. ATSC 2.0은, TV를 인터넷 서비스와 접속하고 대화형 요소를 방송 스트림 내에 허용함으로써 대화형 및 하이브리드 텔레비전 기술을 허용한다. ATSC 2.0은 또한, 고급 비디오 압축, 시청자 측정, 표적 광고, 향상된 프로그램 안내, 주문형 비디오(VOD) 서비스, 및 비실시간(NRT) 콘텐츠를 포함한 정보를 수신기에 저장하는 기능을 허용한다. ATSC 3.0은 시청자에게 추가적인 서비스를 제공하고 대역폭 효율성과 압축 성능을 향상시킨다. ATSC 3.0은, 서비스의 일부가 방송을 통해 전달될 수 있고 서비스의 일부가 광대역을 통해 전달될 수 있는 하이브리드 서비스를 지원한다. ATSC 3.0의 양태들 중 하나는 수신기 및/또는 수신기의 애플리케이션에 의해 수신되는 이벤트들의 등록을 위한 기술 및 수신기 및/또는 수신기의 애플리케이션들로의 이러한 이벤트들의 통보를 위한 기술을 포함한다. 추가로, 수신기는 이벤트를 생성할 수 있고, 수신기 상의 애플리케이션은 이벤트를 수신하기 위해 등록할 수 있다. 이 경우 수신기는 이러한 이벤트를 애플리케이션에 통보할 수 있다. 이러한 등록 및 통보에 대한 비효율적인 기술은 수신기로부터 애플리케이션으로의 불필요한 메시지의 과잉 범람을 초래할 수 있다.

본 발명의 전술된 및 기타의 목적, 특징, 및 이점들은, 첨부된 도면들과 연계하여 본 발명의 이하의 상세한 설명으로 참조하면 더욱 용이하게 이해될 것이다.

도 1은 하나 이상의 서비스 제공자 및 하나 이상의 수신기 디바이스를 포함하는 예시적인 시스템을 나타내는 블록도를 도시한다.
도 2는 본 개시내용의 하나 이상의 기술을 구현할 수 있는 수신기 디바이스의 한 예를 나타내는 블록도를 도시한다.
도 3은 본 개시내용의 하나 이상의 기술을 구현할 수 있는 또 다른 수신기 디바이스의 한 예를 나타내는 블록도를 도시한다.
도 4는 예시적인 emsg 박스를 도시한다.
도 5는 예시적인 애플리케이션 이벤트 정보(application event information)(AEI) 신택스를 도시한다.
도 6은 예시적인 evti 박스를 도시한다.
도 7은 예시적인 inband_event_descriptor() 신택스를 도시한다.
도 8은 예시적인 eventType 테이블을 도시한다.

도 1은 본 명세서에서 설명된 하나 이상의 기술을 구현할 수 있는 시스템의 한 예를 나타내는 블록도이다. 시스템(100)은 본 명세서에서 설명된 기술에 따라 수신기 디바이스에 콘텐츠 정보를 제공하도록 구성될 수 있다. 도 1에 도시된 예에서, 시스템(100)은, 하나 이상의 수신기 디바이스(102A-102N), 텔레비전 서비스 네트워크(104), 텔레비전 서비스 제공자 사이트(106), 네트워크(116), 및 웹 서비스 제공자 사이트(118)를 포함한다. 시스템(100)은 소프트웨어 모듈을 포함할 수 있다. 소프트웨어 모듈은 메모리에 저장되고 프로세서에 의해 실행될 수 있다. 시스템(100)은 하나 이상의 프로세서와 복수의 내부 및/또는 외부 메모리 디바이스를 포함할 수 있다. 메모리 디바이스의 예로서는, 파일 서버, FTP 서버, NAS(Network Attached Storage) 디바이스, 로컬 디스크 드라이브, 또는 데이터를 저장할 수 있는 기타 임의의 유형의 디바이스나 저장 매체가 포함된다. 저장 매체는, Blu-ray 디스크, DVD, CD-ROM, 자기 디스크, 플래시 메모리, 기타 임의의 적절한 디지털 저장 매체를 포함할 수 있다. 여기서 설명된 기술들이 부분적으로 소프트웨어로 구현될 때, 디바이스는 소프트웨어를 위한 명령어들을 적절한 비일시적인 컴퓨터-판독가능한 매체에 저장하고 하나 이상의 프로세서를 이용하여 하드웨어로 명령어들을 실행할 수 있다.

시스템(100)은, 예를 들어, 텔레비전 프로그램 등의 디지털 미디어 콘텐츠가 수신기 디바이스들(102A-102N) 등의 복수의 컴퓨팅 디바이스에 배포되고 이에 의해 액세스되는 것을 허용하도록 구성될 수 있는 시스템의 한 예를 나타낸다. 도 1에 나타낸 예에서, 수신기 디바이스들(102A-102N)은 텔레비전 서비스 제공자 사이트(106)로부터 트랜스포트 스트림을 수신하도록 구성된 임의의 디바이스를 포함할 수 있다. 예를 들어, 수신기 디바이스들(102A-102N)은 유선 및/또는 무선 통신을 위한 장비를 갖출 수 있고, 소위 스마트 텔레비전, 셋탑 박스, 및 디지털 비디오 레코더를 포함한 텔레비전을 포함할 수 있다. 또한, 수신기 디바이스들(102A-102N)은, 데스크탑, 랩탑, 또는 태블릿 컴퓨터, 게임 콘솔, 예를 들어 "스마트" 전화, 셀룰러 전화, 및 텔레비전 제공자 사이트(106)로부터 트랜스포트 스트림을 수신하도록 구성된 개인용 게임 디바이스를 포함한 모바일 디바이스들을 포함할 수 있다. 예시적인 시스템(100)은 별개의 사이트를 갖는 것으로 도시되어 있지만, 이러한 예시는 설명의 목적을 위한 것이며 시스템(100)을 특정한 물리적 아키텍처로 제한하고자 하는 것이 아니라는 점에 유의해야 한다. 시스템(100) 및 여기에 포함된 사이트의 기능은, 하드웨어, 펌웨어 및/또는 소프트웨어 구현의 임의의 조합을 이용하여 실현될 수 있다.

텔레비전 서비스 네트워크(104)는, 텔레비전 서비스가 제공될 수 있게 하도록 구성된 네트워크의 한 예이다. 예를 들어, 텔레비전 서비스 네트워크(104)는, 공중용 공중파 텔레비전 네트워크, 공중용 또는 가입-기반의 위성 텔레비전 서비스 제공자 네트워크, 공중용 또는 가입-기반의 케이블 텔레비전 제공자 네트워크 및/또는 오버더 탑(over the top) 또는 인터넷 서비스 제공자를 포함할 수 있다. 일부 예에서, 텔레비전 서비스 네트워크(104)는 주로 텔레비전 서비스가 제공될 수 있게 하는데 이용될 수 있지만, 텔레비전 서비스 네트워크(104)는 또한, 여기서 설명된 통신 프로토콜들의 임의의 조합에 따라 다른 유형의 데이터 및 서비스가 제공될 수 있게 할 수 있다. 텔레비전 서비스 네트워크(104)는, 무선 및/또는 유선 통신 매체의 임의의 조합을 포함할 수 있다. 텔레비전 서비스 네트워크(104)는, 동축 케이블, 광섬유 케이블, 꼬인 쌍 케이블, 무선 전송기 및 수신기, 라우터, 스위치, 리피터, 기지국, 또는 다양한 디바이스와 사이트 사이의 통신을 가능하게 하는데 유용할 수 있는 기타 임의의 장비를 포함할 수 있다. 텔레비전 서비스 네트워크(104)는 하나 이상의 통신 프로토콜들의 조합에 따라 동작할 수 있다. 통신 프로토콜은 전용 양태를 포함하거나 및/또는 표준화된 통신 프로토콜을 포함할 수 있다. 표준화된 통신 프로토콜의 예로서는, DVB(Digital Video Broadcasting) 표준, ATSC 표준, ISDB(Integrated Services Digital Broadcasting) 표준, DTMB(Digital Terrestrial Multimedia Broadcast) 표준, DMB(Digital Multimedia Broadcasting) 표준, Data Over Cable Service Interface Specification(DOCSIS) 표준, 하이브리드 방송 및 광대역(HbbTV) 표준, W3C 표준 및 범용 플러그 앤 플레이(UPnP) 표준이 포함된다.

도 1을 다시 참조하면, 텔레비전 서비스 제공자 사이트(106)는, 텔레비전 서비스 네트워크(104)를 통해 텔레비전 서비스를 배포하도록 구성될 수 있다. 예를 들어, 텔레비전 서비스 제공자 사이트(106)는, 공공 방송국, 케이블 텔레비전 제공자, 또는 위성 텔레비전 제공자를 포함할 수 있다. 일부 예에서, 텔레비전 서비스 제공자 사이트(106)는 방송 서비스 제공자 또는 방송사를 포함할 수 있다. 도 1에 도시된 예에서, 텔레비전 서비스 제공자 사이트(106)는 서비스 배포 엔진(108) 및 멀티미디어 데이터베이스(110A)를 포함한다. 서비스 배포 엔진(108)은, 복수의 프로그램 피드를 수신하고 그 피드를 텔레비전 서비스 네트워크(104)를 통해 수신기 디바이스(102A-102N)에 배포하도록 구성될 수 있다. 예를 들어, 서비스 배포 엔진(108)은, 전술된 전송 표준들 중 하나 이상(예를 들어, ATSC 표준)에 따라 텔레비전 방송들을 전송하도록 구성된 방송국을 포함할 수 있다. 멀티미디어 데이터베이스(110A)는, 프로그램 피드와 연관된 콘텐츠 정보를 포함한, 멀티미디어 콘텐츠 및/또는 콘텐츠 정보를 저장하도록 구성된 저장 디바이스를 포함할 수 있다. 일부 예에서, 텔레비전 서비스 제공자 사이트(106)는, 저장된 멀티미디어 콘텐츠에 액세스하고 멀티미디어 콘텐츠를 텔레비전 서비스 네트워크(104)를 통해 수신기 디바이스들(102A-102N) 중 하나 이상에 배포하도록 구성될 수 있다. 예를 들어, 멀티미디어 데이터베이스(110A)에 저장된 멀티미디어 콘텐츠(예를 들어, 음악, 영화 및 TV 쇼)는 온 디맨드 방식으로 텔레비전 서비스 네트워크(104)를 통해 사용자에게 제공될 수 있다.

네트워크(116)는 무선 및/또는 유선 통신 미디어의 임의의 조합을 포함할 수 있다. 네트워크(116)는, 동축 케이블, 광섬유 케이블, 꼬인 쌍 케이블, Ethernet 케이블, 무선 전송기 및 수신기, 라우터, 스위치, 리피터, 기지국, 또는 다양한 디바이스와 사이트 사이의 통신을 가능하게 하는데 유용할 수 있는 기타 임의의 장비를 포함할 수 있다. 네트워크(116)는 액세스 레벨에 기초하여 구별될 수 있다. 예를 들어, 네트워크(116)는 월드 와이드 웹으로의 액세스를 가능하게 할 수 있다. 또는 네트워크(116)는 사용자가 디바이스들의 서브셋, 예를 들어 사용자의 집에 위치한 컴퓨팅 디바이스에 액세스할 수 있게 할 수 있다. 따라서, 네트워크는 광역 네트워크 또는 근거리 통신망 또는 이들의 조합일 수 있고, 일반적으로 인터넷 또는 광대역 네트워크라고도 칭해질 수 있다. 일부 예에서, 로컬 영역 네트워크는 개인 네트워크 또는 홈 네트워크로 지칭될 수 있다.

네트워크(116)는 패킷 기반 네트워크일 수 있고 하나 이상의 원격통신 프로토콜의 조합에 따라 동작할 수 있다. 통신 프로토콜은 전용 양태를 포함하거나 및/또는 표준화된 통신 프로토콜을 포함할 수 있다. 표준화된 통신 프로토콜의 예로서는, GSM(Global System Mobile Communications) 표준, CDMA(Code Division Multiple Access) 표준, 3GPP(Third Generation Partnership Project) 표준, ETSI(European Telecommunications Standards Institute) 표준, IP(인터넷 프로토콜) 표준, Wireless Application Protocol(WAP) 표준들, 및 예를 들어 IEEE 802 표준들 중 하나 이상(예를 들어, Wi-Fi) 등의 IEEE 표준들이 포함될 수 있다.

도 1을 다시 참조하면, 웹 서비스 제공자 사이트(118)는, 하이퍼텍스트 기반 콘텐츠 또는 애플리케이션 또는 애플리케이션이나 오디오/비디오/폐쇄 자막/미디어 콘텐츠 등과 연관된 다른 메타데이터를 네트워크(116)를 통해 하나 이상의 수신기 디바이스들(102A-102N)에 제공하도록 구성될 수 있다. 웹 서비스 제공자 사이트(118)는 하나 이상의 웹 서버를 포함할 수 있다. 하이퍼텍스트 콘텐츠는, 예를 들어, HTML(Hypertext Markup Language), 동적 HTML, XML(Extensible Markup Language) 및 JSON(JavaScript Object Notation) 등의 데이터 포맷과 같은, 프로그래밍 언어에 따라 정의될 수 있다. JSON(JavaScript Object Notation)은 데이터 교환 포맷이다.

JSON 스키마는 JSON 데이터의 구조를 정의하기 위한 JSON 기반 포맷을 정의한다. JSON 스키마는 JSON 데이터의 유효성확인, 문서화, 하이퍼링크 네비게이션, 및 상호작용 제어를 정의하기 위한 것이다.

객체는 0개 이상의 명칭 및 값 쌍으로 이루어진 비정렬된 모음이며, 여기서, 명칭은 문자열이고, 값은 문자열, 숫자, 부울(Boolean), null, 객체 또는 어레이이다.

JSON 스키마는 객체일 수 있는 JSON 문서이다. JSON 스키마에 의해 정의된 객체 특성은, 키워드 또는 스키마 키워드라고 한다.

JSON 스키마는, 스키마 키워드가 아닌 특성을 포함할 수 있다.

JSON 값은, 객체, 어레이, 숫자, 문자열이거나 false, null 또는 true 중 하나일 수 있다.

특성 또는 요소 또는 키 또는 키워드 또는 명칭 또는 파라미터 또는 요소라는 용어는 본 문서에서 서로 바꾸어 사용할 수 있다. 특성이라는 용어는 본 문서에서 객체 또는 요소 또는 파라미터의 명칭을 지칭하는데 사용될 수 있다.

웹페이지 콘텐츠 배포 사이트의 한 예는, 미국 특허 및 상표청(US Patent and Trademark Office) 웹 사이트가 포함된다. 또한, 웹 서비스 제공자 사이트(118)는, 프로그램 피드들과 연관된 콘텐츠 정보를 포함한, 콘텐츠 정보를 수신기 디바이스들(102A-102N)에 제공하도록 구성될 수 있다. 하이퍼텍스트 콘텐츠 및 콘텐츠 정보는 애플리케이션에 이용될 수 있다. 하이퍼텍스트 기반 콘텐츠 등은 오디오 및 비디오 콘텐츠를 포함할 수 있다는 점에 유의해야 한다. 예를 들어, 도 1에 도시된 예에서, 웹 서비스 제공자 사이트(118)는, 멀티미디어 데이터베이스(110B)에 액세스하고 멀티미디어 콘텐츠 및 콘텐츠 정보를 네트워크(116)를 통해 하나 이상의 수신기 디바이스(102A-102N)에 배포하도록 구성될 수 있다. 한 예에서, 웹 서비스 제공자 사이트(118)는 인터넷 프로토콜 스위트를 이용하여 멀티미디어 콘텐츠를 제공하도록 구성될 수 있다. 예를 들어, 웹 서비스 제공자 사이트(118)는 실시간 스트리밍 프로토콜(RTSP)에 따라 수신기 디바이스에 멀티미디어 콘텐츠를 제공하도록 구성될 수 있다. 본 명세서에 설명된 기술들은 수신기 디바이스가 웹 서비스 제공자 사이트로부터 멀티미디어 콘텐츠 및 그와 관련된 콘텐츠 정보를 수신하는 경우에 적용가능할 수 있다는 점에 유의해야 한다.

도 1을 참조하면, 웹 서비스 제공자 사이트는 애플리케이션 및 이벤트에 대한 지원을 제공할 수 있다. 애플리케이션은 자체 포함된 강화된 또는 대화형 서비스를 구성하는 문서 모음일 수 있다. 애플리케이션의 문서는 예를 들어: HTML, XHTML, Java, JavaScript, CSS, XML, 멀티미디어 파일 등이다. 대화형 애플리케이션은 방송사 또는 시청자로부터의 입력에 기초하여 작업을 수행할 수 있다. 이벤트는 비동기 방식으로 제1 엔티티로부터 제2 엔티티로의 어떤 정보의 전달일 수 있다. 일부 경우에 이벤트는 제1 엔티티로부터의 명시적 요청없이 한 엔티티에서 또 다른 엔티티로 전달될 수 있다. 이벤트는 비동기 방식으로 엔티티의 제1 부분으로부터 동일한 엔티티의 제2 부분으로의 어떤 정보의 전달일 수 있다. 예로서, 수신기 디바이스는 수신기 디바이스의 제1 부분으로부터 동일한 수신기 디바이스의 제2 부분으로 이벤트를 전달할 수 있다. 이벤트 수신은 (항상은 아니지만) 동작을 트리거할 수 있다. 수신기 디바이스는 이벤트 통보를 애플리케이션에 전달할 수 있다. 애플리케이션 수신 이벤트 통보는 수신기에서 실행 중이거나 수신기와 연관될 수 있다.

수신기 디바이스들(102A-102N) 각각은 본 명세서에서 일반적으로 이벤트 송수신기라고 지칭되는 각각의 이벤트 수신기/전송기(120A-120N)를 포함할 수 있다. 이벤트 수신기/전송기(120A-120N)는 이벤트를 수신하고, 이벤트를 전송하며, 및/또는 이벤트를 수신 및 전송할 수 있다. 이러한 방식으로, 텔레비전 서비스 제공자 사이트(106) 및/또는 웹 서비스 제공자 사이트(118)는 이벤트 수신기/전송기(120A-120N)에 이벤트를 전달할 수 있다. 이러한 방식으로, 이벤트 수신기/전송기(120A-120N)는 텔레비전 서비스 제공자 사이트(106) 및/또는 웹 서비스 제공자 사이트(118)에 이벤트를 전달할 수 있다. 또한, 이벤트 수신기/전송기(120A-120N) 중 하나는 이벤트를 이벤트 수신기/전송기(120A-120N) 중 또 다른 하나에 전달할 수 있다. 또한, 수신기 디바이스들(102A-102N) 중 하나의 이벤트 수신기/전송기는 동일한 수신기 디바이스들(102A-102N)의 또 다른 이벤트 수신기/전송기와 통신할 수 있다. 텔레비전 서비스 제공자 사이트(106)는 각각의 이벤트/전송기를 포함할 수 있다. 웹 서비스 제공자 사이트(118)는 각각의 이벤트/전송기를 포함할 수 있다.

대화형 부속 데이터 서비스를 실행하는 모델은, 예를 들어, 직접 실행 모델, 및 트리거형 선언적 객체(triggered declarative object)(TDO) 모델을 포함할 수 있다. 직접 실행 모델에서, 선언적 객체(DO)는 수신기 디바이스(200) 상에서 사용자에 의해 채널이 선택되자마자, 예를 들어, 텔레비전에서 채널을 선택하자마자, 자동적으로 론칭될 수 있다. 채널은 가상 채널일 수 있다. 가상 채널은, 시청자로의 프리젠테이션을 위해 선택될 때 수신 디바이스에서 "선택"된다고 말할 수 있다. 이것은 아날로그 TV 채널에 "튜닝"되는 것과 유사하다. DO는 인터넷을 통해 서버와 통신하여 화면 상의 특정 위치에서 대화형 피처-생성 디스플레이를 제공하고, 설문 조사를 실시하며, 다른 전문화된 DO들을 론칭하는 등에 대한 상세한 지침을 얻을 수 있고, 이들 모든 작업은 오디오 비디오 프로그램과 동기화된다. 한 실시예에서 백엔드 서버는 웹 서비스 제공자 사이트(118)일 수 있다.

TDO 모델에서, 신호는 방송 스트림 또는 인터넷을 통해 전달되어 TDO 론칭, TDO 종료 또는 TDO에 의한 소정 작업 통보 등의 TDO 이벤트를 시작할 수 있다. 이들 이벤트들은, 통상적으로 오디오-비디오 프로그램과 동기화된 특정한 시간들에서 시작될 수 있다. TDO가 론칭되면, 프로그래밍할 수 있는 대화형 기능을 제공할 수 있다.

선언적 객체(DO)라는 용어는 대화형 애플리케이션을 구성하는 모음으로 구성될 수 있다. 앞서 정의된 애플리케이션은 자체 포함된 강화된 또는 대화형 서비스를 구성하는 문서 모음일 수 있다. 애플리케이션의 문서는 예를 들어: HTML, XHTML, Java, JavaScript, CSS, XML, 멀티미디어 파일 등이다. 대화형 애플리케이션은 방송사 또는 시청자로부터의 입력에 기초하여 작업을 수행할 수 있다.

"트리거형 선언적 객체"(TDO)라는 용어는, 트리거형 상호작용 부속 데이터 서비스의 트리거, 또는 트리거에 의해 론칭된 DO 등에 의해 반복적으로 론칭된 선언적 객체를 지칭하는데 사용될 수 있다.

TDO 모델의 기본 개념은, TDO를 구성하는 파일들, 및 어떤 동작을 수행하기 위해 TDO에 의해 이용되는 데이터 파일들 모두는, 주어진 크기에 따라 수신기에 전달되는데 어느 정도의 시간이 필요하다는 것이다. 대화형 요소들의 사용자 경험이 콘텐츠의 방송에 앞서 제작될 수 있지만, 소정의 거동들은 프로그램 자체의 이벤트들, 예를 들어, 상업 광고 세그먼트의 발생과 일치하도록 정교하게 타이밍조절될 수 있다.

TDO 모델은, 선언적 객체 및 연관된 데이터, 스크립트, 텍스트 및 그래픽의 전달을 대화형 이벤트 재생의 특정한 타이밍 시그널링으로부터 구분한다.

대화형 이벤트의 타이밍을 설정하는 요소는 트리거이다.

세그먼트에서 이용된 TDO 및 트리거에 의해 시작되는 연관된 TDO 이벤트에 대한 정보는 "TDO 파라미터 테이블"(TPT)이라고 불리는 데이터 구조에 의해 제공된다.

TPT는 세그먼트들의 TDO들 및 이들을 타겟으로 하는 이벤트들에 대한 정보를 포함할 수 있다. TDO 정보는, 애플리케이션 식별자(appID), 애플리케이션 유형, 애플리케이션 명칭(들), 애플리케이션 버전, 애플리케이션의 일부인 파일들의 위치, 애플리케이션 경계를 정의하는 정보, 및/또는 애플리케이션 원점을 정의하는 정보에 대응할 수 있다. TPT 내의 이벤트 정보는, 이벤트 식별자(eventID), 이벤트가 활성화될 때 적용될 동작, 애플리케이션에 대한 타겟 디바이스 유형, 및/또는 이벤트에 관련된 데이터 필드를 포함할 수 있다. 이벤트에 관련된 데이터 필드는, 식별자(dataID), 이벤트에 이용될 데이터를 포함할 수 있다. 추가로, TPT는, 트리거 위치, 버전, 요구되는 수신기 능력, TPT 내의 정보가 유효한 기간, 수신기가 새로운 TPT를 체크하고 다운로드할 필요가 있는 때에 대한 정보를 포함할 수 있다.

동작은 애플리케이션의 라이프사이클을 제어한다. 동작은 애플리케이션이 천이할 수 있는 상태를 나타낼 수 있다.

한 예에서, 이벤트(들)은 애플리케이션 라이프사이클 제어 동작(들)에 대응할 수 있다.

한 예에서, 애플리케이션 라이프사이클 제어 동작(들)은 이벤트에 대응할 수 있다.

애플리케이션 정보 테이블(Application Information Table)(AIT)은, 예를 들어, 자신에 의해 운반되는 애플리케이션의 요구되는 활성화 상태, 애플리케이션 유형, 애플리케이션 프로필, 애플리케이션 우선순위, 애플리케이션 버전, 애플리케이션 식별자(appID) 등에 관한 정보를 제공할 수 있다. AIT의 데이터는 방송사가, 수신기가 애플리케이션의 활성화 상태를 변경할 것을 요청하게 할 수 있다. 유의사항 - AIT는 TPT의 일부 데이터 요소들과 기능적으로 동일한 일부 데이터 요소를 포함할 수 있다.

역시 또 다른 실시예에서, 애플리케이션은 브라우저 환경 내에서 수신기(102A-102N) 상에서 실행될 수 있다. 이 경우, 애플리케이션 패키지는 방송(예를 들어, 104) 또는 광대역 네트워크(예를 들어, 116)로부터 다운로드될 수 있다. 그 다음, 애플리케이션 패키지와 함께 URL(Uniform Resource Locator)을 오픈함으로써 애플리케이션이 론칭된다.

도 2는 본 개시내용의 하나 이상의 기술을 구현할 수 있는 수신기 디바이스의 한 예를 나타내는 블록도이다. 수신기 디바이스(200)는, 통신 네트워크로부터 데이터를 수신하고 사용자가 멀티미디어 콘텐츠에 액세스하는 것을 허용하도록 구성될 수 있는 컴퓨팅 디바이스의 한 예이다. 도 2에 나타낸 예에서, 수신기 디바이스(200)는, 예를 들어 전술된 텔레비전 서비스 네트워크(104) 등의, 텔레비전 네트워크를 통해 데이터를 수신하도록 구성된다. 또한, 도 2에 나타낸 예에서, 수신기 디바이스(200)는 근거리 통신망 및/또는 광역 네트워크를 통해 데이터를 송수신하도록 구성된다. 수신기 디바이스(200)는, 근거리 통신망을 통해 또는 직접, 수신기 디바이스와 데이터를 송수신하도록 구성될 수 있다. 다른 예에서, 수신기 디바이스(200)는 텔레비전 네트워크(106)를 통해 단순히 데이터를 수신하고 (직접적으로 또는 간접적으로) 데이터를 수신기 디바이스에 전송하거나 및/또는 수신기 디바이스로부터 수신하도록 구성될 수 있다는 점에 유의해야 한다. 여기서 설명된 기술들은 통신 네트워크들의 임의의 조합 및 모든 조합을 이용하여 통신하도록 구성된 디바이스들에 의해 이용될 수 있다.

도 2에 나타낸 바와 같이, 수신기 디바이스(200)는, 중앙 처리 유닛(들)(202), 시스템 메모리(204), 시스템 인터페이스(210), 복조기(212), A/V & 데이터 디먹스(214), 이벤트 수신기(232), 오디오 디코더(216), 오디오 출력 시스템(218), 비디오 디코더(220), 디스플레이 시스템(222), I/O 디바이스(224) 및 네트워크 인터페이스(226)를 포함한다. 복조기(212), AV & 데이터 디먹스(214), 및 이벤트 수신기(232)의 조합은 ATSC 튜너(230)로서 간주될 수 있다. 도 2에 나타낸 바와 같이, 시스템 메모리(204)는, 운영 체제(206), html 브라우저(207), 및 애플리케이션(208)을 포함한다. 애플리케이션(208)은 방송사 애플리케이션이라 부를 수 있다. 애플리케이션은 이벤트(들)를 등록 또는 등록 해제하고 이벤트 통보를 수신하기 위한 모듈(2081)을 포함할 수 있다. 일부 애플리케이션(208)은, 이벤트 및 수신기 이벤트 통보에 대해서만 등록/등록 해제할 수 있지만 이벤트를 전송하지 않을 수도 있다. HTML 브라우저(207)는 또한 이벤트를 수신 및/또는 전송하는데 적합할 수 있다. HTML 브라우저는 애플리케이션(208) 내의 이벤트 전송기/수신기(2081)에 이벤트를 수신/전송할 수 있다. 운영 체제(206)는 애플리케이션(208) 내의 이벤트 전송기/수신기(2081)에 이벤트를 수신/전송할 수 있다. 중앙 처리 유닛(들)(202) 각각, 시스템 메모리(204), 시스템 인터페이스(210), 복조기(212), A/V & 데이터 디먹스(214), 오디오 디코더(216), 오디오 출력 시스템(218) 비디오 디코더(220), 디스플레이 시스템(222), I/O 디바이스(224), 및 네트워크 인터페이스(226)는, 컴포넌트간 통신을 위해 (물리적으로, 통신가능하게, 및/또는 동작적으로) 상호접속될 수 있고, 하나 이상의 마이크로프로세서, 디지털 신호 프로세서(DSP), 주문형 집적 회로(ASIC), 필드프로그래머블 게이트 어레이(FPGA), 개별 로직, 소프트웨어, 하드웨어, 펌웨어 또는 이들의 임의의 조합 등의, 다양한 적절한 회로 중 임의의 것으로서 구현될 수 있다. 예시적인 수신기 디바이스(200)가 별개의 기능 블록을 갖는 것으로 도시되어 있지만, 이러한 예시는 설명의 목적을 위한 것이며 수신기 디바이스(200)를 특정한 하드웨어 아키텍처로 제한하지 않는다는 점에 유의해야 한다. 수신기 디바이스(200)의 기능들은, 하드웨어, 펌웨어 및/또는 소프트웨어 구현들의 임의의 조합을 이용하여 실현될 수 있다.

CPU(들)(202)는 수신기 디바이스(200)에서의 실행을 위한 기능성 및/또는 프로세스 명령어들을 구현하도록 구성될 수 있다. CPU(들)(202)는 여기서 설명된 하나 이상의 기술을 구현하기 위해, 명령어, 코드 및/또는 데이터 구조를 검색하고 처리할 수 있다. 명령어들은, 시스템 메모리(204) 및/또는 저장 디바이스 등의 컴퓨터 판독가능한 매체 상에 저장될 수 있다. CPU(들)(202)는 단일 및/또는 멀티 코어 중앙 처리 유닛들을 포함할 수 있다.

시스템 메모리(204)는 비일시적인 또는 유형의(tangible) 컴퓨터-판독가능한 저장 매체로서 기술될 수 있다. 일부 예에서, 시스템 메모리(204)는 임시적 및/또는 장기적 저장을 제공할 수 있다. 일부 예에서, 시스템 메모리(204) 또는 그 일부는 비휘발성 메모리로서 기술될 수 있고, 다른 예에서는 시스템 메모리(204)의 일부는 휘발성 메모리로서 기술될 수 있다. 휘발성 메모리의 예로서는, 랜덤 액세스 메모리(RAM), 동적 랜덤 액세스 메모리(DRAM), 및 정적 랜덤 액세스 메모리(SRAM)가 포함된다. 비휘발성 메모리의 예로서는, 자기 하드 디스크, 광 디스크, 플로피 디스크, 플래시 메모리, 또는 전기적으로 프로그램가능한 메모리(EPROM) 또는 전기적으로 소거 및 프로그램가능한(EEPROM) 메모리의 포맷이 포함된다. 시스템 메모리(204)는 동작 동안에 수신기 디바이스(2200)에 의해 이용될 수 있는 정보를 저장하도록 구성될 수 있다. 시스템 메모리(204)는, CPU(들)(202)에 의한 실행을 위한 프로그램 명령어들을 저장하는데 이용될 수 있고, 프로그램 실행 동안에 정보를 임시적으로 저장하기 위해 수신기 디바이스(200) 상에서 실행중인 프로그램들에 의해 이용될 수 있다. 또한, 수신기 디바이스(200)가 디지털 비디오 레코더의 일부로서 포함되는 예에서, 시스템 메모리(204)는 복수의 비디오 파일을 저장하도록 구성될 수 있다.

애플리케이션(208)은, 수신기 디바이스(200) 내에 구현되거나 수신기 디바이스(200)에 의해 실행되는 애플리케이션들을 포함할 수 있고, 수신기 디바이스(200)의 컴포넌트들 내에 구현되거나 포함될 수 있고, 이들에 의해 동작가능하거나, 이들에 의해 실행되거나, 및/또는 이들에 동작적으로/통신가능하게 결합될 수 있다. 애플리케이션(208)은 html 브라우저(207) 내에서 실행될 수 있다.

애플리케이션들(208)은 수신기 디바이스(200)의 CPU(들)(202)로 하여금 특정한 기능들을 수행하게 할 수 있는 명령어들을 포함할 수 있다. 애플리케이션(208)은 for-loops, while-loop, if-statement, do-loop 등의 컴퓨터 프로그래밍 문장으로 표현되는 알고리즘을 포함할 수 있다. 애플리케이션(208)은 명시된 프로그래밍 언어를 이용하여 개발될 수 있다. 프로그래밍 언어의 예로서는, Java™, Jini™, C, C++, Objective C, Swift, Perl, Python, PhP, UNIX 쉘, Visual Basic 및 Visual Basic Script가 포함된다. 수신기 디바이스(200)가 스마트 텔레비전을 포함하는 예에서, 애플리케이션들은 텔레비전 제조사 또는 방송사에 의해 개발될 수 있다. 도면에는 용어 애플리케이션들(208)은 복수를 사용하지만, 단 하나의 애플리케이션(208)이 있을 수 있다. 도 2에 도시된 바와 같이, 애플리케이션(208)은 운영 체제(206)와 연계하여 실행될 수 있다. 즉, 운영 체제(206)는, 애플리케이션(208)과 CPU(들)(202) 및 수신기 디바이스(200)의 기타의 하드웨어 컴포넌트들과의 상호작용을 가능하게 하도록 구성될 수 있다. 운영 체제(206)는, 셋탑 박스, 디지털 비디오 레코더, 텔레비전 등에 설치되도록 설계된 운영 체제일 수 있다. 여기서 설명된 기술들은 소프트웨어 아키텍처들의 임의의 조합 및 모든 조합을 이용하여 동작하도록 구성된 디바이스들에 의해 이용될 수 있다는 점에 유의해야 한다. 일부 실시예에서, 운영 체제(206)는 애플리케이션에 의해 요구되는 공통 기능을 제공하는 미들웨어(206)일 수 있다. 또한 이를 위해 "런타임 플랫폼"이라는 용어가 사용할 수도 있다. 한 예에서, 운영 체제(206) 및/또는 애플리케이션(208) 및/또는 html 브라우저(207)는, 수신기 디바이스와의 가입을 설정하고 이하에서 상세히 설명되는 기술에 따라 콘텐츠 정보 메시지를 생성하도록 구성될 수 있다.

시스템 인터페이스(210)는 컴퓨팅 디바이스(200)의 컴포넌트들 사이의 통신을 가능하게 하도록 구성될 수 있다. 한 예에서, 시스템 인터페이스(210)는, 데이터가 하나의 피어 디바이스로부터 또 다른 피어 디바이스로 또는 저장 매체로 전송될 수 있게 하는 구조를 포함한다. 예를 들어, 시스템 인터페이스(210)는, AGP(Accelerated Graphics Port) 기반 프로토콜, PCI Special Interest Group에 의해 유지되는 PCI Express™ (PCIe) 버스 명세 등의, PCI(Peripheral Component Interconnect) 버스 기반 프로토콜, 또는 피어 디바이스들을 상호접속하는데 이용될 수 있는 기타 임의의 형태의 구조(예를 들어, 독점적 버스 프로토콜)을 지원하는 칩셋을 포함할 수 있다.

전술된 바와 같이, 수신기 디바이스(200)는, 텔레비전 서비스 네트워크를 통해 데이터를 수신하고 임의로 데이터를 전송하도록 구성된다. 전술된 바와 같이, 텔레비전 서비스 네트워크는 통신 표준에 따라 동작할 수 있다. 통신 표준은, 예를 들어, 물리적 시그널링, 어드레싱, 채널 액세스 제어, 패킷 속성, 및 데이터 처리 등의 통신 특성(예를 들어, 프로토콜 계층)을 정의할 수 있다. 도 2에 도시된 예에서, 복조기(212), A/V & 데이터 디먹스(214), 및/또는 이벤트 수신기(232)는, 트랜스포트 스트림으로부터 비디오, 오디오 및 데이터를 추출하도록 구성될 수 있다. 트랜스포트 스트림은, 예를 들어, DVB 표준, ATSC 표준, ISDB 표준, DTMB 표준, DMB 표준 및 DOCSIS 표준에 따라 정의될 수 있다. 복조기(212), A/V & 데이터 demux(214), 및 이벤트 수신기/전송기(232)가 별개의 기능 블록들로서 도시되었지만, 복조기(212), A/V & 데이터 디먹스(214) 및/또는 이벤트 수신기/전송기(232)에 의해 수행되는 기능은, 하드웨어, 펌웨어 및/또는 소프트웨어 구현의 임의의 조합을 이용하여 고도로 통합 및 실현될 수 있다. 또한, 간결성을 위해, 디지털 RF(무선 주파수) 통신(예를 들어, 아날로그 튜닝 상세사항, 에러 정정 방식 등)의 완전한 설명은 여기서는 제공되지 않는다는 점에 유의해야 한다. 여기서 설명된 기술들은 일반적으로, 디지털 미디어 콘텐츠 및 연관된 콘텐츠 정보를 전송하는데 이용되는 디지털 RF 통신 기술에 적용가능하다.

한 예에서, 복조기(212)는, 무선 신호(over-the-air signal) 및/또는 동축 케이블로부터 신호를 수신하고 복조를 수행하도록 구성될 수 있다. 데이터는, 예를 들어, 직교 진폭 변조(QAM), 잔류 측파대 변조(VSB) 또는 직교 주파수 분할 변조(OFDM) 등의 변조 방식에 따라 변조될 수 있다. 복조의 결과는 트랜스포트 스트림일 수 있다. 트랜스포트 스트림은, 전술된 것들을 포함한, 원격통신 표준에 따라 정의될 수 있다. 인터넷 프로토콜(IP) 기반 트랜스포트 스트림은 단일 미디어 스트림 또는 복수의 미디어 스트림을 포함할 수 있고, 여기서 미디어 스트림은 비디오, 오디오 및/또는 데이터 스트림을 포함한다. 일부 스트림은 ISO 베이스 미디어 파일 포맷(ISOBMFF)에 따라 포맷팅될 수 있다. MPEG(Motion Picture Experts Group) 기반 트랜스포트 스트림은 단일 프로그램 스트림 또는 복수의 프로그램 스트림을 포함할 수 있고, 여기서, 프로그램 스트림은, 비디오, 오디오 및/또는 데이터 기본 스트림을 포함한다. 한 예에서, 미디어 스트림 또는 프로그램 스트림은 텔레비전 프로그램(예를 들어, TV "채널") 또는 멀티미디어 스트림(예를 들어, 온 디맨드 유니캐스트)에 대응할 수 있다. A/V & 데이터 디먹스(214)는, 트랜스포트 스트림 및/또는 프로그램 스트림을 수신하고, 비디오 패킷, 오디오 패킷, 및 데이터 패킷을 추출하도록 구성될 수 있다. 즉, AV 디먹스(214)는 수신기 디바이스(200)에 의한 추가 처리를 위해 디멀티플렉싱 기술을 적용하여 비디오 기본 스트림, 오디오 기본 스트림 및 데이터 기본 스트림을 분리할 수 있다. 또한, 이벤트 수신기(232)는 명시된 이벤트를 수신하고 및/또는 명시된 이벤트를 전송하도록 구성될 수 있다.

도 2를 다시 참조하면, 패킷들은, CPU(들)(202), 오디오 디코더(216) 및 비디오 디코더(220)에 의해 처리될 수 있다. 오디오 디코더(216)는 오디오 패킷을 수신 및 처리하도록 구성될 수 있다. 예를 들어, 오디오 디코더(216)는 오디오 코덱의 양태들을 구현하도록 구성된 하드웨어 및 소프트웨어의 조합을 포함할 수 있다. 즉, 오디오 디코더(216)는, 오디오 패킷을 수신하고 오디오 데이터를 렌더링을 위해 오디오 출력 시스템(218)에 제공하도록 구성될 수 있다. 오디오 데이터는, Dolby 및 Digital Theater Systems에서 개발된 것들 등의 다중-채널 형식을 이용하여 코딩될 수 있다. 오디오 데이터는 오디오 압축 포맷을 이용하여 코딩될 수 있다. 오디오 압축 포맷의 예로서는, MPEG 포맷, AAC 포맷, DTS-HD 포맷, 및 AC-3 포맷이 포함된다. 오디오 시스템(218)은 오디오 데이터를 렌더링하도록 구성될 수 있다. 예를 들어, 오디오 시스템(218)은, 오디오 프로세서, 디지털-대-아날로그 변환기, 증폭기, 및 스피커 시스템을 포함할 수 있다. 스피커 시스템은, 헤드폰, 통합 스테레오 스피커 시스템, 멀티-스피커 시스템, 또는 서라운드 사운드 시스템 등의 다양한 스피커 시스템 중 임의의 것을 포함할 수 있다.

비디오 디코더(220)는 비디오 패킷을 수신하고 처리하도록 구성될 수 있다. 예를 들어, 비디오 디코더(220)는 비디오 코덱의 양태들을 구현하는데 이용되는 하드웨어와 소프트웨어의 조합을 포함할 수 있다. 한 예에서, 비디오 디코더(220)는, ITU-T H.262 또는 ISO/IEC MPEG-2 Visual, ISO/IEC MPEG-4 Visual, (ISO/IEC MPEG-4 AVC라고도 알려진) ITU-T H.264, 및 HEVC(High-Efficiency Video Coding) 등의, 임의의 개수의 비디오 압축 표준에 따라 인코딩된 데이터를 디코딩하도록 구성될 수 있다. 디스플레이 시스템(222)은 디스플레이를 위한 비디오 데이터를 검색하고 처리하도록 구성될 수 있다. 예를 들어, 디스플레이 시스템(222)은 비디오 디코더(220)로부터 픽셀 데이터를 수신하고 시각적 프리젠테이션을 위해 데이터를 출력할 수 있다. 또한, 디스플레이 시스템(222)은, 비디오 데이터, 예를 들어, 그래픽 사용자 인터페이스와 연계하여, 그래픽을 출력하도록 구성될 수 있다. 디스플레이 시스템은, 액정 디스플레이(LCD), 플라즈마 디스플레이, 유기 발광 다이오드(OLED) 디스플레이, 또는 사용자에게 비디오 데이터를 프리젠팅할 수 있는 또 다른 유형의 디스플레이 디바이스 등의 다양한 디스플레이 디바이스 중 하나를 포함할 수 있다. 디스플레이 디바이스는, 표준 해상도 콘텐츠, 고선명 콘텐츠, 또는 초고화질 콘텐츠를 디스플레이하도록 구성될 수 있다.

I/O 디바이스(224)는, 수신기 디바이스(200)의 동작 동안에 입력을 수신하고 출력을 제공하도록 구성될 수 있다. 즉, I/O 디바이스(224)는 사용자가 렌더링될 멀티미디어 콘텐츠를 선택할 수 있게 할 수 있다. 입력은, 예를 들어, 푸시-버턴 원격 제어기, 터치 감지 스크린을 포함하는 디바이스, 움직임-기반 입력 디바이스, 오디오-기반 입력 디바이스, 또는 사용자 입력을 수신하도록 구성된 기타 임의의 유형의 입력 디바이스 등의 입력 디바이스로부터 생성될 수 있다. I/O 디바이스(들)(224)는, 예를 들어 USB(Universal Serial Bus) 프로토콜, Bluetooth, ZigBee, 또는 예를 들어, 전용 적외선 통신 프로토콜과 같은 전용 통신 프로토콜 등의, 표준화된 통신 프로토콜을 이용하여, 컴퓨팅 디바이스(200)에 동작적으로 결합될 수 있다.

네트워크 인터페이스(226)는 수신기 디바이스(200)가 근거리 통신망 및/또는 광역 네트워크를 통해 데이터를 송수신할 수 있게 하도록 구성될 수 있다. 또한, 네트워크 인터페이스는 수신기 디바이스(200)가 수신기 디바이스와 통신할 수 있게 하도록 구성될 수 있다. 네트워크 인터페이스(226)는, Ethernet 카드, 광 트랜시버, 무선 주파수 트랜시버, 또는 정보를 전송 및 수신하도록 구성된 기타 임의의 유형의 디바이스 등의 네트워크 인터페이스 카드를 포함할 수 있다. 네트워크 인터페이스(226)는, 네트워크에서 이용되는 물리적 및 미디어 액세스 제어(MAC) 계층에 따라 물리적 시그널링, 어드레싱, 및 채널 액세스 제어를 수행하도록 구성될 수 있다.

전술된 바와 같이, A/V & 데이터 디먹스(214)는 트랜스포트 스트림으로부터 데이터 패킷을 추출하도록 구성될 수 있다. 데이터 패킷은 콘텐츠 정보를 포함할 수 있다. 또 다른 예에서, 네트워크 인터페이스(226) 및 차례로 시스템 인터페이스(210)는 데이터 패킷을 추출할 수 있다. 이 예에서 데이터 패킷은 네트워크(116) 등의 네트워크로부터 유래할 수 있다. 본 명세서에서 사용될 때, 콘텐츠 정보라는 용어는 일반적으로 네트워크를 통해 수신된 서비스와 연관된 임의의 정보를 지칭할 수 있다. 또한, 콘텐츠 정보라는 용어는 더 구체적으로는 특정한 멀티미디어 콘텐츠와 연관된 정보를 지칭할 수 있다. 콘텐츠 정보에 대한 데이터 구조는 통신 표준에 따라 정의될 수 있다. 예를 들어, ATSC 표준은 콘텐츠 정보를 포함하는 PSIP(Program and System Information Protocol) 테이블을 기술하고 있다. PSIP 테이블의 유형은, 이벤트 정보 테이블(EIT), 확장된 텍스트 테이블(ETT) 및 데이터 이벤트 테이블(DET)을 포함한다. ATSC 표준에서, DET와 EIT는, 이벤트 설명, 시작 시간, 및 지속시간을 제공할 수 있다. ATSC 표준에서, ETT는 가상 채널 및 이벤트를 기술하는 텍스트를 포함할 수 있다. 또한, ATSC와 유사한 방식으로, DVB 표준은, 네트워크 내의 서비스들을 설명하고 서비스 제공자 명칭을 제공하는 Service Description Table, 및 이벤트 명칭 설명, 시작 시간 및 지속시간을 포함하는 EIT를 포함한다. 수신기 디바이스(200)는, 이들 테이블을 이용하여 (예를 들어, EPG를 제시하는) 사용자에게 콘텐츠 정보를 디스플레이하도록 구성될 수 있다.

전술된 바와 같이, 콘텐츠 정보를 검색하기 위해 트랜스포트 스트림으로부터 테이블을 추출하는 것에 추가하여 또는 그 대안으로서, 수신기 디바이스(200)는 대안적 기술을 이용하여 콘텐츠 정보를 검색하도록 구성될 수 있다. 예를 들어, ATSC 2.0은 NRTC(Non-Real-Time Content) 전달 기술을 정의한다. NRTC 기술은, 수신기 디바이스가 파일 전달 프로토콜(예를 들어, FLUTE(File Delivery over Unidirectional Transport))을 통해 및/또는 인터넷을 통해(예를 들어, HTTP를 이용하여) 콘텐츠 정보를 수신할 수 있게 할 수 있다. NRTC에 따라 수신기 디바이스에 전송된 콘텐츠 정보는 수 개의 데이터 포맷에 따라 포맷팅될 수 있다. 하나의 예시적인 포맷은 OMA(Open Mobile Alliance) BCAST Service Guide Version 1.0.1에 정의된 데이터 포맷을 포함한다. 유사한 방식으로, DVB 표준은 콘텐츠 정보를 전송하는데 이용될 수 있는 전자 서비스 가이드(Electronic Service Guide)(ESG) 기술을 정의한다. 서비스 가이드는 현재 및 미래의 서비스 및/또는 콘텐츠에 대한 정보를 제공할 수 있다. 수신기 디바이스(200)는, NRTC 기술 및/또는 ESG 기술에 따라 콘텐츠 정보를 수신하도록 구성될 수 있다. 즉, 수신기 디바이스(200)는 서비스 가이드를 수신하도록 구성될 수 있다. 여기서 설명된 기술들은 수신기 디바이스가 콘텐츠 정보를 수신하는 방법에 관계없이 일반적으로 적용될 수 있다는 점에 유의해야 한다. 전술된 바와 같이, 수신기 디바이스(200)는, 근거리 통신망을 통해 또는 직접, 수신기 디바이스와 데이터를 송수신하도록 구성될 수 있다.

도 3은 본 개시내용의 하나 이상의 기술을 구현할 수 있는 수신기 디바이스의 한 예를 나타내는 블록도이다. 수신기 디바이스(300)는 하나 이상의 프로세서와 복수의 내부 및/또는 외부 저장 디바이스를 포함할 수 있다. 수신기 디바이스(300)는 수신기 디바이스와 통신하도록 구성된 한 예시적인 디바이스이다. 예를 들어, 수신기 디바이스(300)는 수신기 디바이스로부터 콘텐츠 정보를 수신하도록 구성될 수 있다. 수신기 디바이스(300)는 콘텐츠 정보 통신 메시지에 포함된 정보를 이용할 수 있는 하나 이상의 실행중인 애플리케이션을 포함할 수 있다. 수신기 디바이스(300)는 유선 및/또는 무선 통신을 위한 장비를 갖출 수 있고, 예를 들어 데스크탑 또는 랩탑 컴퓨터, 모바일 디바이스, 스마트폰, 셀룰러 전화, 개인 휴대 정보 단말기(PDA), 태블릿 디바이스 및 개인 게임 디바이스 등의 디바이스들을 포함할 수 있다.

도 3에 나타낸 바와 같이, 수신기 디바이스(300)는, 중앙 프로세서 유닛(들)(302), 시스템 메모리(304), 시스템 인터페이스(310), 저장 디바이스(312), I/O 디바이스(들)(314) 및 네트워크 인터페이스(316)를 포함한다. 도 3에 나타낸 바와 같이, 시스템 메모리(304)는, 운영 체제(306), 애플리케이션(308), 및/또는 HTML 브라우저(309)를 포함한다. 애플리케이션(308)은 방송사 애플리케이션이라 부를 수 있다. 애플리케이션은 이벤트(들)를 등록 또는 등록 해제하고 이벤트 통보를 수신하기 위한 모듈(3081)을 포함할 수 있다. 일부 애플리케이션(308)은, 이벤트 및 수신기 이벤트 통보에 대해서만 등록/등록 해제할 수 있지만 이벤트를 전송하지 않을 수도 있다. HTML 브라우저(309)는 또한 이벤트를 수신 및/또는 전송하는데 적합할 수 있다. HTML 브라우저는 애플리케이션(308) 내의 이벤트 전송기/수신기(3081)에 이벤트를 수신/전송할 수 있다. 운영 체제(306)는 애플리케이션(308) 내의 이벤트 전송기/수신기(3081)에 이벤트를 수신/전송할 수 있다. 예시적인 수신기 디바이스(300)가 별개의 기능 블록을 갖는 것으로 도시되어 있지만, 이러한 예시는 설명의 목적을 위한 것이며 수신기 디바이스(300)를 특정한 하드웨어 또는 소프트웨어 아키텍처로 제한하지 않는다는 점에 유의해야 한다. 수신기 디바이스(300)의 기능들은, 하드웨어, 펌웨어 및/또는 소프트웨어 구현들의 임의의 조합을 이용하여 실현될 수 있다. 도 2와 도 3의 수신기 사이의 차이점 중 하나는, 도 3의 수신기는 주로 광대역 네트워크로부터 모든 데이터를 얻을 수 있다는 것이다.

중앙 프로세서 유닛(들)(302), 시스템 메모리(304), 및 시스템 인터페이스(310) 각각은, 전술된 중앙 프로세서 유닛(들)(202), 시스템 메모리(204), 및 시스템 인터페이스(210)와 유사할 수 있다. 저장 디바이스(들)(312)는, 시스템 메모리(304)보다 많은 양의 데이터를 저장하도록 구성될 수 있는 수신기 디바이스(300)의 메모리를 나타낸다. 예를 들어, 저장 디바이스(들)(312)는 사용자의 멀티미디어 모음을 저장하도록 구성될 수 있다. 시스템 메모리(304)와 유사하게, 저장 디바이스(들)(312)는 또한, 하나 이상의 비일시적인 또는 유형의 컴퓨터 판독가능한 저장 매체를 포함할 수 있다. 저장 디바이스(들)(312)는 내부 또는 외부 메모리일 수 있고, 일부 예에서는 비휘발성 저장 요소를 포함할 수 있다. 저장 디바이스(들)(312)는, 메모리 카드(예를 들어, 표준 용량(SDSC), 대용량(SDHC) 및 확장된 용량(SDXC) 포맷을 포함하는 보안 디지털(SD) 메모리 카드), 외부 하드 디스크 드라이브, 및/또는 외부 솔리드 스테이트 드라이브를 포함할 수 있다.

I/O 디바이스(들)(314)는, 수신기 디바이스(300)에 대한 입력을 수신하고 출력을 제공하도록 구성될 수 있다. 입력은, 예를 들어, 터치-감지 스크린, 트랙 패드, 트랙 포인트, 마우스, 키보드, 마이크로폰, 비디오 카메라 또는 입력을 수신하도록 구성된 기타 임의의 유형의 디바이스 등의 입력 디바이스로부터 생성될 수 있다. 출력은, 예를 들어, 스피커 또는 디스플레이 디바이스 등의 출력 디바이스에 제공될 수 있다. 일부 예에서, I/O 디바이스(들)(314)는 수신기 디바이스(300)의 외부에 있을 수 있고, 예를 들어, 범용 직렬 버스(USB) 프로토콜 등의 표준화된 통신 프로토콜을 이용하여 수신기 디바이스(300)에 동작적으로 결합될 수 있다.

네트워크 인터페이스(316)는, 수신기 디바이스(300)가, 수신기 디바이스(200) 및 다른 디바이스 또는 서버 등의 외부 컴퓨팅 디바이스와 통신할 수 있게 하도록 구성될 수 있다. 또한, 수신기 디바이스(300)가 스마트폰을 포함하는 예에서, 네트워크 인터페이스(316)는 수신기 디바이스(300)가 셀룰러 네트워크와 통신할 수 있게 하도록 구성될 수 있다. 네트워크 인터페이스(316)는, Ethernet 카드, 광 트랜시버, 무선 주파수 트랜시버, 또는 정보를 전송 및 수신할 수 있는 기타 임의의 유형의 디바이스 등의 네트워크 인터페이스 카드를 포함할 수 있다. 네트워크 인터페이스(316)는, 예를 들어, GSM(Global System Mobile Communications) 표준, CDMA(Code Division Multiple Access) 표준, 3GPP(3rd Generation Partnership Project) 표준, 인터넷 프로토콜(IP) 표준, WAP(Wireless Application Protocol) 표준, Bluetooth, ZigBee, 및/또는 802.11 표준들 중 하나 이상 등의 IEEE 표준뿐만 아니라 이들의 다양한 조합 등의, 하나 이상의 통신 프로토콜에 따라 동작하도록 구성될 수 있다.

도 3에 도시된 바와 같이, 시스템 메모리(304)는, 저장된 운영 체제(306), HTML 브라우저(309) 및 애플리케이션(308)을 포함한다. 운영 체제(306)는, 중앙 처리 유닛(들)(302) 및 수신기 디바이스(300)의 다른 하드웨어 컴포넌트들과 애플리케이션(308)의 상호작용을 용이하게하도록 구성될 수 있다. 운영 체제(306)는 랩탑 및 데스크탑에 설치되도록 설계된 운영 체제일 수 있다. 예를 들어, 운영 체제(306)는 Windows(등록 상표) 운영 체제, Linux 또는 Mac OS일 수 있다. 운영 체제(306)는, 스마트폰, 태블릿, 및/또는 게임 디바이스에 설치되도록 설계된 운영 체제일 수 있다. 예를 들어, 운영 체제(306)는, Android, iOS, WebOS, Windows Mobile(등록 상표) 또는 Windows Phone(등록 상표) 운영 체제일 수 있다. 여기서 설명된 기술들은 특정한 운영 체제로 제한되지 않는다는 점에 유의해야 한다.

애플리케이션(308)은, 수신기 디바이스(300) 내에 구현되거나 수신기 디바이스(300)에 의해 실행되는 임의의 애플리케이션일 수도 있고, 수신기 디바이스(300)의 컴포넌트들 내에 구현되거나 포함될 수 있고, 이들에 의해 동작가능하며, 이들에 의해 실행되며, 및/또는 이들에 동작적으로/통신가능하게 결합될 수 있다. 애플리케이션(308)은 수신기 디바이스(300)의 중앙 처리 유닛(들)(302)로 하여금 특정한 기능을 수행하게 할 수 있는 명령어들을 포함할 수 있다. 애플리케이션(308)은 for-loops, while-loop, if-statement, do-loop 등의 컴퓨터 프로그래밍 문장으로 표현되는 알고리즘을 포함할 수 있다. 또한, 애플리케이션(308)은 제2 스크린 애플리케이션을 포함할 수 있다.

다양한 이벤트 테이블은 이벤트에 대한 정보를 제공할 수 있다. 이들은, 그 전체 내용이 참조로 포함되는, 2014년 4월자 TDO Parameters Table (TPT) of ATSC A/105:2014: "ATSC Candidate Standard: Interactive Services Standard", 이벤트 메시지 테이블(EMT), 이벤트 스트림 테이블(EST) 등의 테이블을 포함할 수 있다. 이들은 단지 예시일 뿐이고, 이벤트 및/또는 동작 정보를 운반하는 임의의 테이블 또는 데이터 구조는 여기서는 이벤트 테이블이라고 지칭될 수 있다.

애플리케이션 테이블과 이벤트 테이블은 별개로 명시된다. 어떤 경우에는 이들은 결합될 수도 있다. 또한 다른 유형의 테이블들이 정의될 수도 있다. 예를 들어, 서비스 목록 테이블은 서비스 레벨 정보를 제공할 수 있다. 어떤 경우에는 시그널링 테이블이 정의될 수 있다. 본 개시내용에서 설명된 기술들은, 하나의 엔티티로부터 또 다른 엔티티로 동적으로 전달될 필요가 있는 임의의 이러한 테이블들에 적용가능하다. 동적 통신이란, 실시간으로 한 엔티티로부터 또 다른 엔티티로 그 내부의 테이블 또는 정보의 새로운 또는 업데이트된 버전을 전송할 수 있다는 것을 말한다.

동작은, 전통적인 데이터 서비스로 인코딩되든 하나 이상의 워터마크로 인코딩된 비트스트림 내에서든, 방송 기반 시스템 또는 광대역 기반 시스템을 이용하는 전달되는 등의 임의의 메커니즘에 의해 전달되는 통보에 의해 시작될 수 있는 이벤트 전달의 결과로서 취해질 수 있다.

일반적으로, 이벤트는, 다음과 같은 속성(attribute)들 중 하나 이상을 갖는 이벤트 스트림들 내에 포함될 수 있다,

schemeIdUri는 이벤트 스트림의 유형의 전역적인 고유 식별자이다;

value는 schemeIdUri에 의해 범위가 지정되는 이벤트 스트림의 서브유형의 ID이며;

timescale은 이벤트 스트림 내의 이벤트 타이밍에 이용되는 타임 스케일이다.

이벤트 스트림 내의 각각의 개별 이벤트는 다음과 같은 추가 속성들 중 하나 이상을 가질 수 있다.

presentationTime은 이벤트의 시작 시간이다;

duration은 이벤트 지속시간이다;

id는 이벤트 스트림 내에서 이벤트의 고유 식별자이다; 및

데이터는 이벤트에 응답하는 애플리케이션에 의해 이용되는 이벤트에 수반되는 데이터이다.

이들 속성들 및 그들의 시맨틱의 데이터 유형은 원한다면 수정될 수 있다.

이벤트 스트림의 명시자는 "schemeIdUri" 속성을 선택하고, "value" 속성, 및 "data" 요소가 포함되어 있는지와 포함되어 있다면 그 구조가 무엇인지 등의 특성들의 가능한 값을 결정할 수 있다.

방송 기반 시스템에서의 이벤트들의 전달은, 바람직하게는, ROUTE/DASH(Real-time Object delivery over Unidirectional Transport/ Dynamic Adaptive Streaming over HTTP) 기반의 서비스 또는 MMT(MPEG Media Transport) 기반의 서비스를 이용한다. ROUTE/DASH 및 MMT는, 참조로 본 명세서에 포함되는 http://atsc.org/candidate-standard/a331-atsc-candidate-standard-signaling-delivery-synchronization-and-error-protection/에서 이용가능한 ATSC A/331 Candidate Standard에 정의되어 있다. MMT는, 그 전체 내용이 참조로 본 명세서에 포함되는, ISO/IEC: ISO/IEC 23008-1, "Information technology-High efficiency coding and media delivery in heterogeneous environments-Part 1: MPEG media transport (MMT),"에서 설명되어 있다. MMT는 "MMT 엔티티에 의해 처리되고 다른 MPU들과는 독립적으로 프리젠테이션 엔진에 의해 소비될 수 있는 미디어 데이터 항목"으로서 MPU(MMT 패키지 처리 유닛)를 정의한다. ROUTE/DASH 기반 시스템을 통해 전달되는 방송 이벤트와 관련하여, 이벤트들은 DASH 명세에서 정의된 이벤트 전달을 위한 2가지 메커니즘 중 하나를 이용하여 DASH 이벤트로서 전달될 수 있다. 제1 메커니즘은 MPD(Media Presentation Description)의 기간 요소에 나타나는 EventStream 요소(들)이다. 제2 메커니즘은 표현 세그먼트에 나타나는 'emsg' 박스(들) 내에 있는 이벤트(들)이며, 여기서 그들의 존재는, MPD 내의 표현의 하나 이상의 InbandEventStream 요소에 의해 시그널링된다. 제1 및 제2 메커니즘은, 원한다면, 혼합되어, EventStream 요소를 통해 전달된 일부 이벤트와 'emsg' 박스를 통해 전달된 다른 이벤트들을 포함하는 단일 이벤트 스트림을 야기할 수 있다.

DASH 표준 ISO/IEC 23009-1:2012 5.10.2절 Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats에 정의된 EventStream 요소는, "정적" 이벤트들, 즉, 타이밍이 미리 알려지는 이벤트들에 특히 적합하다. EventStream 요소는 일반적으로 이벤트 요소들의 목록으로서 간주될 수 있다. 각각의 EventStream 요소는 schemeIdUri 속성과 EventStream의 이벤트들의 유형을 식별하는 value 속성, 및 이벤트 프리젠테이션 시간 및 지속시간에 대한 기준 타임 스케일을 나타내는 타임스케일 속성을 가질 수 있다. EventStream 요소 내의 각각의 이벤트는 (기간의 시작에 관한) 이벤트의 시작 시간 presentationTime 속성, 이벤트의 지속시간을 나타내는 duration 속성, 이벤트 인스턴스를 식별하는 id 속성, 및 이벤트에 의해 시작된 동작을 실행하기 위한 정보를 제공하는 데이터 요소를 가질 수 있다. 데이터 요소의 구조는 이벤트의 유형에 의해 결정된다. 기간 내에는 상이한 유형들의 복수의 EventStream 요소가 있을 수 있다.

일부 DASH-특유의 schemeIdUri 식별자들은, 동반되는 값 식별자들의 이용법 및 대응하는 이벤트들의 의미와 함께 DASH 표준의 5.10.4절에 정의되어 있다. 추가적인 schemeIdUri 식별자들이 원한다면 정의될 수 있다. schemeIdUri 값의 "소유자"는 그것이 고유하다고(예를 들어, 소유자에 의해 통제되는 URI에 기초한다고) 보장할 수 있고 이벤트들의 대응하는 value 속성의 이용 및 의미를 정의할 수 있다.

ATSC-특유의 schemeIdUri 식별자는, 이벤트들의 동반하는 value 식별자들의 이용법 및 의미와 함께 정의될 수 있다. 다른 schemeIdUri 식별자들은, 원한다면, 특정한 애플리케이션에 대해, 애플리케이션 개발자에 의해 정의될 수 있다.

표현의 InbandEventStream 요소는 그 표현의 세그먼트들 내의 'emsg' 박스들의 존재를 나타낸다. InbandEvent 요소는 나타날 수 있는 이벤트의 유형을 나타내는 속성들 schemeIdUri 및 value를 가질 수 있다. 표현의 세그먼트에 나타나는 각각의 'emsg' 박스는 이들이 속하는 이벤트 스트림을 나타내는 필드들 schemeIdUri 및 값, 및 프리젠테이션 시간 및 지속시간에 이용되는 기준 타임 스케일을 나타내는 필드들 (a) timescale, (b) 'emsg' 박스가 나타나는 세그먼트 내의 임의의 액세스 유닛의 가장 이른 프리젠테이션 시간에 관한 이벤트의 시작 시간을 나타내는 presentation_time_delta, (c) 이벤트의 지속시간을 나타내는 event_duration, (d) 이벤트 인스턴스를 식별하는 id, 및 (e) 이벤트에 의해 시작된 동작을 실행하는 것이 필요한 경우 message_data를 가질 수 있다. 'emsg' 박스에서 전달되는 이벤트들은, "동적" 이벤트 - 즉, 타이밍이 마지막 순간에만 알려지게 되는 이벤트(예를 들어, 풋볼 게임에서 터치다운이 기록될 때 애플리케이션에 의해 어떤 동작을 시작하는 이벤트)에 특히 적합하다.

도 4를 참조하면, DASH 표준에 정의된 'emsg' 박스의 구조가 도시되어 있다.

도 5를 참조하면, MMT 기반 시스템을 통해 전달된 방송 이벤트에 관하여, 이벤트는 애플리케이션 이벤트 정보(AEI) 문서라고 지칭되는 XML 문서로 전달될 수 있다. 이 문서는 정적 이벤트에 적합하다. AEI가 방송을 통해 전달될 때, AEI는 서비스에 대한 서비스 계층 시그널링에서 전달될 수 있다. MMT 기반 서비스의 이벤트는 MPU의 'evti' 박스에서도 운반될 수 있다. 이 기술은 동적 이벤트에 매우 적합하다.

도 6을 참조하면, 'evti' 박스의 예시적인 구조가 도시되어 있다. 이러한 'evti' 박스는 MPU 시작 부분, 'ftyp' 박스 이후에, 그러나 'moov' 박스 이전에 나타나거나, 'moof' 박스 바로 앞에 나타날 수도 있다. 이들 박스들 - 'ftyp', 'moov', 'moof'는, 본 명세서에 참조로 포함되는, ISO/IEC 14496-15: 2014: "Information technology - Coding of audio-visual objects - Part 15: Carriage of NAL unit structured video in the ISO base media file format"에 설명된 바와 같다.

MMT 이벤트 디스크립터는, 본 명세서에 참조로 포함되는 ISO/IEC 23008-1에 정의된 바와 같이 MMT 패키지 테이블(MPT)에서 서명될 수 있다.

도 7을 참조하면, MMT 패키지 테이블(MPT) 메시지는 자산의 목록을 포함한 MMT 패키지에 관련된 정보를 제공한다. 시그널링 메시지의 자산-레벨 디스크립터 부분에 포함된 inband_event_descriptor()는 MPU 내의 이벤트의 존재를 나타낸다.

본 명세서에 설명된 바와 같이, 방송 전달은 MPD나 AEI에서의 이벤트의 일괄 전달 및 표현 세그먼트나 MPU에서의 이벤트의 증분 전달을 지원하지만, 광대역 전달도 역시 일괄 전달 및 증분 전달을 지원할 수 있다. 서비스의 이벤트들이 (특히 정적 이벤트에 적합한) 일괄 모드로 광대역을 통해 전달될 때, 이들은 HTTP를 이용하여 광대역을 통해 전달되는 MPD 또는 HTTP를 이용하여 광대역을 통해 전달되는 AEI에서 EventStream 요소에서 전달될 수 있다. 광대역을 통해 전달되는 경우, MPD 및 AEI는, 서비스에서 SLT에서 시그널링되는 이 목적을 위한 베이스 URL(또는 재배포 기술에서 워터마크로부터 획득되는 URL)을 이용하여, HTTP 요청에 의해 이용가능할 수 있다.

광대역을 통해 MPD 또는 AEI에 대한 스케줄링된 업데이트를 검색하기 위한 타이밍 및 위치는, MPD 또는 AEI의 메타데이터 래퍼(metadata wrapper)에 있는 validUntil 및 nextURL 속성에 의해 제공된다. 스케줄링되지 않은 업데이트 가용성은 동적 이벤트를 통해 비동기적으로 시그널링된다.

서비스에 대한 이벤트들이 (특히 동적 이벤트에 적합한) 광대역을 통해 증분적으로 전달될 때, 그 서비스의 임의의 컴포넌트들이 광대역을 통해 전달되고 있다면 광대역을 통해 전달되고 있는 콘텐츠의 DASH 세그먼트의 'emsg' 박스로서 전달될 수 있고, 또는 이들은 SLT로부터 획득된 동적 이벤트 서버의 URL을 이용하여 HTTP 서버를 폴링(poll)함으로써 취득되거나, 이들은, SLT로부터 획득된 동적 이벤트 웹소켓 서버의 URL을 이용하여 동적 이벤트 웹소켓 서버를 통해 취득될 수 있다.

HTTP 서버 또는 웹 소켓을 통해 전달되는 이벤트의 포맷은 ROUTE/DASH 기반 서비스에 대해 여기서 설명된 'emsg' 박스의 포맷 또는 MMT 기반 서비스에 대해 위에서 정의된 'evti' 박스의 포맷과 동일할 수 있지만, ROUTE/DASH의 경우에는 MPD ID와 Period ID가 접두사로 이용되고 MMT의 경우에는 Asset ID와 MPU 시퀀스 번호가 접두사로 이용된다. ROUTE/DASH의 경우, presentation_delta는 참조된 기간의 시작 시간에 대해 상대적이며, MMT의 경우 presentation_delta는 참조된 MPU의 가장 이른 액세스 유닛 프리젠테이션 시간에 대해 상대적이다.

재배포 설정에서, 본 명세서에 참조로 포함되는 A/336 "Audio/Video Watermark Payload" 표준에 설명된 바와 같이, 이벤트는 워터 마크를 통해 취득될 수 있다. 이벤트는 또한, 오디오 스트림의 개인 데이터 영역에서 전달될 수도 있다.

광대역 기술 및/또는 방송 기술에 의해 또는 수신기를 통해 국지적으로 이용가능한 이벤트와 같이, 다양한 소스로부터의 이벤트를 등록하기 위한 기술을 포함하는 것이 바람직하다. 풋볼 경기와 관련된 애플리케이션의 모든 이벤트와 같이, 특정한 이벤트의 수신을 등록하는 것이 유익할 수 있지만, 풋볼 경기의 필드 골이 발생하는 이벤트와는 달리 풋볼 경기의 터치다운이 발생하는 이벤트 등의, 특정한 이벤트 유형만에 대해 등록하는 능력을 포함하는 것이 바람직할 수 있다. 특정한 수신기에 이벤트를 전송하는 선택적 능력의 경우, 또는 수신기로부터 애플리케이션으로 이벤트를 전송하는 선택적 능력의 경우, 등록된 선택된 유형의 이벤트 및 특히 등록된 선택된 서브이벤트는 전송기로부터 수신기로 또는 수신기로부터 애플리케이션으로 제공되는 반면 다른 유형의 이벤트 및 서브이벤트는 제공을 생략할 수 있다. 특정한 수신기에 이벤트를 전송하는 선택적 능력이 없는 경우, 등록된 선택된 유형의 이벤트, 특히 등록된 선택된 서브이벤트는, 수신기의 튜너에 의해 등록된 이벤트 및 서브이벤트만 포함하도록 필터링될 수 있다. 일부 경우에, 특정한 이벤트의 수신에 등록해 있는 동안, 제공되고 있는 단일 데이터 구조에서 복수의 이벤트를 함께 그룹화함으로써 수신 시스템의 계산 효율을 증가시키고 이러한 이벤트가 수신될 가능성을 증가시키는 것이 바람직할 수 있다.

런타임 플랫폼에서와 같이, 예를 들어 수신기에서 실행중인 애플리케이션은 특정한 이벤트가 발생할 때 통보받을 수 있다. 특정한 유형의 이벤트가 발생할 때 통보받기를 원하는 애플리케이션은 그 유형의 이벤트에 대해 이벤트 제공자에게 등록할 수 있고 또한 콜백 루틴(callback routine)의 명칭을 제공할 수도 있다.

이벤트 등록 API는 다음과 같이 정의될 수 있다:

method: "org.atsc.event.register"

params: 요구되는 Event 유형(도 8 참조), 및 콜백 루틴 명칭, 및 일부 유형의 이벤트의 경우에는, 하나 이상의 추가 인수 객체

이벤트 등록 API에 대한 예시적인 JSON 스키마는 다음과 같이 정의될 수 있다:

eventType: 이 문자열은 도 8의 eventType 열에 명시된 값에 대응해야 한다.

eventArg: eventArg 객체는 eventType의 소정 값들에 대해 존재해야 하며 그렇지 않으면 부재해야 한다. 특정한 eventType에 대한 eventArg 객체의 요구되는 구조는 도 8에 주어진 참조에서 정의된다. eventStream 유형의 이벤트들만이 eventArg가 존재한다.

callBackFunction: 콜백 함수

또 다른 예에서, 이벤트 등록 API에 대한 예시적인 JSON 스키마는 다음과 같이 정의될 수 있다:

메소드: org.atsc.event.register의 호출 결과는 다음과 같을 수 있다: regID(String): 등록이 성공적이면 이 등록과 연관된 등록 식별자 문자열이고 등록이 실패하면 null이다.

추가적인 변형에서 성공/오류 코드가 결과로서 반환될 수 있다. 원하는 경우, 결과 오류 코드는 다음과 같을 수 있다.

예를 들어, rCode(오류 코드 - 정수):

200 = 성공적인 등록

400 = 등록 실패(이러한 이벤트 유형 없음)

401 = 등록 실패(이러한 schemeIdUri 없음)

402 = 등록 실패(이러한 값 없음)

404 = 등록 실패

이벤트의 등록 능력을 용이하게 하기 위해, 이벤트의 소정의 서브유형만이 애플리케이션에 의해 요청되는 경우, 이벤트 등록 API에 대한 JSON 스키마는 수정될 수 있다. 이러한 스트림 이벤트의 경우, 이벤트 등록 API는 schemeIdUri 및 value 속성을 포함하도록 보강될 수 있다. 이것은 애플리케이션이 이벤트의 소정의 서브유형만을 요청하는 것을 허용한다. 이로 인해, 관심대상 이벤트만 결정하기 위해 이벤트 서브유형의 필터링을 수행할 필요가 없고 이러한 이벤트의 제공자가 바람직한 이벤트만 선택적으로 제공할 수 있으므로 더 효율적인 애플리케이션이 된다.

수정된 JSON 스키마는 다음과 같을 수 있다:

예를 들어, rCode(오류 코드 - 정수):

200 = 성공적인 등록

400 = 등록 실패(이러한 이벤트 유형 없음)

401 = 등록 실패(이러한 schemeIdUri 없음)

402 = 등록 실패(이러한 값 없음)

404 = 등록 실패

수정된 JSON 스키마의 파라미터는, 이벤트 서브유형을 식별하는 eventArg.schemeIdUri 특성을 포함하며, 바람직하게는 URI이다. 수정된 JSON 스키마의 파라미터는 이벤트 서브 유형 eventArg.schemeIdUri에 의해 식별된 이벤트의 값을 명시하는 eventArg.value 특성을 포함한다.

eventArg.value의 포함은 등록할 때 이벤트들의 추가 필터링을 허용한다. 따라서, 이제 애플리케이션은, 파라미터 eventType에 의해 제공되는 명시된 이벤트 유형, 그 다음 파라미터 eventArg.schemeIdUri에 의해 명시된 특정한 식별자, 및 추가로 파라미터 eventArg.value에 의해 명시된 이 식별자에 대응하는 소정 유형의 값에 대응하는 이벤트들만 수신기에 등록할 수 있다. eventArg.value의 추가는, 동일한 eventArg.schemeIdUri이지만 파라미터 eventArg.value에 의해 명시된 관심대상 애플리케이션의 값과는 상이한 값에 대응하는 소정 유형의 이벤트들에는 관심없는 애플리케이션이 애플리케이션에 의해 수신되지 않도록 허용하여 관심대상이 아닌 이러한 이벤트를 처리하는 애플리케이션의 부담을 경감시킨다. 이것은 더욱 목표화되고 효율적인 애플리케이션의 작성을 허용한다.

eventStream 유형 이벤트에 대해 등록하는 애플리케이션의 예는 다음과 같다:

이 예에서 "eventArg"는 "schemeIdURI" 특성만을 포함한다.

eventStream 유형 이벤트에 대해 등록하는 애플리케이션의 또 다른 예는 다음과 같다:

상기 예와 본 문서에서, 다음과 같은 표기법이 사용된다:

--> 수신기에 전송된 데이터

<-- 애플리케이션에 전송된 데이터

이 예에서 "eventArg"는 "schemeIdURI" 특성과 "value" 특성을 포함한다. 따라서 이 경우 urn:uuid:afxd-ghji:2016과 동등한 "schemeIdURI" 및 "1"과 동등한 "value"에 대응하는 이벤트 스트림 내의 이벤트들만이 애플리케이션에 전달된다. 예를 들어, 이벤트 스트림이 urn:uuid:afxd-ghji:2016과 동등한 "schemeIdURI" 및 "2"와 동등한 "value"에 대응하는 이벤트를 수신한다면, 이것은 "value" "2"는 등록된 값 "1"과 일치하지 않으므로 애플리케이션에 전달되지 않을 것이다.

JSON 스키마는 또한, eventType이 "eventStream"과 동등한 "type"을 가질 때 schemeIdUri가 존재하거나(또는 원한다면 존재해야 하거나) 그 값이 존재할 수 있는 등의, 추가 제약 조건을 정의한다. 그렇지 않다면(즉, eventType이 "eventStream"이외의 "type"을 가질 때) schemeUri 및 value는 존재하지 않는다.

JSON 스키마는 또한, schemeIdUri 및 value 특성들이 포함되지 않은 경우 eventType의 모든 이벤트가 애플리케이션에 통보되어야 하는 것과 같은, 추가 제한 조건을 정의한다. schemeIdUri 및 value 특성들이 포함된다면, 포함된 schemeIdUri와 일치하는 schemeIdUri 및 포함된 값과 일치하는 값을 갖는 eventstream과 동등한 eventType의 이벤트들만이 애플리케이션에 통보된다.

또 다른 변형에서, 단일 호출을 이용하여 복수의 eventType 및 서브유형의 세트가 등록될 수 있다. JSON-RPC는 JSON으로 인코딩된 원격 프로시저 호출 프로토콜이다. 단일 호출을 이용하여 복수의 eventTypes 및 서브유형 세트의 등록을 허용하는 능력을 제공하는 것은, 각각의 JSON-RPC 호출이 예를 들어 WebSocket을 통한 통신을 요구하므로 요구되는 JSON-RPC 호출 수를 감소시킨다. 아래에 나타낸 예시적인 JSON 스키마는 단일의 호출로 복수의 서브유형을 등록하는 어레이를 포함한다.

또 다른 변형 예에서, eventTypes 및 sub-types의 등록을 위한 확장성 피처를 포함하는 것이 바람직하다. 이것은 이용가능한 등록된 유형들의 수정에 있어서 추가적인 유연성을 포함한다. 아래에 나타낸 예시적인 JSON 스키마는 확장성 피처를 포함한다.

또 다른 변형 예에서, schemeIdUri 및 value를 eventArg 객체의 특성으로 만드는 대신 이들 두 특성을 서브유형 객체의 외부에 표시하는 것이 바람직하다. 이런 방식으로 schemeIdUri 특성이 존재하지 않을 때 value 특성이 존재하지 않아야 한다는 요구조건이 있을 수 있다. 아래에 나타낸 예시적인 JSON 스키마는 서브유형 객체 외부의 표시를 포함한다.

잠재적으로 악의적인 코드가 애플리케이션에 의해 실행되지 않도록 다양한 보안상의 이유로 바람직하게는 callbackFunction이 JSON 스키마에 포함되지 않지만, 원하는 경우 각각의 JSON 스키마에 추가로 정의될 수 있다. 또한, 오류가 발생하지 않는 한 바람직하게는 JSON 스키마에 대한 응답은 논(none)이다.

도 8을 참조하면, 예시적인 이벤트 등록 테이블이 도시되어 있다. 특히, eventStream 유형은 서브이벤트들을 포함할 수 있는 반면, 바람직하게는, 다른 eventType의 어느 것도 서브이벤트를 포함하지 않는다.

이벤트에 대한 효과적인 등록이 유익하지만, 이러한 등록을 효과적으로 취소하는 것도 유익하다. 특히, 이벤트 통보에 대해 이전에 등록한 애플리케이션은, 이전에 등록한 이벤트 통보 수신에 더 이상 관심이 없을 때 이전 등록을 취소할 수 있다. 예로서, 애플리케이션은 소정 유형의 이벤트를 수신기에 등록할 수 있고 등록한 이벤트에 대한 통보를 수신할 때 사용자에게 방송중인 TV 프로그램에 관련된 다양한 통보를 보여주기 시작할 수 있다. 그러나, 사용자는 얼마나 시간이 지난 후에 TV 시청에 대한 집중을 방해한다는 이유로 다양한 통보를 원하지 않는다고 결정할 수 있다. 그 다음, 사용자는 통보를 디스에이블하지만 다른 것들은 계속 실행할 것을 애플리케이션에게 요청할 수 있다.

이 경우 이벤트의 통보를 수신하기 위해 이전에 등록한 애플리케이션은, 이전에 등록한 이벤트 통보 수신에 더 이상 관심이 없으면 등록 취소 API를 이용하여 이전 이벤트 등록을 취소할 수 있다. 예시적인 이벤트 등록 취소 API는 아래에 나타낸 바와 같을 수 있다.

regID는 등록 식별자 값(이전에 성공적인 메소드 org.atsc.event.register 호출로부터의 출력)에 대응하는 문자열이다. 결과는 seCode(정수): 성공/오류 코드(값: 200 = 등록 취소 성공, 400: 무효한 등록 ID, 410: 등록 실패(유효한 등록 ID))이다.

대안으로서 이전 등록을 취소하기 위한 입력 파라미터로서 등록 식별자를 이용하는 것과는 대조적으로, 등록에 이용된 것과 동일한 입력 파라미터를 org.atsc.event.register 메소드에 되돌려 보내는 API가 등록 취소에 이용될 수 있다. 이 대안에서 이벤트 등록 취소 API는 아래에 나타낸 것과 같을 수 있다.

params: 요구되는 Event 유형(도 8 참조), 및 콜백 루틴 명칭, 및 일부 유형의 이벤트의 경우에는, 하나 이상의 추가 인수 객체 object.params JSON Schema:

eventType 문자열은 도 8에 명시된 값에 대응한다.

eventArg는 eventType의 소정 값들에 대해 존재하고 그렇지 않으면 부재하는 객체이다. 특정한 eventType에 대한 eventArg 객체의 요구되는 구조는 도 8에 주어진 참조에서 정의된다.

seCode(정수)의 결과는 성공/오류 코드이다. (값: 200 = 등록 취소 성공, 400: 무효한 등록, 410: 등록 실패).

등록된 이벤트가 발생할 때마다 JSON RPC 메시지가 수신기에서 애플리케이션으로 비동기적으로 전달될 수 있다. 수신기가 특정한 유형의 이벤트가 발생했음을 검출하고 현재 실행중인 애플리케이션이 그 유형의 이벤트에 대해 통보받도록 등록한 경우, 단말기는 eventType 및 그 이벤트에 관련된 데이터(있는 경우)를 포함하는 WebSocket 메시지를 애플리케이션에 발행해야 한다. 통보 메시지는 다음과 같이 포매팅될 수 있다:

ParameterA는 도 8 eventType 열로부터의 유효한 eventType 문자열이어야 한다.

ParameterB는, 있다면, JSON 객체로서 포함된 통보와 연관된 데이터로 구성된다. 각각의 유형의 이벤트에 대한 통보 메시지의 정의는, (있다면) 반환된 JSON eventData 객체의 포맷을 포함한다.

ParameterC는 통보들과 그들의 대응하는 응답을 연관시키기 위해 JSON RPC에 의해 요구되는 정수이어야 한다.

params: 요구되는 Event 유형, 및 일부 유형의 이벤트의 경우, 이벤트 데이터: params JSON 스키마:

여기서:

eventType은 도 8로부터의 유효한 eventType 문자열이어야 한다;

eventData는, 있다면, JSON 객체로서 포함된 통보와 연관된 데이터로 구성된다. 각각의 유형의 이벤트에 대한 통보 메시지의 정의는, 반환된 JSON 데이터 객체의 포맷을 포함한다. 일부 이벤트의 경우, eventData는 생략된다.

이벤트 스트림 통보는, eventStream 이벤트 유형에 대해 등록되었고, 현재 선택된 서비스의 콘텐츠 또는 애플리케이션이 Event Stream 이벤트에 대해 등록했을 때 제공된 schemeIdURI의 값과 일치하는 현재 재생중인 콘텐츠에서 이벤트 스트림이 발견된다면, 현재 실행중인 애플리케이션에 대해 수신기에 의해 발행될 수 있다. 스트림 이벤트 통보 API는 아래와 같을 수 있다.

EventData: 아래에 정의된 JSON 스키마를 준수하는 JSON 객체이다.

EventData JSON 객체는 다음과 같은 JSON 스키마에 의해 명시될 수 있다.

스트림 이벤트 통보에 포함된 스트림 이벤트 객체(즉, eventData 스키마)는 객체의 JSON 데이터 유형에 스트림 이벤트 데이터의 데이터 유형을 포함시킴으로써 제한될 수 있다. 이것은 각각의 스트림 이벤트가 애플리케이션에 전달할 필요가 있는 데이터에 대한 그 자신의 JSON 데이터 유형을 정의하는 것을 허용한다.

스트림 이벤트 통보에 포함된 스트림 이벤트 객체는 timescale에 대해 0의 값을 나타내는 것을 금지하는 제약을 스트림 이벤트 데이터 정의에 포함시킴으로써 제한될 수 있다. DASH에서와 같이, 초단위의 프레젠테이션 시간의 값은 이 presentationTime의 값을 나눈 값이며 timescale의 값은 timescale에 대해 0의 값을 금지할 수 있다.

스트림 이벤트 통보에 포함된 스트림 이벤트 객체는 timescale에 대해 허용되는 최대값과 id에 대해 전체 32 비트 timescale 값을 허용함으로써 제한될 수 있다.

스트림 이벤트 통보에 포함된 스트림 이벤트 객체는 복수의 이벤트의 통보를 허용하는 것을 포함함으로써 제한될 수 있다. 이것은 복수의 이벤트 및 이벤트 데이터를 전달하기 위해 단일 JSON-RPC 호출을 이용하는 것을 용이하게 한다. 이것은, 하나의 JSON-RPC 호출을 이용하여 복수의 이벤트 통보가 전송될 수 있기 때문에 더 적은 수의 JSON-RPC 호출을 허용한다. 또한, 각각의 JSON-RPC 호출은 예를 들어 WebSocket을 통한 통신을 요구하기 때문에, 이것은 시스템 안정성을 높인다. 또한, 이것은 데이터 무결성을 보존하기 위해 복수의 이벤트 데이터를 원자적으로 전송(atomically sending)하는 것을 허용할 수 있다.

스트림 이벤트 통보에 포함된 스트림 이벤트 객체는 presentationTime에 대해 정의된 디폴트 값을 포함함으로써 제한될 수 있고, 이것은 이벤트 통보에 이 속성을 포함하는 것을 생략하는 것을 허용한다.

EventData가 준수하는 예시적인 이벤트 통보 스트림 이벤트 스키마는 아래에 도시된 바와 같을 수 있다:

EventData가 준수하는 또 다른 예시적인 이벤트 통보 스트림 이벤트 스키마는 아래에 도시된 바와 같을 수 있다: 이 스키마에서, "객체"의 데이터 유형이 "데이터"에 대해 이용된다. 또한, 특성들 "presentationTime", "duration", "id" 및 "data"로 구성된 객체들의 어레이 "Event"가 포함된다.

문자열 또는 객체 중 어느 하나가 되도록 허용된 데이터의 데이터 유형을 포함한 EventData가 준수하는 또 다른 예시적인 이벤트 통보 스트림 이벤트 스키마는 아래에 도시된 바와 같을 수 있다.

각각의 JSON-RPC 호출은, 예를 들어, WebSocket을 통한 통신을 요구하기 때문에 JSON-RPC 호출 수를 감소시키는 이점을 갖는 단일 호출을 이용하여 EventData 내의 복수의 속성들의 어레이가 통보되는 것을 포함한 EventData가 준수하는 또 다른 예시적인 이벤트 통보 스트림 이벤트 스키마는 아래에 도시된 바와 같을 수 있다.

추가적인 한 변형에서, 이벤트의 소스에 관한 트랜스포트 정보는 아래에 예시된 바와 같이 EventData에 포함될 수 있다. 이 경우, 추가적인 특성 "EventTransport"는, 이벤트에 대한 트랜스포트 프로토콜의 유형을, (ROUTE/DASH 트랜스포트를 통해 이벤트가 시그널링되었음을 나타내는) ROUTEDASH 또는 (MMT 트랜스포트를 통해 이벤트가 시그널링되었음을 나타내는) MMT 또는 (알려지지 않은 트랜스포트 프로토콜을 통해 이벤트가 시그널링되었음을 나타내는) UNKNOWN으로서 표시한다.

추가적인 한 변형에서, 아래에서 나타낸 바와 같이, 이벤트의 소스에 관한 트랜스포트 정보는 이벤트에 대한 트랜스포트 프로토콜의 경로를 (이벤트가 방송을 통해 시그널링되었음을 나타내는) "방송" 또는 (이벤트가 광대역 네트워크를 통해 시그널링되었음을 나타내는) "광대역" 또는 (이벤트가 로컬 네트워크 상의 또는 수신기 내부의 모듈을 통해 시그널링되었음을 나타내는) "로컬" 또는 (이벤트가 오디오 및/또는 비디오 워터마크를 통해 시그널링되었음을 나타내는) "워터마크" 또는 UNKNOWN"으로서 표시하는 추가적인 속성 EventTransportPath에 포함될 수 있다.

상기에서 도시된 것들에 비해 상이한 데이터 유형들이 요소에 이용될 수 있다. 예를 들어, unsignedByte 데이터 유형 대신 unsignedShort 데이터 유형이 이용될 수 있다. 또 다른 예에서 부호없는 Byte 데이터 유형 대신 String 데이터 유형이 이용될 수 있다.

JSON 스키마에서의 어레이의 경우 "minItems": 1 대신에 대안적인 실시예들은 minItems에 대해 상이한 값을 정의할 수 있다. 예를 들어, 일부 경우에 "minItems": 0이 본 문서에서 설명된 JSON 스키마에서 정의될 수 있다.

다양한 JSON 스키마 특성 명칭들이 변경될 수 있다. 예를 들어 "eventStream"대신 이 특성은 "StreamEvents" 또는 "StreamEvent" 또는 "EventData"또는 "eventData"라고 부를 수 있다. 유사하게, 특성 "eventArg" 대신, 이것은 "eventSubType"의 "subType" 또는 "sub-type"이라고도 부를 수 있다. 모든 이러한 상이한 명칭들은 본 문서의 범위 내에 있다.

또한 대문자와 소문자의 명칭들(upper and lower case names)은 본 문서에서 서로 바꾸어 사용할 수 있다, 예를 들어 "eventStream"과 "EventStream"은 동일한 것을 의미할 수 있다. 또한 "eventData"및 "EventData"는 동일한 것을 의미할 수 있다. 또한 "schemeIDURI", "schemeIdURI", "schemeIDUri", "schemeIdUri"는 모두 동일한 것을 의미할 수 있다.

JSON 스키마에 "요구됨"으로 마킹된 특성들 중 일부는 요구되지 않을 수도 있다. 다른 경우에는 JSON 스키마에서 "요구됨"으로 마킹되지 않은 특성들 중 일부가 대신에 "요구됨"으로 될 수 있다. 신택스를 속성으로서 시그널링하는 것 대신에 요소로서 시그널링될 수 있다. 신택스를 요소로서 시그널링하는 것 대신에 속성으로서 시그널링될 수 있다. 신택스를 특성으로서 시그널링하는 것 대신에 속성으로서 또는 요소로서 시그널링될 수 있다.

다양한 필드들의 비트 폭은 변경될 수 있다, 예를 들어 비트스트림 신택스의 요소 또는 필드에 대해 4 비트 대신에 5 비트 또는 8 비트 또는 2 비트 또는 38 비트가 이용될 수 있다. 여기서 나열된 실제 값들은 단지 예일 뿐이다.

일부 실시예들에서, x 내지 y까지의 코드 값들의 범위 대신에, x+p 또는 x-p 내지 y+d 또는 y-d까지의 코드 값들의 범위가 예약되어 유지될 수 있다. 예를 들어 2 내지 255의 코드 값들의 범위가 예약된 상태로 유지되는 것 대신에 3 내지 255의 코드 값들의 범위가 예약된 상태로 유지될 수 있다.

XML 포맷 및 XML 스키마 대신에 JSON(JavaScript Object Notation) 포맷 및 JSON 스키마가 이용될 수 있다. 대안으로 제안된 신택스 요소들이, CSV(Comma Separated Values), BNF(Backus-Naur Form), ABNF(Augmented Backus-Naur Form) 또는 EBNF(Extended Backus-Naur Form)를 이용하여 시그널링될 수 있다.

JSON 포맷 및 JSON 스키마 대신, XML 포맷 및 XML 스키마가 이용될 수 있다. 대안으로 제안된 신택스 요소들이, CSV(Comma Separated Values), BNF(Backus-Naur Form), ABNF(Augmented Backus-Naur Form) 또는 EBNF(Extended Backus-Naur Form)를 이용하여 시그널링될 수 있다.

요소 및/또는 속성의 카디널리티(Cardinality)가 변경될 수 있다. 예를 들어 카디널리티가 "1"로부터 "1..N"으로 변경되거나 카디널리티가 "1"로부터 "0..N"으로 변경되거나 카디널리티가 "1"로부터 "0..1"로 변경되거나 카디널리티가 "0..1"로부터 "0..N"으로 변경되거나 카디널리티가 "0..N"으로부터 "0..1"로 변경될 수 있다.

요소 및/또는 속성 및/또는 특성은 상기에서 임의적으로(optional) 표시될 때 요구됨(required)으로 될 수 있다. 요소 및/또는 속성 및/또는 특성은 상기에서 요구됨으로서 표시될 때 임의적으로 될 수 있다.

일부 자식 요소는 부모 요소로서 시그널링되거나 또 다른 자식 요소의 자식 요소로서 시그널링될 수 있다.

상기의 모든 변형들은 본 발명의 범위 내에 있는 것으로 의도한다.

또한, 전술된 실시예들 각각에서 이용된 기지국 디바이스 및 단말 디바이스(비디오 디코더 및 비디오 인코더)의 각각의 기능 블록 또는 다양한 피처들은, 전형적으로 집적 회로 또는 복수의 집적 회로인, 회로에 의해 구현되거나 실행될 수 있다. 본 명세서에서 설명된 기능들을 실행하도록 설계된 회로는, 범용 프로세서, 디지털 신호 프로세서(DSP), 애플리케이션 특유의 또는 범용 애플리케이션 집적 회로(ASIC), 필드 프로그래머블 게이트 어레이(FPGA), 또는 기타의 프로그래머블 로직 디바이스들, 개별 게이트들 또는 트랜지스터 로직, 또는 개별 하드웨어 컴포넌트, 또는 이들의 조합을 포함할 수 있다. 범용 프로세서는, 마이크로프로세서이거나, 대안으로서 프로세서는, 종래의 프로세서, 제어기, 마이크로제어기 또는 상태 머신일 수 있다. 전술된 범용 프로세서 또는 각각의 회로는 디지털 회로에 의해 구성될 수도 있고, 아날로그 회로에 의해 구성될 수도 있다. 또한, 반도체 기술의 진보에 의해 현재의 집적 회로를 대체하는 집적 회로 제작 기술이 출현하면, 이 기술에 의한 집적 회로도 역시 이용될 수 있다.

청구항들은 전술된 정확히 그대로의 구성 및 컴포넌트들로 제한되지 않는다는 것을 이해해야 한다. 청구항들의 범위를 벗어나지 않고 본 명세서에서 설명된 시스템, 방법 및 장치의 배열, 동작 및 상세사항에서 다양한 수정, 변경 및 변형이 이루어질 수 있다.

Claims

스트림 이벤트들을 요청하는 제1 디바이스로서, 상기 요청은 제2 디바이스에 대한 등록 데이터를 포함하고,
(a) 상기 요청은 복수의 각각의 스트림 이벤트에 대한 복수의 등록 필드를 포함하는 등록 데이터를 포함하고, 상기 등록 필드들 중 적어도 하나는 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것이며,
(b) 상기 요청은 schemeIdUri 및 값을 포함하는 등록 필드들을 포함하며, 상기 schemeIdUri는 각각의 상기 스트림 이벤트와 연관된 URI 문자열이며, 상기 값은 상기 schemeIdUri에 의해 식별된 상기 스트림 이벤트들의 특정한 서브유형을 식별하는 문자열인, 제1 디바이스.
제1항에 있어서, 상기 schemeIdUri는 상기 문자열의 데이터 유형과 상기 URI의 포맷을 갖는, 제1 디바이스.
제1항에 있어서, 상기 값은 문자열의 데이터 유형을 갖는, 제1 디바이스.
제1항에 있어서, 상기 등록 데이터는 JSON 스키마(Schema)에 포함되는, 제1 디바이스.
제1항에 있어서, 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것인 상기 등록 필드들 중 적어도 하나를 더 포함하고,
(a) 상기 제1 디바이스가 상기 이벤트 데이터를 수신하는 것은:
(i) 상기 제1 디바이스가 타임스케일(timescale)을 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 타임스케일은 최소값 1과 최대값 4294967295를 갖는 정수임 -;
(ii) 상기 제1 디바이스가 id를 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 id는 최소값 0과 최대값 4294967295를 갖는 정수임 -;
(iii) 상기 제1 디바이스가 데이터를 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택됨 -
중 적어도 하나를 포함하는, 제1 디바이스.
제5항에 있어서, 상기 이벤트 데이터 필드들은 상기 타임스케일을 포함하고, 상기 타임스케일은 최소값 1 및 최대값 4294967295를 갖는 정수인, 제1 디바이스.
제5항에 있어서, 상기 이벤트 데이터 필드들은 상기 id를 포함하고, 상기 id는 최소값 0 및 최대값 4294967295를 갖는 정수인, 제1 디바이스.
제5항에 있어서, 상기 이벤트 데이터 필드들은 상기 데이터를 포함하고, 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택되는, 제1 디바이스.
제2 디바이스에 대한 스트림 이벤트들에 대한 등록 데이터를 포함하는 요청을 하는 것에 응답하는 제1 디바이스를 위한 방법으로서,
(a) 상기 제1 디바이스에 의해 복수의 각각의 스트림 이벤트에 대한 복수의 등록 필드를 포함하는 상기 등록 데이터를 요청하는 단계 - 상기 등록 필드들 중 적어도 하나는 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것임 - ; 및
(b) 상기 제1 디바이스에 의해 schemeIdUri 및 값을 포함하는 상기 등록 필드들을 요청하는 단계 - 상기 schemeIdUri는 각각의 상기 스트림 이벤트와 연관된 URI 문자열이며, 상기 값은 상기 schemeIdUri에 의해 식별된 상기 스트림 이벤트들의 특정한 서브유형을 식별하는 문자열임 -
를 포함하는 방법.
제9항에 있어서, 상기 schemeIdUri는 상기 문자열의 데이터 유형과 상기 URI의 포맷을 갖는, 방법.
제9항에 있어서, 상기 값은 문자열의 데이터 유형을 갖는, 방법.
제9항에 있어서, 상기 등록 데이터는 JSON 스키마에 포함되는, 방법.
제9항에 있어서, 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 상기 등록 필드들 중 적어도 하나를 더 포함하고,
(a) 상기 제1 디바이스가 상기 이벤트 데이터를 수신하는 것은:
(i) 상기 제1 디바이스가 타임스케일을 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 타임스케일은 최소값 1과 최대값 4294967295를 갖는 정수임 -;
(ii) 상기 제1 디바이스가 id를 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 id는 최소값 0과 최대값 4294967295를 갖는 정수임 -;
(iii) 상기 제1 디바이스가 데이터를 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택됨 -
중 적어도 하나를 포함하는, 방법.
제13항에 있어서, 상기 이벤트 데이터 필드들은 상기 타임스케일을 포함하고, 상기 타임스케일은 최소값 1 및 최대값 4294967295를 갖는 정수인, 방법.
제13항에 있어서, 상기 이벤트 데이터 필드들은 상기 id를 포함하고, 상기 id는 최소값 0 및 최대값 4294967295를 갖는 정수인, 방법.
제13항에 있어서, 상기 이벤트 데이터 필드들은 상기 데이터를 포함하고, 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택되는, 방법.
제1 디바이스로부터 등록 데이터를 포함하는 요청을 수신하는 것에 응답하여 스트림 이벤트들에 대한 이벤트 데이터를 제공하기 위한 제2 디바이스로서,
(a) 상기 제2 디바이스는 복수의 각각의 스트림 이벤트에 대한 복수의 등록 필드를 포함하는 상기 등록 데이터를 수신하고, 상기 등록 필드들 중 적어도 하나는 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것이며,
(b) 상기 제2 디바이스는 schemeIdUri 및 값을 포함하는 상기 등록 필드들을 수신하고, 상기 schemeIdUri는 각각의 상기 스트림 이벤트와 연관된 URI 문자열이며, 상기 값은 상기 schemeIdUri에 의해 식별된 상기 스트림 이벤트들의 특정한 서브유형을 식별하는 문자열인, 제2 디바이스.
제17항에 있어서, 상기 schemeIdUri는 상기 문자열의 데이터 유형과 상기 URI의 포맷을 갖는, 제2 디바이스.
제17항에 있어서, 상기 값은 문자열의 데이터 유형을 갖는, 제2 디바이스.
제17항에 있어서, 상기 등록 데이터는 JSON 포맷으로 수신되는, 제2 디바이스.
제17항에 있어서, 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 상기 등록 필드들 중 적어도 하나를 더 포함하고,
(a) 상기 제2 디바이스가 상기 이벤트 데이터를 제공하는 것은:
(i) 상기 제2 디바이스가 타임스케일을 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 타임스케일은 최소값 1과 최대값 4294967295를 갖는 정수임 -;
(ii) 상기 제2 디바이스가 id를 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 id는 최소값 0과 최대값 4294967295를 갖는 정수임 -;
(iii) 상기 제2 디바이스가 데이터를 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택됨 -
중 적어도 하나를 포함하는, 제2 디바이스.
제21항에 있어서, 상기 이벤트 데이터 필드들은 상기 타임스케일을 포함하고, 상기 타임스케일은 최소값 1 및 최대값 4294967295를 갖는 정수인, 제2 디바이스.
제21항에 있어서, 상기 이벤트 데이터 필드들은 상기 id를 포함하고, 상기 id는 최소값 0 및 최대값 4294967295를 갖는 정수인, 제2 디바이스.
제21항에 있어서, 상기 이벤트 데이터 필드들은 상기 데이터를 포함하고, 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택되는, 제2 디바이스.
스트림 이벤트들에 대한 등록 데이터를 포함하는 제1 디바이스로부터의 요청을 수신하는 것에 응답하는 제2 디바이스를 위한 방법으로서,
(a) 상기 제2 디바이스에 의해 복수의 각각의 스트림 이벤트에 대한 복수의 등록 필드를 포함하는 상기 등록 데이터를 수신하는 단계 - 상기 등록 필드들 중 적어도 하나는 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것임 - ; 및
(b) 상기 제2 디바이스에 의해 schemeIdUri 및 값을 포함하는 상기 등록 필드들을 수신하는 단계 - 상기 schemeIdUri는 각각의 상기 스트림 이벤트와 연관된 URI 문자열이며, 상기 값은 상기 schemeIdUri에 의해 식별된 상기 스트림 이벤트들의 특정한 서브유형을 식별하는 문자열임 -
를 포함하는 방법.
제25항에 있어서, 상기 schemeIdUri는 상기 문자열의 데이터 유형 및 상기 URI의 포맷을 갖는, 방법.
제25항에 있어서, 상기 값은 문자열의 데이터 유형을 갖는, 방법.
제25항에 있어서, 상기 등록 데이터는 JSON 포맷으로 수신되는, 방법.
제25항에 있어서, 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 상기 등록 필드들 중 적어도 하나를 더 포함하고,
(a) 상기 제2 디바이스가 상기 이벤트 데이터를 제공하는 것은:
(i) 상기 제2 디바이스가 타임스케일을 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 타임스케일은 최소값 1과 최대값 4294967295를 갖는 정수임 -;
(ii) 상기 제2 디바이스가 id를 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 id는 최소값 0과 최대값 4294967295를 갖는 정수임 -;
(iii) 상기 제2 디바이스가 데이터를 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택됨 -
중 적어도 하나를 포함하는, 방법.
제29항에 있어서, 상기 이벤트 데이터 필드들은 상기 타임스케일을 포함하고, 상기 타임스케일은 최소값 1 및 최대값 4294967295를 갖는 정수인, 방법.
제29항에 있어서, 상기 이벤트 데이터 필드들은 상기 id를 포함하고, 상기 id는 최소값 0 및 최대값 4294967295를 갖는 정수인, 방법.
제29항에 있어서, 상기 이벤트 데이터 필드들은 상기 데이터를 포함하고, 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택되는, 방법.
제2 디바이스에 대한 요청에 기초하여 스트림 이벤트들을 수신하기 위한 등록 데이터를 포함하는 요청을 하는 것에 응답하는 제1 디바이스로서,
(a) 상기 제1 디바이스는 복수의 각각의 스트림 이벤트에 대한 복수의 필드를 포함하는 상기 이벤트 데이터를 수신하고, 상기 등록 필드들 중 적어도 하나는 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것이며,
(b) 상기 제1 디바이스가 상기 이벤트 데이터를 수신하는 것은:
(i) 상기 제1 디바이스가 타임스케일을 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 타임스케일은 최소값 1과 최대값 4294967295를 갖는 정수임 -;
(ii) 상기 제1 디바이스가 id를 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 id는 최소값 0과 최대값 4294967295를 갖는 정수임 -;
(iii) 상기 제1 디바이스가 데이터를 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택됨 -
중 적어도 하나를 포함하는, 제1 디바이스.
제33항에 있어서, 상기 이벤트 데이터 필드들은 상기 타임스케일을 포함하고, 상기 타임스케일은 최소값 1 및 최대값 4294967295를 갖는 정수인, 제1 디바이스.
제33항에 있어서, 상기 이벤트 데이터 필드들은 상기 id를 포함하고, 상기 id는 최소값 0 및 최대값 4294967295를 갖는 정수인, 제1 디바이스.
제33항에 있어서, 상기 이벤트 데이터 필드들은 상기 데이터를 포함하고, 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택되는, 제1 디바이스.
제2 디바이스에 대한 요청에 기초하여 스트림 이벤트들을 수신하기 위한 등록 데이터를 포함하는 요청을 하는 것에 응답하는 제1 디바이스를 위한 방법으로서,
(a) 상기 제1 디바이스에 의해 복수의 각각의 스트림 이벤트에 대한 복수의 필드를 포함하는 상기 이벤트 데이터를 수신하는 단계 - 상기 필드들 중 적어도 하나는 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것임 - ; 및
(b) 상기 제1 디바이스에 의해 상기 이벤트 데이터를 수신하는 단계
를 포함하고,
상기 제1 디바이스에 의해 상기 이벤트 데이터를 수신하는 단계는,
(i) 상기 제1 디바이스가 타임스케일을 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 타임스케일은 최소값 1과 최대값 4294967295를 갖는 정수임 -;
(ii) 상기 제1 디바이스가 id를 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 id는 최소값 0과 최대값 4294967295를 갖는 정수임 -;
(iii) 상기 제1 디바이스가 데이터를 포함하는 상기 이벤트 데이터 필드들을 수신하는 것 - 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택됨 -
중 적어도 하나를 포함하는, 방법.
제37항에 있어서, 상기 이벤트 데이터 필드들은 상기 타임스케일을 포함하고, 상기 타임스케일은 최소값 1 및 최대값 4294967295를 갖는 정수인, 방법.
제37항에 있어서, 상기 이벤트 데이터 필드들은 상기 id를 포함하고, 상기 id는 최소값 0 및 최대값 4294967295를 갖는 정수인, 방법.
제37항에 있어서, 상기 이벤트 데이터 필드들은 상기 데이터를 포함하고, 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택되는, 방법.
제1 디바이스로부터의 요청에 기초하여 스트림 이벤트들에 대한 이벤트 데이터를 제공하기 위한 제2 디바이스로서,
(a) 상기 제2 디바이스는 복수의 각각의 스트림 이벤트에 대한 복수의 필드를 포함하는 상기 이벤트 데이터를 제공하고, 상기 필드들 중 적어도 하나는 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것이며,
(b) 상기 제2 디바이스는:
(i) 상기 제2 디바이스가 타임스케일을 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 타임스케일은 최소값 1과 최대값 4294967295를 갖는 정수임 -;
(ii) 상기 제2 디바이스가 id를 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 id는 최소값 0과 최대값 4294967295를 갖는 정수임 -;
(iii) 상기 제2 디바이스가 데이터를 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택됨 -
중 적어도 하나를 포함하는, 제2 디바이스.
제41항에 있어서, 상기 이벤트 데이터 필드들은 상기 타임스케일을 포함하고, 상기 타임스케일은 최소값 1 및 최대값 4294967295를 갖는 정수인, 제2 디바이스.
제41항에 있어서, 상기 이벤트 데이터 필드들은 상기 id를 포함하고, 상기 id는 최소값 0 및 최대값 4294967295를 갖는 정수인, 제2 디바이스.
제41항에 있어서, 상기 이벤트 데이터 필드들은 상기 데이터를 포함하고, 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택되는, 제2 디바이스.
제1 디바이스로부터의 요청에 기초하여 스트림 이벤트들에 대한 이벤트 데이터를 제공하기 위한 제2 디바이스를 위한 방법으로서,
(a) 상기 제2 디바이스에 의해 복수의 각각의 스트림 이벤트에 대한 복수의 필드를 포함하는 상기 이벤트 데이터를 제공하는 단계 - 상기 필드들 중 적어도 하나는 각각의 상기 스트림 이벤트의 특정한 서브유형에 대한 것임 - ; 및
(b) 상기 제2 디바이스에 의해:
(i) 상기 제2 디바이스가 타임스케일을 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 타임스케일은 최소값 1과 최대값 4294967295를 갖는 정수임 -;
(ii) 상기 제2 디바이스가 id를 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 id는 최소값 0과 최대값 4294967295를 갖는 정수임 -;
(iii) 상기 제2 디바이스가 데이터를 포함하는 상기 이벤트 데이터 필드들을 제공하는 것 - 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택됨 -
중 적어도 하나를 포함하는 단계
를 포함하는, 방법.
제45항에 있어서, 상기 이벤트 데이터 필드들은 상기 타임스케일을 포함하고, 상기 타임스케일은 최소값 1 및 최대값 4294967295를 갖는 정수인, 방법.
제45항에 있어서, 상기 이벤트 데이터 필드들은 상기 id를 포함하고, 상기 id는 최소값 0 및 최대값 4294967295를 갖는 정수인, 방법.
제45항에 있어서, 상기 이벤트 데이터 필드들은 상기 데이터를 포함하고, 상기 데이터는 객체의 데이터 유형과 문자열의 데이터 유형 중 하나가 되도록 선택되는, 방법.