KR20050059185A - 플러그인 소프트웨어를 사용하는 모바일 플랫폼의 기능성확장에 대한 방법과 시스템 - Google Patents

Abstract

무선통신 시스템에 대한 모바일 터미널과 같은 제품에 대한 플랫폼의 기능성 확장 그리고/또는 수정에 대한 방법과 시스템이 개지되었다. 본 발명의 시스템은 기능성을 제공하기 위한 소프트웨어 서비스 컴포넌트 및, 어플리케이션 도메인 소프트웨어가 최소한 하나의 인터페이스를 경유하여 플랫폼 내에 설치되고, 로드되고, 그리고 실행되게 하기 위한 상기 소프트웨어 서비스 컴포넌트의 기능성으로의 접근을 제공하기 위한 상기 최소한 하나의 인터페이스를 가지는 인터페이스 컴포넌트를 갖는 플랫폼 도메인을 포함한다. 상기 시스템은 또한 최소한 하나의 인터페이스를 경유하는 플랫폼 도메인의 소프트웨어 서비스 컴포넌트의 기능성 확장 그리고/또는 수정에 대한 어플리케이션 소프트웨어와 함께 사용하기 위한 플러그인 소프트웨어를 포함한다.

Description

플러그인 소프트웨어를 사용하는 모바일 플랫폼의 기능성 확장에 대한 방법과 시스템{Method and System for Extending the Functionality of A Mobile Platform Using Plug-In Software}

발명의 분야

본 발명은 일반적으로 무선 원격통신의 영역에 관한 것이다. 좀 더 구체적으로 본 발명은, 기준 기능성의 수정 없이, 무선 원격통신 시스템에 대한 모바일 터미널에 대한 플랫폼의 기능성 확장 및/또는 수정에 대한 방법과 시스템에 관한 것이다.

발명의 배경

고도의 배치능력을 제공하는 플랫폼은 최종 사용자 모바일 제품들의 많은 제작자들과 다른 플랫폼 고객들에 대해 흥미 있는 선택이다. 배치능력은 어떤 고객들이 원하는 기능성 같은 높은 레벨의 기능성에 관해서는 특별히 중요하며, 때때로 다른 사람들이 그들의 제품들에 기능성 같은 것을 포함하는데 있어 흥미를 가지지 않는 동안에 사내의 기능성으로 개발되는 것을 선호한다.

고도의 배치능력을 제공하는 모바일 터미널 플랫폼은 그러나 플랫폼의 제공자에 대하여 수많은 어려움을 내놓는다. 예를 들어, 제공자는 플랫폼에 추가되고 그들의 독특한 구성을 위해 특화된 플랫폼 참고문서의 이용과 제공하는 고객들에 의한 것과 같이 다른 고객들이 요구하는 다수의 구조들을 지원하는 어떤 높은 레벨 기능성을 지원해야만 한다. 또한, 플랫폼의 모든 구조들의 적절한 움직임이 예측되어질 수 없으므로, 그것은 고객에 의해 요구되는 추가적인 기능성 일들을 확실하게 하는 각각의 특별한 구성을 테스트하는 플랫폼 제공자를 위해 필요로 되어진다. 게다가, 많은 예들에서, 추가적인 기능성은 플랫폼 내에 공급되는 다른 기능을 위해서 논리적 종속 관계를 의존하며 가질 것이어서 만약, 후자의 기능이 제거되면, 추가적인 기능은 더 이상 적절하게 움직일 수 없다.

더구나, 플랫폼 제공자가 그것의 플랫폼 소유권의 상세한 기술을 유지하는 것을 원하는 예가 자주 있다. 이것을 달성하기 위해, 플랫폼 제공자는 코드 기준을 직접적으로 고객이나 어떤 다른 관계자에게 노출시키지 않아야만 한다. 대신에, 고객이 바라보는 플랫폼을 정해진 인터페이스와 정해진 작동을 갖는 "black box"과 같이 간단한 것을 선호한다.

고도의 배치능력을 갖는 터미널은 그러나, 플랫폼 소유권의 상세한 기술을 유지하는 것을 고려한 어려움을 줄 수 있다. 예를 들어, 그것은 플랫폼에 대한 고도의 애드온을 개발하기 위해 제3자와 계약하려는 플랫폼 제공자에 대한 통상의 관습이다. 플랫폼 제공자는 플랫폼과 함께 전해진 플랫폼에 대한 어플리케이션을 개발할 수 있다. 이러한 것이 일어나는 전형적 예는 높은 레벨 그래픽 라이브러리같이 자주 수행되는 사용자 인터페이스의 룩 앤드 필(look and feel)을 조절하는 기능성과 같은 제품 특화된 기능성을 고려한다. 룩 앤드 필은 브랜드 특화되기 때문에, 이 기능성은 제품들과 브랜드들 사이에서 달라질 것이다.

만약 제3자가 높은 레벨 애드온 개발을 위해 계약되었다 하더라도, 제3자에 대한 소유권 정보를 드러내는 제공자를 강화하면, 그 자는 기능성을 개발하기 위하여 플랫폼 코드 기준에 접근할 필요가 있을 것이다.

게다가, 플랫폼이 구성되고 고객에 전달된 후, 플랫폼의 기능성은 테스트되고, 안정화되며, 그리고 고정될 것이다. 그러나 아마도 고객은 전달된 플랫폼의 디자인에 의해 배제된 플랫폼의 수정, 확장, 그리고 구성을 고려하여 추가적인 요구를 할 것이다. 예를 들어, 고객은 제공된 기능성의 다양한 부분을 수정하고, 플랫폼을 맞추고, 특별히 필요로 하고, 전달된 플랫폼에 포함되는 것보다 더 힘 좋은 기능성을 더할 것을 바랄 수 있다. 즉, 기능성은 플랫폼 제공자가 플랫폼 도메인의 외부를 고려하는 것이다. 더구나, 고객은 플랫폼 기능성이 기본적 플랫폼 어셈블리 구성내의 플랫폼 제공자에 의한 제안보다 더 자세한 레벨로 구성되고, 또는 최종사용자가 지불할 것이 준비되는 것을 기반으로 한 플랫폼에 대해 기능성을 추가하거나 제거하는 극도의 미세한 구성의 어떤 형태를 수행할 것을 원할 수 있다.

일반적으로, 모바일 터미널들과 그리고 다른 제품들에 대한 현재의 플랫폼들은 상기 플랫폼의 기능성이 확장될 수 있고, 제거되고, 또는 다르게 변화하는 것에 의해 효율적인 공정을 제공하지 않는다.

발명의 요약

본 발명은 무선통신 시스템 또는 확장될 수 있고 다르게 변화할 수 있는 또 다른 제품에 대한 모바일 터미널에 대한 플랫폼의 기능성에 의한 방법과 시스템을 제공한다. 제품을 위한 플랫폼의 기능성 확장 및/또는 수정을 위한 시스템은 제공하는 기능성에 대한 소프트웨어 서비스 컴포넌트를 가진 플랫폼 도메인과 최소한 하나의 인터페이스를 경유하여 상기 플랫폼 내에 설치되고, 로드되고, 그리고 실행되는 가능한 어플리케이션 도메인 소프트웨어에 대한 소프트웨어 서비스 컴포넌트의 기능성에 대해 제공하는 접근에 대한 상기 최소한 하나의 인터페이스를 가진 인터페이스 컴포넌트를 포함한다. 시스템은 또한 최소한 하나의 인터페이스를 경유하여 플랫폼 도메인의 소프트웨어 서비스 컴포넌트의 기능성 확장 및/또는 수정을 위한 어플리케이션 소프트웨어에 의한 사용에 대한 플러그인 소프트웨어를 포함한다.

제품을 위한 플랫폼의 기능성 확장 및/또는 수정을 위한 방법은 제공하는 기능성에 대한 소프트웨어 서비스 컴포넌트를 가진 플랫폼 도메인을 제공하는 단계와 최소한 하나의 인터페이스를 경유하여 상기 플랫폼 내에 설치되고, 로드되고, 그리고 실행되는 가능한 어플리케이션 도메인 소프트웨어 에 대한 소프트웨어 서비스 컴포넌트의 기능성에 대해 제공하는 접근에 대한 상기 최소한 하나의 인터페이스를 가진 인터페이스 컴포넌트를 포함한다. 방법은 또한 최소한 하나의 인터페이스를 경유하여 플랫폼 도메인의 소프트웨어 서비스 컴포넌트의 기능성 확장 및/또는 수정을 위한 어플리케이션 소프트웨어와 함께 플러그인 소프트웨어를 제공하는 단계를 포함한다.

본 발명의 한층 더한 장점과 특별한 상세한 기술은 첨부한 도면과 관련하여 주어진 상세한 서술로부터 명백하게 될 것이다.

도면의 간단한 설명

제1도는 본 발명의 원리 설명에 도움을 주는 무선통신 시스템에 대한 모바일 터미널에 대한 플랫폼 시스템을 도식적으로 도해한 블록 다이어그램이다.

제2도는 본 발명의 원리 설명에 더 도움을 주는 도 1의 플랫폼 시스템의 모바일 터미널 플랫폼 어셈블리의 배치도를 도식적으로 도해한 블록 다이어그램이다.

제3도는 본 발명의 원리 설명에 더 도움을 주는 도 1과 도 2의 모바일 터미널 플랫폼 어셈블리의 소프트웨어 구조를 도식적으로 도해한 블록 다이어그램이다.

제4a도는 도 1 내지 도 3의 미들웨어 서비스 계층의 상세한 기술을 도식적으로 도해한 논리적 블록 다이어그램이다.

제4b도는 도 4a의 블록 다이어그램의 실행도이다.

제5도는 개방 플랫폼 API(OPA) 도메인의 주요 소프트웨어 모듈을 도식적으로 도해한 블록 다이어그램이다.

제6a도와 제6b도는 개방 플랫폼 API(OPA) 도메인의, 각각의, 논리적인 실행도를 도식적으로 도해한 블록 다이어그램이다.

제7a도와 제7b도는 콜백모드와 풀 메시지 모드 각각에 따르는 메시지 모델을 수행하는 플러그인 모델에 대한 순서를 도식적으로 도해한 다이어그램이다.

발명의 구체예에 대한 상세한 설명

도 1은 본 발명의 원리 설명에 도움을 주는 무선통신 시스템에 대한 모바일 터미널에 대한 플랫폼 시스템을 도식적으로 도해한 블록 다이어그램이다. 플랫폼 시스템은 일반적으로 참조 번호(10)로 표시되고 모바일 터미널 플랫폼 어셈블리(12), 그리고 상기 모바일 터미널 플랫폼 어셈블리 내에 설치되고, 로드되고, 그리고 실행되었던 하나 또는 그 이상의 어플리케이션(즉, 어플리케이션 소프트웨어)(14)을 포함한다. 플랫폼 시스템(10)은 점선(16)에 의해 일반적으로 디자인된 모바일 터미널 내에 병합되도록 적응된다. 모바일 터미널 플랫폼 어셈블리(12)는 소프트웨어 서비스 컴포넌트(22), 하드웨어 컴포넌트(24), 그리고 인터페이스 컴포넌트(26)를 포함한다. 소프트웨어 서비스 컴포넌트(22)는 인터페이스 컴포넌트(26)를 경유하여 사용자에게 제안하는 서비스를 제공하기 위한 복수의 잘 구성된 기능적 소프트웨어 단위들을 포함한다. 도 1에 도시된 전형적인 시스템(10)내에서 복수의 소프트웨어 단위들은 복수의 수직배향의 기능적 소프트웨어 스택들(30-38)을 포함한다.

도 1에 도시된 전형적인 시스템(10)내에서 하드웨어 컴포넌트(24)는 그들의 각각의 기능적 소프트웨어 스택들(30-38)에 의해 연합되고 조절되는 일련의 하드웨어 블록들(40-48)을 포함한다. 인터페이스 컴포넌트(26)는 모바일 터미널 플랫폼 어셈블리(12)내의 설치, 로딩, 그리고 실행하는 하나 또는 그 이상의 어플리케이션들(14)을 위한 최소한 하나의 어플리케이션 프로그래밍 인터페이스(API)를 포함하고, 상기 모바일 터미널 플랫폼 어셈블리(12)를 사용하는 상기 어플리케이션들(14)로부터 상기 모바일 터미널 플랫폼 어셈블리(12)를 분리하고, 그리고 상기 어플리케이션들(14)에 대한 다양한 다른 서비스들을 제공하는 미들웨어 서비스 계층을 포함한다.

플랫폼 시스템(10)의 모바일 터미널 플랫폼 어셈블리(12)는 완벽하게 디자인되고, 설치되고(조합되고) 그리고 테스트되도록 적응되고, 어플리케이션 소프트웨어(14)(용어 "어플리케이션 소프트웨어"는 여기서 사용자들이 사용하는 것을 원하는 기능성을 제공하는 어떠한 소프트웨어에도 쓸 수 있다)로부터 둘러싼 단위를 분리한다. 따라서 사용자들은 그들 자신의 어플리케이션 소프트웨어를 개발하거나 다르게 획득할 수 있고 그리고 플랫폼 시스템(10)을 완벽하게 하기 위해 더 나중의 시간에 모바일 터미널 플랫폼 어셈블리(12)에 대한 소프트웨어를 추가할 수 있다. 따라서 모바일 터미널 플랫폼 어셈블리(12)는 판매될 수 있고 또는 플랫폼 시스템에 대해 그들 자신의 특별한 필요조건들을 만족시키기 위해 어셈블리 내의 그들 자신의 어플리케이션 소프트웨어를 설치, 로딩, 그리고 실행하는 것에 의해 플랫폼 시스템(10)을 완벽하게 할 수 있는 각각의 복수의 다른 사용자들에게 다르게 전해질 수 있다.

도 2는 본 발명의 원리 이해에 더 도움을 주는 도 1의 모바일 터미널 플랫폼 시스템(12)의 배치도의 한 예를 도식적으로 도해한 블록 다이어그램이다. 도 2에 도시된 바와 같이, 모바일 터미널 플랫폼 어셈블리(12)는 주 CPU(50) 내의 소프트웨어 실행을 경유하여 조절된다. 주 CPU(50)는 마이크로프로세서들, 마이크로 프로그래머블 프로세서들(micro programmable processors) 또는 DSPs(디지털 신호 프로세서(Digital Signal Processors))와 같은 하나 또는 그 이상의 프로세서들을 포함할 수 있다. 소프트웨어 컴포넌트(22)의 소프트웨어 스택들(30-38)은 각각의 스택과 결합한 하드웨어 유닛들을 실행하는 하드웨어 드라이브 소프트웨어(60-68)를 각각 포함한다. 모바일 터미널 플랫폼 어셈블리(12)와 플랫폼 시스템(10)의 더 상세한 기술이 U. S. Patent Application Serial No. 10/359,835에 자세히 설명되어 있으며, 본 명세서에서는 그 내용 모두가 포함되는 것으로 참조한다.

모바일 터미널 플랫폼 어셈블리(12)내에 병합된 소프트웨어는 그것을 좀 더 쉽게 디자인할 수 있고, 좀 더 쉽게 업그레이드 또는 수정할 수 있게 하기 위하여 소프트웨어 구성을 이해하기 쉽게 만드는 것에 관한 어떤 방법으로 배열하는 것을 선호한다. 도 3은 본 발명의 원리 설명에 더 도움을 주는 모바일 터미널 플랫폼 어셈블리(12)의 소프트웨어 구조를 도식적으로 도해한 블록 다이어그램이다.

도 3에서 볼 수 있는 바와 같이, 복수의 버티컬에 추가적으로 구성된, 상술한 기능적 소프트웨어 스택들, 소프트웨어 서비스 컴포넌트(22)는 또한 미들웨어 서비스 계층의 소프트웨어와 상기 소프트웨어 서비스 컴포넌트(22)의 소프트웨어를 합쳐 계층 구조를 명확히 하고, 일반적으로 참조 번호 70에 의해 표시되고, 계층들은 낮은 레벨 서비스 계층에 대한 높은 레벨 서비스 계층으로부터 내림차순으로 배열된 복수의 수평 계층을 명확히 하기 위해 배열된다.

소프트웨어 구조는 표준 ISO/OSI(ISO Open Systems Interconnection) 모델과 그것이 복수의 수직적으로 분할된 소프트웨어 계층의 보충물인 복수의 수평적으로 분할된 기능적 소프트웨어 유닛들을 포함한다는 점에서 다르다

계층 구성의 가장 높은 계층은 인터페이스 컴포넌트(26)의 일부분인 미들웨어 서비스 계층이다. 소프트웨어 서비스 컴포넌트(22)의 계층들은 어플리케이션 서비스를 제공하는 어플리케이션 서비스 계층(80), 어플리케이션을 위한 플랫폼 특별한 서비스를 제공하는 플랫폼 서비스 계층(82), 세션 프로토콜들과 어플리케이션 특별한 프로토콜들을 제공하는 플랫폼 프로토콜 계층(84), 오디오 접근/조절을 제공하는 운송 계층(86), 데이터컴(datacom) 운송 프로토콜들, 메시징(messaging) 운송 프로토콜들과 그것과 비슷한 것, 외부의 데이터 IF 접근을 제공하는 데이터 접근 계층(88), 구조적 저장 서비스와 다른 낮은 레벨 플랫폼 지지 서비스들, 논리적 드라이버 계층(90)과 하드웨어 종속관계로 조심스럽게 보호되는 물리적 드라이버 계층(92)을 포함한다. 게다가 소프트웨어 서비스 컴포넌트(22)는 플랫폼 어셈블리(12)에 의해 필요로 되어지는 일반적 서비스를 제공하는 기본 시스템 서비스 계층(94)을 포함한다.

바닥의 두 계층들(90과 92)은 소프트웨어와 하드웨어 사이의 종속관계를 분리시키는 하드웨어 추출 계층들(Hardware Abstraction Layers(HAL))로 구성된다. 단지 물리적 드라이버 계층이 하드웨어(즉, 어드레스된 ASIC 하드웨어내의 레지스터들)의 상세한 기술에 관련된다. 논리적 드라이버 계층(90)은 하드웨어에 대한 논리적 맵핑(mapping)을 제공한다. 즉 이 계층은 모바일 터미널 플랫폼 어셈블리의 하드웨어와 소프트웨어 부분들 사이에 브리지(bridge)를 제공한다.

소프트웨어 그 자체는 복수의 소프트웨어 모듈들, 도 3에 특별하게 나타내어진 모듈들 102, 104, 106으로 구성된다. 소프트웨어 서비스 컴포넌트(22)내에서, 한 단일 모듈은 단지 하나의 수직의 기능적 스택과 그 스택 내의 단지 하나의 수평적 계층에 거주할 수 있다. 각 계층은 하나에서부터 많은 모듈들을 포함할 수 있고, 특별한 스택 내에서 특별한 계층 안의 모든 모듈들은 추출의 같은 레벨을 가진다. 다양한 모듈들 사이의 통신은 소프트웨어 모듈에서 모듈까지(module to module) 접근에 대한 일련의 기본적 규칙에 좌우된다. 이러한 규칙들은 하기와 같이 요약될 수 있다:

- 소프트웨어 모듈은 그 자신의 계층 하위의 모든 계층 인터페이스 내의 기능성(functionality)을 불러올 수 있다.

- 직렬 데이터 흐름의 방향에 대한 제한은 없다. 이는 어떠한 방향으로도 가능하다.

- 소프트웨어 모듈은 그 자신의 계층 상위의 계층 인터페이스(SwBP(112) 내) 내의 기능성을 그 계층이 포함하는 모듈에 관계없이 불러올 수 없다.

- 소프트웨어 모듈은 동일한 수직 스택 내의 자신의 계층 내에서 계층 인터페이스 내의 기능성을 불러올 수 있다.

- 소프트웨어 모듈은 다른 수직 스택 내의 동일한 계층에서 소프트웨어 모듈 내의 기능성을 불러올 수 있다. (이러한 성능은 수직 스택 내의 계계층의 수를 제한하도록 승인된다.)

SwBP내에서 다양한 모듈들과 인터페이스들 사이에서는 어려운 커플링은 없다. 결과적으로, 인터페이스의 모듈들 및/또는 기구는 인터페이스들에 대한 고객들에게 강한 영향을 주지 않고 자유롭게 변화할 수 있다. 이러한 능력은 플랫폼 어셈블리 내에서 다른 모듈들에 영향을 받지 않고 개개의 모듈들이 추가되고, 제거되고 또는 변화되는 것을 허용한다. 모바일 터미널 플랫폼 어셈블리 내의 모듈들 사이에 내부적 통신을 할 수 있는 SwBP 소프트웨어 구조를 포함하는 계층으로 된 구조의 좀 더 상세한 기술은, 미국 특허 출원 제10/359,911호에 자세히 설명되어 있으며, 본 명세서에서는 그 내용 모두가 포함되는 것으로 참조한다.

모바일 터미널 플랫폼 어셈블리(12)내의 소프트웨어와 어플리케이션 소프트웨어(14)사이에 잘 정의된 인터페이스를 제공하기 위한 미들웨어 서비스 계층 기능은 플랫폼 어셈블리 내에서 설치되고, 로드되고, 그리고 실행된다; 그리고 추가적으로 모바일 터미널 플랫폼 어셈블리(12)를 둘러싸고, 미들웨어 서비스 계층을 경유한 어플리케이션으로부터 어셈블리를 분리하고, 그리고 어플리케이션(14)을 위해 다양한 다른 서비스들을 공급한다.

도 4a는 도 1-3의 인터페이스 컴포넌트(26)의 미들웨어 서비스 계층의 상세한 기술을 도식적으로 도해한 논리적 블록 다이어그램이다. 도 4a에서 도시한 바와 같이, 미들웨어 서비스 계층은 넌네이티브(non-native) 환경 예를 들어, 자바 수행(Java Execution(Java ExE))환경 도메인(206), 개방 어플리케이션 프레임워크(Open Application framework(OAF)도메인(204), 개방 플랫폼 API(Open Platform API(OPA)도메인(206) 그리고 UI 툴 키트(UI Tool-kit)도메인(208)을 포함하는 복수의 API 도메인을 포함한다. 미들웨어 서비스 계층 내의 APIs를 통해, 모바일 터미널 플랫폼 어셈블리는 복수의 어플리케이션 환경을 지원한다. 도 4a의 전형적인 구체예에서, 미들웨어 서비스 계층은 네이티브(native) 어플리케이션(어플리케이션은 특별한 프로세서와 그것의 명령 세트와 함께 실행을 위해 컴파일된다)과 자바 J2ME CLDC/MIDP(자바 2 미세 판 연결 제한 장치 구조/모바일 정보 장치 프로파일(Java 2 Micro Edition Connected Limited Device Configuration/ Mobile Information Device Profile))어플리케이션과 같은 넌네이티브 어플리케이션을 위해 환경들을 지원한다. 각각의 수행 환경은 그것 자신의 특색을 갖고 다음과 같이 정의된다.

- 어플리케이션이 개발되는 방식(프로그래밍 언어 지원, 컴파일레이션(compilation) 및 링키지(linkage))

- 어플리케이션이 실행되는 방식(예를 들어, 해독(interpretation) 또는 네이티브 코드 실행)

- 제공되는 기능 서비스.

- 사용에 있어 잠재적인 제한.

복합의 어플리케이션 환경 대안의 제안에 의하여, 비용, 쉬운 사용법, 판매를 위한 시간, 기능성 세트, 크기, 휴대성 등과 같은 다양한 요구와 함께 제품의 광대 영역이 촉진된다. 각각의 API 도메인은 복수의 소프트웨어 모듈들을 포함하며, 상기 도메인의 다양한 상세한 기술이 미국 특허 출원 제10/359,772호에 자세히 설명되어 있으며, 본 명세서에서는 그 내용 모두가 포함되는 것으로 참조한다.

도 4b는 어플리케이션 도메인(500)과 미들웨어 도메인(501)의 실행도이다. 그것은 플러그인 A(510)과 플러그인 B(512)의 두 개의 플러그인들을 묘사하고 있으며, 둘 다 모두 미들웨어 도메인(501)의 개방 플랫폼 API(514)의 서비스들을 확장 및/또는 수정하기 위한 어플리케이션 도메인 내에 속한다. 플러그인 A(510)는 플러그인 B(512)가 개방 플랫폼 API(514)와 같은 플러그인 A(510)상에 의존하는 동안 단지 개방 플랫폼 API(514)상에 의존할 수 있다. 네이티브 어플리케이션(508)과 넌네이티브 어플리케이션(506)은 둘 다 모두 개방 플랫폼 API(514)상과 같은 플러그인 A(510)상, 플러그인 B(512)상에 의존할 수 있다. 넌네이티브인 환경의 예(예를 들어, 자바 가상 기계(a Java Virtual Machine)), 어플리케이션의존은 직접적이지 않고, 어떤 의미에서 어플리케이션(506)은 넌네이티브인 환경(504)에 의존한다. 넌네이티브인 환경(504)은 플러그인 A(510)상, 플러그인 B(512) 또는 개방 플랫폼 API(514)상에 의존한다.

도 5는 본 발명의 구체예에 따른 개방 플랫폼 API(OPA) 도메인(206)의 주요 소프트웨어 모듈을 도식적으로 도해한 블록 다이어그램이다. 묘사된 바와 같이, OPA 도메인(206)은 네이티브 환경 관리(a Native Environment Management(NEM))모듈(230), 네이티브 어플리케이션 코어(a Native Application Core(NAC))모듈(232), OPA 인터페이스와 핸들러(OPA Interface and Handler)모듈(234), 미들웨어 지원 서비스 모듈(236) 그리고 네이티브 확장 플러그인 모듈(들)(238)의 다섯 개의 모듈을 포함한다.

네이티브 환경 관리 모듈(230)은 플랫폼 시스템(10)내의 네이티브 어플리케이션을 조절하는 책임을 진다. 그것은 조절의 수신기에 관계되는 네이티브 어플리케이션들을 명령하고, 시스템 내에서 현재 실행되고 있는 네이티브 어플리케이션의 추적을 유지한다.

네이티브 어플리케이션 코어 모듈(232)은 어플리케이션들이 그들 자신을 다르게 핸들하는 스레딩과 메시지-핸들링 복잡성을 관리하고 유의하여 다룬다. 메시지 루팅(routing)/필터링(filtering)과 공급원 핸들링과 관련된 메시지를 포함하는 NAC 모듈(232)은 또한 실행 시간의 복잡성으로부터 어플리케이션을 완화하기 위해 OS의 기구의 상세한 설명을 간단히 하는 것에 의해 OS 독립의 달성의 목적을 증진시킨다. 게다가 또 다른 중요한 네이티브 어플리케이션 코어의 책임은 메시지 핸들링 내의 시동의 상세한 기술을 간단히 하고 어플리케이션의 위상을 중지하는 것이다.

미들웨어 지원 서비스 모듈(236)은 다른 핸들러를 위해 공통되거나 또는 예를 들어, 대상의 관리와 공급원 관리 같은 집중화 되는 것을 필요로 하는 OPA 도메인으로의 서비스를 제공한다.

네이티브 확장 플러그인 모듈(들)(238)은 플랫폼 어셈블리(12)의 제공자를 위한 유연한 확장 가능성을 제공한다. 플러그인은 사실상 추가적 인터페이스들의 제공과 최종 사용자 장치 제작자 또는 또 다른 파티에 의해 써진 어플리케이션 소프트웨어(14)에 대한 추가적인 서비스에 의한 플랫폼 어셈블리의 기능성을 확장한다.

도 5가 개방 플랫폼 API(OPA)도메인(206)의 모듈과 같은 플러그인을 묘사한 논리도인 동시에, 도 6은 복수의 개방 플랫폼 API 모듈들(242, 244, 246) 그리고 본 발명의 또 다른 전형적인 구체예에 따른 플러그인 모듈(250)을 가진 좀 더 일반적인 개방 플랫폼 API(OPA)도메인(240)의 표현을 묘사한 논리도이다. 이 논리도 내에서 플러그인(250)은 또한 고객의 관점으로부터 개방 플랫폼 API(240)내에 일부분이 된 것처럼 보이기 때문에, 플러그인(250)은 플랫폼 어셈블리의 미들웨어 서비스 컴포넌트(260)내의 상기 개방 플랫폼 API(240)의 부분처럼 행동하고 나타날 것이다. 그러나 실제로 플러그인(250)은 플랫폼 어셈블리(12)의 꼭대기상의 어플리케이션 소프트웨어 도메인(270)내에서 실행하는 독립하여 조작이 가능한 존재를 포함하며, 그것은 상기 플랫폼 어셈블리에 의해 제공되는 기능성을 사용한다. 따라서 기구의 관점으로부터, 그것은 도 6의 실행도 내에 묘사한 바와 같이 플랫폼 어셈블리 기능성으로 접근하기 위한 개방 플랫폼 API를 사용하며 플랫폼 어셈블리의 위에 위치한다.

플러그인은 플랫폼 어셈블리에 의해 지원되는 모든 어플리케이션 소프트웨어 메커니즘들을 지원하고, 상기 플랫폼 어셈블리 내에서 정제된 어플리케이션 모델을 함께 컴파일 한다. 바꾸어 말하면, 플러그인은 개방 플랫폼 API에 의해 전해진 제공된 OPA 서비스와 같은 동일한 패러다임과 부착할 것이다. 이것들은 다음을 포함하나 제한되지 않는다.

● 인터페이스들과 컴포넌트들이 어떻게 정의되고 수행되는지의 점에서 컴포넌트 모델 컴플라이언스. 플러그인은 컴포넌트와 같이 실행되고 정의된 기능 또는 방법에 근거한 인터페이스를 통한 최종 제품 어플리케이션 소프트웨어로 그 자체의 서비스를 제공할 것이다.

● 컨벤션 컴플라이언스 명명(Naming convention compliance). 플러그인은 개방 플랫폼 API과 같은 인터페이스 방법들에 대한 같은 이름의 컨벤션을 사용한다. 또한 파라미터들과 이러한 인터페이스 방법들 내에 정의된 타입들 둘 다 개방 플랫폼 API 내에서 사용된 이름의 컨벤션을 따를 것이다.

● 원하지 않는 사건(Undesired-event) 핸들링 컴플라이언스. 플러그인은 플랫폼과 같은 방법 내에서 기능의 가능한 잘못된 작용을 핸들링할 것이다. 어떤 에러에 대한 정보는 개방 플랫폼 API내와 같은 동일한 패러다임을 따라 어플리케이션 소프트웨어로 전달된다.

● 메시지 모델 컴플라이언스. 플러그인은 비동시적인 요구들, 콜백, 그리고 풀 메시지 모드(full message mode) 서비스에 기인하는 전달에 대한 두 개의 모드를 지원할 것이다.

● 패러다임에 근거한 객체와 인터페이스

상술한 거의 맨 마지막 점에 관하여, 메시지 모델 컴플라이언스는 플러그인의 작용과 어떻게 플러그인이 구성되었는가에 대하여 중대한 영향을 갖는다. 구체적으로, 플랫폼 어셈블리 메시지 모델은 비동시적 서비스 요구에 기인하고 사건 청약에 기인한 수신을 받기 위한 어플리케이션 소프트웨어를 위한 이중의 모드를 제공한다. 이중의 모드는 콜백 메커니즘(콜백 모드)을 경유하거나 메시지 대기 행렬(풀 메시지 모드)을 경유하여 결과가 수신되었음을 암시한다. 이것은 어플리케이션 기능성의 본성에 의존하고, 다른 메시지 모델들에 따른 다른 어플리케이션들 구조에 플랫폼 어셈블리 고객 소프트웨어 개발자에 대한 유연성과 자유도를 제공한다.

어플리케이션은 상기 어플리케이션이 리턴 스테이트먼트의 수행, 또는 수행이 아닌 것에 의해 비동시적인 결과를 수신하려는 메시지 모드를 결정한다. 만약 어플리케이션이 콜백 모드에서 결과를 받는 것을 결정했다면, 어플리케이션은 비동시적인 서비스 요구가 완전해진 후에 수행 조절로 돌아온다. 만약 결정이 풀 메시지 모드로 가는 것이면 어플리케이션은 서비스 요구 뒤에 수행 조절로 돌아오는 것이 아니라 메시지 대기 행렬을 폴하고 홀로 메시지 핸들링 코드를 수동적으로 일깨운다. 이러한 해결책의 또 다른 장점은 이것이 필요로 되거나 또는 어떤 문제 또는 상황에 대해 요구되는 예에서, 어플리케이션이 콜백과 실행시간 내에서 풀 메시지 모드의 어떤 점 사이에 실질적으로 변화할 수 있다는 것이다.

플러그인 모델은 메시지 모델의 이중의 모드와 컴플라이언스하고, 고객의 어플리케이션 소프트웨어에 명백하게 이러한 유연성을 제공할 수 있다. 본 발명의 전형적인 구체예에 따른 이러한 컴플라이언스를 완성시키기 위한 순서는 콜백 모드에 대한 순서(310)를 도식적으로 도해한 도 7a, 풀 메시지 모드에 대한 순서(320)를 도식적으로 도해한 도 7b내에 도식적으로 도해하였다. 이러한 순서도는 개방 플랫폼 API(OPA)(316), 플러그인(또는 유용한 것)(314) 그리고 서비스를 요구하는 어플리케이션(312) 사이의 관련성을 준다.

1. 고객 어플리케이션은 시동에서의 OPA로부터 수행 조절을 수신 할 것이다. 그것은 또한 플러그인 서비스를 OPA 서비스(플랫폼 어셈블리 기능적)를 초기화하기 위해 사용되는 동일한 패러다임에 따라 초기화하기 위해 임의적으로 요구된다. 플러그인 인터페이스가 "IX"로 호칭될 때(즉, 다시 말해서 플러그인으로부터의 서비스는 어플리케이션에 의해서 요구된다), 플러그인은 직무를 수행하는 하나 또는 여러 개의 OPA 서비스 인터페이스들 "IX"에 의존할 것이다. 도 7a와 도 7b를 유의하여 보면, 이러한 서비스 요구 단계들은 콜백 모드와 풀 메시지 모드 둘 다에 대하여 동일하다.

2. 어떻게 고객 어플리케이션이 결과를 수신하는지는 도 7a와 도 7b에서 318에 의해 나타내어지는 바와 같이 OPA(콜백 모드(310))에 대한 수행 조절이 돌아오거나 또는 풀 메시지 모드(320)를 경유한 메시지에 대해 폴(poll)하는 것에 의존한다.

3. 플랫폼 어셈블리는 서비스 "IX"는 플러그인과 예를 들어 322에 따른 핸들 메시지 방법(Handle Message Method)과 같은 플러그인 방법의 일깨움에 의해 상기 플러그인에 대한 결과로 돌아올 것이라고 알고 있다. 플러그인은 도 7에 나타낸 바와 같이 플랫폼 어셈블리 결과로부터 메시지 포맷으로 변환될 것이고, 플랫폼 어셈블리로 돌아온 이 메시지는 이 예에서 OPA(316)에 의해 나타내어진다. 만약 어플리케이션이 결과의 핸들링과 전달의 속도를 증진시킬, 단지 콜백 모드 내의 수신 메시지를 원하는 플러그인으로 나타내어진다면 이 단계는 생략되어야 함을 유의하라. 플랫폼 어셈블리는 결과에 대하여 어플리케이션이 기다리고 결과에 따라 돌아올 것인 메시지 모드를 알고 있다. 활성인 모드에 의존하여 최소한 두 개의 시나리오가 가능하다.

● 만약 어플리케이션이 도 7a에 따라 콜백 모드(310)내이면, 그 결과는 콜백 모드 "ICBY_OnService"내에 주어질 것이다. 이러한 예에서 플러그인은 절차 콜을 사용하는 스택을 경유하여 돌아올 수 있는 결과를 처리하고 포맷할 것이다.

● 만약 어플리케이션이 도 7b에 따라 풀 메시지 모드(320)내이면, 그 결과는 핸들 메시지(Handle_Message(322)) 단계내의 플러그인에 의해 창조된 메시지를 사용하여 전달될 수 있다. 플러그인이 OPA(316)로 포맷된 메시지 내의 결과를 리턴시, OPA는 그것 때문에 전달되는 결과인, Get_Message로부터 어플리케이션(312)으로 차례로 리턴 조절할 것이다.

본 발명의 이론에 따른 플러그인 모델과 함께, 모바일 터미널 플랫폼의 기능의 변화에 관한 상술한 문제점이 극복되었다. 예를 들어, 높은 레벨의 실행을 위한 OPA 플러그인들을 사용하여, 기본적 및/또는 최종 사용자 제품들의 필요들을 커버하는 것에 고려되는 디폴트(default)된 플랫폼 기능을 여전히 포함하는 플랫폼 제공자는 슬리머(slimmer)하고 좀 더 안정한 플랫폼을 제공할 수 있다. 이것은 비표준화 추가적 기능성이 플러그인과 같이 공급되기 때문에, 어플리케이션 도메인과 최종 사용자 제품들 그리고 다른 고객들에게 좀 더 가깝게 되어 관련된 특별한 제품에 의존하여 쉽게 추가/제거가 가능한, 높은 레벨 기능성의 관리를 가져온다.

추가적으로, 본 발명의 구체예와 함께, 제3의 파티 개발자들은 제3의 파티 개발자들 또는 다른 사람들에게 플랫폼 코드 베이스에 관계되는 적절한 정보가 밝혀질 필요가 없이 하나 또는 여러 개의 플러그인들과 같이 추가적 기능성을 수행할 수 있다. 구체적으로, 플러그인이 어플리케이션 도메인 소프트웨어의 존재이므로, 제3의 파티 개발자는 단지 디폴트/기본적 플랫폼 API을 사용하도록 선택할 수 있다.

상술한 플러그인 기술을 활용하여, 플랫폼 어셈블리의 제공자는 고객다시 말해, 하나 또는 여러 개의 홀로 서있는 플러그인들에 대한 코드 베이스가 단지 조절되고 바쳐진 부분을 노출시키는 것을 선택할 수 있다. 제공자는 아마도, 예를 들어, 플러그인의 기능성과 작용을 적응시키기 위해 상기 플러그인의 코드를 변화하고 수정할 수 있는 고객에 대해 소스 코드와 같은 상기 플러그인을 제공하는 것을 선택할 것이다.

높은 레벨의 기능성과 복수의 플러그인들을 공급하는 것에 의해, 최종 사용자 제품 제조자 또는 다른 파티는 플랫폼 어셈블리의 기능성을 확장시키는데 있어 용이해진다. 그것은 또한 플랫폼 제공자가 플랫폼 어셈블리의 기본적 기능성 제공의 부분에 대해 고려하지 않은 상기 플랫폼 어셈블리에 대한 제조자의 특별한 확장에 대한 전달을 가능하게 한다.

확장된 기능성과 복수의 플러그인들을 공급하는 것에 의하면, 그것은 또한 플랫폼 어셈블리의 "last minute" 구성을 수행하는 것, 예를 들어, 다른 제품들로부터 다른 부산물을 필요로 하는 것에 대해 플랫폼 어셈블리를 적응시키고, 또는 구매시간 당시에 최종 사용자 제품을 개별화하는 것을 용이하게 한다. 본 발명의 구체예와 함께, 그것은 플랫폼 제공자 플러그인들을 사용하는지 또는 사내에서 기능성을 개발하는지 여부에 대해 전의 결정을 하기 위해 플랫폼 어셈블리를 사용하는 최종사용자를 용이하게 할 것이다.

상술한 바와 같이, 제품 플랫폼의 높은 레벨 기능성 있는 예는 외관을 조절하고 사용자 인터페이스의 필인 기능성 같은 제품 특성 기능성에 관하여 요구되어질 것이다. 진보된 사용자 인터페이스와 모바일 터미널 그리고 다른 특징화된 소비자 제품들을 위해, 사용자 인터페이스의 룩 앤드 필은 시장에서 제품의 차별화와 위치를 위한 중요한 열쇠이며, 그리고 결과적으로 상업적 성공을 위하여 중요하다. 따라서 제품의 룩 앤드 필의 정의에서 수많은 자유도를 제공하는 모바일 터미널을 위한 플랫폼 그리고 다른 제품들이 요구된다.

룩 앤드 필의 정의로부터 윈도잉 시스템 코어(windowing system core)의 분리는 증명되고 널리 사용된 개념이다. X 윈도우 시스템은 여기 설명되었고, 그리고 이러한 구성의 타입을 사용하여 동일한 윈도우 시스템의 최상위에 세워질 수 있는 매우 다른 룩 앤드 필의 시스템의 다양한 예가 있다. 한편으로는, 주어진 수행의 룩 앤드 필을 변경하는 능력은 제한된다.

자바 VM의 포팅(porting)은 전통적으로 UI 서포트의 낮은 레벨에서 수행된다. 높은 정도로의 룩 앤드 필은 자바내의 그래픽 객체의 수행에 의해 정의된다. MIDP(Mobile Information Device Profile)의 소개는 그래픽 객체가 추출 레벨에서 단지 정의되는 곳에서 또 다른 시도를 제안한다. 룩 앤드 필은 VM이 수행되는 기본적인 시스템 상에 의해 정의된다. 만약 자바의 외부에서 수행하는, 자바 어플리케이션과 다른 어플리케이션들 사이의 룩 앤드 필 일치는 성취되며, 동일한 그래픽의 객체들 세트도 양쪽을 위해 사용될 수 있다. 이것은 정의된 룩 앤드 필과 시스템을 향해 곧장 나아간다.

모바일 장치 내의 자바 VM은 이상적으로 MIDP 상술을 따라서 UI 서포트를 제공하기 위해 수행되는 플랫폼에 의지한다. 이것은 자바 VM을 포함하는 모바일 플랫폼에 대한 것을 의미하며, MIDP 서포트는 또한 플랫폼의 부분이 되어야 한다. 다른 말로 하면, 다른 매각인으로부터 높이 프로파일드되는(profiled) 것을 위해 의도된 플랫폼에 대하여, 룩 앤드 필 상의 조절의 가장 높은 가능한 레벨을 제공하는 것이 중요하다. 명백하게, 조절의 가장 높은 레벨은 그래픽 객체의 정의의 조절을 통해서 달성되어진다. 플랫폼 상의 이러한 두 개의 충돌되는 필요는 이전의 묘사된 접근들로 만족되어질 수 없다.

본 발명의 더 전형적인 구체예에 일치하여, 그래픽 객체의 세트와 유틸리티들은 개방 플랫폼 API(OPA)내에서 하나 또는 그 이상의 플러그인들과 같이 정의된다. 하나 또는 그 이상의 플러그인들에 대한 인터페이스들은 고정되고 MIDP 서포트에 대하여 충분해야만 하나, 수행은 자유롭게 변경될 수 있다.

본 발명의 이론과 일치하여, 높은 레벨 그래픽 객체와 유틸리티들의 수행은 네이티브 어플리케이션과 자바와 같은 수행 환경 사이에서 공유될 수 있다. 같은 시각에, 그래픽 사용자 인터페이스의 외관과 수행의 플랫폼 고객의 조절은 매우 높다.

본 발명의 구성된 전형적인 구체예가 묘사되는 동안에, 상기 발명은 그 자신의 영역으로부터 떨어짐이 없이 많은 방법으로 다양해질 수 있다는 점을 이해해야 한다. 예를 들어, 비록 본 발명이 기본적으로 특별한 모바일 터미널 플랫폼 어셈블리와 관련되어 묘사되었다 할지라도, 그것은 본 발명이 모바일 터미널과 다른 제품들을 위한 다른 플랫폼이 또한 사용되는 만큼 본 발명을 제한하는 것은 아니다.

Claims (21)

1. 제공하는 기능성에 대한 소프트웨어 서비스 컴포넌트를 갖고, 그리고 인터페이스 컴포넌트는 최소한 하나의 인터페이스를 경유하여 플랫폼 내에 설치되고, 로드되고, 그리고 실행되는 가능한 어플리케이션 도메인 소프트웨어에 대한 소프트웨어 서비스 컴포넌트의 기능성으로의 접근을 제공하는 것에 대한 상기 최소한 하나의 인터페이스를 가지는 플랫폼 도메인; 및

   상기 최소한 하나의 인터페이스를 경유하여 상기 플랫폼 도메인의 상기 소프트웨어 서비스 컴포넌트의 상기 기능성을 확장 및/또는 수정하기 위한 어플리케이션 소프트웨어에 의해 사용하기 위한 플러그인 소프트웨어;

   를 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
2. 제1항에 있어서, 상기 최소한 하나의 인터페이스는 어플리케이션 프로그래밍 인터페이스를 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
3. 제1항에 있어서, 상기 플러그인 소프트웨어는 상기 어플리케이션 소프트웨어의 도메인 내에 존재하는 소프트웨어와 최소한 하나의 상기 플랫폼 도메인과 다른 플러그인 소프트웨어의 기능성에 그것을 사용하는 것을 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
4. 제1항 내지 제2항 중 어느 한 항에 있어서, 상기 플러그인 소프트웨어는 상기 어플리케이션 프로그래밍 인터페이스에 의해 전해지는 제공된 서비스들과 같은 동일한 패러다임에 따르는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
5. 제4항에 있어서, 상기 제공된 서비스들은 하나 또는 그 이상의 컴포넌트 모델 컴플라이언스, 컨벤션 컴플라이언스의 명명, 원하지 않는 사건 처리 컴플라이언스와 메시지 모델 컴플라이언스를 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
6. 제5항에 있어서, 상기 메시지 모델은 콜백 모드와 풀 메시지 모드를 포함하는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
7. 제1항에 있어서, 상기 플러그인 소프트웨어는 복수의 플러그인 소프트웨어 모듈들을 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
8. 제1항에 있어서, 상기 플러그인 소프트웨어는 상기 플랫폼의 룩 앤드 필을 정의하기 위한 그래픽 객체들과 유틸리티들의 세트를 정의한 플러그인 소프트웨어를 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
9. 제1항에 있어서, 상기 플랫폼 도메인은 무선 원격통신 시스템을 위한 모바일 터미널을 위한 플랫폼을 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 시스템.
10. 제공하는 기능성에 대한 소프트웨어 서비스 컴포넌트를 갖고, 그리고 인터페이스 컴포넌트는 최소한 하나의 인터페이스를 경유하여 플랫폼 내에 설치되고, 로드되고, 그리고 실행되는 가능한 어플리케이션 도메인 소프트웨어에 대한 소프트웨어 서비스 컴포넌트의 기능성으로의 접근을 제공하는 것에 대한 상기 최소한 하나의 인터페이스를 가지는 플랫폼 도메인을 제공하는 단계;

    상기 최소한 하나의 인터페이스를 경유하여 상기 플랫폼 도메인의 상기 소프트웨어 서비스 컴포넌트의 상기 기능성을 확장 및/또는 수정하기 위한 어플리케이션 소프트웨어와 함께 플러그인 소프트웨어를 제공하는 단계; 및

    상기 플러그인 소프트웨어를 경유하여 상기 소프트웨어 서비스 컴포넌트의 기능성을 확장 및/또는 수정하는 단계;

    를 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
11. 제10항에 있어서, 상기 플러그인 소프트웨어는 상기 어플리케이션 소프트웨어의 도메인 내에 존재하는 소프트웨어와 상기 플랫폼 도메인의 기능성에 그것을 사용하는 것을 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
12. 제10항에 있어서, 상기 최소한 하나의 인터페이스는 어플리케이션 프로그래밍 인터페이스를 포함하고, 상기 플러그인 소프트웨어는 상기 어플리케이션 프로그래밍 인터페이스에 의해 전해지는 제공된 서비스들과 같은 동일한 패러다임에 따르는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
13. 제12항에 있어서, 상기 제공된 서비스들은 하나 또는 그 이상의 컴포넌트 모델 컴플라이언스, 컨벤션 컴플라이언스의 명명, 예외 처리 컴플라이언스와 메시지 모델 컴플라이언스를 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
14. 제13항에 있어서, 상기 메시지 모델은 콜백 모드와 풀 메시지 모드를 포함하고, 상기 어플리케이션 도메인 소프트웨어는 상기 콜백 모드와 상기 풀 메시지 모드사이의 스위치에 적응하는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
15. 제10항에 있어서, 상기 플러그인 소프트웨어는 상기 플랫폼의 룩 앤드 필을 정의하기 위한 그래픽 객체들과 유틸리티들의 세트를 정의한 플러그인 소프트웨어를 포함하고, 상기 기능성의 상기 확장 및/또는 수정의 단계는 상기 플랫폼의 상기 룩 앤드 필을 변화하는 것을 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
16. 제10항에 있어서, 상기 기능성의 확장 및/또는 수정의 단계는 상기 플랫폼의 제공자의 고객에 의하여 수행되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
17. 제16항에 있어서, 상기 고객은 최종 사용자 제품 제작자인 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
18. 제10항에 있어서, 상기 기능성의 확장 및/또는 수정의 단계는 상기 기능성의 변화를 축소시키는 제3의 파티에 의하여 수행되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
19. 제10항에 있어서, 상기 기능성의 확장 및/또는 수정의 단계는 상기 플랫폼의 상기 소프트웨어 서비스 컴포넌트에 대한 기능성을 추가 또는 제거하는 단계를 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
20. 제10항에 있어서, 상기 플랫폼 도메인은 무선 원격통신 시스템을 위한 모바일 터미널을 위한 플랫폼을 포함하여 구성되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.
21. 제10항에 있어서, 상기 기능성을 상기 수정하는 단계는 어플리케이션 및/또는 하나에서 여러 개의 플러그인들을 다운로드하는 것에 의해 수행되는 것을 특징으로 하는, 제품에 대한 플랫폼의 기능성의 확장 및/또는 수정을 위한 방법.