KR20130140719A - 정보의 전송 - Google Patents

Abstract

본 발명은 핸드셋으로의 푸시 정보의 전송에 관한 것이다. 페이지를 핸드셋에 푸싱하기 이전에, 페이지가 현재 표시하는 동일한 서비스에 그 페이지가 속하는지가 체크된다. 푸싱될 페이지가 상이한 서비스에 속하는 경우에, 푸시되지 않는다. 그럼으로써, 원래 서비스의 오염의 위험이 감소된다. 체크는 양호하게는 핸드셋이 접속되는 게이트웨이에 의해 수행된다. 게이트웨이는 체크를 용이하게 하기 위해 핸드셋에 최종 송신된 페이지의 세부사항들을 저장할 수 있다.

Description

정보의 전송{TRANSMITTING INFORMATION}

본 발명은 정보의 전송에 관한 것으로, 특히 푸시 방식의 정보의 전송에 관한 것이다.

노드, 특히 사용자 핸드셋과 같은 모바일 노드에 상이한 방식들로 정보를 송신하는 것이 알려져 있다. 풀 방식으로 알려진 하나의 방식에서, 정보는 노드로부터 발원하는 요구에 응답하여 송신된다. 일단 요구된 정보가 송신되었다면, 추가 정보가 송신되기 위해서는 정상적으로는 추가 요구가 필요하다. 정보를 이와같은 방식으로 풀링하는 하나의 잇점은 사용자로부터의 요구에 직접 응답하여 송신되므로, 정보가 수신되는 때에 대한 사용자 제어를 제공한다는 점이다. 정보를 풀링하는 하나의 예는 사용자가 퍼스널 컴퓨터의 브라우저 상에 검색 스트링을 입력하고, 원격 서버가 매칭 링크들의 리스트를 포함하는 페이지를 리턴하는 것이다. 그리고나서, 사용자는 링크를 클릭하여 원하는 페이지를 검색함으로써 추가 풀 액션을 수행할 수 있다.

푸시 방식으로 알려진, 정보를 통신하는 또 하나의 방법에서, 정보를 송신하려는 결정은 수신 노드로부터 원격으로 유발된다. 예를 들면, 사용자는 주식-가격 서비스에 가입했을 수 있다. 그러면, 주식-가격 서버는 주식-가격 다큐먼트를 사용자 노드에 송신하여 사용자에게 특정 주식 가격을 통지할 것이다. 다큐먼트를 송신하려는 결정은 특정 주식 가격이 임계 레벨에 도달하는 것에 응답하여 수행될 수 있다. 대안적으로는, 결정은 타이머에 기초하여 수행될 수 있으므로, 주식 가격 뉴스 다큐먼트는 예를 들면 매일 사용자 핸드셋에 송신된다. 각 경우에, 정보는 사용자에게 효율적으로 푸시된다.

정보가 요구될 때마다 사용자가 요구를 송신해야 할 필요가 없으므로, 정보를 푸싱하는 것은 통신에 필요한 대역폭을 감소시킨다는 장점을 가지고 있다. 그러나, 정보의 푸싱이 문제가 되는 상황들이 있을 수 있다.

본 발명의 하나의 양태에 따르면, 제1 컨텐츠는 수신되는 경우에, 노드에서 렌더링되는 제2 컨텐츠 - 존재하는 경우에 - 대신에, 노드로 하여금 제1 컨텐츠를 렌더링하게 하도록 구성되는, 노드 외부에서 발원되는 명령들에 응답하여 노드에 제1 컨텐츠를 송신하기 위한 장치가 제공되고, 제1 컨텐츠 및 제2 컨텐츠은 각각 각 서비스와 연관되며, 그 장치는 (i) 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되는지 여부를 결정하고, (ii) 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되어 있는지의 여부에 종속하여 제1 컨텐츠가 송신되게 하도록 구성된 처리 스테이지를 포함한다.

장치는 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되어 있는지의 여부에 따라 제1 컨텐츠가 노드에 송신되게 되도록 구성되기 때문에, 장치는 제1 컨텐츠 및 제2 컨텐츠가 상이한 서비스들에 연관되어 있다고 결정된다면, 제1 컨텐츠가 노드에 송신되는 것을 유발하는 것을 금지할 수 있다. 결과적으로, 하나의 서비스를 운영하는 노드가 또 하나의 서비스로부터 새로운 컨텐츠를 예기치 않게 수신할 가능성 - 새로운 컨텐츠는 원래 서비스를 오염시킬 수 있음 - 이 감소될 것이다. 노드의 사용자는 새로운 컨텐츠의 도달을 정상적으로는 예측할 수 없을 것이므로, 이것은 노드 외부에서 발원하는 명령들에 응답하여 송신되는 컨텐츠의 경우에 특히 중요하다.

컨텐츠는 서비스 모듈로부터 발원할 수 있고, 처리 스테이지는 제어 명령을 서비스 모듈에 송신함으로써 컨텐츠가 송신되도록 유발할 수 있다. 서비스 모듈은 장치의 일부일 수 있고, 이 경우에 제어 명령은 양호하게는 내부 명령일 것이다. 즉, 처리 스테이지는 양호하게는, 통신 스테이지가 컨텐츠를 송신하도록 효율적으로 유발할 것이다. 대안적으로는, 서비스 모듈은 장치로부터 원격으로 로케이팅될 수 있고, 통신 네트워크를 통해 장치와 통신하도록 구성될 수 있다. 이 경우에, 제어 명령은 양호하게는 통신 네트워크를 통해 송신될 것이고, 노드에 포워딩하기 위한 컨텐츠는 통신 네트워크를 통해 수신될 것이다. 서비스 모듈은 로컬화될 수 있고, 이 경우에 컨텐츠는 양호하게는 제어 명령들의 목적지와 동일한 로케이션으로부터 수신될 것이다. 그러나, 서비스 모듈은 분산될 수 있고, 이 경우에 컨텐츠의 출발점 및 제어 명령들의 목적지는 상이한 로케이션에 있을 수 있다.

서비스 모듈이 원격으로 로케이팅되는 경우에, 장치는 양호하게는 노드로의 순방향 전송을 위해, 서비스 모듈로부터 통신 네트워크를 통해 컨텐츠를 수신하기 위한 인터페이스 스테이지를 가질 것이다.

양호한 실시예에서, 노드를 향해 컨텐츠를 송신하기 이전에, 서비스 모듈은 노드가 제1 컨텐츠, 즉 서비스 모듈이 송신하려고 하는 컨텐츠와 연관된 서비스와 동일한 서비스를 운영하고 있는지의 여부의 표시를 얻기 위해 요구를 장치에 송신하도록 구성된다. 요구는 양호하게는 제1 컨텐츠와 연관된 서비스의 표시를 포함할 것이다.

이러한 요구에 응답하여, 장치는 양호하게는 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되는지 여부를 결정하도록 구성된다. 처리 스테이지는 제어 명령에 의해 서비스 모듈로부터의 요구에 응답하도록 구성된다. 양호한 실시예에서, 제어 명령은 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되는지에 대한 긍정 및 부정 표시 중 어느 하나이다. 긍정 표시가 수신되는 경우에, 서비스 모듈은 노드에 포워딩하기 위해 장치에 컨텐츠를 송신할 수 있게 된다. 그렇지 않으면, 서비스 모듈은 노드로의 순방향 전송을 위해 장치에 컨텐츠를 송신하는 것을 금지한다.

긍정 및 부정 표시 중 어느 하나를 송신함으로써, 노드에서 현재 운영되고 있거나 최종 운영된 서비스의 아이덴티티를 장치가 드러낼 필요성이 감소된다. 그럼으로써, 노드의 사용자의 프라이버시가 증가된다. 그러나, 장치는 그 노드에서 운영되고 있는 서비스의 아이덴티티를 서비스 모듈에게 송신할 수 있고, 서비스 모듈은 결국 제1 컨텐츠 및 제2 컨텐츠가 동일한 서비스와 연관되는지 여부를 결정할 수 있다.

노드는 양호하게는 서비스와 연관된 컨텐츠를 얻기 위해 장치에 서비스 요구들을 송신하도록 구성되고, 그 서비스 요구들은 요구되는 서비스의 표시를 포함한다. 통신 스테이지는 양호하게는 서비스 요구들을 수신하도록 구성된다. 처리 스테이지는 양호하게는 노드로부터의 적어도 최종 수신된 서비스 요구와 연관된 서비스의 표시를 저장하도록 구성된다.

양호하게는, 노드로부터 송신된 서비스 요구들 또는 일부 부류의 서비스 요구들은 장치를 통과해야 한다. 또한 더 양호하게는, 서비스 모듈로부터의 서비스가 장치를 통해 액세스가능하다면, 그 서비스에 대한 서비스 요구들이 그 장치를 통과해야만 하도록 노드가 구성될 것이다. 그리고나서, 최종 서비스의 저장된 표시가 주어진 컨텐츠의 서비스와 매칭하지 않는다면, 처리 스테이지는 그 노드에서의 현재 컨텐츠가 주어진 컨텐츠와 동일한 서비스의 일부일 수 없다고 유추할 수 있다.

그러나, 장치는, 대안적으로는 또는 거기에 덧붙여, 최종 운영되거나 운영되고 있는 서비스의 표시, 즉 제2 컨텐츠와 연관된 서비스의 표시로 응답하도록 노드를 초청하는 요구를 노드에게 송신함으로써 노드에서 운영되고 있는 서비스의 표시를 얻을 수 있다. 그리고나서, 처리 스테이지는 노드로부터의 응답을 이용하여, 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되어 있는지의 여부를 결정할 수 있다. 그러한 접근법은, 노드에서 발원하는 하나 이상의 로컬 서비스들, 또는 장치로의 요구없이 액세스될 수 있는 서비스들을 노드가 액세스할 수 있는 경우에, 특히 유용할 것이다.

양호한 실시예에서, 노드에 액세스가능한 상이한 서비스에 대해 각각, 복수의 서비스 모듈들이 제공될 것이다. 하나 이사의 서비스 모듈들은 장치의 일부일 수 있고, 하나 이상의 서비스 모듈들은 장치로부터 이격될 수 있고, 노드 또는 통신 네트워크의 상이한 포인트 중 어느 하나에 로케이팅될 수 있다.

양호하게는, 노드는 직접적으로, 또는 네트워크로서 구성될 수 있는 하나 이상의 라우터들 및 링크들을 통해, 무선 링크를 통해 장치와 통신하도록 구성되는 것과 같은 모바일 노드일 것이다. 그리고나서, 컨텐츠는 적어도 부분적으로는 무선 링크를 통해 노드에게 편리하게 송신될 수 있다. 더 양호하게는, 노드는 전화 핸드셋과 같은 핸드셋일 것이다. 그러한 디바이스는 빈번하게는 제한된 메모리를 가지고 있으므로, 이는 현재 운영되고 있는 서비스와 연관되지 않는 컨텐츠의 수신이 그 서비스를 오염시킬 것이라는 가능성을 더 크게 한다.

양호하게는, 핸드셋은 디스플레이를 가질 것이고, 컨텐츠는 그 디스플레이 상에서 렌더링될 수 있는 이미지 데이터일 것이다. 양호한 실시예에서, 컨텐츠는 디스플레이 상에서의 표시를 위한 페이지와 관련될 것이고, 더 양호하게는 디스플레이의 단일 페이지 내에 또는 디스플레이의 단일 페이지로서 렌더링될 수 있도록 구성될 것이다.

장치는 한편으로는 하나 이상의 가내(domestic) 디바이스들로의 라우터 기능, 및 다른 한편으로는 원격통신 네트워크로의 접속성을 가지는 홈 게이트웨이일 수 있다. 그러나, 양호한 실시예에서, 장치는 DECT 기지국과 같은 전화 기지국일 것이다.

본 발명의 또 하나의 양태에 따르면, 제1 컨텐츠는, 수신되는 경우에, 그 노드에서 현재 렌더링되는 제2 컨텐츠 - 존재하는 경우에 - 대신에 노드가 제1 컨텐츠를 렌더링하도록 유발하는, 노드 외부에서 발원되는 명령들에 응답하여 제1 컨텐츠를 노드에 제공하는 방법이 제공되고, 제1 컨텐츠는 주어진 서비스와 연관되며, 그 방법은: (i) 제2 컨텐츠가 제1 컨텐츠의 주어진 서비스와 연관되어 있는지의 여부를 결정하는 단계, 및 (ii) 제2 컨텐츠가 제1 컨텐츠의 주어진 서비스와 연관되어 있는지의 여부에 따라 노드를 향해 제1 컨텐츠를 송신하는 단계를 포함한다.

이제, 본 발명은 이하의 도면들을 참조하여 단지 예로서 더 설명될 것이다.
도 1은 게이트웨이 및 핸드셋이 제공되는, 본 발명에 따른 시스템의 기능적 표현이다.
도 2는 게이트웨이의 하드웨어 아키텍쳐를 도시하고 있다.
도 3은 핸드셋의 하드웨어 아키텍쳐를 도시하고 있다.
도 4는 메시지들의 제1 시퀀스를 도시하고 있다.
도 5는 메시지들의 제2 시퀀스를 도시하고 있다.
도 6은 메시지들의 제3 시퀀스를 도시하고 있다.
도 7은 메시지들의 제4 시퀀스를 도시하고 있다.
도 8 내지 15는 서비스, 서비스 매니저 및 핸드셋 브라우저에서 취해지는 단계들을 나타내는 플로우 차트의 다양한 스테이지들을 도시하고 있다.
도 16a는 도 3과 상이한 레벨에서의 핸드셋 아키텍쳐의 추가 뷰이다.
도 16b는 게이트웨이 아키텍쳐의 추가 뷰이다.
도 17 내지 19는 메시지들의 추가 시퀀스들을 도시하고 있다.

도 1에서는, 모바일 터미널, 여기에서는 핸드셋(12)이 인터페이스 모듈(32)(이하에서는 게이트웨이로 지칭됨)과 무선 네트워크 링크(16)를 통해 통신할 수 있는 시스템(10)이 도시된다.

개략적으로, 핸드셋은 게이트웨이(14)로부터 특정 서비스와 관련된 업데이트 페이지와 같은 푸시 정보를 수신하도록 구성된다. 정보를 푸시 방식으로 수신함으로써, 정보가 가용한 지 여부를 발견하기 위해 핸드셋이 게이트웨이를 폴링해야 할 필요성이 감소되고, 그럼으로써 대역폭 및 핸드셋 전력을 절약한다. 그러나, 정보를 푸싱하는 것은 핸드셋 디바이스에 의해 현재 렌더링되고 있는 정보와 충돌하는 경우에 불편할 수 있다.

따라서, 푸시 정보를 송신하기 이전에, 게이트웨이는 푸시 정보가 핸드셋 상에서 현재 운영되고 있는 서비스와 연관되는지 또는 그러한 서비스와 충돌할 것인지 여부를 결정하기 위해, 요구 메시지를 핸드셋에 송신하도록 구성된다. 핸드셋은 핸드셋에서 현재 운영되고 있는 서비스의 표시로 게이트웨이에 응답하도록 구성된다. 게이트웨이는 운영되고 있는 서비스가 푸싱될 정보에 대응하는 서비스에 매칭하는지 또는 그와 충돌하는지를 결정하도록 구성된다. 서비스들의 충돌이 있다면, 게이트웨이는 푸시 정보를 송신하는 것을 금지하도록 구성된다. 이렇게 하여, 푸시 정보가 핸드셋에서 운영되고 있는 또 하나의 서비스를 혼란시킬 가능성이 감소된다.

핸드셋 전력 및 무선 대역폭을 절약하기 위해, 게이트웨이는 제공되는 적어도 최종 서비스의 아이덴티티를 계속 유지하도록 구성된다. 이러한 아이덴티티가 송신될 푸시 정보와 연관된 서비스의 아이덴티티에 매칭하지 않는다면, 핸드셋의 현재 서비스가 푸시 정보의 것과 충돌하는 것으로 추론되고, 게이트웨이는 푸시 정보를 핸드셋에 송신하는 것을 금지한다. 핸드셋에서의 현재 서비스가 푸시 정보와 충돌한다고 추론함으로써, 현재 운영되고 있는 서비스를 결정하기 위해 요구 메시지를 핸드셋에 송신할 필요성이 감소된다.

더 상세하게는, 게이트웨이(14)는 인터넷(18)으로 지칭되는 네트워크와 예를 들면 DSL 또는 디지털 가입자 라인 기술을 이용하는 꼬임 2선식 접속(twisted pair connection)과 같은 접속(20)을 통해 통신하도록 구성된다. 게이트웨이(14)는 핸드셋에 로케이팅된 브라우저(24)에 대한 인터페이스로서 작동하는 서비스 매니저(22)를 가지고 있다. 브라우저 및 서비스 매니저(22) 양쪽 모두는 WML 타입이고, 즉 무선 마크업 언어 또는 WML(WML은 협대역 디바이스들에서 타겟팅된 컨텐츠 및 사용자 인터페이스들을 생성하기 위한 주지된 다큐먼트 디스크립션 언어임)을 이용하여 통신하도록 구성된다.

브라우저(24)는 서비스 매니저(22)에 무선 링크(16)를 통해 송신될 정보에 대한 요구들을 생성한다. 이에 응답하여, 서비스 매니저는 요구된 정보를 요구된 포맷으로 리턴한다. 그리고나서, 브라우저(24)는 핸드셋(12)의 디스플레이(26) 상에 정보를 브라우저에 의해 이용되는 포맷으로 표시한다. 키패드(28)와 같은 사용자 입력 디바이스는 사용자 명령들을 입력하기 위해 제공된다. 브라우저(24) 및 키패드(28)는, 키패드 명령들이 예를 들면 정보에 대한 요구들을 서비스 매니저에게 송신하도록 브라우저에게 명령할 수 있도록 동작가능하게 접속된다. 이렇게 하여, 사용자는 키패드를 이용하여 정보를 얻기 위해 풀 명령을 유발시킬 수 있다.

분리되어 있는 것으로 도시되어 있지만, 키패드(28) 및 디스플레이(26)는 터치-민감성 디스플레이로서 통합하여 형성될 수 있다. 대안적으로는 또는 이에 덧붙여, 포인터 디바이스는 정보에 대한 요구를 유발시키기 위해 디스플레이 상에서 복수의 명령들 중 하나를 선택하도록 제공될 수 있다.

핸드셋(12)은 복수의 서비스들(서비스 1, 2 및 3)의 적어도 하나로부터 정보를 렌더링하도록 구성된다. 여기에 이용된 바와 같이, 용어 "서비스"는 컨텐츠 데이터 및 그 컨텐츠 데이터를 제공하기 위한 컴퓨터-실행가능 명령들의 시퀀스를 지칭하고, 주어진 서비스의 명령들 및 데이터는 로컬화되거나 분산된 형태로 컴퓨터-판독가능 매체 상에 저장되며, 명령들은 하나 이상의 프로세서들 상에서 실행된다. 이들 서비스들의 각각은 연혁적인 서비스 정보를 포함하는 컨텍스트 데이터베이스(30)로의 액세스를 가지고 있다.

이들 서비스들 중 하나(서비스 2)는 로컬 서비스이다. 이러한 서비스는 핸드셋에 로케이팅되어 있고 메시지 라우터(25)를 통해 브라우저(24)와 동작 통신 상태인 것으로 보여질 수 있는데 반해, 서비스-1 및 서비스-3은 원격 서비스들이다. 메시지 라우터(25)는 메시지가 서비스-1 또는 서비스-3과 같은 비-로컬 서비스와 관련되는 경우에 브라우저로부터 외부 링크(16)에 메시지들을 라우팅하도록 제공된다. 메시지가 서비스-2와 같은 로컬 서비스(즉, 핸드셋으로부터 제공된 서비스)와 관련되는 경우에, 메시지 라우터(25)는 메시지를 내부적으로 라우팅한다.

서비스-1 및 서비스-3이 게이트웨이 내에 로케이팅되어 있는 것으로 도시되어 있지만, 제4 서비스와 같은 하나 이상의 서비스들이 네트워크 내의 상이한 포인트에 로케이팅될 수 있고, 이러한 또는 이들 서비스들로부터의 정보는 인터넷(18)을 통해 제공된다. 외부 서비스들 인터페이스(32)는 그러한 외부 서비스들을 관리하기 위해 게이트웨이에서 제공된다.

서비스는 푸시 모델 및 풀 모델 중 하나 또는 양쪽에서 동작할 수 있다. 풀 모델에서, 정보는 핸드셋 사용자에 의해 유발된 요구들에 응답하여 핸드셋에 제공된다. 이것은 요구별로(request by request basis) 수행된다.

그러므로, 요구는 정상적으로는 주어진 다큐먼트, 이미지 또는 요구 시에 존재하는 정보의 다른 공간적으로 또는 시간적으로 그룹화된 아이템들에 관련된다. 일단 사용자에 의해 요구된 정보가 송신되었다면, 서비스는 추가 정보를 전송하기 이전에 프레시 요구를 기다릴 것이다. 풀 모델에서, 사용자는 사용자-요구에서 식별된 특정 정보를 지연없이 기대하고 있는 것으로 예상된다. 풀 요구의 하나의 예는 검색 엔진 페이지 상에 입력된 검색 스트링이다. 그리고나서, 검색 엔진은 매칭하는 요소들의 리스트로 응답한다.

푸시 모델에서, 서비스는 각 송신에 대한 사용자 요구를 기다리기 보다는 핸드셋으로의 정보의 전송을 스스로 유발한다. 푸시 모델에서의 송신들은 스케줄링되거나, 특별히 중요한 뉴스 아이템들 또는 임계값에 도달한 주식 가격들과 같은 외부 이벤트들에 의해 트리거링될 수 있다.

상기 모델들 중 어느 하나에서 동작하는 서비스에 대해, 핸드셋 브라우저(24)는 그 서비스로부터 정보를 수신하고 이를 디스플레이(26) 상에 표시하도록 구성되어, 수신 시에 표시되는 정보를 무시한다. 서비스로부터의 수신된 정보가 표시 페이지를 나타내는 경우에, 정보는 이에 응답하여 핸드셋 브라우저가 디스플레이를 리프레시하고 이전 페이지 대신에 수신된 페이지를 표시하는 제어 명령들을 포함한다. 제어 명령들은 명시적일 필요는 없다. 여기에서, 제어 명령들은 인커밍 컨텐츠가 도달하고 명시적이지 않은 포맷의 일부로서 제공되는데: 핸드셋은 포맷을 인식하고 그 컨텐츠가 도달할 때 인식된 포맷으로 도달하는 컨텐츠를 렌더링하도록 구성된다.

도 2는 게이트웨이(14)의 하드웨어 아키텍쳐를 도시하고 있다. 인터넷(18)에 송신되고 그로부터 수신되는 정보를 각각 변조 및 복조하기 위한 비대칭 디지털 가입자 라인(ADSL) 인터페이스(40), 및 무선 링크(16)를 통해 핸드셋(12)과 무선 신호들을 통신하도록 구성된 안테나(44)를 구비하는 무선 모듈(42)이 제공된다. ADSL 인터페이스(40) 및 무선 모듈(42)은 그로부터의 데이터를 처리하거나 거기에 처리된 데이터를 출력하도록 구성된 프로세서 모듈(46)에 접속된다. 프로세서는 ROM 메모리 및 플래시 메모리를 포함하는 메모리 모듈(48)로의 액세스를 가지고 있다. 컨텍스트 데이터베이스(30)가 저장되는 RAM 메모리가 또한 제공된다. 다양한 게이트웨이 컴포넌트들에 대한 전력은 전기적 메인들(도시되지 않음)에 접속된 전원(50)에 의해 제공된다.

서비스들 1 및 3은 플래시 메모리에 저장된 소프트웨어 실체들이고, 그 실행가능한 명령들은 주어진 서비스가 운영되고 있는 때에 프로세서(46)에 의해 수행되며, 그 서비스에 대응하는 데이터베이스(48)로부터의 컨텐츠는 무선 모듈(42)에 의한 핸드셋으로의 송신을 위해 프로세서에 의해 검색될 수 있다. 컨텐츠는 서비스의 특성에 따라 메모리 모듈(48)로부터, 또는 인터넷(18) 내의 로케이션으로부터 검색된다. 유사하게, 서비스 매니저(22) 및 외부 서비스 인터페이스는 플래시에 저장되어 이용 시에 프로세서(46)에 의해 실행되는 소프트웨어 실체들이다.

서비스 매니저(22)는 핸드셋에 대해 검출된 최종 서비스의 아이덴티티를 기록하도록 구성되고, 아이덴티티들은 프로세서(46)에 의해 컨텍스트 데이터베이스(30)에 저장된다. 핸드셋으로부터의 비-로컬 서비스 요구들은 서비스 매니저를 통해 채널링되므로, 비-로컬 서비스는 서비스 요구들에 기초하여 서비스 매니저(22)에서 편리하게 검출될 수 있다. 정보는 서비스를 나타내는 식별자를 포함할 것이므로, 비-로컬 서비스는 또한 주어진 서비스로부터 핸드셋에 송신된 정보에 기초하여 검출될 수 있다.

대안적으로는 또는 그에 덧붙여, 서비스 매니저는 일반 컨텍스트 요구를 브라우저에 송신함으로써 서비스를 검출할 수 있다. 이것은 그에 응답하여 브라우저(22)가 최종 브라우징되었거나 현재 브라우징되고 있는 서비스의 아이덴티티를 나타내는 컨텍스트 메시지를 서비스 매니저에게 리턴하도록 구성되는 요구를 나타낸다. 명백하게는, 브라우저는 서비스 매니저를 통해 그러한 서비스에 액세스하지 않을 것이므로, 일반적인 컨텍스트 요구는 로컬 서비스를 검출하는데 적합하다.

도 3을 참조하면, 핸드셋(12)은 메모리 모듈(54), 및 안테나(57)를 구비하는 무선 모듈(56)에 접속되는 프로세서(52)를 가지고 있고, 이들 컴포넌트들 각각은 그들 정상 기능을 수행하도록 구성된다. 메모리 모듈은 ROM 메모리, RAM 메모리 및 플래시 메모리를 포함한다. 디스플레이(26) 및 키패드(28)는 오디오 출력 및 입력 디바이스들, 여기에서는 각각 이어피스(59) 및 마이크로폰(58)과 같이, 프로세서에 접속된다. 핸드셋 컴포넌트들은 필요한 경우에, 통상적으로는 10시간의 이용 이후에 재충전될 수 있는 배터리 전원(60)에 의해 전력공급된다. 브라우저(24) 및 메시지 라우터(25)의 각각은 메모리 모듈(54)에 저장되어 이용 시에 프로세서(52)에 의해 실행되는 소프트웨어 실체들이다. 시스템(10)이 복수의 핸드셋을 포함하는 경우에, 각각은 그 플래시 메모리에 저장된 각각의 ID를 가질 것이다.

도 4에서, 서비스 S1, 서비스 매니저(22), 및 핸드셋 브라우저(24) 사이에서 송신되는 메시지들의 시퀀스가 도시되어 있다. 각 메시지는 수평 화살표에 의해 표현되고, 화살표의 출발점과 끝은 각각 대응하는 메시지의 출발점 및 목적지를 나타낸다. 증가하는 시간은 아래로 지향하는 화살표들에 의해 표시되고, 점선들은 메시지들 사이의 연장된 시간 간격들을 나타낸다. 인커밍 메시지 및 아웃고잉 메시지를 결합하는 구부러진 화살표는 아웃고잉 메시지가 인커밍 메시지에 응답하여 전송된다는 것을 나타낸다.

메시지들은 시간상 2가지 페이즈들로 그룹화된다. 도 4의 제1 페이즈 I에서, 브라우저는 서비스 S1을 브라우징한다. 처음에, 핸드셋 브라우저는 서비스를 요구하는 요구(S1 요구)를 서비스 매니저에게 송신한다. 그리고나서, 서비스 매니저(22)는 요구를 적절한 서비스, 여기에서는 서비스 S1에게 포워딩한다. 이러한 요구에 응답하여, 서비스 S1은 도 4에 도시된 바와 같이 S1 답변의 형태로 요구된 정보를 송신한다. 그리고나서, 서비스 매니저는 S1 답변을 핸드셋 브라우저(24)에게 릴레이한다. 핸드셋 브라우저는, S1 답변 메시지를 수신한 것에 응답하여, 답변 메시지의 정보를 이용하여 수신된 정보를 나타내는 페이지를 디스플레이(26) 상에 표시한다. 이렇게 하여, 핸드셋 브라우저(24)는 S1 서비스를 브라우징한다.

서비스 매니저(22)는 핸드셋 브라우저(24)로부터의 S1 요구를 컨텍스트 데이터베이스에 저장하도록 구성된다.

제1 페이즈의 종료 후 얼마 간에 발생하는 제2 페이즈 II에서, 푸시 모델에 따라 동작하는 서비스 S1은 정보 페이지 P1을 송신하기를 "원한다". 즉, 서비스 S1은 핸드셋 외부의 이벤트에 의해 트리거링되어, 정보 페이지 P1의 푸시 송신을 개시한다.

페이지 P1이 핸드셋에서 현재 브라우징되고 있는 서비스와 충돌하는지 여부를 결정하기 위해, 서비스 S1은 우선, "컨텍스트가 S1인지 묻는" 메시지로서 도 4에서 도시된, 특정 컨텍스트 요구를 서비스 매니저(22)에게 송신하도록 구성된다. 이러한 특정 컨텍스트 요구는 현재 브라우징된 서비스가 서비스 S1인지 여부의 이진(즉, 긍정 또는 부정) 표시에 대한 요구를 나타낸다. 그러한 표시는 핸드셋 사용자의 브라우징 습관에 대해 제공되는 정보의 양을 제한하고, 서비스가 게이트웨이 외부에 있는 경우에 특히 유용하다.

특정 컨텍스트 요구에 응답하여, 서비스 매니저(22)는 컨텍스트 데이터베이스(30)를 심문하여 핸드셋 브라우저에 의해 최종 요구된 서비스가 S1이었는지를 결정하도록 구성된다. 최종 서비스가 S1이 아니었다면, 서비스 매니저는 "S1을 브라우징하지 않는다"는 메시지를 리턴한다. 이러한 부정적 이진 메시지는 서비스 S1이 프레시 페이지를 푸싱하는 것을 방지한다.

한편, 컨텍스트 데이터베이스(30)에 저장된 최종 서비스가 S1이었다면, 서비스 S1이 여전히 핸드셋 상에서 운영되고 있을 가능성이 있다(즉, 이러한 서비스에 관련된 페이지가 핸드셋에 의해 현재 표시될 가능성). 이것이 사실인지 여부를 결정하기 위해, 서비스 매니저는 그것이 핸드셋에 송신하는 일반 컨텍스트 요구를 생성한다. 일반 컨텍스트 요구는 도 4에서 "컨텍스트를 요청하는" 메시지로서 도시되어 있다. "컨텍스트를 요청하는" 메시지는 그에 응답하여 핸드셋이 현재 운영되고 있는 서비스를 나타내는 메시지로 응답하는 명령을 포함하는 필드를 가지고 있다.

본 예에서, 브라우저가 여전히 서비스 S1을 브라우징하고 있으므로(즉, 서비스 S1로부터의 페이지가 여전히 표시됨), 핸드셋 브라우저는 컨텍스트 메시지, 여기에서는 "S1을 브라우징한다"는 메시지를 서비스 매니저(22)에게 리턴하고, 서비스 S1이 현재 브라우징되고 있다는 것을 나타낸다. 그리고나서, "S1을 브라우징한다"는 메시지는 서비스 매니저에 의해 서비스 S1에 송신되는 긍정 이진 응답으로 번역된다.

브라우징되고 있는 서비스가 정보를 푸시하기 원하는 서비스에 대응하므로, 긍정 응답은 서비스 S1이 정보 페이지 P1을 서비스 매니저에게 송신할 수 있게 한다. 그리고나서, 서비스 매니저는 이러한 페이지를 핸드셋 브라우저(22)에 포워딩하여, 페이지를 디스플레이(26)에 표시한다.

상기 실시예에서, 서비스 매니저는 "컨텍스트가 S1인지 묻는" 것에 이진 응답으로 응답하여 핸드셋 사용자의 프라이버시를 보호한다. 그러나, 대안적인 실시예에서, 서비스 매니저는 브라우징되고 있는 서비스를 나타내는 식별자로 응답하고, 서비스 S1은 (i) 현재-브라우징된 서비스(여기에서는 S1)의 수신된 아이덴티티와 그 자신의 아이덴티티를 비교하고, (ii) 2개의 아이덴티티들이 매칭하는 경우에 페이지 P1을 송신하도록 구성된다.

도 4의 예는 특정 컨텍스트 요구를 송신함으로써, 서비스 S1이 서비스 매니저에게 핸드셋이 현재 이러한 서비스를 브라우징하고 있는지를 효율적으로 묻는 상황으로 보여질 수 있다. 응답을 제공하기 위해, 서비스 매니저는 일반 컨텍스트 요구를 핸드셋에게 송신하고, 핸드셋은 현재 브라우징되고 있는 서비스의 ID로 답변한다. 긍정 또는 부정 답변은 서비스 S1에 릴레이되어, 그것이 각각 페이지 P1을 전송하는 것을 가능하게 하거나 불가능하게 한다.

도 5는 서비스 S1이 프레시 페이지를 송신하는 것을 금지해야 하는 상황에서 메시지들의 시퀀스를 도시하고 있다. 여기에서, 도 2의 것들에 대응하는 라벨들은 유사한 의미를 가지고 있다.

도 4에서와 같이, 도 5의 시퀀스는 핸드셋이 S1을 브라우징하고 있는 제1 페이즈 I를 가지고 있다. 그러나, 서비스 S1을 브라우징한 이후에, 브라우저는 서비스 S1과 상이한 로컬 서비스 S2를 브라우징하기 시작한다. 이러한 브라우징은 도 5에서 브라우저로부터의 "S2 요구"에 이은 서비스 S2로부터의 "S2 답변"으로 표현된다.

제2 페이즈 II에서, 프레시 페이지 P1을 푸시하기 원하는 서비스 S1은 특정 컨텍스트 요구 "컨텍스트가 S1인지를 묻는" 것을 서비스 매니저에게 송신한다. 도 4에서와 같이, 서비스 매니저는 일반 컨텍스트 요구로 핸드셋에서 현재 브라우징되고 있는 서비스의 아이덴티티의 표시를 찾는다. 그러나, 핸드셋에서 브라우징되는 최종 서비스는 이제 서비스 S2이므로, 브라우저는 "S2를 브라우징한다"는 메시지를 리턴한다. 결국, 서비스 매니저는 "S1을 브라우징하지 않는다"는 메시지를 생성한다. "S1을 브라우징하지 않는다"는 메시지는 서비스 S1로부터의 컨텍스트 요구에 대한 부정 응답을 나타낸다. 결과적으로, 서비스 S1은 페이지 P1을 송신할 수 없게 된다.

그리고나서, 서비스 S1은 새로운 특정 컨텍스트 요구를 개시하고, 서비스 매니저는 "S1을 브라우징하지 않는다"는 메시지의 형태로 부정 응답을 다시 제공한다. 서비스 S1은 긍정 응답이 서비스 매니저로부터 얻어질 때까지 시간 간격들에서 컨텍스트 요구의 송신을 반복하도록 구성되고, 그 포인트에서 서비스 S1은 프레시 페이지 P1을 송신가능하게 된다.

도 6은 메시지의 또 다른 하나의 가능한 시퀀스를 예시하고 있다. 여기에서, 페이즈 I에서, 브라우저는 도 5에서와 같이 서비스 S1을 브라우징한다. 그러나, 그리고나서, 브라우저는 또 하나의 비-로컬 서비스, 여기에서는 서비스 S3에 대한 요구를 서비스 매니저에게 송신한다. 수신된 요구에 기초하여, 서비스 매니저는 서비스 S3을 검출하고, S3을 최종 검출된 서비스로서 컨텍스트 데이터베이스(30)에 저장한다. 후속적으로, 서비스 S1이 "컨텍스트가 S1인지를 묻는" 특정 컨텍스트 요구를 서비스 매니저에게 송신한다면, 서비스 매니저(22)는 컨텍스트 데이터베이스(30)를 심문한다. 최종 검출된 서비스가 S1이 아니므로, 서비스 매니저는 "S1을 브라우징하지 않는다"는 메시지로 응답하고, 서비스 S1은 프레시 페이지 P1을 푸시하는 것이 가능하지 않다. 명백하게는, 서비스 매니저는, S1 요구 또는 서비스 S1에 의해 푸시된 정보가 통과되어 결과적으로 서비스 매니저에 의해 검출되었으므로, 브라우저가 S1을 브라우징하지 않고 있다고 추론할 수 있다.

도 7에서, 서비스 S1은 특정 컨텍스트 요구보다 일반 컨텍스트 요구를 서비스 매니저에게 송신한다. 그리고나서, 서비스 매니저는 프레시 일반 컨텍스트 요구를 생성하고, 이는 "S2를 브라우징한다"는 메시지의 형태로 브라우저에 의해 답변된다. 그리고나서, 서비스 매니저는 긍정 또는 부정 응답을 제공하기 보다는, 현재-브라우징된 서비스의 아이덴티티를 서비스 S1에 포워딩한다. 도 7에 예시된 상황이 가능하더라도, 서비스 S1이 특정 컨텍스트 요구를 송신하고 긍정 또는 부정 응답을 수신하는 도 4-6의 실시예들이 바람하고, 이는 이들 실시예들에서 핸드셋 사용자의 프라이버시가 더 잘 보호되기 때문이다.

도 4의 상황은 다음의 예에 의해 예시될 수 있는데: 사용자는 핸드셋 호출 로그에 액세스하기 원하고, 이는 서비스 S1에 대응하는 "호출 로그 서비스"라는 제목의 서비스에 의해 게이트웨이에서 관리된다. 사용자는 호출 로그 서비스에서 게이트웨이에 요구(도 4에서의 "S1 요구")에 요구를 전송한다. 호출 로그 서비스가 호출 로그 다큐먼트를 구축하는데 일부 시간을 요구하므로, 호출 로그 서비스는, 사용자에게 그의 요구가 수신되었고 처리되고 있다는 것을 나타내는 "기다려 달라"는 다큐먼트("S1 답변"에 대응함)를 핸드셋에게 전송한다. 호출 로그 다큐먼트가 준비된 경우에, 호출 로그 서비스는 서비스 매니저에게, "컨텍스트가 S1인지 묻는" 메시지의 형태로, 호출 로그 서비스가 여전히 핸드셋 상에서 브라우징되고 있는지를 묻는다. 그리고나서, 서비스 매니저는 핸드셋과의 무선 접속을 열고, 현재 브라우징되고 있는 서비스의 아이덴티티를 얻기 위해 "컨텍스트를 요청한다"는 메시지를 송신한다. 서비스는 변경되지 않으므로, 핸드셋 브라우저는 서비스 매니저에게, 여전히 호출 로그 서비스를 브라우징하고 있다, 즉 호출 로그에 대응하는 표시 페이지가 여전히 표시되고 있다는 것을 나타내는 표시를 리턴한다. 그리고나서, 서비스 매니저는 호출 로그 서비스에 긍정 응답을 송신하여, 호출 로그 서비스가 여전히 브라우징되고 있다는 것을 나타낸다. 그리고나서, 호출 로그 서비스는 최종 다큐먼트를 전송한다.

그러나, 호출 로그 서비스가 호출 로그를 구축하는 것을 기다리고 있는 동안에, 사용자는 불안하게 되고 또 하나의 게이트웨이 서비스, 예를 들면 "옐로우 페이지들" 서비스에 액세스하려고 결심한다. 서비스 매니저가 옐로우 페이지 서비스에 대한 요구를 수신하는 경우에, 그 컨텍스트 데이터베이스를 업데이트한다.

이 경우에, 도 6에 도시된 상황에 대응하여, 호출 로그 서비스가 서비스 매니저에게 컨텍스트가 S1인지를 묻는 경우에, 서비스 매니저는 컨텍스트 데이터베이스를 심문하고 핸드셋과 프레시 무선 링크를 셋업할 필요없이 부정 응답을 리턴할 수 있다. 그리고나서, 호출 로그 서비스는 옐로우 페이지 서비스를 오염시키고 사용자를 혼동시켰을 호출 로그 페이지를 송신하는 것을 금지할 것이다.

이렇게 하여, 핸드셋 상에서의 서비스 충돌들의 위험이 감소되고, 그러면서도 고가의 무선 링크를 열어야 할 필요성이 또한 감소될 수 있다. 열려지는 경우에, 무선 링크는 정상적으로는 무선 디바이스들 사이에서 교환되는 동기화 패킷들을 나르고 결과적으로 비-접속 상태보다 더 많은 전력 소비를 야기한다. 더욱이, 무선 접속 대역폭은 종종 다른 디바이스들과 공유된다. 열려진 접속은 다른 디바이스들 사이의 접속을 방지할 위험을 내재한다. 그러면, 임의의 회피가능한 링크를 회피하는 것이 매우 유리하다.

도 8 내지 15는 서비스, 서비스 매니저 및 핸드셋 브라우저에서 취해지는 단계들을 나타내는 플로우차트의 다양한 스테이지들을 도시하고 있다.

핸드셋에서 수행된 단계들을 도시하는 도 8에서, 브라우저는 서비스 S1을 요구한다. 이러한 요구는 예를 들면 사용자 입력의 결과일 수 있다. 그리고나서, 메시지 라우터(25)는 서비스 S1이 로컬인지 결정하고, 그렇다면 서비스 요구를 로컬 서비스에게 전송한다. 그렇지 않으면, 서비스 요구는 무선 링크(16)를 통해 게이트웨이에 송신된다. 도 9는 서비스 요구를 수신하는, 서비스 매니저에서의 단계들을 도시하고 있다. 요구를 수신할 때, 서비스 매니저는 서비스의 식별자 S1을 컨텍스트 정보로서 컨텍스트 데이터베이스에 last_service=S1의 형태로 저장한다. 실제로, 서비스 매니저는 메모리에, 게이트웨이를 통해 액세스된 최종 서비스가 S1이라는 사실을 저장한다. 그리고나서, 서비스 매니저는 요구를 서비스 S1을 향해 송신한다.

도 10에서, 서비스 S1은 서비스 매니저로부터 포워딩된 요구를 수신하고 그 요구를 처리한다. 서비스는 상이한 방식들로, 예를 들면 요구에 대한 응답으로서, 또는 이미 전송된 다큐먼트의 업데이트로서 다큐먼트들을 전송할 수 있다. 환언하면, 서비스는 풀 및 푸시 모드들 양쪽 모두에서 작동할 수 있다. 그러나, 도 11에 표시된 바와 같이, 서비스 S1이 다큐먼트를 송신하기에 앞서서, 서비스 S1로부터의 정보가 요구의 소스에 의해 현재 브라우징되고 있는지를 묻는다. 이것은 특정 컨텍스트 요구를 서비스 매니저에게 송신함으로써 수행된다.

도 12는 서비스, 여기에서는 서비스 S1로부터의 특정 컨텍스트 요구에 응답하여 서비스 매니저에 의해 수행되는 단계들을 도시하고 있다. 서비스 S1로부터 특정 컨텍스트 요구의 수신 시에, 서비스 매니저는 컨텍스트 데이터베이스로부터, last_service의 값이 S1과 동일한 지를 결정한다.

last_service의 값이 S1과 동일하지 않다면, 부정 응답이 서비스 S1에 리턴된다. 즉, S1이 핸드셋에 의해 브라우징되지 않고 있다는 표시("S1을 브라우징하지 않는다"는 메시지)가 서비스 S1에 전송된다. 도 13에 도시된 바와 같이, 서비스 매니저로부터의 메시지가 서비스 S1에서 수신되는 경우에, 서비스 S1은 S1이 현재 핸드셋에서 브라우징되고 있는지를 메시지가 나타내는지를 결정한다. S1이 브라우징되고 있지 않다면, "서비스 중지" 명령이 발행되고, 서비스가 종료한다. 그렇지 않다면, 프레시 페이지 P1과 같은 다큐먼트가 전송된다.

도 12로 돌아가면, last_service=S1이 참이라면, "컨텍스트를 요청한다"는 메시지 형태의 일반 컨텍스트 요구는 서비스 매니저에 의해 핸드셋 브라우저에게 송신된다. "컨텍스트를 요청한다"는 메시지는, 이것이 무선 링크를 개방하는 비용에 크게 영향을 미치지 않으므로, 요구되는 서비스를 지정하지 않는다(접속은 각 경우에서 개방될 필요가 있고, 서비스 매니저는 핸드셋 브라우저로부터 오고 가는 모든 메시지에 의해 교차되므로 여기에서 비밀성 이슈가 전혀 없다. 더구나, "컨텍스트를 요청한다"는 메시지와 "서비스가 운영되고 있는지 묻는" 메시지 사이의 페이로드 비용에 있어서의 차이는 단지 수 바이트 길이에 불과하다.).

이러한 "컨텍스트를 요청한다"는 메시지는 도 14에 도시된 바와 같이 핸드셋 브라우저에서 수신되고, 여기에서 현재 브라우징된 어플리케이션의 아이덴티티는 컨텍스트 메시지에서 다시 게이트웨이로 송신된다. 다시, 도 12로 돌아가면, 핸드셋으로부터의 컨텍스트 메시지는 게이트웨이의 서비스 매니저에서 수신되고, 여기에서 브라우징되고 있는 서비스가 S1인지 결정된다. 브라우징되고 있는 서비스가 S1이 아닌 경우에, "S1을 브라우징하지 않는다"는 메시지가 서비스로 다시 송신되고, 컨텍스트 데이터베이스는 브라우징되고 있는 서비스의 아이덴티티로 업데이트된다. 이러한 업데이트 정보는, 게이트웨이가 핸드셋으로의 무선 링크를 반드시 개방할 필요없이 컨텍스트 요구 메시지들에 답변할 수 있도록 허용하기 위해, 장래에 유용할 것이다.

핸드셋 컨텍스트가 수신된 핸드셋 컨텍스트 메시지로부터 S1인 것으로 결정된다면, 이러한 정보는 "S1을 브라우징한다"는 메시지의 형태로 서비스 S1에 송신된다.

도 15는 서비스 S1로부터 페이지 P1과 같은 다큐먼트의 수신 시에 서비스 매니저에서 수행되는 단계들을 도시하고 있다. 다큐먼트를 수신한 후에, 서비스 매니저는 다큐먼트가 발원하는 서비스의 아이덴티티가 컨텍스트 데이터베이스에 저장된 것과 매칭하는지를: 즉 S1이 데이터베이스에서 last_service의 값과 동일한지 여부를 결정한다. 어느 경우든, 다큐먼트가 핸드셋에 송신된다. 그러나, last_service의 값이 S1과 매칭하지 않는 경우에, 컨텍스트 데이터베이스는 새로운 서비스 정보로 업데이트되고, 값 last_service는 값 S1로 설정된다(그러한 상황은 서비스 S1이, 현재 브라우저 운영 서비스가 무엇이든지간에 전송되어야 되는 경보 서비스인 경우에 발생할 수 있다). 이렇게 하여, 컨텍스트 데이터베이스는, 컨텍스트 요구를 핸드셋에 송신할 필요를 줄이기 위해, 프레시 서비스 요구의 수신 시에 심문될 수 있다.

상기 실시예들에서 단지 하나의 단일 핸드셋이 제공되어 있지만, 복수의 핸드셋들이 제공될 수 있다. 이 경우에, 컨텍스트 데이터베이스는 그 핸드셋에 대한 각 식별자와 연관하여 각 핸드셋에 대해 last_service에 대한 값을, 예를 들면 룩업 테이블의 형태로 저장할 것이다.

도 16a는 다양한 논리적 기능들 또는 소프트웨어 모듈들을 도시하는 핸드셋(12)의 아키텍쳐의 추가 뷰이다. 브라우저(24) 및 로컬 서비스 S2뿐만 아니라, 메시지 라우터가 도시되어 있고, 그 목적은 브라우저로부터 요구들 및 이벤트들을 게이트웨이에, 또는 로컬 서비스 S2에 라우팅하는 것이다(도 16b는 게이트웨이에서 대응하는 세부사항을 도시하는 다이어그램이다).

메시지 라우터에 의해 수신된 원격 또는 로컬 서비스로부터의 답변들 및 이벤트들에 대한 포맷의 예는 표 1에 도시되어 있다. 핸드셋에 의해 수신되는 가능한 다큐먼트 타입들은 표 2에 리스트되어 있다.

핸드셋에 의해 수신된 가능한 다큐먼트의 전체 포맷은 표 3에 도시되어 있다. 이미지 다큐먼트 포맷은 표 4에 도시되어 있다.

이벤트의 포맷은 표 5에 도시되어 있다. 이벤트는 브라우저 요구 동안에 에러를 보고하는 메시지(다큐먼트가 발견되지 않음, 서비스가 응답하지 않음, 다큐먼트가 너무 큼, 또는 브라우저에게 통지되어야 되는 임의의 다른 에러 메시지)일 수 있다.

컨텍스트 요구에 대한 포맷은 표 6에 도시되어 있다. 핸드셋으로부터 게이트웨이로의 답변들은 컨텍스트 스킴으로 http 요구 포맷을 통해 전송된다. 스킴은 서비스가 로컬인지(handset://), 게이트웨이에 내장되는지(base://), 또는 외부 시스템에 로케이팅되는지(인터넷, http://)를 식별하는데 이용된다.

예를 들면:

GET Handset://phone_settings, phone_setting이 핸드셋 로컬 서비스인 경우

GET base://call_log, call_log가 게이트웨이에 로케이팅된 서비스인 경우

GET http://yellow_pages, yellow_pages가 인터넷에 로케이팅된 서비스인 경우.

표준 http 요구 포맷을 이용함으로써, Dect 핸드셋과 같은 무선 디바이스에게, 컨텍스트 관리 메커니즘을 내장하지 않는 베이스/게이트웨이와의 완전 양립성을 부여할 수 있다.

도 17 내지 19는 충돌들의 가능성을 감소시키는 컨텍스트 관리를 가지는 멀티 서비스 액세스의 예들에 관한 것이다. 도 17에 도시된 하나의 예에서, 사용자는 핸드셋 호출 로그에 액세스하기 원한다. 호출 로그는 게이트웨이에서 "호출 로그 서비스"로 불리는 서비스에 의해 관리된다.

<>우선, 핸드셋은 요구를 게이트웨이에 전송한다. 호출 로그 다큐먼트를 구축할 일정 시간을 필요로 하므로, 호출 로그 서비스는 그의 요구가 수신되었고 현재 처리되고 있다는 것을 사용자에게 말하는 "기다려 달라"는 다큐먼트를 핸드셋에 전송한다. 이는 또한 이러한 대기 시간을 이용하여 최종 다큐먼트가 가용되기 이전에 광고들을 푸시할 수 있다.

도 17의 시나리오에서, 사용자는 핸드셋 상에서 어떠한 액션도 없이 서비스 답변을 기다린다. 호출 로그 다큐먼트가 준비된 경우에, 호출 로그 서비스는 WML 서비스/매니저에게 여전히 핸드셋 상에서 이용되고 있는지를 묻는다. WML 서비스/매니저는 핸드셋과 무선 링크를 오픈하고 컨텍스트 정보를 요청한다. 서비스가 변경되지 않았으므로, 이는 호출 로그 서비스에게 그 서비스가 여전히 브라우징되고 있다고 말한다. 그리고나서, 이러한 후자는 최종 다큐먼트를 전송한다.

요약하면, 도 17은 호출_로그 서비스가 새로운 페이지(누락된 호출들)를 푸시하기 원하고 최종 핸드셋 액티비티가 이러한 서비스를 브라우징해오고 있었던 시나리오를 도시하고 있다. 누락된 호출들 페이지를 전송하기 이전에, 호출_로그 서비스는 WML 서비스/매니저 컴포넌트에게, 핸드셋이 이러한 서비스를 현재 브라우징하고 있는지를 묻는다. 핸드셋 상에 어떠한 로컬 브라우징도 없었는지를 체크하기 위해, WML 서비스/매니저는, 그 차례에서, 이러한 서비스가 현재 브라우징되고 있다는 것을 답변하는 핸드셋에게 컨텍스트 체크를 전송한다. 그리고나서, 호출_로그 서비스는 누락된 호출 페이지를 전송할 수 있다.

WML 서비스/매니저를 통한 최종 액티비티가 호출_로그 서비스에 대한 것이었으므로, 핸드셋과의 접속은 이러한 후자가 여전히 호출_로그 서비스를 브라우징하고 있는지(즉, 로컬 서비스로 스위칭되지 않았는지)를 체크하는 것이 필요하다. 이러한 접속 비용은 그것을 닫고 또 다른 하나를 열 필요성이 없이 누락된 호출들 페이지를 전송하는데 재이용될 것이기 때문에, 무시가능하다. 일부 무선 기술에서, 접속 닫기 및 열기는 1초 또는 일부 초까지 지속될 수 있다. 동일한 접속을 이용하는 것은 더 반응적인 시스템 및 더 짧은 무선 링크 이용 주기를 함축한다.

도 18은 호출_로그 서비스가 새로운 페이지(누락된 호출들)를 푸시하기 원하지만 핸드셋은 또 하나의 로컬 서비스(폰 세팅들)로 스위칭된 시나리오를 도시하고 있다. 누락된 호출들 페이지를 전송하기 이전에, 호출_로그 서비스는 WML 서비스/매니저 컴포넌트에게, 핸드셋이 이러한 서비스 S1을 현재 브라우징하고 있는지를 묻는다. 핸드셋 상에 어떠한 로컬 브라우징도 없었다는 것을 체크하기 위해, WML 서비스/매니저는, 그 차례에서, 그것이 로컬 폰_세팅들 서비스를 브라우징하고 있다고 답변하는 핸드셋에 컨텍스트 체크를 전송한다. WML 서비스/매니저는 호출_로그 서비스가 현재 브라우징되고 있지 않다고 결론짓고, 호출_로그 서비스에 통지한다. 그리고나서, 이러한 후자는 누락된 호출들 페이지를 전송하지 않기로 결정한다.

WML 서비스/매니저는 이제 핸드셋이 폰 세팅들 서비스로 스위칭되었다는 것을 알고 있다. 호출_로그 서비스가 호출_로그 컨텍스트(2)를 요청하는 다음 번에, WML 서비스/매니저는 핸드셋으로의 어떠한 접속없이도 "호출_로그 서비스를 브라우징하지 않는다"고 답변할 수 있을 것이다.

도 19는 호출_로그 서비스가 새로운 페이지(누락된 호들)를 푸시하기 원하지만 핸드셋은 또 하나의 원격 서비스로 스위칭되었던 시나리오를 도시하고 있다. 누락된 호출들 페이지를 전송하기 이전에, 호출_로그 서비스는 WML 서비스/매니저 컴포넌트에게, 핸드셋이 이러한 서비스를 현재 브라우징하고 있는지를 묻는다. 모든 페이지 푸시는 이러한 컴포넌트를 통과해야 하므로, 이러한 후자는 최종 호출_로그 페이지 푸시 이래로 또 하나의 서비스가 액세스되었다는 것을 알고 있다. 핸드셋 접속은 그것이 브라우징되고 있지 않다고 호출_로그 서비스에게 답변하는 것이 회피될 수 있다.

이러한 솔루션은 단지 하나의 WML 버퍼를 가지는 핸드셋에 대해 설명되었지만, 유리하게는 멀티 버퍼 디바이스들로도 확장될 수 있다. 컨텍스트 요구에 대한 답변으로서, 멀티 버퍼 핸드셋은 현재 브라우징된 서비스들의 리스트를 전송할 것이다. 게이트웨이 WML 서비스/매니저는 그 컨텍스트 데이터베이스에서 브라우징된 서비스들의 리스트를 관리할 것이다. 이러한 확장은 이러한 솔루션의 원리를 변경시키지 않고, 그 솔루션이 브라우저를 가지는 모든 디바이스들(그들 모두는 제한된 메모리 공간을 가지므로) - 그들이 동시에 단지 하나의 다큐먼트를 브라우징할 수 있든지 또는 수개의 다큐먼트를 브라우징할 수 있든지 - 에게 적용될 수 있는 방법을 설명하고 있다.

요약하면, 이들 실시예들은 상이한 서비스들로의 액세스를 제공하도록 브라우저를 내장하는 무선 디바이스들에 적용된다. 그러한 디바이스들은 이들(예를 들면, 날씨 서비스와 옐로우 페이지들 서비스) 사이에 독립적이고 정상적으로는 통신 링크를 가지지 않는 복수의 서비스들에게 공통 사용자 인터페이스(하나의 스크린, 하나의 키패드, 하나의 오디오 입력/출력)를 제공한다.

작은 메모리 또는 대역폭 제한들을 가지는 디바이스에 대해, 이러한 후자는 이러한 메모리에서 일부 상이한 다큐먼트들을 그 메모리에 저장하고 서비스 액세스를 매우 용이하게 관리할 수 있다(예를 들면, 멀티탭 브라우저).

그러나, 매우 낮은 메모리를 가지는 디바이스에 대해, 단지 하나의 다큐먼트가 저장될 수 있거나 제한된 개수가 저장될 수 있는 경우에, 서비스 액세스는 특히 푸시 모델에서 충돌이 발생할 수 있다.

풀 모델에서, 핸드셋은 서비스에게 하나의 다큐먼트를 요청하고, 그의 요구들 중 하나에 대한 답변으로 그것이 수신하는 모든 다큐먼트를 요청한다. 그것은 서비스들 사이의 충돌들을 용이하게 관리할 수 있지만, 최신의 다큐먼트를 얻도록 서비스들을 풀하기 위한 비용이 필요하다. 이러한 풀은 무선 접속을 필요로 하고, 이는 대역폭 및 전력 소비의 측면에서 고가이며, 이는 어떠한 다큐먼트 업데이트도 없는 경우에 낭비적인 것이다.

이러한 이슈에 대한 답변은 푸시 모델을 지원하는 것이다. 푸시 모델에서, 서비스들은 업데이트가 가용한 경우에 다큐먼트를 푸시하는 때를 결정한다. 단일 서비스에 있어서, 핸드셋에 의해 제공되는 단일 사용자 인터페이스는 효율적으로 작동할 수 있다. 그러나, 복수의 서비스들에 있어서, 이들 후자는 동시에 발생할 수 있고 사용자가 또 하나를 브라우징할 때 서비스 다큐먼트가 푸시되는 경우에는 사용자 인터페이스를 오염시킬 수 있다.

상기 실시예들은 다음의 잇점들을 갖는 푸시 모델에서 서비스들이 작동하는 방식을 제공할 수 있다: 핸드셋은 업데이트를 얻기 위해 서비스를 풀 할 필요가 없고; 서비스는 그것에게 다큐먼트 업데이트를 전송하기 이전에 핸드셋 상태 및 액티비티를 알 수 있으며; 임의의 쓸모없는 핸드셋 접속을 회피하는 제약에 대한 지식이 부여된다. 그것이 푸시 모델에서 작동하더라도, 이러한 솔루션은 풀 모델과 양립가능하다.

Claims (15)

1. 제2 컨텐츠(12)를 렌더링하는 노드에 제1 컨텐츠를 송신하기 위한 장치(14)로서 - 상기 제1 컨텐츠 및 제2 컨텐츠 각각은 각자의 서비스와 연관됨 - ,
   처리 스테이지(processing stage)
   를 포함하고, 상기 처리 스테이지는,
   (i) 상기 제1 컨텐츠에 연관된 서비스가 상기 제2 컨텐츠에 연관된 서비스에 공통인지 여부를 결정하고,
   (ii) 제1 서비스 및 제2 서비스가 공통 서비스인지에 따라, 상기 제1 컨텐츠가 송신되어 상기 노드에 의해 렌더링되게 하도록 구성되는 장치.
2. 제1항에 있어서,
   상기 노드로의 순방향 전송(onward transmission)을 위해, 통신 네트워크를 통해, 서비스 모듈로부터의 콘텐츠를 수신하기 위한 인터페이스 스테이지(32)를 포함하는 장치.
3. 제2항에 있어서,
   상기 처리 스테이지는 상기 서비스 모듈로부터 수신된 요구에 응답하여 상기 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되어 있는지의 여부를 결정하도록 구성되고, 상기 요구는 상기 제1 컨텐츠와 연관된 서비스의 표시를 포함하는 장치.
4. 제3항에 있어서,
   상기 처리 스테이지는, 상기 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되어 있는지에 대한 긍정 표시 또는 부정 표시 중 어느 하나에 의해 상기 서비스 모듈로부터의 요구에 응답하도록 구성되는 장치.
5. 제1항 내지 제4항 중 어느 한 항에 있어서,
   상기 노드로부터 서비스 요구들을 수신하도록 구성된 통신 스테이지를 포함하고,
   상기 처리 스테이지는 스토어를 구비하며,
   상기 처리 스테이지는 상기 노드로부터의 적어도 최종 수신된 서비스 요구와 연관된 서비스의 표시를 저장하도록 구성되는 장치.
6. 제1항 내지 제5항 중 어느 한 항에 있어서,
   상기 처리 스테이지는 컨텐츠 요구를 생성하도록 구성되고,
   상기 통신 스테이지는 상기 컨텐츠 요구를 상기 노드에 송신하도록 구성되며,
   상기 컨텐츠 요구는 상기 노드로 하여금 상기 노드에서의 상기 제2 컨텐츠와 연관된 서비스의 표시에 의해 응답하게 하도록 구성되는 장치.
7. 제6항에 있어서,
   상기 처리 스테이지는 상기 노드로부터의 응답을 이용하여 상기 제1 컨텐츠 및 제2 컨텐츠가 공통 서비스와 연관되어 있는지의 여부를 결정하도록 구성되는 장치.
8. 제1항에 있어서,
   상기 제1 컨텐츠 및 상기 제2 컨텐츠에 연관된 서비스들은 아이덴티티들이 매칭되는 서비스들에 이들이 관련되는 경우에 공통인 장치.
9. 제2 컨텐츠를 렌더링하는 노드에 제1 컨텐츠를 제공하는 방법으로서 - 상기 제1 컨텐츠 및 제2 컨텐츠는 서비스 모듈로부터의 주어진 서비스와 각각 연관됨 -,
   (i) 상기 제1 컨텐츠의 주어진 서비스는 상기 제2 컨텐츠의 주어진 서비스에 공통인지 여부를 결정하는 단계; 및
   (ii) 제1 서비스 및 제2 서비스가 공통 서비스인지에 따라, 상기 제1 컨텐츠를 상기 노드에 송신하는 단계
   를 포함하는 방법.
10. 제9항에 있어서,
    상기 제1 컨텐츠 및 상기 제2 컨텐츠에 연관된 서비스들은 상기 제1 서비스의 아이덴티티가 상기 제2 서비스의 아이덴티티와 매칭하는 경우에 공통인 방법.
11. 제10항에 있어서,
    상기 노드는 서비스와 연관된 컨텐츠를 수신하기 위해 컨텐츠 요구들을 송신하도록 구성되고,
    상기 방법은, 요구된 컨텐츠가 연관되는 적어도 최종 서비스의 표시를 저장하는 단계를 포함하는 방법.
12. 제11항에 있어서,
    상기 최종 요구된 서비스의 저장된 표시가 상기 제1 컨텐츠의 주어진 서비스와 매칭하지 않는 경우에, 상기 제2 컨텐츠는 상기 제1 컨텐츠의 서비스와 연관되어 있지 않은 것으로 추론하는 단계를 포함하는 방법.
13. 제1항에 있어서,
    상기 제1 컨텐츠는 무선 링크를 통해 상기 노드에 적어도 부분적으로 송신되는 장치.
14. 제1항에 있어서,
    상기 컨텐츠는 디스플레이 상에서 렌더링될 수 있는 이미지 데이터를 포함하는 장치.
15. 제1항에 있어서,
    상기 노드는 전화 핸드셋인 장치.

Images