KR20040020124A

KR20040020124A - 무선통신 시스템에서 데이터 파일의 다운로드 방법 및 그기록매체

Info

Publication number: KR20040020124A
Application number: KR1020020051578A
Authority: KR
Inventors: 김굉태; 권오성; 이경헌
Original assignee: 주식회사 네오엠텔
Priority date: 2002-08-29
Filing date: 2002-08-29
Publication date: 2004-03-09

Abstract

본 발명은 무선통신 시스템에서 임의의 데이터 파일을 효과적이고 안전하게 다운로드하기 위한 방법 및 그 기록매체에 관한 것이다.

본 발명에 따르면, 무선통신 기능을 구비한 단말기에서 상기 단말기와 소정의 프로토콜에 따라 무선통신 연결될 수 있는 콘텐츠 서버로부터 데이터 파일을 다운로드받기 위한 방법에 있어서, 상기 단말기에 대한 사용자의 조작에 대응하여 상기 콘텐츠 서버로 상기 소정의 프로토콜에 따른 통신연결을 요구하는 메세지를 전송하는 제1 단계; 상기 통신연결의 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 다운로드 가능 아이템 및 상기 아이템에 대한 링크 메세지의 하나이상의 조합을 포함하는 디렉토리 페이지를 획득하여 상기 사용자에게 디스플레이하는 제2 단계; 상기 디스플레이된 화면 상에서 상기 사용자가 다운로드 가능 아이템을 선택하는 동작이 검출되면 상기 선택된 아이템에 링크된 메세지를 이용하여 상기 소정의 프로토콜에 따른 요구 메세지 코드를 획득하는 제3 단계; 상기 요구메세지 코드를 이용하여 상기 콘텐츠 서버로 상기 선택된 아이템에 대응하는 데이터 파일에 대한 다운로드를 요구하는 메세지를 전송하는 제4 단계; 상기 다운로드 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 제1 데이터 블록을 획득하는 제5 단계; 상기 제1 데이터 블록의 내용으로부터 상기 데이터 파일의 다운로드가 완료되었는지 여부를 판단하고, 상기 판단결과로부터 상기 데이터파일의 다운로드가 완료되지 않은 경우에는 상기 데이터 파일의 다운로드가 완료될 때까지 상기 데이터 파일의 다음 데이터 블록을 요구하는 메세지를 상기 콘텐츠 서버로 전송하는 제6a 단계, 상기 다음 데이터 블록의 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 상기 다음 데이터 블록을 획득하는 제6b 단계, 및 상기 다음 데이터 블록의 내용으로부터 상기 데이터 파일의 다운로드가 완료되었는지 여부를 판단하는 제6c 단계를 포함하는 과정을 반복하는 제6 단계; 및 상기 제5 단계와 제6 단계에서 수신된 하나이상의 데이터 블록으로부터 상기 데이터 파일을 구성하는 제7 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법, 및 그 방법을 구현하기 위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록매체가 제시된다.

본 발명의 데이터 파일의 다운로드 방법에 따르면 무선통신 시스템에서 데이터 파일을 효과적이고 안전하게 다운로드할 수 있는 장점이 있다.

Description

무선통신 시스템에서 데이터 파일의 다운로드 방법 및 그 기록매체{Method for downloading data files in wireless communication system, and the storage media thereof}

종래로 휴대폰이나 무선호출기, 또는 개인휴대단말(PDA) 등을 이용하여 인터넷 액세스나 전자우편 송수신, 또는 메세지 송수신 등과 같은 무선통신 서비스를 활용하여 왔다. 이러한 무선통신 서비스를 가능하도록 하기 위해서는 통상의 인터넷 브라우징과 마찬가지로 각종 데이터 파일을 서버 시스템에서 무선 단말기로 다운로드하여 저장하는 작업이 필수적이다.

이를 위해, 종래로 WAP (Wireless Application Protocol)을 비롯한 여러 프로토콜이 제안되었으나, 이러한 종래의 프로토콜은 텍스트 형태의 정보를 무선통신망을 통해 전달한다는 용도에 맞추어 설계되어 있으므로 이미지 파일이나 멜로디파일 등과 같이 구체적인 응용에서 사용되는 임의의 데이터 파일을 특정의 단말기로 다운로드하는 것에 있어서는 적합하지 않다. 따라서, 무선통신 시스템에서 임의의 데이터 파일을 다운로드함에 있어서 효과적이고도 안전하게 사용할 수 있는 구체적인 방법이 요구된다.

이에, 본 발명은 무선통신 시스템에서 임의의 데이터 파일을 효과적이고 안전하게 다운로드하기 위한 방법, 및 그 방법을 구현하기 위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록매체를 제공하는 데에 그 목적이 있다.

도1은 종래기술에 따른 무선통신 시스템의 아키텍쳐를 도시한 도면.

도2는 종래기술에 따른 무선통신 시스템의 아키텍쳐에서 각 구성부분 간의 관계를 도시한 도면.

도3은 무선통신 시스템의 아키텍쳐에서 사용하는 MIME 타입의 예를 도시한 도면.

도4는 본 발명에 따른 무선통신 시스템에서 마이크로브라우저가 콘텐츠 서버로 연결하여 데이터 파일을 다운로드받는 과정의 일 실시예를 개념적으로 도시한 도면.

도5는 본 발명에 따른 무선통신 시스템에서 WML 데크의 일 실시예를 도시한 도면.

도6은 본 발명에 따른 무선통신 시스템에서 HTTP 응답 메세지와 데이터 블록, 그리고 다운로드 데이터의 상호관계의 실시예를 도시한 도면.

도7은 도6에 도시된 데이터 블록의 필드 포맷(field format)의 일 실시예를도시한 도면.

도8은 도7에 도시된 필드 포맷의 실시예에 따라 데이터 블록을 파싱한 결과를 나타낸 도면.

도9는 도4에 도시된 데이터 파일의 다운로드 과정에서 도7에 도시된 데이터 블록의 필드가 갖는 값의 예를 도시하는 도면.

도10은 무선통신 시스템에서 데이터 파일이 콘텐츠 서버로부터 WAP 게이트웨이를 거쳐 WAP 응용 단말기로 다운로드되는 네트워크 토폴로지 및 WAP 게이트웨이의 최대 PDU를 표시하는 도면.

도11은 본 발명에 따른 무선통신 시스템에서 마이크로브라우저로 전달되는 WML 데크의 다른 실시예를 도시한 도면.

도12는 본 발명에 따른 무선통신 시스템에서 마이크로브라우저가 콘텐츠 서버로 연결하여 데이터 파일을 다운로드받는 과정에 있어서 실제의 최대 PDU 값에 기초하여 다운로드 과정을 최적화하는 일 실시예를 개념적으로 도시한 도면.

도13은 본 발명에 따른 무선통신 시스템에서 마이크로브라우저가 콘텐츠 서버로 연결하여 데이터 파일을 다운로드받는 과정에 있어서 실제의 최대 PDU 값에 기초하여 다운로드 과정을 최적화하는 다른 실시예를 개념적으로 도시한 도면.

<도면의 주요 부분에 대한 부호의 설명>

650: 데이터 블록

660: 블록 헤더

670: 페이로드

1010: WAP 응용 단말기

1030: WAP 게이트웨이

1040: 콘텐츠 서버

1050: 베어러

1060: 인터넷망

전술한 바와 같은 본 발명의 목적을 달성하기 위해서, 본 발명은 무선통신 기능을 구비한 단말기에서 상기 단말기와 소정의 프로토콜에 따라 무선통신 연결될 수 있는 콘텐츠 서버로부터 데이터 파일을 다운로드받기 위한 방법에 있어서, 상기 단말기에 대한 사용자의 조작에 대응하여 상기 콘텐츠 서버로 상기 소정의 프로토콜에 따른 통신연결을 요구하는 메세지를 전송하는 제1 단계; 상기 통신연결의 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 다운로드 가능 아이템 및 상기 아이템에 대한 링크 메세지의 하나이상의 조합을 포함하는 디렉토리 페이지를 획득하여 상기 사용자에게 디스플레이하는 제2 단계; 상기 디스플레이된 화면 상에서 상기 사용자가 다운로드 가능 아이템을 선택하는 동작이 검출되면 상기 선택된 아이템에 링크된 메세지를 이용하여 상기 소정의 프로토콜에 따른 요구 메세지 코드를 획득하는 제3 단계; 상기 요구메세지 코드를 이용하여 상기 콘텐츠 서버로 상기 선택된 아이템에 대응하는 데이터 파일에 대한 다운로드를 요구하는 메세지를 전송하는 제4 단계; 상기 다운로드 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 제1 데이터 블록을 획득하는 제5 단계; 상기 제1 데이터 블록의 내용으로부터 상기 데이터 파일의 다운로드가 완료되었는지 여부를 판단하고, 상기 판단결과로부터 상기 데이터 파일의 다운로드가 완료되지 않은 경우에는 상기 데이터 파일의 다운로드가 완료될 때까지 상기 데이터 파일의 다음 데이터 블록을 요구하는 메세지를 상기 콘텐츠 서버로 전송하는 제6a 단계, 상기 다음 데이터 블록의 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 상기 다음 데이터 블록을 획득하는 제6b 단계, 및 상기 다음 데이터 블록의 내용으로부터 상기 데이터 파일의 다운로드가 완료되었는지 여부를 판단하는 제6c 단계를 포함하는 과정을 반복하는 제6 단계; 및 상기 제5 단계와 제6 단계에서 수신된 하나이상의 데이터 블록으로부터 상기 데이터 파일을 구성하는 제7 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법, 및 이 방법을 구현하기 위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록매체를 제공한다.

이하, 첨부된 도면을 참조하여 본 발명을 상세히 설명한다.

도1은 종래기술에 따른 무선통신 시스템의 아키텍쳐로서 WAP 프로토콜에서제안하는 구성을 도시한 도면이다. 도1에서 WAP 응용 단말기(110)는 일반적으로 콘텐츠 제공자(contents provider : CP)가 제공하는 콘텐츠들의 브라우징을 지원하는 소프트웨어로서 마이크로브라우저(micro browser: 120)를 내장한다. 현재 WML (Wireless Markup Language) 기반의 브라우저, 예컨대 Unwired Planet사의 UP 브라우저(UP.Browser)가 마이크로브라우저(120)의 주류를 이루고 있지만, 그 외에도 미국 마이크로소프트 사의 ME 브라우저(Mobile Explorer browser)나 일본 NTT 토코모 사의 i-모드 브라우저(i-mode browser) 등도 존재한다.

콘텐츠 서버(contents server: 140)는 통상 CP 서버라고도 불리는데, 사용자가 이용하는 무선 인터넷 서비스의 목적물인 콘텐츠를 WAP 응용 단말기(110) 또는 마이크로브라우저(120)가 인식할 수 있도록 WML 데크(deck) 형태로 제공하는 역할을 담당한다. 콘텐츠 서버(140)로는 종래로 아파치(Apache) 또는 IIS 등의 일반적인 웹서버를 이용하고, 서비스는 종래로 WML과 서버사이드 스크립트(server-side script)를 이용해서 개발된다.

WAP 게이트웨이(130)는 WAP 기반 무선인터넷을 구성하는 핵심요소로서, 그 기본 기능은 WSP (Wireless Session Protocol)와 HTTP (HyperText Transfer Protocol) 간에 프로토콜 변환을 수행하는 기능과 WML 콘텐츠를 인코딩/디코딩하는 기능이다. 이하, WAP 게이트웨이(130)의 프로토콜 변환 기능 및 인코딩/디코딩 기능에 대해서 보다 상세히 설명한다.

콘텐츠 서버(140)와 WAP 게이트웨이(130)는 통상의 인터넷망으로 연결되어 HTTP 프로토콜을 통해 통신이 이루어지는데, 구체적으로는 이 HTTP 프로토콜을 이용하여 요구(HTTP request)와 응답(HTTP response)이 텍스트 형식으로 전달된다. 이러한 HTTP 프로토콜은 콘텐츠 서버(140)와 WAP 게이트웨이(130)를 연결하는 통상의 인터넷망에서는 적절하지만, WAP 응용 단말기(110)와 WAP 게이트웨이(130)를 연결하는 무선 인터넷망은 그 속성상 대역폭(bandwidth)이 좁고 시간지연(latency)이 길기 때문에 HTTP 프로토콜이 적합하지 않다. 이에, 무선 인터넷망에서는 이러한 특성에 최적화된 WSP 프로토콜이 대신 사용되는데, 이 WSP 프로토콜에서는 모든 정보가 바이너리(binary) 형식으로 전달된다.

따라서, 도시된 바와 같이 통상의 인터넷망과 무선 인터넷망을 매개하는 WAP 게이트웨이(130)는 HTTP 프로토콜과 WSP 프로토콜 사이에서 프로토콜 변환을 수행하여야 하며, 텍스트 형식의 WML 파일과 바이너리 형식의 WBXML 파일 사이에서 형식 변환을 수행하여야 한다. 이를 위해, WAP 게이트웨이(130)는 통상적으로 WML의 태그(tag)나 속성(attribute) 등에 대응하는 바이너리 값들을 토큰 테이블(token table)의 형태로 보유하는데, 이 토큰 테이블을 참조하여 WAP 게이트웨이(130)가 텍스트 형식의 WML 파일을 바이너리 형식으로 변환하는 과정을 인코딩(encoding) 또는 토큰화(tokenization) 과정이라고 하고, 역의 과정을 디코딩(decoding)이라고 한다.

도시되어 있지는 않으나, WAP 게이트웨이(130)는 전술한 프로토콜 변화 기능 및 인코딩/디코딩 기능 이외에도 접근제어(access control) 기능, 보안(security) 기능, 그리고 WML 스크립트 컴파일링 기능 등을 수행한다.

또한, 베어러(150)는 WAP 게이트웨이(130)와 WAP 응용 단말기(110)를 연결하는 무선 통신망 또는 무선 전송방식을 의미하는데, 본 특허출원의 최초의 출원시점에서 대한민국에서 사용하는 이동통신 방식인 CDMA (Code Division Multiple Access)나 유럽에서 사용하는 이동통신 방식인 GSM (Global System for Mobile communication) 등은 전술한 베어러(150)의 일종으로 볼 수 있다. 또한, 보다 다른 차원에서 베어러(150)를 정의할 수 있는데, 예컨대 CSD (Circuit Switched Data)나 PSD (Packet Switched Data), 또는 SMS (Short Message Service) 등도 베어러(150)의 일종으로 볼 수 있다.

도2는 도1에 도시된 통상의 WAP 프로토콜에 따른 아키텍쳐에서 WAP 응용 단말기(210), 마이크로브라우저(220), WAP 게이트웨이(230), 콘텐츠 서버(240) 간의 관계 및 상호작용을 도시한 도면이다.

도2에서 마이크로브라우저(220)와 콘텐츠 서버(240)는 일종의 WSP/HTTP 연결을 이루고 있는데, 이 때 마이크로브라우저(220)는 콘텐츠 서버(240)에 대해서 WSP 프로토콜에 따라서 WML 파일 등의 콘텐츠 객체(contents object)를 요구하고(WSP request), 이에 대해서 콘텐츠 서버(240)는 HTTP 프로토콜에 따라서 적절한 응답을 마이크로브라우저(220)로 되돌린다(HTTP response). 전술한 WSP 프로토콜과 HTTP 프로토콜의 요구/응답에 대해서는 WAP 포럼의 WSP 규격, 즉 Wireless Session Protocol Specification Approved Version 5-July-2001, 및 IETF의 HTTP 규격, 즉 RFC (Request For Comments) 1945 또는 RFC 2068을 참조한다.

전술한 바와 같이, WAP 게이트웨이(230)는 마이크로브라우저(220)와 콘텐츠 서버(240) 사이에서 WSP/HTTP 프로토콜 변환 작업 및 인코딩/디코딩 작업을 수행한다. 먼저, WAP 게이트웨이(230)의 WSP/HTTP 프로토콜 변환 작업에 의해서 마이크로브라우저(220)의 WSP 프로토콜 동작(WSP 요구/응답)과 콘텐츠 서버(240)의 HTTP 프로토콜 동작(HTTP 요구/응답)이 상호 운영성(inter-operability)을 갖게 된다. 또한, WAP 게이트웨이(230)의 인코딩/디코딩 작업에 의해서 WML 파일은 HTTP 프로토콜을 위한 텍스트 형식과 WSP 프로토콜을 위한 바이너리 형식 사이에서 변환이 이루어진다. 바이너리 형식의 파일을 통상 WBXML (WAP Binary eXtensible Markup Language)로 표시하는데, WBXML에 대해서는 WAP 포럼의 WBXML 규격, 즉 Binary XML Content Format Specification Version 1.3, 25-July-2001을 참조한다.

한편, WSP 또는 HTTP 프로토콜에 따르면 콘텐츠 객체를 전달함에 있어서 그 객체의 종류를 나타내기 위해 헤더(header) 부분에 도3에 도시한 바와 같은 MIME (Multipurpose Internet Mail Extension) 타입을 사용한다. 도3(a)는 통상의 인터넷 브라우징을 위해 사용하는 전형적인 MIME 타입의 예를 도시하는 도면이다. 또한, 구체적인 응용 분야에 따라서 필요한 만큼 MIME 타입을 더 정의하여 사용할 수 있는데, 도3(b)는 본 발명의 최초의 출원시점에서 무선통신의 멀티미디어 응용을 위해 사용되는 MIME 타입의 예를 도시한다. 참고의 목적을 위해, 도3에서 사용된 약자의 원문은 다음과 같다: HTML (HyperText Markup Language), WBMP (Wireless BitMaP), WMLC (WML Compiler).

마지막으로, 마이크로브라우저(220)는 전달받은 콘텐츠를 저장하거나 디스플레이하는 등과 같은 소정의 기기제어 동작을 위해서 WAP 응용 단말기(210)의 내부함수(internal device function)를 호출하고, WAP 응용 단말기(210)는 그 내부함수의 수행 결과를 마이크로브라우저(220)로 되돌린다. 여기에서, 내부함수의 수행 결과를 되돌리는 방법은 여러가지가 가능한데, 함수의 리턴값으로 되돌리는 방식도 가능하고 또한 포인터 등으로 지정된 소정의 메모리 공간에 수행 결과를 작성하는 방식도 가능하다.

본 발명은 도1 및 도2에 도시된 무선통신 시스템에서 마이크로브라우저(120, 220)가 WAP 게이트웨이(130, 230)를 통해 콘텐츠 서버(140, 240)로부터 임의의 데이터 파일을 다운로드 받는 부분과 관련하여 효과적이고 안정적인 방법을 제안하고자 한다. 다만, 본 발명의 권리범위 해석에 있어서 도1 및 도2와 관련하여 사용된 구체적인 명칭 및 기술에 구애받지 않는 것으로 해석되어야 한다.

도4는 본 발명에 따른 무선통신 시스템에서 마이크로브라우저(420)가 콘텐츠 서버(440)로 연결하여 데이터 파일을 다운로드받는 과정의 일 실시예를 개념적으로 도시한 도면이다. 도4에서 WAP 게이트웨이는 도시가 생략되었는데, 이는 WAP 게이트웨이의 기본 기능이 도1 내지 도3를 참조하여 설명된 바와 같이 WSP/HTTP 프로토콜 변환 및 WML 인코딩/디코딩이므로 생략하더라도 데이터 다운로드의 개념적인 설명이 가능하기 때문이다. 이에, 도4에서는 모든 트랜젝션(transaction)이 마이크로브라우저(420)와 콘텐츠 서버(440) 사이에서 직접 일어나는 것처럼 도시되어 있다. 다만, 그 구체적인 동작에 있어서는 WAP 게이트웨이가 개입되어 전술한 동작을 수행하는 것으로 이해되어야 한다.

먼저, 마이크로브라우저(420)가 예컨대 단말기 사용자의 조작에 의해서 콘텐츠 서버(440)로 연결을 요구한다. (단계 4-1) 이 연결은 상위 애플리케이션에서정의하는 방식을 따르는데, 예컨대 특정 무선통신 사업자가 관리하는 무선 인터넷 서비스인 경우에는 이 사업자가 전술한 연결의 방식 및 요구/응답 프로토콜 등을 정의한다. 바람직한 실시예로서, 전술한 목적을 위해서 통상의 HTTP 연결 및 HTTP 요구/응답이 사용될 수 있다.

이 연결 요구에 대해서 콘텐츠 서버(440)는 WML 데크(410)를 마이크로브라우저(420)로 전송한다. (단계 4-2) WML에 있어서 데크(Deck)는 하나 또는 그 이상의 카드(Card)의 집합으로 정의되는데, 카드는 사용자와 단말기 사이에서 이루어지는 하나 또는 그 이상의 대화, 예컨대 메뉴에서 특정 아이템을 선택하거나 혹은 텍스트를 입력하는 것과 같은 동작으로 정의된다. 즉, WML 데크는 하나의 HTML 페이지와 등가의 것으로서 이해되고 사용되며, 이에 본 발명의 기술분야에서는 통상 WML 데크와 WML 페이지라는 용어가 혼용될 수 있다.

콘텐츠 서버(440)가 마이크로브라우저(420)로 전송하는 WML 데크(410)는 일반적으로 콘텐츠 서버(440)가 다운로드 서비스를 제공할 수 있는 각종 아이템들에 대한 디렉토리(directory)를 포함하는데, 이러한 각종 아이템에 대해서 WAP 응용 단말기의 내부함수(local function)를 호출하여 해당 데이터 파일의 다운로드가 기동(activate)되도록 할 수 있는 링크(link)가 제공된다. 즉, 사용자가 마이크로브라우저(420) 상에서 조작을 통해 특정 아이템을 선택하면 마이크로브라우저(420)가 소정의 단말기 내부함수를 호출하면서 이 선택된 아이템에 링크되어 있는 내용의 전부 또는 일부를 파라미터로 전달하면, 본 단말기에서 전술한 선택된 아이템에 대응하는 데이터 파일에 대한 다운로드 동작이 기동되게 된다. 전술한 링크는 통상메세지 형식으로 구성되며, 데이터 파일에 대한 구체적인 다운로드 동작에 대해서는 후술한다.

마이크로브라우저(420)에서 WAP 응용 단말기의 내부 기능을 기동하는 방법은 다양하게 구현할 수 있는데, 본 명세서에서는 마이크로브라우저(420)를 위해 단말기가 제공하는 소정의 확장 API (Application Programming Interface) 함수에 URL (Uniform Resource Locator) 형식의 캐릭터 스트링(character string)을 전달함으로써 달성하고자 한다. 예를 들어, 데이터 파일의 다운로드 기능을 기동시키기 위해 사용하는 확장 API 함수가 "sysLocalFunction1(char *URL, char *buf, .....)"이라고 가정하면 브라우저(420)가 이 API 함수를 호출하면서 소정 포맷, 예컨대 "device:data/download?url=<DownUrl>&filename=<FileName>&filesize=<FileSize>"와 같은 형식의 캐릭터 스트링을 URL 파라미터로서 전달하는 것이다. 이 확장 API 함수에서는 이 URL 파라미터를 파싱(parsing)함으로써 현재 마이크로브라우저(420)의 요구를 해석하고 이에 따라 소정의 동작을 수행한다.

전술한 확장 API 함수 "sysLocalFunction1(char *URL, char *buf, .....)"은 WAP 응용 단말기의 미들웨어(middleware) 또는 펌웨어(firmware), 또는 운영체제가 마이크로브라우저(420)를 위해 미리 정해진 바에 따라 제공하는 것으로서, 마이크로브라우저(420)는 이 확장 API 함수를 통해서 WAP 응용 단말기에 대해서 소망하는 명령을 내릴 수 있다.

이와 같이 확장 API 함수를 이용하여 내부 기능을 기동시키는 방법을 보다 상세히 설명하기 위하여 다른 예를 들면, 예컨대 자바 애플릿(JAVA applet)을 처리하기 위해 자바 가상머신(JAVA virtual machine)을 기동시키고자 하는 경우라면 마이크로브라우저(420)는 이 확장 API 함수를 호출하면서 소정의 캐릭터 스트링, 예컨대 "device:java_vm?filename=<FileName>&......"을 URL 파라미터로서 사용할 수 있다.

도5는 도4에서 콘텐츠 서버(440)가 마이크로브라우저(420)로 전송하는 WML 데크(410)의 코드의 실시예를 도시한 것이다. 이 실시예는 통상의 WML 데크와 마찬가지로 XML 규격의 형식을 따르고 WML에 의해 작성되었는데, 이 WML 데크에 의하면 WAP 응용 단말기의 마이크로브라우저(420) 화면 상에는 "MyPhone"과 "ZZanggu"라고 하는 두 가지 다운로드가능 아이템으로 구성된 메뉴가 나타난다.

이 때, 사용자가 "MyPhone"이라는 아이템을 선택하면 WAP 응용 단말기의 다운로드 내부함수가 호출되면서 그 파라미터로서 "http://download_url"이라는 다운로드 URL과 "myphone.sis"라는 파일이름, 1800 바이트의 파일크기 정보, 그리고 "0"이라는 저장타입이 전달된다. 반면, 사용자가 "ZZanggu"라는 아이템을 선택하면 단말기의 내부함수가 호출되면서 그 파라미터로서 "http://download_url"이라는 다운로드 URL과 "zzanggu.sis"라는 파일이름, 3300 바이트의 파일크기 정보, 그리고 "1"이라는 저장타입이 전달된다. 여기서, 저장타입(savetype)은 WAP 응용 단말기가 이 데이터를 다운로드받아 저장한 후 어떠한 용도로 사용할 것인지를 지정하는 파라미터로서, 예컨데 "0"은 단말기 디스플레이의 대기화면을 위한 용도이고 "1"은 핸드폰의 경우 전화가 왔을 때 화면에 나타나는 이미지 또는 동영상으로 사용하는 용도인 것과 같이 설정할 수 있다.

도5에 도시된 WML 코드는 도4에서 최상위 레이어(top layer)에 해당하는 WML 데크(410)에 한정되는 것으로 해석되어서는 안되며, WML 데크(410)를 구성하는 임의의 카드에서 도5에 도시된 바와 같은 WML 코드가 나타날 수 있다. 즉, 데이터 파일을 다운로드하는 아이템을 포함하는 메뉴는 임의의 카드에서 나타날 수 있는 것으로 해석된다. 다만, 해당 레이어에 따라서 WML 코드의 일부분이 적절히 변경될 수는 있으나 이는 충분히 예상가능한 것이다.

도4에 있어서, 도5에 도시된 바와 같은 WML 코드에 의해 구성된 메뉴 상에서 사용자가 소정의 단말기 조작을 통해 "device:data/download?url=......"가 링크된 메뉴 아이템을 선택하면 전술한 바와 같이 마이크로브라우저(420)가 WAP 응용 단말기의 내부함수를 기동하면서 선택된 메뉴 아이템에 링크되어 있는 메세지의 전부 혹은 일부를 전달(단계 4-3)한다. 단말기의 하위 소프트웨어는 전달된 메세지에 포함된 정보를 이용하여 소정의 WBXML 코드를 생성하여 마이크로브라우저(420)로 반환(단계 4-3)하고, 마이크로브라우저(420)가 이 WBXML 코드를 사용하여 콘텐츠 서버(440)에 대해서 데이터 파일에 대한 요구를 수행(단계 4-4)함으로써 본 발명에 따른 데이터 파일의 다운로드가 개시된다.

본 명세서에서는 발명의 실시예로서 마이크로브라우저(420)가 도1 내지 도3을 참조하여 전술한 바와 같이 통상의 WSP/HTTP 프로토콜에 기초하여 데이터 파일을 다운로드하는 것으로 가정하고 기술한다. 즉, 마이크로브라우저(420)는 WSP/HTTP 요구를 사용하여 콘텐츠 서버(440)로 데이터 파일의 다운로드를 요구(단계 4-4)하고, 콘텐츠 서버(440)는 이에 응답하여 WSP/HTTP 응답을 사용하여 데이터파일을 전송(단계 4-5)한다. 도3을 참조하여 전술한 바와 같이 데이터 파일의 전송에 있어서 파일의 종류를 나타내기 위해서 종래로 MIME 타입을 사용하는데, 예컨대 다운로드할 콘텐츠 객체가 특별한 형식을 갖는 경우 "application/x-up-download"와 같은 MIME 타입이 사용될 수 있다.

단계(4-4)에 있어서, 마이크로브라우저(420)는 WSP 프로토콜에 따른 WSP 요구 메세지를 전송하는데, 이 WSP 요구 메세지는 전술한 바와 같이 통상 바이너리 형식의 WBXML 코드이다. 본 실시예에서는 단계(4-4)에서 사용하는 WBXML 코드는 이전 단계, 즉 단계(4-3)에서 확장 API 함수 "sysLocalFunction1(char *URL, char *buf, .....)"의 결과물로서 얻어지는 것으로 다룬다. 즉, 마이크로브라우저(420)가 이 확장 API 함수를 호출하여 소정의 동작을 수행하고 나면 전달 파라미터 *buf로 표시되는 캐릭터 배열(character array) 내에 다음 단계, 즉 단계(4-4)에서 사용할 WBXML 코드가 채워지는 것이다. 다만, 본 발명의 방법에서 단계(4-4)에서 사용할 WBXML 코드를 얻는 방법은 다양하게 구현될 수 있으며, 전술한 실시예에 한정되는 것은 아니라고 이해되어야 한다.

전술한 WBXML 코드에 포함되는 내용은 마이크로브라우저(420)와 콘텐츠 서버(440) 간에 다양하게 규정하여 사용할 수 있으나, 본 명세서에서는 해당 데이터 파일의 URL과 데이터 파일 내의 오프셋, 그리고 요구하는 데이터 바이트 갯수 등이 포함되는 것으로 가정한다. 여기에서 데이터 파일 내의 오프셋 정보와 요구하는 데이터 바이트 갯수가 포함되는 것은 후술하는 바와 같이 하나의 데이터 파일이 여러 번의 요구/응답 과정을 통해서 전달될 수 있기 때문이다.

마이크로브라우저(420)와 콘텐츠 서버(440)를 연결하는 네트워크의 종류 및 구체적인 구성 상태에 따라서는 데이터 파일이 1회의 WSP/HTTP 요구/응답 과정에 의해 모두 전달되지 못하고 복수 개의 데이터 세그먼트(data segment)로 분할되어 수 회에 걸친 WSP/HTTP 요구/응답 과정에 의해 전달될 수도 있다. (단계 4-6) 예컨대, 무선통신 시스템을 구성하는 구성요소인 WAP 게이트웨이가 1회의 트랜젝션에서 처리할 수 있는 데이터의 양에는 소위 최대 PDU (maximum Payload Data Unit)라고 부르는 일정한 한계가 존재하는데, 데이터 파일의 크기가 이 최대 PDU보다 큰 경우에는 전술한 바와 같은 수 회에 걸친 일련의 WSP/HTTP 요구/응답 과정이 필요하게 된다.

이 과정에서 WAP 응용 단말기가 마이크로브라우저(420)를 위해 제공하는 다른 확장 API 함수, 예컨대 "sysLocalFunction2(char *URL, char *data ......)"가 유용하게 사용될 수 있다. 본 명세서의 실시예에서 이 함수는 브라우저(420)가 독자적으로 처리할 수 없는 데이터에 대해서 WAP 응용 단말기로 대신 처리를 요청하는 함수인데, 데이터 파일의 다운로드에 있어서 1회의 WSP/HTTP 요구/응답 과정(단계 4-4, 4-5)이 수행되면 마이크로브라우저(420)는 전달받은 데이터 내용물을 이 확장 API 함수를 통해서 WAP 응용 단말기의 미들웨어 또는 펌웨어로 전달하여 콘텐츠 데이터의 처리를 의뢰한다. 이 함수는 통상적으로 WSP/HTTP 응답 과정(단계 4-5, 4-6)에서 얻은 데이터를 검사하여 더이상의 데이터 다운로드 과정이 필요한지 여부를 판단한다.

전술한 확장 API 함수 "sysLocalFunction2(......)"가 최초의 WSP/HTTP요구/응답 과정(단계 4-4, 4-5)에 의해 데이터 파일의 다운로드가 완료되었다고 판단하면 그대로 데이터 파일의 다운로드가 종료할 것이지만, 그렇지 않은 경우에는 WAP 응용 단말기는 다음의 WSP/HTTP 요구/응답 과정(단계 4-6)을 준비한다. 이를 위해서는 전술한 확장 API 함수 "sysLocalFunction1(......)"이 유용하게 사용되는데, 마이크로브라우저(420)는 이 API 함수를 호출함으로써 데이터 파일의 다운로드 과정의 완료여부 및 오류발생 여부를 파악하고 또한 다음 WSP/HTTP 요구에서 사용할 WBXML 코드를 얻는다. 이와 같이 복수의 WSP/HTTP 요구/응답 과정(단계 4-4 내지 4-6)이 필요할 수 있기 때문에, "sysLocalFunction1(......)" 함수가 제공하는 WBXML 코드는 전술한 바와 같이 금번의 WSP/HTTP 요구/응답 과정에서 요구하는 데이터에 있어서 데이터 파일 내의 오프셋 정보와 요구하는 데이터 바이트 갯수에 대한 정보를 포함하는 것이 바람직하다.

도4에 도시되어 있지는 않으나, 본 발명에 따른 WAP 응용 단말기를 구현함에 있어서 필요한 사항들이 추가적으로 필요할 수 있다. 예를 들어, 사용자가 소정의 단말기 조작을 통해서 특정의 메뉴 아이템을 선택하고 이에 따라 데이터 파일의 다운로드가 개시된 후에, 사용자는 다운로드가 완료되기 전에는 언제라도 자신의 선택을 취소할 수 있고 이에 대응하여 마이크로브라우저(420)와 콘텐츠 서버(440)와의 연결은 끊어질 수 있다. 또한, 현실적으로 네트워크는 완전하지 못하므로 데이터 파일의 다운로드 도중에 마이크로브라우저(420)와 콘텐츠 서버(440)와의 네트워크 연결이 언제라도 끊어질 수 있다. 따라서, 본 발명에 따른 데이터 파일의 다운로드 동작을 보다 신뢰할 수 있도록 하기 위해서는 본 발명에 따른 WAP 응용 단말기는 다운로드 도중에 사용자의 키입력 등에 의해 다운로드가 취소되었는지 여부 또는 네트워크 문제로 마이크로브라우저(420)와 콘텐츠 서버(440) 간의 연결이 끊어졌는지 여부를 체크하여 그 결과를 반영하여야 한다.

마이크로브라우저(420)는 데이터 파일의 다운로드 과정이 완료되면 선택적으로 콘텐츠 서버(440)에 대해서 데이터 파일의 다운로드가 성공하였는지 여부를 알릴 수 있다. 이와 같이 다운로드의 성공 여부를 알리는 방법은 다양하게 구현 가능하나, 본 명세서에서는 실시예로서 도4의 단계(4-7)에 도시된 바와 같이 데이터 다운로드 이후의 WSP/HTTP 요구에서 성공 여부에 대한 정보를 제공하도록 하였다. 이를 위해, WSP/HTTP 요구(단계 4-7)의 소정의 부분, 예컨대 URL 스트링의 일부분에 이에 대응하는 내용을 포함시킬 수 있다.

이와 같이 데이터 파일의 다운로드가 성공하였는지 여부를 콘텐츠 서버(440)로 알려주는 것은 본 발명의 기술분야인 무선통신 시스템에서는 상당히 중요한 기능을 가질 수 있다. 즉, 무선인터넷 서비스 등에서는 수익모델의 하나로서 데이터 파일의 다운로드에 대해서 사용자에게 과금(billing)을 하는데, 데이터 파일의 다운로드가 성공하였는지 여부를 확인하지 않고 과금을 하는 경우에는 분쟁이 일어날 소지가 있다. 따라서, 전술한 바와 같은 다운로드 성공여부를 확인할 수 있는 메커니즘이 있다면 안전한 과금이 가능하다.

전술한 WSP/HTTP 요구(단계 4-7)에 대한 응답(단계 4-8)에 있어서 콘텐츠 서버(440)는 다음 메뉴에 대한 WML 데크를 마이크로브라우저(420)로 전송한다. 이 WML 데크는 통상의 WML 파일에 해당할 것이므로 MIME 타입은 도시된 바와 같이"text/vnd.wap.wml"일 것으로 예상된다.

한편, 마이크로브라우저(420)는 특정의 데이터 파일을 다운로드할 때 그 데이터 파일의 전체 크기(size)에 대한 정보를 가지고 있는 것이 여러가지 면에서 바람직하다. 이러한 파일크기 정보는 바람직하게는 콘텐츠 서버(440)에서 마이크로브라우저(420)로 보내는 메세지에 이 정보를 포함시킴으로써 전달할 수 있는데, 그 방법은 다양하게 구현이 가능하다. 본 명세서에서는 도5에 나타낸 바와 같이 다운로드가능 아이템에 링크되어 있는 URL의 일부분에 이러한 파일크기 정보가 삽입되어 있도록 하였다. 즉, 도5를 참조하면 다운로드가능 아이템 "MyPhone"에 링크되어 있는 URL에 포함된 "filesize=1800" 부분이 다운로드할 데이터 파일 "myphone.sis"의 크기에 해당한다.

도4에서 단계(4-5) 내지 단계(4-6)과 관련하여 전술하였던 데이터 파일이 콘텐츠 서버(440)로부터 마이크로브라우저(420)로 다운로드됨에 있어서 여러 개의 데이터 세그먼트로 분할되어 전송되는 경우에 대해서 도6 및 도9를 참조하여 보다 상세히 설명하고자 한다. 도6은 본 발명에 따른 무선통신 시스템에서 HTTP 응답(610)과 데이터 블록(650), 그리고 다운로드 데이터(680)의 상호관계의 실시예를 도시한 도면이다. WSP 응답은 HTTP 응답(610)의 바이너리 표현에 불과하므로 본 실시예에서 별도로 설명하지는 않는다.

종래의 HTTP 프로토콜에 규정된 바와 같이, HTTP 응답 메세지(610)는 상태 라인(Status-Line : 620)과 응답 헤더(630), 그리고 엔터티 바디(entity body : 640)로 구성되는데, 다운로드 데이터는 이 중에서 엔터티 바디(640)에 위치한다.다만, 전술하였던 세그먼트 분할 전송을 위해서 본 실시예에서는 엔터티 바디(640) 내에 데이터 블록(650)이라는 데이터 구조를 정의하여 사용한다.

도시된 바와 같이, 데이터 블록(650)은 블록헤더(660)과 페이로드(670)로 구성되는데, 블록헤더(660)는 데이터의 안정적인 다운로드를 보조하기 위한 부분이고, 페이로드(670)는 다운로드 데이터를 포함하는 부분이다. 데이터 블록(650)의 필드 포맷(field format)에 대해서는 도7을 참조하여 보다 상세히 후술한다. 마지막으로, 페이로드(670)에는 본 발명의 방법을 통해서 다운로드되는 데이터의 세그먼트(680)가 포함된다. 개념적으로, WAP 응용 단말기(210)는 데이터를 다운로드하면서 블록헤더(660)의 내용을 참조하여 데이터 세그먼트(680)를 재조합(re-assemble)함으로써 최종적으로 데이터 파일을 재구성한다.

도6에 도시된 HTTP 응답 메세지(610)의 구성과 HTTP 프로토콜의 규격 버전 1.1, 즉 RFC 2068의 규정을 비교하면, 도6의 상태 라인(620)은 HTTP 규격에서 HTTP 버전정보(HTTP-Version), 상태코드(status code), 그리고 근거구문(reason phrase)으로 구성되고, 도6의 응답 헤더(630)는 HTTP 규격에서 일반헤더(general header), 응답헤더(response header), 그리고 엔터티 헤더(entity header)로 구성된다. 또, 도6의 엔터티 바디(640)는 HTTP 규격에서는 메세지 바디(message body)라고도 불리는데, 인코딩 방식에 따라서 여러가지 모습으로 나타날 수 있다. 즉, 도6에 도시된 구성은 개념적인 것으로 해석되어야 한다.

도7은 도6에 도시된 데이터 블록(750)의 필드 포맷의 실시예를 도시한 도면이다. 도6을 참조하여 전술한 바와 같이, 데이터 블록(750)은 블록헤더(760)와 페이로드(770)로 구성되는데, 블록헤더(760)는 데이터 파일을 안정적으로 전달할 수 있도록 보조하기 위한 정보를 포함하고, 페이로드(770)는 콘텐츠 서버(440)가 마이크로브라우저(420)로 전달하고자 하는 데이터 파일의 내용을 포함한다.

이하, 블록헤더(760)에 대해서 정의된 각각의 필드에 대해서 설명하고자 한다. 헤더 사이즈(header_size) 필드는 블록헤더(760)의 바이트 갯수로서 전체 데이터 블록(750)에서 블록헤더(760)의 영역과 페이로드(770)의 영역을 구분하기 위한 것이다.

또한, 파일타입(file_type) 필드는 다운로드되는 데이터 파일의 종류를 나타내는 것으로서 구체적인 인코딩은 응용 분야에서 임의로 설정하여 사용한다. 예컨대, 0의 값은 동영상 파일포맷인 SIS 파일에 대응하고 1의 값은 멜로디 파일포맷인 MMD 파일에 대응하는 등과 같다. 본 발명에 따른 WAP 응용 단말기는 데이터 파일을 다운로드한 후 파일타입 필드의 값에 따라서 이 데이터 파일을 저장 및 처리한다. 즉, 전술한 예에 있어서, 다운로드한 데이터 파일의 파일타입 필드의 값이 0이면 데이터 파일은 동영상 파일인 SIS 파일이므로 이에 맞도록 저장 및 처리하여 화면에 디스플레이되도록 하고, 반면 다운로드한 데이터 파일의 파일타입 필드의 값이 1이면 데이터 파일은 멜로디 파일인 MMD 파일이므로 이에 맞도록 저장 및 처리하여 단말기로부터 음악이 흘러나오도록 한다.

또한, 데이터 플래그(data_flag) 필드는 현재의 데이터 블록(750)에 존재하는 페이로드 데이터(payload_data)의 특징을 나타내기 위한 것으로서, 본 명세서에서는 두 개의 1비트 플래그가 정의되어 있다. 먼저 s 플래그는 start_indicator플래그로서 현재의 데이터 블록(750)에 존재하는 페이로드 데이터가 데이터 파일 내에서 처음 부분에 해당하는지 여부를 나타내기 위한 플래그이고, m 플래그는 more_data 플래그로서 현재의 데이터 블록(750)에 존재하는 페이로드 데이터에 의해서 데이터 파일의 다운로드가 완료되는지 여부를 가리킨다.

마이크로브라우저(420)는 자신의 다운로드 요구(단계 4-4)에 대응하여 콘텐츠 서버(440)로부터 전달되는 최초의 데이터 블록을 인식할 수 있으므로, 전술한 s 플래그에 의하지 않더라도 현재의 데이터 블록(750)에 존재하는 페이로드 데이터가 데이터 파일 내에서 처음 부분에 해당하는지 여부를 판단할 수 있다. 다만, 이와같이 s 플래그가 제공되어 사용하는 경우에는 후술하는 바와 같이 페이로드 데이터를 모아서 데이터 파일을 재구성함에 있어서 좀더 간편할 수 있다.

도4 및 도5를 참조하여 전술한 바와 같이, 마이크로브라우저(420)는 다운로드할 데이터 파일의 크기를 알고 있는 것이 바람직한데, 그러한 경우 마이크로브라우저(420)는 페이로드(770) 내의 필드 값인 페이로드 사이즈(payload_size)를 계수하여 데이터 파일의 크기와 비교함으로써 현재의 데이터 블록(750)이 데이터 파일의 끝(End Of File)인지 여부를 스스로 판단할 수 있는 반면, 그렇지 않은 경우에는 마이크로브라우저(420)는 전술한 m 플래그에 의해서만 데이터 파일의 끝인지 여부를 판단할 수 있다.

한편, 마이크로브라우저(420)가 다운로드할 데이터 파일의 크기를 알고 있는 경우라 하더라도 본 실시예와 같이 블록헤더(760)에 m 플래그가 제공되어 이에 기초하여 현재의 데이터 블록(750)이 데이터 파일의 끝인지 여부를 판단하는 경우에는 페이로드 사이즈의 값을 계수하여 데이터 파일의 크기와 비교할 필요가 없으므로 다소나마 동작이 간단하고 판단 시간을 절약할 수 있는 장점이 있다. 또한, m 플래그가 제공되는 경우에는 데이터 파일의 전송/수신 과정에서 오류(error)가 발생하더라도 페이로드 데이터를 계수하여 데이터 파일의 크기와 비교한 제1 판단 결과와 m 플래그의 값에 따른 제2 판단 결과가 서로 불일치하는 이벤트가 발생하게 되므로 이러한 오류 발생을 효과적으로 검출해 낼 수 있는 장점이 있다.

또한, 파일이름(file_name) 필드는 다운로드하는 데이터 파일의 이름을 나타내는 필드로서, 통상 캐릭터 스트링(character string)으로 이루어지며 바람직하게는 확장명(extension name)과 도트(dot)를 포함한다. 파일이름 필드의 길이는 문제가 발생하지 않도록 충분히 긴 것이 바람직하며, 남는 부분은 널(NULL) 문자, 즉 0x00으로 채워지도록 하여 유효 캐릭터 영역과 구분되도록 한다.

또한, 데이터 오프셋(data_offset) 필드는 다운로드하는 데이터 파일 내에서 현재의 데이터 블록(750)에 존재하는 페이로드 데이터의 시작 위치를 나타내기 위한 것으로서, 현재의 페이로드 데이터가 전체 데이터 파일에서 얼마만큼 오프셋된 위치에 존재하는지를 나타낸다. 마지막으로, 유예(rsv) 필드는 현재로서는 특별히 용도가 정의되지 않은 필드이다.

이하, 페이로드(770)에서 사용하는 각각의 필드에 대해서 설명하고자 한다. 페이로드 크기(paylaod_size) 필드는 이어지는 페이로드 데이터(payload_data) 필드의 바이트 갯수를 나타내는 필드이고, 페이로드 데이터 필드는 실제로 전달되는 데이터 파일의 내용에 해당하는 필드이다. 전술한 데이터 세그먼트의 각각은 도7에서 이 페이로드 데이터 필드에 위치하게 된다.

도8은 도7에 도시된 필드 포맷의 실시예에 따라 실제 데이터 블록(810)을 파싱한 결과(820)를 나타낸 도면이다. 도8의 실시예를 위해서, 블록헤더(760)의 파일이름(file_name) 필드의 길이는 20 바이트로 하였다. 파싱결과(820)에 나타낸 바와 같이, 현재 다운로드 중인 데이터 파일의 종류는 SIS이고(file_type=0) 파일이름은 "a.sis"이며, 현재의 데이터 블록(750)에 존재하는 페이로드 데이터는 전체 데이터 파일의 처음 영역이고(s=1) 현재의 데이터 블록(750)으로 데이터 파일의 다운로드 과정이 완료되지 않고 데이터 블록(750)의 다운로드가 더 필요하다(m=1). 처음 영역이므로 데이터 오프셋은 당연히 0의 값을 갖고, 현재의 데이터 블록(750)에 존재하는 페이로드 데이터는 크기는 1400 바이트이며(payload_size=1400), 페이로드 데이터의 내용은 0x53, 0x49, 0x53, ......이다.

도7 및 도8에 도시된 데이터 블록(750)의 필드 포맷은 본 발명의 다운로드 방법에 있어서 콘텐츠 서버(440)가 데이터 파일을 복수의 데이터 세그멘트로 분할하여 전송하고 이에 대응하여 마이크로브라우저(420)가 이들 데이터 세그먼트를 적절히 재조합하여 원래의 데이터 파일을 재구성하는 것이 기술적으로 가능하다는 것을 나타내기 위한 하나의 실시예로서 이해되어야 하며, 도7 및 도8에 도시된 필드 각각의 구체적인 정의, 예컨대 위치, 길이, 의미 등에 의해 본 발명의 권리범위가 제한되는 것으로 해석되어서는 않된다.

이하, 도6 내지 도8을 참조하여 도4에서 데이터 파일의 다운로드 단계(4-4 내지 4-6)를 보다 상세히 설명하고자 한다. 사용자의 단말기 조작에 의해서 WAP응용 단말기의 다운로드 내부함수가 호출되어 데이터 파일의 다운로드가 기동(단계 4-3)되고, WSP/HTTP 요구/응답 과정(단계 4-4, 단계 4-5)을 통해 데이터 파일이 콘텐츠 서버(440)로부터 마이크로브라우저(420)로 전달되는 것은 전술한 바와 같다. 또한, 전술한 바와 같이, 다운로드할 데이터 파일의 크기가 최대 PDU보다 큰 경우에는 복수 회의 WSP/HTTP 요구/응답 과정이 수행되는데(단계 4-4 내지 4-6), 이 때 도6 내지 도8을 참조하여 설명하였던 데이터 블록(750)의 각종 필드들이 유용하게 사용된다.

이해의 편이를 위해, 다운로드할 데이터 파일 "a.sis"의 파일 크기가 3224 바이트이고 최대 PDU가 1400 바이트인 경우에, 도4에 도시된 데이터 파일의 다운로드 과정(단계 4-4 내지 4-6)에서 도7에 도시된 데이터 블록(750)의 주요 필드의 역할을 도9에 도시하였다. 데이터 파일의 크기가 3224 바이트이고 최대 PDU가 1400 바이트이므로 도9에서는 모두 3회의 WSP/HTTP 요구/응답 과정(950, 960, 970)을 통해서 데이터 파일이 전달된다.

첫번째 WSP/HTTP 요구/응답 과정(단계 950-1, 단계 950-2)을 보면, 데이터 파일에서 첫번째 데이터 블록이므로 data_flag는 11000000b (s=1, m=1)이고 data_offset은 0이며 payload_size는 최대 PDU와 동일한 1400의 값을 갖는다. 도시된 바와 같이, 첫번째 WSP/HTTP 요구/응답 과정(단계 950-1, 단계 950-2)이 수행되면 콘텐츠 서버(940)에는 1824 바이트(즉, 3224 바이트 - 1400 바이트)가 남고 마이크로브라우저(920)에는 1400 바이트가 존재하게 된다.

두번째 WSP/HTTP 요구/응답 과정(단계 960-1, 단계 960-2)을 보면, 데이터파일에서 두번째 데이터 블록이고 이번 데이터 블록 이후에 보내야할 데이터가 아직 남아 있으므로 data_flag는 01000000b (s=0, m=1)이고 data_offset은 1400이며 payload_size는 이전과 마찬가지로 1400이다. 도시된 바와 같이, 두번째 WSP/HTTP 요구/응답 과정(단계 960-1, 단계 960-2)이 수행되면 콘텐츠 서버(940)에는 424 바이트(즉, 1824 바이트 - 1400 바이트)가 남고 마이크로브라우저(920)에는 2800 바이트가 존재하게 된다.

마지막인 세번째 WSP/HTTP 요구/응답 과정(단계 970-1, 단계 970-2)을 보면, 데이터 파일에서 세번째이자 마지막 데이터 블록이므로 data_flag는 00000000b (s=0, m=0)이고 data_offset은 2800이며 payload_size는 남아있던 데이터의 크기, 즉 424이다. 도시된 바와 같이, 세번째 WSP/HTTP 요구/응답 과정(단계 970-1, 단계 970-2)이 수행되면 콘텐츠 서버(940)로부터 마이크로브라우저(920)에 대한 데이터 파일(3224 바이트)의 전달 동작이 완료된다.

전술한ㅁ 바와 같이, 마이크로브라우저(920)는 데이터 파일의 전달 동작이 완료되면 선택적으로 콘텐츠 서버(940)에 대해서 다운로드가 성공하였는지 여부를 알릴 수 있다. 이와 같이 다운로드의 성공 여부를 알리는 방법은 그 구체적인 구현방식에 따라서 여러가지가 가능하나 도9에서는 하나의 실시예로서 이후의 WSP/HTTP 요구(단계 980-1)에서 성공 여부에 대한 정보를 제공하도록 하였다.

도10은 통상의 무선통신 시스템에서, 데이터 파일이 콘텐츠 서버(1040)로부터 WAP 게이트웨이(1030)를 거쳐 WAP 응용 단말기(1010)로 다운로드되는 네트워크 토폴로지(network topology) 및 WAP 게이트웨이(1030)의 최대 PDU를 표시하는 도면이다. 도시된 바와 같이, 무선통신 시스템의 네트워크 토폴로지는 전형적으로 통상의 인터넷망(1060)과 무선통신 시스템 특유의 베어러(1050)로 구성되고, WAP 게이트웨이(1030)는 인터넷망(1060)과 베어러(1050) 사이를 매개한다.

무선통신 기술, 예컨대 WAP 등에 있어서 게이트웨이가 한번에 처리할 수 있는 데이터의 양에는 최대 PDU라고 부르는 한계가 존재하고 따라서 데이터 파일의 크기가 이 최대 PDU보다 큰 경우에는 수 회에 걸친 일련의 WSP/HTTP 요구/응답이 필요하게 됨은 전술한 바와 같다.

그런데, 이러한 최대 PDU의 값은 사용하는 무선통신 기술의 종류에 따라서 서로 상이하고, 또한 동일한 무선통신 기술을 사용한다고 하더라도 단말기에 탑재된 브라우저의 종류 및 지원하는 규격 버전(version)에 따라서도 서로 상이하다. 예를 들면, 동일한 WAP 기술이더라도 UP 브라우저나 ME 브라우저 등은 서로 상이한 최대 PDU의 값을 사용하고, 또한 동일한 UP 브라우저이더라도 버전 3.1에서와 버전 4.1에서 서로 상이한 최대 PDU의 값, 즉 각각 1492 바이트와 2984 바이트, 페이로드 데이터에 대해서는 대략 1200 바이트와 2400 바이트를 규정한다.

이러한 이유로 인해, 도10에 도시된 것과 같은 무선통신 시스템의 네트워크 토폴로지에 있어서 구체적인 데이터 파일의 다운로드 이벤트에 있어서 실제로 연결되는 WAP 게이트웨이(1030)가 갖는 최대 PDU의 값은 미리 정하여져 있지 않고 다양한 값이 가능하다. 예컨대, 통상의 이동통신 시스템에 있어서는 다수의 WAP 게이트웨이(1030)가 각각 일정한 지역을 담당하도록 구성되는데, 이러한 경우에 구체적인 다운로드 이벤트에 있어서 연결되는 WAP 게이트웨이(1030)는 다운로드 개시 시점에서 단말기(1010)가 위치한 지역에 의해 결정되는 것이다.

그런데, WAP 응용 단말기(1010)는 해당 WAP 게이트웨이(1030)에 대해서 설정된 최대 PDU 값을 알지 못하기 때문에 현재 상태에서 가장 안전한 선택, 즉 UP 브라우저를 내장한 경우에는 항상 1492 바이트를 최대 PDU로 간주하고 WSP/HTTP 요구/응답 과정의 횟수 및 WSP/HTTP 요구에서의 요구 내용, 예컨대 다운로드할 데이터의 크기 등을 결정하게 된다. 이로 인해, 불필요하게 많은 횟수의 WSP/HTTP 요구/응답 과정이 존재하게 되는데, 특히 이동통신 시스템과 같이 시간지연이 큰 통신환경에서는 상당한 정도의 성능 저하가 야기되는 문제가 있다. 따라서, 구체적인 다운로드 이벤트에 대해서 현재 설정된 다운로드 경로에서의 실재로 가능한 최대 PDU 값을 적용함으로써 데이터 파일의 다운로드 과정을 최적화할 필요성이 있다.

이러한 문제점을 방지하기 위해서, 데이터 파일의 다운로드를 시작할 때 WAP 응용 단말기(1010)가 현재 다운로드 경로에서의 최대 PDU 값에 대한 정보를 갖는 것이 바람직하다. WAP 응용 단말(1010)가 전술한 최대 PDU 값의 정보를 갖도록 하는 방법은 다양하게 구현할 수 있는데, 본 명세서에서는 그 실시예로서 마이크로브라우저(920)로 전달되는 WML 데크의 소정의 영역에 현재 설정된 다운로드 경로에서의 실제 최대 PDU 값을 나타내는 코드가 포함되도록 한다.

도11은 마이크로브라우저(920)로 전달되는 WML 데크로서 전술한 바와 같이 실제 최대 PDU 값이 표시된 실시예를 도시한 도면이다. 도11의 WML 데크에서 다운로드를 위한 메뉴 아이템, 즉 "MyPhone"과 "ZZanggu"에 링크된 URL 각각은 소정의영역(1110, 1120)에 이를 위한 정보, 즉 "maxpdu=1200"를 포함한다. 전술한 바와 같이, 사용자가 단말기(1010)의 조작을 통해 임의의 메뉴 아이템, 예컨대 "ZZanggu"를 선택하면 마이크로브라우저(920)는 WAP 응용 단말기(1010)가 제공하는 확장 API 함수를 호출하면서 전달 파라미터로서 해당 메뉴 아이템에 링크되어 있는 URL, 예컨대 "device:data/download?url=......&maxpdu=1200"을 사용한다. 이어서, WAP 응용 단말기(1010)의 미들웨어나 펌웨어는 이 URL 메세지를 파싱하여 현재 설정된 다운로드 경로에서의 최대 PDU의 값이 1200이라는 정보를 획득하고 이를 활용하여 WSP/HTTP 요구 메세지의 생성에 활용하며(단계 4-3 참조), 이로써 데이터 파일의 다운로드 과정이 최적화된다.

마이크로브라우저(920)로 전달되는 WML 데크의 소정의 영역에 현재 설정된 다운로드 경로에서의 실제 최대 PDU 값을 나타내는 코드가 포함되도록 하는 방법은 다양하게 구현할 수 있는데, 본 명세서에서는 그 실시예로서 콘텐츠 서버(1040)가 이 코드를 포함시켜 WML 데크를 작성하는 방법 및 WAP 게이트웨이(1030)가 이 코드를 WML 데크에 삽입하는 방법을 기술한다.

도12는 본 발명에 따른 무선통신 시스템에서 마이크로브라우저(1220)가 콘텐츠 서버(1240)로 연결하여 데이터 파일을 다운로드받는 과정에 있어서 실제의 최대 PDU 값에 기초하여 다운로드 과정을 최적화하는 실시예로서, 콘텐츠 서버(1240)가 실제 최대 PDU 값에 대한 코드를 포함시켜 WML 데크를 작성하는 실시예를 도시하는 도면이다.

전술한 바와 같이, WAP 게이트웨이(1230)는 마이크로브라우저(1220)와 콘텐츠 서버(1240) 사이에서 WSP/HTTP 프로토콜 변환 기능을 수행하는데, 본 실시예에서는 마이크로브라우저(1220)로부터의 WSP 요구를 HTTP 요구로 변환할 때 현재 설정된 다운로드 경로에서 최대 PDU에 대한 정보를 삽입한다. 즉, 본 실시예에서는 최대 PDU에 대한 정보는 마이크로브라우저(1220)가 보내는 WSP 요구에는 포함되어 있지 않으나 WAP 게이트웨이(1230)의 프로토콜 변환과정에서 예컨대 HTTP 요구헤더(HTTP request header)에 삽입되는 것이다.

콘텐츠 서버(1240)는 이 최대 PDU에 대한 정보를 사용하여 도11에 도시된 것과 같이 최대 PDU에 대한 정보를 나타내는 코드(1110, 1120)를 포함하는 WML 데크를 작성한 후, 마이크로브라우저(1220)로 전달(단계 12-2)하고, 이어서 WAP 응용 단말기(1010) 또는 마이크로브라우저(1220)는 이 정보(1110, 1120)에 기초하여 이후의 단계에서 데이터 파일의 다운로드 과정을 최적화한다.

도12를 참조하여 설명한 본 실시예에 있어서, 마이크로브라우저(1220)가 데이터 파일의 다운로드 과정이 완료되면 선택적으로 콘텐츠 서버(1240)에 대해서 데이터 파일의 다운로드가 성공하였는지 여부를 알릴 수 있고(단계 12-7), 이러한 기능이 본 발명의 기술분야인 무선통신 시스템에 있어서 상당히 중요한 기능을 가질 수 있음은 도4를 참조하여 전술한 바와 같다.

도13은 본 발명에 따른 무선통신 시스템에서 마이크로브라우저(1320)가 콘텐츠 서버(1340)로 연결하여 데이터 파일을 다운로드받는 과정에 있어서 실제의 최대 PDU 값에 기초하여 다운로드 과정을 최적화하는 실시예로서, WAP 게이트웨이(1330)가 실제 최대 PDU 값에 대한 코드를 WML 데크에 삽입하는 실시예를 도시하는 도면이다.

전술한 바와 같이, WAP 게이트웨이(1330)는 마이크로브라우저(1320)와 콘텐츠 서버(1340) 사이에서 인코딩/디코딩 기능을 수행하는데, 본 실시예에서는 콘텐츠 서버(1340)로부터의 WML 데크를 바이너리 형식으로 인코딩할 때 현재 설정된 다운로드 경로에서 최대 PDU에 대한 정보(1110, 1120)를 삽입한다. 즉, 본 실시예에서 최대 PDU에 대한 정보(1110, 1120)는 콘텐츠 서버(1340)가 보내는 WML 데크에는 포함되어 있지 않으나 WAP 게이트웨이(1330)에서 바이너리로 인코딩될 때 삽입되는 것이다. 이어서, WAP 응용 단말기(1010) 또는 마이크로브라우저(1320)는 이 정보(1110, 1120)에 기초하여 이후의 단계에서 데이터 파일의 다운로드 과정을 최적화한다.

본 실시예에 있어서, 최대 PDU에 대한 정보(1110, 1120)가 WML 데크에 삽입되는 구체적인 형식은 도11에 도시된 바에 한정되지 않음은 전술한 바와 같으며, 단지 최대 PDU 정보(1110, 1120)가 WAP 게이트웨이(1330)에 의해 WML 데크에 삽입되고, WAP 응용 단말기(1010) 또는 마이크로브라우저(1320)가 이 정보(1110, 1120)에 기초하여 본 발명에 따른 데이터 파일의 다운로드 과정을 최적화하는 것으로 충분하다고 이해되어야 한다.

도13을 참조하여 설명한 본 실시예에 있어서, 마이크로브라우저(1320)가 데이터 파일의 다운로드 과정이 완료되면 선택적으로 콘텐츠 서버(1340)에 대해서 데이터 파일의 다운로드가 성공하였는지 여부를 알릴 수 있고(단계 13-7), 이러한 기능이 본 발명의 기술분야인 무선통신 시스템에 있어서 상당히 중요한 기능을 가질수 있음은 도4를 참조하여 전술한 바와 같다.

도12 및 도13에 도시한 실시예에 있어서, 무선통신 시스템에서 WAP 응용 단말기(1010)는 데이터 파일의 다운로드 도중에 이동할 수 있으므로 데이터 파일의 다운로드 도중에 다운로드 경로가 변경될 수 있으며 이에 따라 실제 최대 PDU 값도 변경될 수 있으므로, 이러한 점을 감안할 때 전술한 정보(1110, 1120)는 최초의 WML 데크 뿐만 아니라 마이크로브라우저(1220, 1320)로 전달되는 하나 이상의 WML 파일 또는 모든 WML 파일에 삽입되는 것이 바람직하다. 이 경우, 마이크로브라우저(1220, 1320)는 최대 PDU 값의 변화에 적응적으로 대처하여 지속적으로 다운로드 과정을 최적화한다.

또한, 본 발명의 데이터 파일의 다운로드 방법에 따르면 무선통신 시스템에서 데이터 파일을 다운로드함에 있어서 다운로드 과정을 최적화하여 성능을 극대화할 수 있는 장점이 있다.

본 명세서에서 "데이터 파일(data file)"이라 함은 통상의 컴퓨터 관련 분야에서 지칭하는 파일에 한정되지 않으며 본 발명과 관련된 다운로드 시스템에서 무선으로 다운로드 되어야 하는 데이터의 덩어리로서 전체로서 유효한 의미를 갖는 데이터의 집합을 의미하는 것으로 해석되어야 한다.

또한, 본 명세서에서 "다운로드(download)"라 함은 본 발명에 따른 무선통신 서비스를 제공하는 시스템으로부터 소정의 단말기로 데이터 또는 데이터 파일이 옮겨지는 프로세스를 말하는 것으로서, 그 형식에 있어서 제한받지 않는 것으로 해석되어야 한다.

또한, 본 명세서에서 "단말기(terminal)"라 함은 전술한 휴대용 단말기 뿐만 아니라 개인용 컴퓨터나 세트톱 박스, 또는 디지탈 TV 등도 포함하는 넓은 개념으로서 해석되어야 한다. 이 때, 단말기가 자체적으로는 무선통신 기능이 없어 다른 통신장치와 협조동작하여 무선통신 기능을 구현하거나 혹은 자체적으로는 디스플레이 기능이 없어 다른 디스플레이 장치와 협조동작하여 콘텐츠 디스플레이 기능을 구현하는 경우가 있을 수 있는데, 본 명세서에서 설명된 동작방식은 이러한 경우에 대해서 적절히 유추되어 이해되어야 한다.

또한, 본 명세서에서 "마이크로브라우저(micro browser)"라 함은 단말기에서 콘텐츠들의 브라우징을 지원하는 소프트웨어를 일반적으로 지칭하는 용어로서, 특정의 브라우저, 예컨대 UP 브라우저나 ME 브라우저 등에 한정되지 않는 것으로 해석되어야 한다.

또한, 본 명세서에서 "무선통신 시스템(wireless communication system)"이라 함은 앞의 발명의 상세한 설명에서 기술한 이동통신(mobile communication) 시스템에 한정되지 않고 IEEE 802.11 규격이나 MMAC (Multimedia Mobile Access Communication) 규격, 또는 HyperLAN2 규격 등에 따른 무선랜 시스템을 포함하는 일반적인 무선통신 시스템을 지칭하는 것으로 해석되어야 하며, 본 명세서에서 사용한 용어 및 명칭도 이에 따라 적응적으로 해석되어야 한다.

또한, 본 명세서에서 "최대 PDU 정보를 이용한 데이터 파일의 다운로드 최적화" 과정에 있어서 본 발명의 발명자 및 출원인은 실제 구현에 있어서 전술한 최적화 과정은 WAP 게이트웨이의 최대 PDU 값 뿐만 아니라 마이크로브라우저 또는 콘텐츠 서버의 성능 및 용량과도 관련되어 있음을 인식하고 있는 것으로 이해되어야 한다. 예컨대, WAP 게이트웨이의 최대 PDU가 2400 바이트라고 하더라도 마이크로브라우저가 1회의 트랜젝션에서 다운로드받을 수 있는 용량이 1200 바이트이거나 콘텐츠 서버가 1회의 트랜젠션에서 전송할 수 있는 용량이 1200 바이트인 경우에는 다운로드 최적화 과정에 있어서 1200 바이트가 기준으로 반영되어야 할 것이다.

또한, 본 명세서의 발명의 상세한 설명에 있어서 "현재 설정된 경로상의 최대 PDU 값"의 정의에 마이크로브라우저 또는 콘텐츠 서버의 용량에 대한 고려도 포함되어 있다고 해석하는 방법도 가능하다. 즉, WAP 게이트웨이에서 최대 PDU 값에 대한 정보를 삽입하는 과정(도 12, 도13)이나 콘텐츠 서버가 최대 PDU 값의 정보를 이용하여 WML 데크를 작성하는 과정(도 12), 또는 마이크로브라우저가 WML 데크의 코드를 통해 전달된 최대 PDU 값의 정보를 이용하여 현재 설정된 최대 PDU 값을 획득하는 과정(도 12, 도13)에 있어서, WSP/HTTP 요구/응답의 헤더 내용을 통해 알 수 있는 마이크로브라우저 또는 콘텐츠 서버의 버전 정보를 적절히 고려하여 판단할 수 있다.

또한, 본 명세서에서 "메세지(message)"라 함은 텍스트로 구성된 캐릭터 스트링 뿐만 아니라 바이너리 포맷으로 구성된 데이터 집합도 포함하는 것으로 해석되어야 한다. 이는 본 발명의 기술분야에서 "메세지"라는 용어는 이와 같이 바이너리 포맷의 데이터 집합에도 사용될 수 있는데, 이는 전술한 WSP 규격, 즉 Wireless Session Protocol Specification Approved Version 5-July-2001의 내용에서 베어러 네트워크(Bearer Network)의 정의, 5.2.2장의 확장기능(Extended Functionality)에 대한 설명, 그리고 6.3.2.2장의 정의된 성능(Defined Capabilities)의 서버 메세지 사이즈(Server Message Size)에 대한 설명 등 여러 곳에서 드러난다. 따라서, 본 명세서에 있어서도 "메세지"라는 용어의 의미는 이와같이 바이너리 포맷으로 구성된 데이터 집합도 포함한다고 해석하는 것이 타당하다.

Claims

무선통신 기능을 구비한 단말기에서 상기 단말기와 소정의 프로토콜에 따라 무선통신 연결될 수 있는 콘텐츠 서버로부터 데이터 파일을 다운로드받기 위한 방법에 있어서, 상기 단말기에 대한 사용자의 조작에 대응하여 상기 콘텐츠 서버로 상기 소정의 프로토콜에 따른 통신연결을 요구하는 메세지를 전송하는 제1 단계; 상기 통신연결의 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 다운로드 가능 아이템 및 상기 아이템에 대한 링크 메세지의 하나이상의 조합을 포함하는 디렉토리 페이지를 획득하여 상기 사용자에게 디스플레이하는 제2 단계; 상기 디스플레이된 화면 상에서 상기 사용자가 다운로드 가능 아이템을 선택하는 동작이 검출되면 상기 선택된 아이템에 링크된 메세지를 이용하여 상기 소정의 프로토콜에 따른 요구 메세지 코드를 획득하는 제3 단계; 상기 요구메세지 코드를 이용하여 상기 콘텐츠 서버로 상기 선택된 아이템에 대응하는 데이터 파일에 대한 다운로드를 요구하는 메세지를 전송하는 제4 단계; 상기 다운로드 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 제1 데이터 블록을 획득하는 제5 단계; 상기 제1 데이터 블록의 내용으로부터 상기 데이터 파일의 다운로드가 완료되었는지 여부를 판단하고, 상기 판단결과로부터 상기 데이터 파일의 다운로드가 완료되지 않은 경우에는 상기 데이터 파일의 다운로드가 완료될 때까지 상기 데이터 파일의 다음 데이터 블록을 요구하는 메세지를 상기 콘텐츠 서버로 전송하는제6a 단계, 상기 다음 데이터 블록의 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 상기 다음 데이터 블록을 획득하는 제6b 단계, 및 상기 다음 데이터 블록의 내용으로부터 상기 데이터 파일의 다운로드가 완료되었는지 여부를 판단하는 제6c 단계를 포함하는 과정을 반복하는 제6 단계; 및 상기 제5 단계와 제6 단계에서 수신된 하나이상의 데이터 블록으로부터 상기 데이터 파일을 구성하는 제7 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제1항에 있어서, 상기 데이터 파일의 다운로드 방법은 상기 제7 단계 이후에 상기 제7 단계에서 상기 데이터 파일을 구성함에 있어서 오류가 발생하였는지 여부를 검사하여 오류가 없다는 검사결과를 얻는 경우에 상기 데이터 파일의 다운로드가 성공하였음을 나타내는 메세지를 상기 콘텐츠 서버로 전송하는 제8 단계를 더 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제1항에 있어서, 상기 제3 단계는 상기 디스플레이된 화면 상에서 상기 사용자가 다운로드 가능 아이템을 선택하는 동작을 검출하는 제3a 단계; 상기 단말기가 제공하는 확장 인터페이스 함수를 호출하면서 상기 선택된 아이템에 링크된 메세지의 소정의 부분을 상기 확장 인터페이스 함수의 파라미터로서 사용하는 제3b 단계;및 상기 확장 인터페이스 함수의 수행 결과로서 상기 소정의 프로토콜에 따른 요구 메세지 코드를 획득하는 제3c 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제1항에 있어서, 상기 제6a 단계는 상기 단말기가 제공하는 확장 인터페이스 함수를 호출하면서 상기 제3 단계에서 선택된 아이템에 링크된 메세지의 소정의 부분을 상기 확장 인터페이스 함수의 파라미터로서 사용하는 제6(1) 단계; 상기 확장 인터페이스 함수의 수행 결과로서 상기 다음 데이터 블록에 대한 상기 소정의 프로토콜에 따른 다음 데이터블록 요구 메세지 코드를 획득하는 제6(2) 단계; 및 상기 다음 데이터블록 요구 메세지 코드를 이용하여 상기 콘텐츠 서버로 상기 데이터 파일에 대한 상기 다음 데이터 블록에 대한 요구 메세지를 전송하는 제6(3) 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
무선통신 기능을 구비한 단말기와 소정의 프로토콜에 따라 무선통신 연결되어 데이터 파일을 다운로드시키기 위한 방법에 있어서, 상기 단말기로부터 상기 소정의 프로토콜에 따른 통신연결의 요구 메세지를 수신하는 제1 단계; 상기 통신연결의 요구 메세지에 대응하여 상기 단말기로 다운로드 가능 아이템 및 상기 아이템을 위한 데이터 파일을 나타내는 링크 메세지의 하나이상의 조합을 포함하는 디렉토리 페이지를 포함하는 응답 메세지를 전송하는 제2 단계; 상기 단말기로부터 상기 디렉토리 페이지의 상기 링크 메세지에서 나타낸 하나이상의 데이터 파일에 포함된 데이타 파일에 대한 다운로드를 요구하는 메세지를 수신하는 제3 단계; 상기 데이터 파일을 소정의 기본사이즈를 기준하여 하나이상의 데이터 세그먼트로 분할하는 제4 단계; 상기 하나이상의 데이터 세크먼트 중에서 최초의 제1 세그먼트를 사용하여 제1 데이터 블록을 구성하고 상기 제1 데이터 블록을 사용하여 상기 다운로드 요구에 대한 응답 메세지를 구성한 후 상기 응답 메세지를 상기 단말기로 전송하는 제5 단계; 상기 데이터 세그먼트의 갯수가 2이상일 때 상기 데이터 세그먼트가 모두 전송될 때까지, 상기 단말기로부터 다음 데이터 블록의 다운로드를 요구하는 메세지를 수신하는 제6a 단계, 상기 다음 데이터 블록의 다운로드 요구 메세지에 대응하여 상기 하나이상의 데이터 세그먼트 중에서 다음 순서에 해당하는 다음 데이터 세그먼트를 사용하여 다음 데이터 블록을 구성하는 제6b 단계, 상기 다음 데이터 블록을 사용하여 상기 다음 데이터 블록의 다운로드 요구에 대한 다음 응답 메세지를 구성하는 제6c 단계, 및 상기 다음 응답 메세지를 상기 단말기로 전송하는 제6d 단계를 포함하는 과정을 반복하는 제6 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제5항에 있어서, 상기 데이터 파일의 다운로드 방법은 상기 제6 단계 이후에 상기 단말기로부터 상기 데이터 파일의 다운로드가 성공하였는지 여부를 나타내는메세지를 수신하는 제7 단계를 더 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제1항 또는 제5항에 있어서, 상기 소정의 프로토콜은 WAP 프로토콜이고, 상기 디렉토리 페이지는 WML 데크이며, 상기 선택된 아이템에 링크된 메세지는 상기 단말기의 데이터 다운로드를 위한 내부기능을 이용함을 나타내는 기능식별부; 및 상기 선택된 아이템에 대응하는 데이터 파일이 존재하는 URL을 나타내는 자원위치부를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
무선통신 기능을 구비한 단말기에서 상기 단말기와 소정의 프로토콜에 따라 무선통신 연결된 콘텐츠 서버로부터 데이터 파일을 다운로드받기 위한 방법에 있어서, 상기 콘텐츠 서버로 상기 소정의 프로토콜에 따라 상기 데이터 파일에 대한 다운로드를 요구하는 메세지를 전송하는 제1 단계; 상기 다운로드 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 제1 데이터 블록을 획득하는 제2 단계; 상기 제1 데이터 블록의 필드포맷으로부터 상기 제1 데이터 블록이 상기 데이터 파일의 끝인지 여부를 검사하여 상기 데이터 파일의 끝이 아닌 것으로 판단되는 경우에는 상기 데이터 파일의 끝인 것으로 판단될 때까지 상기 데이터 파일의 다음 데이터 블록을 요구하는 메세지를전송하는 제3a 단계, 상기 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 상기 다음 데이터 블록을 획득하는 제3b 단계, 및 상기 다음 데이터 블록의 필드포맷으로부터 상기 다음 데이터 블록이 상기 데이터 파일의 끝인지 여부를 검사하는 제3c 단계를 포함하는 과정을 반복하는 제3 단계; 상기 제2 단계와 제3 단계에서 수신된 하나이상의 데이터 블록으로부터 페이로드 데이터의 필드, 및 상기 페이로드 데이터의 오프셋을 나타내는 필드, 그리고 상기 페이로드 데이터의 사이즈를 나타내는 필드를 각각 획득하여 상기 하나이상의 데이터오프셋 필드와 상기 하나이상의 데이터사이즈 필드의 값을 참조하여 상기 하나이상의 페이로드 데이터 필드를 조합함으로써 상기 데이터 파일을 구성하는 제4 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제8항에 있어서, 상기 데이터 파일의 다운로드 방법은 상기 제4 단계 이후에 상기 제4 단계에서 상기 데이터 파일을 구성함에 있어서 오류가 발생하였는지 여부를 검사하여 오류가 없다는 검사결과를 얻는 경우에 상기 데이터 파일의 다운로드가 성공하였음을 나타내는 메세지를 상기 콘텐츠 서버로 전송하는 제5 단계를 더 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
무선통신 기능을 구비한 단말기와 소정의 프로토콜에 따라 무선통신 연결되어 데이터 파일을 다운로드시키기 위한 방법에 있어서, 상기 단말기로부터 상기 소정의 프로토콜에 따라 상기 데이터 파일에 대한 다운로드의 요구 메세지를 수신하는 제1 단계; 상기 데이터 파일을 소정의 기본사이즈를 기준하여 하나이상의 데이터 세그먼트로 분할하는 제2 단계; 상기 하나이상의 데이터 세크먼트 중에서 최초의 제1 세그먼트를 페이로드 데이터 필드로서 사용하여 제1 데이터 블록을 구성하고 상기 제1 데이터 블록을 사용하여 상기 다운로드 요구에 대한 응답 메세지를 구성한 후 상기 응답 메세지를 상기 단말기로 전송하는 제3 단계; 상기 데이터 세그먼트의 갯수가 2이상일 때 상기 데이터 세그먼트가 모두 전송될 때까지, 상기 단말기로부터 다음 데이터 블록의 다운로드를 요구하는 메세지를 수신하는 제4a 단계, 상기 다음 데이터 블록의 다운로드 요구 메세지에 대응하여 상기 하나이상의 데이터 세그먼트 중에서 다음 순서에 해당하는 다음 데이터 세그먼트를 선택하는 제4b 단계, 상기 다음 데이터 세그먼트를 페이로드 데이터 필드로서 사용하고 상기 데이터 파일에서 상기 다음 데이터 세그먼트의 상대적인 위치를 나타내는 오프셋 값을 데이터오프셋 필드로서 사용하며 상기 다음 데이터 세그먼트의 사이즈를 데이터사이즈 필드로서 사용하여 다음 데이터 블록을 구성하는 제4c 단계, 상기 다음 데이터 블록을 사용하여 상기 다음 데이터 블록의 다운로드 요구에 대한 다음 응답 메세지를 구성하는 제4d 단계, 및 상기 다음 응답 메세지를 상기 단말기로 전송하는 제4e 단계를 포함하는 과정을 반복하는 제4 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법
제10항에 있어서, 상기 데이터 파일의 다운로드 방법은 상기 제4 단계 이후에 상기 단말기로부터 상기 데이터 파일의 다운로드가 성공하였는지 여부를 나타내는 메세지를 수신하는 제5 단계를 더 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제8항 또는 제10항에 있어서, 상기 데이터 블록의 필드포맷은 상기 데이터 블록의 페이로드 데이터가 상기 데이터 파일의 처음 부분에 해당하는지 여부를 나타내는 제1 플래그 필드, 및 상기 데이터 블록의 페이로드 데이터가 상기 데이터 파일의 마지막 부분에 해당하는지 여부를 나타내는 제2 플래그 필드를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제8항 또는 제10항에 있어서, 상기 데이터 블록의 필드포맷은 상기 데이터 파일의 종류를 나타내는 파일타입 필드, 및 상기 데이터 파일의 이름을 나타내는 파일이름 필드를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
무선통신 기능을 구비한 단말기에서 상기 단말기와 소정의 프로토콜에 따라무선통신 연결될 수 있는 콘텐츠 서버로부터 데이터 파일을 다운로드받기 위한 방법에 있어서, 상기 단말기에 대한 사용자의 조작에 대응하여 상기 콘텐츠 서버로 상기 소정의 프로토콜에 따른 통신연결을 요구하는 메세지를 전송하는 제1 단계; 상기 통신연결의 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 다운로드 가능 아이템 및 상기 아이템에 대한 링크 메세지의 하나이상의 조합을 포함하는 디렉토리 페이지를 획득하여 상기 사용자에게 디스플레이하는 제2 단계; 상기 디스플레이된 화면 상에서 상기 사용자가 다운로드 가능 아이템을 선택하는 동작이 검출되면 상기 선택된 아이템에 링크된 메세지로부터 현재 설정된 다운로드 경로상에서의 최대 PDU 정보와 상기 선택된 아이템에 대응하는 데이터 파일의 사이즈 정보를 획득하고, 상기 링크된 메세지와 상기 최대 PDU 정보, 그리고 상기 데이터 파일의 사이즈 정보를 사용하여 요구 데이터 블록의 크기가 상기 최대 PDU 이하가 되도록 작성된 상기 소정의 프로토콜에 따른 요구 메세지 코드를 획득하는 제3 단계; 상기 요구메세지 코드를 이용하여 상기 콘텐츠 서버로 상기 선택된 아이템에 대응하는 데이터 파일에 대한 다운로드를 요구하는 메세지를 전송하는 제4 단계; 상기 다운로드 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 제1 데이터 블록을 획득하는 제5 단계; 상기 제1 데이터 블록의 내용으로부터 상기 데이터 파일의 다운로드가 완료되었는지 여부를 판단하고, 상기 판단결과로부터 상기 데이터 파일의 다운로드가 완료되지 않은 경우에는 상기 데이터 파일의 다운로드가 완료될 때까지 상기 데이터 파일의 다음 데이터 블록을 요구하되 상기 다음 데이터 블록에 포함되는 페이로드 데이터의 크기가 상기 최대 PDU 이하가 되도록 작성된 요구 메세지를 상기 콘텐츠 서버로 전송하는 제6a 단계, 상기 다음 데이터 블록의 요구 메세지에 대응하여 상기 콘텐츠 서버로부터 전달되는 응답 메세지를 수신하고 상기 응답 메세지로부터 상기 다음 데이터 블록을 획득하는 제6b 단계, 및 상기 다음 데이터 블록의 내용으로부터 상기 데이터 파일의 다운로드가 완료되었는지 여부를 판단하는 제6c 단계를 포함하는 과정을 반복하는 제6 단계; 및 상기 제5 단계와 제6 단계에서 수신된 하나이상의 데이터 블록으로부터 상기 데이터 파일을 구성하는 제7 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제14항에 있어서, 상기 데이터 파일의 다운로드 방법은 상기 제7 단계 이후에 상기 제7 단계에서 상기 데이터 파일을 구성함에 있어서 오류가 발생하였는지 여부를 검사하여 오류가 없다는 검사결과를 얻는 경우에 상기 데이터 파일의 다운로드가 성공하였음을 나타내는 메세지를 상기 콘텐츠 서버로 전송하는 제8 단계를 더 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제14항에 있어서, 상기 제3 단계는 상기 디스플레이된 화면 상에서 상기 사용자가 다운로드 가능 아이템을 선택하는 동작을 검출하는 제3a 단계; 상기 선택된아이템에 링크된 메세지를 파싱하여 현재 설정된 다운로드 경로상에서의 최대 PDU 정보 및 상기 선택된 아이템에 대응하는 데이터 파일의 사이즈 정보를 획득하는 제3b 단계; 및 상기 최대 PDU 정보와 상기 데이터 파일의 사이즈 정보, 그리고 상기 링크된 메세지를 사용하여 요구 데이터 블록의 크기가 상기 최대 PDU 이하가 되도록 상기 소정의 프로토콜에 따른 데이터 요구 메세지 코드를 작성하는 제3c 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
무선통신 기능을 구비한 단말기와 소정의 프로토콜에 따라 무선통신 연결되어 데이터 파일을 다운로드시키기 위한 방법에 있어서, 상기 단말기로부터 상기 소정의 프로토콜에 따른 통신연결의 요구 메세지를 수신하는 제1 단계; 상기 통신연결의 요구 메세지로부터 현재 설정된 다운로드 경로상에서의 최대 PDU 정보를 획득하는 제2 단계; 상기 통신연결의 요구 메세지에 대응하여 상기 단말기로 다운로드 가능 아이템 및 상기 아이템을 위한 데이터 파일의 식별자와 파일 사이즈 정보 및 상기 최대 PDU 정보를 포함하는 링크 메세지의 하나이상의 조합을 포함하는 디렉토리 페이지를 포함하는 응답 메세지를 전송하는 제3 단계; 상기 단말기로부터 상기 디렉토리 페이지의 상기 링크 메세지에서 나타낸 하나이상의 데이터 파일에 포함된 데이타 파일에 대한 다운로드를 요구하는 메세지를 수신하는 제4 단계; 상기 데이터 파일을 하나이상의 데이터 세그먼트로 분할하되 상기 데이터 세그먼트의 크기는 상기 최대 PDU보다 크지 않도록 구성하는 제5 단계; 상기 하나이상의 데이터 세크먼트 중에서 최초의 제1 세그먼트를 사용하여 제1 데이터 블록을 구성하고 상기 제1 데이터 블록을 사용하여 상기 다운로드 요구에 대한 응답 메세지를 구성한 후 상기 응답 메세지를 상기 단말기로 전송하는 제6 단계; 상기 데이터 세그먼트의 갯수가 2이상일 때 상기 데이터 세그먼트가 모두 전송될 때까지, 상기 단말기로부터 다음 데이터 블록의 다운로드를 요구하는 메세지를 수신하는 제7a 단계, 상기 다음 데이터 블록의 다운로드 요구 메세지에 대응하여 상기 하나이상의 데이터 세그먼트 중에서 다음 순서에 해당하는 다음 데이터 세그먼트를 사용하여 다음 데이터 블록을 구성하는 제7b 단계, 상기 다음 데이터 블록을 사용하여 상기 다음 데이터 블록의 다운로드 요구에 대한 다음 응답 메세지를 구성하는 제7c 단계, 및 상기 다음 응답 메세지를 상기 단말기로 전송하는 제7d 단계를 포함하는 과정을 반복하는 제7 단계를 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제17항에 있어서, 상기 데이터 파일의 다운로드 방법은 상기 제7 단계 이후에 상기 단말기로부터 상기 데이터 파일의 다운로드가 성공하였는지 여부를 나타내는 메세지를 수신하는 제8 단계를 더 포함하는 특징을 갖는 데이터 파일의 다운로드 방법.
제1항 또는 제5항 또는 제8항 또는 제10항 또는 제14항 또는 제17항 중 어느하나의 항에 따른 데이터 파일의 다운로드 방법을 구현하기 위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록매체.