KR101150071B1

KR101150071B1 - 미지원 장치를 위한 플러그 ＆ 플레이 기능

Info

Publication number: KR101150071B1
Application number: KR1020050040161A
Authority: KR
Inventors: 크라이그 젠센; 할란 후스만; 자니네 에이. 하리슨; 서게이 바이코브; 실베스터 엠. 라 블랜크; 티모시 이. 벨빈
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-05-14
Filing date: 2005-05-13
Publication date: 2012-06-01
Also published as: JP2006012128A; US20050257226A1; EP1603038A2; EP1603038A3; KR20060047889A; JP4818640B2

Abstract

본 발명은 오퍼레이팅 시스템에 의해 지원되지 않는 장치에 대해 플러그 & 플레이(PnP) 기능을 제공한다. 미지원 장치의 설치에 응답하여, 오퍼레이팅 시스템은 사용자 모드 코드에 상주하는 장치 관리자 애플리케이션에 이벤트를 전송한다. 이벤트의 수신시, 장치 관리자 애플리케이션은 지원 구성 엔트리 및 소프트웨어를 자동 설치한다. 장치 설치 후, 장치는 어떠한 프로그래밍 변경을 필요로 하지 않고 애플리케이션으로부터 액세스 가능하다. 이벤트는 공통 제어 라이브러리(CCL)를 통해 애플리케이션에 노출된다. 라이브러리는 장치에 액세스하기 위한 일반 인터페이스를 제공한다. 등록된 애플리케이션은 CCL을 사용하여 장치와 관련된 이벤트를 수신할 수 있다.

오퍼레이팅 시스템, 플러그 & 플레이, 미지원 장치, 이벤트, 공통 제어 인터페이스

Description

미지원 장치를 위한 플러그 ＆ 플레이 기능{PNP FUNCTIONALITY FOR UNSUPPORTED DEVICES}

도 1은 오퍼레이팅 환경을 나타내는 도면.

도 2는 PnP 소매 시스템의 일반 시스템 도면.

도 3은 PnP 시스템의 고레벨 아키텍처 도면.

도 4는 PnP 시스템과 CCL 사이의 상호작용을 나타내는 도면.

도 5는 레거시 장치들과 PnP 소매 시스템을 통합하기 위한 아키텍처 도면.

도 6은 예시적인 헬퍼 클래스 및 SO 저장소를 나타내는 도면.

도 7은 시스템에 부착된 POS 장치들에 대한 정보를 제공하기 위한 예시적인 디스플레이를 나타내는 도면.

도 8은 본 발명의 양태들에 따라 설치된 POS 장치들의 예시적인 스크린샷을 나타내는 도면.

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

100: 컴퓨팅 장치

102: 프로세싱 유닛

104: 시스템 메모리

105: 오퍼레이팅 시스템

본 발명은 미지원 장치를 위한 플러그 & 플레이 기능에 관한 것이다.

지난 10년간, 소매상이 장치를 소비하는 방식에는 거의 변화가 없었다. 오늘날 소매 장치들을 설치하는 일은 플러그 & 플레이의 도래 전에 PC 상에 장치를 설치하는 것과 유사하다. 종종, 장치를 설치하려고 할 때, 네트워크 카드, 모뎀, 마우스 및 다른 네트워크 카드 사이에는 장치 포트 충돌이 발생한다. 너무나 빈번하게 소매상들은 "박스를 열고, 장치를 찾아, 점퍼 설정을 변경"하거나, 사용자에게 쉽지 않은 소정의 동작을 수행해야 한다. 이들 장치의 설치는 어렵고 시간이 많이 걸릴 수 있다.

요컨대, 본 발명은 오퍼레이팅 시스템에 의해 지원되지 않는 장치에 대해 플러그 & 플레이(PnP) 기능을 제공한다.

본 발명의 일 양태에 따르면, 미지원 장치가 설치될 때, 장치는 오퍼레이팅 시스템에 의해 검출된다. 설치에 응답하여, 오퍼레이팅 시스템은 사용자 모드에 상주하는 장치 관리자 애플리케이션에 이벤트를 전송한다. 설치 이벤트의 수신시, 장치 관리자 애플리케이션은 추가된 장치를 결정하고, 지원 구성 엔트리 및 소프트웨어를 자동 설치한다. 예를 들어, 장치 관리자 애플리케이션은 레지스트리를 자동 갱신하고, 장치에 대한 지원 바이너리를 설치할 수 있다. 장치가 설치된 후, 소매 장치는 어떠한 프로그래밍 변경 없이도 애플리케이션으로부터 액세스 가능하다.

본 발명의 다른 양태에 따르면, PnP 이벤트는 공통 제어 라이브러리(CCL)를 통해 소매 애플리케이션에 노출된다. 라이브러리는 장치에 액세스하기 위한 일반 인터페이스를 제공한다. 등록된 애플리케이션은 CCL을 사용하여 장치와 관련된 이벤트를 수신할 수 있다.

본 발명의 또 다른 양태에 따르면, 소매 장치를 제어하는 데 사용되는 CCL은 커널 모드와 반대인 커널의 사용자 모드로 동작한다.

본 발명은 오퍼레이팅 시스템에 의해 지원되지 않는 소매 장치들은 물론 다른 장치들에게 "플러그 & 플레이"와 같은 경험을 허용한다. 미지원 장치가 설치될 때, 오퍼레이팅 시스템은 공통 제어 라이브러리(CCL)를 통해 장치에 대한 애플리케이션 액세스를 제공하는 PnP 이벤트와 같은 이벤트를 사용자 모드에서 동작하는 장치 관리자 애플리케이션으로 전송한다. CCL 라이브러리는 미지원 장치들에 대한 애플리케이션 및 서비스 객체들의 기입을 크게 단순화하며, 제품의 호환성 및 품질을 향상시키고, 비용을 줄인다.

본 발명의 일 실시예에 따르면, 통합 서비스 시점(UPOS) V1.8 사양에 정의되어 있는 소매 장치들에 대한 분류가 행해진다. UPOS V1.8 사양은 국내 소매상 연합의 웹사이트(www.nrf-art.org)로부터 얻을 수 있다. UPOS에 의해 지원되는 소매 장치들의 일부는 범프 바, 현금 교환기, 현금 인출기, 신용 인증 단말기, 동전 교 환기, 회계 프린터(fiscal printer), 하드 토탈(hard totals), 키록(keylock), 바코드 스캐너, 톤 표시기, 모션 검출기, 라인 디스플레이, 자기 잉크 문자 인식 판독기, 자기 띠 판독기, PIN 패드, 포인트 카드, POS 키보드, POS 프린터, 원격 주문 디스플레이, 스케일, 서명 캡쳐 및 체크 이미지 스캐너를 포함한다. 본 발명은 소매 장치들의 지원으로 제한되는 것은 아니다. 오퍼레이팅 시스템의 지원되는 PnP 장치들의 리스트에 포함되지 않은 임의의 장치도 지원될 수 있다.

본 명세서 전반에서, 명백하게 달리 지시되지 않는 한 다음 용어들은 아래와 같이 정의된다. "OPOS"라는 용어는 판매 또는 서비스 시점에 대한 OLE를 나타낸다. "UPOS"라는 용어는 판매 또는 서비스 시점에 대한 통합 사양을 나타낸다. "POS 클래스 주변 장치" 또는 "OPOS 장치"라는 용어는 UPOS V1.8 사양에 정의되어 있는 24개의 다른 장치 클래스들 중 하나에 속하는 장치들의 집합을 나타낸다. "장치 클래스"라는 용어는 특성들, 메소드들 및 이벤트들의 일관된 세트를 공유하는 POS 장치들의 카테고리이다. 그 예는 현금 인출기 및 POS 프린터이다. 몇몇 장치들은 둘 이상의 장치 클래스를 지원한다. 예를 들어, 몇몇 POS 프린터는 현금 인출기를 포함한다. "제어 객체(CO)"라는 용어는 특성들, 메소드들 및 이벤트들의 세트를 특정 장치 클래스에 대한 애플리케이션에 노출시키는 객체를 말한다. "서비스 객체(SO)"라는 용어는 CO에 의해 호출되어 UPOS에 규정된 특정 장치에 대한 기능을 구현하는 객체를 말한다. SO는 원시 코드를 포함하는 CLR에 의해 지원되는 임의의 언어로 구현될 수 있다. "미지원 장치"라는 용어는 디폴트로 기반 오퍼레이팅 시스템에 의해 지원되지 않는 임의의 장치를 나타낸다.

예시적인 오퍼레이팅 환경

아래 도시된 도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨팅 장치(100)와 같은 컴퓨팅 장치를 포함한다. 매우 기본적인 구성에 있어서, 컴퓨팅 장치(100)는 일반적으로 적어도 하나의 프로세싱 유닛(102) 및 시스템 메모리(104)를 포함한다. 컴퓨팅 장치의 정확한 구성 및 타입에 따라, 시스템 메모리(104)는 휘발성(예를 들어, RAM), 불휘발성(예를 들어, ROM, 플래시 메모리 등) 또는 이 둘의 소정의 조합일 수 있다. 시스템 메모리(104)는 일반적으로 오퍼레이팅 시스템(105), 하나 이상의 프로그램 모듈(106)을 포함하며, 프로그램 데이타(107)를 포함할 수 있다. PnP 소매 애플리케이션(120)은 소매 장치들을 위한 PnP 기능을 제공한다. 이러한 기본 구성은 점선(108) 내의 컴포넌트들로서 도 1에 도시되어 있다.

컴퓨팅 장치(100)는 추가적인 특징 또는 기능을 가질 수 있다. 예를 들어, 컴퓨팅 장치(100)는 예를 들어 자기 디스크, 광 디스크 또는 테이프와 같은 추가적인 데이타 저장 장치(분리식 및/또는 비분리식)를 더 포함할 수 있다. 이러한 추가적인 저장 장치는 분리식 저장 장치(109) 및 비분리식 저장 장치(110)로서 도 1에 도시되어 있다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령들, 데이타 구조들, 프로그램 모듈들 또는 다른 데이타와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 불휘발성, 분리식 및 비분리식 매체를 포함할 수 있다. 시스템 메모리(104), 분리식 저장 장치(109) 및 비분리식 저장 장치(110)는 모두 컴퓨터 저장 매체의 예이다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, 디지탈 다기능 디스크(DVD) 또는 다른 광학 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 다른 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨팅 장치(100)에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만, 이에 한정되는 것은 아니다. 이러한 임의의 컴퓨터 저장 장치는 장치(100)의 일부일 수 있다. 컴퓨팅 장치(100)는 또한 소매 장치들, 키보드, 마우스, 펜, 음성 입력 장치, 터치 입력 장치 등과 같은 입력 장치(112)를 구비할 수 있다. 디스플레이, 스피커, 프린터 등과 같은 출력 장치도 포함될 수 있다.

컴퓨팅 장치(100)는 또한 예를 들어 네트워크를 통해 다른 컴퓨팅 장치(118)와 통신할 수 있도록 해주는 통신 접속(116)을 포함한다. 통신 접속(116)은 통신 매체의 일례이다. 통신 매체는 일반적으로 컴퓨터 판독 가능 명령들, 데이타 구조들, 프로그램 모듈들, 또는 반송파 또는 다른 전송 메카니즘과 같은 변조 데이타 신호 내의 다른 데이타에 의해 구현될 수 있다. "변조 데이타 신호"는 신호의 특성들 중 하나 이상이 신호 내의 정보를 인코딩하는 방식으로 설정 또는 변경된 신호를 의미한다. 예를 들어, 통신 매체는 유선 네트워크 또는 직접 유선 접속과 같은 무선 매체 및 음향, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함하지만, 이에 한정되지 않는다. 본 명세서에서 사용되는 컴퓨터 판독 가능 매체라는 용어는 저장 매체 및 통신 매체를 모두 포함한다.

소매 장치들에 대한 플러그 & 플레이(PnP)

도 2는 본 발명의 양태들에 따른 PnP 소매 시스템의 일반 시스템 도면이다.

소매 장치들에 대한 PnP 지원은 POS 장치들의 설치 및 유지 작업을 단순화한다. 예를 들어, 최종 사용자들은 간단하게 POS 장치를 언플러그하고, 그들의 기계가 새로운 장치와 상호작용하도록 다시 부팅하거나 재구성할 필요 없이 새로운 장치를 플러그 인할 수 있다.

일반적으로, 사용자가 소매 장치(210)와 같은 미지원 장치를 설치할 때, 설치는 오퍼레이팅 시스템(220)에 의해 PnP 이벤트로서 검출된다. 그러나, 오퍼레이팅 시스템(220)은 소매 장치가 지원되지 않기 때문에 소매 장치를 설치하지 못하며, 장치를 설치하는 데 필요한 지식을 갖고 있지 않다. PnP 이벤트에서, PnP 관리자(225)는 이벤트를 장치 관리자 애플리케이션(230)으로 전송한다. 장치 관리자 애플리케이션(230)은 오퍼레이팅 시스템의 커널 모드가 아니라 사용자 모드에 상주하므로, 장치 관리자 애플리케이션(230)은 오퍼레이팅 시스템의 변경 없이도 수정될 수 있다. 초기화시, 장치 관리자 애플리케이션(230)은 오퍼레이팅 시스템으로부터 PnP 이벤트는 물론 다른 I/O 이벤트를 수신하도록 등록한다.

오퍼레이팅 시스템(220)에 의해 장치 관리자 애플리케이션(230)으로 전달되는 PnP 이벤트는 설치된 장치에 대한 장치 ID를 포함한다. 장치 관리자 애플리케이션(230)은 수신된 장치 ID로부터 장치를 식별하도록 시도한다. 장치가 장치 관리자 애플리케이션(230)에 의해 지원될 때, 장치 ID는 장치와 관련된 컴포넌트, 레지스트리 설정 및 유사 구성 옵션을 기술하는 설치 INF 파일에 대한 맵을 제공한 다. 일 실시예에 따르면, 장치와 관련된 구성 설정은 설정 파일(245)에 저장된다. 일 실시예에 따르면, 구성 파일은 장치가 어떻게 구성되어야 하는지에 대한 명령들을 포함하는 XML로서 저장된다. 이러한 상황에서 구성은 어떤 서비스 객체들(SO들)이 어느 장치들로 맵핑되는지의 식별을 의미한다. XML 파일에 포함된 정보는 장치 ID, 장치 클래스, IHV 명칭, SO 명칭, SO GUID, 장치의 특성(포트 속도, 멀티 헤드 장치 등), 장치 관리를 위해 UI를 론칭하기 위한 진입점 등과 같은 항목들을 포함한다. 장치 구성의 일부로서 최종 공지된 장치의 상태도 저장될 수 있다. 최종 공지된 상태는 장치의 디버깅에 유용할 수 있다.

본 발명의 일 실시예에 따르면, 템플릿 INF 파일이 지원되는 장치 클래스들 각각에 대해 소프트웨어 개발 키트(SDK)의 일부로서 제공된다. 템플릿 INF 파일의 목적은 공통 제어 라이브러리(CCL)를 지원하는 데 필요한 표준 레지스트리 및 구성 요소들을 식별하기 위한 것이다. 장치 관리자 애플리케이션(230)이 비관리 장치를 소매 장치로서 인식할 때, CCL(235)은 소매 장치(210)에 관련된 POS 애플리케이션(240)에 노출된다.

오퍼레이팅 시스템으로부터 이벤트를 수신하고 장치를 식별한 때, 장치 관리자 애플리케이션(230)은 레지스트리 및 관련 구성 엔트리들을 자동으로 갱신하며, 관련 INF 파일에 기초하는 사용자 중재 없이 장치에 대한 지원 바이너리를 설치한다. 이어서, POS 애플리케이션(240)은 특정 장치의 액세스에 대한 상세를 알 필요 없이 소매 장치(210)에 액세스하기 위해 CCL(235) 내의 기능들에 액세스할 수 있다.

CCL(235)은 지원되는 장치들과 관련된 특성들, 메소드들 및 이벤트들을 애플리케이션에 제공한다. 일 실시예에 따르면, CCL(235)은 .NET 클래스 라이브러리를 통해 UPOS 버전 1.8 사양에서 지정된 지원되는 장치 클래스들 각각에 대해 관리 코드로서 UPOS 특성들, 메소드들 및 이벤트들을 노출시킨다. 다른 장치들도 지원될 수 있다. 일반적으로, 오퍼레이팅 시스템의 PnP 시스템에 의해 지원되지 않는 임의의 장치는 장치 관리자 애플리케이션(230)을 통해 사용자 모드 코드에서 지원될 수 있다.

도 3은 본 발명의 양태들에 따른 PnP 시스템의 고레벨 아키텍처 도면이다. 도시된 바와 같이, 아키텍처 도면은 오퍼레이팅 시스템에 의해 커널 모드(아래 라인 335)에서 제공되는 기능과 사용자 모드(위 라인 335)에서 제공되는 기능을 포함한다.

I/O 시스템(350)은 오퍼레이팅 시스템의 커널 모드에서 동작하며, I/O 관리(365), 파워 관리(360) 및 PnP 관리(355)를 제공한다. I/O 관리자는 표준 I/O 관리를 제공한다. 파워 관리자(360)는 오퍼레이팅 시스템에 의해 관리되지 않는 파워 이벤트를 장치 관리자 애플리케이션(310)으로 전송한다. PnP 관리자(355)는 PnP 이벤트를 검출하고, 이벤트를 장치 관리자 애플리케이션에 제공한다. PnP 이벤트 관리자(320)는 어떤 이벤트가 장치 관리자(310)에 의해 지원되는 장치와 관련되어 있는지를 결정하고, POS 애플리케이션(305)에게 수신하고자 등록한 모든 이벤트를 제공한다.

연동층(315)은 레거시 COM 기반 소매 장치들이 CCL을 목표로 하는 애플리케 이션에 의해 사용될 수 있게 하기 위해 사용된다. 즉, 연동층(315)은 POS 애플리케이션(305)에게 동일한 메소드를 사용하여 PnP 장치들 및 레거시 장치들 양자에 액세스하는 통합 방식을 제공한다. 레거시 OPOS 장치들은 일반적으로 그들 자신에 대한 정보를 저장하고, 통신 경로를 식별하며, 구성 데이타를 유지한다. 예를 들어, 이러한 정보를 저장하기 위해 시스템 레지스트리가 사용될 수 있다. 일반적으로, 각각의 장치 제조자는 장치의 구성을 관리하기 위한 고객 애플리케이션을 제공한다.

도 4는 본 발명의 양태들에 따른 PnP 시스템과 CCL 사이의 상호작용을 나타낸다. 도시된 바와 같이, 시스템(400)은 POS 애플리케이션(405), 공용 API(CCL)(415), 열거자(420), PnP 시스템(430), SO 저장소(440), 구성 관리자(450), 및 .NET 프레임워크 및 Win 32 레벨을 포함한다.

POS 애플리케이션(405)은 CCL에 의해 지원되는 장치들과 상호작용하기 위해 API(410)와 상호작용한다. API(410)는 POS 애플리케이션(405)에게 수신하고자 등록한 PnP 이벤트들을 제공한다.

루트 클래스(415)는 공용 API(410) 내에 노출되며, 모든 동작들에 대한 진입점으로서 기능한다. API(410)는 POS 애플리케이션과 같은 애플리케이션에게 설치된 POS 장치들을 열거하고 이들에 대한 서비스 객체를 인스턴스화하며 POS 장치가 접속 또는 분리될 때 플러그 & 플레이 이벤트를 수신할 수 있는 능력을 제공한다.

일 실시예에 따르면, 루트 클래스(415)는 다음의 메소드들, 즉 기계 상에 설치된 모든 POS 장치의 집합을 리턴하는 GetDevices(), 기계 상에 설치된 주어진 타 입의 POS 장치들의 집합을 리턴하는 GetDevices( string type ), 주어진 타입의 디폴트 장치에 대한 IDevice 인터페이스를 리턴하는 GetDefaultDevice ( string type ), 및 요구된 서비스 객체의 인스턴스(IPOSControl 인터페이스)를 리턴하는 OpenControl( IDevice device )를 노출시킨다.

루트 클래스(415)는 또한 두 개의 플러그 & 플레이 이벤트, 즉 POS 장치가 기계에 접속/분리될 때 개시되는 OnDeviceAdded 및 OnDeviceRemoved를 POS 애플리케이션(510)에게 노출시킨다.

OPOS는 서비스 객체들이 개시하는 5개의 이벤트, 즉 OnDataEvent, OnDirectIOEvent, OnErrorEvent, OnOutputCompleteEvent 및 OnStatusUpdateEvent를 정의한다. 상이한 장치 클래스들이 이벤트들의 모두, 0개 또는 서브세트를 개시한다. 이벤트들은 IPOSControl 인터페이스에 추가된다. OPOS에 따른 표준이 이벤트들의 일부 또는 전부를 지원하지 않는 장치 클래스들에 대한 SO들은 단순히 이들을 개시하지 않을 것이다.

루트 클래스는 또한 어떤 서비스 객체들이 기계 상에 설치되는지를 검출하고, 그 정보를 설치된 SO들(420)의 내부 열거자에 의해 리턴되는 열거자들을 통해 애플리케이션에 제공한다. 루트 클래스(410)는 하드웨어 ID에 의해 설치된 서비스 객체에 의해 지원되는 물리적 장치가 현재 접속/턴온되어 있는지를 결정하기 위해 블록 420을 통해 오퍼레이팅 시스템의 플러그 & 플레이 시스템(430)과 통합된다.

블록 420은 .NET 서비스 객체들에 대한 .NET SO 저장소(440)를 스캐닝한다. 일 실시예에 따르면, 블록 420은 HKLM/SOFTWARE/OLEforRetail.NET/ControlAssemblies 레지스트리 키에 지정된 디렉토리들을 스캐닝한다. 이 키는 스캐닝할 디렉토리마다 하나씩 다수의 스트링 값을 포함할 수 있다. .NET SO들은 특수 고객 속성을 가진 DLL 어셈블리들이다. SO 어셈블리 내의 모든 서비스 객체 클래스는 장치 클래스, 명칭, 설명, 및 서비스 객체의 버젼을 지정하는 POSServiceObject 속성을 갖는다. 그 예는 다음과 같다:

[POSServiceObjectAttribute("MSR","CommonMSR","Common service object for magnetic stripe reader","1.0.0")]

구성 관리자(550)는 구성 파일을 판독하여, PnP 하드웨어 ID의 레거시 SO로의 맵핑, .NET SO 메타데이타로의 확장, 논-PnP 장치의 SO로의 맵핑, 장치 디스에이블, 및 보안 설정을 행한다.

물리적 장치의 하드웨어 ID를 SO로 맵핑하는 하나 이상의 POSHardwareId 속성이 있을 수 있다. ID는 그의 플러그 & 플레이 시스템에 의해서도 사용되는 하드웨어 ID이다. 하드웨어 ID는 범위의 하위 및 상위 ID를 지정함으로써 범위 내에서 정의된다. 그 예는 다음과 같다:

[POSHardwareId("USB/Vid_05d9&Pid_a794&Rev_0000","USB/Vid_05d9&Pid_a794&Rev_9999")]

일 실시예에 따르면, 레거시 서비스 객체들에 대해, 루트 클래스(415)는 HKLM/SOFTWARE/OLEforRetail/ServiceOPOS 레지스트리 키를 판독한다. 모든 등록된 OPOS 서비스 객체의 명칭 및 프로그램 ID는 장치 타입들에 의해 그룹화된 키 하에서 정의된다. 레거시 SO들에 대한 하드웨어 ID는 특수 폴더 내에 위치한 구성 XML 파일들에 의해 정의된다.

전술한 바와 같이, 일 실시예에 따르면, CCL은 UPOS 사양에서 정의된 지원되는 장치 클래스들 각각에 대하여 관리 코드로서 UPOS V1.8 특성, 메소드 및 이벤트를 POS 애플리케이션에 노출시킨다.

CCL(410)은 각각의 장치 클래스에 대한 제어 객체(CO)를 나타내는 어셈블리들의 집합이다. CCL은 POS 애플리케이션과 같은 애플리케이션에 애플리케이션 인터페이스를 제공한다. 서비스 객체는 API를 구현하며, CO 클래스의 장치를 지원한다. 다음은 표준 특성, 메소드 및 이벤트의 예시적인 리스트이다.

명칭	타입	가변성	주
AutoDisable	bool	read-write
BinaryConversion	int	read-write	레거시 지원
CapPowerReporting	int	read-only
CapStatisticsReporting	bool	read-only
CapUpdateStatistics	bool	read-only
CheckHealthText	string	read-only
Claimed	bool	read-only
DataCount	int	read-only
DataEventEnabled	bool	read-write
DeviceEnabled	bool	read-write
FreezeEvents	bool	read-write
OpenResult	int	read-only	레거시 지원
OutputID	int	read-only
PowerNotify	int	read-write
PowerState	int	read-only
ResultCode	int	read-only	레거시 지원
ResultCodeExtended	int	read-only	레거시 지원
State	int	read-only
ControlObjectDescription	string	read-only
ControlObjectVersion	int	read-only
ServiceObjectDescription	string	read-only
ServiceObjectVersion	int	read-only
DeviceDescription	string	read-only
DeviceName	string	read-only

일 실시예에 따르면, UPOS V1.8 상수들이 구현되고, UPOS에 의해 설정된 분 류 및 명명 규약이 뒤따른다. 일 실시예에 따르면, CCL은 .NET 델리게이트 형태의 UPOS 이벤트를 노출시킨다. 또한, 라이브러리는 POS 장치와 관련된 PnP 이벤트를 노출시킨다.

CCL은 인터페이스들 및 이들의 장치 클래스 명칭들을 정의한다. 라이브러리는 또한 추가 장치 클래스들이 정의되는 것을 허용한다.

IPhysicalDevice 인터페이스는 부착 또는 제거되고 있는 특정 장치에 대한 여러 특성들, 예를 들어 설치 상태, POS 장치 클래스, 전체 장치 경로, 설명 및 하드웨어 Id를 노출시킨다. 이러한 정보는 애플리케이션이 이벤트를 어떻게 처리할 것인지를 결정하는 데 필요한 컨텍스트를 애플리케이션에게 제공한다.

공용 인터페이스 IPhysicalDevice

{

string Description {get;}

string DevicePath {get;}

string Class {get;}

string[] HardwareIds {get;}

bool Installed {get;}

}

PnP 지원은 PhysicalDeviceInfo 클래스에서 구현된다. 일 실시예에 따르면, PhysicalDeviceInfo 클래스는 System.Windows.Forms.Form으로부터 상속되는 관리 클래스이다. PhysicalDeviceInfo 클래스는 *.Form으로부터 상속되는데, 이는 원시 오퍼레이팅 시스템 이벤트들이 윈도우 메시지를 통해 애플리케이션에 노출되고 *.Form이 원시 윈도우를 랩핑하기 때문이다. 원시 윈도우는 OS로부터 PnP 이벤트를 캡쳐하는 데 사용되며, 표시되지 않는다.

PhysicalDeviceInfo 클래스가 인스턴스화될 때, 이 클래스는 모든 장치 인터페이스 클래스로부터의 PnP 이벤트에 대해 등록되어, PnP를 지원하는 임의의 장치가 시스템(논-POS 장치 포함)으로부터 추가 또는 제거될 때 이벤트를 노출시킨다. 또한, PhysicalDeviceInfo 클래스는 현재 시스템에 의해 알려진 모든 장치의 내부 리스트를 구축하며, 어느 장치가 현재 부착되어 인에이블되어 있는지를 결정한다. 이 클래스는 또한 장치들의 완전한 리스트를 리턴하고 특정 장치들에게 그들의 현재 설치 상태를 질의하기 위해 장치 열거 동안 CCO.Net에 의해 사용되는 헬퍼 메소드를 포함한다. 장치 열거 및 장치 정보는 Win32 API 내의 P 호출 스타일 연동성으로 행해지는 원시 API 호출을 통해 이루어진다.

PhysicalDeviceInfo 클래스는 원시 오퍼레이팅 시스템 PnP 이벤트를 이벤트로서 루트 CCO.Net 클래스에 노출시킨다. 이들 이벤트는 IPhysicalDevice 인터페이스를 구현하는 PhysicalDevice 객체를 리턴한다. PhysicalDevice 클래스는 단일 장치를 나타내는 클래스이며, 그의 하드웨어 ID, 설명 등과 같은 장치에 대한 여러 특성들을 노출시킨다. 이것은 결과적으로 애플리케이션에 버블 업되는 동일 객체이다.

메소드 및 특성 액세스

라이브러리에 의해 지원되는 장치에 액세스하기를 원하는 POS 애플리케이션(405)과 같은 애플리케이션은 다른 메소드를 호출하기 전에 장치를 먼저 열어야 한다. 일 실시예에 따르면, 장치를 성공적으로 열기 전에 메소드를 호출하려는 시도는 OPOSClosedException을 발생시킨다. 독점 이용 장치들에 액세스하는 애플리케이션은 메소드들의 대부분을 호출하기 전에 장치를 요구하고 인에이블시켜야 한다. 공유 가능 장치에 액세스하는 애플리케이션은 메소드들의 대부분을 호출하려고 시도하기 전에 장치를 인에이블시켜야 한다. 성공적으로 장치를 열기 전에, 장치와 관련된 대부분의 특성들의 값은 초기화되지 않는다. 장치에 대한 특성들이 초기화된 후, 장치에 대한 후속 요구 및 인에이블은 특성들을 재초기화하지 않는다. 특성들은 장치가 닫힐 때까지 초기화된 채로 유지된다.

장치 관리자 애플리케이션에 의해 수신된 데이타는 DataEvent로서 큐잉된다. 데이타가 수신될 때 AutoDisable 특성이 참으로 설정되면, 제어는 그 자체를 자동으로 디스에이블시켜 DeviceEnabled 특성을 거짓으로 설정한다. 이것은 제어가 추가 입력을 큐잉하고, 가능할 때 장치를 물리적으로 디스에이블시키는 것을 방지한다.

애플리케이션이 장치로부터 입력을 수신할 준비가 된 때, 애플리케이션은 DataEventEnabled 특성을 참으로 설정한다. 이어서, 입력이 수신된 때(통상 하드웨어 인터럽트의 결과로서), 제어는 DataEvent를 큐잉하여 이벤트를 요구한 애플리케이션으로 전달한다. 데이타가 이미 큐잉된 경우, DataEvent는 전달될 것이다. 이 이벤트는 수치 파라미터를 통한 입력 상태 정보를 포함할 수 있다. 제어는 이벤트가 개시되기 직전에 필요에 따라 입력 데이타 플러스 다른 정보를 장치 특성들 내에 배치한다.

이벤트를 전달하기 직전에, 제어는 DataEventEnabled 특성을 거짓으로 설정함으로써 추가 데이타 이벤트를 디스에이블시킨다. 이것은 후속 입력 데이타가 제어에 의해 큐잉되게 하며, 애플리케이션은 현재의 입력 및 관련 특성들을 처리한다. 애플리케이션이 현재의 입력을 마쳤고, 더 많은 데이타에 대해 준비가 된 때, 애플리케이션은 DataEventEnabled를 참으로 설정함으로써 이벤트들을 다시 인에이블시킨다.

입력 장치가 독점 이용 장치인 경우, 애플리케이션은 장치가 입력의 판독을 시작하기 전에 장치를 요구하여 인에이블시킨다. 공유 가능 입력 장치에 대해서는 장치가 입력의 판독을 시작하기 전에 하나 이상의 애플리케이션이 장치를 열어 인에이블시킬 수 있다. 애플리케이션은 제어가 DataEvent를 이용하여 데이타를 전송하기 전에 ClaimDevice 메소드를 호출하여 장치에 대한 독점 액세스를 요구한다. 이벤트 구동 입력이 수신되지만, 애플리케이션이 장치를 요구하지 않은 경우, 입력은 애플리케이션이 장치를 요구할 때까지(그리고 DateEventEnabled 특성이 참일 때까지) 버퍼링된다. 이러한 거동은 다수의 애플리케이션 사이에서 장치의 순차 공유를 허용하여, 이들 사이에 입력 포커스를 효율적으로 전달한다.

제어가 이벤트 구동 입력을 모으거나 처리하는 동안 에러가 발생하는 경우, 제어는 그의 상태를 에러로 변경하고, 하나 또는 2개의 ErrorEvent를 큐잉하여 애 플리케이션에게 에러 상태를 경고한다. 이 이벤트(또는 이벤트들)는 DataEventEnabled 특성이 참일 때까지 전달되지 않으며, 따라서 순차 애플리케이션 시퀀싱이 발생한다. 일 실시예에 따르면, 에러 이벤트 및 예외는 다음의 로커스들과 함께 전달된다:

에러가 발생한 반면 하나 이상의 DataEvent가 큐잉된 경우에 큐잉되는 InputWithData(OPOS_EL_INPUT_DATA). 이것은 모든 DataEvent 앞에 큐잉된다. 일반적인 구현은 이것을 이벤트 큐의 헤드에 배치한다. 이 이벤트는 입력을 즉시 소거하거나 사용자에게 에러에 대해 선택적으로 경고하고 버퍼링된 입력을 처리할 수 있는 능력을 애플리케이션에 제공한다. 후자의 경우는 스캐너 제어에 유용할 수 있는데, 사용자는 즉시 에러에 대해 경고를 받아 에러가 해결될 때까지 더 이상의 항목들을 스캐닝하지 않을 수 있다. 이어서, 임의의 미리 스캐닝된 항목들은 에러 복구가 이루어지기 전에 성공적으로 처리될 수 있다.

에러가 발생하였고 이용 가능한 데이타가 없을 때 전달되는 InputNoData(OPOS_EL_INPUT). 일반 구현은 이것은 이벤트 큐의 끝에 배치한다. 에러가 발생한 때 몇몇 입력 데이타가 이미 큐잉된 경우, 로커스 "InputWithData"와 함께 ErrorEvent가 먼저 큐잉되고 전달되며, 모든 DataEvent가 개시된 후에 이 에러 이벤트가 전달된다. "InputWithData" 이벤트가 전달되고, 애플리케이션 이벤트 핸들러가 "Clear"로 응답한 경우, 이 "InputNoData" 이벤트는 전달되지 않는다.

제어는 다음 중 하나가 발생할 때, 즉 (1) 애플리케이션이 InputNoData로부터 ErrorEvent를 리턴하거나, (2) 애플리케이션이 InputWithData로부터 OPOS_ER_CLEAR와 함께 ErrorEvent를 리턴하거나, (3) 애플리케이션이 ClearInput 메소드를 호출할 때 에러 상태에서 벗어난다.

일부 제어들에 대해, 애플리케이션은 이벤트 구동 입력을 시작하기 위한 메소드를 호출한다. 입력이 제어에 의해 수신된 후, 일반적으로 메소드가 입력을 시작하기 위해 다시 호출될 때까지 어떠한 추가 입력도 수신되지 않는다. 그 예는 MICR 및 서명 캡쳐 장치들을 포함한다. 이러한 이벤트 구동 입력의 변형은 종종 "비동기 입력"이라고 한다.

DataCount 특성은 제어에 의해 큐잉된 DataEvent들의 수를 얻기 위해 판독될 수 있다. 제어에 의해 큐잉된 모든 입력은 ClearInput 메소드를 호출함으로써 삭제될 수 있다. ClearInput은 공유 가능 장치들에 대한 Open 후에, 그리고 독점 이용 장치들에 대한 ClaimDevice 후에 호출될 수 있다.

일반적인 이벤트 구동 입력 모델은 입력 데이타를 직접 리턴하는 메소드 또는 특성을 포함하는 장치 클래스의 정의를 규제하지 않는다. 몇몇 장치 클래스들은 보다 직관적이거나 유연한 방식으로 동작하기 위해 이러한 메소드 및 특성을 정의한다. 그 일례는 키록 장치이다. 이러한 타입의 입력은 종종 "동기 입력"이라고 한다.

출력

OPOS 출력 모델은 동기 및 비동기 출력으로 구성된다. 장치 클래스는 하나 또는 양 타입을 지원하거나 어느 타입도 지원하지 않을 수 있다.

동기 출력

동기 출력은 장치 출력이 빠르게 수행될 수 있을 때 선호된다. 이것의 장점은 간이성에 있다. 애플리케이션은 출력을 수행하기 위해 클래스 특정 메소드를 호출한다. 제어는 출력이 완료될 때까지 리턴하지 않는다. 이러한 타입의 출력 동안 에러가 발생하면, OPOSException이 발생한다.

비동기 출력

비동기 출력은 선입 선출 방식으로 수행된다. 이러한 타입의 출력은 장치 출력이 느린 하드웨어 상호작용을 요구할 때 선호된다. 이것의 장점은 인식된 응답성인데, 이는 장치가 출력을 수행하고 있는 동안 애플리케이션이 다른 작업을 수행할 수 있기 때문이다. 애플리케이션은 출력을 시작하기 위해 클래스 특정 메소드를 호출한다. 제어는 물리적 장치가 요구를 수신하여 처리할 수 있게 되자마자 물리적 장치로 전달하기 위해 요구를 프로그램 메모리에 버퍼링하고, OutputID 특성을 이 요구에 대한 식별자로 설정하며, 가능한 한 빨리 리턴한다. 장치가 요구를 성공적으로 완수한 때, OPOS는 OutputCompleteEvent를 개시한다. 이 이벤트의 파라미터는 완수된 요구의 OutputID를 포함한다.

비동기 요구를 수행하는 동안 에러가 발생하면, ErrorEvent가 개시된다. 애플리케이션의 이벤트 핸들러는 미해결 출력을 재시도하거나 삭제한다. 제어는 ErrorEvent가 진행되는 동안 에러 상태에 있다.

모든 비동기 출력을 포함하는 모든 버퍼링된 출력 데이타는 ClearOutput을 호출하여 삭제될 수 있다. OutputCompleteEvents는 삭제된 출력에 대해 개시되지 않는다. 이 메소드는 또한 (가능한 때) 진행중일 수 있는 임의의 출력을 중지한다.

에러 핸들링

라이브러리 내의 에러 핸들링은 예외를 통해 구현된다. 에러는 UPOS V1.8 사양에 정의된 HRESULT 코드들(ResultCode 및 ResultCodeExtended 값들)에 기초한다. POSException 클래스는 System.ApplicationException으로부터 도출되며, 기본 예외 클래스이다. 이 클래스는 또한 OPOS 에러 코드에 대한 상수를 정의한다. POSControlException은 POSException으로부터 도출되며, 서비스 객체들에 의해 발생한다. POSLibraryException은 또한 POSException으로부터 도출되며, 라이브러리에 의해 발생한다.

일 실시예에 따르면, 에러 핸들링은 System.ApplicationException으로부터 도출된다. 이러한 도출 클래스는 UPOS 사양으로부터 ResultCode 및 ResultCodeExtended 특성들을 구현한다.

보안

CCL, 플러그 & 플레이 기능, 및 장치 열거 기능은 서비스 객체들에 액세스하기 위해 역할 기반 보안을 이용한다. 장치 관리는 서비스 객체들과 관련된 역할들 의 UI 및 관련 구성에 대한 요건을 포함한다.

시스템에 부착되어 접속 및 구성된 장치들을 열거하는 헬퍼 클래스가 노출된다. 이 클래스는 애플리케이션 개발자가 어떤 장치가 액세스 가능한지를 결정하기 위해 CCL에 질의하는 것을 허용하는 공용 메소드를 노출시킨다. 이러한 열거 클래스는 또한 장치 통계(UPOS V1.8 사양에 정의됨)에 질의할 수 있는 능력을 포함한다.

서비스 객체 개발자 및 소매상에 대한 보안을 간략화하기 위하여, 소유자, 통합자, 관리자 및 회계자를 포함하는 추가적인 사용자 타입이 추가된다. 디폴트로, 소유자는 관리자 그룹의 일원이며, 통합자 및 관리자는 파워 사용자이고, 회계자는 사용자이다.

적절한 역할 특권 없이 제어에 액세스하려는 시도는 "비인증 액세스" 예외를 발생시킨다. 에러가 발생했다는 표준 에러 메시지가 식별된다. 애플리케이션이 메시지를 처리하고 있는 경우 표준 에러 메시지를 표시하지 않는 옵션이 있어야 한다. 표준 메시지는 역할 기반 보안이 사용되고 애플리케이션이 이 에러를 처리하지 않는 경우에는 방해되지 말아야 한다.

일 실시예에 따르면, CCL은 UPOS 장치 클래스에 의해 그룹화된 이용 가능 POS 장치들의 열거자를 노출시킨다. 라이브러리는 서비스 객체들의 인스턴스들을 인스턴스화하기 위한 공장으로서 기능한다. 이것은 특정 서비스 객체들의 구현으로부터 POS 애플리케이션들의 작성자들을 분리하며, POS 장치들과 상호작용을 위한 애플리케이션에 대한 단일 진입점이다.

일 실시예에 따르면, 에러들은 표준 .NET 방식으로(예외에 의해) 보고된다. 라이브러리 예외는 논리적인 상속 계층 구조를 갖는다. 표준 OPOS 에러 코드는 가능하고 알 수 있는 경우에 사용된다.

도 5는 본 발명의 양태들에 따라 PnP 소매 시스템과 레거시 장치들을 통합하기 위한 아키텍처를 나타낸다.

CCL(510)은 관리 프록시 클래스로 COM 기반 SO들을 랩핑한다. 프록시는 반사(530)를 통해 SO의 제어 객체를 인스턴스화하고, 이 객체에 애플리케이션 호출을 중계한다. 프록시는 실제 SO(570)에게 직접 대화하지 않는다. 대신, 그의 CO(560)와 통신한다.

LegacyProxy 클래스는 모든 레거시 프록시에 대한 보편적인 기본 클래스이다. LegacyProxy 클래스는 현재 지원되는 24개의 OPOS 장치 클래스(ICashDrawer, IMSR, IPOSPrinter 등)에 대한 인터페이스를 구현하여, 그의 인스턴스들이 인터페이스들 중 어느 하나로 전송될 수 있게 한다. 본질적으로, LegacyProxy는 모든 OPOS 제어들의 수퍼세트이다. LegacyProxy는 모든 플럼빙(plumbing)을 관리하고 실제 통신을 위해 IDispatch를 사용하는 표준 .NET-COM 연동층을 통해 CO와 대화한다. IDispatch는 명칭에 의해 특성 및 메소드를 호출하므로, LegacyProxy 클래스는 기반 CO가 이들을 구현하는 한 특성 및 메소드를 노출시킬 수 있다.

일 실시예에 따르면, 레거시 제어로부터 발생하는 이벤트는 System.Runtime.InteropServices 명칭 공간으로부터의 UCOMIConnectionPointContainer 및 UCOMIConnectionPoint 인터페이스들에 의해 훅업된다. 이벤트 핸들러는 이벤트 수신기 클래스(LegacyProxy)가 레거시 제어의 특정 이벤트 싱크 인터페이스를 구현하는 경우 UCOMIConnectionPoint에 의해 설정될 수 있다. 5개의 표준 OPOS 이벤트만이 존재한다고 해도, 이벤트 싱크 인터페이스들은 모든 제어 객체들에 대해 모두 상이하다(이들은 다른 인터페이스 guid를 갖는다). 레거시 제어 객체의 모든 인스턴스에 대해 LegacyProxy 클래스를 인스턴스화하는 대신, CO가 예측하는 이벤트 싱크 인터페이스를 추가적으로 구현하는 LegacyProxy로부터 도출되는 동적 인-메모리 클래스가 생성된다. 인터페이스의 GUID는 레거시 CO 인스턴스의 이벤트 접속점으로부터(UCOMIConnectionPoint를 통해) 검색된다. 생성된 클래스는 이벤트 핸들러에 대한 호출을 LegacyProxy 클래스로 하향 중계하며, LegacyProxy 클래스는 이들을 변환하여 애플리케이션에 대해 개시한다.

1. 애플리케이션은 레거시 OPOS 제어에 대한 Root.OpenControl을 호출한다.

2. Root.OpenControl은 AssemblyFinder.OpenControl을 호출한다.

3. AssemblyFinder.OpenControl은 요구가 레거시 제어에 대한 것임을 이해하고, AssemblyFinder.GenerateLegacyProxy를 호출한다.

4. AssemblyFinder.GenerateLegacyProxy는 COM 클래스를 인스턴스화한 후, 접속점(이벤트 싱크) 인터페이스의 guid를 얻기 위해 UCOMIConnectionPointContainer 및 UCOMIConnectionPoint를 사용한다.

5. AssemblyFinder.GenerateLegacyProxy는 이벤트 싱크 guid와의 인터페이스 를 구현하는 인-메모리 프록시 클래스를 생성하기 위해 AssemblyFinder.EmitProxy를 호출한다.

6. 애플리케이션은 그 위에 Open을 호출하여 프록시를 연다.

7. Open 메소드 내에서, 다른 것들 중에서 LegacyProxy(생성된 프록시의 부모 클래스)는 인스턴스를 이벤트 핸들러로서 설정하기 위해 UCOMIConnectionPoint.Advise를 호출한다.

POS 애플리케이션에 대한 지원

OPOS.NET API

CCL은 3개의 코어 어셈블리, 즉 (1) 인터페이스, enum 및 상수를 정의하고 SO 및 애플리케이션 양자에 의해 참조되는 POS.Interfaces.dll, (2) 애플리케이션들(ISV)이 설치된 POS 장치들에 대한 서비스 객체들을 열거하고 인스턴스화하도록 하는 POS.Root 클래스를 포함하는 POS.dll, 및 (3) 서비스 객체에 대한 기본 클래스인 GenericServiceObject.dll로 구성된다. 서비스 객체(IHV)의 작성자는 그로부터 도출하고 이벤트 큐, 글로벌 요구 등과 같은 기본 SO 기능의 디폴트 구현을 이용하도록 권장된다.

3개의 어셈블리는 POS 기계 하드 드라이브 상의 여러 곳에서 참조되므로, 글로벌 어셈블리 캐시에 대한 어셈블리들이 설치된다. 이것은 기계 전체에서 바이너리들의 하나의 사본만이 사용되고 바이너리들이 하나의 중심 장소에서 서비스되는 것을 보장하는 것을 돕는다.

서비스 객체 인터페이스

관리 서비스 객체를 생성하기 위해 여러 인터페이스들이 정의되어 있다. 이들 인터페이스는 POS 1.8 사양을 캡슐화하며, 2개의 카테고리, 즉 (1) 공통 POS 기능을 모델링하는 장치 클래스 독립 인터페이스들, 및 (2) 주어진 장치 클래스에 고유한 기능을 모델링하는 장치 종속 인터페이스들로 분류된다.

공개적으로 노출된 POS 인터페이스(공통 및 장치 종속 인터페이스)는 개별 어셈블리 POS.Interfaces.dll에 정의된다. 이들 인터페이스는 .NET 서비스 객체에 의해 구현된다. 애플리케이션은 CCL로부터 수신된 SO 인스턴스를 이들 인터페이스로 전송하여 특정 장치 클래스의 특정 기능에 액세스한다. 기본 제어 인터페이스는 POS.Interface.Basic 명칭 공간에 정의되며, 다음의 계층 구조를 갖는다. IPOSControl은 .NET 서비스 객체에 대한 기본 인터페이스이다. SO는 이것을 직접 또는 간접 구현한다. 라이브러리는 SO에 대해 이 인터페이스에 대한 포인터를 사용하며, 애플리케이션은 이것을 IMSR, IPOSPrinter 등과 같은 보다 특정한 장치 종속 인터페이스로 전송한다. IPOSEventInput은 이벤트 구동 입력 장치의 SO에 대한 3개의 특성을 추가함으로써 IPOSControl을 확장한다. IPOSAsyncOutput는 비동기 출력을 지원하는 장치(예를 들어 프린터)의 SO에 대한 OutputID 특성을 추가함으로써 IPOSControl를 확장한다.

표준 OPOS 장치 클래스에 대한 장치 종속 인터페이스는 POS.Interfaces.Specific 명칭 공간에 정의된다. 이들은 위의 기본 인터페이스들 중 하나로부터 도출되며, 특정 장치 클래스에 고유한 기능으로 이들을 확장한다. IHV는 이들의 SO를 구현할 때 이들 인터페이스로부터 도출되어야 한다. 예시적인 인터페이스는 현금 인출기에 대한 ICashDrawer, 자기 띠 판독기에 대한 IMSR, 영수증 프린터에 대한 IPOSPrinter 등이 있다.

인터페이스는 각각의 OPOS 인터페이스와 밀접하게 매칭된다. 동시에, COM 제한으로 인해 UPOS로부터 OPOS가 도출되는 몇몇 경우에는 오리지날 UPOS 인터페이스가 사용된다. 예를 들어, OPOS는 바이너리에서 ANSI로의 변환에서 소정의 복잡함을 유발하는 바이너리 데이타를 송수신하기 위해 BSTR 스트링을 사용한다. CCL에서, 바이너리 데이타에 대해 바이트 어레이가 사용된다.

예를 들어, 다음은 MSR(자기 띠 판독기)에 대한 OPOS 및 라이브러리 인터페이스들이 어떻게 보이는지를 나타낸다.

인터페이스들은 이들의 부모/조부모로서 IPOSControl을 가지며, 따라서 임의의 SO가 IPOSControl 인터페이스로 전송될 수 있다. 라이브러리 클래스는 IPOSControl 인터페이스와 함께 동작하며, 애플리케이션은 SO의 인스턴스를 장치 특정 인터페이스로 전송한다. 이것은 라이브러리의 변경 없이 새로운 장치 클래스의 도입을 허용한다. 새로운 장치 클래스 인터페이스가 IPOSControl로부터 도출되는 한, 라이브러리는 새로운 장치 클래스에 대한 SO 인스턴스를 처리할 수 있다.

도 6은 본 발명의 양태들에 따른 예시적인 헬퍼 클래스 및 SO 저장소를 나타낸다.

하드웨어 벤더는 일반적으로 POS 사양에 기술된 인터페이스를 구현하고 그들의 하드웨어와 직접 대화하는 장치 종속 서비스 객체(SO)를 구현한다. CCO.Net 라이브러리는 관리 코드에 서비스 객체를 기입하기 위한 지원, 대부분의 서비스 객체들에 공통인 POS 기능들의 일반적인 구현을 포함하는 SO의 고품질 구현들을 생성하기 위한 부담을 덜어 주는 여러 기술을 포함한다. 이것은 장치 요구/인에이블링, 이벤팅, 메시지의 큐잉, 통계 등을 위한 기반 구조를 포함한다. IHV는 이들이 장치 특정 상세에 집중되는 것을 허용하는 SO의 POS 특정 양태들, 및 성능 카운터, 장치 통계 등에 대한 한 세트의 헬퍼 클래스를 구현하기 위한 부담의 많은 부분을 줄이기 위하여 이 객체를 이용할 수 있다.

일 실시예에 따르면, 서비스 객체는 .Net 어셈블리로서 작성된다. 이들 어셈블리는 IPOSControl 인터페이스, 또는 IPOSControl로부터 도출되는 정의된 장치 특정 인터페이스들 중 하나로부터 도출된다. 이들 어셈블리는 지원되는 장치들의 장치 클래스, POS 버젼 및 하드웨어 ID를 기술하는 어셈블리 레벨 및 클래스 레벨 속성들을 포함한다. CCO.Net 라이브러리는 이들 속성을 이용하여, SO가 장치 클래스들 중 어느 클래스를 구현하고, 어떤 하드웨어를 제어하는지를 결정한다. 어셈블리 속성을 사용함으로써 SO의 설치가 매우 간단해지는데, 이는 어셈블리를 CCO.Net가 그것을 발견할 수 있는 디렉토리로 복사하는 것이 행해져야 할 모든 것이기 때문이다.

일반 서비스 객체 클래스는 모든 장치 클래스의 서비스 객체에 의해 요구되는 디폴트 기능을 구현하는 추상 기본 클래스이다. 일반적인 시나리오는 IHV가 일반 서비스 객체 및 장치 특정 인터페이스들 중 하나로부터 도출되는 것이다. 이를 행함으로써, IHV는 일반 서비스 객체에 의존하여, POS 특정 상세의 많은 부분을 처리할 수 있으며, SO의 장치 특정 양태들에 그들의 노력을 집중할 수 있다.

일반 서비스 객체 클래스는 IPOSControl 인터페이스 상의 메소드들 및 특성들의 모두에 대한 디폴트 구현을 포함한다. 이것은 이벤트 큐잉 및 전달, 장치 상태 관리(요구, 인에이블링 등) 및 상태 보고를 위한 메카니즘을 포함한다. 이것은 추상 클래스이므로, 직접 인스턴스화될 수 없으며, IHV가 그들의 SO를 도출하는 것만을 의도한다. 모든 메소드 및 특성은 가상적인 것으로 표시되며, 따라서 IHV는 디폴트 구현을 사용하여 이들이 적당하다고 보는 임의의 메소드를 무시할 수 있다.

일반 서비스 객체는 이벤트 큐, 이벤트 큐 작업자 스레드 및 다양한 동기화 객체의 형태로 POS 이벤트 전달의 상세를 구현한다. 고레벨에서, 이벤팅은 다음과 같이 일반 서비스 객체에 의해 처리된다:

1) 스레드가 시그널링되고, FreezeEvents 특성이 거짓일 때까지 대기한다.

2) 스레드가 종료되고 있는지를 검사한다. 그러한 경우, 이벤트 큐를 소거하고 스레드를 종료한다.

3) 이벤트 큐로부터 다음 이벤트를 제거한다.

4) PreFireEvent(EventArgs posEvnet)를 호출한다.

5) PreFireEvent()가 단계 4에서 참을 리턴한 경우, 이벤트를 애플리케이션에 대해 개시한다.

6) 단계 1로 돌아간다.

2개의 헬퍼 메소드, 즉 QueueEvent(EventArgs posEvent) 및 PreFireEvent(EventArgs posEvent)가 이벤팅을 구동하기 위해 제공된다. QueueEvent(EventArgs posEvent)는 이벤트를 이벤트 큐에 추가하고, 새로운 이벤트가 도달한 것을 이벤트 스레드에 신호하기 위해 사용된다. PreFireEvent(EventArgs posEvent)는 이벤트가 개시되기 직전에 일반 SO에 의해 호출된다. 이것은 SO에게 특정 이벤트가 개시되기 전에 그의 내부 상태를 갱신할 기회를 주기 위해 제공된다.

Open() 메소드가 호출될 때 이벤트 큐잉 데이타 구조가 생성되고 초기화된다. Close() 메소드는 장치를 릴리스하고, 이벤트 스레드를 종료하며, 내부 객체들을 모두 삭제한다. 간단하고 일관된 방식으로 IHV가 성능 카운터 및 장치 통계를 구현하는 것을 돕기 위해 한 세트의 헬퍼 클래스가 제공된다.

장치 통계는 2개의 카테고리, 즉 (1) 장치 정보 통계 및 (2) 장치 통계로 분류될 수 있다. 장치 정보 통계는 명칭, 제조자, 버젼 등과 같은 장치의 특성들이다. 장치 통계는 일반적으로 장치가 파워온된 시간 수 등과 같은 장치 사용 정보를 반영한다. UPOS 1.8은 모든 장치들이 또한 지원해야 하는 한 세트의 통계 및 각 장치 클래스에 대한 통계들을 정의한다. UPOS는 또한 장치들이 제조자 특정 장치 통계를 지원할 수 있음을 지정하고 있다.

DeviceStatistics 헬퍼 클래스는 UPOS 사양의 1.8 버전에 정의된 장치 통계를 구현하는 부담을 덜어준다. 이것은 GenericSO 구현에 포함되며, 따라서 GenericSO로부터 도출되는 SO는 통계를 지원하기 위해 매우 적은 양의 코드만을 작성하면 된다. 일반적으로, 고객들이 작성해야 하는 유일한 코드는 적절한 시간에 주어진 통계의 값을 증가시키기 위한 IncrementStatistics(string Name) 메소드를 호출하기 위한 것이다. GenericSO는 상세들의 나머지를 관리한다.

DeviceStatistics 클래스는 하드웨어 또는 소프트웨어에 저장된 통계를 지원한다. 소프트웨어 기반 통계는 애플리케이션 정의 가능 간격으로 XML 파일에 자동 유지되며, 장치가 요구될 때 이 파일로부터 자동 로딩된다. DeviceStatistics는 3개의 메소드(resetStatistics, retrieveStatistics 및 updateStatistics) 각각은 물론 2개의 특성(CapStatisticsReporting 및 CapUpdateStatistics)을 구현한다. 이것은 또한 통계를 생성하고, 통계를 증가시키고, 통계를 디스크에 로딩/저장하기 위한 공용 헬퍼 메소드를 포함한다. 장치 자체에 저장된 통계를 지원하기 위하여, 통계의 값을 리턴하는 SO에 의해 콜백 기능이 지정된다. DeviceStatistics 클래스 는 클라이언트 애플리케이션이 이 통계를 요구할 때마다 이 기능을 호출할 것이다.

IHV는 필요에 따라 장치 드라이버와 함께 이들 서비스 객체를 설치하기 위한 INF 파일을 제공한다. 선택된 INF 파일 세트는 미리 설치되어, 오퍼레이팅 시스템이 새로운 장치가 부착될 때 이들을 설치할 수 있게 된다.

서비스 객체 설치

일 실시예에 따르면, .NET 서비스 객체들은 이들의 어셈블리를 HKLM/SOFTWARE/OLEforRetail.NET/ControlAssemblies 레지스트리 키에 지정된 폴더에 복사함으로써 설치된다. .NET SO들은 이들의 어셈블리 메타데이타에 이들을 물리적 장치들로 맵핑하는 데 필요한 정보를 가지므로, 간단한 경우에 대해 그 밖에 어떤 것도 필요하지 않다. 모든 추가 설정은 XML 설정 파일을 통해 제공된다. 추가 설정의 예는 기준 서비스 객체로 맵핑될 추가 하드웨어 id, 둘 이상의 클래스의 장치가 접속되는 경우에 대한 디폴트 서비스 객체, 및 직렬 포트와 같은 논-PnP 장치들에 대한 설정과 같은 항목들을 포함한다.

전술한 바와 같이, 글로벌 설정은 XML 구성 파일에 유지된다. SO에 대한 설정은 미리 정의된 폴더로 넣어진 개별 XML 파일에 위치한다. 라이브러리는 설치된 서비스 객체들이 열거될 때 폴더로부터 주 구성 파일 및 구성 파일들 양자를 판독한다.

IHV들은 그들의 드라이버를 설치하고 SO 어셈블리들 및 선택적인 XML 구성 파일들을 각각의 폴더로 복사하는 그들의 장치에 대한 INF 파일을 갖는다. ISV들 및 관리자들은 XML 구성 파일들을 편집함으로써 설정을 주문화할 수 있다.

CCL은 기본 클래스에 공통 기능의 디폴트 구현을 제공함으로써 .NET 기반 서비스 객체의 작성을 단순화한다. IHV는 기본 클래스로부터 도출되고 필요한 경우 제공된 구현을 무시하며,장치 특정 기능을 추가하도록 권장된다. 새로운 .NET 서비스 객체는 라이브러리에 의해 정의되는 장치 클래스 인터페이스를 구현하는 .NET 클래스이다. CCL은 그들의 서비스 객체에 대한 기본 클래스로서 사용될 수 있는 일반 서비스 객체 클래스를 제공한다. 클래스는 SO의 작성을 단순화하기 위해 가능한 많은 장치 독립 기능을 구현한다.

CCL은 둘 이상의 벤더에 의해 필요할 가능성이 있는 기능들에 대한 한 세트의 헬퍼 클래스를 제공한다. 이것은 .NET SO의 작성을 단순화한다.

일 실시예에 따르면, 라이브러리는 .NET 서비스 객체의 드래그 & 드롭 스타일 설치를 지원한다. SO 어셈블리는 충분한 메타데이타 정보를 포함하여, CCL이 추가 구성 없이 그것을 사용할 수 있게 한다. 어셈블리 메타데이타를 확장하기 위해 추가적인 XML 구성 파일이 정의될 수 있다.

도 7은 본 발명의 양태들에 따라 시스템에 부착된 POS 장치들에 대한 정보를 제공하기 위한 예시적인 디스플레이를 나타낸다.

각각의 장치는 인에이블 또는 디스에이블될 수 있다. 드롭 다운 리스트(720)가 사용되거나, 애플리케이션이 CCL을 호출하여 장치를 디스에이블/인에이블시킬 수 있다. 디스에이블된 장치는 CCL에 의해 액세스될 수 없다. 장치의 액세스를 시도하기 전에, 애플리케이션은 장치를 인에이블시켜야 한다.

각각의 SO 제공자는 그들 각각의 장치들에 대한 이러한 타입의 관리 정보를 제공한다.

일반 탭 및 드라이버 탭은 장치에 대한 다음의 정보, 즉 명칭 및 설명, 하드웨어 ID 및 경로(플러그 & 플레이 장치에 대한), NET 또는 레거시 서비스 객체, 어셈블리 경로, 전체 명칭, 버젼, 클래스 명칭(.NET 객체에 대한), 및 레지스트리로부터의 ProgId, ClsId, 바이너리 경로, 버젼, 구성 파라미터를 나타낸다.

장치에 대한 장치 상태(710)도 표시된다.

도 8은 본 발명의 양태들에 따라 설치된 POS 장치들의 예시적인 스크린 샷을 나타낸다. 도시된 바와 같이, 설치된 POS 장치들은 창(910) 내에 도시되어 있다.

창(810)은 기계에 현재 접속된 장치 클래스 및 장치, 기계에 지금까지 접속된 장치 클래스 및 장치, 설치된 .NET 서비스 객체 어셈블리, 클래스 및 이들이 제어하는 물리적 장치, 설치된 레거시 서비스 객체 및 이들이 제어하는 물리적 장치, 및 글로벌 라이브러리 구성과 같은 항목들을 포함하는 설치된 장치들 및 구성들의 다수의 뷰를 나타낸다. 이 인터페이스는 관리자가 어떤 바이너리가 어떤 서비스 객체를 구현하는지, 그것이 어디에 설치되는지, 어떤 버젼인지 등과 같은 장치와 관련된 저레벨 상세로 드릴 다운하는 것을 돕는다.

또 하나의 패널(820)은 선택된 트리 뷰 노드에 대한 한 세트의 컨텍스트 종속 제어를 호스트한다. 이것은 선택된 노드에 대한 상세한 정보를 나타내며, 이용 가능하나 동작을 제공한다. 예를 들어, 프린터에 대해, Open, Claim, Enable, PrintNormal, CutReceipt 등의 메소드를 호출하는 제어가 있을 수 있다. 또한, 장 치로부터 나오는 이벤트를 가시화하는 제어가 있을 수 있다. 이러한 탭은 관리자가 실제 POS 애플리케이션을 실행하지 않고도 부착된 하드웨어를 빠르게 테스트할 수 있게 한다.

보안 설정도 선택될 수 있다. 예를 들어, 장치들이 록 다운되는 것을 허용함으로써 시스템이 소정의 장치 객체들 및/또는 하드웨어만이 애플리케이션에 이용되는 것을 허용하게 하는 글로벌 보안 설정이 노출될 수 있다. 통계는 또한 장치 통계에 대한 빠른 판독/리셋 액세스를 제공할 수 있다.

전술한 명세서, 예 및 데이타는 본 발명의 구성의 제조 및 이용에 대한 완전한 설명을 제공한다. 본 발명의 많은 실시예들이 본 발명의 사상 및 범위를 벗어나지 않고도 이루어질 수 있으므로, 본 발명은 첨부된 청구범위 내에 있다.

본 발명은 오퍼레이팅 시스템에 의해 지원되지 않는 장치에 대해 플러그 & 플레이(PnP) 기능을 제공한다.

Claims

오퍼레이팅 시스템에 의해 지원되지 않는 장치들에 대해 플러그 & 플레이(PnP) 기능을 제공하기 위한 방법에 있어서,

상기 오퍼레이팅 시스템의 커널 모드(kernel mode)에서 동작하는 이벤트 관리자에 의하여, 장치와 관련된 이벤트를 결정하고, 상기 장치가 상기 오퍼레이팅 시스템에 의하여 지원되지 않는 경우에 상기 장치와 관련된 ID를 포함하는 상기 이벤트를 장치 관리자 애플리케이션에 송신하는 단계;

상기 오퍼레이팅 시스템의 유저 모드(user mode)에 상주하는 상기 장치 관리자 애플리케이션에 의하여 상기 ID로부터 상기 장치를 식별(identify)하는 단계;

상기 장치가 상기 장치와 관련된 상기 장치 관리자 애플리케이션에 의해 지원되면 상기 장치를 사용자 모드 코드로 구현되는 서비스 객체로 맵핑하는 단계; 및

애플리케이션이 일반 인터페이스(generic interface)를 통해 상기 장치에 액세스할 수 있도록, 상기 장치 관리자 애플리케이션에 의하여, 상기 일반 인터페이스를 상기 애플리케이션에 노출시키는 단계

를 포함하는 방법.
제1항에 있어서, 상기 이벤트는 플러그 & 플레이(PnP) 이벤트인, 방법.
제1항에 있어서, 상기 장치는 소매 장치(retail device)인, 방법.
제3항에 있어서, 상기 소매 장치는 범프 바, 현금 교환기, 현금 인출기, 신용 인증 단말기, 동전 교환기, 회계 프린터(fiscal printer), 하드 토탈(hard totals), 키록(keylock), 바코드 스캐너, 톤 표시기, 모션 검출기, 라인 디스플레이, 자기 잉크 문자 인식 판독기, 자기 띠 판독기, PIN 패드, 포인트 카드, POS 키보드, POS 프린터, 원격 주문 디스플레이, 스케일, 서명 캡쳐, 및 체크 이미지 스캐너 중 적어도 하나로부터 선택되는, 방법.
제1항에 있어서, 상기 이벤트가 상기 장치가 설치되는 것을 표시할 경우 상기 장치를 구성하는 단계를 더 포함하는 방법.
제1항에 있어서, 상기 일반 인터페이스를 노출시키는 단계는 상기 애플리케이션에 상기 장치와 관련된 특성들, 메소드들, 및 이벤트들을 제공하는 단계를 더 포함하는, 방법.
제1항에 있어서, 상기 장치가 상기 장치와 관련된 오퍼레이팅 시스템에 의해 지원되지 않을 때 사용자 모드 코드로 구현되는 상기 서비스 객체로 상기 장치를 맵핑하는 단계는 상기 장치가 언제 레거시(legacy) 장치인지 그리고 상기 장치가 언제 PnP 장치인지를 결정하는 단계를 더 포함하는, 방법.
오퍼레이팅 시스템에 의해 지원되지 않는 장치에 대해 플러그 & 플레이(PnP) 기능을 제공하기 위한 시스템에 있어서,

이벤트 관리자를 포함하는 오퍼레이팅 시스템 - 상기 이벤트 관리자는 상기 오퍼레이팅 시스템의 커널 모드에서 동작하고, 상기 오퍼레이팅 시스템은 상기 오퍼레이팅 시스템에 의해 지원되지 않는 장치와 관련된 이벤트를 검출하며, 사용자 모드에 상주하는 장치 관리자 애플리케이션에 상기 이벤트를 제공하도록 구성됨 - ;

상기 장치가 레거시 장치인 때 그리고 상기 장치가 PnP 장치인 때를 결정하도록 구성되고, 상기 장치가 상기 장치 관리자 애플리케이션에 의해 지원되는 경우에 상기 장치와 관련된 특성들, 메소드들, 및 이벤트들을 제공하도록 구성된 공통 제어 라이브러리(common control library; CCL)를 포함하는 상기 장치 관리자 애플리케이션; 및

상기 CCL을 통해 상기 장치 관리자 애플리케이션과 상호작용하고 상기 장치와 관련된 상기 특성들, 메소드들, 및 이벤트들을 수신하도록 구성된 애플리케이션

을 포함하는 시스템.
제8항에 있어서, 상기 오퍼레이팅 시스템은 또한 상기 장치 관리자 애플리케이션에 장치 ID를 제공하도록 구성되며, 상기 장치 관리자 애플리케이션은 또한 상기 장치 ID를 수신하고, 상기 ID에 응답하여 상기 장치를 설치하고, 상기 장치를 사용자 모드 코드로 구현되는 서비스 객체로 맵핑하도록 구성되는, 시스템.
제9항에 있어서, 상기 장치는 범프 바, 현금 교환기, 현금 인출기, 신용 인증 단말기, 동전 교환기, 회계 프린터(fiscal printer), 하드 토탈(hard totals), 키록(keylock), 바코드 스캐너, 톤 표시기, 모션 검출기, 라인 디스플레이, 자기 잉크 문자 인식 판독기, 자기 띠 판독기, PIN 패드, 포인트 카드, POS 키보드, POS 프린터, 원격 주문 디스플레이, 스케일, 서명 캡쳐, 및 체크 이미지 스캐너 중 적어도 하나로부터 선택되는 소매 장치인, 시스템.
제8항에 있어서, 상기 장치 관리자 애플리케이션은 레거시 장치들이 상기 CCL을 통해 상기 애플리케이션에 의해 사용되는 것을 가능하게 하도록 구성된 레거시 연동층(legacy interoperability layer)을 더 포함하는, 시스템.
제8항에 있어서, 상기 장치 관리자 애플리케이션은 또한 상기 오퍼레이팅 시스템에 의해 지원되지 않는 장치와 관련된 이벤트들을 수신하기 위해 상기 오퍼레이팅 시스템에 등록하도록 구성되는, 시스템.
오퍼레이팅 시스템에 의해 지원되지 않는 장치에 대해 플러그 & 플레이(PnP) 기능을 제공하기 위한 컴퓨터 실행 가능 명령들을 구비한 컴퓨터 판독 가능 기록 매체에 있어서,

상기 오퍼레이팅 시스템의 커널 모드에 상주하면서, 상기 장치가 오퍼레이팅 시스템에 의해 지원되지 않는 경우에 장치와 관련된 이벤트를 제공하도록 구성된 제1 컴포넌트; 및

상기 오퍼레이팅 시스템의 사용자 모드에 상주하면서, 상기 제1 컴포넌트에 의해 제공되는 상기 이벤트를 수신하고, 상기 장치가 상기 장치 관리자 애플리케이션에 의해 지원되는 경우에 애플리케이션이 일반 인터페이스를 통해 상기 장치에 액세스하여 상기 이벤트를 수신할 수 있도록 상기 일반 인터페이스를 상기 애플리케이션에 노출시키도록 구성된 제2 컴포넌트

를 포함하는 컴퓨터 판독 가능 기록 매체.
제13항에 있어서, 상기 이벤트는 플러그 & 플레이(PnP) 이벤트와 관련되는, 컴퓨터 판독 가능 기록 매체.
제14항에 있어서, 상기 일반 인터페이스는 또한 PnP 장치 및 레거시 장치와 상호작용하기 위해 상기 애플리케이션에 통합 방식을 제공하도록 구성되는, 컴퓨터 판독 가능 기록 매체.
제14항에 있어서, 상기 장치는 범프 바, 현금 교환기, 현금 인출기, 신용 인증 단말기, 동전 교환기, 회계 프린터(fiscal printer), 하드 토탈(hard totals), 키록(keylock), 바코드 스캐너, 톤 표시기, 모션 검출기, 라인 디스플레이, 자기 잉크 문자 인식 판독기, 자기 띠 판독기, PIN 패드, 포인트 카드, POS 키보드, POS 프린터, 원격 주문 디스플레이, 스케일, 서명 캡쳐, 및 체크 이미지 스캐너 중 적어도 하나로부터 선택되는 소매 장치인, 컴퓨터 판독 가능 기록 매체.
제13항에 있어서, 상기 제2 컴포넌트는 또한 상기 이벤트가 상기 장치가 설치되는 것을 표시할 경우 상기 장치를 설치하도록 구성되는, 컴퓨터 판독 가능 매체.
제13항에 있어서, 상기 일반 인터페이스의 노출은 상기 애플리케이션에 상기 장치와 관련된 특성들, 메소드들, 및 이벤트들을 제공하는 것을 더 포함하는, 컴퓨터 판독 가능 기록 매체.
제18항에 있어서, 상기 제2 컴포넌트는 또한 상기 장치가 상기 오퍼레이팅 시스템에 의해 지원되지 않을 때 사용자 모드 코드로 구현되는 서비스 객체로 상기 장치를 맵핑하도록 구성되는, 컴퓨터 판독 가능 기록 매체.
제18항에 있어서, 상기 제1 컴포넌트는 또한 상기 제2 컴포넌트에 장치 ID를 제공하도록 구성되고, 상기 제2 컴포넌트는 또한 설치된 장치의 타입을 결정하고 구성 파일에 기초하여 상기 장치를 구성하도록 구성되는, 컴퓨터 판독 가능 기록 매체.