키오스크 프로그램 오픈소스 - kioseukeu peulogeulaem opeunsoseu

목차 Show

오픈소스 인터랙티브 키오스크 시스템
스크린 샷

오픈소스 인터랙티브 키오스크 시스템

이것은 최신 릴리스를 XRSSfeedforfil로 다운로드할 수 있는 OpenSource Interactive Kiosk System이라는 Linux 앱입니다. 워크스테이션용 무료 호스팅 제공업체 OnWorks에서 온라인으로 실행할 수 있습니다.

OnWorks와 함께 OpenSource Interactive Kiosk System이라는 이 앱을 무료로 다운로드하여 온라인으로 실행하십시오.

이 앱을 실행하려면 다음 지침을 따르세요.

- 1. 이 애플리케이션을 PC에 다운로드했습니다.

- 2. 파일 관리자 https://www.onworks.net/myfiles.php?username=XXXXX에 원하는 사용자 이름을 입력합니다.

- 3. 이러한 파일 관리자에서 이 응용 프로그램을 업로드합니다.

- 4. 이 웹사이트에서 OnWorks Linux 온라인 또는 Windows 온라인 에뮬레이터 또는 MACOS 온라인 에뮬레이터를 시작합니다.

- 5. 방금 시작한 OnWorks Linux OS에서 원하는 사용자 이름으로 파일 관리자 https://www.onworks.net/myfiles.php?username=XXXXX로 이동합니다.

- 6. 응용 프로그램을 다운로드하여 설치하고 실행합니다.

스크린 샷

오픈소스 인터랙티브 키오스크 시스템

기술

OSIKS(OpenSource Interactive Kiosk System) - 전자 정부, 공공 서비스, 정보 및 기타 목적을 위한 무료 정보 시스템입니다. LAMP + Opera(키오스크 모드의 브라우저) + 키보드(자바 가상 키보드).

특징

키오스크 인터페이스 생성 및 관리
터치 스크린 지원(TFT17에 최적화됨)
많은 브라우저를 지원하지만 훌륭한 Opera 소프트웨어
Opera 브라우저에 플러그인으로 Java의 가상 키보드

오디언스 (Audience)

비영리 단체, 정부, 의료 산업, 최종 사용자/데스크톱

사용자 인터페이스

Gnome, X Window System(X11), KDE, 웹 기반

프로그래밍 언어

PHP, 자바스크립트

데이터베이스 환경

MySQL의

카테고리

HTML/XHTML, CMS 시스템, 연구

https://sourceforge.net/projects/osiks/에서도 가져올 수 있는 애플리케이션입니다. 무료 운영 체제 중 하나에서 가장 쉬운 방법으로 온라인으로 실행하기 위해 OnWorks에서 호스팅되었습니다.

따라서, 본 발명은 첨부된 특허청구범위에 규정된 것과 같은 키오스크와 서버를 제공한다.

본원에서 설명하고 있는 해결책은 융통적이며 재구성가능하고 협력적인 키오스크 아키텍쳐로부터 이점을 갖는데, 이 아키텍쳐는 여러 가지의 애플리케이션에 대해 공공장소 도처에서 재구성 및 직접 액세스 가능한 네트워크 인터페이스를 제공하며, 관리자가 클라이언트에 대해 "페이스-투-페이스(face-to-face)"의 서비스 및/또는 상거래 행위를 제공하며, 다중 통신 네트워크 예컨대 인터넷 (TCP/IP), 공중전화망(PSTN), 종합 정보 통신망(ISDN) 등에 대해 공중 액세스(public access)를 제공한다. 결국, 네트워크 서버 시스템은, 특히, 상이한 애플리케이션과 관련하여 상이한 방식으로 이용되는 다양한 입출력 장치를 지원하기 위해, (하나 이상의 네트워크 서버상에서 잠재적으로 형성, 개발 및 저장되는) 매우 방대한 양의 애플리케이션을 이 상이한 애플리케이션과 관련한 상이한 방식으로 네트워크상의 재구성 가능한 원격 키오스크 및 키오스크 장치로 보낸다.

결국, 바람직한 실시예에서, 키오스크 시스템은 하나 이상의 네트워크, 예컨대 인터넷, 회사 인트라넷 또는 정부 인트라넷 등에 접속될 수도 있다. 키오스크는 하나 이상의 입출력 장치(예를들면, 디스플레이 장치, 키보드, 페이퍼 프린터, 전화 등)를 구비하며, 이들 입출력 장치의 각각과 관련한 하나 이상의 드라이버 프로그램(로컬 APIs)을 구비한다. 디스플레이 장치는 키오스크의 사용자에게 하나 이상의 그래픽 사용자 인터페이스(graphical user interfaces;GUI)와 비디오 영상을 제공하는데 이용된다. 인터페이스들중 몇몇은 애플리케이션에 따라 특정된다. (애플리케이션이란 해당 키오스크가 구성 혹은 재구성되는 사용.) 키오스크는 브라우저를 갖는데, 이 브라우저는 네트워크상의 하나 이상의 서버로부터 하나 이상의 애플리케이션 파일을 (하나의 구성 세트(a configuration set)의 상태로) 페치(fetch)한다. 애플리케이션 파일(구성 세트)은 일련의 HTML 파일을 포함하고, 이 HTML 파일들은 키오스크의 브라우저에 의해 하나의 시퀀스(애플리케이션에 의해 결정됨)로 제공된다. 하나 이상의 HTML 파일들은, 키오스크의 하나 이상의 장치의 로컬 API를 제어하는데 이용되는 내장된(embedded) (제어) 프로그램을 포함한다. 또한 하나 이상의 파일들은 그 밖의 HTML 파일, 멀티미디어 성분(예를들면, 영상 또는 음향) 및/또는 다른 HTML 파일, 멀티미디어 성분, 내장 프로그램들(embedded programs) 및/또는 다른 애플리케이션 파일에 대한 하이퍼링크를 포함할 수도 있다. 첫 번째 애플리케이션 파일은 키오스크에서의 선택 기능(예를들면, 음성, 소프트 버튼, 하이퍼링크 등등)에 의해 서버로부터 선택된다. 이러한 선택(즉 선택 기능)과 관련된 애플리케이션 파일들(구성 세트)은 그에 맞게 키오스크를 구성한다. 따라서 키오스크는 애플리케이션 파일들에 의해 정의되는 다양한 애플리케이션들을 수행하도록 구성 및 재구성될 수 있다.

몇몇 바람직한 실시예에서, 하나 이상의 애플리케이션 파일들은 하나 이상의 사전결정된 선택 링크(예컨대 하이퍼링크)를 갖는다. 브라우저가 애플리케이션 파일들을 (예를 들어 파일 단위로) 번역 또는 해석하는 동안, 사전결정된 선택 링크들이 추가의 선택으로서 GUI상에서 사용자에게 제공된다. 하나 이상의 선택 기능을 이용해 하나 이상의 선택을 행함으로써, 사용자는 하나 이상의 다른 구성 세트, HTML 파일들 등을 선택 및 호출할 수 있는데, 이들 구성 세트, HTML 파일 등은 다른 내장 제어 프로그램을 포함하고 있거나 전혀 포함하지 않을 수 있다. 그러므로, 전술한 것과 같은 추가의 선택을 이용함으로써, 브라우저로 HTML 파일들의 내용을, 또한 사실상 이 시퀀스내의 파일들을 번역하는 시퀀스는 상이한 방식으로 키오스크를 재구성하도록 변경되어, 사용자로부터 정보를 획득하거나 사용자에게 정보를 제공하는 것이 가능해진다. 시퀀스내의 HTML 파일들의 내용을 번역함으로써, 대화형 스크린을 구성하는 하나 이상의 스크린 시퀀스를 제공하도록, 그리고 필요하다면, 선택된 특정 애플리케이션용으로 키오스크를 재구성하기 위해 조합된 장치 작동 시퀀스(내장 프로그램에 의해 제어됨)를 제공하도록 키오스크가 재구성된다. 이러한 실시예에서, 사용자는 (혹은 키오스크나 서버내의 다른 기능은) 키오스크상의 다른 선택 기능을 선택함으로써 키오스크를 다른 애플리케이션용으로 재구성할 수 있다.

몇몇 바람직한 실시예에서는, 애플리케이션의 일부가 웹 페이지 공유 기능을 포함하여, 관리자와 클라이언트가 키오스크와 서버를 연결하는 네트워크를 통해 협력할 수 있도록 해준다. 바람직한 일 실시예에 따르면, 애플리케이션 전용 소프트웨어가 키오스크상에 상주하지 않는 "씬(thin)" 클라이언트 아키텍쳐가 구현된다.

이제 본 발명의 다양한 바람직한 실시예는 다음의 첨부 도면들을 참조로하여 예를들어 상세히 설명될 것이다.

도 1을 참조하면, 잘 알려진 적절한 네트워크 인터페이스(155)를 구비하는 컴퓨터(110)(예를들면, PC350 또는 PC750과 같은 IBM 퍼스널 컴퓨터)를 포함하는 키오스크(kiosk)(100)의 바람직한 일 실시예를 블럭도로 나타내고 있다. 네트워크(150)는 임의의 공지된 근거리 통신망(LAN) 또는 광역망(wide area network : WAN)일 수 있다. 바람직한 실시예에서, 네트워크(150)는 인터넷이다. 그러나, 그 밖의 다른 일반적인 네트워크(150)로서, 예를들면, 회사 네트워크, 정부 네트워크, 교육 네트워크같은 인트라네트워크(intranetworks)와, 회사간 엑스트라네트워크(extranetworks) 및, 전화망, 케이블 네트워크, ISDN 네트워크 등으로 구현되어 1인 이상의 소매 상인(retailer)에 의해 사용되는 네트워크들을 들 수 있다. 컴퓨터(110)는, 키오스크(100)의 일부로서 장착되는 하나 이상의 입력 및/또는 출력 장치(아래 부분에 있음)(130)를 구비한다. 전형적으로 컴퓨터(110)는 하나 이상의 메인 메모리와, 하나 이상의 기억 장치(예를들면, 하드 디스크 드라이브, CDROM 등)(110M)와, 하나 이상의 중앙 처리 장치(CPU)를 구비하는데, 이들은 잘 알려진 것들이다. 또한, 컴퓨터(110)는 예를 들어 유지 보수(maintenance)를 위한 선택사양의 하드웨어 키보드(135) 및 마우스(134)를 구비한다. 사용자는 이러한 다양한 입력 및/또는 출력 장치(주변장치(130)로서 이들 집단을 참조번호 130으로 표시함)에 액세스하여, 컴퓨터(110) 및 네트워크(150)를 통해 네트워크(150)에 연결된 그 밖의 다른 클라이언트 및/또는 서버(195)와 정보를 주고 받는다. 이들 입력/출력 장치(130)의 예로서, 스크린(105)을 구비한 터치 감응성 단말기(touch sensitive terminal)(103)와, 프린터(109)와, 임의의 공지된 일반적인 정보 판독기(111)(예를들면, 마그네틱 카드, 신용 카드, 또는 스마트 카드를 판독하기 위한 카드 판독기(121)), 스캐너(예를들면, 레이저 스캐너)(112), 임의의 공지된 일반적인 정보 기록기(113)(프린터, 티켓 프린터, 매체 프린터―예를들면, 디스켓 디스크 드라이브, 명세서 프린터, 또는 영수증 프린터), 디스펜서(dispenser)(예를 들어, 스티커 또는 컴퓨터 디스크를 디스펜스함), 또는 사용자에게 유형 매체(tangible media)(113A) 상의 정보를 제공하는 그 밖의 다른 임의의 장치(130)를 들 수 있다. 그 밖의 다른 입력/출력 장치(130)는, 현금 지급기, 스캐너, 디포저(deposer), 펜 입력 장치(pen input)(136), 카드 발행기, 티켓 발행기, CRT, 키보드, 터치 감응성 스크린, 프로그램 제어가능한 카메라, 하나 이상의 인체 센서(예를 들어, 적외선을 이용함), 하나 이상의 광원(lights), CD ROM 플레이어, 오디오 입력/출력 장치(예를들면, 마이크로폰(133), 스피커(132), 또는 전화기(107)), 및 메모리(113B)중 하나 이상을 포함한다. 키오스크(100)는, 전화기(107) 또는 화상 회의 시스템(114)(예를들면, PictureTel PCS-100 데스크탑 ISDN 화상 회의 시스템)과 같은 공지의 통신 장치를 구비할 수 있다. (PictureTel은 PictureTel사의 상표이다.) 화상 회의 시스템은, 카메라(들)(131), 스피커(들)(132), 마이크로폰(들)(133) 및/또는 적절한 네트워크 인터페이스(155)를 통해 접속되어 있는 하나 이상의 ISDN 접속부나 개별 네트워크 접속부를 포함한다. 다른 네트워크(151), 예컨대 전화기(107), 스피커(132), 마이크로폰(133) 및/또는 ISDN 라인(123)을 통한 재래식 전화 시스템(POTS;a plain old telephone system)(122)에 대해 접속이 행하여 질 수 있다. 그 밖의 다른 주변장치(130) 역시 공지의 인터페이스를 이용하여 독립적으로 네트워크(150, 151)에 접속될 수 있다.

컴퓨터의 CPU(110C)는 제어 프로세스와 라이브러리(libraries)(125)를 포함하는 소프트웨어 프로그램을 실행하는데, 몇몇 바람직한 실시예에서는 소프트웨어 프로그램이 하나 이상의 협력 프로세스(collaboration processes)(170)를 포함한다. 제어 프로세스(125)는 하나 이상의 내장 제어 기능/프로그램(620)과, 하나 이상의 제어 메카니즘(640)으로 이루어진다. (이하, 도 5, 6-6D를 참조하기로 한다.) 내장 제어 프로그램/기능(620)은 내용 특정 프로세스(content specific processes)(예를들면, 은행 업무, 차 임대 업무, 상품 구매 등)로서, 이 프로세스는 비내용 특정 제어 메카니즘(non-content specific control mechanisms)(640)을 이용하여, 각각의 입력/출력 장치(또는 이 입력/출력 장치의 서브세트(subsets))(130)와 관련된 로컬 애플리케이션 프로그램 인터페이스(680)(APIs)를 제어한다. 따라서, 입력/출력 장치(130)는 애플리케이션의 내용에 따라 특정된 방식으로 제어된다. 다른 실시예에서, 제어 메카니즘은 네트워크(150)로부터 컴퓨터(110)에 동적으로 로딩될 수 있다.

협력 프로세스(170)는, API와, 키오스크(100)로부터 협력 세션을 설정하는 기능을 수행하는 그 밖의 다른 프로그램을 포함한다. 이 협력 프로세스는, 1996년 9월 27일 핀(Fin) 등에 의해 출원된 발명의 명칭이 "Internet Web Page Sharing"인 미국 특허 출원 08/722,287에 개시되어 있으며, 이는 본 명세서에 참조로 인용된다(출원 번호가 97307536.0이고 공개 번호가 833260인 EP 참조). 컴퓨터는 또한 예컨대 네스케이프 내비게이터(Netscape Navigator) 브라우저 같은 웹 브라우저 프로그램(160)을 포함하는 네트워크(150)와 대화하는데 필요한 프로그램을 실행한다. (Netscape Navigator는 네스케이프 통신사의 상표이다.)

도 2는 본 발명의 다른 실시예를 나타내는 블럭도로서, 폐쇄된 공간 또는 부분적으로 폐쇄된 공간(200) 내에 있는 키오스크(100)를 도시한다. 폐쇄된 공간(200)은 임의의 유형의 공간, 예를들면 방, 작은 칸막이 방, 또는 임의의 그 밖의 전용 영역 혹은 반 전용 영역일 수 있으며, 이 공간 내에 1인 이상의 사용자와 함께 키오스크(100)가 존재한다. 이 실시예에서, 컴퓨터(110)는 하나 이상의 공지된 환경 주변장치(environmental peripherals)(130)에 접속되는데, 컴퓨터(110)는 이 환경 주변장치(130)를 제어하여 사용자를 위해 공간(200) 내의 환경을 조성한다. 예를 들어, 이 환경 주변장치는 공간의 조명 기구(205)와, 공간(200) 내의 디스플레이 장치(210)를 포함할 수 있는데, 디스플레이 장치(210)는 부가적인 정보(예를들면, 판매 정보) 및/또는 환경 요소(예를들면, 풍경 또는 가상 세계의 변화무쌍한 디스플레이) 및/또는 공간(200)으로/으로부터의 보안 액세스(security access)(215)를 전달한다. 또한, (부분적으로) 폐쇄된 공간은 전술한 주변장치(130)와 유사한 그 밖의 다른 환경용 주변장치(130)로서, 예를들면 음향 장치, 화상 회의 장치 등을 가질 수 있다. 가상 세계의 예는 잘 알려져 있다.

시스템(100, 200)의 바람직한 실시예에서, 사용자는 (선택 기능을 이용하여) 애플리케이션(예를들면, 은행 업무)을 선택하는데, 이를 위해 키오스크가 구성될 것이며 브라우저(160)는 인터넷(일반적인 네트워크)(150) 상의 하나 이상의 웹 서버(195)와 대화하여 하나 이상의 구성 세트(175)를 페치(fetch)한다. 선택적으로, 데이터 통신은 키오스크(100, 200) 내의 서버(195)와 브라우저(160) 사이에서 시작된다. 그 후, 브라우저(160)에 의해 애플리케이션 파일(175)이 파일 단위로 실행되어, 1) 선택적으로, 각각의 애플리케이션과 함께 사용되는 하나 이상의 입력/출력 장치(예를들면, 터치 감응성 단말기(103) 또는 디스플레이 장치)(130)를 제어하는 구동 프로그램(로컬 API(680))을 호출하고, 2) 선택적으로, 예를 들어, 단말기/디스플레이(103) 상에 디스플레이될 일련의 웹 페이지같은, 일련의 입력/출력장치(130) 동작이 발생되도록 하고, 3) 선택적으로, 사용자 입력을 입력 장치(130)로부터 서버(195)로 전달하며, 4) 선택적으로, 사용자 입력에 따라 브라우저(160)가 또다른 실행을 행하기 위해 또다른 애플리케이션 파일(175)을 선택한다. 따라서, 사용자는 첫 번째 선택 기능을 사용하여, 키오스크를 첫 번째 선택된 특정 애플리케이션으로 재구성하는 첫 번째 애플리케이션(및 서버(195) 상의 그와 관련된 애플리케이션 파일(175))을 선택한다. 두 번째 애플리케이션을 선택함으로써, 키오스크가 두 번째 애플리케이션에 대해 다시 재구성되며, 이런 식으로 계속 진행된다. 임의의 추후 구성에 대한 선택 기능은 그 전단계 구성에서 사용자에게 제공될 수 있다.

애플리케이션은 이용(use)을 말하며, 특히 키오스크가 이 이용을 위해 구성되는 임의의 이용을 말한다. 예를 들면 애플리케이션은, 금융, 사업, 정보(뉴스, 광고), 통신(전자 메일, 웹 액세스, 화상 회의), 소매업, 마케팅, 서비스(예를들면, 행정 프로그램(government programs))분야에서의 이용(구성)을 포함한다. 애플리케이션 소유자는, 키오스크를 구성하여 애플리케이션을 제공하는 임의의 사람, 조직체, 또는 사업소이다. 예를들면, 은행 또는 뮤추얼 펀드(mutual fund)은 하나 이상의 금융 애플리케이션에 대해 키오스크를 구성할 것이다. 이들 금융 애플리케이션의 예로서, 사용자에게 금융 정보를 제공하는 것, 예금 계좌를 개설하는 것, 현금을 지급하는 것, 어음을 지불하는 것, 대출 신청, 예금 및 관리자의 도움을 구하는 것을 들 수 있다. 서비스 소유자의 예로서, 차 임대/리스(car rental/lease) 등을 제공하도록 키오스크를 구성하는 차 임대 회사를 들 수 있다.

다른 바람직한 실시예에서, 키오스크(100, 200)는, 사용자가 아니라 서버(195)에 의해 재구성된다. 예를 들어, 키오스크는 쇼핑 몰과 같은 공공 장소에 위치될 수 있다. 브라우저는, 하나 이상의 서버(195)로부터 혹은, 네트워크(150) 상에 위치되는 디폴트 또는 프록시 서버(proxy server)(195A)로부터 구성 세트(애플리케이션 파일)(175)를 초기에 혹은 주기적으로 키오스크(100)로 페치하도록(혹은 서버가 이를 "푸시(push)"하도록) 만들어질 수 있다. 따라서, 시스템 설계자는 서버(195)의 원격 위치로부터 키오스크의 구성을 제어할 수 있다. 예로서, 쇼핑 몰 내의 키오스크는, 쇼핑 몰의 지도를 디스플레이하고, 배경 음악을 연주하고, 안내 멘트를 하거나 혹은 날씨를 안내하고, 또는 뉴스 혹은 주식 시세와 같은 그 밖의 다른 일반적인 정보를 제공하도록 초기에 구성될 수 있다. 구성 세트(175)는 하나 이상의 입력/출력 장치(130)가 선택 기능(105A), 예를들면 터치 스크린, 아이콘, 하이퍼텍스트 링크, 그래픽 사용자 인터페이스 상의 소프트 버튼, 하드 와이어드 버튼(hard-wired button), 원격 센서(예를들면 무선 주파수 식별 태그), 또는 화상 회의 시스템을 위한 음성 활성화된 메시지 같은 기능을 갖거나 혹은 이와 같이 되도록 조작한다. 선택 기능(105A)은, 사용자가 선택을 행함으로써 키오스크가 사용자 애플리케이션으로 재구성되도록 해주는 기능이다. 이들 선택 기능(105A)으로 인해 사용자는 키오스크(100/200)를 재구성하고/하거나 서버(195)가 키오스크에게 제공하도록 요구하는 그 밖의 다른 정보에 액세스할 수 있게 된다.

선택 기능(105A) 및/또는 디스플레이되는 그 밖의 다른 정보는 또한 키오스크의 소유자/작동자의 수입원(source of revenue)일 수 있다. 예를들면, 키오스크에 의해 제공되는 통지 사항은 유료 광고일 수 있다. 애플리케이션 제공자(예를들면, 은행, 뮤추얼 펀드, 저당권 설정 회사, 대금업자(lenders), (주식, 부동산) 브로커(brokers), 임대 사업(차, 장비 임대 사업), 서비스 제공자 및 소매업자)는 키오스크(100/200) 상의 선택 기능(105A)을 갖기 위해 요금을 지불할 것인데, 이 선택 기능(105A)은 키오스크를 그러한 애플리케이션에 대해 구성하기 위해 사용자가 선택하는 것이다. 요금은, 키오스크의 위치, 키오스크 상의 선택 기능/정보의 위치(예를들면, 그래픽 사용자 인터페이스), 선택 기능(105A)의 크기, 선택 기능(105A)/정보가 키오스크에 의해 제공되는 시간 및 지속 시간 등에 근거하여 산정될 수 있다. 선택 기능(105A)/정보는 서로 다른 부류의 고객/클라이언트를 목표로하기 위해 상이한 시점에서 변화되거나 혹은 주기적으로 디스플레이될 수 있다. 예를들어, 그랜드 센트럴 스테이션(Grand Central Station) 내의 키오스크가 출퇴근시간에는 출퇴근 정보를 디스플레이하고, 점심 시간 바로 전에는 식당 예약을 위한 선택 기능(105A)을 갖도록 재구성될 수 있을 것이다.

키오스크(100/200)는 사용자에게 특정되도록 서버(195)를 통해 애플리케이션 제공자에 의해 재구성될 수 있다. 예를 들어, 여행사는 스미스(Smith)씨에 대한 사용자 프로파일을 가질 수도 있다. 스미스씨는 공공 장소 또는 자신의 작업장에 있는 키오스크(100/200) 상에서 선택 기능(105A)을 선택한다. 일단 키오스크가 여행사의 애플리케이션에 대해 재구성되면, (애플리케이션 파일(175)중 하나에 의해 지시되는 것처럼) 키오스크는 입력/출력 장치(130)중 하나를 이용하여 예를 들어 PIN 코드를 입력하거나 신용 카드를 긁도록(swiping) 함으로써 스미스씨로부터 개인 정보를 요구할 수 있다. 그 후, 키오스크(100/200)에 의해 스미스씨의 개인 정보가 서버(195)로 전달되어 스미스씨에 관한 프로파일이 액세스된다. 프로파일 내의 정보를 이용하여, 하나 이상의 애플리케이션 파일(175)이 서버(195)에 의해 전송되어 스미스씨에 대해 구체적으로 키오스크가 재구성된다. 예를 들어, 중앙 아메리카에 대한 휴가 패키지(package) 만이 키오스크 상에 제공될 수도 있다. 다른 실시예로서, 하나 이상의 애플리케이션 파일(175)에 의해 사용자는 GUI(이하, 300)를 편성할 수 있다.

키오스크(100/200)의 그 밖의 다른 바람직한 구성에서, 1인 이상의 키오스크 사용자와 애플리케이션 제공자의 1인 이상의 관리자 사이에 협력 세션이 설정된다. 협력 세션은, 키오스크 상에 존재하거나 혹은 서버(195)에 의해 애플리케이션 파일(175)로서 제공되는 협력 프로세스(170)에 의해 설정된다(전술한 핀 등에 의한 특허 출원 참조).

키오스크(100, 200)의 또다른 바람직한 구성에서, 서버(195)는, 키오스크를 모니터링하거나 유지보수하는데 사용되는 애플리케이션 파일(175)을 키오스크에 제공한다. 예를 들어, 이들 실시예에서 하나 이상의 내장 제어 프로그램(620)은, 예를 들어 "데드 맨(dead man)" 타이머 상태, 에러 체크 프로토콜 등을 이용하여 하나 이상의 입력/출력 장치(130)의 동작 상태를 모니터링함으로써 어떤 입력/출력 장치가 동작가능한 지를 판단한다. 이 정보는 서버(195)에게 도로 전달된다. 주어진 키오스크 내에서 어떤 입력/출력 장치(130)가 인스톨되는지 혹은 동작가능한 지를 질문하는 데에는 그 밖의 다른 애플리케이션 파일(175)이 사용된다. 이러한방식으로 서버(195)는, 인스톨되거나 혹은 동작가능한 입력/출력 장치(130)는 인에이블시키고, 인스톨되지 않거나 장해가 있는 장치는 인에이블(구성)시키지 않기 위해, 어떤 애플리케이션 파일(175)을 키오스크로 보내야 할지를 판단한다. 따라서, 입력/출력 장치(130)의 임의의 일반적인 결합을 포함하는 키오스크가 서버로부터 멀리 떨어져 인스톨될 수 있으며, 서버는 올바르고 동작가능한 애플리케이션 파일을 제공하여 임의의 주어진 애플리케이션용으로 키오스크를 동작 가능하게 할 것이다. 애플리케이션 파일은 또한, 장치를 작동하는 방법을 결정하기 위해 하나 이상의 입력/출력 장치로부터 정보를 획득하는 데에 사용될 수 있다.

도 3은 키오스크(100/200)의 스크린/디스플레이(105) 상에 나타나는 그래픽 사용자 인터페이스(GUI)(300)의 예를 도시한 도면이다. GUI(300)는 선택 기능(105A)을 통해 키오스크의 사용자에게 메인 액세스 인터페이스를 제공한다. 선택 기능(105A)의 예로서, 은행(301), 보험 서비스(302), 일반적인 소프트 버튼(303) 및 피자 레스토랑(304)에 대한 애플리케이션을 나타내는 아이콘 이미지(301-304)를 들 수 있다. GUI(300)는 또한, 하나 이상의 선택 사항(대표적으로, 325)을 갖는 메뉴(320)의 형태로 선택 기능(105A)을 디스플레이할 수 있다. 선택 기능(105A)의 다른 예로서, GUI(300) 및/또는 메뉴(320)의 일부일 수 있는 하이퍼링크(hyperlinks)(350)를 들 수 있다. GUI(300)의 그 밖의 다른 영역(340)은 정보 및/또는 다른 데이터를 입력하는데 사용될 수 있다. 이들 정보 필드(340)를 이용하여, GUI는 세금 고지서, 대출 신청서, 저당 설정 신청서, 예금 전표(deposit slip) 등과 같은 서식(370)을 나타낼 수 있다. GUI(300)는 잘 알려진 기법을 이용하여 브라우저(160)에 의해 웹 페이지로서 디스플레이될 수 있다. 웹 페이지는, 다른 입력/출력 장치(130)를 통해 사용자에게 보여지는 멀티미디어(음향, 비디오) 특성을 가질 수 있다.

도 4는 사용자가 사용자 인터페이스를 통해 대화하여 선택 기능(105A)을 선택하는 방법의 메카니즘을 도시한 도면으로서, 선택 기능(105A)은 대응하는 구성 세트(175)를 서버(195)로부터 클라이언트(키오스크(100, 200))로 다운로드하여서 소정의 특정 기능을 불러오고 주변장치(130)(예를들면, 107, 109, 111, 113, 114 등)의 특정 서브세트(451)를 제어한다. 주변장치(130)는 자신의 로컬 API(440)(또는 이들 로컬 API(440)의 서브세트(441))를 통해 제어된다. 로컬 API(440)는 직접적으로 하나 이상의 주변장치(130)를 제어하는 소프트웨어 기능 인터페이스이다. 예를들면, 카드 판독기(130)에 대한 로컬 API(440)는 초기화, 개시, 카드로부터 데이터 판독, 카드 배출, 기능을 턴 오프하는 것을 포함할 수 있다.

(키오스크 구성의) 선택은 선택 기능(105A)에 의해 행해진다. 선택 기능(105A)의 예는 다음과 같다.

a) 사용자가 스크린 상의 이미지 아이콘이나 또는 버튼과 같은 다른 선택 장치를 확실하게 터칭(touching)하는 것과,

b) 현재 실행중인 프로그램이 사용자의 행위에 근거하여 선택을 불러올 필요가 있는지를 판단하는 것, 예를 들면 사용자가 한 행(row)에서 동일한 실수를 2번 이상 행할 경우 도움말 프로그램(help program)을 불러오는 것과,

c) 현재 실행중인 프로그램내의 로직이 다음 선택(키오스크 구성)을 결정하는 것. 예를들어, 일단 사용자가 저당권 사전 자격 애플리케이션을 완료하고 은행이 이를 승인하면, 현재 애플리케이션은 사용자에게 부동산 정보를 필요로 하는지를 질문할 수 있다. 사용자가 "예"로 응답할 경우, 키오스크 구성은 부동산 중개업자 애플리케이션의 구성으로 변경된다.

일 실시예에서, 선택(105A)이 행해지면, 브라우저(160)는 그 선택 기능(105A)에 대응하는 첫 번째 애플리케이션 파일(175)(파일(500))에 대한 요구를 네트워크 인터페이스(155)를 통해 HTTP로 서버(195)에게 전송한다. (애플리케이션 파일/구성 세트(175)내의 파일(500)을 나타내고 있는 도 5를 또한 참조하기 바란다.) 그 후 서버(195)는 애플리케이션 파일(175)을 브라우저(160)에게 서브한다. 애플리케이션 파일(500)이 브라우저(160)에 도달한 후, 파일(500)의 HTML 내용이 라인 단위로 실행된다. 다음의 애플리케이션 파일(500)이 브라우저가 실행하고 있는 현재의 애플리케이션 파일(500)과 연관될 경우(예를 들어 하이퍼링크될 경우), 이 다음의 애플리케이션 파일(500)도 또한 브라우저에게 전송된다. 이러한 방식으로, 브라우저(160)는 각 파일(500)을 라인 단위로 실행하고, 구성 세트(175) 내의 HTML 텍스트의 시퀀스를 구성 세트(175) 단위로 실행한다. 이러한 방식으로 애플리케이션 파일/구성 세트(175)의 파일들(500)을 실행함으로써, 로컬 API(440)(장치(130)와 관련됨) 또는 로컬 API의 서브세트가 호출되어, 피선택 장치의 서브세트(451)를 제어하고 키오스크(100, 200)가 재구성된다. 애플리케이션 파일/파일들(175, 500) 및/또는 사용자 조작들의 각각의 로직은, 어떤 애플리케이션 파일/파일들(175, 500)이 실행되는지, 혹은 몇몇의 애플리케이션 파일이 실행되는지의 여부를 변경시킬 수 있다.

애플리케이션 파일(175)을 실행시킴으로써, 브라우저(160)는 하나 이상의 장치(130)를 선택하고 제어한다. 키오스크의 구성은, 애플리케이션 파일의 실행동안 선택된 장치(예를들면, 장치 서브세트(451))와, 이 장치 서브세트(451)가 제어되는 방법에 의해 정의된다. 예를들면, 은행 업무 구성에서, 애플리케이션 파일(175)의 실행에 의해 API(441)의 서브세트가 호출되고, 예를들어 카드 판독기(111) 및 프린터(109)(장치 서브세트(451))가 선택 및 제어되어, 각각 은행 카드를 판독하고 거래 기록을 프린트 출력한다. 동일한 은행 업무 구성에서, 하나 이상의 애플리케이션 파일 (및/또는 애플리케이션 파일의 라인)의 실행에 의해 장치(130)가 선택되거나 제어되는 것은 아니지만, 데이터를 저장하고 데이터 또는 메시지를 서버(195)에게 도로 전송하는 등의 조치를 포함하는 그 밖의 다른 조치를 유발시킨다. 다른 구성에서, 예를들면 피자를 주문하는 구성에서, 애플리케이션 파일의 실행에 의해 상이한 서브세트의 API(441)가 호출되어 동일한 장치 서브세트(451)(즉, 카드 판독기(111) 및 프린터(109))가 선택 및 제어됨으로써, 각각 신용 카드를 판독하고 신용 카드로 요금을 부과하고 선택된 피자 토핑(pizza toppings)을 나타내는 구입 영수증을 프린트 출력한다.

몇몇 구성에서는, 애플리케이션 파일(175)의 실행에 의해 하나 이상의 장치(130)가 선택되지 않음에 유의한다. 이들 경우, 디폴트 장치가 사용된다. 예를들면, 텍스트의 라인이 디스플레이되도록 하는 파일(500)의 라인이 디폴트로서 디스플레이(103)로 향하게 될 것이다.

브라우저(160)는, 다른 로컬 프로그램 및/또는 라이브러리를 사용하여 애플리케이션 파일의 실행과 대화하는 특정 세트의 실행가능한 로컬 모듈에 액세스할 수 있음에 유의하기 바란다(도 6 참조).

도 5는, 하나 이상의 HTML 파일(500)과, 적어도 하나의 내장 제어 프로그램(620)을 포함하는 관련 하이퍼텍스트 구성 요소를 포함하는 일련의 애플리케이션 파일들(구성 세트)(175)을 나타내는 블럭도이다. 모든 웹 기반 애플리케이션 파일(175)은 적어도 하나의 내장 제어 프로그램(620)을 갖는 HTML 기반 파일이다. 이 애플리케이션 파일들(175)은 HTML을 기반으로 하거나 기반으로 하지 않을 수도 있는 그 밖의 다른 하이퍼텍스트 구성 요소를 선택적으로 포함한다. 전형적으로, HTML 파일은 텍스트(525), 이미지 또는 그래픽(528), 애니메이션(이미지(528), 애플릿(505), 스크립트(515), 또는 그 밖의 다른 내장 구성 요소(520)로서 구현됨), 음향(하나의 내장 구성 요소(520)임), 비디오(하나의 내장 구성 요소(520)임)와 그 밖의 다른 내장 프로그램(520)에 대해 표준 HTML(예를들면 HTML 3.0) 태그를 포함한다. 이들 태그는 널리 알려진 것이다. 바람직한 일 실시예에서, 브라우저(160)는 넷스케이프 내비게이터 v3.0이다. 내장 프로그램은 자바스크립트(JavaScript)를 이용하거나 자바 애플릿를 이용해 구현될 수 있고, 혹은 플러그-인(plug-ins)을 사용하는 그 밖의 다른 임의의 내장 프로그램을 이용하여 구현될 수도 있다(자바(Java)는 선 마이크로시스템사(Sun Microsystems Inc.)의 상표이다). 도 5에 도시한 바와 같이, HTML 파일(500)은 태그(505)를 사용하여 자바 애플릿을 내장하며, 태그(515)를 사용하여 자바스크립트 기능을 내장하고, 태그(520)를 사용하여 브라우저의 플러그-인 기능을 불러올 그 밖의 다른 임의의 프로그램을 내장한다. 표준 HTML 태그에 관한 더 많은 정보는 "네스케이프 HTML 3.0 소스 북(Netscape HTML 3.0 Source Book)"에 나타나 있으며, 이는 본 명세서에 참조로 인용된다. 이들 몇몇 내장 프로그램(520)은 내장 제어 기능/프로그램(620)이다.

도 6은, 키오스크(100)를 구성하는 전형적인 애플리케이션의 내장 제어 프로그램(620)을 실행하는데 관련되는 시스템의 구성 요소를 나타내는 블럭도이다.

브라우저(160)에서, HTML 파일 내의 HTML 태그를 해석하거나 혹은 인식하는 인터프리터(610)가 기능적으로 존재한다. 인터프리터(610)는 HTML 태그 실행기(611)를 호출하여, 태그의 유형과 태그의 내용에 따라 HTML 태그 각각에 대한 기능을 실행한다. 이 실행에서, 로컬 키오스크 프로그램(로컬 주변장치 API(440)를 포함)에 대한 API 호출(680)이 발생하지 않을 경우, 브라우저는 필요에 따라 표준 기능의 라이브러리를 이용하여(617), HTML 태그 각각을 실행한다(615). 이들 비 API 제어 기능(non-API-control functions)(615)의 예로서, 텍스트를 디스플레이하는 것, 이미지를 디스플레이하는 것 등을 들 수 있다. 이들은 널리 알려진 것이며 종래 기술의 브라우저에 존재하는 것이다.

그러나, 실행기(611)가 로컬 키오스크 API(680)중 하나를 호출하는 내장 제어 기능(620)을 만날 경우, 실행기(611)는 브라우저(160)내의 보안 관리기(625)를 불러내어 API 호출이 허용되는지 여부를 판단한다. 이하 더욱 상세히 기술하는 바와 같이, 키오스크 제어 메카니즘(640) 또는 이 메카니즘(640A)의 일부는 브라우저가 위치되는 디렉토리의 서브디렉토리 내에 배치된다. 이렇게 함으로써, 실행기(611)가 내장 제어 기능(620)을 만날 때 보안 관리기(625)는 제어 메카니즘(640)을 찾을 것이며(640A 이하), API 제어 기능(621)은 제어 메카니즘(640/640A)을 브라우저 프로세스(160)에 로드할 것이다. 예를들면, 이들 내장 제어 기능(620)은, 하나 이상의 로컬 API 기능(680/440)(즉, 선택된 API(441)의 서브세트)을 호출하여 주어진 장치(451)의 서브세트를 동작시키는 애플릿을 포함할 수 있다. 예를들면, 장치가 카드 판독기일 경우, 내장 제어 기능(620)은 제어 메카니즘(640)을 이용해 적절한 API(440)를 호출하여 카드 판독기 장치를 열고 카드로부터 데이터를 판독하고 카드를 배출하고 카드 판독기 장치를 닫을 수도 있다.

공지된 브라우저(160)는 로컬 API(680)를 실행시키기 위해 네트워크(150)로부터 내장 제어 기능(620)을 실행하지 않음에 유의한다. 사실상, 이들 브라우저는, 잘 알려진 네트워크 보안 이유로 인해 이들 API 제어 기능의 실행을 특히 방지한다. 예를들면, 애플리케이션 파일(175)이 네트워크를 통과하는 동안 변화될 경우, 애플리케이션 파일 내의 손상된 제어 기능의 실행으로 인해 클라이언트 머신, 즉 키오스크(100, 200) 측에 예상치 못한 좋지 않은 결과가 발생될 수 있다.

자바는 예컨대 바이트-코드 전송 및 검증, 가상 머신에 의한 에러 체크 등과 같은 다양한 특정 수단을 이용해 네트워크 보안 문제를 해결하도록 설계되어 있다. 또한, 자바가 웹 기반 애플리케이션에서 애플릿으로서 사용될 때, 즉 HTML 파일 내에 내장될 때, 브라우저는 자바 애플릿이 클라이언트 머신 상의 임의의 로컬 자바 프로그램(브라우저 내에 구축되는 표준 자바 라이브러리 내에 있는 것은 제외)에 액세스하는 것을 통상적으로 엄격하게 방지한다. 이에 대한 이유는 단순히, 애플릿이 제어되지 않는 환경으로부터 온 것(즉, 네트워크를 통해 임의의 서버로부터 온 것)이기 때문에 이 애플릿이 클라이언트 머신에 행할 수 있는 임의의 손상을 방지하기 위한 것이다.

"Java Now"라는 책(잠사(Jamsa) 출판사의 크리스 잠사(Kris Jamsa)의 저서, 1996, ISBN 1-884133-30-4, p4)에 기술된 바와 같이, “보안 문제를 다루기 위해, 자바 개발자는, 프로그래머가 자바 애플릿을 이용하여 컴퓨터 바이러스를 개발하지 않도록 해야 하고 애플릿이 사용자의 시스템에 관한 정보(예를들면, 사용자의 시스템 상의 파일)를 서버로 다시 전송하지 않도록 해야 한다. 예를들어, 경쟁자의 웹 사이트를 검색하는 것도 싫겠지만 경쟁자의 자바 애플릿이 나의 하드 디스켓을 검색하는 것은 더욱 싫을 것이다. 이러한 보안성을 제공하기 위해, 자바 개발자는 애플릿이 수행할 수 있는 동작을 제한할 것을 선택하였다. 예를들면, 자바 애플릿은 사용자의 시스템 상에 파일을 판독하거나 기록할 수 없다. 이러한 방식으로, 애플릿은 사용자의 디스크 상에 바이러스를 저장하거나 사용자의 디스크 상에 저장된 정보를 판독할 수 없게 된다.” 또한, “자바는 프로그래머가 독립형 프로그램(stand alone program)을 생성할 수 있도록 해준다. 자바 독립형 프로그램은 프로그래머가 C++을 이용하여 생성할 수 있는 프로그램과 유사하다. 이러한 독립형 프로그램은 파일을 판독 및 기록하고, 자바가 애플릿이 수행하지 못하도록 제한하는 동작을 수행할 수 있다. 반면에, 자바 애플릿은 브라우저 내에서만 실행된다...”라고 기술되어 있다. 이는, 자바 애플릿이 의도한 바대로 브라우저 프로세스(160) 이외의 기능을 동작시키지 않음을 의미한다.

표준 브라우저의 동작이 행해지는 동안, 브라우저의 보안 관리기(625)는 이들이 보안 규칙을 위반하는 지를 감시한다. 애플릿이, 표준 자바 라이브러리 내에 있지 않은 프로그램에 대해 액세스를 요구하는 것으로 알려질 경우, 브라우저는 단순히 보안 규칙 위반 에러를 보고하고 애플릿의 실행을 중지시킨다.

일 실시예에서, 키오스크 고유 제어 메카니즘(640)의 일부(640A)는 브라우저(160)에 부가되고 키오스크 고유 제어 메카니즘(640)의 다른 부분(640B)은 애플리케이션 프로그래밍 인터페이스(API)(680)(440을 포함함)에 부가되어 애플리케이션 파일(1750)이 키오스크를 구성할 수 있도록 한다. 따라서, 키오스크 고유 제어 메카니즘(640)은 두 부분으로 나누어지는데, 하나는 브라우저 메카니즘(640A)이며, 다른 하나는 API 메카니즘(640B)이다. 이 실시예에서, 브라우저 메카니즘(640A) 및 API 메카니즘(640B)은 인터프로세스 통신(interprocess communication:IPC)(640I)을 통해 통신한다. IPC(640I) 인터페이스는, 브라우저 메카니즘(640A) 및 API 메카니즘(640B)이 직접적인 기능 호출 대신에 메시지 전달을 이용하여 통신할 수 있도록 해준다. (IPC는 널리 알려진 것이며, 하나의 예로서, 윈도우즈 오퍼레이팅 시스템 내의 동적 데이터 교환(Dynamic Data Exchange:DDE)의 사용을 들 수 있는데, 윈도우즈(Windows)는 마이크로소프트사의 상표이다.)

브라우저 메카니즘(640A)은 브라우저 서브디렉토리 내에 위치되어서, 임의의 애플리케이션 파일(175) 내의 임의의 API 제어 기능(620)이 브라우저(160) 내의 인터프리터(610)에 의해 인식되도록 한다. API 메카니즘(640B)은, 브라우저 메카니즘(640A)으로부터 메시지를 수신하며, 그 메시지에 따라 장치 API(440)를 포함하는 여러 기능을 독립적으로 제어한다. 이러한 방식으로, 브라우저로부터의 애플릿이 인에이블되어 하나 이상의 장치 및 로컬 기능을 제어할 수 있게 되지만, 브라우저 메카니즘(640A)을 갖는 것에 한해서이다. 따라서, 키오스크 내의 그 밖의 다른 기능은 네트워크를 통해 애플리케이션 파일(175)의 액세스로부터 여전히 안전한 채로 유지된다. 따라서, 키오스크는 구성가능하면서 안전하다. 또한, API 메카니즘(640B)은 브라우저에 독립적으로 장치 API(440)를 작동시키기 때문에, API 메카니즘(640B)으로 전달되는 임의의 장치 제어 기능(주어진 장치를 제어하는 데 사용되는 API 제어 기능(620)의 서브세트)은, 애플리케이션 파일이 추후에 브라우저(160)에서 드롭(drop)되거나 변경될지라도 장치(451)의 서브세트 상에서 수행될 것이다. 이로 인해, 장치 동작이 지속적으로 유지될 수 있는데, 즉 API 기능(640, 440)이 일단 개시되면, 그 기능은, 애플리케이션 파일(175)이 브라우저(160)에 의해 변경/드롭되는지 여부에 관계없이 완료될 수 있다. 또한 이러한 실행 지속성으로 인해 다수의 사용자가 키오스크와 더 효율적으로 대화할 수 있게 된다. 예를들면, 애플리케이션 파일(175)은 카드 발행기에게 새로운 카드를 발행할 것을 지시할 수 있다. 그러면, 카드 발행 장치가 데이터를 마그네틱 스트라이프에 기입하고 새로운 카드를 엠보싱 처리(embossing)하는 동안, 사용자/브라우저는 다른 애플리케이션 파일로 이동할 수 있다.

브라우저 메카니즘(640A)은, 1) 브라우저 자신의 표준 디렉토리/라이브러리 내에 위치되며, 2) 하나 이상의 로컬 API 기능에 관한 메시지(예를들면, 기능 네임 및 관련 파라미터)를 전달하는 네임 서버 메카니즘을 이용해 메시지를 전달하거나(도 6a 및 6c와 그에 관한 설명 참조) 또는 로컬 API 기능을 직접 불러내는 것(도 6b 및 6d와 그에 관한 설명 참조)에 의해, 애플리케이션 파일(175)이 하나 이상의 로컬 API(680)를 불러낼 수 있는 구조를 갖는다.

하나의 바람직한 실시예에서, 브라우저 메카니즘(640A)은 애플리케이션 파일(500)에게 알려진 자바 API(종종 "자바 랩퍼(Java wrapper)"로 불리움)를 포함하고, 또한 (예를들면, 인터프로세스 통신 또는 네임 서버를 이용하여) 통신을 하거나 또는 로컬 API(680)를 직접 호출하기 위해 원시 언어(native language)(예를들면, C++)로 프로그램된 기능들을 포함한다.

API 메카니즘(640B)은, 1) 다양한 로컬 기능 모듈(예를들면, 브라우저 제어 모듈, 협력 기능 모듈, 장치 제어 모듈 및 시스템 모니터링 모듈 등)을 직접 액세스하고, 2) 네임 서버 메카니즘을 이용하거나 관련 로컬 기능 모듈을 직접 호출함으로써 하나 이상의 API 기능들(680)의 세트를 불러올 수 있는 구조를 가지며, 3) API(640A)와의 메시지 기반 통신을 가능하게 해주는 IPC를 갖는다. (API 기능(680)은 특별히 키오스크 내의 임의의 주어진 장치 또는 기능을 제어하도록 설계되며, 애플리케이션 파일(175)에 의해 액세스될 수도 있고 액세스되지 않을 수도 있음에 유의한다.)

이 키오스크 제어 메카니즘을 이용하는 하나의 애플리케이션의 예로서, 애플리케이션이 키오스크 구성 방법을 결정하기 전에 시스템 셋업 및 상태를 문의하는것을 들 수 있다. 애플리케이션 파일(175)에서, 애플릿 CallAPI.class는 API 기능(640) "query_status"를 불러오는 데 사용될 수 있다. 예를들면 다음과 같다.

그리고, 이 애플릿은 HTML 파일 내에 다음과 같이 내장된다.

이 애플릿이 브라우저에 의해 실행될 때, 우선 kioskAppInterface로 명명된 클래스를 사례화(instantiation)한다. 이 파일 및 관련 DLL은 브라우저 표준 라이브러리에 위치된다. 그 후, 이는 send_APImessage()로 명명된 kioskAppInterface 클래스(640A)의 메쏘드(method)를 이용하여 API 메시지 "query_status"(640A)를 전송한다. 이 매쏘드는 인터프로세스 통신 기능(640I)을 불러내어, 이 메시지를 API 메카니즘(640B)으로 보낸다. 그 후, API 메카니즘(640B)은 관련 로컬 API 기능(680)을 불러내어 시스템 상태 데이터를 얻고 인터프로세스 통신 기능(640I)을 통해 이 데이터를 (640A)로 되돌려 보낸다. 애플릿은 커맨드 "status"와 함께 매쏘드 get_APImessage()를 이용하여 데이터를 얻는데, 이 데이터는 (640B)로부터 다시 보내져온 것이며, 이 데이터는 sysStatus로 명명된 클래스내의 데이터 구조에 저장된다.

(640A) 및 (640B) 사이에 전달되는 API 메시지는 네임 서버 기능 메카니즘을 사용할 수도 있다(이하 도 6a 참조). 일반적으로, 메시지가 (640B)에 의해 획득될 때, (640B 내의) 네임 서버 기능은 그 메시지를 분석하여, 대응하는 로컬 기능 API(680)를 호출한다. 이 예에서는, 시스템 감시자 기능 API를 호출하여 이하와 같이 예시될 수 있는 시스템 상태 데이터를 얻는다.

(640B)의 네임 서버 기능에서,

전술한 바와 같이 "sysStatus" 클래스 데이터 구조에서 획득되는 데이터의 예를 여기에 나타낸다.

이 메시지에 따르면, 키오스크 상에는 다섯 개의 장치가 존재하며, 카드를 필요로 하는 카드 발행기를 제외하고는 모두 작업하고 있는 것으로 나타난다.

키오스크의 현재 상태 데이터에 따르면, 애플리케이션 파일(175)은 카드 발행기의 사용을 피하면서 레이저 프린터, 영수증 프린터 및 카드 판독기(장치 서브세트(451))를 사용하도록 선택할 수 있는데, 그 이유는 상태 데이터에 나타난 바와 같이 카드 발행기에게 공급되는 카드가 없기 때문이다(이러한 환경에서, 카드는 다른 수단에 의해 생성되어 키오스크 사용자에게 메일링(mailing)될 수도 있음).

몇몇 바람직한 실시예에서, 이와 같은 기법은, 어떤 장치가 키오스크 상에 제공될 것이지, 그리고 이들 장치가 적절하게 기능하는지 여부를 판단하는데 사용된다. 이러한 방식으로, 서버는 특정 애플리케이션 파일(175)을 제공하여, 키오스크가 제공하는 장치 및/또는 동작가능한 장치에 근거하여 키오스크를 구성할 수 있게 된다. 따라서, 각 애플리케이션 구성에 대해 서버측에서 애플리케이션 파일을 적절하게 선택함으로써 임의의 수의 서로 다른 키오스크 설계 및/또는 동작가능한 상황이 구성될 수 있다. 예를들면, 은행 업무 애플리케이션에서, 레이저 프린터 제어를 갖는 애플리케이션 파일(175)(파일(500))은 레이저 프린터를 구비한 키오스크로 보내져서, 고품질의 은행 명세서(statement)를 프린트하고, 반면에 영수증 프린터 제어를 갖는 애플리케이션 파일(175)(파일(500))은 동일한 작업(은행 명세서)과 관련한 영수증 프린터(이용가능하고 동작가능함)를 갖는 키오스크에 전송될 것이다. 이러한 방식으로, 오동작하는 레이저 프린터를 갖는 키오스크 또는 레이저 프린터가 없는 저렴한 키오스크도 여전히 은행 업무 애플리케이션에 대해 적절하게 구성될 수 있다.

다른 실시예에서, 애플리케이션 파일상에 요구를 전송함으로써 하나 이상의 서버에 의해 상태 정보가 요구될 수 있다. 이 정보는, 어떤 키오스크 및/또는 이들 키오스크 상의 장치가 서비스를 필요로 하는 지를 판단하는 데 사용될 수 있다. 예를 들면, 필요할 경우 서비스 대행자가 파견되어 카드 발행기에 카드를 부가할 수 있다.

그 밖의 다른 실시예에서, 상태 정보는 키오스크 및/또는 장치의 서비스 내력(service history)에 이용하기 위해 요구될 수 있다. 또한, 그 밖의 다른 마케팅 정보도 획득될 수 있는데, 예를들면 특정 위치에서는 어떤 부류의 고객에 의해 어떤 구성이 가장 많이 요구되는지에 관한 정보를 획득할 수 있다.

바람직한 일 실시예에서, 키오스크는, 임의의 그 밖의 다른 애플리케이션의 백그라운드에서 가동되는 브라우저 윈도우(시스템 모니터링 애플리케이션 윈도우)를 구비할 수 있다. 이 시스템 모니터링 애플리케이션 윈도우는 하나 이상의 HTML 파일을 포함할 수 있는데, 이 하나 이상의 HTML 파일은 하나 이상의 서버와 통신하는 하나 이상의 애플릿을 포함한다. (서버와의 자바 애플릿 통신에 대한 메카니즘은 널리 알려져 있다.) 이 시스템 모니터링 애플리케이션 윈도우는, 키오스크가 파워 온 상태이고 키오스크가 계속해서 동작중일 때는 언제나 개시할 수 있다. 이러한 방식으로, 하나 이상의 서버는, 애플릿과의 통신을 통해 임의의 시간에 키오스크의 시스템 상태 정보를 얻을 수 있다.

본원 명세서에 개시한 방법에 의하면 다음이 실현 가능하다.

1) "씬 클라이언트(thin-client)" 키오스크； 키오스크 상에 사전에 인스톨될 필요가 있는 애플리케이션 특정 소프트웨어(application specific software)가 존재하지 않기 때문에, 키오스크는 비용면에서 효율적으로 구축되고 유지될 수 있다. 따라서, 하나의 애플리케이션(애플리케이션 파일(500))은 하나의 서버에 기록되고, 기록된 애플리케이션은 이 서버에 접속된 네트워크상의 다수의 "씬(thin)" 키오스크에 의해 사용될 수 있다. 네트워크 상의 임의의 "씬" 키오스크에 대해 애플리케이션 특정 소프트웨어가 설계되지 않아도 된다. 사실상, 네트워크는, 애플리케이션 특정 소프트웨어를 전혀 갖지 않는 하나 이상의 표준(따라서 더 저렴한) "씬" 키오스크로 구성될 수 있다. (예를들면, 키오스크 제작자는 임의의 애플리케이션과 관련하여 이 애플리케이션에 독립적인 하나 이상의 표준 키오스크를 사용할 수 있다.) 애플리케이션 파일(500)은 서버측에서 개발되고, 업그레이드되며/되거나 유지될 수 있으며, 키오스크 내의 임의의 프로그래밍을 변경하지 않으면서, 네트워크 상에서 하나 이상의 키오스크를 재구성하는데 사용될 수 있다. 이 "씬-클라이언트" 키오스크로 인해, 임의의 시간에 임의의 장소에서 일반적인 퍼블릭 액세스를 서비스하는 키오스크의 대량 배치가 가능하게 된다(예를들면, 인터넷 및/또는 전화망을 통해 통신할 수 있는 "키오스크 전화").

2) 키오스크의 재구성이 가능하기 때문에, 다양한 종류의 다수의 애플리케이션이 서버 상에서 개발되고 이 키오스크를 통해 전달될 수 있다. 따라서, 애플리케이션 제공자는 네트워크 상에 있는 모든 키오스크를 공유할 수 있다. 이들 애플리케이션은, 특정 시간 및/또는 특정 상황, 예를들면 사용자가 요구할 때 또는 임의의 주어진 환경 상태(비가 내리기 시작할 때의 우산 가게 광고)에서 키오스크 상에 제공될 수 있다.

3) 키오스크는 인터넷 및 웹 개방 표준 기법에 근거할 수 있기 때문에, 인터넷 및 월드 와이드 웹의 풍부한 정보, 풍부한 매체 및 풍부한 기술을 채용할 수 있다는 이점이 있다.

이하에 사용자가 이 키오스크(100)를 사용하는 방법의 몇몇 예(반드시 이에 한정되는 것은 아님)를 나타낸다.

1. 유휴 시간(idle time)에 키오스크 스크린은 여러 가지 동적인 이미지, 비디오 클립(video clips), 음향 및 그래픽 패턴과 텍스트를 보여준다. 이 스크린의 내용은 모두 HTML 파일(들)로부터 제어되며 HTML 파일(들)은 키오스크 요구 또는 서버 푸시(sever push)에 근거하여 갱신된다. 서비스 제공자는 서로 다른 종류의 "부동산(real estate)" 스크린과 이들을 보여주는 시간에 대해 상이한 가격을 책정할 수도 있다. 아침 및 저녁 출퇴근 시간에는 주로 헤드라인 뉴스 및 금융 시장 변화를 보여줄 수도 있으며, 반면에 점심 시간에는 많은 식당 광고를 보여줄 수도 있으며, 주말에는 백화점 세일 광고를 보여줄 수도 있다. 이 내용은 항상 스크린을 지나가는 사람에게 스크린을 터치하도록 유혹한다.

2. 사용자는 스크린을 보고 스크린을 검토하면서 이를 터치한다. 그러면 스크린은 즉시 다음 스크린으로 턴(turn)되어 애플리케이션의 카테고리를 나타내는 이미지 아이콘 및 텍스트의 어레이를 보여준다.

3. 사용자가 피자 주문 아이콘을 터치하면, 사용자가 피자의 종류를 선택할 수 있는 스크린이 나타난다. 이 스크린에서는 사용자에게 피자를 배달할 장소 및 시기를 요구할 것이며 사용자는 온-스크린(on-screen) 터치 키패드를 통해 정보를 줄 수 있다. HTML내의 내장 제어 프로그램(620)은 그 데이터를 포착한다. 그 후 스크린은 사용자에게 신용 카드를 삽입하여 요금을 승인받도록 요구할 것이다. 제어 프로그램은 카드 판독기를 열어서 신용 카드 정보를 포착할 것이다. 그 후, 제어 프로그램은 관련 키오스크 API 기능을 이용하여 키오스크 상의 통신 기능을 불러와서 신용 카드 회사(예를들면, 모뎀을 통해) 및 피자 가게(예를들면 팩스를 보냄으로써)에 액세스할 수 있다. 이들 기능이 완료된 후, 스크린은 고객에게 주문 정보를 확인할 것이다. 그 밖의 다른 일반적인 소매 거래는 이와 유사한 방식으로 행해질 수 있다.

4. 사용자는 또한 전화 아이콘을 터치하여 전화를 걸 수 있다. 전화 애플리케이션 HTML 파일은 전화 키패드로 스크린 상에 나타난다. 사용자가 번호를 입력하면, 내장 제어 프로그램은 관련 API 기능(640A)을 불러와서 전화를 걸기 시작할 것인데, 이 전화 걸기는, PSTN(Public Service Telephone Network)을 통하거나, 또는 ISDN(Integrated Service Digital Network)을 통하거나, 또는 키오스크의 네트워크 접속(122, 123, 150), 애플리케이션 파일(500) 및 사용자 선택(105A)에 따른 인터넷 기반 전화를 통한 통상적인 방법에 의해 행해질 수 있다. 전화가 연결되면, 사용자는 키오스크에 구비된 핸드셋 또는 스피커 폰을 사용할 수 있다(호텐셔스(Hortensius) 등에 의한 미국 특허 출원 번호 제 08/595,897호(1996, 2월 6일 출원)인 "Multipoint Simultaneous Voice and Data Services Using a Media Splitter Gateway Architecture"(유럽 특허 출원 제 789470 호에 대응)를 참조하며 이는 본 명세서에 참조로 인용됨).

다른 바람직한 실시예에서, 사용자는 애플리케이션을 공유하는 비디오 전화 또는 화상 회의 전화를 선택할 수 있다(단, 상대방이 동일한 시설을 갖고 있는 경우). 그 후, HTML 애플리케이션 내에 내장 제어 프로그램(620)은 관련 API 기능을 불러와서 키오스크 화상 회의 기능을 개시할 것이다. 사용자는 키오스크 상에 구비된 터치 스크린 및 전자 펜을 사용하여 대화를 용이하게 할 수 있다(전술한핀(Fin) 등의 "Internet Web Page Sharing" 특허 출원에서 인용함).

5. 사용자는 팩스 기능을 선택할 수도 있다. 스크린에서는 사용자에게 팩스 번호를 입력하고 신용 카드를 삽입하고 관련 서류를 적절한 장치(예를들면 서류 슬롯(document slot)) 내로 팩스되도록 놓여지게 하고 준비가 되면 스크린 상의 OK 버튼을 누르도록 촉구할 것이다. 이 버튼이 터치되면, 내장 제어 프로그램(620)은 키오스크 상의 관련 장치 제어 API 기능(640A)을 불러와서, 스캐너를 동작시키고 서류를 스캐닝하고 서류를 제위치로 되돌려 보내고 네트워크(예를들면, PSTN 또는 인터넷)를 통해 전자적으로 서류를 전송할 것이다.

6. 사용자는 전자 메일 기능을 선택할 수도 있다. 스크린은 전자 메일에 대한 HTML 애플리케이션을 보여줄 것이다. 내장 제어 프로그램(620)은 관련 API 기능(640A)을 불러오거나 혹은 브라우저를 통해 메일 서버 및 디렉토리 서버와 직접 통신하여 사용자를 식별하고 기존의 전자 메일 메시지를 검색하거나 새로운 메시지를 전송할 수도 있다.

7. 사용자는 (105A)를 선택하여 매체 캐리어(예를들면, 플로피 디스켓) 상에 전자 파일을 전송할 수도 있다. 스크린은 사용자에게 소정의 프로세스(예를들면 슬롯 내에 플로피를 삽입하는 것)를 따르도록 촉구할 수도 있다. 내장 제어 프로그램(620)은 관련 API 기능(640A)을 불러와서 디스켓을 판독하고, 사용자가 선택한 파일(들)을 판독 또는 기록하고 이들을 사용자의 지시에 따라 전송(예를들면 소정의 사람의 이메일 어드레스로 전송)한다.

8. 사용자는 예컨대 변호사, 의사, 회계사, 부동산 중개인, 대출 브로커, 투자 조언자, 보험 대리인 등과 같이 광범위한 서비스 제공자(즉, 서버상의 애플리케이션 소유자) 중에서 서비스를 선택할 수도 있다. 스크린은 요구된 서비스를 전달하는, HTML 내의 대응하는 애플리케이션을 보여줄 것이다. (사용자의 선택에 근거하여, 이 서비스는 임의의 원시 언어, 예를들면 영어, 스페인어, 중국어, 일본어, 프랑스어, 이탈리아어 등으로 나타날 수 있다.)

9. 서비스 제공자의 애플리케이션에 따라, 비디오, 오디오, 공유 스크린 및 원격 장치 제어 기능과 함께 실시간 협력 세션이 또한 개시될 수 있다(전술한 핀 등의 특허 참조). 내장 프로그램은 관련 API 기능(620)을 불러와서 비디오, 오디오 및 데이터 통신을 처리한다.

10. 사용자는 정보를 서치(search)할 수도 있다. 스크린은 사용자에게 어떤 정보를 필요로 하는지를 질문하고 내장 제어 프로그램은 그 데이터를 포착하여 정보의 유형에 따른 질문을 전송한다. 이 질문은, 잘 알려진 탐색 엔진, 애플리케이션 서버 상의 데이터베이스, 그 밖의 다른 네트워크 서버 상의 데이터베이스를 이용하여 인터넷을 통해 전송될 수 있다.

11. 사용자는 주문에 따라 제작된 애플리케이션 서비스를 선택할 수 있다. 예를들면, (예를 들어, 마그네틱 또는 스마트 카드상에서 액세스되는 정보로부터) 일단 사용자가 식별되면, 애플리케이션 파일은 사용자를 위해 주문제작된 정보 및/또는 키오스크 구성을 제공한다.

12. 사용자는 초기에 키오스크에 의해 제공되지 않는 키오스크(100)의 구성을 선택할 수 있다. 키오스크의 제 1 구성과의 대화에 의해, 그 밖의 다른 애플리케이션 파일(175)을 참조하면서 제 2 구성을 갖는 키오스크를 재구성할 수 있다. 예를들면, 제 1 구성은 제 2 구성을 위한 애플리케이션 파일(175)을 액세스하는 사용자 입력(아이콘 또는 하이퍼링크)을 제공할 수도 있다.

13. 사용자는, 서버가 "교습(teaching)" 애플리케이션 파일(175)을 제공하고 있는 네트워크에 연결되는 하나 이상의 키오스크에 액세스할 수 있는 1인 이상의 학생 또는 훈련생일 수 있다.

14. 사용자는 키오스크로부터 "전자" 제품을 선택할 수 있다. 예를들면, 음악, 비디오, 컴퓨터 소프트웨어 및/또는 그 밖의 다른 멀티미디어 정보를 갖는 콤팩트 디스크(CD)가 적절한 분배 장치(dispensing device)로부터 분배될 수 있다. 선택적으로, 빈 매체(blank media)(예를들면, 테이프, 디스켓, 기록가능한 CD 등)가, 적절한 키오스크 장치에 의해 기록되어 무형의 형태로 사용자에게 네트워크를 통해 전송될 수 있는 임의의 "전자" 정보를 제공할 수 있다. 예를들면, 공장에서 가게로 CD "컷(cut)"을 운반하지 않고도 이러한 방식으로 최신 오페라 레코딩을 CD 상에 제공할 수 있다.

키오스크 장치로부터 정보를 입력하고 이로부터 정보를 출력하는데 사용되는 몇몇 키오스크 제어 메카니즘(640)을 나타내는 또다른 예를 이하에 나타낸다. 일반적인 입력 상황에서, 애플리케이션 파일(500)은 CallAPI.class로 명명된 내장 애플릿(620)을 가질 수도 있는데, 이는 API 기능(640) "hardkey_input"을 불러오는데 사용된다. 예를들면 다음과 같다.

그리고, 이 애플릿은 HTML 파일내에 다음과 같이 내장된다.

이 애플릿이 브라우저에 의해 실행될 때, 우선 kioskAppInterface로 명명된 클래스를 사례화한다. 이 파일 및 관련 DLL은 브라우저 표준 라이브러리 내에 위치된다. 그 후, send_APImessage()로 명명된 kioskAppInterface 클래스(640A)의 매쏘드를 이용해 API 메시지 "hardkey_input"(640A)를 전송한다. 이 매쏘드는 인터프로세스 통신 기능(640I)을 호출하여 이 메시지를 API 메카니즘(640B)에 전송한다. 그 후, API 메카니즘(640B)은 관련 로컬 API 기능(680)을 불러와서, 키오스크에 구비된 하드웨어 키로부터의 키 입력(들)을 포착한 다음, 이들을 인터프로세스 통신 기능(640I)을 통해 (640A)로 다시 전송한다. 애플릿은 "input" 커맨드와 함께 get_APImessage() 메쏘드를 이용하여, (640B)로부터 다시 전송되어온 데이터를 취하고, 이 데이터를 InputData로 명명된 클래스의 데이터 구조내에 저장한다.

640B의 네임 서버 기능에서,

애플리케이션 파일(500)이, "소프트 키(softkey)" 입력을 불러오는 내장 애플릿을 가질 경우, 유사한 API 메시지는 (640A)와 (640B) 사이에서 전달될 것이며, 상이한 API 기능(680)은 스크린 상의 소프트 키패드 윈도우를 "팝 업(pop-up)"하여 사용자 입력을 포착하는데 사용될 것이다. 이들 소프트 키 입력을 위한 API 기능(680)은 널리 알려져 있다.

유사하게, 애플리케이션 파일(500)이, 출력 장치(예를들면 레이저 프린터) 상에 파일을 프린트하도록 하는 내장 애플릿을 가질 경우, 전술한 코드는 로컬 API 기능(680), 즉 Laser_print(FileName)을 지시하여 레이저 프린터가 파일 "FileName"을 프린트하도록 제어할 것이다.

도 6a는 IPC(640I) 및 네임 서버 기능(640B)을 이용하는 키오스크 제어 메카니즘(640)의 일 실시예를 도시한 도면이다. 이 경우, 일반적인 통신(주로 메시지 전달) API 기능(640A)의 고정된 소규모 세트는 애플리케이션 파일(175, 500)에 의해 사용된다. 이들 통신 API 기능은 640A 및 640B 사이에서 통신하거나 혹은 메시지를 전달한다. 메시지의 실행은 (640B)에 있는 네임 서버 기능에 의해 행해진다. 서버 기능(640B)은 또한 IPC(640I) 서버로서 작용한다. 네임 서버 기능은 다양한 사전정의된 메시지를 인식한다. 예를들면, 일 실시예에서, 통신 API 기능 세트는 두 가지 기능을 갖는데, 그 중 하나는 send_message(메시지)이고 다른 하나는 get_message(메시지)이다. 그러나 다수의 "메시지"가 존재한다. 640B 내의 네임 서버 기능은 이들 사전정의된 메시지들 각각을 포함하는 리스트를 가지며, 사전정의된 메시지 각각은, 각각의 사전정의된 메시지를 실행하기 위해 적절한 로컬 API 기능(680)을 호출하는 로직 세트와 연관된다.

이 실시예에서, 이들 장치에 의해 수행되는 새로운 장치 및/또는 새로운 기능은, 이 새로운 기능을 수행하기 위한 새로운 사전정의된 메시지(들) 및 그에 필요한 로직을 제공함으로써 부가될 수 있다. 이러한 방식으로, 애플리케이션 파일(175, 500)은 소정의 통신 API 기능에서 단순히 새로운 메시지 식별자를 사용함으로써 이들 새로운 기능을 실행할 수 있다. 이는 통상 애플리케이션 파일(500)의 "ASCII" 또는 "텍스트" 메시지 식별자를 변화시키는 것만으로도 이루어진다. 새로운 기능을 사용하기 위해 새로운 내장 프로그램(들)을 코딩 또는 컴파일하거나 혹은 기존의 프로그램(들)을 변경할 필요가 없다. 따라서, 키오스크 제공자가 네임 서버(640B) 내의 필요한 로직을 조직하기 때문에, 애플리케이션 소유자(그러므로, 서버(들)상의 애플리케이션 파일들(175))는, 새로운 기능을 수행하기 위해 해야 할 일이 거의 없게 된다.

도 6B는 브라우저 메카니즘(640A)에서 로컬 API를 맵핑하기 위해 IPC(640I)를 사용하는 키오스크 제어 메카니즘(640)의 다른 실시예를 나타내는 블럭도이다. 이 경우, 애플리케이션 파일(500)로부터 브라우저 메카니즘(640A) 내의 대응하는 맵핑 로컬 API를 직접 호출함으로써, 많은 혹은 모든 키오스크 제어 기능(620)이 실행된다. 맵핑 로컬 API(640A) 각각은 IPC(640I)를 통해 API 메카니즘(640B)과 통신하며, 이 API 메카니즘(640B)은 그 후 적절한 로컬 API 기능(680)을 불러온다. 여기에서, 맵핑 로컬 API(640A)는 자바 API 프로그램이다. 하나 이상의 로컬 API(680)에 대해 구체적으로 기록된 하나의 자바 API 프로그램이 존재한다. 네임 서버의 경우와는 달리, 적어도 하나의 자바 API 프로그램은 하나 이상의 로컬 API(680)를 제어하기 위한 로직을 가져야 한다. 이들 자바 API 프로그램(640)은 사전정의된 것이며 애플리케이션 파일(500)에 알려져 있는 것이다.

이 실시예에서, 이들 장치에 의해 수행되는 새로운 장치 및/또는 새로운 기능은, 브라우저 메카니즘(640A) 내의 새로운 맵핑 로컬 API(640A)를 그에 대응하는 API 메카니즘(640B)에 제공함으로써 부가될 수 있다. 이 실시예에서, 애플리케이션 파일(500)은 직접적인 호출로 이들 새로운 기능 각각을 실행할 필요가 있다. 따라서, 새로운 기능을 수행하기 위한 로직의 일부 또는 모두가 애플리케이션 파일(500)에서 정의되어야 한다. 예를들면, 서버 상에서 애플리케이션 파일(500)을 설계하는 애플리케이션 프로그래머는 예를 들어 새로운 자바 애플릿을 기록함으로써 이 로직을 코딩해야 한다.

도 6c는 키오스크 제어 메카니즘(640)의 다른 실시예를 나타내는 도면이다. 이 실시예에서는, IPC(640I)가 존재하지 않으며, 이에 따라 API 메카니즘(640B)은브라우저 메카니즘(640A) 내로 병합된다. 그러나, 네임 서버 기능(역시 병합됨)은 여전히 사용되며 통신 API 세트와 결합되어 브라우저 메카니즘(640B, 640)으로 된다. 이 실시예에서, 일단 애플리케이션 파일(500)(애플릿을 포함함)이 브라우저(160)에 의해 "드롭(drop)"(더 이상 실행되지 않음)되면 로컬 기능(680)이 종료하기 때문에 지속성이 상실된다. 이 실시예는 지속성이 요구되지 않는 경우에 유용한데, 예를들면 브라우저에 의해 제어되는 스크린을 제외하고는 어떠한 키오스크 장치도 관련되지 않는 경우에 유용하다.

도 6d는 키오스크 제어 메카니즘(640)의 다른 실시예를 나타내는 도면이다. 이 실시예에서는, IPC(640I) 및 API 메카니즘(640B)이 전혀 존재하지 않는다. 여기에서, 애플릿은 API 기능(640, 640A)을 직접 호출하고, 이 API기능은 로컬 API 기능(680)을 직접 호출한다. 여기서 API 기능(640)은 자바 API 프로그램이다. 하나 이상의 로컬 API(680) 각각에 대해 구체적으로 기록된 하나의 자바 API 프로그램이 존재한다. 네임 서버의 경우와는 달리, 적어도 하나의 자바 API 프로그램은, 하나 이상의 로컬 API(680)를 제어하기 위해 로직을 가져야 한다. 이들 자바 API 프로그램(640)은 사전정의된 것이며 애플리케이션 파일(500)에 알려져 있다. 이 실시예에서 지속성은 또한 상실된다.

도 7은 키오스크에 의해 수행되는 실행 프로세스(700)의 흐름도이다.

브라우저(160)는 우선 애플리케이션 파일(175)로부터 (HTML) 파일(500)을 얻는다(단계 705). 그 후 브라우저(160)는 애플리케이션 파일(500)의 태그 및 내용을 해석한다(단계 710). 브라우저(160)가 로컬 API 호출을 만나지 않을 경우(단계715), 브라우저는 태그를 실행하기 위해 관련된 공지의 조치를 취한다(단계 720). 브라우저가 로컬 API 호출을 만날 경우(단계 715), 브라우저는 관련 API 기능(640 또는 640A)을 불러올 것이다(단계 725).

바람직한 일 실시예에서, 브라우저 메카니즘(640A)은 인터프로세스 통신 기능(640I)을 통해 API 메카니즘(640B)과 메시지를 주고 받는다(단계 730). 선택적으로, 메시지 서버가 전술한 바와 같이 이용된다. API 메카니즘(640B)은 메시지를 수신하여 관련 로컬 기능(680)을 불러온다(단계 735). 그 후, API 메카니즘(640B)은 로컬 기능의 실행 결과로서 인터프로세스 기능(640I)을 통해 브라우저 메카니즘(640A)과 메시지를 주고 받는다(단계 740).

브라우저는, 스크린 입력, 내장 제어 프로그램 로직, 또는 외부 브라우저 제어 기능(660)을 통해 다음 HTML 파일을 요구하도록 제어된다(단계 750). 따라서, 브라우저는 로컬 키오스크 장치로서 취급될 수 있다. 따라서, 브라우저는, 로컬 API(660)를 이용하여 공지의 브라우저 인터페이스(API(681))에 액세스함으로써 네트워크를 통해 하나 이상의 서버로부터 임의의 특정한 HTML 파일을 로드하도록 제어될 수 있다. 로컬 API(660)는 내장 제어 프로그램(620)이 브라우저 인터페이스(681)를 액세스하도록 설계된다(전술한 내용 참조).

도 8은 네트워크 상의 하나 이상의 서버 상에서 실행되는 서버 프로세스(800)의 흐름도이다. 서버는 하나 이상의 키오스크로부터 네트워크를 통해 요구를 수신한다(단계 810). 그 요구는 키오스크가 어떤 애플리케이션 파일(175)을 선택/액세스하는지 식별한다. 그 요구는 또한 애플리케이션 파일을 요구/액세스하는 키오스크(100)의 위치를 갖는다. 이 요구를 수신하였을 때, 서버는 요구된 애플리케이션 파일(들)(175)을 키오스크에 전송한다(단계 820). 애플리케이션 파일(들)(175)은 사전에 만들어지거나 혹은 서버 상의 로직에 의해 동적으로 생성될 수 있다.

다른 실시예에서, 키오스크는 프록시 서버(proxy server)(195A)에게 요구를 전송한다(단계 810). 프록시 서버(195A)는, 전형적으로 서버(195)보다 키오스크에 더 가까이 위치된다. 선택적으로, 프록시 서버(195A)는 키오스크(100/200) 내의 컴퓨터(110) 상에 위치될 수 있다. 예를들면, 서버(195)는 제 1 도시, 예를들면 본부 위치(headquarters location)에 배치될 수 있으며, 반면에 프록시 서버(195A)는 다른 도시에 있는 키오스크(들)에 연결되는 LAN 상에 위치된다. 프록시 서버(195A)는, 키오스크가 사전정의된 스케줄에 따라 요구할 수도 있는 많은 혹은 모든 애플리케이션 파일(175)에 대한 요구를 네트워크(150)를 통해 서버에게 전송할 수 있다. 이러한 방식으로, 키오스크는, 애플리케이션 파일이 요구될 때 프록시 서버(195A) 상의 애플리케이션 파일(175)에 더 빠르고 더욱 신뢰성있게 액세스할 것이다. 또한, 프록시 서버는, 네트워크 상의 "오프 피크(off peak)" 시간 동안 서버(195)로부터 애플리케이션 파일(175)을 요구할 수도 있다.

다른 실시예에서, 서버(195, 195A)는 서버(195)에 의해 식별되는 하나 이상의 키오스크로 정보를 "푸시(push)"하는 데 사용될 수 있다. 예를들면, 단계(810)에서, 서버(195)측에서 요구가 개시된다. 이러한 개시(810)는 여러 이유로 유발될 수 있다. 예를들면, 애플리케이션을 갱신하는데 있어서, 하나 이상의 키오스크가새로운 애플리케이션 파일(175)로 재구성될 것이 요구될 수도 있다. 선택적으로, 매일 특정 시간에 요구되는 새로운 구성이 존재할 수도 있는데, 즉 여러 공급원으로부터 뉴스가 매일 오후 5시에 제공될 수도 있다. 서버는 또한 키오스크의 주기적인 "검사(inspection)"를 "푸시"하여서 어떤 키오스크가 유지보수(maintenance)를 필요로 하는지 판단할 수도 있다.

이 실시예를 바람직하게 구현하는데 있어서, 키오스크에서 동작하는 "서버 푸시 기능"(685)을 사용한다. 서버 푸시 기능(685)은 네트워크(150)에 연결되며, 서버(195)로부터 메시지를 수신할 수 있다. 서버 푸시 기능(685)은 또한 브라우저 인터페이스(681)에 액세스할 수 있다. 서버(195)는 서버 푸시 기능(685)으로 요구를 전송하여서 브라우저로 하여금 서버(195)로부터 특정 애플리케이션 파일(500)을 요구하도록 한다.

도 9는, 내장 제어 프로그램이 자바 대신에 Activex 기법을 사용할 때의 메카니즘을 나타낸 블럭도이다. Activex 제어 객체는, C++ 또는 비주얼 베이직(Visual Basic) 혹은 자바와 같은 여러 프로그래밍 언어를 사용하여 구현될 수 있다. Activex 객체는 HTML 파일 내에 내장될 수 있다. 예를들면, 다음과 같다.

이 경우, 브라우저는 Activex-인에이블되어야 하는데, 즉 Activex 기법을 지원해야 한다. 하나의 바람직한 실시예에서, 브라우저는 마이크로소프트 인터넷 익스플로러이다.

애플리케이션 파일(500)이 브라우저(160)에 도달하면, HTML 파일은 그 태그 및 내용에 근거하여 해석된다(단계 910). 전술한 자바의 경우에서처럼, 브라우저는 비 API 제어 기능을 실행할 것이다(단계 920). 브라우저에 의해 실행되는(단계 930) API 제어 기능은 API를 직접 불러온다(단계 940). 자바의 경우와 유사하게, API의 제 1 부분(940A)은 인터프로세스 통신 기능(940I)(예를들면, 640I)을 통해 API의 제 2 부분(940B)(예를들면, 640B)과 통신하며 이는 그 후 로컬 API 기능(680)을 호출한다.

Activex와 이전의 자바 경우의 상위점은, Activex가 C++ 또는 비주얼 베이직과 같은 비-네트워크(non-network) 언어로 기록된 객체를 포함할 수 있다는 점이다. 이러한 언어로 된 객체는 실행가능한 코드로 브라우저에게 다운로드된다. 따라서, 이러한 객체는 동일한 언어로 기록된 로컬 프로그램이 할 수 있는 모든 것을 할 수 있지만, 자바 애플릿이 가지고 있는 보안 한계를 가지고 있지 않다. 따라서, 내장 제어 프로그램(620)이 자바 언어를 이용하지 않고 Activex 제어로서 기록될 경우, API 기능(940)은 키오스크 내의 어느 장소에나 놓여질 수 있다. 자바가 Activex 객체에서 사용될 경우, 전술한 메카니즘을 여전히 사용해야 한다.

도 9a-9d에서, 이전에 설명한 번호를 갖는 박스는 전술한 것과 동일한 기능을 갖는다.

도 9a는 IPC 및 네임 서버 기능을 이용하는 키오스크 제어 메카니즘(940)의 일 실시예를 도시하는 도면이다. 브라우저 메카니즘(940A)은 원시 언어 API로서, 브라우저 디렉토리 내에 위치될 필요는 없으며, 키오스크의 메모리 내, 예를들면 시스템 디렉토리 내의 임의의 장소에 위치될 수 있다. 그러나, 브라우저 메카니즘(940A)의 경로(즉, 위치)는 애플리케이션 파일(500)에 알려져야 한다.

도 9B는 매핑 로컬 API를 갖는 IPC(640I)를 이용하는 다른 실시예의 키오스크 제어 메카니즘의 블럭도이다. 도 6B에서 처럼, 하나 이상의 로컬 APIs(680)와 관련하여 적어도 하나의 브라우저 메카니즘(940)이 존재한다.

도 9C는 IPC(640I)를 갖지 않는 다른 실시예의 키오스크 제어 메카니즘(940)을 도시한다. 여기에서 브라우저 메카니즘(940A)은 도 9A에서 논의된 것처럼 위치될 수 있다.

도 9D는 제어가 자바로 구현되지 않을 때 ActiveX를 이용하는 다른 실시예의 키오스크 제어 메카니즘을 도시한다. 이 실시예에서는, 내장 ActiveX 제어가 로컬 APIs(680)를 직접 호출할 수 있기 때문에 브라우저 메카니즘(940)이 필요없다. 이 경우, 실행의 지속성(the persistence of execution)이 없어진다.

도 10은 흔히 말하는 플러그-인 기법을 이용하는 또다른 키오스크 제어 메카니즘을 도시한다. 이 경우, 바람직한 실시예에 따르면 네스케이프 내비게이터 v3.0 혹은 그 이상 버전(version)의 브라우저(160)가 이용된다.

여기에서, 제어 메카니즘(1040)은 애플리케이션 파일/파일(175, 500)의 키오스크 제어 프로그램(620)에 의해 액세스되는 브라우저 메카니즘(플러그-인 모듈 및관련 자바 래퍼(Java wrapper))(1040A)을 포함한다. 액세스되면, 플러그-인 모듈(1040A)은 브라우저(160)의 일부로서 실행된다. 실행중인 플러그-인 모듈(1040A)은 차례로 인터프로세스 통신 기능(1040I)을 호출한다. 이 인터프로세스 통신 기능(IPC)(1040I)은 전술한 IPCs(640I, 940I)와 동일한 것이 될 수 있다. IPC(1040I)는 차례로 API 메카니즘(1040B)과 통신하여, 로컬 APIs(680)를 호출한다. API 메카니즘(1040B)은 전술한 것(640B, 940B)과 동일한 것이 될 수 있다.

이 실시예에서, 브라우저 메카니즘(1040A)은 플러그-인 기법으로 구현된다(잔 올리판트(Zan Oliphant)의 "Programming Netscape Plug-ins", Sams.net Publishing, 1996, ISBN 1-57521-098-3을 참조할 것). 플러그-인 기법은 네가티브 코드 모듈을 이용하는데, 즉, C 또는 C++혹은 그와 유사한 프로그래밍 언어를 이용해서 구현되며, 더 나아가 더욱 바람직한 실시예로서 자바 래퍼로 구현된다. 플러그-인(1040A)은 브라우저(160)가 지정하는 특정 플러그-인 디렉토리내에 위치된다. HTML 인터프리터(610)가 해당 내장 파일 고유의 파일명 확장자로 각각의 플러그-인(1040A)을 식별하는 내장 파일(620)(흔히 다목적 인터넷 메일 확장형(MIME;Multipurpose Internet Mail Extension)으로 불림)과 만나면, 플러그-인(1040A)은 브라우저(160)에 동적으로 로드된다.

내장 키오스크 제어 프로그램(620)은 1) 자바스크립트 기능, 2) 자바 애플릿 및/또는 3) 고유 확장자를 갖는 (MIME) 파일에 포함되는 사전정의된 일련의 제어 스크립트일 수 있다.

브라우저(160)가 플러그-인 모듈(1040A)을 로드하면, 플러그-인(1040A)은 HTML 문서를 활용할 수 있게 되는데, 즉, 플러그-인의 기능들(플러그-인 기능들)이 내장 프로그램(620)에 대해 활용가능해져서, 예를들면, 자바스크립트 기능 또는 자바 애플릿 기능을 호출할 수 있다. 이러는 동안, 키오스크 로컬 APIs(680)는 하나 이상의 대응 플러그-인(1040A)을 통하여 어떤 소정의 내장 프로그램(620)에 의해 제어될 수 있다. 다시 말하면, 플러그-인 모듈(1040A)은 대응 API 메카니즘(1040B)을 통해 키오스크 로컬 API(680)를 호출하기 위해 IPC 기능(1040I)을 호출할 것이다.

이제 세 가지 예가 제공될 것이지만, 반드시 이 예들에 한정되는 것은 아님을 유의하자.

예 1은 메시지 전달 기능을 제공하는 플러그-인 모듈(1040A)을 구비하는 내장 키오스크 제어 프로그램(1030)으로서 자바스크립트 기능을 이용한다.

제어 프로그램(1030)을 갖는 애플리케이션 파일(175)은 다음과 같다.

자바 애플릿 "MYPPLET.Java"는 다음과 같은 코드를 포함할 것이다.

자바 래퍼 파일 PluginWrapper.java은 다음 코드를 포함할 것이다.

전술한 내장 제어 프로그램(1030)과 관련된 플러그-인 모듈(1040A)은 예를들면 C++같은 원시 언어 코드로 구현되는 메쏘드 SendMsg()를 제공할 것이다.

예 2는 메시지 전달 기능을 제공하는 플러그-인 모듈(1040A)을 갖는 내장 키오스크 제어 프로그램(1030)으로서 자바 애플릿을 직접 이용한다.

제어 프로그램(1030)을 갖는 애플리케이션 파일(175)은 다음과 같다.

자바 애플릿 "MYAPPLET.Java"는 다음과 같은 코드를 포함한다.

자바 래퍼 파일 PluginWrapper.java은 다음 코드를 포함할 것이다.

예 1에서와 마찬가지로, 전술한 내장 제어 프로그램(1030)과 관련된 플러그-인 모듈(1040A)은 예를들면, C++같은 원시 언어 코드로 구현되는 메쏘드 SendMsg()를 제공할 것이다.

예 3은 일련의 사전정의된 제어 스크립트를 포함하는 내장 파일(1030)과, 키오스크 로컬 APIs(680)를 제어하는 스크립트를 해석 및 실행하는 대응 플러그-인 모듈(1040A)을 이용한다.

내장 파일(1030)을 갖는 애플리케이션 파일(175)은 다음과 같을 수 있다.

반면에 플러그-인 모듈(1040A)은 다음 코드로 이루어질 수 있을 것이다.

전술한 이들 세 가지 플러그-인 기능들 모두는 네스케이프 브라우저(160)에 의해 제공되는 표준 플러그-인 APIs를 구현한다. 브라우저(160)에 의해 제공되는 그 밖의 플러그-인 APIs는 본원에서 사용되지 않는다.

클래스 KioskIPC와 기능 InterpretFile()은 내장 파일의 사전정의된 스크립트를 해석 및 실행하기 위해 예컨대 C++같은 원시 언어를 이용하여 구현될 수 있다. 이런 점에서, 스크립트를 파싱(parsing)하고 필요한 기능들을 어느 정도의 성능으로 실행할 수 있도록 기능 InterpretFile()이 구현되는 한, 스크립트는 어떤 스크립트이든지 제한받지 않는다. 일 예를들면 다음과 같다.

내장 파일에서, 스크립트는 다음과 같을 수 있다.

그리고, 기능 InterpretFile()은 다음과 같은 코드를 포함한다.

플러그-인 모듈(1040A)은 또한 자신의 기능들과 관련해 대화형 제어를 실현하기 위해 브라우저(160) 윈도우상에 몇 개의 버튼들을 생성할 수 있다. 예를들면, "PrintCurrentPage" 메시지를 전송하는 SendMsg() 기능을 호출하기 위해 "Print" 버튼을 생성하고, 이 버튼이 터치 혹은 클릭되기를 기다리 수 있다. 또한 <embed> 태그는 플러그-인 모듈(1040A)의 구현에 따라 플러그-인 모듈(1040A)을 제어하는 사전정의된 일련의 파라미터들을 포함할 수 있다. <embed> 태그의 이용 방법 및 플러그-인 모듈의 구현 방법과 관련한 더 많은 정보는 "HTML publishing for Netscape"(Stuart Harris 및 Gayle Kidder 공저, ISBN1-56604-288-7)와, 전술한 잔올리판트(Zan Oliphant)의 저서를 참조하기 바란다.