KR20100058586A - 플랫폼 독립적인 통신 프로토콜 - Google Patents

Abstract

통신 프로토콜을 통해서 모바일 제어기 기기와 호스트 기기 사이에서의 플랫폼 독립적인 양방향 통신을 제공하는 단계를 포함하는 방법이 개시된다. 상기 통신을 가능하게 하는 것은, 상기 모바일 제어기 기기로부터 상기 호스트 기기로의 바이트들의 어레이를 배송하는 단계를 포함한다. 상기 바이트들의 어레이는 상기 모바일 제어기 기기의 하나 이상의 데이터 패킷들을 서술한다. 상기 호스트 기기가 원래의 디바이스 드라이버를 포함한다는 것이 탐지되면, 그 원래의 디바이스 드라이버를가이용되어 상기 배송된 바이트들의 어레이를 분석한다. 대안으로, 상기 호스트 기기가 원래의 디바이스 드라이버를 포함하지 않는다는 것이 탐지되면, 상기 배송된 바이트들의 어레이를 분석하기 위한 디바이스 드라이버가 제공된다.

Description

플랫폼 독립적인 통신 프로토콜 {Platform Independent Communication Protocol}

본원의 개시는 통신 프로토콜을 통한 모바일 제어기 기기와 호스트 기기 사이에서의 플랫폼 독립적인 양방향 통신들을 가능하게 하기 위한 기술들에 관한 것이다.

관련된 출원 상호 참조

본원은 2007.8.24.에 출원된 미국 출원 일련번호 11/844,999에 대한 우선권을 향유하며, 상기 출원의 내용들은 본원에 참조로 편입된다.

모바일 전화기와 같은 모바일 기기들은 더 이상 단순하게 음성 통화의 기능을 제공하는 통신 기기로는 보이지 않을 것이다. 모바일 기기들은 텍스트 메시징, 주소책, 달력, 다른 생산성 애플리케이션들, 매핑 애플리케이션들, 게임 애플리케이션 및 다수의 다른 것들을 포함하는 다양한 애플리케이션들을 구동시키기 위해 사용될 수 있는 컴퓨터 플랫폼으로서 구현될 수 있을 것이다.

블루투스 2.0 표준은 마우스, 키보드, 무선 헤드셋 및 핸즈프리 차량 키트와 같은 제한된 개수의 기기들이 모바일 전화기와 통신하는 것을 가능하게 하도록 설계된 다양한 "프로파일들 (profiles)"을 규정할 수 있다. 이런 프로파일들은 모바일 전화기들 상에서 펌웨어로 구현되는 것이 보통이다. 예를 들면, 휴먼 인터페이스 기기 (Human Interface Device ("HID"))를 지원하는 모바일 전화기는 펌웨어에 내장된 HID 프로토콜을 구비할 것이다. 추가로, 블루투스 2.0 프로파일을 이용하기 위해, 모바일 전화기 그리고 그 모바일 전화기가 통신하기 원하는 입력 기기, 출력 기기 또는 입출력 기기의 둘 모두는 펌웨어나 소프트웨어에서 지원되는 동일한 프로파일을 구비하는 것이 필요하다.

본 발명의 목적은, 여기에서 설명된 모바일 제어기 기기와 호스트 기기 사이에서의 플랫폼 독립적인 통신들을 가능하게 하기 위한 기술들과 입력 시스템 및 휴먼 인터페이스를 구현하는 것이다.

여기에서 설명된 모바일 제어기 기기와 호스트 기기 사이에서의 플랫폼 독립적인 통신들을 가능하게 하기 위한 기술들과 입력 시스템 및 휴먼 인터페이스를 구현하는 것은 다음의 특징들을 다양하게 결합하는 것을 포함할 수 있을 것이다.

본 발명의 하나의 모습에서, 통신 프로토콜을 통해서 모바일 제어기 기기와 호스트 기기 사이에서의 플랫폼 독립적인 양방향 통신을 제공하는 단계는 상기 모바일 제어기 기기로부터 상기 호스트 기기로의 바이트들의 어레이를 배송하는 단계를 포함한다. 상기 바이트들의 어레이는 상기 모바일 제어기 기기의 하나 이상의 데이터 패킷들을 서술한다 (describe). 상기 호스트 기기가 원래의 디바이스 드라이버를 포함한다는 것이 탐지되면, 상기 배송된 바이트들의 어레이를 분석하기 (parse) 위해 그 원래의 디바이스 드라이버가 이용된다. 대안으로, 상기 호스트 기기가 원래의 디바이스 드라이버를 포함하지 않는다는 것이 탐지되면, 상기 배송된 바이트들의 어레이를 분석하기 위한 디바이스 드라이버가 제공된다.

본 발명의 구현들은 다음의 특징들 중의 하나 또는 그 이상을 선택적으로 포함할 수 있을 것이다. 상기 디바이스 드라이버를 제공하는 단계는 상기 배송된 바이트들의 어레이를 기반으로 하는 커스터마이즈된 휴먼 인터페이스 디바이스 드라이버를 제공하는 것을 포함할 수 있다. 또한, 상기 플랫폼 독립적인 양방향 통신을 제공하기 위해 자바 (Java) 플랫폼과 호환되는 양방향 통신이 제공될 수 있다. 상기 바이트들의 어레이를 배송하기 위해, 상기 바이트들의 어레이로부터의 고정된 개수의 바이트가 이용되어, 원래의 휴먼 인터페이스 기기 서술자에 의해 지원되지 않는 하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자 (device specific descriptor)들을 생성할 수 있다. 또한, 하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자들을 생성하는 것은, 조이스틱, 선형 전위차계, 트랙볼, 인코더, 힘 감지 저항 (force sensitive resistor), 장력 측정기, 일련의 디지털 스위치들, 가속도계, 자이로 (gyro), 관성 센서 및 전자기 센서의 그룹에서 선택된 적어도 하나를 지원하는 하나 이상의 기기 특정 서술자들을 생성하는 것을 포함할 수 있다. 또한, 상기 플랫폼 독립적인 양방향 통신을 제공하는 단계는 자바 플랫폼 드라이버에 의해 액세스 가능한 적어도 2개의 통신 채널들을 제공하는 단계를 포함할 수 있다. 추가로, 바이트들의 어레이를 배송하는 단계는 상기 모바일 제어기 기기용으로 커스터마이즈된 가변의 바이트들의 시퀀스를 배송하는 단계를 포함할 수 있다. 가변의 바이트들의 시퀀스를 배송하는 단계는, 상기 바이트들의 시퀀스 내의 각 바이트를 상기 모바일 제어기 기기 상의 하나 이상의 입력 요소들로 매핑하는 단계; 그리고 각 바이트에 할당된 값을 상기 입력 요소의 상태를 기반으로 하여 변경하는 단계를 또한 포함할 수 있다.

본 발명의 다른 모습에서, 본 명세서에서 설명된 기술은, 컴퓨터로 읽을 수 있는 매체 상에 구현되어 데이터 프로세싱 장치로 하여금 다양한 동작들을 수행하도록 하는 컴퓨터 프로그램 제품으로서 구현될 수 있다. 예를 들면, 상기 컴퓨터 프로그램 제품은 통신 프로토콜을 통해서 모바일 제어기 기기와 호스트 기기 사이에서의 플랫폼 독립적인 양방향 통신을 제공하도록 설계된다. 상기 플랫폼 독립적인 양방향 통신을 제공하는 것은 상기 모바일 제어기 기기로부터 상기 호스트 기기로의 바이트들의 어레이를 배송하는 단계를 포함하며, 상기 바이트들의 어레이는 상기 모바일 제어기 기기의 하나 이상의 데이터 패킷들을 서술한다. 상기 호스트 기기가 원래의 디바이스 드라이버를 포함한다는 것이 탐지되면, 상기 컴퓨터 프로그램 제품은 그 원래의 디바이스 드라이버를 이용하여 상기 배송된 바이트들의 어레이를 분석하도록 설계된다. 대안으로, 상기 호스트 기기가 원래의 디바이스 드라이버를 포함하지 않는다는 것이 탐지되면, 상기 컴퓨터프로그램 제품은 상기 배송된 바이트들의 어레이를 분석하기 위한 디바이스 드라이버를 제공하도록 설계된다.

본 발명의 구현들은 다음의 특징들 중의 하나 또는 그 이상을 선택적으로 포함할 수 있을 것이다. 상기 컴퓨터 프로그램 제품은 상기 데이터 프로세싱 장치로 하여금, 상기 배송된 바이트들의 어레이를 기반으로 하는 커스터마이즈된 휴먼 인터페이스 디바이스 드라이버를 제공하는 것을 더 포함하는 동작을 수행케 하도록 설계될 수 있다. 상기 컴퓨터 프로그램 제품은 상기 데이터 프로세싱 장치로 하여금, 자바 (Java) 플랫폼과 호환되는 양방향 통신을 적어도 제공하여 플랫폼 독립적인 양방향 통신을 제공하는 것을 더 포함하는 동작을 수행케 하도록 설계될 수 있다. 상기 컴퓨터 프로그램 제품은 상기 데이터 프로세싱 장치로 하여금, 원래의 휴먼 인터페이스 기기 서술자에 의해 지원되지 않는 하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자들을 생성하기 위해 상기 바이트들의 어레이로부터의 고정된 개수의 바이트들을 적어도 이용함으로써 상기 바이트들의 어레이를 배송하는 것을 더 포함하는 동작을 수행케 하도록 설계될 수 있다. 상기 컴퓨터 프로그램 제품은 상기 데이터 프로세싱 장치로 하여금, 조이스틱, 선형 전위차계, 트랙볼, 인코더, 힘 감지 저항 (force sensitive resistor), 장력 측정기, 일련의 디지털 스위치들, 가속도계, 자이로 (gyro), 관성 센서 및 전자기 센서의 그룹에서 선택된 적어도 하나를 지원하는 하나 이상의 기기 특정 서술자들을 적어도 생성함으로써, 하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자들을 생성하는 것을 더 포함하는 동작을 수행케 하도록 설계될 수 있다. 상기 컴퓨터 프로그램 제품은 상기 데이터 프로세싱 장치로 하여금, 자바 플랫폼 드라이버에 의해 액세스 가능한 적어도 2개의 통신 채널들을 구비한 플랫폼 독립적인 양방향 통신을 제공하는 것을 더 포함하는 동작을 수행케 하도록 설계될 수 있다. 상기 컴퓨터 프로그램 제품은 상기 데이터 프로세싱 장치로 하여금, 상기 모바일 제어기 기기용으로 커스터마이즈된 가변의 바이트들의 시퀀스를 구비하는 바이트들의 어레이를 배송하는 것을 더 포함하는 동작을 수행케 하도록 설계될 수 있다. 또한, 상기 컴퓨터 프로그램 제품은 상기 데이터 프로세싱 장치로 하여금, 상기 바이트들의 시퀀스 내의 각 바이트를 상기 모바일 제어기 기기 상의 하나 이상의 입력 요소들로 매핑하는 것; 그리고 각 바이트에 할당된 값을 상기 입력 요소의 상태를 기반으로 하여 변경하는 것을 포함하는, 가변의 바이트들의 시퀀스를 배송하는 것을 포함하는 바이트들의 가변 시퀀스를 배송하는 것을 포함하는 동작을 수행케 하도록 설계될 수 있다.

본 발명의 또 다른 모습에서, 본 명세서에서 설명되는 기술은 상기 모바일 제어기 기기를 호스트 기기에 연결시키도록 설계된 기저대역 프로토콜을 포함하는 통신 프로토콜 스택을 동작시키도록 설계된 통신 메커니즘을 포함한 모바일 제어기 기기로서 구현될 수 있다. 상기 모바일 제어기 기기는 상기 기저대역 프로토콜을 통해, 각각이 바이트들의 시퀀스를 포함하는 하나 이상의 메시지들을 상기 호스트 기기로 송신하도록 설계된 양방향 시리얼 통신 프로토콜을 또한 포함한다. 송신된 각 메시지는 바이트들의 하나의 시퀀스를 포함한다. 상기 제어기 기기는 상기 모바일 제어기 기기에서 이용 가능한 다양한 입력 메카니즘들이 제공한 입력 신호들을 모니터하도록 설계되고, 그리고 상기 하나 이상의 메시지들을 생성하도록 설계된 제어기 펌웨어를 또한 포함한다. 상기 양방향 시리얼 통신 프로토콜은 상기 기저대역 프로토콜을 통한 상기 모바일 제어기 기기와 호스트 기기 사이의 플랫폼 독립적인 양방향 통신을 가능하게 한다.

본 발명의 구현들은 다음의 특징들 중의 하나 또는 그 이상을 선택적으로 포함할 수 있다. 플랫폼 독립적인 양방향 통신들을 가능하게 하는 양방향 시리얼 통신 프로토콜은 자바 (Java) 플랫폼과 호환되는 양방향 통신을 포함할 수 있다. 상기 제어기 펌웨어는 원래의 휴먼 인터페이스 기기 서술자에 의해 지원되지 않는 하나 또는 그 이상의 센서들을 지원하는 하나 또는 그 이상의 기기 특정 서술자들을 생성하기 위해 상기 바이트들의 시퀀스로부터 고정된 개수의 바이트들을 취하도록 설계된다. 상기 제어기 펌웨어는, 조이스틱, 선형 전위차계, 트랙볼, 인코더, 힘 감지 저항 (force sensitive resistor), 장력 측정기, 일련의 디지털 스위치들, 가속도계, 자이로 (gyro), 관성 센서 및 전자기 센서의 그룹에서 선택된 적어도 하나를 지원하는 하나 또는 그 이상의 기기 특정 서술자들을 생성하도록 또한 설계될 수 있다. 상기 제어기 펌웨어는 하나 또는 그 이상의 메시지드을 생성하도록 설계될 수 있으며, 그 생성된 메시지들 각각은 모바일 제어기 기기용으로 맞춤 처리된 가변의 바이트들의 시퀀스를 포함한다. 상기 제어기 펌웨어는 상기 바이트들의 시퀀스 내의 각 바이트를 상기 모바일 제어기 기기에 이용 가능한 다양한 입력 메커니즘의 하나 또는 그 이상의 입력 요소들로 매핑하고 그리고 각 바이트에 할당된 값을 상기 매핑된 하나 또는 그 이상의 입력 요소들의 상태를 기반으로 하여 변경할 수 있다.

여기에서 설명되는 통신 프로토콜을 통해서 모바일 제어기 기기와 호스트 기기 사이의 플랫폼 독립적인 양방향 통신들을 가능하게 하는 기술들은 다음과 같은 이점들 중의 하나 또는 그 이상을 잠재적으로 제공할 수 있을 것이다. 본 명세서에서 설명되는 시스템들과 기술들은 센서 데이터, 상태 정보 그리고 시리얼화될 수 있으며 작은 크기로 송신될 수 있는 임의 유형의 데이터를 모바일 제어기 기기와 호스트 기기가 교환하도록 하는 효율적이며, 경량의 메커니즘을 제공할 수 있을 것이다. 상기 메커니즘은 빠르며 효율적일 수 있으며 펌웨어 및/또는 소프트웨어에 있어서 작은 발자취를 취할 수 있으며 그리고 부속된 데이터를 송신하고 수신하는 프로세스에 있어서 최소양의 타이밍 오버헤드만을 초래한다. 상기 메커니즘은 전위차계들 또는 다중-자유도 아날로그 조이스틱들로부터의 아날로그 신호들; 광학 마우스들이나 최상위 로봇식의 기기들에서 찾을 수 있는 것과 같은 디지털 인코더들; 인가된 압력이 변경되는 것에 응답하여 비례하는 신호를 제공하는 힘 감지 저항들; 가속도계 신호 및 자이로스코프 신호; 트랙볼들로부터의 신호들; 내비게이션 스틱들을 기반으로 하는 인장 계측기 (strain gauge)와 같은 힘 감지 기기들로부터의 신호들; 광학 센서들로부터의 비례 신호들 또는 디지털 신호들; 전자기 센서들로부터의 신호들; 및 기타 유사한 것을 포함하는 게이밍에서 보통 사용되는 아주 다양한 센서들을 지원하기 위해 특별하게 정의될 수 있다. 상기 메커니즘은 상기 모바일 제어기 기기와 호스트 기기가 게임 상태 정보, 차량 진단 정보, GPS 고정점 등과 같이 시리얼화될 수 있는 다른 유형의 데이터를 교환하는 것을 가능하게 하도록 또한 확장될 수 있다.

본 명세서에서 설명된 시스템들 및 기술들은 블루투스 논리 링크 제어 및 적용 프로토콜 (logical link control and adaptation protocol (L2CAP)) 또는 블루투스 시리얼 포트 프로파일 (serial port profile (SPP)) 과 같은 다양한 전송 프로토콜들을 가로질러 또는 다른 유선의 또는 무선의 전송 프로토콜들을 통해서 동작할 수 있는 애플리케이션 프로그램 인터페이스 (Application Program Interface (API))처럼 구현될 수 있을 것이다. 예를 들면, USB, 파이어와이어 (firewire), IrDA 또는 다른 유선과 무선 통신 프로토콜들을 통해서 통신들을 지원하기 위해 동일한 API가 설계될 수 있다.

상기 통신 프로토콜은, HID 기반의 메커니즘, 모바일 제어기 기기로부터 호스트 기기로 송신되는 미리 정의된 구문을 구비한 바이트들의 고정된 개수와 결부된 고정-길이 시리얼 메커니즘 그리고 상기 모바일 제어기 기기로부터 상기 호스트 기기로 그리고 그 반대로 질의들과 데이터가 송신되도록 하는 양방향 통신 프로토콜 메커니즘을 포함하는 다양한 메커니즘으로 또한 구현될 수 있다.

상기 HID 기반의 메커니즘은 HID 프로파일의 부분집합의 경량의 Java 구현을 상기 호스트 기기 상에 제공할 수 있으며, 선택적으로는 상기 모바일 제어기 기기들에 적합한 공통의 센서들을 지원하기 위해 맞춤의 HID 서술자들을 선택할 수 있다. 고정-길이 시리얼 메커니즘은 모바일 제어기 기기들에 적합한 센서들에게 아주 일반적인 고정된 개수의 바이트들을 구비한 바이트 구조를 반영할 수 있다. 상기 양방향 시리얼 통신 프로토콜 메커니즘은, 상기 모바일 제어기 기기들에 적합한 공통의 센서들에 대한 지원을 제공하기 위해 구현될 수 있는 맞춤의 바이트 시퀀스 구조를 포함할 수 있다.

상기 HID 기반의 메커니즘이나 시리얼 통신 프로토콜이 구현되는가의 여부에 관계없이, 본 명세서에서 설명되는 시스템들과 기술들은, Java와 같이 상기 호스트 기기 상에서 동작하는 프로그래밍 플랫폼 상에서 구현되는 API 내에 또한 병합될 수 있을 것이다. 그런 API는 상기 호스트 기기 상에서 동작하는 애플리케이션들로 병합될 수 있다.

본 명세서에서 설명되는 주제는 방법, 시스템 또는 CD-ROM, DVD-ROM, 반도체 메모리 또는 하드디스크와 같은 정보 운반체 내에서 유형화되어 구현된 컴퓨터 프로그램 제품으로서 구현될 수 있다. 그런 컴퓨터 프로그램 제품들은 데이터 프로세싱 장치로 하여금 본 명세서에서 설명되는 하나 또는 그 이상의 동작을 수행케 하도록 할 수 있을 것이다.

추가로, 본 명세서에서 설명된 주제는 프로세서 및 그 프로세서에 연결된 메모리를 포함하는 시스템으로서 구현될 수도 있을 것이다. 상기 메모리는 상기 프로세서로 하여금 본 명세서에서 설명되는 방법의 동작들 중의 하나 또는 그 이상을 수행하도록 하는 하나 또는 그 이상의 프로그램들을 인코딩할 수 있을 것이다. 또한, 본 명세서에서 설명되는 주제는 다양한 데이터 프로세싱 기계들을 이용하여 구현될수 있다.

하나 또는 그 이상의 구현들의 상세한 내용들은 동반된 도면들과 아래에서의 설명에서 제시된다. 다른 특징들과 이점들은 상기 설명, 도면들 그리고 청구범위로부터 명백할 것이다.

여기에서 설명되는 통신 프로토콜을 통해서 모바일 제어기 기기와 호스트 기기 사이의 플랫폼 독립적인 양방향 통신들을 가능하게 하는 기술들은 다음과 같은 이점들 중의 하나 또는 그 이상을 잠재적으로 제공할 수 있을 것이다. 본 명세서에서 설명되는 시스템들과 기술들은 센서 데이터, 상태 정보 그리고 시리얼화될 수 있으며 작은 크기로 송신될 수 있는 임의 유형의 데이터를 모바일 제어기 기기와 호스트 기기가 교환하도록 하는 효율적이며, 경량의 메커니즘을 제공할 수 있을 것이다. 상기 메커니즘은 빠르며 효율적일 수 있으며 펌웨어 및/또는 소프트웨어에 있어서 작은 발자취를 취할 수 있으며 그리고 부속된 데이터를 송신하고 수신하는 프로세스에 있어서 최소양의 타이밍 오버헤드만을 초래한다. 상기 메커니즘은 전위차계들 또는 다중-자유도 아날로그 조이스틱들로부터의 아날로그 신호들; 광학 마우스들이나 최상위 로봇식의 기기들에서 찾을 수 있는 것과 같은 디지털 인코더들; 인가된 압력이 변경되는 것에 응답하여 비례하는 신호를 제공하는 힘 감지 저항들; 가속도계 신호 및 자이로스코프 신호; 트랙볼들로부터의 신호들; 내비게이션 스틱들을 기반으로 하는 인장 계측기 (strain gauge)와 같은 힘 감지 기기들로부터의 신호들; 광학 센서들로부터의 비례 신호들 또는 디지털 신호들; 전자기 센서들로부터의 신호들; 및 기타 유사한 것을 포함하는 게이밍에서 보통 사용되는 아주 다양한 센서들을 지원하기 위해 특별하게 정의될 수 있다. 상기 메커니즘은 상기 모바일 제어기 기기와 호스트 기기가 게임 상태 정보, 차량 진단 정보, GPS 고정점 등과 같이 시리얼화될 수 있는 다른 유형의 데이터를 교환하는 것을 가능하게 하도록 또한 확장될 수 있다.

도 1a 및 도 1B는 제어기 기기와 호스트 기기 사이에서의 통신들을 가능하게 하기 위한 시스템을 예시하는 블록도이다.
도 2는 HID 기반의 메커니즘을 위한 HID 조이스틱용으로 설계된 예시적인 보고 서술자 (300)를 도시한다.
도 3, 도 4 및 도 5는 HID 기반의 메커니즘을 위한 다양한 센서들 용의 통신들을 가능하게 하기 위해 설계된 예시적인 맞춤 보고를 도시한다.
도 6은 HID 클래스 기기와 HID가 가능한 호스트 기기 사이에서의 통신들을 가능하게 하기 위한 시스템을 서술하는, HID 기반의 메커니즘 구현을 도시하는 블록도이다.
도 7은 고정된-길이의 바이트 시퀀스를 이용하는 통신들을 가능하게 하는 고정된-길이의 시리얼 접근을 구현하기 위한 블루투스 스택을 도시하는 블록도이다.
도 8은 종결 바이트를 구비한 4-바이트 시퀀스 용의 예시적인 바이트 시퀀스를 도시한다.
도 9는 종결 바이트를 구비한 5-바이트 시퀀스 용의 예시적인 바이트 시퀀스를 도시한다.
도 10은 블루투스 시리얼 포트 프로파일 (Bluetooth Serial Port Profile (SPP)을 통해서 구현된 메커니즘을 기반으로 양방향 시리얼 통신 프로토콜을 구현하기 위한 예시적인 통신 스택을 도시한다.
도 11은 양방향 시리얼 통신 프로토콜 메커니즘을 위한 예시적인 바이트 시퀀스 또는 보고 포맷을 도시한다.
도 12는 아이들 설정 (SET_IDLE) 용의 예시적인 메시지 포맷을 도시한다.
도 13은 아이들 레이트를 보여주는 예시적인 바이트 시퀀스를 서술한다.
도 14는 버전 보고 (Version Report)를 위한 예시적인 바이트 시퀀스를 도시한다.
도 15는 설정 데이터 입력 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 16은 버튼 메타데이터 보고 (Button Metadata Report)를 위한 예시적인 바이트 시퀀스를 도시한다.
도 17은 인에이블/디세이블 (Enable/Disable) 보고 유형을 위한 예시적인 바이트 시퀀스를 도시한다.
도 18은 버튼 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 19는 8-비트 아날로그 2-축 조이스틱 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 20은 16-비트 아날로그 2-축 조이스틱 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 21은 32-비트 아날로그 2-축 조이스틱 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 22는 8-비트 아날로그 3-축 가속도계 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 23은 16-비트 아날로그 3-축 가속도계 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 24는 32-비트 아날로그 3-축 가속도계 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 25는 예시적인 8-비트 아날로그 패들 (Paddle) 보고를 도시한다.
도 26은 예시적인 16-비트 아날로그 패들 (Paddle) 보고를 도시한다.
도 27은 예시적인 32-비트 아날로그 패들 (Paddle) 보고를 도시한다.
도 28은 예시적인 16-비트 배터리 레벨 보고를 도시한다.
도 29는 예시적인 8-비트 트랙볼 보고를 도시한다.
도 30은 예시적인 16-비트 트랙볼 보고를 도시한다.
도 31은 예시적인 32-비트 트랙볼 보고를 도시한다.
도 32는 예시적인 8-비트 스크롤 휠 보고를 도시한다.
도 33은 예시적인 16-비트 스크롤 휠 보고를 도시한다.
도 34는 예시적인 32-비트 스크롤 휠 보고를 도시한다.
도 35는 가공하지 않은 (Raw) 조건부의 8-비트 아날로그 2-축 조이스틱 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 36은 런 루프 (Run Loop) 테스트 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 37은 32-비트 기기 타임스탬프 (밀리초 단위) 보고를 위한 예시적인 바이트 시퀀스를 도시한다.
도 38은 모바일 제어기 기기와 호스트 기기 사이의 통신들을 가능하게 하기 위한 프로세스를 도시하는 프로세스 흐름도이다.
도 39는 내비게이션 시스템 상에서의 매핑 애플리케이션을 제어하는 원격 제어기 기기를 가능하게 하기 위해 자바 (Java)를 구현하기 위한 예시적인 시스템을 도시한다.
도 40은 GPS 가능한 기기들 사이에서의 데이터 교환을 제공하기 위한 예시적인 시스템을 도시한다.
도 41은 모바일 전화가, 차량 및 PC 사이에서의 데이터 통신들을 가능하게 하기 위한 예시적인 시스템을 도시한다.
도 42는 다중의 헬스 및 피트니스 기기들 사이에서의 데이터 통신들을 가능하게 하기 위한 예시적인 시스템을 도시한다.
도 43은 자바가 가능한 조이스틱 제어기와 모바일 전화기 사이에서의 데이터 통신들을 가능하게 하기 위한 예시적인 시스템을 도시한다.
도 44는 다중-플레이어 모바일 게임 시나리오에서 HID 통신들을 가능하게 하기 위한 예시적인 시스템을 도시한다.
상기의 다양한 도면들에서 유사한 참조 심볼들은 유사한 요소들을 나타내는 것이다.

개관 (OVERVIEW)

도 1a 및 도 1b는 제어기 기기 (110)와 호스트 기기 (120) 사이에서의 플랫폼 독립적인 (즉, 블루투스, USB, 파이어와이어, IrDA 등과 같은 통신 프로토콜에 독립적인) 통신들을 가능하게 하기 위한 시스템을 도시하는 블록도들이다. 상기 제어기 기기 (11)는 통신 프로토콜 (130)을 이용하여 상기 호스트 기기 (120)와 통신한다.

상기 호스트 기기 (120)는, 모바일 전화기, 개인용 디지털 보조기 (PDA), 스마트 전화기, 개인용 내비게이터 시스템, 디지털 비디오 녹화기 (DVR) 기기, 정보 (예를 들면, GPS 내비게이션, 무선 통신) 및/또는 엔터테인먼트 (예를 들면, 디지털 비디오 디스크 드라이브)를 제공하는 업그레이드 기술을 구비한 차량, 보도계 (pedometer), 포도당 계량기, 혈압 센서, 욕실 체중계 등과 같이 하나 또는 그 이상의 내장된 프로세서들을 구비한 기기들을 포함한다. 입력 제어기 기기 (110)는 상기 호스트 기기 (120)와 통신하도록 설계되며 상기 호스트 기기 (120)를 제어하기 위한 직관적인 인터페이스 요소들을 제공한다. 직관적인 요소들을 제공함으로써, 상기 제어기 기기 (110)는, 예를 들면, 게임 애플리케이션 그리고 매핑 애플리케이션과 같은 복잡한 애플리케이션들을 제어하고 수행하는 것을 용이하게 할 수 있다. 상기 제어기 기기 (110)는 다양한 직관적인 제어 인터페이스 요소들을 제공하는 모바일 부속 기기들을 포함한다. 그런 제어기 기기들 (110)의 예는 공동 계류중인 "Human Interface Input Acceleration System" 제목의 미국 특허 출원 (U.S. Patent Application Publication No. 20070080934) 및 "Human Interface Input Acceleration System" 제목의 미국 특허 출원 (U.S. Patent Application Publication No. 20070080931)에서 설명된다. 공동 계류 중인 이들 출원 (U.S. Patent Application Publication Nos. 20070080934 and 20070080931)은 본원에 참조로서 편입된다.

통신 프로토콜 스택 (130)은 상기 제어기 기기 (110)와 상기 호스트 기기 (120) 사이에서의 통신 신호들을 양방향으로 교환하는 것을 가능하게 한다. 상기 통신 프로토콜 스택 (130)은 전송 메커니즘 (132)의 제일 위의 부분에서 동작하는 플랫폼 독립적인 전송 프로토콜 (134)을 포함한다. 상기 전송 메커니즘 (132)은 블루투스, USB (Universal Serial Bus), 파이어와이어, IrDA 등과 같은 하나 또는 그 이상의 유선 또는 무선 전송/통신 프로토콜들을 포함한다. 상기 플랫폼 독립적인 전송 프로토콜 (134)은 다양한 전송 메커니즘들 중의 하나 또는 그 이상의 전송 메커니즘을 통해서 동작하도록 설계된다. 상기 플랫폼 독립적인 전송 프로토콜 (134)은 전송 메커니즘 (132)의 제일 상단에 위치하는 애플리케이션 프로그래밍 인터페이스 (API)을 이용하여 구현될 수 있다. API는 서비스들에 대한 요청을 지원하기 위해 컴퓨터 시스템이나 프로그램 라이브러리가 제공하는 소스 코드 인터페이스이다.

본 명세서에서 설명되는 플랫폼 독립적인 전송 프로토콜 (134)은 모바일 제어기 기기와 호스트 기기 사이에서의 통신 또는 복수의 모바일 제어기 기기들과 복수의 호스트 기기들 사이에서의 통신을 가능하게 하기 위해 다양한 메커니즘들 하에서 구현될 수 있다. 예를 들면, 플랫폼 독립적인 전송 프로토콜은 HID 기반의 메커니즘, 고정-길이 시리얼 메커니즘 또는 양방향 시리얼 통신 프로토콜 메커니즘 사에서 구현될 수 있다.

HID 기반의 메커니즘

플랫폼 독립적인 전송 프로토콜 (134)은 모바일 제어기 기기와 호스트 기기 사이에서의 통신들을 가능하게 하기 위해 HID 기반의 메커니즘 하에서 구현될 수 있다. HID 기반의 통신 프로토콜은 표준 HID 기기들을 위한 현존하는 HID 규격 (예를 들면, 본원에 그 전체가 참조로 편입된, Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.11 (www.usb.org) 그리고 the Universal Serial Bus (USB) HID Usage Tables, Version 1.12 (www.usb.org) 참조)들을 기반으로 하여 구축된다. HID 프로파일 용의 경량의 자바 2 마이크로 에디션 (Java 2 Micro Edition (J2ME)) 구현은 모바일 전화기들 그리고 호스트 기기로서 서빙하는 다른 모바일 기기와 같은 모바일 기기들에서 동작하도록 구현될 수 있다. 하나 또는 그 이상의 모바일 제어기 기기들 상에서의 펌웨어는 HID 프로파일의 경량 구현을 또한 포함한다. 하나 또는 그 이상의 모바일 제어기 기기들에서 사용하기에 적합한 일반적인 센서들 그리고 특별한 센서들을 지원하기 위해 맞춤 서술자들 (custom descriptor)이 구현될 수 있다.

도 2는 HID 조이스틱 기기를 위해 설계된 예시적인 보고 서술자 (200)를 도시한다. 상기 예시적인 보고 서술자 (200)는 다음의 특징들을 포함한다: (1) 전방/후방 그리고 오른쪽/왼쪽으로 틸트되는 2-축 (2-axis) 조이스틱 (바이트 (byte) 1과 바이트 (byte) 2); (2) 베이스 (base) 위에서의 아날로그 스로틀 (throttle) 제어 (바이트 0); (3) 스틱 상의 4-위치 햇 스위치 (hat switch) (바이트 3의 비트 (bit) 0-3); (4) 스틱 상의 두 개 버튼 (바이트 3의 비트 4-5 또는 비트 6-7); 및 (5) 베이스 위의 두 개의 버튼 (바이트 3의 비트 4-5 또는 비트 6-7). 이런 서술자 보고는 각 조이스틱을 읽기 위한 8-비트 해상도를 제공한다.

보고의 바이트 배치에 추가하여, 보고 서술자는 다양한 필드들에 일부 의미들 (semantics)을 또한 포함할 수 있다. 예를 들면, 조이스틱에 대한 X-축 (X-axis) 필드는, X-축에서의 조이스틱의 위치를 나타내는, -127 내지 127까지 범위인 8 비트 부호화 (signed) 값으로 정의될 수 있다. 일부 실시예들에서, X-축 및 Y-축을 읽으면 상기 첫 번째 서술자에서의 8-비트 해상도 대신에 16-비트 해상도를 제공하는 두 번째 서술자가 제공될 수 있다.

도 3, 도 4 및 도 5는 다양한 센서들을 위한 통신들을 가능하게 하기 위해 설계된 예시적인 맞춤 보고 서술자들을 도시한다. 고유의 ID들을 구비한 고정된 개수의 바이트들이 선택되며, 그렇게 선택된 바이트들의 내용들은 사용되는 센서들의 유형에 따라서 다양한 방식으로 적용된다. 이는 다양한 센서들을 지원하기 위한 경량이지만 유연한 프로토콜을 지원하는 결과를 낳는다. 상시 다양한 센서들은, 예를 들면, 다음을 포함한다: (1) 2 단의 자유도 (2 DOF (degrees of freedom)) 또는 3단의 자유도 (3 DOF)를 가진 저해상도 조이스틱들 (도 3); (2) 선형 전위차계 (potentiometer)들; (3) (인코더 유형의) 2 DOF를 구비한 트랙볼들 (도 4); (3) 인코더들; (4) 힘 감지 저항들; (5) 장력 측정기; (6)광센서들; (7) 일련의 디지털 스위치들; (8) 가속도계 (도 5); (9) 자이로 (gyro); (10) 다른 관성 센서들; 및 (11) 전자기 센서들.

도 6은 HID 클래스 기기 (610)와 HID 호스트 기기 (620) 사이에서의 통신을 가능하게 하는 시스템 (600)을 도시하는 블록도이다. HID 클래스 기기 (예를 들면, 제어기 기기 (610))는 제어 (디폴트) 파이프 (630)이나 인터럽트 파이프 (640) 중의 어느 하나를 이용하여 상기 호스트 기기 (620) 상의 HID 클래스 드라이버 (도시되지 않음)와 통신한다. 상기 제어 파이프 (630)는, (1) 제어 및 클래스 데이터에 대한 요청들을 수신하고 그에 응답하고; (2) 상기 호스트 기기 (620)로부터의 HID 클래스 기기에 의해 폴링될 때에 상기 제어기 기기 (610)로부터 상기 호스트 기기 (620)로의 데이터 전송하며; 그리고 (3) 상기 제어기 기기 (620)가 상기 호스트 기기 (620)로부터 데이터를 수신하는 것을 가능하게 하는 것을 포함하는 동작들을 수행하기 위해 사용된다. 상기 인터럽트 파이프 (640)는, (1) 상기 제어기 기기 (610)로부터 비동기식 (요청되지 않은) 데이터를 수신하고; 그리고 (2) 상기 호스트 기기 (620)로부터 상기 제어기 기기 (610)로의 낮은 레이턴시 (latency) 데이터를 전송하는 것을 포함하는 동작들을 수행하기 위해 사용된다.

이런 두 파이프들은 채널 0x11 및 채널 0x13 상에서의 두 L2CAP 접속과 같이 HID 프로토콜에서 구현된다. 자바 (예를 들면, J2ME) 구현들을 위한 지원을 게임 및 애플리케이션 개발 플랫폼으로서 제공하기 위해, HID 프로파일의 부분 집합에 대한 경량의 자바 구현이 제공된다. 그러므로, HIDP 준수를 위한 두 L2CAP 채널 0x11 및 채널 0x13에 추가하여, 두 L2CAP 채널 0x11 및 채널 0x13은 자바 드라이버로부터의 액세스를 제공하기 위해 구현된다 (예를 들면, J2ME 구현).

대체의 실시예들에서, 맞춤 시리얼 전송 프로토콜은 시리얼 포트 프로파일 (Serial Port Profile (SPP))을 통해 동작하기 위해 구현된다. HID 프로토콜에서와 같이 L2CAP 구현을 이용하는 것 대신에, 블루투스 스택을 통한 전송 채널을 제공하기 위해 다른 전송 메커니즘들이 채택된다. 상기 SPP는 다양한 기기들이, 에뮬레이트되는 시리얼 케이블 접속을 무선 주파수 통신 (Radio Frequency Communication (RFCOMM))을 이용하여 셋업하도록 허용한다 (시리얼 포트 프로파일 규격 버전 1.1 (Serial Port Profile Specification, Version 1.1 (wmv.bluetooth.org)) 참조, 상기 규격은 그 전체가 본원에 참조로 편입된다). RFCOMM은 L2CAP 프로토콜을 통해 RS-232C 시리얼 포트들의 9개 회로들의 에뮬레이션을 제공하는 단순한 전송 프로토콜이다 (RFCOMM Specification, Version 1.1 (www.bluetooth.org) 참조, 상기 규격은 그 전체가 본원에 참조로 편입된다). 이런 구현은 HID 프로토콜과는 다르며, HID 프로토콜은 L2CAP를 직접적으로 사용하며 SPP에 의해 제공되는 추가적인 기능은 사용하지 않는다.

고정 길이 시리얼 프로토콜 기반의 메커니즘 (FIXED-LENGTH SERIAL PROTOCOL BASED MECHANISM )

대체의 실시예에서, 모바일 제어기 기기가 호스트 기기로 정보를 전달하는 것을 허용하기 위해 고정 길이 시리얼 시퀀스가 채택될 수 있을 것이다. 이런 바이트 시퀀스는 블루투스 SPP (Serial Port Profile)를 전송 메커니즘으로서 이용하여 상기 모바일 제어기 기기로부터 상기 호스트 기기로 송신될 수 있을 것이다.

도 7은 블루투스 시리얼 프로파일 (SPP) (714, 725)의 상단에서 구현된 고정 길이 시리얼 시퀀스 통신 프로토콜 (713, 714)을 도시한 블록도이다. 상기 프로토콜 스택 (700)은 고정-길이 시리얼 통신 프로토콜을 이용하는 통신을 가능하게 한다. 상기 프로토콜 스택 (700)은 프로토콜들의 스택에서 계층들로서 구현될 수 있는 다양한 프로토콜 모듈들을 포함한다. 제어기 기기 측 (710)에서, 전송 프로토콜 스택의 계층들은 기저대역 (baseband) 계층 (717), 논리적인 링크 제어 및 적응 프로토콜 (logical link control and adaptation protocol (L2CAP)) 계층 (716), RFCOMM 계층 (715), SPP 계층 (714), 고정-바이트 시리얼 시퀀스 프로토콜 계층 (713) 및 제어기 펌웨어 계층 (712)을 포함한다. 호스트 기기 측 (720)에서, 상기 프로토콜 스택의 계층들은 기저대역 계층 (728), L2CAP 계층 (727), EFCOMM 계층 (726), SPP 게층 (725), 고정-길이 시리얼 시퀀스 프로토콜 계층 (724) 및 애플리케이션 계층 (722)을 포함한다.

제어기 펌웨어 (712)는 상기 제어기 기기 (710)에게 이용 가능한 다양한 입력 메커니즘들 (예를 들면, 버튼들, 조이스틱들, 트랙볼들)에 의해 제공되는 아날로그 신호와 디지털 신호를 모니터한다. 신호 이벤트가 발생할 때마다 (예를 들면, 버튼이 눌려지거나 조이스틱이 제거되는 경우), 상기 제어기 펌웨어는 상기 고정-길이 프로토콜 (713)을 이용하여 메시지를 생성하여 그 메시지를 상기 호스트 기기 (720)로 송신한다.

상기 고정 길이 바이트 시퀀스는 미리 정해진 개수의 바이트들을 구비할 수 있을 것이다. 이 시퀀스 내의 각 바이트는 특정 목적을 가질 수 있을 것이다. 일 실시예에서, 상기 시퀀스 내의 마지막 바이트는 "종결 바이트 (termination byte)"로서 표시될 수 있을 것이며, 그 데이터는 도달하지 않도록 제한되었다는 고정된 값, 예를 들면, 0xFF을 항상 나타낼 수 있을 것이다. 대안의 일 실시예에서, 상기 시퀀스의 첫 번째 바이트는 바이트 스트림 내에 바이트들의 개수를 인코딩할 수 있을 것이다.

상기 호스트 기기 (720) 상에서 동작하며 호스트 애플리케이션으로 링크된 제어기 기기 (723)는 상기 고정-길이 시리얼 시퀀스 프로토콜 메시지를 수신하고 그 메시지를 하나 또는 그 이상의 애플리케이션-레벨 이벤트들로 변환한다. 그러면 이런 이벤트들은 호스트 애플리케이션으로 송신된다.

한가지 구현 예에서, 상기 고정-길이 시리얼 시퀀스 프로토콜 (713)은 상기 제어기 기기 (710)로부터 상기 호스트 기기 (720)로의 단일방향 (730)이다. 상기 제어기 기기 (710)가 상기 호스트 기기 (720)로 메시지를 송신할 수 있지만, 상기 호스트 기기는 상기 제어기 기기 (730)로 메시지를 돌려보낼 수 없다. 대안의 구현들에서, 상기 고정-길이 프로토콜 (713)은 양방향이어서, 상기 호스트 기기가 유사하게 미리 정해진, 고정-바이트 시퀀스를 이용하여 명령어들을 상기 모바일 제어기 기기로 송신하는 것을 가능하게 할 수 있을 것이다.

상기 고정-길이 시리얼 시퀀스 프로토콜 (173)은, (1) 전위차계나 다중의 자유도 아날로그 조이스틱으로부터의 아날로그 신호들; (2) 광학 마우스에 또는 최상위 로봇식의 기기들에 장착된 것과 같은 디지털 인코더들; (3) 인가된 압력이 변경되는 것에 응답하여 비례하는 신호를 제공하는 힘 감지 저항들; (4) 가속도계 신호 및 자이로스코프 신호; (5) 트랙볼들로부터의 신호들; (6) 내비게이션 스틱들을 기반으로 하는 인장 계측기 (strain gauge)와 같은 힘 감지 기기들로부터의 신호들; (7)광학 센서들로부터의 비례 신호들 또는 디지털 신호들; (8) 전자기 센서들로부터의 신호들; 및 기타 유사한 것을 포함하는 게이밍 (gaming)에서 일반적으로 사용되는 아주 다양한 센서들을 지원하기 위해 맞춤의 고정 바이트 시퀀스를 구현할 수 있는 예시적인 프로토콜이다.

도 8은 종결 바이트 (네 번째 바이트 (4th byte)로서 0xFF 또는 종결 바이트)를 구비한 4-바이트 시퀀스를 위한 예시적인 바이트 시퀀스를 도시한다. 이런 구현에서, 첫 번째 바이트 (1st Byte)는 버튼들이 눌러진 상태를 나타내는 비트맵으로서 사용된다. 상기 제어기 기기 (710)는 버튼 눌러짐이 눌러지면 탐지되면 이벤트를 발생시키고 버튼 릴리즈 (release)가 탐지되면 다른 이벤트를 발생시킨다. 또한 상기 고정-길이 시리얼 시퀀스 프로토콜은 상기 제어기 기기 (710)가 버튼이 눌러진 이후에 그리고 그 버튼이 릴리즈 되기 전에 고정된 구간에서 "반복 (repeat)" 이벤트를 발생시키는 것을 가능하게 한다. 이런 반복 이벤트들은 주기적이다 (예를 들면, 매 50 ms마다). 예를 들면, 단일 버튼 누름에 대한 이벤트들의 시퀀스는 다음과 같이 표현될 수 있다:

(1) 누름 이벤트 (Press Event)

(2) 반복 이벤트 (Repeat Event)

(3) 반복 이벤트 (Repeat Events) - 매 50 ms마다 계속해서 수신됨

(4) 릴리즈 이벤트 (Release Event)

일 실시예에서, 반복 이벤트들의 주기는 상기 제어기의 펌웨어 내에서 고정된다. 그 주기는 클라이언트 애플리케이션에 의해서는 설정 불가능하다. 다른 실시예에서, 반복 이벤트들의 주기는 고정-바이트 시리얼 시퀀스를 이용하여 상기 호스트에 의해 상기 호스트 기기로부터 상기 모바일 제어기 기기로 규정될 수 있을 것이다.

두 번째 바이트 (2nd byte)와 세 번째 바이트 (third byte)는 조이스틱, 트랙볼, 가속도계 또는 다른 입력 요소들의 X 값 및 Y 값을 나타내며, 그 X 값 및 Y 값은 각각이 8 비트의 부호화되지 않은 (unsigned) 수 (1 내지 254의 범위로 잘라진다)로서 표시된다. 마지막 바이트는 0xFF로 표현되는 종결 바이트이다. 상기 데이터 값들이 255 (이는 16진수 표현으로는 0xFF이다)에 절대로 도달하지 않도록 제한되기 때문에, 0xFF의 프레이밍 (framing) 바이트 값은 데이터 스트림의 마지막을 확실하게 나타낸다는 것이 보장된다.

도 9는 종결 바이트 (다섯 번째 (5th) 바이트로서 0xFF 또는 255, 또는 종결 바이트)를 구비한 5-바이트 시퀀스에 대한 예시적인 바이트 시퀀스를 도시한다. 이 예에서, 첫 번째 두 개의 바이트들은 버튼과 키패드 (keypad) 이벤트들을 나타낸다. 고정-길이 시리얼 시퀀스 프로토콜의 세 번째 바이트 (3rd byte) 및 네 번째 바이트 (4th byte)는 X 값 및 Y 값을 포함한다. 이 값들의 각각은 부호화되지 않은 8 비트 값으로서 표현되며, 이 값은 절단되어 그 데이터 값들은 항상 1 내지 254까지의 범위이다. 다섯 번째 바이트 (5th Byte)는 펌웨어 및 드라이버 레거시 (legacy) 버전들이 5-바이트 패킷이 종단 (end)을 탐지하는 것을 돕기 위해 사용된다. 프레이밍 (framing) 바이트에는 실제 데이터의 허용 가능한 범위 (예를 들면, 0xFF 또는 255) 외부에 있는 고정된 값이 할당된다. 상기 데이터 값들은 255 (이는 16진수 표현으로는 0xFF이다)에 절대로 도달하지 않도록 제한되기 때문에, 0xFF의 프레이밍 (framing) 바이트 값은 데이터 스트림의 마지막을 확실하게 나타낸다는 것이 보장된다.

양방향 시리얼 통신 프로토콜 기반의 메커니즘

플랫폼 독립의 통신 프로토콜 (134)은 블루투스 시리얼 포트 프로파일 (Bluetooth Serial Port Profile (SPP))과 같은 전송 메커니즘을 통해서 동작하는 양방향 시리얼 통신 프로토콜로서 구현될 수 있다. 바이트 시퀀스는 길이에 있어서 가변일 수 있으며 설계에 있어서 유연하고 확장 가능하다. Bluetooth Special Interest Group이 휴먼 인터페이스 기기 프로파일 (Human Interface Device Profile (HIDP))을 규정했지만, 불루투스의 J2ME (Java 2 Micro Edition) 구현 (JSR-82)은 HIDP를 필수적으로 지원하지는 않는다. 또한 J2ME도 HIDP에 의해 요청되는 2개의 동시 L2CAP 접속을 필수적으로 지원하지는 않는다. 그러므로, 본 명세서에서 설명되는 상기 양방향 시리얼 통신 프로토콜은 J2ME를 지원하면서도 HIDP를 모방하고 설계되고 그리고 SPP 접속 (또는 L2CAP와 같은 다른 접속들)을 통해서 HIDP와 유사한 데이터가 흐르도록 설계된다.

도 10은 블루투스 시리얼 포트 프로파일 (SPP)을 통해 양방향 시리얼 통신 프로토콜 기반의 메카니즘을 구현하기 위한 예시적인 통신 스택 (1000)을 도시한다. 상기 통신 스택 (1000)은 HID 프로파일에서 사용되었던 것을 바탕으로 모델링된 메커니즘을 이용하여 제어기 기기 (1010)와 호스트 기기 (1020) 사이에서의 양방향 통신들을 제공한다. 상기 제어기 기기 (1010) 측은 기저대역 계층 (1012) (예를 들면, 블루투스), L2CAP 계층 (1014), RFCOMM 계층 (1015), SPP 계층 (1016), 양방향 시리얼 통신 프로토콜 계층 (1017) 및 제어기 펌웨어 (1018)을 포함한다. 상기 호스트 기기 (1020) 측은 기저대역 계층 (1022), L2CAP 계층 (1024), RFCOMM 계층 (1025), SPP 계층 (1026), 양방향 시리얼 통신 프로토콜 계층 (1027) 및 호스트 애플리케이션 계층 (1029)을 포함한다.

양방향 시리얼 통신 프로토콜 (900, 1100)의 몇몇 구현들에서, 고정된 개수의 미리 정의된 바이트 시퀀스들 또는 보고 포맷들은 상기 호스트 기기 (1020)와 모바일 제어기 기기 (1010)가 센서 정보, 상태 정보 및 다른 유형의 데이터를 포함하는 다양한 데이터를 교환할 수 있도록 구현된다. 상기 바이트 시퀀스의 구조는 완전히 확장 가능하도록 설계되어, 표준 센서 유형들의 집합이 처음에 지원될 수 있고 더 많은 센서 유형들은 그런 센서들이 개발되게 될 것이므로 시간이 지나면서 지원될 수 있도록 한다.

도 11은 양방향 시리얼 통신 프로토콜 (700, 1000)을 위한 예시적인 바이트 시퀀스를 도시한다. 상기 바이트 시퀀스 용으로 미리 결정된 구조는 상기 제어기 기기 (1010)와 호스트 기기 (1020) 두 가지 모두에서 드라이버들에 의해 분석된다. 그 바이트 시퀀스는 데이터의 가변 길이 시리얼화를 지원하기 위해 특별히 설계된다. 그 바이트 시퀀스 길이는 첫 번째 바이트 (바이트 (byte) 0)로서 인코딩된다. 그 바이트 0에서 인코딩된 정보는 그 데이터 패킷의 바이트 시퀀스 길이를 나타낸다. 보고 유형 식별자 (예를 들면, HIDP에 대한 것들과 유사하다)는 바이트 1에서 인코딩된다. 바이트 1에서 인코딩된 특정 보고 유형에 부속된 파라미터들은 바이트 2에서 바이트 n으로 시리얼화되며, 이 경우 n은 바이트 시퀀스 길이이다. 바이트 0이 들어올 데이터 패킷의 바이트 시퀀스 길이를 나타내기 때문에, 바이트 1로부터 시작하는 바이트들 (예를 들면, 1 바이트부터 n 바이트까지)은 바이트 길이 그리고 처리될 부속 데이터를 반영한다. 그 파라미터들의 유형과 의미론 (sementics), 그 파라미터들의 순서 결정되는 방식 그리고 그 파라미터들의 차지하는 바이트들의 개수는 하나의 보고 유형으로부터 다른 보고 유형으로 변할 수 있을 것이다. 상기 파라미터들이 하나 이상의 바이트를 차지하면 (예를 들면, 하나의 타임스탬프는 완전한 표현을 위해서 4 바이트를 필요로 할 수 있을 것이다), 그 바이트들은 최상위 바이트 (most significant byte (MSB))가 먼저 오는 (빅 엔디안 (Big Endian) 규칙이라고 알려진) 바람직한 네트워크 규약으로 시리얼화될 수 있을 것이다. 대안의 구현의 예에서, 상기 바이트들은 최하위 바이트 (least significant byte (LSB))가 먼저 오는 (리틀 엔디안 (Little Endian) 규칙이라고 알려진) 방식으로 시리얼화될 수 있을 것이다.

크기가 작아서 255-바이트 엔빌로프 (envelope) 내에 그 이진 포맷이 딱 들어갈 수 있을 정도로 시리얼화가 가능한 데이터는 본 명세서에서 설명된 것과 같은 양방향 시리얼 통신 프로토콜을 이용하여 쉽게 이동될 수 있을 것이다. 더 큰 데이터 패킷들은 많은 더 작은 연속적인 패킷들로 시리얼화되고 분리되며, 각 패킷은 255-바이트 엔빌로프 내에 딱 들어갈 수 있도록 설계된다. 상기 더 큰 데이터 패킷들을 분리된 개수의 더 작은 패킷들로 분할함으로써, 시리얼화 가능한 임의의 데이터 스트림은 양방향 시리얼 통신 프로토콜을 이용하여 전송될 수 있다.

분석기/시리얼화기 (parsers/serializer)들의 한 쌍의 세트는 그런 보고들을 어떻게 번역해야 하는지를 이해하는 모바일 제어기 기기 측 (710, 1010)과 호스트 기기 측 (720, 1020) 둘 모두에 제공될 수 있다. 최선의 호환성을 위해, 상기 양방향 시리얼 통신 프로토콜을 위한 상기 분석기들 및 시리얼화기들은 상기 양 측에서 버전이 부합된다 (version-matched). 그러나, 상기 모바일 제어기 기기 측 (710, 1010)이나 상기 호스트 기기 측 (720, 1020) 중의 어느 하나에서의 분석기의 어떤 버전은 상기 첫 번째 바이트에서 인코딩된 바이트 길이를 기반으로 하여 새로운 시리얼 통신을 수신할 수 있도록 그리고 상기 분석기가 상기 보고 유형 식별자를 인식하는가의 여부를 판별하기 위해상기 두 번째 바이트를 검사할 수 있도록 설계될 수 있다. 상기 보고 유형 식별자가 인식되는가의 여부에 따라서, 상기 분석기는 상기 보고 유형 식별자에 따라서 동작하도록 또는알려지지 않은 보고 유형 식별자를 탐지한 것을 기반으로 하여 상기 수신한 시리얼 보고를 무시하도록 선택될 수 있을 것이다.

다음의 단락들은 상기 모바일 제어기 기기들이 데이터를 호스트 기기들로 그리고 그 호스트 기기로부터 전달하기 위한 양방향 시리얼 통신 프로토콜의 예시적인 구현을 상세하게 설명한다. 그 예들은 예시의 목적을 위해서만 제공되며, 그리고 상기 바이트 시퀀스의 다른 특정한 구현들이 가능하다. 추가로, 지원되는 센서들의 유형들 그리고 전달된 데이터 유형들 또한 예일 뿐이다. 그런 구현들은 본 명세서에서 설명된 양방향 통신 프로토콜 메커니즘 하에서 구현된 플랫폼 독립적인 통신 프로토콜 (134) 아래에서 다른 센서 유형들 및 다른 데이터 유형들을 지원하는 것을 가능하게 할 수 있다.

상기 호스트 기기 (1020) 상에서의 SPP 데이터 스트림은 방해받지 않은 (uninterrupted) 데이터 스트림으로 보인다. 이 명세서에서 설명된 것과 같은 양방향 시리얼 통신 프로토콜은 패킷-지향이며 (packet-oriented), 그 경우 각 메시지는 패킷 내에서 캡슐화된다. 상기 호스트 기기의 SPP 구현이 패킷의 개념을 숨기기 때문에, "엔빌로프 방식 (envelope scheme)"이 제공된다. 특히, 각 메시지는 바이트 카운트를 뒤따른다. 예를 들면, 상기 호스트 기기 (1020)가 상기 제어기 기기 (1010)로 SET_IDLE 메시지를 12의 값으로 송신하기를 원하면, 상기 SET_IDLE 메시지는 도 12에 도시된 것과 같이 포맷된다 (상기 SET_IDLE 메시지에 대한 상세한 것은 이하를 참조한다). 상기 호스트 기기 (1020)는 이어지는 바이트들을 0x02 0x90 OxOC의 데이터 스트림에 기록한다.

첫 번째 바이트 (0x02)는 다음의 메시지 내의 바이트들의 개수 (즉, 바이트 카운트)를 나타낸다. 다음의 두 바이트들인 0x90 (SET_IDLE 메시지 헤더) 그리고 OxOC (SET_IDLE 값)은 SET_IDLE 메시지로 번역된다.

일부 구현예들에서, 전방 호환성을 유지하기 위해, 인식되지 않은 데이터 패킷들 (즉, 입력 보고 및 출력 보고)은 무시된다.

하나의 일-바이트 (one-byte) 핸드세이크 (Handshake) 메시지는 SET_IDLE 메시지 또는 DATA OUTPUT 메시지로서 송신된다. 올바른 핸드세이크 값들의 목록은 다음을 포함한다:

HANDSHAKE_SUCCESSFUL OxOO

HANDSHAKE_NOT_READY OxOl

HANDSHAKE_ERR_INVALID_REPORT_ID 0x02

HANDSHAKE_ERR_UNSUPPORTED_REQUEST 0x03

HANDSHAKE_ERR_INVALID_PARAMETER 0x04

HANDSHAKE_ERR_UNKNOWN OxOE

HANDSHAKE_ERR_FATAL OxOF

디폴트로, 상기 제어기 기기 (1010)는 버튼 상태가 변경될 때마다 (즉, 버튼이 눌리거나 릴리즈될 때에) 입력 (예를 들면, 버튼) 이벤트들을 송신한다. 상기 제어기 기기 (1010)는 버튼 반복 이벤트들을 고정된 주기로 송신하는 것을 지원한다. 이 고정된 주기는 상기 제어기의 아이들 레이트 (idle rate) (즉, 반복 레이트)를 설정하여 상기 SET_IDLE 메시지 내에서 식별된다.

영 (0)의 아이들 레이트는 버튼 반복 이벤트들이 발생하지 않았다는 것으로서 번역된다. 이는 새로운 접속이 설립될 때마다 상기 제어기 기기 (110, 710, 1010)의 디폴트 행동이다. 상기 호스트 기기 (120, 720, 1020)는 새로운 반복 레이트를 규정하기 위해 SET_IDLE 메시지를 상기 제어기 기기 (110, 710, 1010)로 송신할 수 있다. 상기 반복 레이트는 상기 SET_IDLE 메시지 내로 송신되어 설정 시간 양 (예를 들면, 4 ms)과 곱해진 값이 되도록 설정된다. 예를 들면, 12의 값과 함께 SET_IDLE 메시지를 송신하면 48 ms 마다 상기 제어기 기기 (110, 710, 1010) 발생 버튼 반복 이벤트들을 구비하게 되는 것이다.

상기 SET_IDLE 메시지는 다양한 적용 가능한 값들을 사용하여 응답된다. 예를 들면, 올바른 SET_IDLE 메시지에 대한 응답은 0x00의 HANDSHAKE_SUCCESSFUL 값이다. 대안으로, SET_IDLE 메시지의 길이가 2 바이트 길이가 아니라는 것이 탐지되면, 00x4의 HANDSHAKE_ERR_ INVALID_PARAMETER 값이 응답으로 송신된다. 또한, 상기 규정된 아이들 레이트가 접속의 레이턴시 (latency) (50 ms로 가정한다)보다 작으면, 상기 제어기 기기 (110, 710, 1010)는 상기 레이턴시와 같도록 상기 아이들 레이트를 설정한다. 도 13은 아이들 레이트를 보여주는 예시적인 데이터 시퀀스를 설명한다.

제어기 기기 (110, 710, 1010) 사이에서의 접속이 설립되면, 다양한 표준 보고들이 상기 호스 기기 (120, 720, 1020)로 송신된다. 상기 송신된 표준 보고는 (1) 버전 보고; (2) 버튼 카운트를 보여주는 설정 데이터 보고 카운트 (Configuration Data Report); (3) 영 (0) 또는 그 이상의 버튼 메타데이터 보고들 (Button Metadata Reports); (4) 영 또는 그 이상의 설정 데이터 보고들; 및 (5) OxFF의 유형과 0x00000000의 값을 구비한 설정 데이터 보고를 포함한다. 추가로, 다른 맞춤 보고들이 송신될 수 있다.

표준 보고는 하나의 API에서 사용하는 것이 가능한 입력과 출력을 나타낸다. 예를 들면, "입력"은 상기 제어기 기기 (110, 710, 1010)로부터 상기 호스트 기기 (120, 720, 1020)로 흐르는 데이터인 것으로 간주된다. "출력"은 상기 호스트 기기 (120, 720, 1020)로부터 상기 제어기 기기 (110, 710, 1010)로 흐르는 데이터인 것으로 간주된다. 모든 다중-바이트 값들은 네트워크 바이트 순서 (빅 엔디언)로 송신된다. 모든 스트링들은 UTF-8 (8-bit UCS/Unicode Transformation Format)로 송신된다. 이것이 표준의 규약이지만, 다중-바이트 값들 및 스트링들은 다른 바이트 순서 및 다른 스트링 포맷으로도 송신될 수 있다.

도 14는 버전 보고 (Version Report)를 위한 예시적인 바이트 시퀀스를 도시한다. 0x03의 입력 보고 ID (Report ID)가 상기 버전 보고에 할당된다. 접속이 설립된 후에, 상기 버전 보고는 송신된 최초의 패킷이다. 펌웨어 메이저 버전 (Firmware Major Version) (바이트 2-3)은 양방향 시리얼 통신 프로토콜의 버전을 식별한다. 펌웨어 마이너 버전 (Firmware Minor Version) (바이트 4-5)은 상기 펌웨어가 특징들이 부가될 때마다 증가된다. 펌웨어 리비전 (Firmware Revision) (바이트 6-7)은 새로운 릴리즈가 수행될 때마다 (예를 들면, 버그 수정) 증가된다. 플랫폼 ID (Platform ID) (바이트 8-9)은 표 1에서 도시된 것과 같이 현재의 플랫폼 (예를 들면, 하드웨어 또는 프로세서)을 식별한다.

표 1: 플랫폼 ID 값들

0x0000: BlueCore4 PNG

0x0001 : PIC

0x0002-0xFFFF: Reserved

모델 ID (Model ID)는 상기 제어기 모델의 레이아웃을 식별한다.

도 15는 설정 데이터 보고 입력 보고를 위한 예시적인 바이트 시퀀스를 도시한다. 입력 보고 ID (report ID) (예를 들면, 0x05)는 설정 데이터 보고에 할당된다. 접속하고 버전 보고를 송신한 후에, 상기 제어기 기기 (110, 710, 1010)는 상기 호스트 기기 (120, 720, 1020)로 하나 또는 그 이상의 설정 데이터 보고들을 송신한다. 유형 필드 (type field) (바이트 2)는 상기 설정 데이터 보고 내에 송신된 제어기 설정 데이터를 규정한다. 올바른 유형 값들의 목록이 표 2에 목록으로 보여진다.

표 2: 설정 데이터 보고들을 위한 유형 값들의 목록

0x01: 버튼 카운트

0x02: 2-축 조이스틱 카운트

0x03: 샘플당 2-축 조이스틱 비트들

0x04: 2-축 조이스틱 로 (Raw) 중심 X 눈금

0x05: 2-축 조이스틱 로 (Raw) 중심 Y 눈금

0x06: Trackball 카운트

0x07: 샘플당 트랙볼 비트들

0x08: 패들 (Paddle) 카운트

0x09: 샘플당 패들 비트들

OxOA: 스크롤 휠 카운트

OxOB: 샘플당 스크롤 휠 비트들

OxOC: 3-축 가속도계 카운트

OxOD: 샘플당 가속도계 3-축 비트들

OxOE: 배터리 최대 전압 mV (범위: 0-65535)

OxOF: 배터리 최소 전압 mV (범위: 0-65535)

0x10: 배터리 경고 전압 mV (범위: 0-65535)

OxFF: 설정 데이터 완료 (값 = 0). 이 값은 더 이상의 설정 데이터가 송신되지 않을 것을 호스트 기기 (120, 220, 720, 920, 1120)에게 알리기 위해 송신된다.

상기 값 (Value) 필드 (바이트 3)는 유형 (Type) 필드 (바이트 2)에 의해 규정된 유형에 대응하는 값을 포함한다. 상기 제어기 기기 (110, 710, 1010)에 속한 그런 데이터만이 상기 호스트 기기 (120, 720, 1020)로 송신될 것이다. 다른 말로 하면, 상기 제어기 기기 (110, 710, 1010)가 어떤 가속도계도 가지고 있지 않다면, 어떤 가속도계 카운트도 송신되지 않는다.

샘플당 비트들의 개수 b는 2보다는 크고 32 이하이다. 연관된 보고들에서 허용된 값들의 범위는 (-2 ^b-1 )부터 (2 ^b-1 )까지의 범위로 표현된다. 예를 들어, 일 실시예에서, 8-비트 조이스틱에 대한 값들의 범위는 -128 부터 127 까지를 포함할 수 있다 (상기 값들은 부호화된 8 비트 값을 나타내며, 0은 조이스틱 동작 범위의 중간이다). 12-비트 조이스틱에 대해서, 값들의 범위는 -2048 부터 2047 까지 이다. 몇몇의 구현들에서, 8-비트 조이스틱에 대한 값들의 범위는 0부터 255까지의 범위인 것이 가능하다 (이 값들은 부호화되지 않은 8 비트 값을 나타내며, 128은 동작 범위의 중간이다). 12-비트 조이스틱에 대해, 값들을 범위는 0-4095를 포함할 수 있으며, 이는 부호화되지 않은 12-비트 숫자를 나타내며, 2048은 동작 범위의 중간이다.

다양한 아날로그 제어들 (예를 들면, 조이스틱, 가속도계, 패들)을 위한 샘플당 비트들의 개수가 주어지면, 상기 제어기 기기 (110, 710, 1010)는 상기 샘플당 비트들의 개수에 맞는 가장 작은 크기의 입력 보고들을 방출한다. 다른 말로 하면, 샘플당 10 비트들을 가지는 2-축 조이스틱은 16-비트 2-축 조이스틱 보고로 송신된다.

도 16은 버튼 메타데이터 보고를 위한 예시적인 바이트 시퀀스를 도시한다. 0x04의 입력 보고 (report ID) ID 가 상기 버튼 메타데이터 보고에 할당된다. 설정 데이터 보고들을 송신한 후에, 상기 제어기 기기 (110, 710, 1010)는 상기 제어기 상의 각 버튼마다 하나의 버튼 메타데이터 보고를 송신한다. 상기 버튼 메타데이터 보고는 상기 버튼 보고들에서 보고된 동일한 버튼 ID인 버튼 ID (Button ID) (바이트 2)를 포함한다. 버튼 서술 (button description) 필드는 그 버튼의 사람이 읽을 수 있는 표현이다 (예를 들면, "발사" 또는 "위 (Up)"). 권장 게임 동작 (recommended game action) 필드 (바이트 3)는 각 버튼에 대한 권장되는 의미들을 제공한다. 권장 게임 동작 필드를 위한 값들의 목록은 표 3에서 제공된다. 이 범위 외의 권장 게임 동작 값들은 정의되지 않은 것으로 취급된다.

표 3: 권장 게임 동작을 위한 유형 값들의 목록

0x00: 정의되지 않음

0x01: 위

0x02: 아래

0x03: 왼쪽

0x04: 오른쪽

0x05: 발사

0x06: 게임 A

0x07: 게임 B

0x08: 게임 C

0x09: 게임 D

도 17은 인에이블/디세이블 (Enable/Disable) 보고 유형을 위한 예시적인 바이트 시퀀스를 도시한다. 0x06의 출력 보고 ID 값이 인에이블/디세이블 보고 (바이트 1)에 할당된다. 인에이블/디세이블 보고의 바이트 2는 인에이블되거나 디세이블될 수 있는 보고 ID를 포함한다. 제어기 기기로부터 호스트 기기로 흐르는 어떤 입력 보고도 인에이블되거나 또는 디세이블될 수 있다. 바이트 3의 비트 0은 인에이블되거나 또는 규정된 보고 ID를 디세이블하도록 클리어되도록 설정된다.

인에이블/디세이블 보고 내의 바이트 3의 비트 1은 상기 보고가 조건부 (conditioned)이어야 하는가의 여부를 규정한다. 바이트 3의 비트 1이 세트된 것으로 탐지되면, 규정된 유형의 보고들은 조건부가 아니다. 그 비트가 클리어된 것으로 탐지되면, 상기 규정된 유형의 보고들은 상기 제어기 기기 상의 신호 조건화 소프트웨어 알고리즘으로 선택적으로 조건부가 된다. 신호 조건화는 상기 조이스틱의 중심 주위의 "폐기 영역 (dead zone)", 데이터 범위의 제한들에서의 끊음 (truncation), 주어진 범위에서 결과 데이터를 생성하기 위해 가공되지 않은 상태의 (raw) 데이터 크기 조절 또는 다른 동작들의 구현에 결부된다. 규정된 보고 ID가 아날로그 보고가 아니거나 크기 조절을 사용하지 않는 아날로그 보고인 것이 탐지되면, 바이트 3의 비트 1은 무시된다 (아무런 크기 고절도 발생할 수 없기 때문에). 규정된 보고 ID가 인에이블되거나 또는 디세이블될 수 없음이 탐지되면, 또는 규정된 보고 ID가 인식되지 않으면, HANDSHAKE_ERR_INVALID_PARAMETER가 반환된다. 그렇지 않은 경우에는, HANDSHAKE_SUCCESSFUL 이 반환된다.

도 18은 버튼 보고를 위한 예시적인 바이트 시퀀스를 도시한다. 0x07의 입력 보고 ID 값이 (바이트 1)에 할당된다. 상기 버튼 보고는 눌러진 키들을 나타내는 키 코드들 (key codes) (바이트 2-7)의 어레이를 제시한다. 여섯 개의 키 (예를 들면 Keycode 1-6) 중의 하나 또는 그 이상은 임의의 주어진 시각에 구동될 수 있다. 키 코드들은 0x00에서부터 순차적으로 할당된 값들이다. 이런 키 코드들은 버튼 번호를 반영한다. 버튼들은 하드웨어 설계의 과정에서 석차순으로 번호가 부여된다. 최대 키 코드 값은 0xFD이다.

상기 키 코드들은 증가하는 순서로 상기 보고에서 목록화되어 있다. n번째 키가 눌려지지 않았다면, 구동되지 않은 버튼에 대한 키 코드는 KEYCODE_NO_EVENT (OxFE)로서 보고된다. 6개 이상의 키들 (버튼들)이 눌려진 것이 감지되면, 6개 모든 키 코드들이 KEYCODE_ERROR_ROLL_OVER (OxFF)로서 보고된다.

아이들 레이트 (idle rate)가 규정되지 않았다면, 또는 아이들 레이트가 "0"으로 설정되었다면, 버튼 상태가 변경될 때마다 버튼 보고들이 송신된다. 대안으로, 영 아닌 (nonzero) 아이들 레이트가 규정된 것이 탐지되면, 하나 또는 그 이상의 버튼들이 규정된 아이들 레이트로 눌려질 때마다 버튼 보고들이 반복해서 송신된다. 아래에서 SET_IDLE에 대해 추가로 설명된다.

도 19는 8-비트 아날로그 2-축 조이스틱 보고를 위한 예시적인 바이트 시퀀스를 도시한다. 0x08의 입력 보고 ID (Report ID) 값이 할당된다 (바이트 1). 조이스틱 ID (Joystick ID) (바이트 2) 값이 설정 데이터 (입력 보고 (0x05) 참조)에 의해 보고된 조이스틱의 전체 개수에 대해 검사되며 새로운 조이스틱 각각은 0부터 n-1까지 순차적으로 번호가 매겨지며, 이 경우 n은 상기 제어기 내에 존재하는 조이스틱의 전체 개수와 동일하다. 그러므로, 예를 들면, 첫 번째 조이스틱에게는 0x00의 조이스틱 ID 값이 할당된다.

중심 위치는 (0, 0)으로서 보고된다. X-축 눈금 (reading)은 조이스틱이 오른쪽으로 이동할수록 증가한다. Y-축 눈금은 조이스틱이 아래로 움직일수록 증가한다. 로 (raw) 비트 (바이트 2의 비트 7)가 세트된 것이 탐지되면, 그 눈금은 조건부가 아니다. 대안으로, 상기 로 비트가 클리어되면 상기 눈금은 조건부이다.

도 20은 예시적인 16-비트 아날로그 2-축 조이스틱 보고이다. 0x09의 입력 보고 ID 값이 할당된다 (바이트 (Byte) 1). 상기 조이스틱 ID 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 조이스틱 카운트보다 더 작다. 그러므로, 첫 번째 조이스틱에는 0x00의 ID 값이 할당된다.

유사하게 설계된 8-비트 보고에서와 같이 16-비트들이 각 축 눈금을 위해서 할당된다. 중심 위치는 (0, 0)으로서 보고된다. X-축 눈금 (reading)은 조이스틱이 오른쪽으로 이동할수록 증가한다. Y-축 눈금은 조이스틱이 아래로 움직일수록 증가한다. 로 (raw) 비트 (바이트 2의 비트 7)가 세트된 것이 탐지되면, 그 눈금 (reading)은 조건부가 아니다. 대안으로, 상기 로 비트가 클리어되면 상기 눈금은 조건부이다.

도 21은 예시적인 32-비트 아날로그 2-축 조이스틱 보고이다. 0x0A의 입력 보고 ID (Report ID) 값이 할당된다 (바이트 (Byte) 1). 상기 조이스틱 ID 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환된 조이스틱 카운트보다 더 작다. 그러므로, 첫 번째 조이스틱에는 0x00의 ID 값이 할당된다.

유사하게 설계된 8-비트 보고에서와 같이 32-비트들이 각 축 눈금 용으로 할당된다. 중심 위치는 (0, 0)으로서 보고된다. X-축 눈금 (reading)은 조이스틱이 오른쪽으로 이동할수록 증가한다. Y-축 눈금은 조이스틱이 아래로 움직일수록 증가한다. 로 (raw) 비트 (바이트 2의 비트 7)가 세트된 것이 탐지되면, 그 눈금은 조건부가 아니다. 대안으로, 상기 로 비트가 클리어되면 상기 눈금은 조건부이다.

도 22는 예시적인 8-비트 아날로그 3-축 가속도계 보고를 도시한다. 0x0B의 입력 보고 ID 값이 할당된다 (바이트 1). 가속도계 ID 값은 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 조이스틱 카운트보다 더 작다. 그러므로, 첫 번째 가속도계에는 0x00의 ID 값이 할당된다. 로 (raw) 비트 (바이트 2, 비트 7)가 세트된 것이 탐지되면, 눈금 (reading)은 조건부가 아니다. 그 로 비트가 클리어되면, 눈금은 조건부이다.

도 23은 예시적인 16-비트 아날로그 3-축 가속도계 보고를 도시한다. 0x0C의 입력 보고 ID 값이 할당된다 (바이트 1). 가속도계 ID 값은 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 조이스틱 카운트보다 더 작다. 그러므로, 첫 번째 가속도계에는 0x00의 ID 값이 할당된다. 로 (raw) 비트 (바이트 2, 비트 7)가 세트된 것이 탐지되면, 눈금은 조건부가 아니다. 그 로 비트가 클리어되면, 눈금은 조건부이다.

도 24는 예시적인 32-비트 아날로그 3-축 가속도계 보고를 도시한다. 0x0D의 입력 보고 ID 값이 할당된다 (바이트 1). 가속도계 ID 값은 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 조이스틱 카운트보다 더 작다. 그러므로, 첫 번째 가속도계에는 0x00의 ID 값이 할당된다. 로 (raw) 비트 (바이트 2, 비트 7)가 세트된 것이 탐지되면, 눈금은 조건부가 아니다. 그 로 비트가 클리어되면, 눈금은 조건부이다.

도 25는 예시적인 8-비트 아날로그 패들 보고를 도시한다. 일 실시예에서, 패들은 고정된 동작 범위의 회전 전위차계로서 하드웨어로 구현된다. 0x0E의 입력 보고 ID 값이 할당된다 (바이트 1). 패들 ID (Paddle ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 패들 카운트보다 더 작다. 그러므로, 첫 번째 패들에는 0x00의 ID 값이 할당된다. 중심 위치는 "0"으로서 보고될 것이다. 로 (raw) 비트 (바이트 2, 비트 7)가 세트된 것이 탐지되면, 눈금 (reading)은 조건부가 아니다. 그 로 비트가 클리어되면, 눈금은 조건부이다.

도 26은 예시적인 16-비트 아날로그 패들 보고를 도시한다. 0x0F의 입력 보고 ID 값이 할당된다 (바이트 1). 패들 ID (Paddle ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 패들 카운트보다 더 작다. 그러므로, 첫 번째 패들에는 0x00의 ID 값이 할당된다. 중심 위치는 "0"으로서 보고될 것이다. 로 (raw) 비트 (바이트 2, 비트 7)가 세트된 것이 탐지되면, 눈금 (reading)은 조건부가 아니다. 그 로 비트가 클리어되면, 눈금은 조건부이다. 각 눈금에는 16-비트들이 할당된다.

도 27은 예시적인 32-비트 아날로그 패들 보고를 도시한다. 0x10의 입력 보고 ID 값이 할당된다 (바이트 1). 패들 ID (Paddle ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 패들 카운트보다 더 작다. 그러므로, 첫 번째 패들에는 0x00의 ID 값이 할당된다. 중심 위치는 "0"으로서 보고될 것이다. 로 (raw) 비트 (바이트 2, 비트 7)가 세트된 것이 탐지되면, 눈금 (reading)은 조건부가 아니다. 그 로 비트가 클리어되면, 눈금은 조건부이다. 각 눈금에는 32-비트들이 할당된다.

도 28은 예시적인 16-비트 배터리 레벨 보고를 도시한다. 0x11의 입력 보고 ID 값이 할당된다 (바이트 1). 배터리 레벨 보고들은 고정된 레이트로 송신된다 (예를 들면, 매 60초마다 한번씩). 바이트 2-3은 현재의 배터리 눈금을 포함한다. 배터리 레벨 눈금을 위해 16 비트들이 할당된다.

도 29는 예시적인 8-비트 트랙볼 보고를 도시한다. 0x12의 입력 보고 ID 값이 할당된다 (바이트 1). 트랙볼 ID (Trackball ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 트랙볼 카운트보다 더 작다. 그러므로, 첫 번째 트랙볼에는 0x00의 ID 값이 할당된다. 트랙볼이 오른쪽으로 이동하면 X 눈금은 양의 값으로 탐지된다. 트랙볼이 아래로 이동하면 Y 눈금은 양의 값으로 탐지된다. X 눈금 및 Y 눈금용으로 8 비트들이 할당된다.

도 30은 예시적인 16-비트 트랙볼 보고를 도시한다. 0x13의 입력 보고 ID 값이 할당된다 (바이트 1). 트랙볼 ID (Trackball ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 트랙볼 카운트보다 더 작다. 그러므로, 첫 번째 트랙볼에는 0x00의 ID 값이 할당된다. 트랙볼이 오른쪽으로 이동하면 X 눈금은 양의 값으로 탐지된다. 트랙볼이 아래로 이동하면 Y 눈금이 양의 값으로 탐지된다. X 눈금용으로 16 비트들이 할당되며, 그리고 Y 눈금용으로 16 비트들이 할당된다.

도 31은 예시적인 32-비트 트랙볼 보고를 도시한다. 0x14의 입력 보고 ID 값이 할당된다 (바이트 1). 트랙볼 ID (Trackball ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 트랙볼 카운트보다 더 작다. 그러므로, 첫 번째 트랙볼에는 0x00의 ID 값이 할당된다. 트랙볼이 오른쪽으로 이동하면 X 눈금은 양의 값으로 탐지된다. 트랙볼이 아래로 이동하면 Y 눈금이 양의 값으로 탐지된다. X 눈금용으로 32 비트들이 할당되며, 그리고 Y 눈금용으로 32 비트들이 할당된다.

도 32는 예시적인 8-비트 스크롤 휠 보고를 도시한다. 0x15의 입력 보고 ID 값이 할당된다 (바이트 1). 스크롤 휠 ID (Scroll Wheel ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 트랙볼 카운트보다 더 작다. 그러므로, 첫 번째 스크롤 휠에는 0x00의 ID 값이 할당된다. 눈금이 양이라고 탐지되면, 스크롤 휠은 멀어지게 움직였거나 (move away) 왼쪽으로 움직였다고 결정된다. 눈금이 음이라고 탐지되면, 스크롤 휠은 가까워지게 움직였거나 오른쪽으로 움직였다고 결정된다.

도 33은 예시적인 16-비트 스크롤 휠 보고를 도시한다. 0x16의 입력 보고 ID 값이 할당된다 (바이트 1). 스크롤 휠 ID (Scroll Wheel ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 트랙볼 카운트보다 더 작다. 그러므로, 첫 번째 스크롤 휠에는 0x00의 ID 값이 할당된다. 눈금이 양이면, 스크롤 휠은 멀어지게 움직였거나 (move away) 왼쪽으로 움직였다고 결정된다. 눈금이 음이면, 스크롤 휠은 가까워지게 움직였거나 오른쪽으로 움직였다고 결정된다. 눈금을 위해 16-비트들이 할당된다.

도 34는 예시적인 32-비트 스크롤 휠 보고를 도시한다. 0x17의 입력 보고 ID 값이 할당된다 (바이트 1). 스크롤 휠 ID (Scroll Wheel ID) 값은 상기 설정 데이터 (입력 보고 (0x05))에 의해 반환되는 트랙볼 카운트보다 더 작다. 그러므로, 첫 번째 스크롤 휠에는 0x00의 ID 값이 할당된다. 눈금이 양이면, 스크롤 휠은 멀어지게 움직였거나 (move away) 왼쪽으로 움직였다고 결정된다. 눈금이 음이면, 스크롤 휠은 가까워지게 움직였거나 오른쪽으로 움직였다고 결정된다.

상기에서 설명된 것과 같이, 아날로그 보고들은 가공되지 않은 상태 (raw)로 배송된다 (조건부가 아니다). 일반적으로, 조건부 보고들은 0에 중심이 위치하고 (샘플-당-비트들 설정 데이터 보고에서 규정된 것과 같은) 미리 결정된 범위를 채우도록 크기 조절된 부호화된 눈금들을 송신하도록 설계된다. 가공되지 않은 보고들은 처리되지 않았던 값들을 구비한 보고들이다. 상기 가공되지 않은 보고들은 부호화되지 않았으며 중심 눈금은 상기에서 규정된 설정 데이터 보고에 의해 규정된다. 예를 들면, 보고가 가공되지 않은 것으로 검출되면, 그 눈금들은 부호화되지 않은 것이다. 대안으로, 보고가 조건부라면, 그 눈금들은 부호화된 것이다.

다양한 출력 보고들 역시 제공될 수 있다. 도 35는 가공되지 않고 조건부인 8-비트 아날로그 2-축 조이스틱을 위한 예시적인 바이트 시퀀스를 도시한다. 0xFD의 출력 보고 (Report) ID 값이 할당된다 (바이트 (Byte) 1). 가공되지 않고 조건부인 8-비트 아날로그 2-축 조이스틱 보고는 크기 고절 알고리즘의 성능을 시험하기 위해 포함된다. 가공되지 않고 조건부인 8-비트 아날로그 2-축 조이스틱 보고는 테스팅 애플리케이션의 외부에서 사용될 용도로 의도된 것은 아니다. 가공되지 않고 조건부인 8-비트 아날로그 2-축 조이스틱 보고는 출력 보고 0x06을 이용하여 인에이블될 수 있다.

도 36은 런 루프 (Run Loop) 테스트 보고를 위한 예시적인 바이트를 도시한다. 0xFE의 출력 보고 ID 값이 할당된다. 올바른 런 루프 테스트 보고를 수신하면 제어기 기기 (110, 710, 1010)는 다음의 것들 중에서 하나 또는 그 이상을 수행한다: (1) HANDSHAKE_SUCCESSFUL로 호스트 기기 (120, 720, 1020)에게 응답; (2) (배터리 보고들을 포함한) 현재 인에이블된 모든 보고들을 디세이블 시킴; (3) 타임스탬프 보고를 송신 (입력 보고 ID OxFF); (4) n 개 리포트 송신, 이 경우 (a) n은 (바이트 4-7 에서) 규정된 반복 횟수와 같다; (b) 상기 보고는 (바이트 2에서) 규정된 유형에 관한 것이다; (c) 상기 보고는 아날로그 보고 유형이어야만 한다; 그리고 (d) 로 (raw) 비트 (바이트 3의 비트 0)가 설정되면, 아날로그 눈금들에는 어떤 크기 조절도 행해지지 않는다 (대안으로, 로 비트가 클리어되면 통상의 크기 조절이 수행된다); (5) 타임 스탬프 보고를 송신 (입력 보고 ID OxFF); 그리고 (6) 원래 인에이블된 보고들을 다시 인에이블 시킴.

또한, 원하는 보고 ID (바이트 2)가 상기 기기에 의해 지원되는 보고인 것이 탐지되면 런 루프 테스트 보고는 올바른 것이다. 예를 들면, 제어기 기기 (110, 710, 1010)가 가속도계를 구비하지 못하면, 원하는 보고 ID는 가속도계 보고를 규정할 수 없다. 대안으로, 원하는 보고 ID가 아날로그 보고 유형을 규정한다는 것이 탐지되면 상기 런 루프 테스트 보고는 올바른 것이다.

영 (0) 반복이 규정된 (예를 들면, 바이트 4-7이 모두 0x00과 같다) 런 루프 테스트 보고를 수신하면 현재 수행되는 어떤 루프 테스트도 모두 취소된다. 만일 현재 동작하는 테스트가 없다고 해도 제어기 기기는 HAND_SHAKE_SUCCESSFUL로 응답한다.

도 37은 32-비트 기기 타임스탬프 (밀리초 단위) 보고를 위한 예시적인 바이트 시퀀스를 도시한다. 0xFF의 입력 보고 ID 값이 할당된다 (바이트 1). 32-비트 기기 타임스탬프 (밀리초 단위) 보고는 내부 클록에 의해 보고된 것과 같은 제어 기기 (110, 710, 1010) 상에서의 시간을 반영한다. 32-비트 기기 타임스탬프 (밀리초 단위) 보고는 루프 테스트와 결합해서만 사용된다.

모바일 제어기 기기와 호스트 기기 사이에서의 데이터 전달

한 모습에서, 이 명세서에서 설명된 것과 같은 플랫폼 독립적인 통신 프로토콜은 휴먼 인터페이스 기기 (예를 들면, 제어기 기기 (1010))로부터 호스트 기기 (1020)로 제어 데이터 (통신 활성화)를 전달하도록 설계된다. 플랫폼 독립적인 통신 프로토콜 (134)은 다양한 제어기 기기에 의해 제어될 수 있는 게임과 같은 애플리케이션을 구동하는 호스트 기기로 데이터를 전달하기 위한 다양한 입력 메커니즘 (예를 들면, 조이스틱과 버튼 상태)을 구비한 상기 다양한 제어기 기기들에 대한 지원을 제공한다. 추가로, 본 명세서에서 설명된 것과 같은, 다른 유형의 데이터 전달을 지원하기 위해 추가의 보고들이 부가될 수 있다는 점에서 상기 플랫폼 독립적인 통신 프로토콜은 확장 가능하다. 상기 플랫폼 독립적인 통신 프로토콜이 블루투스 휴먼 인터페이스 프로파일 (Bluetooth Human Interface Profile (HID)) 또는 블루투스 시리얼 포트 프로파일 (Bluetooth Serial Port Profile (SPP)) 접속에 관하여 설명될 수 있을 것이지만, 다른 기저대역 (baseband) 접속들도 마찬가지로 이용 가능하다. 양방향 시리얼 통신 프로토콜 (1017, 1027)은 접속 유형에 독립적이다. 그러나, 다른 전송 프로토콜 (예를 들면, L2CAP)을 사용하는 것은 바이트 시퀀스 길이가 불필요하게 만들 수 있을 것이며, 또는 전송에 있어서 다른 "오버헤드"를 부과할 수 있을 것이다.

도 38은 모바일 제어기 기기와 호스트 기기 사이에서의 통신을 가능하게 하기 위한 프로세스 (3800)을 도시하는 프로세스 흐름도이다. 상기 제어기 기기에서의 펌웨어는 상기 모바일 제어기 기기에 이용 가능한 다양한 입력 메커니즘들 (예를 들면, 버튼들, 조이스틱들, 트랙볼들 등)에 의해 제공되는 입력 신호들 (예를 들면, 아날로그 신호 및 디지털 신호)을 모니터한다 (3810). 각 입력 메커니즘은 하나 또는 그 이상의 입력 요소들 (예를 들면, 버튼들)을 포함할 수 있을 것이다. 신호 이벤트가 발생할 때마다 (3820) (예를 들면, 버튼이 눌리거나, 조이스틱이 제거된다), 상기 제어기 펌웨어는 양방향 시리얼 통신 프로토콜 (1017)을 이용하여 메시지를 생성하고 그 메시지를 호스트 기기 (1020)으로 송신한다.

그 메시지는 검출된 신호 이벤트를 기반으로 하여 상기 제어기 펌웨어에 의해 생성된다 (3830). 그 메시지는, 전위차계들 또는 다중-자유도 아날로그 조이스틱들로부터의 아날로그 신호들; 광학 마우스들이나 최상위 로봇식의 기기들에서 찾을 수 있는 것과 같은 디지털 인코더들; 인가된 압력이 변경되는 것에 응답하여 비례하는 신호를 제공하는 힘 감지 저항들; 가속도계 신호 및 자이로스코프 신호; 트랙볼들로부터의 신호들; 내비게이션 스틱들을 기반으로 하는 인장 계측기 (strain gauge)와 같은 힘 감지 기기들로부터의 신호들; 광학 센서들로부터의 비례 신호들 또는 디지털 신호들; 전자기 센서들로부터의 신호들; 및 기타 유사한 것을 포함하는 게이밍 (gaming)에서 일반적으로 사용되는 센서들을 포함하는 아주 다양한 센서들을 지원하도록 설계된 많은 수의 바이트들로 구성된다. HID 기반의 접근 방식의 경우에, 바이트 시퀀스는 맞춤 서술자 (descriptor)에서 정의된다. 고정-길이 시리얼 접근 방식에서, 프리셋 바이트 구문과 상기 센서들로부터의 신호들 사이에서 최선의 부합 (match)이 발견된다. 양방향 시리얼 통신 프로토콜의 경우에, 바이트 시퀀스는 가변이며, 센서들의 실제 출력 및/또는 상기 모바일 제어기 기기로부터의 어떤 다른 데이터 출력에 완벽하게 부합된다.

상기 바이트들의 시퀀스들 중의 적어도 하나는 상기 모바일 제어 기기에 이용 가능한 입력 메커니즘들 상의 하나 또는 그 이상의 입력 요소들로 매핑된다. 예를 들면, 상기 모바일 제어기 기기가 키패드를 포함하면, 적어도 하나의 바이트들이 상기 키패드 상의 하나 또는 그 이상의 버튼들로 매핑될 수 있다. 유사하게, 조이스틱에 대해, 적어도 하나의 바이트들이 그 조이스틱의 다양한 동작들 그리고/또는 그 조이스틱의 버튼들에 매핑될 수 있다. 추가로, 각 센서 유형은 다른 보고 유형 식별자에 의해 표현될 수 있을 것이며 그래서 다양한 센서들이 동일한 펌웨어와 호스트 소프트웨어에 의해 지원될 수 있을 것이다.

상기 생성된 메시지는 상기 호스트 기기로 송신된다 (3840). 상기 호스트 기기 상에서 동작하여 호스트 애플리케이션에 링크된 제어기 드라이버는 상기 메시지를 수신하여 (3850) 그 메시지를 하나 또는 그 이상의 애플리케이션 레벨 이벤트들로 번역한다 (3860). 그러면 이렇게 번역된 이벤트들은 호스트 애플리케이션으로 송신된다 (3870). 그 호스트 애플리케이션은 상기 변역된 이벤트들을 처리한다 (3880). 예를 들면, 상기 호스트 애플리케이션이 게임이면, 상기 번역된 이벤트들은 버튼 누름, 조이스틱 움직임 등에 대응하는 게임 기능을 수행하기 위해 처리된다.

블루투스 구현 (BLUETOOTH IMPLEMENTATION)

제어기 기기와 호스트 기기 사이에서의 접속을 설립하게 위해, 제어기 기기 (1010)는 다른 기기가 접속을 주도하기를 기다린다. 호스트 기기 (1020) (예를 들면, 셀 전화기, PC, 모바일 기기 등)는 주도하여 상기 제어기 기기 (1010)로의 접속을 형성한다. 상기 제어기 기기 (1010)는 상기 호스트 기기 (1020)가 접속할 용도의 SPP 서버 (또는 L2CAP 서버 등)를 제공한다. 그 서버는 UUID (universally unique identifier)를 이용하여 서비스 디스커버리 프로파일 (Service Discovery Profile (SDP))을 경유하여 식별될 수 있다. 일 실시예에서, 이 UUID는 상기 플랫폼 독립적인 통신 프로토콜과 연관되도록 선택될 수 있다. 상기 플랫폼 독립적인 통신 프로토콜의 미래의 모든 구현들은 후방-호환성 (backwards-compatibility)을 제공하기 위해 동일한 UUID를 사용할 수 있다. 서로 다른 UUID가 사용되면, 후방-호환성은 보장되지 않는다. 제어기 기기로의 접속을 바라는 호스트 기기 (1020)는 UUID를 식별할 수 있다. 대안의 실시예에서, UUId는 플랫폼 독립적인 통신 프로토콜로의 업그레이드를 반영하기 위해 변경될 수 있을 것이다.

애플리케이션들의 예

플랫폼 독립적인 통신 프로토콜을 가로질러 전달된 데이터는 센서 출력과 직접적으로 관련된 것일 수도 있고 관련되지 않을 수도 있을 것이다. 예를 들면, 타임스탬프 데이터가 검색될 수 있을 것이다. 다른 예에서, 상기 모바일 제어기 기기는 다른 플랫폼들을 위한 데이터 전달자로서 그리고 저장 기기로서 사용될 수 있을 것이다.

도 39 내지 도 44는 플랫폼 독립적인 통신 프로토콜이 적용될 수 있는 몇몇의 예들을 개략적으로 보여준다. 도 39는 내비게이션 시스템 (3920) 상에서의 매핑 애플리케이션을 제어하는, Java 가능 원격 제어기 기기 (3910)를 구현하기 위한 예시적인 시스템 (3900)을 도시한다. 예를 들면, 차량의 대시보드에 장착되거나 중앙 콘솔에 내장된 차량 내비게이션 시스템 (3920) 상에서의 매핑 애플리케이션을 제어하기 위해 원격 제어기 기기(3910)가 사용될 수 있다. 상기 원격 제어기 기기 (3910)는 손으로 가지고 있을 수 있으며 또는 차량의 스티어링 휠 등에 고정될 수 있다. 이 예에서 기저대역 접속은, 상기 내비게이션 시스템에 의해 블루투스가 지원된다면 블루투스일 수 있고 또는 USB와 같은 무선 접속일 수 있다. 제어기 기기 (3910)를 이용하여 주소들 및 관심 지점들이 원격 제어기 상의 특유 설계들을 이용하여 내비게이션 시스템 (3920)으로 입력될 수 있다. 본 명세서에 설명된 것과 같은 상기 플랫폼 독립적인 통신 프로토콜은, 상기 제어기 측이나 또는 상기 내비게이션 시스템 측의 어느 한 곳에서 커다란 메모리 공간을 취하지 않더라도, 그런 정보가 효율적으로 인코딩되어 상기 내비게이션 시스템 (3920)으로 전송되는 것을 가능하게 한다.

도 40은 GPS가 가능한 기기들 사이에서의 데이터 교환을 제공하기 위한 예시적인 시스템 (4000)을 도시한다. 예를 들면, GPS 가능한 차량 (4020), 원격 제어기 기기 (4010) 및 모바일 전화기 기기 (4030)에서 동작하는 매핑 애플리케이션 (4032)은 본 명세서에서 설명된 플랫폼 독립적인 통신 프로토콜을 경유하여 서로 통신할 수 있다. 상기 플랫폼 독립적인 통신 프로토콜은, 상기 GPS 가능한 차량 (4020)이 상기 모바일 전화기 (4030)와 통신하는 것을 허용하도록 블루투스 (4040)를 통해 구현될 수 있다. 상기 차량 (4020)으로부터 상기 모바일 전화기로 송신되는 특정 정보는 상기 차량 (4020)의 시동이 꺼지는 시점에서 그 차량의 GPS 위치를 서술하는 데이터를 포함할 수 있다. 예를 들면, 본 명세서에서 설명된 것과 같은 상기 플랫폼 독립적인 통신 프로토콜은 공동으로-계속 중인 "System and Method for Providing Local Maps Using Wireless Handheld Devices" 제목의 특허출원 (U.S. Patent Application No. 11/620,604)에서의 통신들을 가능하게 하기 위해 구현될 수 있다. 이 공동으로-계속 중인 출원 (U.S. Patent Application No. 11/620,604)의 내용은 본원에 참조로서 편입된다.

도 41은 모바일 전화기 (4110), 차량 (4120) 및 PC (4130) 사이에서의 데이터 통신을 가능하게 하기 위한 예시적인 시스템 (4100)을 도시한다. 예를 들면, 블루투스가 장착된 차량 (4120)은 상기 플랫폼 독립적인 통신 프로토콜을 경유하여 모바일 전화기 (4110)로 데이터 (예를 들면, 차량의 기계적인 상태 정보)를 전달할 수 있다. 그러면 상기 모바일 전화기 (4110)는 그 데이터를 본 명세서에서 설명된 상기 플랫폼 독립적인 통신 프로토콜을 이용하여 블루투스가 가능한 PC (4130)로 업로드하기 위해 사용될 수 있다. 차량의 운행 거리, 사용 기간 및 손상 등과 같은 정보가 PC 상에서 추적되어, 적절한 예방 정비 및 차에 고장이 나기 전의 수리를 가능하게 할 수 있다.

유사한 예에서 (도시되지 않음), 상기 제어기는 휴대용 또는 차량에 장착된 내비게이션 기기로부터 GPS 정보를 인출하여 그 정보를 검토의 용도로 나중에 PC로 업로드하기 위해 저장한다.

도 42는 복수의 헬스 및 피트니스 기기들 사이에서의 데이터 통신을 가능하게 하기 위한 예시적인 시스템 (4200)을 도시한다. 예를 들면, 모바일 전화기 (4210)는 본 명세서에서 설명된 상기 플랫폼 독립적인 통신 프로토콜을 이용하여 보도계 (4220)로 링크될 수 있다. 상기 보도계 (4220)로부터의 데이터는 시리얼화될 수 있다. 개인 운동으로서, 상기 보도계는 상기 시리얼화된 보도계 데이터를 모바일 전화기 (4210)로 스트리밍할 수 있고, 그러면 상기 모바일 전화기는 그 보도계를 장착한 개인의 운동 상태를 추적할 수 있다. 상기 모바일 전화기 (4210) 상에서 수신한 데이터는 본 명세서에서 설명된 동일한 플랫폼 독립적인 통신 프로토콜을 이용하여 PC로 전송될 수 있다.

도 43은 Java-가능한 조이스틱 제어기 (4310)와 모바일 전화기 (4320) 사이에서의 데이터 통신을 가능하게 하는 예시적인 시스템 (4300)을 도시한다. 예를 들면, 아날로그 조이스틱을 구비한 원격 제어기 (4310)는 본 명세서에서 설명된 상기 플랫폼 독립적인 통신 프로토콜을 통해 모바일 전화기 (4320)와 통신할 수 있다. 상기 모바일 전화기 (4320)는, 예를 들면, J2ME 플랫폼 상에서 게임들을 구동시킬 수 있을 것이다. 그 게임들은 상기 플랫폼 독립적인 통신 프로토콜을 지원하며, 그러므로 그 게임들은 블루투스를 통해 제어기 기기 (4310)로부터 상기 전화기 (4320)로 전달되는 아날로그 조이스틱 신호들, 다른 스위치 신호들 또는 어떤 다른 데이터를 인코딩하는 소프트웨어 라이브러리를 이용할 수 있다. 예를 들면, 본 명세서에서 설명된 것과 같은 상기 플랫폼 독립적인 통신 프로토콜은 공동으로-계속중인 (co-pending) "Human Input Acceleration System" 제목의 특허출원 (U.S. Patent Application No. 11/519,455)에서의 통신들을 가능하게 하기 위해 구현될 수 있다.

도 44는 다중-플레이어 모바일 게이밍 시나리오에서의 통신을 가능하게 하기 위한 예시적인 시스템 (4400)을 도시한다. 예를 들면, 두 플레이어들이 같이 하나의 모바일 전화기 (4430) 상에서 같은 게임을 플레이할 수 있다. 각 플레이어는 자신의 제어기 (4410, 4420)를 가진다. 상기 모바일 전화기 (4430)는 J2ME 플랫폼 상에서의 게이밍을 지원하며, TV 또는 다른 디스플레이 기기들 (4440)로의 비디오 출력을 지원한다. 상기 모바일 전화기 (4430)는 본 명세서에서 설명된 것과 같은 플랫폼 독립적인 통신 프로토콜을 경유하여 제어기들 (4410, 4420) 둘 다와 동시에 통신한다. 두 명의 게이머들은 상기 모바일 전화기 (4430) 상에서 동작하는 게임을 플레이하면서도 게임 콘솔-유형의 경험을 즐길 수 있다.

다른 예에서 (도시되지 않음), 상기 제어기 기기는 호스트 기기 (예를 들면, 모바일 전화기)로부터 게임 상태 정보를 인출할 수 있을 것이며, 그리고 그 정보를 백업을 위해 PC로 전달하거나 또는 PC 상에서 또한 지원되는 게임들 용의 플랫폼 독립적인 게임 플레이를 위해 PC로 전달될 수 있다. 반대로, 상기 제어기 기기는 PC로부터 게임 상태 정보를 인출하여 그 정보는 모바일 전화기로 전달할 수도 있을 것이다. 다른 플랫폼 역시 지원될 수 있을 것이다. 그러므로 상기 모바일 제어기 기기는 게이밍 경험이 한 플랫폼에서 다른 플랫폼으로 전달될 수 있는 차량이 될 수 있을 것이다. 예를 들면, 본 명세서에 설명된 것과 같은 상기 플랫폼 독립적인 통신 프로토콜은 공동-계속중인 "Universal Controller for Toy and Games" 제목의 미국 특허출원 (U.S. Patent Application No. 11/519,455)에서의 통신을 가능하게 하기 위해 구현될 수 있다.

주제의 실시예들 그리고 본 명세서에 설명된 기능적인 동작들은 본 명세서에서 개시된 구조들과 그 구조들의 동등물 및 그것들의 하나 또는 그 이상의 것들을 결합한 것을 포함하여, 디지털 전자 회로로, 또는 컴퓨터 소프트웨어, 펌웨어 또는 하드웨어로 구현될 수 있다. 본 명세서에서 설명된 주제의 실시예들은 하나 또는 그 이상이 컴퓨터 프로그램 제품들, 즉, 데이터 프로세싱 장치에 의해 수행되기 위해 또는 그 장치의 동작을 제어하기 위해 유형의 프로그램 캐리어 상에서 인코딩된 컴퓨터 프로그램 명령어들의 하나 또는 그 이상의 모듈들로서 구현될 수 있다. 상기 유형의 프로그램 캐리어는 전파되는 신호 또는 컴퓨터로 읽을 수 있는 매체일 수 있다. 상기 전파된 신호는 컴퓨터에 의해 실행하려고 적합한 수신기 장치로 전송할 용도로 정보를 인코딩하기 위해 생성한, 인공적으로 생성되는 신호, 예를 들면, 기계로 생성된 전기적인, 광학적인 또는 전자기 신호이다. 상기 컴퓨터로 읽을 수 있는 매체는 기계로 읽을 수 있는 저장 기기, 기계로 읽을 수 있는 저장 기판, 메모리 기기, 기계로 읽을 수 있는 전파된 신호에 영향을 끼치는 물질의 구성 또는 그것들 하나 또는 그 이상의 조합일 수 있다.

"데이터 프로세싱 장치"의 용어는 프로그램 가능한 프로세서, 컴퓨터, 다중의 프로세서 또는 컴퓨터들을 예로서 포함하는 데이터를 처리하기 위한 장치, 기기 및 기계를 모두 망라한다. 그런 장치는, 하드웨어에 추가로, 문제의 컴퓨터 프로그램을 위한 실행 환경을 생성하는 코드, 예를 들면, 프로세서 펌웨어, 프로토콜 스택, 데이터베이스 관리 시스템, 운영 시스템 또는 그것들의 조합을 조직하는 코드를 포함할 수 있다.

(프로그램, 소프트웨어, 소프트웨어 애플리케이션, 스크립트 또는 코드로서도 또한 알려진) 컴퓨터 프로그램은 컴파일된 언어 또는 인터프리트된 언어 또는 서술 언어 또는 절차적인 언어를 포함하는 프로그래밍 언어의 형식으로 쓰여질 수 있으며, 그 컴퓨터 프로그램은 단독의 프로그램으로서 또는 모듈, 컴포넌트, 서브루틴 또는 컴퓨터 환경에서 사용하기에 적합한 다른 유닛으로서의 임의 형식으로 배치될 수 있다. 컴퓨터 프로그램은 파일 시스템에서의 파일에 반드시 대응할 필요는 없다. 프로그램은 다른 프로그램들이나 데이터(예를 들면, 마크업 언어 문서에 저장된 하나 또는 그 이상의 스크립트들)를 보유하는 파일의 일부에, 문제의 프로그램에 전용된 단일의 파일에, 또는 다중의 협응 파일들 (예를 들면, 하나 또는 그 이상의 모듈들, 서브 프로그램들, 또는 코드의 일부분들)에 저장될 수 있다. 컴퓨터 프로그램은 하나의 컴퓨터 상에서 실행되기 위해 배치될 수 있으며 또는 하나의 사이트에 위치한 또는 다중의 사이트들에 걸쳐서 분포되어 통신 네트워크에 의해 서로 접속되는 다중의 컴퓨터들 상에서 실행되기 위해 배치될 수 있다.

본 명세서에서 설명된 프로세스들과 논리 흐름들은, 입력 데이터 상에서의 동작 및 출력 생성에 의한 기능들을 수행하기 위해 하나 또는 그 이상의 컴퓨터 프로그램들을 실행하는 하나 또는 그 이상의 프로그램 가능한 프로세서들에 의해 수행될 수 있다. 또한 상기의 프로세스들과 논리 흐름들은 특수 목적의 논리 회로, 예를 들면, FPGA (field programmable gate array) 또는 ASIC (application specific integrated circuit)에 의해 그리고 그런 논리 회로로서 또한 구현될 수 있는 장치에 의해 수행될 수 있다.

컴퓨터 프로그램을 실행시키기에 적합한 프로세서들은, 예컨대, 범용의 마이크로프로세서와 특수 용도의 마이크로프로세서 둘 다 그리고 디지털 컴퓨터의 임의 유형의 하나 또는 그 이상의 프로세서들을 포함한다. 일반적으로, 프로세서는 읽기 전용 메모리 또는 랜덤 액세스 메모리 또는 그 두 가지 모두로부터 명령어들과 데이터를 수신할 것이다. 컴퓨터의 본질적인 요소들은 명령어들을 수행하기 위한 프로세서와 명령어들과 데이터를 저장하기 위한 하나 또는 그 이상의 메모리 기기들이다. 일반적으로, 컴퓨터는 데이터를 저장하기 위한 하나 또는 그 이상의 대용량 저장 기기들, 예를 들면, 자기 디스크, 자기 광학식 디스크 또는 광학 디스크를 또한 포함하거나 또는 데이터를 수신하거나 데이터를 전달하거나 또는 두 가지 다를 하기 위해 그 저장 기기들에 동작 가능하게 연결될 것이다. 그러나, 컴퓨터는 그런 기기들을 구비할 필요는 없다. 더 나아가, 컴퓨터는 다른 기기 내에 내장될 수 있다.

컴퓨터 프로그램 명령어들과 데이터를 저장하기에 적합한 컴퓨터로 읽을 수 있는 매체는, 예컨대, 반도체 메모리 기기들, 예를 들면, EPROM, EEPROM 및 플래시 메모리 기기들; 자기 디스크들, 예를 들면, 내부 하드디스크들이나 탈부착 가능한 디스크들; 자기 광확식 디스크들; 그리고 CD-ROM과 DVD-ROM 디스크들을 포함하는, 비휘발성 메모리, 매체 및 메모리 기기들의 모든 형상을 포함한다. 프로세서와 메모리는 특수 용도의 로직 회로에 부수될 수 있으며 또는 그 로직 회로에 병합될 수 있다.

사용자와의 인터액션 (interaction)을 제공하기 위해, 본 명세서에서 설명된 주제의 실시예들은 사용자에게 정보를 디스플레이하기 위한 디스플레이 기기, 예를 들면, CRT (cathode ray tube) 또는 LCD (liquid crystal display) 모니터 그리고 사용자가 컴퓨터로 입력을 할 수 있게 하는 키보드와 포인팅 기기, 예를 들면, 마우스 또는 트랙볼을 구비한 컴퓨터에서 구현될 수 있다. 사용자와의 인터액션을 제공하기 위해 다른 유형의 기기들 역시 사용될 수 있다. 예를 들면, 상기 사용자로부터의 입력은 음향, 음성 또는 촉각적인 입력을 포함한 임의 유형으로 수신될 수 있다.

본 명세서에서 설명된 주제의 실시예들은, 예를 들어 데이터 서버로서 백 엔드 컴포넌트 (back end component)를 포함하는 컴퓨터 시스템이나 미들웨어 컴포넌트, 예를 들면 애플리케이션 서버를 포함하는 컴퓨터 시스템이나 또는 프론트 엔드 (front end) 컴포넌트, 예를 들면, 사용자가 본 명세서에서 설명된 주제를 구현한 것과 상호작용 (interact)할 수 있는 그래픽 사용자 인터페이스나 웹 브라우저를 구비한 클라이언트 컴퓨터를 포함하는 컴퓨터 시스템에서 또는 그런 백 엔드, 미들웨어 또는 프론트 엔드 컴포넌트들 중의 하나 또는 그 이상이 조합을 포함하는 컴퓨터 시스템에서 구현될 수 있다. 상기 시스템의 컴포넌트들은, 디지털 데이터 통신의 임의 형상의 또는 임의의 매체, 예를 들면, 통신 네트워크에 의해 상호 접속할 수 있다. 통신 네트워크들의 예들은 로컬 영역 네트워크 (local area network ("LAN") and 광역 네트워크 (wide area network (WAN)), 예를 들면, 인터넷을 포함한다.

상기 컴퓨팅 시스템은 클라이언트들과 서버들을 포함할 수 있다. 클라이언트와 서버는 보통은 서로 원거리에 위치하고 통신 네트워크를 통해서 상호작용하는 것이 전형적이다. 클라이언트와 서버와 관계는 각각의 컴퓨터들에서 동작하며 서로에게 클라언트-서버 관계를 구비한 컴퓨터 프로그램들에 의해 일어난다.

이런 규격이 많은 특성들을 포함하지만, 이들은 본 발명의 범위 또는 청구될 수 있는 범위에 대한 제한으로서 해석되어서는 안되며, 오히려 특정한 발명의 특정한 실시예들에 특정될 수 있는 특성들에 대한 설명으로서 해석되어야 한다. 개별 실시예들에서의 맥락으로 본 명세서에서 설명된 것과 같은 어떤 특징들은 단일의 실시예에서의 조합으로 또한 구현될 수 있다. 반대로, 단일의 실시예의 맥락으로 설명되었던 다양한 특징들이 다중의 실시예들에서 개별적으로 또는 어떤 적절한 서브-조합으로 구현될 수도 있다. 더 나아가, 특징들이 특정 조합에서 그리고 그와 같이 초기에 청구된 것과 같이 동작하는 것으로 상기에서 설명되었지만, 청구된 조합으로부터의 하나 또는 그 이상의 특징들은 일부 경우에 상기 조합으로부터 실행될 수 있으며, 청구된 조합은 서브-조합이나 서브-조합의 변형에 관한 것일 수도 있다.

유사하게, 동작들이 특정 순서로 도면들에서 표현되었지만, 이는 그런 동작들이 도시된 특정한 순서대로 또는 순차적인 순서로 수행되어야만 하며, 또는 원하는 결과들을 얻기 위해 도시된 모든 동작들이 수행되어야만 한다는 것을 필요로 하는 것으로 해석되어서는 안된다.

몇몇의 구현과 예들만이 설명되었으며, 본원에서 설명되고 도시된 것을 기반으로 하여 다른 구현들, 개선점들 및 변형들이 만들어질 수 있다.

더 나아가, 데이터 입력 제공, 기기 제어 또는 게임 제어이 방법들이 다른 순서로 수행될 수 있을 것이며 그래도 여전히 원하는 결과를 획득할 수 있을 것이다. 따라서, 다른 구현들은 이어지는 청구항들의 범위 내에 있는 것이다.

Claims (22)

1. 통신 프로토콜을 통해서 모바일 제어기 기기와 호스트 기기 사이에서의 플랫폼 독립적인 양방향 통신을 제공하는 단계를 포함하는 방법으로서,
   상기 제공하는 단계는,
   상기 모바일 제어기 기기로부터 상기 호스트 기기로의 바이트들의 어레이를 배송하는 단계로서, 상기 바이트들의 어레이는 상기 모바일 제어기 기기의 하나 이상의 데이터 패킷들을 서술하는 (describe), 배송 단계;
   상기 호스트 기기가 원래의 디바이스 드라이버를 포함한다는 것이 탐지되면, 그 원래의 디바이스 드라이버를 이용하여 상기 배송된 바이트들의 어레이를 분석하는 (parse) 단계; 및
   상기 호스트 기기가 원래의 디바이스 드라이버를 포함하지 않는다는 것이 탐지되면, 상기 배송된 바이트들의 어레이를 분석하기 위한 디바이스 드라이버를 제공하는 단계;를 포함하는 방법.
2. 제1항에 있어서,
   상기 디바이스 드라이버를 제공하는 단계는 상기 배송된 바이트들의 어레이를 기반으로 하는 커스터마이즈된 휴먼 인터페이스 디바이스 드라이버를 제공하는 것을 포함하는, 방법.
3. 제1항에 있어서,
   상기 플랫폼 독립적인 양방향 통신을 제공하는 단계는 자바 (Java) 플랫폼과 호환되는 양방향 통신을 제공하는 것을 포함하는, 방법.
4. 제1항에 있어서,
   상기 바이트들의 어레이를 배송하는 단계는, 상기 바이트들의 어레이로부터의 고정된 개수의 바이트들을 이용하여, 원래의 휴먼 인터페이스 기기 서술자에 의해 지원되지 않는 하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자 (device specific descriptor)들을 생성하는 것을 포함하는, 방법.
5. 제4항에 있어서,
   하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자들을 생성하는 것은, 조이스틱, 선형 전위차계, 트랙볼, 인코더, 힘 감지 저항 (force sensitive resistor), 장력 측정기, 일련의 디지털 스위치들, 가속도계, 자이로 (gyro), 관성 센서 및 전자기 센서의 그룹에서 선택된 적어도 하나를 지원하는 하나 이상의 기기 특정 서술자들을 생성하는 것을 포함하는, 방법.
6. 제1항에 있어서,
   상기 플랫폼 독립적인 양방향 통신을 제공하는 단계는 자바 플랫폼 드라이버에 의해 액세스 가능한 적어도 2개의 통신 채널들을 제공하는 단계를 포함하는, 방법.
7. 제1항에 있어서,
   바이트들의 어레이를 배송하는 단계는 상기 모바일 제어기 기기용으로 커스터마이즈된 가변의 바이트들의 시퀀스를 배송하는 단계를 포함하는, 방법.
8. 제7항에 있어서,
   가변의 바이트들의 시퀀스를 배송하는 단계는,
   상기 바이트들의 시퀀스 내의 각 바이트를 상기 모바일 제어기 기기 상의 하나 이상의 입력 요소들로 매핑하는 단계; 그리고
   각 바이트에 할당된 값을 상기 입력 요소의 상태를 기반으로 하여 변경하는 단계를 포함하는, 방법.
9. 컴퓨터로 읽을 수 있는 매체 상에 구현된 컴퓨터 프로그램 제품으로서, 데이터 프로세싱 장치로 하여금,
   통신 프로토콜을 통해서 모바일 제어기 기기와 호스트 기기 사이에서의 플랫폼 독립적인 양방향 통신을 제공하는 단계를 포함하는 동작을 수행하도록 동작 가능하며,
   상기 제공하는 단계는,
   상기 모바일 제어기 기기로부터 상기 호스트 기기로의 바이트들의 어레이를 배송하는 단계로서, 상기 바이트들의 어레이는 상기 모바일 제어기 기기의 하나 이상의 데이터 패킷들을 서술하는 (describe), 배송 단계;
   상기 호스트 기기가 원래의 디바이스 드라이버를 포함한다는 것이 탐지되면, 그 원래의 디바이스 드라이버를 이용하여 상기 배송된 바이트들의 어레이를 분석하는 (parse) 단계; 및
   상기 호스트 기기가 원래의 디바이스 드라이버를 포함하지 않는다는 것이 탐지되면, 상기 배송된 바이트들의 어레이를 분석하기 위한 디바이스 드라이버를 제공하는 단계;를 포함하는, 컴퓨터 프로그램 제품.
10. 제9항에 있어서,
    상기 데이터 프로세싱 장치로 하여금,
    상기 배송된 바이트들의 어레이를 기반으로 하는 커스터마이즈된 휴먼 인터페이스 디바이스 드라이버를 제공하는 것을 더 포함하는 동작을 수행하도록 동작 가능한, 컴퓨터 프로그램 제품.
11. 제9항에 있어서,
    상기 데이터 프로세싱 장치로 하여금,
    자바 (Java) 플랫폼과 호환되는 양방향 통신을 적어도 제공하여 플랫폼 독립적인 양방향 통신을 제공하는 것을 더 포함하는 동작을 수행하도록 동작 가능한, 컴퓨터 프로그램 제품.
12. 제9항에 있어서,
    상기 데이터 프로세싱 장치로 하여금,
    원래의 휴먼 인터페이스 기기 서술자에 의해 지원되지 않는 하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자들을 생성하기 위해 상기 바이트들의 어레이로부터의 고정된 개수의 바이트들을 적어도 이용함으로써 상기 바이트들의 어레이를 배송하는 것을 더 포함하는 동작을 수행하도록 동작 가능한, 컴퓨터 프로그램 제품.
13. 제12항에 있어서,
    상기 데이터 프로세싱 장치로 하여금,
    조이스틱, 선형 전위차계, 트랙볼, 인코더, 힘 감지 저항 (force sensitive resistor), 장력 측정기, 일련의 디지털 스위치들, 가속도계, 자이로 (gyro), 관성 센서 및 전자기 센서의 그룹에서 선택된 적어도 하나를 지원하는 하나 이상의 기기 특정 서술자들을 적어도 생성함으로써, 하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자들을 생성하는 것을 더 포함하는 동작을 수행하도록 동작 가능한, 컴퓨터 프로그램 제품.
14. 제9항에 있어서,
    상기 데이터 프로세싱 장치로 하여금,
    자바 플랫폼 드라이버에 의해 액세스 가능한 적어도 2개의 통신 채널들을 구비한 플랫폼 독립적인 양방향 통신을 제공하는 것을 더 포함하는 동작을 수행하도록 동작 가능한, 컴퓨터 프로그램 제품.
15. 제9항에 있어서,
    상기 데이터 프로세싱 장치로 하여금,
    상기 모바일 제어기 기기용으로 커스터마이즈된 가변의 바이트들의 시퀀스를 구비하는 바이트들의 어레이를 배송하는 것을 더 포함하는 동작을 수행하도록 또한 동작 가능한, 컴퓨터 프로그램 제품.
16. 제15항에 있어서,
    상기 데이터 프로세싱 장치로 하여금,
    상기 바이트들의 시퀀스 내의 각 바이트를 상기 모바일 제어기 기기 상의 하나 이상의 입력 요소들로 매핑하는 것; 그리고
    각 바이트에 할당된 값을 상기 입력 요소의 상태를 기반으로 하여 변경하는 것을 포함하는, 가변의 바이트들의 시퀀스를 배송하는 것을 더 포함하는 동작을 수행하도록 또한 동작 가능한, 컴퓨터 프로그램 제품.
17. 모바일 제어기 기기로서,
    통신 메커니즘을 포함하며,
    상기 통신 메커니즘은,
    상기 모바일 제어기 기기를 호스트 기기에 연결시키도록 구성된 기저대역 프로토콜;
    상기 기저대역 프로토콜을 통해, 각각이 바이트들의 시퀀스를 포함하는 하나 이상의 메시지들을 상기 호스트 기기로 송신하도록 구성된 양방향 시리얼 통신 프로토콜; 및
    제어기 펌웨어;를 포함하는 통신 스택을 동작시키도록 구성되며,
    상기 제어기 펌웨어는,
    상기 모바일 제어기 기기에서 이용 가능한 다양한 입력 메카니즘들이 제공한 입력 신호들을 모니터하도록 구성되고, 그리고
    상기 하나 이상의 메시지들을 생성하도록 구성되며,
    상기 양방향 시리얼 통신 프로토콜은 상기 기저대역 프로토콜을 통한 상기 모바일 제어기 기기와 호스트 기기 사이의 플랫폼 독립적인 양방향 통신을 가능하게 하는, 모바일 제어기 기기.
18. 제17항에 있어서,
    상기 양방향 시리얼 통신 프로토콜은 자바 플랫폼과 호환되는 양방향 통신을 포함하는 플랫폼 독립적인 양방향 통신들을 가능하게 하는, 모바일 제어기 기기.
19. 제17항에 있어서,
    상기 제어기 펌웨어는 원래의 휴먼 인터페이스 기기 서술자에 의해 지원되지 않는 하나 이상의 센서들을 지원하는 하나 이상의 기기 특정 서술자들을 생성하기 위해 상기 바이트들의 시퀀스로부터 고정된 개수의 바이트들을 취하도록 또한 구성된, 시스템.
20. 제19항에 있어서,
    상기 제어기 펌웨어는
    조이스틱, 선형 전위차계, 트랙볼, 인코더, 힘 감지 저항 (force sensitive resistor), 장력 측정기, 일련의 디지털 스위치들, 가속도계, 자이로 (gyro), 관성 센서 및 전자기 센서의 그룹에서 선택된 적어도 하나를 지원하는 하나 이상의 기기 특정 서술자들을 생성하도록 또한 구성된, 시스템.
21. 제17항에 있어서,
    상기 제어기 펌웨어는 하나 이상의 메시지들을 생성하도록 또한 구성되며,
    생성된 메시지 각각은 상기 모바일 제어기 기기 용으로 커스터마이즈된 가변의 바이트들의 시퀀스를 포함하는, 시스템
22. 제17항에 있어서,
    상기 제어기 펌웨어는,
    상기 바이트들의 시퀀스 내의 각 바이트를 상기 모바일 제어기 기기에서 이용 가능한 다양한 입력 메커니즘들의 하나 이상의 입력 요소들로 매핑하며 그리고 각 바이트에 할당된 값을 상기 매핑된 하나 이상의 입력 요소들의 상태를 기반으로 하여 변경하도록 또한 구성된, 시스템.
    

Images