KR100898522B1

KR100898522B1 - 모바일 통신 장치 관리를 웹 브라우징에 통합하는 방법 및시스템

Info

Publication number: KR100898522B1
Application number: KR1020077006297A
Authority: KR
Inventors: 타피오 이퍄; 가우라브 미딸
Original assignee: 노키아 코포레이션
Priority date: 2004-08-20
Filing date: 2005-08-18
Publication date: 2009-05-20
Also published as: KR20070039173A; EP1779594B1; BRPI0517352A8; US20060039561A1; WO2006018707A1; CN101032121A; HK1106090A1; CN101032121B; US7889869B2; CA2577638A1; JP4546528B2; CA2577638C; JP2008511049A; EP1779594A1; BRPI0517352A; BRPI0517352B1

Abstract

본 발명의 방법은 브라우징 세션 중에 장치로부터 소정 타입의 HTTP 요청 메시지를 수신하고, 그 장치로 HTTP 응답 메시지를 전송하는 단계를 포함한다. HTTP 응답 메시지는 장치 관리 세션이 개시된다는 것을 가리키는 전용 MIME-타입을 포함하고, 장치 관리 세션은 HTTP 응답 메시지의 일부를 형성하는 식별자에 의해 식별된다. 장치는 장치 세부사항(details) 및 식별자를 구비한 장치 관리 세션 응답으로서 HTTP 응답 메시지에 답한다. 장치 세부사항을 사용하여, 시스템은 장치와 호환가능한 적어도 한 개의 다운로드 옵션을 구비하는 리스트를 생성하고 그 리스트를 자치로 전송한다. 사용자가 리스트로부터 적어도 한 개의 다운로드 옵션을 선택한 데 반응하여, 시스템은 장치 관리 세션 중에 상기 장치로 상기 선택된 적어도 한 개의 다운로드 옵션을 전송한다.

Description

모바일 통신 장치 관리를 웹 브라우징에 통합하는 방법 및 시스템 {Methods and apparatus to integrate mobile communications device management with web browsing}

본 발명은 모바일 통신 장치 및 방법에 관한 것으로서, 보다 상세하게는 모바일 통신 단말 및 기기들에 사용되는 전파공간 전송을 통한 콘텐츠 전달, 웹 브라우저 및 장치 소프트웨어에 관한 것이다.

모바일 통신 장치들 내의 소프트웨어 양 및 복잡도가 증가하면서, 제조자들, 서비스 제공자들 및 소프트웨어 개발자들이 제조 단계 이후에 모바일 장치 설정(configuration) 및 그 소프트웨어 성분들을 유지시켜야할 필요성도 늘어나고 있다. 이를테면, 모바일 장치들의 사용자들에게 부가(add-on) 어플리케이션들이나 상업용 콘텐츠들을 판매하는 것은, 이상적으로는 소프트웨어 모듈들의 상호 관련 종속성에 대한 관리 및 호환성 체크를 요한다. 장치에 대한 포괄적 프로파일이나 모델 정보의 제공이 상대적으로 간단한 콘텐츠 전송 (가령, 음악 다운로드 등과 같은 것)에 충분할 수는 있지만, 어플리케이션 설치 및 특히 펌웨어 업데이트를 하는데 있어서 전송 버전 및 다운로드 패키지를 올바르게 선택하기 위해서는 상세한 모바일 장치 정보를 얻는 것이 필수적이다. 그러나 많은 경우들에 있어서, 이러한 중요한 세부 사항들이 사용자에게 알려지지 않고/거나 사용자 인터페이스를 통해 사용자에게 가시화되지 못한다.

OMA (Open Mobile Alliance)는 장치 관리 및 디지털 제품의 다운로드에 대한 수요를 충족하기 위해 서비스 일련의 실행자들(enablers)을 규격화화해 왔다. 그러나, 많은 규격들은 매우 단단히 모바일 영역에 초점이 맞춰져 있기 때문에, 이들을 구조적 요소들 (architectural components)로서 보다 일반적인 디지털 전송 시스템 개체 안에 병합하는 것이 수월치 않다.

여러 경우들에서, 모바일 장치들에 대한 디지털 전송의 이용은 전자 상거래 (e-commerce)에 기반하고 있다. 그 때문에, 기술적인 레벨의 장치 관리 작업들 외에, 수요 생성, 메뉴 브라우징, 선택, 위탁 및 지불과 같은 몇몇 사용자 레벨의 양태들이 존재한다. 자연적인 기술 선택, 및 사용자 인터페이스를 구현하기 위한 현재의 사실상의 방법이 웹 기술들, 특히 HTTP 브라우징 및 웹 어플리케이션들을 거친다. 따라서, 위에서 논의된 문제들을 해결하려는 시도는, 이상적으로는 웹 브라우저들을 포함하는 기존 및 장래의 웹 관련 기술들과 호환성이 있어야 하고 상호 운용될 수 있어야 한다.

사용자를 업데이트하는 것과 관련하여, Richard R. Reisman을 발명자로 하는 이하의 모든 미국 특허들에 대해 일반적인 참조가 이뤄질 수 있다: 5,694,546 "System for Automatic Unattended Electronic Information Transport Between a Server and a Client by a Vendor Provided Transport Software with a Manifest List"; 6,125,388, "System for Transporting Information Objects Between a User Station and Multiple Remote Sources Based upon User Modifiable Object Manifest Stored in the User Station"; 6,594,692 B1, "Methods for Transacting Electronic Commerce"; 및 6,658,464 B2, "User Station Software that Controls Transport, Storage, and Presentation of Content from a Remote Source".

상술한 것들 및 기타 문제들은 본 발명의 바람직한 실시예들에 따른 가르침을 통해 해결되거나 유리하게 구현될 것이다.

한 양태로서, 본 발명은 서버와의 사용자 인터랙션(interaction)과 함께 장치 세션을 자동화하기 위한 방법 및 시스템 모두를 제공한다. 이 방법은 브라우징 세션 중에 장치로부터 소정 타입의 HTTP 요청 메시지를 수신한 데 반응하여, 그 장치로 HTTP 응답 메시지를 전송하는 단계를 포함한다. HTTP 응답 메시지는 장치 관리 세션이 개시되었음을 나타내기 위한 전용 MIME 타입을 포함하며, 장치 관리 세션은 HTTP 응답 메시지의 일부를 이루는 식별자에 의해 식별된다. 장치는 HTTP 응답 메시지에 대해, 장치 세부사항들(details) 및 식별자를 포함하는 장치 관리 세션 응답으로 답한다. 장치 세부사항들을 이용하여, 시스템은 그 장치와 호환가능한 적어도 한 개의 다운로드 옵션을 개발하고 그 리스트를 사용자에게 전송한다. 사용자가 그 리스트에서 적어도 한 개의 다운로드 옵션을 선택한 데 응답해, 시스템은 그 적어도 한 개의 선택된 다운로드 옵션을 장치 관리 세션 중에 장치로 전달한다.

다른 양태로서, 본 발명은 무선 네트워크를 통해 정보를 다운로드 하도록 장치를 작동시키는 방법 및, 그 방법에 따라 동작하는 제어기를 구비하는 장치를 제안한다. 이 방법은 무선 HTTP 세션 중에, 다운로드 가능한 정보에 관해 장치를 사용해 탐문을 행하는 단계; 그 탐문에 응해, 보안 장치 관리 무선 다이얼로그를 개시하여 장치의 적어도 소정 사양들을 기술하는 장치 고유의 파라미터들을 얻는 단계; 장치 사양들과 호환되는 다운로드 가능 정보를 기술하는 적어도 한 엔트리를 구비하는 리스트를 생성하고 그 리스트를 장치로 전송하는 단계; 및 무선 HTTP 세션 중에 상기 리스트로부터, 장치로 다운로드 될 적어도 한 엔트리를 선택하는 단계를 포함한다.

본 발명의 또 다른 양태로서, 무선 네트워크를 통해 한 장치로 정보를 다운로드하기 위해 그 장치와 함께 작동될 수 있는 장치 관리 서버가 제안된다. 이 장치 관리 서버는 장치를 연결하는 제1인터페이스, 작업 플로우 (workflow) 관리자를 연결하기 위한 제2인터페이스, 및 장치에 반응하여 개시되는 동작들을 수행하는 프로그램을 통해 작동되고, 무선 HTTP 세션 중에 다운로드 가능한 정보에 관한 질의를 만드는 제어기를 포함한다. 장치 관리 서버는 장치와 보안 장치 관리 무선 세션을 개시하는 작업 플로우 관리자에 더 반응하여 장치의 적어도 소정 사양들을 기술하는 장치 고유의 파라미터들을 얻고; 제2인터페이스를 통해 작업 플로우 관리자와 협동하여, 장치 사양들과 호환되는 다운로드 가능한 정보를 기술하는 적어도 한 엔트리를 포함하는 리스트를 생성하여 제1인터페이스를 통해 장치로 전송하고; 무선 HTTP 세션 중에, 장치 사용자에 의해 선택된 리스트로부터의 적어도 한 엔트리에 대응하는 정보를 장치로 다운로드 한다.

본 발명의 또 다른 양태로서, 장치 및, 무선 네트워크를 거쳐 장치로 정보를 다운로드하는장치 관리 서버와 함께 작동하는 작업 플로우 관리자가 제안된다. 작업 플로우 관리자는 웹 사이트를 통해 장치 및 장치 관리 서버에 연결하는 제1인터페이스, 적어도 한 백엔드(back-end) 시스템에 연결하는 제2인터페이스, 및 장치에 반응하여 개시되는 동작들을 수행하도록 프로그램을 통해 작동되는 것으로서, 무선 HTTP 세션 중에 다운로드 가능한 정보에 관하여 웹 사이트로 탐문을 행하는 제어기를 포함한다. 작업 플로우 관리자는 장치와 보안 장치 관리 무선 세션을 개시하여 장치의 적어도 소정 사양들을 기술하는 장치 고유의 파라미터들을 얻고; 제1인터페이스를 통해 장치 관리 서버와, 그리고 제2인터페이스를 통해 적어도 한 백엔트 시스템과 협동하여 장치 사양들과 호환 가능한 다운로드 가능한 정보를 기술하는 리스트를 생성한다. 작업 플로우 관리자는 제1인터페이스 및 웹 서버를 거쳐 장치로 그 리스트를 전송하도록 더 작동한다.

본 발명에 따른 가르침에 대한 상기 양태들 및 기타의 양태들은, 이하의 바람직한 실시예들에 대한 상세한 설명을 첨부된 도면과 함께 파악함으로써 보다 분명해질 수 있다:

도 1은 전자 상거래 기반 이용 케이스의 일부인 디지털 전송에 대한 통상의 시퀀스의 논리 레벨 시퀀스도이다;

도 2 (도 2a, 도 2b)는 본 발명의 바람직한 실시예들에 따른 장치를 통해 일어나는 펌웨어 업데이트에 대한 전형적인 케이스의 메시지 플로우 시퀀스도이다;

도 3은 도 2의 메시지 플로우 시퀀스에 사용하기 적합한 장치의 블록도이다;

도 4는 도 2의 메시지 플로우 시퀀스에 사용하기 적합한 DM 서버의 블록도이다;

도 5는 도 2의 메시지 플로우 시퀀스에 사용하기 적합한 작업 플로우 관리자에 대한 블록도이다;

도 6은 본 발명의 개념의 한 양태에 따른 장치 관리 통지 메시지를 전송하는 HTTP 응답 메시지의 구조에 대한 비한정적 예를 도시한 것이다;

도 7은 도 6의 HTTP 응답 메시지에 의해 운반되는 장치 관리 통지 메시지의 구조에 대한 비한정적 예를 도시한 것이다.

본 발명에 대해 현재로서 바람직한 실시예들에 대한 당면한 현재의 웹 관련 기술들을 서술한 문서들의 예에 다음과 같은 것들이 포함된다: RFC 2616: Hypertext Transfer Protocol-HTTP/1.1, IETF, 1999년 6월; RFC 2109: HTTP State Management Mechanism; IETF, 1997년 2월; 및 SyncML Device Management Protocol, 1.1.2 버전 (OMA-SyncML-DMProtocol-V1_1_2-20030612-C), 오픈 모바일 연맹, 200년 6월.

디지털 전송 트랜잭션 중에 쾌적한 사용자 경험을 보장하기 위해, 본 발명의 발명자들은 상세한 레벨의 장치 정보 수집 및 관리 절차들이 자동화되고 디지털 전송 트랜잭션에 끊어짐 없이 (seamlessly) 통합될 수 있어야 한다는 것을 인지해 왔다. 본 발명의 바람직한 실시예에서는 웹 브라우징 기반 디지털 전송 트랜잭션시 통합 서브 성분들로서, OMA 서비스 실행자들, 바람직하게는 OMA 장치 관리 및 OMA 다운로드를 활용하는 모델이 사용된다. 본 발명에 대해 현재로서 바람직한 실시예들을 사용하는 것은 펌웨어 업데이트 사용의 경우 특히 유용하겠지만, 다른 디지털 전송 어플리케이션들에도 역시 유익하게 적용될 수 있을 것이다.

본 발명의 목적을 위해 "펌웨어"는, 장치(10)의 일부를 이루는 데이터 프로세서에 의해 직간접적으로 실행될 수 있는 (가령, 컴파일러나 번역기(interpreter)를 통해 실행된 후에) 상대적 하위 레벨 언어로 작성된 컴퓨터 코드를 구비한다고 간주되는 것이다. 펌웨어 또는 펌에어 업그레이드의 예가, 비한정적인 것으로서, 기본적 통신 규격의 변경에 따라 필연적이거나 선택적으로 수행될 수 있는, 운용 시스템 모듈, http 프로토콜 스택 구성, 또는 무선 네트워크 액세스 및/또는 스캐닝 절차에 대한 개정이 될 수 있다. 이와 대비하여, "어플리케이션"이란 포획된 이미지들 (장치(10)가 디지털 카메라를 포함한다고 전제함)을 어떤 네트워크 제공 이미지 데이터베이스에 보관하기 위해 주어지는 개선형이거나 상이한 인터넷 브라우저, 미디어 플레이어, 또는 이미지 포획 프로그램 같이, 새롭고, 가능하면 선택적인 기능을 장치(10)에 전해주는 상위 레벨 프로그램이라고 생각될 수 있다. 이해할 수 있다시피, 장치의 운영 시스템 소프트웨어, 설치된 메모리 량, 부속 디지털 카메라의 타입 (가령, 모델 넘버), 및 다른 종류의 파라미터들 같은, 장치(10) 구조 및 동작에 대한 사양은 장치(10)로 다운로드 되는 펌웨어나 어플리케이션 소프트웨어의 타입 및/또는 개정 레벨에 지대한 영향을 미칠 수 있다. 단지 한 예로서, 사용자가 장치(10) 하드웨어와 호환되지 않거나 장치(10)의 제조일 뒤에 발매 되었던 운영 시스템 버전을 전제한 펌웨어나 어플리케이션을 다운로드 하고 싶어할 수 있다. 이러한 경우들 중 어느 한 경우, 단순히 사용자가 요청한 펌웨어나 어플리케이션을 다운로드하는 것은 사용자에게 중대한 문제를 일으키고, 장치(10) 제조자와 결부되거나 사용자(10)가 가입한 네트워크 운영자와 결부될 수 있는 웹 사이트(30)를 통한 최적을 밑도는 사용자 경험을 만들 수 있다. 본 발명에 동기가 된 한 요인이, 사용자에게 최소의 영향을 미치면서 그러한 문제들을 피하고자 하는 것이다. 사용자 인터랙티브 (user-interactive)및 사용자 비인터랙티브 (non-user-interactive) (가령, 배경) 두 타입 모두의 동작들에 있어 사용자에게 최적의 경험을 제공한다는 것이 본 발명이 원하는 목적이다.

이하에서 논의되는 본 발명의 바람직한 전형적 실시예들은 최초에 OMA 틀 안에서 주어지나, 본 발명의 단지 OMA 기반 실행자들 및 기술에 대해서만 제한되는 것은 아님을 알아야 한다.

도입부로서, 전자 상거래 기반 활용의 일부로서 디지털 전송의 통상적 시퀀스가 도 1에서 논리 레벨 시퀀스도의 형식으로 도시되고 있다. 도 1은 모바일 스테이션(MS)(10), DM 서버(20) 및 웹 서버(30)와 결부된 최종 사용자(1)를 보이고 있다. 최종 사용자(1)와 웹 서버(30) 사이에 사용자 세션이 존재한다고 전제하며, 한편 MS(10) 및 DM 서버(20) 사이에는 장치 세션이 존재한다. 도 1은 MS(10)에 대해 일반적 디지털 전송 세션을 일으키는 문제들을 설명하는데 유용하며, 그에 따라 본 발명의 바람직한 실시예들에 의해 제공되는 개선 효과에 대한 이해를 강화하는데 도움을 준다.

본 발명의 개념이 상당수의 사용자 인터페이스 기술들에 적용될 수 있으며 웹 인터페이스 기술들에만 한정되는 것은 아니라는 것을 알아야 한다. 비한정적 예로서, 무선 어플리케이션 프로토콜 (WAP) 기술들 및 JAVA^TM 기반 어플리케이션들에도 역시 본 발명의 개념이 적용될 수 있다.

도 1과 관련하여, 성공적 마케팅의 성공적 결과로서 웹 링크 정보에 따라 사용자(1)가 모바일 스테이션들에서 이용가능한 다운로드 가능 아이템들을 가진 웹 사이트(30)에 들어왔다고 전제할 것이다. 이러한 인터랙션(interaction)이 일반적 브라우징(40)으로서 도시된다. 사용자(1)에게 주어지는 선택사항들이 실제로 호환성이 있고 기능적이라는 것을 보장하기 위해, 서버 측의 시스템은 MS(10)의 사양을 알 필요가 있다. 이를 얻기 위해 통상의 수동적 절차는 MS(10) 모델들의 범위에 따라 디지털 제품 편차들의 스펙트럼을 제한해야 할 것이며, 사용자 인터랙션의 시작 시점으로서, 사용자(1)에게 MS(10) 모델 정보를 촉구해야 할 것이다. 그러나, 이러한 통상적 방식에는 본질적인 단점들이 여럿 존재한다. 몇 가지 예를 들면, 첫째, 이러한 방식은 사용자(10)가 평범한 데이터 입력 작업을 수행하도록 재촉되면서 열악한 사용자 경험으로 이어질 수 있다. 게다가, 사용자에 대한 명령이 완벽하게 명료하지 않으면, 사용자(10)가 웹 서버(30)를 버리고 원하는 디지털 전송을 위해 다른 곳으로 갈 수가 있다. 둘째, 사용자(1)에게 정보를 입력하라고 요청함으로써 정보 안정성이 떨어질 수 있다. 이해할 수 있다시피, 어떤 경우들에서는 장치 정보의 정확성이 성공적 전송 (및 특히 전달된 어플리케이션이나 펌웨어의 성 공적 작동)에 매우 중요한 것이 된다. 세째, 앞의 두 이슈들과 관련하여, 요청된 정보의 복잡도로 인해 사용자(1)가 그 정보를 알 수 없고, MS(10)의 일반 사용자 인터페이스를 이용해 그것을 검색할 수 없을 정도가 될 수 있다.

사용자 세션(40) 외에, 별개의 장치 세션(42)이 사용되어 충분한 장치 정보를 모음으로써 사용자(10)에 대한 선택적 다운로드 가능 아이템들로 된 메뉴가 생성된다. 이 메뉴가 웹 기반 사용자 세션(44)에 나타날 수 있고, 이때 사용자(1)는 메뉴를 검색하여, 부가적 정보를 읽고, 선택하고 전송을 행할 수 있다 마지막으로, 사용자(1) 선택(들)에 따라, 전송 및 관련 장치 관리 작업들이 제2장치 세션(46)에 걸쳐 이행된다.

발명자들은, 도 1에 도시된 전형적 시나리오에서 일어나는 문제가, 서로 상이한 두 세션들 (사용자 세션과 장치 세션)을 어떻게 최적으로 결합하여 이들 사이에 데이터를 전송하는 것인가 임을 인지해 왔다. 이를테면, 사용자(1)가 웹 브라우저를 써서 웹 서버(30)에 들어와 관련 아이템들의 리스트를 보여줄 것을 요망한 뒤에, 장치(MS(10)) 사양과 호환성 정보를 얻기 위해 OMA 장치 관리 세션을 시작하는 최상의 방법이 어떤 것인지? 또, 이러한 자동 정보 수집이 이행될 수 있다고 전제한 상태에서, 웹 세션에서의 결과들을 사용자 브라우저로 리턴하는 최상의 기술이 무엇인지? 즉, OMA DM 세션을 사용자의 웹 브라우징 세션에 통합시키거나 부트스트랩(bootstrap)할 가장 적절한 방식이 무엇인지?

사용자 브라우저 및 OMA DM 통합 세션을 제공함에 있어 본질적인 심층 문제들에 대한 보다 완전한 이해를 위해, 지금부터 웹 기술들 (HTTP 환경 하의) 및 OMA 장치 관리에 대한 몇 가지 당면한 기본 원리를 설명할 것이다.

HTTP는 간단하면서 강력한 웹의 네트워크 프로토콜이다. 이것은 보통, HTTP 서버 (보통 웹 서버)로부터 HTTP 클라이언트 (웹 브라우저 등)로 자원들 (파일들, 어플리케이션 출력)을 전달하는 TCP/IP (Transport Control Protocol/Internet Protocol) 소켓들의 최상위에 구축된다.

원래, 웹 세션이라는 개념은 HTTP에 존재하지 않았는데, 이는 HTTP가 두 개의 메시지들인 요청 및 응답 메시지들을 가지고 선택적 방법들인 GET, POST 및 HEAD를 포함하는 스테이트리스 프로토콜 (stateless protocol)이기 때문이다.

먼저, 각 쌍의 요청-응답 메시지들 이후에 기본 TCP/IP 세션이 닫혀졌다. 그러나, 웹 기술이 진보되고 더 널리 사용됨에 따라, 웹 페이지들의 사이즈와 복잡도가 극적으로 증가하였고 이것이 현재 통상적으로 보여지고 있는 수십 또는 수백 개의 별도 HTTP 자원들 (반짝이는 GIP 아이콘들, 깜박이는 배너들, 및 애니메이션형 썸네일(thumbnail) 광고 등)을 포함한 웹 페이지들을 가져왔다. 이러한 HTTP 웹 페이지 복잡도의 증가의 결과로서, 클라이언트와 서버 모두에서의, 각 HTTP 요청에 대한 전용 TCP/IP 소켓을 열고 닫기 위한 컴퓨팅 자원 비용이 크게 증가되었다. 그에 따라, 프로토콜 전문가들은 영속적 TCP/IP 접속을 이용하기 위한 기술을 (HTTP 1.1에서) 규격화하였다. 그러나, 영속적 TCP/IP 소켓을 적절히 사용해도, HTTP 요청에 선행하지 않고 서버가 클라이언트를 향해 응답 메시지를 보내는 것은 불가능하다. 달리 말하면, 웹 서버는 브라우저로 정보를 푸시(push)할 수 없다 (RFC 2616: Hypertext Transfer Protocol-HTTP/1.1, IETF, 1999년 6월 참조).

HTTP의 스테이트리스(stateless) 지향에도 불구하고, 더 많은 웹 어플리케이션들이 나타나면서 웹 세션들은 빠르게 자명해졌다. HTTP 상태 관리 메커니즘 (RFC 2109: HTTP State Management Mechanism; IETF 1997년 2월 참조)이 웹 어플리케이션 개발자에게 한 개의 고유 사용자 세션 안에 몇몇 HTTP 메시지들을 결합시키는 HTTP에 더한 특징들을 제공하고 있다. 구성은, 사용자 및 세션 관련 정보를 메시지들 전부를 통해 클라이언트로부터 서버로 전달되는 쿠키들을 포함한다. 서버는 보통 자신의 콘텐츠를 가짜 클라이언트가 함부로 손대지 못하게 하기 위해 그 쿠키를 암호화한다.

이제 OMA DM으로 화제를 돌리면, OMA DM의 풀 네임이 가리키는 바와 같이, SyncML Device Management Protocol (장치 관리 프로토콜)이 장치 관리 영역에서 SyncML을 활용한다. 이것은 DM 클라이언트와 DM 서버에서의 구현을 위한 클라이언트-서버 프로토콜이다.

DM 클라이언트는 관리 가능한 오브젝트들을 포함하는 트리 형태의 데이터 구조인 관리 트리를 포함한다. 요청된 장치 관리 작업들을 실행하기 위해, DM 서버는 Get (가져오기), Replace (치환하기) 및 Exec (실행하기) 같이 관리 트리 내 오브젝트들을 타겟으로 하는 명령들을 사용한다.

OMA DM은 도 1의 MS(10) 같은 장치와 서버 사이에서의 인터랙션에 최적화되어 있다. 사용자 인터랙션을 위해, 통지 및 사용자 선택과 같은 특징을 구현하기 위한 간단한 명령들이 존재하나, 일반적으로 OMA DM의 사용자 인터페이스 사양들은 매우 제한되어 있다.

OMA 장치 관리 세션이 설정되기 이전에, 장치는 "부트스트랩 되어야 (bootstraped)" 한다. SyncML 장치 관리 프로토콜 규격이 부트스트랩을 위한 두 가지 방법을 정의한다:

(a) 주문화된 (customized) 부트스트랩으로서, 장치들은 제조시 SyncML DM 부트스트랩 정보와 함께 로드된다 (팩토리 부트스트랩이라고도 칭함);

(b) 서버 발의 (server initiated) 부트스트랩으로서, 서버가 가령 WAP Push 혹은 OBEX 같은 몇 가지 푸시 메커니즘을 통해 부트스트랩 정보를 발송한다. 이 방법에서, 서버는 사전에 장치 정보/전화 번호에 대해 정보를 얻는다. 부트스트랩 절차 중에, 서버 어드레스와 식별자뿐 아니라 클라이언트와 서버 모두와 관련된 인증 정보를 포함하는 여러 파라미터들이 장치에서 세팅된다. 본 발명에 대해 현재로서 바람직한 실시예들은 팩토리 부트스트랩 절차를 이용하는 것을 선호하지만, 서버 발의 부트스트랩 절차 역시 사용될 수 있다.

본 발명의 현재로서 바람직한 (그러나 여기에 한정되는 것은 아닌) 실시예들에 적절한 HTTP 및 OMA DM 환경들을 설명하였으므로, 지금부터는 본 발명에 따른 방법들 및 장치에 대해 현재로서 바람직한 실시예들을 설명할 것이다.

본 발명의 두드러진 양태들은, HTTP 응답 메시지를 통한 전용 MIME 타입을 사용하여, OMA DM 세션을 시동하고 장치로 부트스트랩 파라미터들을 보내고; 클라이언트 공급 메시지 내 부트스트랩 정보를 비밀 키로서 암호화하고 (통지가 부트스트랩 대신 활용될 수 있음); 웹 세션과 장치 세션(들)을 한 개의 종합적 트랜잭션 안에 합치기 위해 상위 계층 디지털 전송 세션 및 그 식별자를 사용하는 것을 포함 한다. 본 발명의 또 다른 양태는, 대기 된 (queued) HTTP 요청; 소정 URL을 가진 웹 브라우저 오브젝트에 대한 OMA DM Exec 명령; 및 이전에 전송된 동작 프롬프트 (activation prompt)에 대한 사용자 응답을 이용하여, 장치 세션 뒤에 웹 세션에 대한 제어로 돌아가는 절차에 관한 것이다.

보다 구체적으로, 본 발명의 이러한 추가적 양태에 의해 수반되는 것이 어떤 것인지는 다음과 같다:

1. 대기 된 HTTP 요청

HTTP 응답 (이하에서 설명될 도 2의 메시지 (g))에 대한 반응으로서, DM 세션 설정 (이하에서 설명될 도 2의 메시지 (h)) 외에, 장치(10)는 웹 서버(30)에 대한 HTTP 요청문을 생성한다. 웹 서버(30)는 사용자 옵션 메시지 (이하에서 설명될 도 2의 메시지 (o))를 수신할 때까지 그 요청을 대기시키고, 그런 다음 브라우저(10B)로 그에 대한 응답 (이하에서 설명될 도 2의 메시지 (p))을 전송한다.

2. OMA DM Exec

메뉴 (이하에서 설명될 도 2의 동작 (n))를 생성한 후, 작업 플로우 (workflow) 관리자(50)는 DM 서버(20)에 장치 (10)의 DM 클라이언트(10A)로 Exec 명령을 보내줄 것을 요청하고, 이 방식으로 장치의 웹 브라우저(10B)가 활성화될 것과 HTTP 요청을 웹 서버(30)로 보낼 것을 요청한다. 웹 서버(30)는 HTTP 응답 (이하에 설명될 도 2의 메시지 (p))시 웹 브라우저(10B)로 옵션들 (이하에 설명될 도 2의 메시지 (o))을 보내 이 HTTP 요청에 응답한다.

3. 동작 프롬프트에 대한 사용자 응답

HTTP 응답 (이하에 설명될 도 2의 메시지 (g))의 일부로서, 웹 브라우저(10B)에서 나타낼 사용자 인터페이스 정보 역시 존재한다. 이 사용자 인터페이스 동작은 사용자에게 프롬프트 (가령, "기다리시오, 장치 정보 수집 중입니다" ) 및 따르기(submit) (가령, "ok") 버튼 표시를 포함한다. 사용자가 정보를 수용할 때 (가령, "ok" 버튼을 눌러서) 웹 브라우저(10B)는 웹 브라우저(30)로 HTTP 요청문을 보낸다. 이제 그 요청은 선택사항 1에서와 같이 (대기 된 HTTP 요청으로서) 처리될 것이다.

일반적으로, MIME은 원래 인터넷 메일의 포맷을 확장하여 비(non)-US-ASCII 텍스트 메시지들, 비(non)-텍스트 메시지들, 멀티-파트 메시지 본문들 및 비-US-ASCII 정보를 메시지 헤더들에서 허용하도록 의도된 것이었다. 다음과 같은 RFC들이 MIME을 정의한다: RFC 2045: MIME 파트 1; Format of Internet Message Bodies; RFC 2046: MIME 파트 2; Media Types; RFC 2047: MIME 파트 3: Message Header Extensions for Non-ASCII Text; RFC 2048: MIME 파트 4: Registration Procedures; 및 RFC 2049: MIME 파트 5: Confromance Criteria and Examples. RFC 1521에 의해 폐기된 RFC 1341 (1992년 6월): MIME (Multipurpose Internet Mail Extensions) 파트 1: Mechanisms for Specifying and Describing the Format of Internet Message Bodies (1993년 9월) 및 RFC 1342: MIME (Multipurpose Internet Mail Extensions) 파트 2: Message Header Extensions for Non-ASCII Text (1993년 9월)을 참조할 수도 있다.

지금부터, 사용자(1), 도 1의 MS(10) 같은 장치, 웹 사이트 (또는 웹 서 버)(30), DM 서버(20), 상술한 작업 플로우 관리자(50) 및 한 개 이상의 백엔드 시스템들(60) 사이에서의 신호 및 메시지 플로우를 보이는 도 2의 실시예에 관한 시스템을 설명할 것이다. 여기서 행위자들(actors)이라고도 칭할 수 있는 이러한 다양한 구성 요소들의 기능과 책임에 대해 이하에서 논의될 것이며, 그 다음에 도 2에 도시된 사용 시퀀스에 대한 설명이 뒤따를 것이다.

본 발명의 실시예 대한 한정 수단이 아닌, 본 발명의 현재로서 바람직한 실시예에서, 장치(10)와 웹 사이트(30) 사이의 링크가 적어도 부분적으로 셀룰라 RF 링크나 블루투스 링크, 또는 무선 랜 (WLAN) 링크나, 광학적 링크를 통해서, 가능하다면 장치(10)의 네트워크 제공자를 거쳐 (가령, 셀룰라 네트워크 운영자나 WLAN 핫 스팟 (hotspot) 운영자를 거쳐) 실행된다.

본 발명의 실시를 제한하는 것이 아닌 본 발명의 현재로서 바람직한 실시예들에 대한 설명을 목적으로 할 때, 사용자(10)는 장치(10)를 이용하는 사람이 된다. 사용자(1)는 콘텐츠, 어플리케이션 및/또는 펌웨어 업데이트 같이, 네트워크에서 이용 가능한 (가능하다면 상업용) 디지털 제품들에 흥미가 있을 수 있다. 웹 부라우저는 디지털 제품을 찾고, 선택하고 그 전송을 담당하는 바람직한 어플리케이션이다. 사용자(1)가 반드시 장치(10)를 보유하는 것은 아니다.

본 발명의 실시를 제한하는 것이 아닌 본 발명의 현재로서 바람직한 실시예들에 대한 설명을 목적으로 할 때, 장치(10)는 OMA DM 클라이언트 어플리케이션 구현(10A) 인스턴스 및 HTTP 1.1 부합 웹 브라우저(10B)를 구비한 모바일 구성요소이거나 그러한 모바일 구성요소를 포함한다. 펌웨어 업데이트를 위해, 장치(10)는 전형적이지만 비한정 예로서, OMA FOTA(Firmware Over the Air) 사양을 포함할 수 있다. 장치(10)는, 전형적이지만 비한정 예로서, 셀룰라 혹은 비셀룰라 전화, 또는 LAN 및/또는 WLAN과의 무선 인터페이스를 구비한 컴퓨터, 도는 LAN 및/또는 WLAN과의 무선 인터페이스 (RF 및/또는 IR)를 구비한 PDA, 또는 사용자(1)가 브라우저를 작동시켜 웹 서버나 사이트(30)에 접촉할 수 있게 하는 어느 적절한 인터넷 기기일 수 있다. 따라서 장치(10)은 통상적으로 무선 (RF 또는 광학적) 트랜시버를 구비할 것이다.

도 2의 메시지 플로우 시퀀스에 사용하기 적합한 장치(10)에 대한 비한정적 예로서의 블록도를 보인 도 3을 참조할 것이다. 장치(10)는 운영 시스템 및 기타 통상의 소프트웨어 이외에 본 발명에 따른 OMA-DM 클라이언트(10A)를 구현하기 위한 소프트웨어 및 웹 브라우저(10B)를 저장하는 메모리(12)에 연결된, 마이크로프로세서 같은 제어기(11)를 포함한다고 추정된다. 메모리(12)에서, 제조시 로드되었거나, 장치가 최초로 작동되었을 때 로드되었던 장치 세부사항들 (가령, 하드웨어 사양, 운영 시스템 버전, 메모리 용량)을 저장한 장치 테이블(10C)이 더 발견될 수 있다. 사용자 인터페이스 (UI)(13) 또는 적절한 UI에 대한 인터페이스 역시 구비된다. 비한정적인 한 실시예에서, UI(13)는 사용자 디스플레이 (가령, LCD 디스플레이)(13A) 및 키보드나 키패드(13B) 사용자 데이터 입력 장치를 포함한다. 제어기(11)는, 통상적으로 셀룰라 전화 네트워크 운영자나 무선 LAN 네트워크 같은 무선 네트워크/운영자를 거쳐 웹 사이트(30) 및 DM 서버(20)와 통신하기 위한 적절한 RF 혹은 광학 트랜시버(14)에도 연결되어 있다. 장치(10)의 유선 실시예에서 트랜시버(14)는 전기 또는 광 테이블이나 기타 유선에 연결될 것이다.

본 발명을 제한하는 것이 아닌 본 발명의 현재로서 바람직한 실시예들을 설명할 목적에 따라, 웹 사이트(30)는 사용자(1)에 대한 사용자 인터페이스 (HTML 페이지들)를 구현하는 HTTP 1.1-부합 웹 서버를 포함하거나 그거에 링크된다. 웹 사이트(30)는 웹 어플리케이션들을 구현하기 위한 API (Application Program Interface), 및 기타 서버 측 구성요소들 (가령, 20, 50, 60)에 대한 인터페이스를 포함한다.

본 발명을 제한하는 것이 아닌 본 발명의 현재로서 바람직한 실시예들을 설명할 목적에 따라, DM 서버(20)는 OMA SyncML DM 프로토콜 스택을 구축하고, 장치(10)의 DM 클라이언트(10A)와 통신하며, 기타 서버 측 구성요소들(30, 50, 60)로의 인터페이스들을 구비한다. SyncML에 관해 예로서, SyncML Device Management Protocol, 1.1.2 버전 (OMA-SyncML-DMProtocol-V1_1_2-20030612-C, 오픈 모바일 동맹, 2003년 6월과, SyncML Device Information DTD, 1.1 버전, 2002년 2월 (여기서 DTD는 Document Type Definition (문서 종류 정의)를 나타냄)를 참조할 수 있다.

도 2의 메시지 플로우 시퀀스에 사용하기 적합한 DM 서버(20)의 비한정적 예로서의 블록도를 보이는 도 4를 참조한다. DM 서버(20)는 마이크로프로세서 같은 제어기(21)를 포함하며, 제어기는 메모리(21A)에 연결되어 있고, 메모리는 운영 시스템 및 다른 전형적 소프트웨어(SW) 이외에, OMA SyncML DM 프로토콜 스택을 구현하기 위한 소프트웨어 및 장치(10)의 OMA-DM 클라이언트(10A)와 통신하기 위한 소프트웨어를 저장하고 있다. DM 서버(20)는 장치(10) 및 작업 플로우 관리자(50)와 통신하기 위한 입출력 인터페이스들 (I/Os)(22A 및 22B) (이들은 논리 및/또는 물리적 I/O들일 수 있음)을 포함한다. I/O 인터페이스들(22A, 22B)은 TCP/IP를 거쳐 인터넷 통신하는 논리적 인터페이스들로서 구현될 수 있다는 것을 알아야 한다.

본 발명을 제한하는 것이 아닌 본 발명의 현재로서 바람직한 실시예들을 설명할 목적에 따라, 작업 플로우 관리자(50)는 펌웨어 업데이트 트랜잭션 같은 전반적 디지털 전송 프로세스를 계속해서 추적한다. 작업 플로우 관리자(50)는 고유한 트랜잭션 식별자(TID)를 생성하고, 웹 서버(30)와 DM 서버(20)를 사용자(1) 및 장치(10)에 대한 인터페이스들로서 활용하고, 개별적 하위 레벨 세션들을 한 개의 논리적 트랜잭션 안에 합한다. 작업 플로우 관리자(50)는 장치(10)와의 트랜잭션 중에 어떤 특정한 작업들을 이행하기 위해 백엔드 시스템(60)의 서비스들을 활용함이 바람직하다.

도 2의 메시지 플로우 시퀀스에 사용하기 적합한 작업 플로우 관리자(50)에 대한 비한정적 예로서의 블록도를 보이는 도 5를 참조한다. 작업 플로우 관리자(50)는 마이크로프로세서 같은 제어기(51)를 포함한다고 전제되며, 이 제어기는 메모리(51A)에 연결되어 있고, 메모리는 운영 시스템 및 다른 전형적 소프트웨어(SW) 이외에, TID를 생성하고 장치(10) 및 다른 시스템 구성요소들과의 다양한 트랜잭션들을 관리하고 상관시키는 소프트웨어를 저장하고 있다. 작업 플로우 관리자950)는 웹 사이트(30), DM 서버(20), 및 백엔드 서버(들) 및 시스템(들)과 통신하기 위한 I/O들 (52A 및 52B) (이들은 논리적 및/또는 물리적 I/O들일 수 있음)을 포함한다. DM 서버(20)에서처럼, 두 I/O 인터페이스들(52A, 52B) 모두 TCP/IP 를 통해 인터넷과 통신하는 논리적 인터페이스들로서 구현될 수 있다.

본 발명을 제한하는 것이 아닌 본 발명의 현재로서 바람직한 실시예들을 설명할 목적에 따라, 백엔드(back-end) 서버(들) 및 시스템(들)(60)이 작업 플로우 관리자(50)로 서비스를 제공한다. 이 서비스들에는, 인증, 암호화, 서명의 보안 서비스들, 법적 보증 상태 정보 같은 장치(10) 관련 서비스들 및, 제품 데이터 관리 (PDM) 정보 같은 상세한 제품 관리 서비스들이 포함되나, 상기 나열한 예에 한정되지 않는다.

본 발명을 제한하는 것이 아닌 본 발명의 현재로서 바람직한 실시예들을 설명할 목적에 따라, 작업 플로우 관리자(50) 및 백엔드 시스템(들)(60)이 웹 사이트(30) 및 DM 서버(20)를 제어하는 같은 개체에 의해 제어된다. 그러나, 이것이 본 발명의 실시에 대한 제한사항은 아니며, 이 구성요소들 중 하나나 둘 모두가 제3의 당사자들의 통제 하에 놓여 질 수 있다. 이를테면, 백엔드 시스템들(60) 중 하나가 제3자인 디지털 서명 입증자, 혹은 제3자인 디지털 지불 도우미(facilitator)일 수 있다.

이제 도 2에 도시된 전형적 시퀀스도로 주의를 기울이면, 본 발명의 실시예들에 따라 다음과 같은 단계들이 실행된다. (a) 단계에서, 사용자(1)가 경쟁적 웹 사이트들을 두루 검색하고 원하는 판매자의 펌웨어(FW) 업데이트 페이지들을 발견한다. (b) 단계에서, 사용자(1)는 FW 업데이트 페이지 내 어떤 링크를 클릭하여, 어떤 새로운 FW 업데이트 선택사항들 (있는 경우)이 장치(10)에서 사용가능한지를 판단한다. (c) 단계에서, 웹 사이트(30)가 장치(10)를 통해 사용자(1)에게 한 페 이지를 전송하고, 장치(10)를 거쳐 사용자(1)에게 자동화된 장치 정보 수집이 곧 시작된다는 것을 알리도록 HTTP 응답문이 사용된다. 적절한 메시지는 "당신의 전화에 요청된 펌웨어를 검색하는 동안 기다리시오"가 될 수 있다. (d) 단계에서, 사용자(1)는 장치(10)의 사용자 인터페이스를 통해, 자동화된 장치 세션 설정을 수용하고, 이것은 브라우저(10B)로부터 웹 서버(30)로 HTTP 요청문이 보내지게 되는 결과를 가져온다. (e) 단계에서, 웹 서버(30)는 작업 플로우 관리자(50)에게 펌웨어 업데이트 트랜잭션 (FWupdTransaction)을 시작하고 OMA DM 세션을 설정하라는 사용자 요청이 있었음을 알린다. 그에 대한 응답으로서, 작업 플로우 관리자(50)는 고유 TID를 가진 새 트랜잭션을 생성한다. (f) 단계에서, 백엔드 서비스들(60)의 도움으로, 작업 플로우 관리자(50)는 알맞은 OMA 클라이언트 공급 (CP) 메시지를 생성하고 비밀 키를 이용해 그것에 서명한다. INIT DM 메시지가 암호화된 CP와 함께 웹 사이트(30)로 보내진다. (g) 단계에서, HTTP 응답문의 일부로서, 웹 사이트(30)는 OMA 장치 관리 전용 MIME 타입과 함께 그 서명된 CP 메시지를 장치(10)로 보낸다. TID는 HTTP 응답 메시지에 내장된다. MIME-타입 정보와 서명된 CP 메시지에 기반하여, (h) 단계에서 장치(10)가 DM 부트스트랩 정보의 타당성을 체크하고, 그에 따라 파라미터들을 세팅하며, OMA DM 클라이언트 어플리케이션(10A)을 시동한다. (i) 단계에서, OMA DM 클라이언트(10A)는 OMA DM 세션을 설정하고, 장치(10) 정보 세부사항을 DM 서버(20)로 보낸다. 이들 장치 세부사항은 장치(10)의 메모리(12)에서 테이블(10C)로서 저장될 수 있고, 제조시나 장치가 최초로 동작 되었을 때 로드되어 있었을 수 있다. 어느 경우든, 이 (i) 단계가 자동으로 사용 자(1) 개입 없이 일어남이 바람직하기 때문에, 사용자(1)는 장치(10) 정보를 알 필요가 없다. TID는 DM 서버(20)로 다시 보내지는, 이러한 정보의 일부로서 포함됨이 바람직하다. (j) 단계에서 DM 서버는 TID 및 수신된 장치 정보를 작업 플로우 관리자(50)로 전송하고, (k) 단계에서 작업 흐름 관리자(50)가 백엔드 서비스들(60)과 교류하여 장치(10) 정보 세부사항의 양과 수준이 선택사항들의 리스트 (펌웨어 다운로드 옵션들의 메뉴)를 생성하기 충분한지 여부를 판단한다. 더 많은 세부적이고 특정한 장치(10) 정보가 필요하면, (l) 단계에서 작업 플로우 관리자(50)가 DM 서버(20)에 요청해 장치(10)로부터 관련 데이터를 가져오게 한다. 이 경우 (m) 단계에서, OMA DM 프로토콜을 이용해, DM 서버(20)가 추가 장치(10) 정보를 얻고 그것을 다시 작업 플로우 관리자(50)로 전송한다. (n) 단계에서 작업 플로우 관리자(50)는 이용가능한 선택사항들의 리스트, 즉, 최종 사용자(1)를 위한 펌웨어 다운로드 옵션들의 메뉴를 생성한다 (아니면 이것을 생성하기 위해 한 개 이상의 백엔드 서비스들(60)을 이용한다). (o) 단계에서 작업 플로우 관리자(50)는 펌웨어 다운로드 옵션들의 메뉴를 웹 사이트(30)로 전송하고, (p) 단계에서 웹 사이트(30)가 그 메뉴를 사용자(1)의 브라우저(10B)로 리턴하여, 제품들을 선택하거나 더 많은 (웹 형식의) 정보를 요청하게 할 수 있다. 이것은 (p) 단계에서 다음의 적어도 세 가지 기술들을 거쳐 행해질 수 있다: 앞서 대기 된 HTTP 요청; 웹 오브젝트에 대한 OMA DM exec; 또는 앞서 전송된 페이지 내 사용자 동작. (p) 단계에서 사용된 기술이 어느 것이든 그에 따라, HTTP 요청들과 응답들 (장치(10)를 통한 사용자(1)와 웹 사이트(30)의)과, 요청된 펌웨어 및 장치 관리의 궁극적 전송 (장치(10) 및 DM 서버(20))을 수반하는 부가적 웹 브라우징이 (q) 단계 및 (r) 단계에서 각각 일어난다. 어떠한 알맞은 기술과 메커니즘이라도 장치(10)로의 펌웨어의 실질적 다운로드에 사용될 수 있다는 것을 알아야 한다.

본 발명의 실시예들에 따라 웹 세션을 자동화된 DM 세션과 결합하는 양태는, HTTP 응답 메시지 (도 2의 메시지 (g)) 안에서 OMA DM 통지 메시지 전달을 수반한다. 도 6을 참조할 때, HTTP 응답 메시지는 일반적으로 Status Line (상태 라인) 필드(102), General Headers (일반 헤더들) 필드(104), Response Headers (응답 헤더들) 필드(106), Entity Headers (개체 헤더들) 필드(108), 캐리지 리턴/라인 피드 (CRLF)(109)로서 보이는 경계기호(delimiter)나 분리기(separator), 및 Message Body (메시지 본문) 필드(110)를 포함한다. 본 발명의 비한정적 실시예들에 대해 가장 중요한 것이 Content-Type (콘텐츠 타입) 필드(108A), Content-Length (콘텐츠 길이) 필드(108B) 및 Last-Modified (최근 변경) 필드(108C)를 포함하는 Entity Headers (개체 헤더들) 필드(108)이다. 특히 중요한 것은 상술한 소정 MIME-type을 운반하는 Content-Type 필드(108A)이다. 비한정적 예들로서, 일반적인 통지 발의형 세션 경보 메시지 (General Notification Initiated Session Alert message)에 대한 소정 MIME-type은 Content-type (108A):"application/vnd.syncml.notification"일 수 있고, Content-Type 코드는 0x44일 수 있다.

현재로서 바람직하지만 비한정적인, 도 6에 도시된 HTTP 응답 메시지의 구조에 대한 실시예에서, OMA DM 통지는 Message-Body 필드(110)를 통해 전달된다.

전형적 HTTP 응답 메시지 콘텐츠는 다음과 같을 수 있다:

전형적 실시예인 OMA DM 통지 메시지(120)의 필드들이 도 7에서 보여진다. 여기서,

필드 설명

digest (122) MD5 다이제스트 값

trigger-hdr (124)(다음 사항을 포함함):

version (124A) 장치 관리 버전

ui-mode (124B) 미지정/사용자-인터랙션

initiator (124C) 서버/사용자 주도 (클라이언트/서버)

future-use (124D) 추후 DM 사용을 위해 예비됨

sessionid (124E) 세션 식별자

length-identifier (124F) 서버 식별자 길이

server-identifier (124G) 서버 식별자

trigger body(126) 판매자-특정(vendor-specific)

DM Device Details (DM 장치 세부사항) 메시지 (도 2의 메시지 (i))에 대한 비한정적인 한 예가 이하에서 보여지고 있다 (다시, SyncML Device Management Protocol, 1.1.2 버전 (OMA-SyncML-DMProtocol-V1_1_2-20030612-C), 오픈 모바일 연맹, 2003년 6월 참조):

앞의 설명은 본 발명을 실행하기 위해 발명자들이 현재 숙고한 최선의 방법과 장치에 대한 충분하고도 정보력 있는 비한정적인 전형적 예들을 통해 주어졌다. 그러나, 이와 관련된 분야들의 당업자들이라면, 첨부된 도면들과 이하의 청구항들과 함께 상기 설명을 파악할 때, 변형과 조정이 이뤄질 수 있다는 것을 잘 알 수 있을 것이다. 일부 예들로서, 다른 유사 내지 등가적 다운로드 시나리오들, 어플 리케이션 프로그램 및 펌웨어 다운로드 기술들 (가령, 펌웨어 다운로드들은 OMA FOTA 기술 이외의 것을 사용할 수 있다), 메시징 타입들 및 장치 관리 프로토콜들과 방법들이 이 분야의 당업자에 의해 시도될 수도 있다. 그러나, 그러한 모든, 그리고 그와 유사한 본 발명의 개시사항에 대한 변형 역시 본 발명의 범위 안에 들어 올 것이다.

또, 본 발명의 일부 특징들은 다른 특징들의 상응하는 사용 없이도 바람직하게 활용될 수 있을 것이다. 따라서, 상술한 내용은 본 발명의 원리들을 단지 예시한 것으로 간주 될 뿐, 제한하고자 한 것이 아니어야 한다.

Claims

브라우징 세션 중에 장치로부터 소정 타입의 하이퍼텍스트 전송 프로토콜(hypertext transfer protocol; HTTP) 요청 메시지를 송신하는 단계;

장치 관리 세션이 개시된다는 것을 가리키는 전용 다목적 인터넷 메일 확장(multipurpose internet mail extensions; MIME) 타입을 포함하는 하이퍼텍스트 전송 프로토콜 응답 메시지를 수신하는 단계로서, 이때 장치 관리 세션은 하이퍼텍스트 전송 프로토콜 응답 메시지에 끼워넣어지는(embedded) 식별자에 의해 식별되는 단계;

하이퍼텍스트 전송 프로토콜 응답 메시지를 수신함에 반응하여, 장치 세부사항(details) 및 식별자를 구비한 장치 관리 세션 응답을 송신하는 단계;

장치 세부사항들과 호환가능한 적어도 한 개의 디지털 제품을 포함하는 리스트를 상기 장치에서 수신하는 단계; 및

사용자가 상기 리스트로부터 적어도 한 개의 디지털 제품을 선택한 데 반응하여, 장치 관리 세션 중에 상기 장치로 상기 선택된 적어도 한 개의 디지털 제품을 수신하는 단계를 포함함을 특징으로 하는 방법.
제1항에 있어서, 상기 하이퍼텍스트 전송 프로토콜 응답 메시지는 암호화된 클라이언트 공급 메시지를 포함함을 특징으로 하는 방법.
제2항에 있어서, 상기 소정 타입의 하이퍼텍스트 전송 프로토콜 요청 메시지는 상기 식별자를 설정하는 작업 플로우 (workflow) 관리자와의 트랜잭션을 일으키고, 상기 작업 플로우 관리자는 상기 클라이언트 공급 메시지를 생성하여 비밀 키를 사용해 상기 클라이언트 공급 메시지를 암호화함을 특징으로 하는 방법.
제1항에 있어서, 상기 리스트는 브라우징 세션을 이용하여 상기 장치에서 수신됨을 특징으로 하는 방법.
제1항에 있어서, 상기 장치는 웹 서버와 통신하도록 구성된 무선 트랜시버를 구비한 유닛을 포함하고, 상기 수신되는 디지털 제품은 어플리케이션 프로그램을 포함함을 특징으로 하는 방법.
제1항에 있어서, 상기 장치는 웹 서버와 통신하도록 구성된 무선 트랜시버를 구비한 유닛을 포함하고, 상기 수신되는 디지털 제품은 펌웨어를 포함함을 특징으로 하는 방법.
무선 링크를 통해 함께 연결되는 장치와 웹 서버를 구비하는 시스템에 있어서,

웹 서버와 연결되어 있고, 브라우징 세션 중에 장치로부터 송신되어지는 소정 타입의 하이퍼텍스트 전송 프로토콜(hypertext transfer protocol; HTTP) 요청 메시지에 응하여 그 장치로 하이퍼텍스트 전송 프로토콜 메시지를 송신하도록 구성되는 장치 관리 서버로서, 장치 관리 세션이 개시된다는 것을 가리키는 전용 다목적 인터넷 메일 확장(Multipurpose Internet Mail Extentions; MIME) 타입을 포함하는 하이퍼텍스트 전송 프로토콜 응답 메시지를 상기 장치로 전송하며, 이때 장치 관리 세션은 하이퍼텍스트 전송 프로토콜 응답 메시지에 끼워넣어지는(embedded) 식별자에 의해 식별되는, 장치 관리 서버를 포함하고,

상기 장치는, 장치 세부사항(details) 및 식별자를 구비한 장치 관리 세션 응답으로써 하이퍼텍스트 전송 프로토콜 응답 메시지에 답하도록 구성되는 장치 관리 클라이언트를 포함하고,

상기 장치 관리 서버는, 작업 플로우 관리자로 상기 장치 세부사항을 송신하고, 상기 장치 세부사항과 호환가능한 적어도 한 개의 디지털 제품을 포함하는 리스트를 수신하고 그리고 상기 리스트를 상기 장치로 전송하도록 더 구성되고,

상기 장치 관리 서버는, 사용자가 그 리스트로부터 적어도 한 개의 디지털 제품을 선택한 데 반응하여 장치 관리 세션 중에 상기 장치로, 상기 선택된 적어도 한 개의 디지털 제품을 전송하도록 구성됨을 특징으로 하는 시스템.
제7항에 있어서, 상기 하이퍼텍스트 전송 프로토콜 응답 메시지는 암호화된 클라이언트 공급 메시지를 포함함을 특징으로 하는 시스템.
제8항에 있어서, 상기 소정 타입의 하이퍼텍스트 전송 프로토콜 요청 메시지는 상기 식별자를 설정하는 작업 플로우 (workflow) 관리자와의 트랜잭션을 일으키고, 상기 작업 플로우 관리자는 상기 클라이언트 공급 메시지를 생성하여 비밀 키를 사용해 상기 클라이언트 공급 메시지를 암호화함을 특징으로 하는 시스템.
제9항에 있어서, 상기 작업 플로우 관리자는 적어도 한 백엔드(back-end) 시스템과의 인터페이스를 포함하고, 상기 클라이언트 공급 메시지는 적어도 한 백엔드 시스템을 이용하여 암호화됨을 특징으로 하는 시스템.
제7항에 있어서, 상기 리스트는 브라우징 세션과 하이퍼텍스트 전송 프로토콜(HTTP) 프로토콜들을 이용하여 장치로 전송됨을 특징으로 하는 시스템.
제7항에 있어서, 상기 장치는 웹 서버와 통신하도록 구성된 무선 트랜시버를 포함하고, 상기 전송되는 디지털 제품은 어플리케이션 프로그램을 포함함을 특징으로 하는 시스템.
제7항에 있어서, 상기 장치는 웹 서버와 통신하도록 구성된 무선 트랜시버를 포함하고, 상기 전송되는 디지털 제품은 펌웨어를 포함함을 특징으로 하는 시스템.
제7항에 있어서, 상기 장치는 웹 서버와 통신하도록 구성된 무선 트랜시버를 구비하는 통신 유닛을 포함하고, 상기 전송되는 디지털 제품은 프로그램을 포함함을 특징으로 하는 시스템.
무선 하이퍼텍스트 전송 프로토콜(hypertext transfer protocol; HTTP) 세션 중에, 장치로부터 디지털 제품에 관한 탐문(inquiry)을 수신하는 단계;

상기 탐문에 응하여, 보안 장치 관리 무선 세션을 개시하고, 장치의 적어도 하나의 사양을 기술하는 장치 고유 파라미터들을 획득하는 단계;

상기 적어도 하나의 사양인 장치 사양들과 호환되는 디지털 제품을 기술하는 적어도 한 엔트리를 포함하는 리스트를 송신하는 단계; 및

상기 장치와의 무선 하이퍼텍스트 전송 프로토콜 세션 중에, 상기 리스트로부터 적어도 한 엔트리가 선택된 것을 수신하는 단계를 포함함을 특징으로 하는 방법.
제15항에 있어서, 상기 보안 장치 관리 무선 세션은 장치 관리 세션이 시작될 것임을 나타내는 소정의 다목적 인터넷 메일 확장(Multipurpose Internet Mail Extentions; MIME) 타입을 포함하는 하이퍼텍스트 전송 프로토콜 응답 메시지를 이용하여 시작되고, 상기 장치 관리 세션은 하이퍼텍스트 전송 프로토콜 응답 메시지에 끼워넣어지는(embedded) 식별자에 의해 식별됨을 특징으로 하는 방법.
사용자 인터페이스 및 프로그램을 통해 작동하도록 구성된 제어기를 포함하는 장치에 있어서,

상기 프로그램은,

사용자 및 사용자 인터페이스를 개입시킨 무선 하이퍼텍스트 전송 프로토콜(hypertext transfer protocol; HTTP) 세션 중에, 장치로부터 적어도 하나의 디지털 제품에 관한 탐문(inquiry)을 전송하는 동작;

무선 네트워크를 통해 응답을 수신함에 응하여, 장치의 적어도 하나의 사양을 기술하는 장치 고유 파라미터들을 전송하도록 보안 장치 관리 세션을 설정하는 동작;

상기 적어도 하나의 사양인 장치 사양들과 호환되는 적어도 하나의 디지털 제품을 기술하는 적어도 한 엔트리를 포함하는 리스트를 수신하여 무선 하이퍼텍스트 전송 프로토콜 세션 중에, 상기 리스트로부터 적어도 한 엔트리를 사용자 인터페이스를 통해 선택하는 동작; 및

상기 리스트로부터 선택된 적어도 한 엔트리에 해당하는 적어도 하나의 디지털 제품을 수신하는 동작을 수행하도록 함을 특징으로 하는 장치.
제17항에 있어서, 상기 제어기는 보안 장치 관리 세션이 시작된다는 것을 나타내는 소정의 다목적 인터넷 메일 확장(multipurpose internet mail extensions; MIME) 타입을 포함하는 하이퍼텍스트 전송 프로토콜 응답 메시지를 수신하도록 구성되고, 상기 장치 관리 세션은 하이퍼텍스트 전송 프로토콜 응답 메시지에 끼워넣어지는(embedded) 식별자에 의해 식별됨을 특징으로 하는 장치.
기구(Apparatus)에 있어서,

장치에 연결되도록 구성된 제1인터페이스,

작업 플로우 관리자에 연결되도록 구성된 제2인터페이스, 및

프로그램을 사용해 동작하도록 구성된 제어기를 포함하고,

상기 프로그램은

제1 인터페이스를 통해 장치의 적어도 하나의 세부사항을 기술한 장치 고유 파라미터들을 얻는 동작;

제2인터페이스를 통해 작업 플로우 관리자로부터, 장치 사양들에 호환되는 적어도 하나의 디지털 제품을 기술한 적어도 한 엔트리를 포함한 리스트를 수신하는 동작;

그 리스트를 제1 인터페이스를 통해 장치로 전송하는 동작; 및

무선 하이퍼텍스트 전송 프로토콜(hypertext transfer protocol; HTTP) 세션 중에, 리스트로부터의 적어도 한 엔트리에 상응하는 정보를 장치로 업로드하는 동작을 수행하도록 함을 특징으로 하는 기구.
삭제
제19항에 있어서, 상기 기구는 장치 관리 프로토콜(device management protocol)과 호환됨을 특징으로 하는 기구.
기구(Apparatus)에 있어서,

웹 사이트를 통해 장치에 그리고 장치 관리 서버에 연결되도록 구성되는 제1인터페이스;

적어도 한 백엔드 시스템에 연결되도록 구성되는 제2인터페이스; 및

프로그램을 사용하여 동작하도록 구성되는 제어기를 포함하고,

상기 프로그램은

무선 하이퍼텍스트 전송 프로토콜(hypertext transfer protocol; HTTP) 세션 중에, 장치가 적어도 하나의 디지털 제품에 관하여 웹 사이트에 탐문(inquiry)하였다는 것을 가리키는 표시(indication)를 수신한 데 응하여, 장치의 적어도 하나의 세부사항을 기술하는 장치 고유 파라미터들을 얻기 위해 장치와 보안 장치 관리 무선 세션을 시작하는 동작;

제2인터페이스를 통해 적어도 한 백엔드 시스템을 이용하여 상기 장치의 적어도 하나의 세부사항에 기반하여, 장치 사양들에 호환되는 적어도 하나의 디지털 제품을 기술하는 적어도 한 엔트리를 포함하는 리스트를 생성하는 동작; 및

상기 리스트를 제1인터페이스 및 웹 서버를 거쳐 장치로 전송하는 동작을 수행하도록 함을 특징으로 하는 기구.
제22항에 있어서, 상기 기구는 트랜잭션 식별자 및 암호화된 클라이언트 공급 메시지를 생성하도록 구성됨을 특징으로 하는 기구.
제23항에 있어서, 상기 기구는 장치 고유 파라미터들 및 트랜잭션 식별자를 수신하도록 구성됨을 특징으로 하는 기구.
컴퓨터로 읽을 수 있는 프로그램을 포함하는 컴퓨터로 읽을 수 있는 기록 매체에 있어서,

상기 컴퓨터로 읽을 수 있는 프로그램은, 컴퓨터에 의해 실행되어 상기 컴퓨터로 하여금,

브라우징 세션 중에 소정 타입의 하이퍼텍스트 전송 프로토콜(hypertext transfer protocol; HTTP) 요청 메시지를 송신하는 동작,

장치 관리 세션이 개시된다는 것을 가리키는 전용 다목적 인터넷 메일 확장(multipurpose internet mail extensions; MIME) 타입을 포함하는 하이퍼텍스트 전송 프로토콜 응답 메시지를 수신하는 동작으로서, 이때 장치 관리 세션은 하이퍼텍스트 전송 프로토콜 응답 메시지에 끼워넣어지는(embedded) 식별자에 의해 식별되는, 동작;

장치 세부사항(details) 및 식별자를 구비한 장치 관리 세션 응답으로써 하이퍼텍스트 전송 프로토콜 응답 메시지에 답하는 동작;

상기 장치 세부사항과 호환가능한 적어도 한 개의 디지털 제품을 포함하는 리스트를 수신하는 동작;

상기 리스트로부터 적어도 한 개의 디지털 제품을 선택한 결과를 송신하는 동작; 및

장치 관리 세션 중에 상기 장치에서 상기 선택된 적어도 한 개의 디지털 제품을 수신하는 동작을 수행하게 하도록 구성되는, 컴퓨터로 읽을 수 있는 기록 매체.
제25항에 있어서, 상기 하이퍼텍스트 전송 프로토콜 응답 메시지는 암호화된 클라이언트 공급 메시지를 포함함을 특징으로 하는 컴퓨터로 읽을 수 있는 기록 매체.
삭제
제25항에 있어서, 상기 리스트는 브라우징 세션 중에 상기 장치에서 수신됨을 특징으로 하는 컴퓨터로 읽을 수 있는 기록 매체.
제25항에 있어서, 상기 수신되는 디지털 제품은 어플리케이션 프로그램을 포함함을 특징으로 하는 컴퓨터로 읽을 수 있는 기록 매체.
제25항에 있어서, 상기 수신되는 디지털 제품은 펌웨어를 포함함을 특징으로 하는 컴퓨터로 읽을 수 있는 기록 매체.