KR20100119806A

KR20100119806A - 프레젠테이션 기술 언어 콘텐트로 광고를 삽입하는 시스템 및 방법

Info

Publication number: KR20100119806A
Application number: KR1020107021172A
Authority: KR
Inventors: 토니 유하니 파일라; 토피-오스카리 포횰라이넨; 에사 펙카 얄로넨
Original assignee: 노키아 코포레이션
Priority date: 2008-02-22
Filing date: 2009-02-20
Publication date: 2010-11-10
Also published as: WO2009104083A2; EP2245558A2; US20090313654A1; WO2009104083A3; CN101981893A

Abstract

프레젠테이션 기술 (presentation description) 언어를 이용하여 표시 가능한 콘텐트용의 콘텐트 업데이트를 수신하며 그리고 상기 프레젠테이션 기술 언어를 이용해서 상기 콘텐트 업데이트를 기반으로 상기 콘텐트에 보충 (complementary) 정보를 삽입하는 것을 포함하는 방법이 개시된다. 상기 프레젠테이션 기술 언어로 표현된 콘텐트는 리치 미디어 환경 (Rich Media Environment (RME)) 콘텐트일 수 있을 것이며, 그리고 상기 보충 정보는 하나 또는 그 이상의 광고들을 포함할 수 있을 것이다.

Description

프레젠테이션 기술 언어 콘텐트로 광고를 삽입하는 시스템 및 방법 {System and method for insertion of advertisement into presentation description language content}

본 발명은 보통은 리치 미디어 환경 (Rich Media Environment)과 같은 기술 (description) 언어를 이용하여 표시되는 콘텐트에 관련된다. 더 상세하게는, 본 발명은 장면 (scene) 내에 광고를 삽입하거나 그런 콘텐트 내에 멀티미디어 프레젠테이션을 삽입하는 것에 관련된다.

이 섹션은 청구범위에서 개시된 본 발명의 배경 또는 상황을 제공하기 위해서 의도된 것이다. 여기에서의 설명은 수행될 수 있을 개념들을 포함할 수 있을 것이지만, 이전에 고안되었거나 수행되었던 것일 필요는 없다. 그러므로, 여기에서 다르게 표시되지 않는다면, 이 섹션에서 설명된 것은 본 명세서의 설명과 청구범위에 대한 종래 기술은 아니며, 그리고 이 섹션에 포함되었다고 선행 기술로서 인정되는 것도 아니다.

무선 통신, 미디어 브로드캐스팅 및 콘텐트 배포에서의 급격한 개발들은 모바일 기기들에게 다양한 서비스들 및 제품들을 배송하는 것을 계속해서 용이하게 한다. 그런 서비스의 하나인 모바일 TV는 다양한 엔터테인먼트 콘텐트 및 서비스들을 모바일 사용자들에게 배송하는 것을 포함하며, 모바일 매체를 위해 특별하게 적응된 TV 콘텐트를 개인화하여 인터액티브하게 보여주는 것을 가능하게 한다. 이동성 및 순수한 브로드캐스트 (즉, 전통적인) TV 프로그램들을 수신하는 것을 가능하게 하는 것에 추가하여, 모바일 TV는 무선 통신을 인터넷 및 전통적인 TV 브로드캐스트 서비스와 융합하는 것을 제시하는 비디오-온-디맨드, 개인화된 콘텐트 배송, 인터액티브한 투표, SMS 메시징, 라이브 채팅, 타겟이 있는 광고 링크들 등의 다양한 추가적인 서비스들 및 특징들을 배송하도록 적응될 수 있을 것이다.

모바일 브로드캐스트 하부 구조는 소위 리치 미디어 환경 (Rich Media Environment; RME) 콘텐트에 대한 요청에 또한 박차를 가한다. RME는 보통은 그래픽적으로 풍부하고 (rich) 그리고 그래픽, 텍스트, 비디오 및 오디오를 포함하는 복합 (또는 멀티플) 미디어를 포함하는 콘텐트를 일컫는다.

서비스 및/또는 콘텐트는 OMA 리치 미디어 환경 (RME) / 3GPP 동적 인터액티브 멀티미디어 장면들 (Dynamic Interactive Multimedia Scenes (DIMS))로서 형성될 수 있을 것이다.

본 발명의 목적은 콘텐트 장면 (scene) 내에 광고를 삽입하거나 그런 콘텐트 내에 멀티미디어 프레젠테이션을 삽입하기 위한 방법 및 장치를 제공하려는 것이다.

한 가지 모습에서, 본 발명의 방법은 프레젠테이션 기술 (presentation description) 언어를 이용하여 표시 가능한 콘텐트용의 콘텐트 업데이트를 수신하는 단계 그리고 표시될 콘텐트에 상기 콘텐트 업데이트를 기반으로 상기 프레젠테이션 기술 언어를 이용하여 보충 (complementary) 정보를 삽입하는 단계를 포함한다. 프레젠테이션 기술 언어를 사용하여 표시된 콘텐트는, 일 실시예에서, 리치 미디어 환경 (Rich Media Environment (RME)) 콘텐트일 수 있을 것이며, 그리고 상기 보충 정보는 하나 또는 그 이상의 광고들을 포함할 수 있을 것이다.

다양한 실시예들의 이와 같은 그리고 다른 이점들 및 특징들은 그 실시예의 조직 및 동작 방식과 더불어서, 동반된 도면들과 결합될 때에, 다음의 상세한 설명으로부터 명확하게 될 것이며, 상기 도면들에서 유사한 요소들은 아래에서 설명되는 여러 도면들을 통해서 유사한 참조번호들을 가진다.

본 발명을 통해, 콘텐트의 장면 (scene) 내에 광고를 삽입하거나 그런 콘텐트 내에 멀티미디어 프레젠테이션을 삽입하는 것을 효율적으로 실행할 수 있게 된다.

본 발명의 상이한 실시예들은 첨부된 도면들을 참조하여 설명된다.
도 1은 일 실시예의 예시적인 블록도를 도시한다.
도 2는 다른 실시예들에 따른 특수화의 다양한 레벨들을 예시한다.
도 3은 다양한 실시예들을 개략적으로 도시한다.
도 4는 다른 실시예들에 따른 예시적인 프로세스를 도시한다.
도 5는 일 실시예에 따른 최종 사용자 선호도 또는 프로파일을 개발하는 것을 위한 예시적인 프로세스 (500)를 도시한다.
도 6은 다양한 실시예들을 실행하는 것과 결합되어 사용될 수 있는 전자 기기의 투시도이다.
도 7은 도 6의 전자 기기에 포함될 수 있을 회로의 개략적인 표현이다.

설명의 목적이며 한정하기 위한 것은 아닌 다음의 설명에서, 본 발명에 대한 완전한 이해를 제공하기 위해 상세한 내용 및 설명이 제시된다. 그러나, 본 발명이 속한 기술 분야의 통상의 지식을 가진 자들에게는 본 발명은 이런 상세한 내용들과 설명들에서 벗어난 다른 실시예들에서 수행될 수 있을 것이라는 것이 명백할 것이다.

광고들은 그 광고들을 미디어 스트림으로 직접 인코딩하여 방송 시간까지는 고정될 수 있을 것이다. 그러나, 광고들로부터 더 많은 수입을 얻기 위해서, 광고들 그 자체는 시청자에 특정되어야만 한다 (목표가 정해진 광고들). 더 나아가, 광고의 정확한 시각은 대개는 미리 알려지지 않는다. 추가적인 통고없이 광고 방영을 개시하도록 하는 기능을 가지는 것이 바람직할 수 있을 것이다. 예를 들면, 축구 경기에서의 골 직후에 위치되도록 하는 것이 바람직할 수 있을 것이다.

통상적인 방송들에서, 광고들은 방송 콘텐트와 광고들이 교대하도록 방송 스트림에 삽입된다. 한 장면 (scene)에 대해 RME 기술 (description)들을 사용함으로써, 오디오, 비디오, 이미지들, 서로 다른 폰트들을 사용하는 텍스트 정보를 포함하는 방송 또는 멀티캐스트 콘텐트는 한 단말에 동시에 표시될 수 있을 것이다.

실시예들에 따라서, 하나 또는 그 이상의 광고들 또는 다른 추가적인 또는 보충의 정보 및/또는 콘텐트는 장면이나 리치 미디어 환경 (Rich Media Environment (RME))과 같은 프레젠테이션 기술 언어를 이용하여 정의된 하나의 장면이나 멀티미디어 프레젠테이션으로 삽입될 수 있을 것이다. RME는 다음의 문서에서 오픈 모바일 동맹 (Open Mobile Alliance (OMA))에 의해 정의된다: Rich Media Environment Technical Specification; Draft Version 1.0 12 November 2007; OMA-TS-RME-V1_0-20071112-D; Rich-Media Environment Requirements; Draft Version 1.0 25 August 2005; OMA-RD-RichMediaEnvironment-V1_0_4-20050825-D; and Rich Media Environment Architecture; Draft Version 1.0 15 June 2007; OMA-AD-Rich_Media_Environment-V1_0-20070615-D. 이 문서들 각각은 http://member.openmobilealliance.org/ftp/Public_documents/BT/MAE/Permanent_documents/ 에서 다운로드할 수 있다.

RME에 추가하여, 다른 장면 또는 프레젠테이션 기술 언어들이 본 발명의 범위 내에서 기대된다. 그런 다른 언어들은 문서 3GPP TS 26.142 V7.2.0 (2007-12) Technical Specification Dynamic and Interactive Multimedia Scenes; (Release 7)에서 설명된 동적 인터액티브 멀티미디어 장면들 (Dynamic Interactive Multimedia Scenes (DIMS))을 포함하며, 상기 문서는 http://www.3gpp.org/ftp/Specs/archive/26%5Fseries/26.142/ 에서 다운로드할 수 있다.

추가로, 그와 같은 다른 언어는 http://www.w3.org/TR/REC-smil/ 에서 다운로드받을 수 있는 동기화 멀티미디어 집적 언어 (Synchronized Multimedia Integration Language (SMIL)) 1.0 규격 (W3C Recommendation 15-June-1998)이다.

실시예들에 따라서, 도 1에 예시적으로 도시된 것과 같이, 광고 또는 다른 보충 정보나 콘텐트는 하나 또는 그 이상의 장면 업데이트들을 이용하여 한 장면 또는 프레젠테이션에 삽입될 수 있을 것이다. RME-정의된 콘텐트는 비디오, 이미지들, 애니메이션들 및 텍스트 오브젝트와 오디오 오브젝트들과 같은 하나 또는 그 이상의 시각적인 오브젝트들을 포함하는 장면들을 포함할 수 있을 것이다. RME를 이용할 때에, 장면들은 장면의 변경된 그런 부분들을 교체할 수 있을 새로운 정보로 업데이트될 수 있을 것이다. 장면 또는 프레젠테이션 기술은 시각적인 오브젝트 및 오디오 오브젝트를 정의하고 그리고 RME 규격에서 드로잉 캔버스 (drawing canvas)로 불리는 프레젠테이션 스크린 상의 그런 오브젝트들의 레이아웃을 정의한다.

상기 장면 또는 프레젠테이션의 기술 (description)은 장면 오브젝트들과의 로컬인 그리고 원격의 인터액션은 물론이고 상기 장면에서의 상기 오브젝터들 사이의 시간적인 관계들을 또한 정의할 수 있을 것이다. RME의 장면 기술 언어는 크기 조절 가능한 벡터 그래픽스 (Scalable Vector Graphics (SVG)) 규격을 기반으로 하며, 상기 규격은 SVG Basic and SVG Tiny 를 포함하는 몇 가지 버전들에서 공표되었으며 그 버전들은 http://www.w3.org/Graphics/SVG/ 에서 다운로드하는 것이 가능하다. 다른 대안들은 ISO/IEC FDIS 14496-20:2006(E): Information technology Coding of audio-visual objects Part 20: Lightweight Application Scene Representation (LASeR) and Simple Aggregation Format (SAF) 로서 표준화된 LAEeR (Lightweight Application Scene Representation)이며, http://www.mpeg-laser.org/documents/DRAFT_LASER_2ND_ED.pdf, Macromedia/Adobe 독점의 Flash (http://www.adobe.com/products/flash/ 에서 다운로드 가능) 그리고 Microsoft 독점의 Silverlight (http://www.microsoft.com/silverlight/에서 다운로드 가능)에서 다운로드 가능하다.

실시예들에 따라서, 장면 업데이트는 장면의 일부, 상기 장면의 레이아웃, 장면 오브젝트들 사이의 시간적인 관계들 및/또는 상기 장면 오브젝트들과의 인터액션의 일부를 바꿀 수 있을 것이다. 업데이트 명령들은 삽입 동작, 삭제 동작, 교체 동작 및 추가 동작들을 허용할 것이다. 일 실시예에서, 상기 장면 업데이트 명령들은 레이아웃들의 부분들이 다른 불투명체들에 겹치도록 레이아웃을 변경할 수 있을 것이다. 또한, 장면 기술 및/또는 업데이트들은 상기 장면 또는 장면 업데이트를 수정하고 그리고/또는 어떤 장면 오브젝트들 및 그것들의 상호 관계들을 수정하기 위한 용도의 내장된 또는 포함된 스크립트들을 구비할 수 있을 것이다. 상기 스크립트들은 ECMAScript 언어 규격에 기반할 수 있을 것이며, 상기 규격은 http://www.ecma-international.org/publications/standards/Ecma-262.htm 에서 다운로드 가능하다. 그러나, 다른 스크립트 역시 본 발명의 범위 내에서 사용될 수 있을 것이며 그리고 고려될 수 있을 것이다.

광고 삽입에 추가하여, 보충 및/또는 추가 정보는 아이템을 선택하기 위한 선택 박소 또는 풀-다운 메뉴의 프레젠테이션을 포함할 수 있을 것이다. 또한, 상기 보충 정보는 프로그램 스케줄들, 날씨, 교통 경보들 또는 다른 그런 통고에서의 변화들과 같은 통고들을 포함할 수 있을 것이다.

그래서, 실시예들에 따라서, 네트워크는 RME 기술된 장면에 광고가 삽입될 수 있을 RME 장면 업데이트를 발행할 수 있을 것이다. 그 광고는 다양한 방식으로 사용자의 단말로 배송될 수 있을 것이다. 일 실시예에서, 상기 광고의 콘텐트는 미리 공급되어 상기 업데이트에 의해 참조된다. 그러면 상기 사용자 단말은 상기 참조를 기반으로 하여 상기 미리 공급된 콘텐트를 검색할 수 있을 것이다. 그러나 다른 실시예에서, 상기 광고의 콘텐트는 상기 업데이트를 수신하면 상기 사용자 단말에 의해 인터액티브하게 검색된다. 또 다른 실시예에서, 상기 광고의 콘텐트는 브로드캐스트 배송 세션으로부터 수신될 수 있을 것이다.

일 실시예에서, 상기 RME 장면 업데이트는, 예를 들면, 네트워크로부터의 독점의 (proprietary) 시그날링을 이용하는 것을 통해서 상기 단말 자체에 의해 간접적으로 생성될 수 있다. 이는 상기 네트워크가 레거시 (legacy) 광고 트리거 시그날링을 구비할 때에 유용할 수 있을 것이며, 이는 상기 레거시 시그날링은 RME 장면 업데이트로 변환되기 때문이다.

일 실시예에서, 상기 광고의 콘텐트는 단말-특정 또는 최종 사용자-특정 중의 어느 하나일 수 있을 것이다. 이런 면에서, 상기 광고는 특정 단말이나 최종 사용자에 의한 이용 (consumption)에 대한 타겟이 될 수 있다.

일 실시예에서, 단일 RME 스트림은 모든 단말들에 동일한 장면 업데이트들을 배송한다. 상기 장면 업데이트 핸들링은 단말 유형 및/또는 최종 사용자에게 특정될 수 있을 것이다. 다른 실시예에서, 상이한 RME 스트림들은 특정 단말 유형들 그리고/또는 특정 최종 사용자들에게 장면 업데이트들을 배송한다. 또 다른 실시예에서, 상기 두 가지의 결합이 사용될 수 있을 것이다. 이런 면에서, 특수화를 세분화하는 것은 변경될 수 있을 것이다. 예를 들면, 복수의 RME 스트림들은 특정 그룹의 최종 사용자들 또는 단말 유형들에 특정되어 있는 각 RME 스트림을 이용하여 구현될 수 있을 것이다.

이제 도 2 및 도 3을 참조하면, 특수화의 다양한 레벨들이 예시된다. 일 실시예에서, 단말 특정 RME 스트림 또는 최종 사용자 특정 RME 스트림이 구현된다 (210). 이런 면에서, 서비스 및/또는 콘텐트를 이용하는 것을 시작하기 전에, 단말 유형 또는 최종 사용자 선호도를 기반으로 하여 RME 스트림으로의 액세스가 선택된다. 예를 들면, 특별한 RME 스트림 액세스를 단말 유형 및/또는 최종 사용자 선호도들에 연관시키기 위해 오픈 모바일 연합 디지털 모바일 브로드캐스트 (Open Mobile association Digital Mobile Broadcast (OMA BCAST)) 서비스 가이드가 사용될 수 있다. 일 실시예에서, 이는 각각이 특정 "TargetUserProfile" 엘리먼트를 구비한 복수의 "액세스 (Access)" 프래그먼트들을 예시함으로써 달성될 수 있을 것이다.

다른 실시예에서, 단말 또는 최종 사용자 특정 RME 장면 업데이트 핸들링이 구현된다 (220). 이런 점에서, RME 장면 업데이트를 수신하면, 상기 단말은 상기 단말 유형 선호드 및/또는 최종 사용자 선호도를 기반으로 하여 상기 업데이트를 처리한다. 이를 달성하기 위한 한 가지 방법은 상기 단말 유형 선호드 및/또는 최종 사용자 선호도를 결정할 수 있는 그런 스크립트를 상기 장면 업데이트에 내장시키는 것이다. 상기 장면 업데이트의 상기 특정 프로세싱은 그 스크립트 자체에 의해 수행될 수 있을 것이며, 또는 상기 스크립트는 상기 XML 문서 오브젝트 모델 (Document Object Model (DOM))을 수정하여, 단말 유형 및/또는 최종 사용자 특정 업데이트로 간접적으로 귀결될 수 있도록 할 수 있을 것이다. 다른 실시예에서, 상기 스크립트는 루트 (root) RME 문서 내에 주재할 수 있을 것이다. 다른 실시예에서, 상기 단말 유형 및 최종 사용자 특정 핸들링은 상기 RME 사용자 에이전트 그 자체의 단말 유형 특정 부분 및/또는 최종 사용자 특정 부분에 의해 수행될 수 있다.

다른 실시예에서, 단말 또는 최종 사용자 특정 콘텐트 식별자 결정 (resolution)이 구현된다 (230). 이는 상기에서 설명된 RME 장면 업데이트 핸들링 (220)의 특별한 경우로 간주될 수 있을 것이다. 이런 면에서, 상기 RME 장면 업데이트의 코어는 상기 단말 유형 선호도 및 최종 사용자 선호도에 독립적으로 수행된다. 콘텐트 선호도만이 단말 유형 및/또는 최종 사용자 선호도 특정 방식에서 결정된다. 다른 실시예에서, 상기 RME 장면 업데이트의 코어는 상기 단말 유형 및 최종 사용자 선호도와는 독립적으로 수행되며, 그리고 콘텐트 선호도만이 상기 단말 유형 및 최종 사용자 선호도를 기반으로 하여 결정된다.

다른 실시예에서, 단말 특정 콘텐트 또는 최종 사용자 특정 콘텐트가 구현된다 (240). 이런 면에서, 이런 포인트까지 상기 RME 장면 업데이트 그 자체 그리고 그것의 핸들링 두 가지 모두가 독립적으로 처리될 수 있을 것이거나 또는 동일한 콘텐트 참조로 귀결될 수 있을 것이다. 이 포인트에서, 상기 콘텐트 참조들이 동일할지라도, 참조된 콘텐트는 단말 유형 선호도 및/또는 최종 사용자 선호도의 관점에서는 다르다. 이는 단말 유형 및/또는 최종 사용자 선호도 특정 콘텐트 배송을 이용하여 실현될 수 있을 것이다.

본 발명에 따른 도 3을 참조하면, 광고들 또는 다른 정보 또는 콘텐트가 미리 정의된 트리거링 포인트들, 예를 들면, 레거시 광고 삽입 포인트들, 예를 들면, 축구나 아이스 하키 경기에서 골이 발생했을 때에 또는 경기가 중단되었을 때에 메인 콘텐트에 종속된 시간의 이벤트-트리거 경우들 또는, 예를 들면, 스크린 상에서 어떤 아이템을 지시하거나 그리고/또는 선택하는 사용자 동작에 의해 발생된 트리거 포인트(들)로 삽입될 수 있을 것이다.

그러므로, 도 3에서 예시적으로 도시된 것과 같이, 통신 시스템 (300)은 통신 신호들을 전송하고 수신하기 위한 네트워크를 형성하는 하나 또는 그 이상의 기지국 (304)을 구비한 서비스 제공자 (302)를 포함할 수 있을 것이다. 다양한 광고들이 상기 서비스 제공자 (302)에 의해 광고 저장부 (306)에 저장될 수 있을 것이며, 상기 광고 저장부는 일 실시예에서는 데이터베이스일 수 있을 것이다. RME 콘텐트 또는 프레젠테이션 기술 언어로 표시된 다른 콘텐트는 하나 또는 그 이상의 사용자 단말들로 배송될 수 있을 것이다. 도 3에서 도시된 일 실시예에서, 3개의 사용자 단말들 (382, 384, 386)이 도시된다. 본 발명이 속한 기술 분야에서의 통상의 지식을 가진 자들은 아주 더 많은 수의 사용자들이 그런 통신 시스템 (300)에 의해 수용될 수 있을 것이라는 것을 이해할 것이다. 각 사용자 단말은 단말 유형 및/또는 사용자 프로파일과 연관될 수 있을 것이다. 도시된 실시예에서, 첫 번째 사용자 단말 (382)은 단말 유형 "X"를 그리고 사용자 프로파일 "Y"를 가진며, 두 번째 사용자 단말 (384)은 단말 유형 "Z" 및 사용자 프로파일 "Y"를 가진다.

상기에서 설명된 것과 같이, 다양한 실시예들이 서로 다른 방식들로 콘텐트 업데이트들을 배송할 수 있을 것이다. 일 실시예에서, 도 3에서 참조번호 320으로 표시된 것과 같이, 단일 RME 스트림은 단말 유형 또는 사용자 프로파일에 관계없이 모든 단말들에게 동일한 장면 업데이트들을 배송한다. 다른 실시예에서, 도 3에서 참조번호 340 및 360에 의해 표시된 것과 같이, 상이한 RME 스트림들이 특정 단말 유형 및/또는 최종 사용자들에게 장면 업데이트들을 배송한다. 도 3의 실시예에서, 하나의 RME 스트림 (340)은, 상기 첫 번째 사용자 단말 (382)에 대응하는, 단말 유형 "X" 및/또는 사용자 프로파일 "Y"를 가진 사용자 단말들로 콘텐트 업데이트들을 배송한다. 유사하게, 다른 RME 스트림 (360)은 상기 두 번째 사용자 단말 (384)에 대응하는, 단말 유형 "Z" 및/또는 사용자 프로파일 "W"를 가진 사용자 단말들로 콘텐트 업데이트들을 배송한다. 상기에서 설명된 것과 같이, 상기의 두 가지의 결합이 다른 실시예드에서 사용될 수 있을 것이다. 다른 실시예에서, 광고들과 같은 상기 콘텐트의 부분들이 하나 또는 그 이상의 사용자 단말들로 미리 적재되거나 배송될 수 있을 것이다. 상기 미리 적재되거나 배송된 콘텐트는 상기 단말 유형 및/또는 사용자 프로파일을 기반으로 하여 광고들과 같은 보충 정보를 커스터마이징 하는데 있어서 사용될 수 있을 것이며, 이는 도 3의 세 번째 사용자 단말 (386)에서의 경우이다.

미리 적재되어 파일 배송에서 배송되거나 또는 HTTP 요청에 의해 요청될 수 있을 이용 가능한 광고들로부터 상기 광고를 선택하는 것은 상기 RME 스트림 내의 스크립트에 따라 상기 사용자 프로파일 및/또는 선호도에 종속될 수 있을 것이다. 상기 스크립트는 재생될 광고를 선택할 때에 고려되는 사용자 프로파일 데이터베이스로부터 아이템들을 정의한다. 그런 경우에, 상기 사용자 프로파일은 미리 정의되지 않는다. 상기 사용자 프로파일 데이터베이스 내의 아이템들에 추가하여, 상기 스크립트는, 예를 들면, 시간, 날짜, 마지막 접촉들, 마지막 웹 검색 키워드들, 이용 통계치들, 검출된 이웃하는 기기들 등과 같은 단말 내에서 액세스 가능한 어떤 다른 데이터를 또한 이용할 수 있을 것이며, 그래서 동적 사용자 프로파일을 예를 들면 상황 및/또는 위치 종속적으로 만든다. 상기 스크립트는 루트 RME 데이터 내에서 또는 상기 RME 업데이트들 내에서 송신될 수 있을 것이다. 상기 RME 업데이트는 HTTP 요청을 트리거할 수 있을 것이다. 상기 요청은 미리 정의된 시간의 경우에 의해, 사용자 행동에 의해 또는 검출된 이벤트에 의해 또한 트리거될 수 있을 것이다. 또한, 상기 스크립트는 어떤 광고를 상기 수신한 콘텐트 스트림 내에서 교체하라고 지시할 수 있을 것이며, 이 경우 상기 교체 광고는 상기에서 정의된 기준에 따라서 선택된다.

이벤트들의 한가지 클래스는 서버로의 장면 업데이트 요청을 생성하는 이벤트 핸들러에 의해 분석된 사용자 인터페이스 (UI) 이벤트이다. 이런 이벤트들은 몇몇의 실시예들에서 포인팅 기기를 커서, 하나 또는 그 이상의 키 누름들, 조이스틱 동작, 마우스 동작 등으로서 동작시키는 것을 포함한다. 이벤트들의 다른 클래스는 프로그램 시작 또는 종료와 같은 렌더링된 비디오 및/또는 오디오 스트림에서의 변경들을 포함할 수 있을 것이다. 상기 비디오 및/또는 오디오 콘텐트는 스포츠 프로그램에서의 골 또는 정지와 같은 예외들에 대해서 분석될 수 있을 것이다. 그런 이벤트들은 상기 RME 장면 업데이트를 서버 측에서 또는 단말 측에서의 어느 하나에서 트리거할 수 있을 것이며, 그 경우 상기 삽입된 광고 또는 다른 보충 정보는 상기 업데이트 내에 포함될 수 있을 것이며, 미리 다운로드될 수 있을 것이며, 인터액티브하게 검색될 수 있을 것이며 또는 브로드캐스트 세션 내에서 수신될 수 있을 것이다.

이런 면에서, SVG, RME, 플래시 (Flash), MPEG4-LASeR 또는 (이 개시에서는 통합해서 "RME"로 불리는) 유사한 기술들은 장면들, 레이아웃들을 설명하고 그것들로의 업데이트를 관리하는 방법들을 제공한다.

일 실시예에서, RME 장면들, 이벤트 핸들러들 및 DOM 프로세싱이 이용될 수 있을 것이다. 어떤 스트립트는 RME 문서 내에서 엘리먼트와 연관된다. 이벤트 핸들러는 상기 스크립트와 연관된다. 예를 들면, "클릭 (click)" 이벤트가 식별될 때에, 그것은 그 이벤트를 분석하기 위해, 예를 들면, 자바스크립트 (Javascript) 스크립트 또는 자바 코드를 사용하는 이벤트 핸들러와 연관된다. 상기 이벤트의 상세한 내용들은, 상기 이벤트와 연관된 명령어들과 함께, 서버로 송신된다. 상기 서버는 상기 단말에 의한 상기 요청을 분석하고, 그리고, 그 정보를 기반으로 하여, 장면 업데이트를 결정한다. 상기 장면 업데이트는 상기 요청에 대한 응답의 일부로서 단말로 리턴된다. 상기 장면 업데이트는 상기 단말에서 마스터 RME 문서로 적용되며, 그리고 결과적으로, uDOM이 처리되고, 그리고 그 장면 업데이트의 효과가 보여진다.

다음의 RME/SVG 부분은 예시적인 구현을 기술한다:

<?xml version="1.0" encoding="UTF-8"?>

xmlns:xlink="http://www.w3.org/1999/xlink"

width="480" height="272" viewBox="0 0 480 272">

<desc>Example SVG</desc>

var urlCallBackObject;

var targetPostHost = "www.interactionserver.nokia.com";

var outside = 999;

var menu_btn_x = new Array(6);

var menu_btn_y = new Array(6);

var menu_btn_action = new Array(6);

var yspacing = 37;

menu_btn_x[0] = 30;

menu_btn_y[0] = 10;

menu_btn_x[1] = 30;

menu_btn_y[1] = 10+yspacing;

menu_btn_x[2] = 30;

menu_btn_y[2] = 10+yspacing*2;

menu_btn_x[3] = 30;

menu_btn_y[3] = 10+yspacing*3;

menu_btn_x[4] = 30;

menu_btn_y[4] = 10+yspacing*4;

PostUrlCallBackClass.prototype = new Object();

function PostUrlCallBackClass() {}

PostUrlCallBackClass.prototype.operationComplete = function(AsyncURLStatus status) {

if(status.success) {

if(status.contentType == "document/svg+xml") {

Node n = parseXML(status.content);

document.documentElement.importNode(n, true);

}

function change_video(evt) {

var topGroup = document.getElementById("scene-1");

var toBeRemoved = document.getElementById("next-prog");

topGroup.removeChild(toBeRemoved);

var video = document.getElementById("v1");

video.setAttributeNS("http://www.w3.org/1999/xlink", "href", "fs-s2e4-restaurant.mp4");

}

function show_ack_msg(evt) {

var svgNS = "http://www.w3.org/2000/svg";

var xlinkNS = "http://www.w3.org/1999/xlink";

var xmlNS = "http://www.w3.org/XML/1998/namespace";

var topGroup = document.getElementById("top");

var toBeAdded = document.createElementNS(svgNS, "image");

toBeAdded.setAttributeNS(xlinkNS, "href", "done.png");

toBeAdded.setAttribute("x", "130");

toBeAdded.setAttribute("y", "100");

toBeAdded.setAttribute("width", "165");

toBeAdded.setAttribute("height", "78");

toBeAdded.setAttribute("opacity", "0.7");

var anim = document.createElementNS(svgNS, "animate");

anim.setAttributeNS(xmlNS, "id", "id123456");

anim.setAttribute("attributeType", "CSS");

anim.setAttribute("attributeName", "opacity");

anim.setAttribute("from", "0.7");

anim.setAttribute("to", "0");

anim.setAttribute("dur", "2s");

anim.setAttribute("begin", "indefinite");

anim.setAttribute("fill", "freeze");

var discrd = document.createElementNS(svgNS, "discard");

discrd.setAttribute("begin", "id123456.end");

toBeAdded.appendChild(anim);

toBeAdded.appendChild(discrd);

topGroup.appendChild(toBeAdded);

anim.beginElementAt(1);

var triggerAnim = document.getElementById("triggered-ad-anim");

triggerAnim.beginElementAt(2);

}

function show_menu(x, y, target, timestamp, video_name) {

var button1 = document.getElementById("button-1");

var button2 = document.getElementById("button-2");

var button3 = document.getElementById("button-3");

var button4 = document.getElementById("button-4");

var button5 = document.getElementById("button-5");

button1.setAttribute("x", menu_btn_x[0]);

button1.setAttribute("y", menu_btn_y[0]);

button1.setAttribute("opacity", 0.7);

menu_btn_action[0] =

"someaction1?"+ "x=" + x + "?" + "y=" + y + "?" +

"video=" + video_name + "?" + "timestamp=" + timestamp;

button2.setAttribute("x", menu_btn_x[1]);

button2.setAttribute("y", menu_btn_y[1]);

button2.setAttribute("opacity", 0.7);

menu_btn_action[0] =

"someaction2?"+ "x=" + x + "?" + "y=" + y + "?" +

"video=" + video_name + "?" + "timestamp=" + timestamp;

button3.setAttribute("x", menu_btn_x[2]);

button3.setAttribute("y", menu_btn_y[2]);

button3.setAttribute("opacity", 0.7);

menu_btn_action[0] =

"someaction3?"+ "x=" + x + "?" + "y=" + y + "?" +

"video=" + video_name + "?" + "timestamp=" + timestamp;

button4.setAttribute("x", menu_btn_x[3]);

button4.setAttribute("y", menu_btn_y[3]);

button4.setAttribute("opacity", 0.7);

menu_btn_action[0] =

"someaction4?"+ "x=" + x + "?" + "y=" + y + "?" +

"video=" + video_name + "?" + "timestamp=" + timestamp;

button5.setAttribute("x", menu_btn_x[4]);

button5.setAttribute("y", menu_btn_y[4]);

button5.setAttribute("opacity", 0.7);

menu_btn_action[0] =

"someaction5?"+ "x=" + x + "?" + "y=" + y + "?" +

"video=" + video_name + "?" + "timestamp=" + timestamp;

}

function menu_click(evt) {

if (evt.target == document.getElementById("button-1") ) {

hide_menu(evt);

postURL(targetPostHost, menu_btn_action[0], urlCallBackObject, "text", "ascii");

}

if (evt.target == document.getElementById("button-2") ) {

hide_menu(evt);

postURL(targetPostHost, menu_btn_action[1], urlCallBackObject, "text", "ascii");

}

if (evt.target == document.getElementById("button-3") ) {

hide_menu(evt);

postURL(targetPostHost, menu_btn_action[2], urlCallBackObject, "text", "ascii");

}

if (evt.target == document.getElementById("button-4") ) {

hide_menu(evt);

postURL(targetPostHost, menu_btn_action[3], urlCallBackObject, "text", "ascii");

}

if (evt.target == document.getElementById("button-5") ) {

hide_menu(evt);

postURL(targetPostHost, menu_btn_action[4], urlCallBackObject, "text", "ascii");

}

function hide_menu(evt) {

var button1 = document.getElementById("button-1");

var button2 = document.getElementById("button-2");

var button3 = document.getElementById("button-3");

var button4 = document.getElementById("button-4");

var button5 = document.getElementById("button-5");

button1.setAttribute("x", outside);

button1.setAttribute("y", outside);

button2.setAttribute("x", outside);

button2.setAttribute("y", outside);

button3.setAttribute("x", outside);

button3.setAttribute("y", outside);

button4.setAttribute("x", outside);

button4.setAttribute("y", outside);

button5.setAttribute("x", outside);

button5.setAttribute("y", outside);

}

function first_click_on_video(evt) {

var x = evt.screenX; // Get x coordinate for the click

var y = evt.screenY; // Get y coordinate for the click

var target = evt.target; // This resolves the target of click,

// for example whole video area or defined

// part of that (that would be separate element)

var video_playing = document.getElementById("video");

var timestamp = video_playing.getVideoStreamTime();

// The above captures the time of click in terms of current video time

// This is new extension to DOM access for "video" element

var video_name = video_playing.getAttributeNS("http://www.w3.org/1999/xlink", "href");

if (target == document.getElementById("video")) {

// Here we pass resolved event attributes & context to menu creation function

show_menu(x, y, target, timestamp, video_name);

}

if (target == document.getElementById("hot-area")) {

// here goes code if user clicks a specific "hot area" on screen

}

function init() {

urlCallBackObject = new PostUrlCallBackClass();

}

]]></script>

init();

</handler>

<video id="v1" begin="0s" dur="240s" xlink:href="carshow_ATSC-MH-480x272.mp4" x="0%" y="0%" width="480" height="272"

transformBehavior="geometrical" viewport-fill="black">

<handler type="application/ecmascript" ev:event="click">first_click_on_video(evt);</handler>

</video>

</g>

<handler type="application/ecmascript" ev:event="click">menu_click(evt);</handler>

</image>

</image>

</image>

</image>

</image>

</g>

<animate id="triggered-ad-anim" attributeType="CSS" attributeName="opacity"

begin="indefinite" from="0" to="0.8" dur="1s" fill="freeze"/>

<animate attributeType="CSS" attributeName="opacity"

begin="triggered-ad-anim.begin+3s" from="0.8" to="0" dur="2s" fill="freeze"/>

</image>

</g>

<animate attributeType="CSS" attributeName="y"

begin="25" from="272" to="209" dur="2s" fill="freeze"/>

<animate attributeType="CSS" attributeName="y"

begin="33" from="209" to="272" dur="2s" fill="freeze"/>

</image>

<animate attributeType="CSS" attributeName="y"

begin="33" from="209" to="272" dur="2s" fill="freeze"/>

<handler type="application/ecmascript" ev:event="click">change_video(evt);</handler>

</image>

<animate attributeType="CSS" attributeName="y"

begin="33" from="240" to="303" dur="2s" fill="freeze"/>

</image>

</g>

</svg>

이제 도 4를 참조하면, 상이한 실시예들에 따른 예시적인 프로세스가 도시된다. 단계 1에서, 사용자가 메인 비디오 스트림 클릭한다. 클릭하면, 상기 클릭을 분석하기 위해 단계 2에서 "first_click_on_video(evt)" 함수가 호출된다. 단계 3에서, "first_click_on_video(evt)" 는 분석된 클릭 파라미터를 이용하여 메뉴를 구축하기 위해 "show_menu(x, y, target, timestamp, video_name)"를 또한 호출한다. 상기 "show_menu(x, y, target, timestamp, video_name)"는 메뉴를 보여주고 그리고, 예를 들면, 메뉴 버튼이 단계 4에서 클릭될 때에 서버로 전달될 타겟 스트링인 변수 "menu_btn_command[n]"에 연관된 명령어를 저장한다. 단계 5에서, 사용자가 스크린 상의 메뉴 아이템 "n"을 클릭할 때에, 연관된 핸들러 "menu_click(evt)"는 menu_btn_command[n] 으로부터 추가 데이터를 인출하고 그리고 HTTP POST를 타겟 호스트로 발행한다. 단계 1-5는 상기에서의 예시의 스크립트로 달성될 수 있을 것이다.

다음은 서버 말단에서 상기 프로세스들을 설명한다. 단계 6에서, 상기 서버는 HTTP POST를 수신하고 그 요청을 분석한다. 상기 서버는 상기 발행된 데이터로부터 클라이언트에 적용될 장면 업데이트, 예를 들면, 단계 7에서 광고 삽입을 하는 장면 업데이트를 결정한다. 단계 8에서, 상기 장면 업데이트는 HTTP POST 응답의 페이로드로서 반환되고 그리고 HTTP의 "콘텐트 유형 (Content-Type)" 헤더를 이용하여 장면 업데이트 콘텐트로서 식별된다. 그러면 상기 단말은 서버로부터 상기 응답을 수신한다.

단계 9에서, HTTP POST에 대한 응답을 하면, 상기 RME 엔진은 "urlCallBackObject"로의 콜백을 불러낸다. 상기 콜백 오브젝트는 상기 응답으로부터 상기 장면 업데이트를 캡슐 해제한다. 자바스크립트를 실행시켜, 상기 RME 엔진은 장면 업데이트를 적용하고 그리고 상기 DOM을 처리하며, 그러면 그 장면 업데이트의 효과가 보여진다.

일부 경우들에서, RME 스트림의 송신기는 개인화된 타겟 광고를 위치시키는 장면 업데이트를 적용하기를 원할 수 있을 것이다. 상기 광고는 단순한 이미지 또는 심지어는 더 풍부한 기능들을 포함하는 완전한 RME 문서일 수 있다. 상기 광고 위치 명령 또는 장면 업데이트는 예를 들면, 렌더링될 이미지 또는 RME 문서 등의 몇몇의 자원을 참조하는 것이 필요할 수 있을 것이다. 상기 송신기는 단일의 장면 업데이트를 송신하기만을 원할 수 있을 것이다. 실시예들에 따라서, SVG, RME, 플래시, MPEG4-LASeR, 또는 유사한 장면/레이아웃 기술들 및 그것들의 업데이트들은 정확하게 식별되는 것을 대신하는 기준을 기반으로 하여 자원들을 참조할 수 있을 것이다.

이런 면에서, 본 발명의 실시예들은 1) 자원 액세스를 기반으로 하는 기준에 특정된 URI 방식을 이용할 수 있을 것이며; 2) 기초가 되는 문서 오브젝트 모델 (Document Object Model (DOM))을 확장할 수 있을 것이며; 또는 3) "localhost"에서 로컬 단말-영역 (terminal-bound) 서버를 이용할 수 있을 것이다.

한가지 실시예에서, 자원 액세스 기반의 기준에 특정된 URI 방식이 이용된다. 한가지 예시적인 URI 방식은 아래와 같이 제공된다:

Criteria-URI :== URI-scheme-id "://" *(criterion-key "=" criterion-value "?")

URI-scheme-id :== 　"cref"　

Criterion-key :== <any char string without white spaces>

Criterion-value :== <any char string without white spaces>

상기 "cref"-방식은 URI가 이용되는 곳에서는 어디에서든, 보통은 "xlink:href" 또는 "href" 속성과 같이 사용될 수 있으며, 그러나, 그것들만으로 배제되는 것은 아니다.

예시의 URI:

cref://ziplocation=10804?genre=sport

다음은 RME에서 URI를 이용하는 것을 예시하는 예이다.

<gid="targeted-ad">

<image x="250" y="130" width="230" height="132" opacity="0.7"

xlink:href="cref://ziplocation=10804?genre=sport"/>

</g>

상기의 예에서, 상기 RME 엔진은 "cref"-URI를 대응하는 핸들러로 전달한다. 그러므로, 상기 새로운 "cref"-방식을 지원하기 위해, 상기 RME 엔진/단말은 그런 핸들러를 구비해야만 한다. 상기 핸들러는 상기 전달된 "cref"-URI를 "href"를 이용하여 포인팅될 수 있는 참조로 결정하고 그리고 그것을 RME 엔진으로 돌려보낸다. 키-값 기준 쌍들을 결정하는 것은 각 구현에 특정한 것이다. 이런 것을 하는 한 가지 방법은 몇몇 실시예들에서 우선 순위가 결정될 수 있을 복수의 가능한 값들을 구비한 각 키를 이용하여 키들의 레지스트리를 유지하는 것이다. 또한, 각 키는 로컬 자원, 예를 들면 파일과 링크된다. 상기 "cref" 기준을 정합 (matching)시키면, 각 "cref"-키는 상기 레지스트리로부터 룩업 (look up)되며 그러면 상기 룩업 값들은 상기 "cref"에서 상기 값과 정합된다. 결국, 이런 방식으로 가장 잘 정합되는 상기 로컬 자원은 반환된다.

상기의 예를 고려하면, 이런 두 개의 최종적인 해석들이 "cref" 프로세싱 이후에 가능하다:

1) 단순 이미지로 결정됨

<image x="250" y="130" width="230" height="132" opacity="0.7"

xlink:href="car-ad.png"/>

</g>

2) 이미지를 구축하는 더욱 복잡한 방식으로 결정됨

<image x="250" y="130" width="230" height="132" opacity="0.7"

xlink:href="ad-example.svg"/>

</g>

몇몇의 실시예들에서 적절한, 아마도 위치와 최종 사용자 특정된, 광고 클립은, 예를 들면, 다음에 의해서 수행될 수 있다.

상기 컴포넌트는 상기 파일을 표시하는 URI를 결정한다. 상기 URI는 상기 파일 (file://foo/eric.mpg)을 직접적으로 가리킬 수 있을 것이며 또는 정합될 상기 기준을 인코딩하는 것에 의해 형성될 수 있을 것이다. 후자는 보통의 URI들에서 발견되는 키-값 쌍들의 모습으로 존재할 수 있을 것이다. 예를 들면, cref://favouriteColour=red&sex=female&age=25 은 25세 여자에 대해 그리고 그 여자가 좋아하는 색상이 적색인 것에 대한 광고를 나타내는 파일로 결정할 것이다.

상기 SVG 재생기는 스크립트들이 호출하기 위한 정적인 함수를 제공할 수 있을 것이다. 이 함수는 상기 보여진 문서의 DOM-트리의 글로벌 서비스들의 일부로서 제공된다. 상기 기준, 예를 들면, 좋아하는 색상, 성별 및 나이가 스크립트를 호출함으로써 함수의 인수들 또는 파라미터들로서 주어진다. 다른 말로 하면, 상기 스크립트는 상기 주어진 기준에 부합하는 가장 적절한 파일을 결정하기 위해 상기 "보여진 문서"에게 요청하고 있다.

광고로서 렌더링될 상기 파일의 네트워크에 의한 표시는 이제 중점을 두어 다루어질 것이다. 평범한 이름은 일상적인 것이고 이미 지원되고 있다고 가정한다. 여기에서, 최종 사용자 선호도를 기반으로 하는 또는 몇몇의 실시예들에서는 현재의 위치를 기반으로 하는 조건적인 선택이 가능해진다. 단말이 광고를 렌더링하기 위한 네트워크로부터의 트리거는 그러면 상기 기준이 인코딩된 URI ("cref") 또는 상기 SVG 재생기에 의해 제공된 결정 함수를 호출하는 스크립의 부분만을 포함할 수 있을 것이다. 상기 기준-인코딩된 URI ("cref")에 대한 핸들러는 파일 시스템일 수 있을 것이며 또는 상기 문서나 문서 업데이트가 SVG 재생기에게 파일을 오픈하라고 알리면 파일 시스템으로 하여금 상기 파일을 오픈할 것을 요청하는 상기 SVG 재생기의 그런 일부일 수 있을 것이다.

다른 실시예에서, 기초가 되는 문서 오브젝트 모델 (Document Object Model (DOM))은 확장될 수 있을 것이다. 다음의 예는 SVG 1.2 Tiny Micro DOM 과 함께 주어진다. SVG uDOM 글로벌은 다음과 같이 확장되며, 그 경우에 추가된 부분은 밑줄과 함께 보여진다:

interface SVGGlobal : Global, EventListenerInitializer2

{

Connection createConnection();

Timer createTimer(in long initialInterval, in long repeatInterval)

raises(GlobalException);

void gotoLocation(in DOMString newIRI);

readonly attribute Document document;

readonly attribute Global parent;

DOMString binaryToString(in sequence<octet> octets, in DOMString encoding)

raises(GlobalException);

sequence<octet> stringToBinary(in DOMString data, in DOMString encoding)

raises(GlobalException);

void getURL(in DOMString iri, in AsyncStatusCallback callback);

void postURL(in DOMString iri, in DOMString data, in AsyncStatusCallback callback,

in DOMString type, in DOMString encoding);

Node parseXML(in DOMString data, in Document contextDoc);

DOMString createLocalRefByFilterRules(in DOMString filterRules);

};

createLocalRefByFilterRules

filterRule과 정합하는 (로컬 파일 시스템 상의 파일과 같은) 로컬 자원에 연관된 IRI 레퍼런스를 생성한다.

파라미터들:

in DOMString filterRules

"?"-각 키가 자신의 연관된 값에 선행하고 그리고 키가 등호 표시에 의해서 값과 분리되는 경우 범위가 정해진 스트링 또는 키-값. 예: "favoriteContent=sailing?userType=male".　최선으로 정합되는 자원으로의 로컬 IRI 레퍼런스를 단말이 생성하는, 타겟 필터 규칙들의 목록을 규정한다.

반환 값 (Return value):

DOMString

로컬 IRI 레퍼런스의 스트링 표현.

예외들 (Exceptions)

GlobalException

UNDEFINED_ERR: 파라미터 'filterRules'에 대한 값이 주어지지 않으면 일어난다.

사용되는 예:

function show_targetted_ad (evt) {

var svgNS = "http://www.w3.org/2000/svg";

var xlinkNS = "http://www.w3.org/1999/xlink";

var xmlNS = "http://www.w3.org/XML/1998/namespace";

var topGroup = document.getElementById("top");

var toBeAdded = document.createElementNS(svgNS, "image");

var ref = createLocalRefByFilterRules(　ziplocation=10804?genre=sport　);

toBeAdded.setAttributeNS(xlinkNS, "href", ref);

toBeAdded.setAttribute("x", "130");

toBeAdded.setAttribute("y", "100");

toBeAdded.setAttribute("width", "165");

toBeAdded.setAttribute("height", "78");

toBeAdded.setAttribute("opacity", "0.7");

topGroup.appendChild(toBeAdded);

} ]]> </script>

다른 실시예에서, 로컬 단말-영역 서버는 "localhost"에서 사용된다. 이 옵션은 첫 번째 옵션과 유사하다. 차이는 이 경우에 어떤 새로운 URI 방식도 필요하지 않지만, 그러나 http-URI는 'localhost'를 가리키기 위해 사용된다는 것이다. 상기 URI 정의는 다음과 같다:

URI-to-be-used :==　"http://localhost/cref?" *(criterion-key "=" criterion-value "?")

Criterion-key :== <화이트 스페이스들이 없는 임의 문자 (char)>

Criterion-value :== <화이트 스페이스들이 없는 임의 문자 (char)>

그러므로, 이 경우에서의 "cref"는 'localhost'에 이미 직접적으로 존재하는 자원이다 - 예를 들면 서버 스크립트. 이 스크립트는 보통의 http 방법들을 통해서 전달된 기준 키-값 쌍들이다.

예:

<image x="250" y="130" width="230" height="132" opacity="0.7"

xlink : href ="http://localhost/cref?ziplocation=10804?genre=sport"/>

</g>

상기에서 설명된 것과 같이, 사용자 선호도들은 타겟이 된 광고들을 제공하기 위해 사용될 수 있을 것이다. 이런 면에서, 최종 사용자 선호도들 및/또는 프로파일들을 생성하기 위해 다양한 실시예들이 제공된다. 그런 사용자 선호도들/프로파일들은 사용된 시간 그리고 사용되었을 때에는, 예를 들면, 그 하루의 시간 및/또는 그 주의 하루를 포함하는 상기 단말의 등록된 사용자를 고려할 수 있을 것이다.

최종 사용자 선호도들 또는 프로파일들은 다양한 방식들로 특성화될 수 있을 것이다. 그러므로, 상기 프로파일을 위한 일반적인 구조를 미리 정의하는 것은 불가능한 것은 아니지만, 실용적이지는 않다. 다른 말로 하면, 모든 이용의 경우들을 수용할 수 있는 선호도 또는 프로파일 구조를 찾아내는 것은 매우 어렵다. 가끔, "키 (key)"-"값 (value)" 쌍들의 목록들이 활용되며, 이 경우 상기 "키"는 문제의 파라미터를 나타내며 그리고 상기 "값"은 상기 파라미터의 개별 값을 나타낸다. 결국 이것은 콘텐트나 서비스들을 제공하는 주체가 수신 기기가 최종 사용자 선호도들과 정합될 것으로 기대될 수 있는 임의의 특성들을 제공하기 위한 도구가 전혀 아니라는 것을 의미한다.

상이한 실시예들에 따라서, 최종 사용자 선호도들 및 프로파일을 나타내기 위한 상기 데이터 구조는 EndUserPref 로서 언급된다. 도 5는 EndUserRef를 개발하기 위한 예시적인 프로세스 (500)를 예시한다. 콘텐트 제공자는 상기 최종 사용자에게 EndUserRef로 귀결되는 질문서를 제공한다. 상기 질문서가 다양한 방식들로 제공될 수 있을 것이며 그리고 상기 EndUserRef는 다양한 방식으로 형성될 수 있을 것이다.

일 실시예에서, 사용자는 웹 페이지 상에서 양식을 채운다. 그 양식에서의 대답들은 스크립트로, 예를 들면, 상기 EndUserPref를 구축하고 그리고 그것을 상기 단말에 국지적으로 저장하는 자바스크립트로 주어진다.

다른 실시예에서, 상기 서비스 또는 콘텐트 그 자체를 제공할 때에, 유사한 스크립트가 상기 콘텐트 또는 서비스와 같이 제공되며 그리고 실행되어 상기 EndUserPref의 결과가 된다. 상기 결과인 EndUserPref는 상기 단말에 국지적으로 저장될 수 있을 것이다. 대안으로, 상기 결과인 EndUserPref는 상기 콘텐트나 서비스 그 자체를 나타내는 XML 문서 오브젝트 모델 (Document Object Model (DOM))로 직접 저장될 수 있다.

다른 실시예에서, 상기 질문서는, 사용자의 승인이 있으면, 상기 최종 사용자가 선호하는 콘텐트 종류를 추적하는 것을 계속하고, 그리고 EndUserPref를 형성하고 그리고 계속적으로 업데이트하는 자동적인 탐침 또는 굴착기일 수 있을 것이다.

다른 실시예에서, 상기 질문서들은, 사용자의 승인이 있으면, 로컬 파일들, 캐시들 (caches), 프로그램 세팅들, 북마크들 등을 검색하고, 그리고 그 검색을 기반으로 하여 EndUserPref를 추론하는 자동적인 탐침 또는 굴착기일 수 있을 것이다.

다른 실시예에서, 상기 질문서들은, 사용자의 승인이 있으면, 인터넷 자원들, 예를 들면, 페이스북과 같은 소셜 네트워킹 사이트들을 검색하고 그리고 그 검색을 기반으로 하여 EndUserPref를 추론하는 자동적인 탐침 또는 굴착기일 수 있을 것이다.

EndUserPref를 국지적으로 저장하는 것은 예를 들면 OMA 디바이스 관리에서 사용되는 것과 같은 동적 독점 단말 공급 관리 오브젝트들 (management objects (MO))을 생성함으로써 달성될 수 있을 것이다. 이런 경우에, 상기 MO가 원칙적으로 임의의 곳으로부터 유래할 수 있는 것과 같이 임의의 도구들 및 임의 유형의 질문서들이 존재할 수 있다.

일 실시예에서, 상기 EndUserPref는 특별한 콘텐트/서비스의 일반적인 또는 표준화된 특성들과 같이 일반적인 또는 표준화된 포맷을 통해서 적용될 수 있을 것이다. 상기 포맷은 알려진 것이며, 그러므로, 개별 파라미터들의 어의 (semantics)나 그 파라미터들의 대응 값들을 알지 못하면서도 상기 EndUserPref에 대한 상기 프로그램의 특성들 간의 비교를 수행할 수 있다.

다른 실시예에서, 상기 EndUserPref는 특별한 콘텐트/서비스의 독점권 특성들과 같이 독점 포맷을 통해서 적용될 수 있을 것이다. 이런 면에서, 상기 EndUserPref 그리고 특별한 콘텐트/서비스의 특성들에 대한 콘텐트/서비스 특정 분석이 필요할 수 있을 것이다. 이 실시예는 선호도들 및 특성들을 특성화하는 가장 유연한 방식을 허용하는 이점을 제공한다.

EndUserPref는 다양한 위치들에 저장될 수 있을 것이다. 일 실시예에서, 서비스 또는 콘텐트 이용을 시작하면, 상기 EndUserPref는 상기 XML DOM 오브젝트로 적재될 수 있다. 다른 실시예에서, 서비스 또는 콘텐트 이용을 시작하면, 상기 질문서가 상기 최종 사용자에게 표현되며, 그리고 상기 EndUserPref는 이 서비스 또는 콘텐트용으로 특별하게 구축된다.

상기 EndUserPref는 다양한 방식들로 단말 내에 저장될 수 있을 것이다. 일 실시예에서, 상기 EndUserPref는 독점 데이터베이스 내에 저장될 수 있을 것이다. 다른 실시예에서, 상기 EndUserPref는 OMA 디바이스 관리와 같은 보통의 데이터베이스 또는 표준화된 데이터베이스 내에 저장될 수 있을 것이다. 비록 일반적인 포맷 또는 표준화된 데이터베이스 내에 저장되지만, 상기 EndUserPref는 독점 포맷이나 일반적인 포맷 또는 표준화된 포맷 중의 어느 하나로 저장될 수 있을 것이다.

저장부 내의 EndUserPref의 포맷이나 저장 방법에 관계없이, XML DOM 내의 EndUserPref의 표현은 독점적이거나 또는 표준화된 것 중의 어느 하나이다.

도 6 및 도 7은 상기 실시예들이 실행될 수 있는 하나의 전형적인 모바일 기기 (12)를 보여준다. 그러나, 상기 실시예들은 하나의 특정 유형 전자 기기로 한정되는 의도가 아니라는 것이 이해되어야만 한다. 도 6 및 도 7의 상기 모바일 기기 (12)는 하우징 (30), 액정 디스플레이 형상의 디스플레이 (32), 키패드 (34), 마이크로폰 (36), 이어-피스 (38), 배터리 (40), 적외선 포트 (42), 안테나 (44), 일 실시예에 따른 UICC 형상의 스마트 카드 (46), 카드 리더기 (48), 무선 인터페이스 회로 (52), 코덱 회로 (54), 제어기 (56) 및 메모리 (58)를 포함한다. 개개의 회로들 및 엘리먼트들은 모두 당 업계에서, 예를 들면, 모바일 전화기들의 노키아 영역 내에서 잘 알려진 유형이다.

여기에서 설명된 다양한 실시예들은, 일 실시예에서는, 컴퓨터로 읽을 수 있는 매체에서 구체화된, 네트워크 환경에서 컴퓨터들에 의해 실행되는 프로그램 코드와 같은 컴퓨터-실행가능 명령어들을 포함하는 컴퓨터 프로그램 제품에 의해 구현될 수 있을 방법 단계들 또는 프로세스들의 일반적인 맥락으로 설명된다. 일반적으로, 프로그램 모듈들은 특정 태스크를 수행하고 또는 특정의 추상적인 데이터 유형들을 구현하는 루틴들, 프로그램들, 오브젝트들, 컴포넌트들, 데이터 구조 등을포함할 수 있을 것이다. 데이터 구조들과 연관된 컴퓨터-실행가능 명령어들 및 프로그램 모듈들은 여기에서 개시된 방법들의 단계들을 실행시키기 위한 프로그램 코드의 예들을 나타낸다. 그런 실행 가능한 명령어들의 특정 시퀀스 또는 연관된 데이터 구조들은 그런 단계들 또는 프로세스들에서 설명된 기능들을 구현하기 위한 대응 행동들의 예들을 나타낸다.

다양한 실시예들의 소프트웨어 구현 및 웹 구현은 다양한 데이터베이스 검색 단계들 또는 프로세스들, 상관 단계들 또는 프로세스들, 비교 단계들 또는 프로세스들 및 결정 단계들 또는 프로세스들을 달성하기 위한 규칙-기반 로직 및 다른 로직을 갖춘 표준의 프로그래밍 기술들을 이용하여 달성될 수 있다. 여기에서 그리고 이어지는 청구범위에서 사용되는 것과 같은, "컴포넌트" 및 "모듈"의 단어들은 수동 입력들을 수신하기 위한 하나 또는 그 이상의 소프트웨어 코드 라인들 및/또는 하드웨어 구현들 및/또는 장비를 이용하는 구현들을 포함하려는 것으로 의도된 것이라는 것에 유의하여야 한다.

실시예들의 상기 상술한 설명은 예시 및 설명의 목적으로 제공되었다. 상기 상술한 설명은 전부 망라하려는 의도가 아니며 또는 실시예들을 개시된 정확한 모습으로 한정하려는 의도도 아니며, 그리고 수정 및 변형들이 상기의 교시들을 비추어서 가능하며 또는 그런 수정 및 변형들은 다양한 실시예들을 실행하는 것으로부터 얻어질 수 있을 것이다. 여기에서 설명된 실시예들은 본 발명의 다양한 실시예들 및 실제의 응용의 원칙들 및 속성을 설명하기 위해 선택되어 기술되어, 본 발명의 속한 기술 분야의 통상의 지식을 가진 자가 다양한 실시예들에서 그리고 숙고된 특정 사용에 적합한 다양한 수정 사항들과 함께 본 발명을 활용하는 것을 가능하게 한다.

Claims

프레젠테이션 기술 (presentation description) 언어를 이용하여 표시 가능한 콘텐트용의 콘텐트 업데이트를 수신하며; 그리고
상기 프레젠테이션 기술 언어를 이용해서 상기 콘텐트 업데이트를 기반으로 상기 콘텐트에 보충 (complementary) 정보를 삽입하는 것을 포함하는, 방법.
제1항에 있어서,
상기 프레젠테이션 기술 언어는 리치 (rich) 미디어 환경 및 동기화된 멀티미디어 집적 언어 (synchronized multimedia integration language) 중의 하나 이상을 포함하는, 방법.
제1항 또는 제2항에 있어서,
상기 보충 정보는 광고 콘텐트, 선택 정보, 프로그램 스케줄들 변경, 날씨 예보 및 교통 정보 중의 하나 이상을 포함하는, 방법.
제3항에 있어서,
상기 콘텐트 업데이트는 상기 광고 콘텐트로의 참조 (reference)를 포함하는, 방법.
제3항에 있어서,
상기 콘텐트 업데이트는 상기 광고 콘텐트를 포함하는, 방법.
제1항 내지 제5항 중의 어느 한 항에 있어서,
상기 콘텐트 업데이트는 장면 (scene) 업데이트를 위한 업데이트 명령어들을 포함하며,
상기 업데이트 명령어들은 삽입 동작, 삭제 동작, 교체 동작 및 추가 동작 중의 하나 이상을 포함하는, 방법.
제1항 내지 제6항 중의 어느 한 항에 있어서,
상기 콘텐트 업데이트는 수신 단말에 특정된 콘텐트 업데이트, 최종 사용자에 특정된 콘텐트 업데이트 및 모든 수신 단말들에 대한 콘텐트 업데이트 중의 하나 이상을 포함하는, 방법.
컴퓨터로 읽을 수 있는 매체에 구체화된 컴퓨터 프로그램 제품으로서,
제1항 내지 제7항 중의 어느 한 항의 프로세스를 실행하도록 구성된 컴퓨터 코드를 포함하는, 컴퓨터 프로그램 제품.
프로세서를 포함하는 장치로서,
상기 프로세서는,
프레젠테이션 기술 (presentation description) 언어를 이용하여 표시 가능한 콘텐트용의 콘텐트 업데이트를 수신하며; 그리고
상기 프레젠테이션 기술 언어를 이용해서 상기 콘텐트 업데이트를 기반으로 상기 콘텐트에 보충 (complementary) 정보를 삽입하도록 구성된, 장치.
제9항에 있어서,
상기 프레젠테이션 기술 언어는 리치 (rich) 미디어 환경 및 동기화된 멀티미디어 집적 언어 (synchronized multimedia integration language) 중의 하나 이상을 포함하는, 장치.
제9항 또는 제10항에 있어서,
상기 보충 정보는 광고 콘텐트, 선택 정보, 프로그램 스케줄들 변경, 날씨 예보 및 교통 정보 중의 하나 이상을 포함하는, 장치.
제11항에 있어서,
상기 콘텐트 업데이트는 상기 광고 콘텐트로의 참조를 포함하며 그리고
상기 프로세서는 상기 참조를 기반으로 하여 상기 광고 콘텐트를 검색하도록 또한 구성된, 장치.
제11항에 있어서,
상기 콘텐트 업데이트는 상기 광고 콘텐트를 포함하는, 장치.
제11항에 있어서,
상기 프로세서는 브로드캐스트 배송 세션으로부터 광고 콘텐트를 수신하도록 또한 구성된, 장치.
제9항 내지 제14항 중의 어느 한 항에 있어서,
상기 콘텐트 업데이트는 장면 (scene) 업데이트를 위한 업데이트 명령어들을 포함하며,
상기 업데이트 명령어들은 삽입 동작, 삭제 동작, 교체 동작 및 추가 동작 중의 하나 이상을 포함하는, 장치.
제9항 내지 제15항 중의 어느 한 항에 있어서,
상기 프로세서는 네트워크로부터의 독점 (proprietary) 시그날링을 적어도 부분적으로 기반으로 하여 장면 업데이트들을 생성하도록 또한 구성된, 장치.
제9항 내지 제16항 중의 어느 한 항에 있어서,
상기 콘텐트 업데이트는 수신 단말에 특정된 콘텐트 업데이트, 최종 사용자에 특정된 콘텐트 업데이트 및 모든 수신 단말들에 대한 콘텐트 업데이트 중의 하나 이상을 포함하는, 장치.
프레젠테이션 기술 (presentation description) 언어를 이용하여 표시 가능한 콘텐트용의 콘텐트 업데이트를 생성하는 것을 포함하며, 이 경우 상기 콘텐트 업데이트는 상기 콘텐트에 삽입하기 위한 용도의 보충 정보와 연관되며; 그리고
상기 프레젠테이션 기술 언어를 이용하여 상기 콘텐트 업데이트를 전송하는 것을 포함하는, 방법.
제18항에 있어서,
상기 프레젠테이션 기술 언어는 리치 (rich) 미디어 환경 및 동기화된 멀티미디어 집적 언어 (synchronized multimedia integration language) 중의 하나 이상을 포함하는, 방법.
제18항 또는 제19항에 있어서,
상기 보충 정보는 광고 콘텐트, 선택 정보, 프로그램 스케줄들 변경, 날씨 예보 및 교통 정보 중의 하나 이상을 포함하는, 방법.
제20항에 있어서,
상기 콘텐트 업데이트는 상기 광고 콘텐트에 대한 참조를 포함하는, 방법.
제20항에 있어서,
상기 콘텐트 업데이트는 상기 광고 콘텐트를 포함하는, 방법.
제18항 내지 제22항 중의 어느 한 항에 있어서,
상기 콘텐트 업데이트는 장면 (scene) 업데이트를 위한 업데이트 명령어들을 포함하며,
상기 업데이트 명령어들은 삽입 동작, 삭제 동작, 교체 동작 및 추가 동작 중의 하나 이상을 포함하는, 방법.
제18항 내지 제23항 중의 어느 한 항에 있어서,
상기 콘텐트 업데이트는 수신 단말에 특정된 콘텐트 업데이트, 최종 사용자에 특정된 콘텐트 업데이트 및 모든 수신 단말들에 대한 콘텐트 업데이트 중의 하나 이상을 포함하는, 방법.
컴퓨터로 읽을 수 있는 매체에 구체화된 컴퓨터 프로그램 제품으로서,
제18항 내지 제25항 중의 어느 한 항의 프로세스를 실행하도록 구성된 컴퓨터 코드를 포함하는, 컴퓨터 프로그램 제품.
프레젠테이션 기술 (presentation description) 언어를 이용하여 표시 가능한 콘텐트용의 콘텐트 업데이트를 생성하도록 구성된 프로세서로서, 이 경우 상기 콘텐트 업데이트는 상기 콘텐트에 삽입하기 위한 용도의 보충 정보와 연관된, 프로세서; 및
상기 프레젠테이션 기술 언어를 이용하여 상기 콘텐트 업데이트를 전송하기 위한 컴퓨터 코드;를 포함하도록 구성된, 장치.
제26항에 있어서,
상기 프레젠테이션 기술 언어는 리치 (rich) 미디어 환경 및 동기화된 멀티미디어 집적 언어 (synchronized multimedia integration language) 중의 하나 이상을 포함하는, 장치.
제26항 또는 제27항에 있어서,
상기 보충 정보는 광고 콘텐트, 선택 정보, 프로그램 스케줄들 변경, 날씨 예보 및 교통 정보 중의 하나 이상을 포함하는, 장치.
제28항에 있어서,
상기 콘텐트 업데이트는 상기 광고 콘텐트에 대한 참조를 포함하는, 장치.
제28항에 있어서,
상기 콘텐트 업데이트는 상기 광고 콘텐트를 포함하는, 장치.
제26항 내지 제30항 중의 어느 한 항에 있어서,
상기 콘텐트 업데이트는 장면 (scene) 업데이트를 위한 업데이트 명령어들을 포함하며,
상기 업데이트 명령어들은 삽입 동작, 삭제 동작, 교체 동작 및 추가 동작 중의 하나 이상을 포함하는, 장치.
제26항 내지 제31항 중의 어느 한 항에 있어서,
상기 콘텐트 업데이트는 수신 단말에 특정된 콘텐트 업데이트, 최종 사용자에 특정된 콘텐트 업데이트 및 모든 수신 단말들에 대한 콘텐트 업데이트 중의 하나 이상을 포함하는, 장치.