KR101911036B1

KR101911036B1 - 무접촉 프로토콜을 제공하기 위한 시스템들, 방법들, 및 컴퓨터 프로그램 제품들

Info

Publication number: KR101911036B1
Application number: KR1020147035327A
Authority: KR
Inventors: 래리 엘. 부시; 크리스토퍼 제이. 톰자크
Original assignee: 구글 엘엘씨
Priority date: 2012-05-24
Filing date: 2013-05-23
Publication date: 2018-10-23
Also published as: CN104335237A; CN110009329A; AU2016208396A1; US20190244191A1; AU2013266229A1; CA2874649C; US20130317927A1; JP6033956B2; EP2856406A2; KR20150014972A; AU2016203470A1; US11526870B2; JP2018101426A; JP2017062807A; US10949832B2; CA2874652A1; JP2019040608A; CN104584043A; JP6480610B2; US20210233059A1

Abstract

시스템들, 방법들, 및 컴퓨터 프로그램 제품들이 무접촉 트랜잭션들을 관리하기 위해 제공된다. 활성화 요청이 수신된다. 이동 디바이스로부터의 제 1 탭이 식별된다. 제 1 탭은 이동 디바이스가 시스템에 대한 미리 결정된 근거리 내에 위치될 때 발생한다. 제 1 애플리케이션에 대응하는 AID를 포함한 제 1 선택 명령어는 이동 디바이스에 송신된다. 제 1 선택 명령어에 기초한 제 1 응답은 이동 디바이스로부터 수신된다. 지원된 데이터 유형들을 표시한 정보를 포함한 데이터 요청이 이동 디바이스에 송신된다. 데이터 요청에 기초하며 트랜잭션 데이터를 포함한 제 2 응답이 이동 디바이스로부터 수신된다.

Description

무접촉 프로토콜을 제공하기 위한 시스템들, 방법들, 및 컴퓨터 프로그램 제품들{SYSTEMS, METHODS, AND COMPUTER PROGRAM PRODUCTS FOR PROVIDING A CONTACTLESS PROTOCOL}

본 명세서에 설명된 예시적인 측면들은 일반적으로 무접촉 프로토콜들에 관한 것이며, 보다 구체적으로 이동 디바이스들, 근거리 무선 통신(NFC; near field communication) 판독기들, 및 판매 시점 관리(POS; point of sale) 시스템들 사이에서의 상호 연동을 허용하는 무접촉 프로토콜을 제공하기 위한 시스템들, 방법들, 및 컴퓨터 프로그램 제품들에 관한 것이다.

NFC 기술은 일반적으로 10센티미터들 미만으로 떨어진, 특정한 근거리 내에 위치되는 디바이스들 사이에서 데이터가 교환되도록 허용하는 표준들-기반 무선 통신 기술이다. 이러한 NFC 기술의 하나의 사용은 지불, 액세스(access) 및 티켓팅(ticketing)을 위한 것들을 포함하여, 무접촉 트랜잭션들을 이루기 위한 것이다. 예를 들면, NFC-가능 이동 디바이스는 소비자의 금융 기관에 의해 발행된 지불 애플리케이션(application) 및 지불 계좌 정보(즉, 신용 또는 직불 카드와 같은 금융 수단과 연관된 크리덴셜들(credentials))를 제공받을 수 있다. 각각의 지불 애플리케이션은 보안 요소 상에서의 다수의 판매자들, 제조사들 또는 브랜드들(brands)과 연관된 다수의 세트들(sets)의 상거래 데이터(data)를 저장 및 관리할 수 있다. 애플리케이션 및 지불 계좌 정보는 통상적으로 암호화되며 이동 디바이스에서의 보안 영역에 저장된다. 이동 디바이스는, 결과적으로, 상점들과 같은 유인 위치들 및 자동 판매기들과 같은 무인 위치들에서의 NFC-가능 판매 시점 관리(POS) 시스템들과 통신하기 위해 NFC 기술을 사용한다. 지불하기 위해, 소비자는 이동 디바이스를 무접촉 지불-가능 POS 시스템의 대략 수십 센티미터들 내로 간단히 가져오며 트랜잭션이 발생한다. 프로세스(process)는 통상적으로 무접촉 신용 및 직불 카드들에 의해 사용된 것과 동일하다.

NFC-가능 판독기 가까이에 이동 디바이스 또는 무접촉 신용 또는 직불 카드를 그것들이 통신적으로 결합될 수 있도록 위치시키는 것은 때때로 "웨이브(wave)" 또는 "탭(tap)"으로서 불리운다. 소비자들이 NFC-가능 POS 시스템들에서 "지불하기 위해 탭"하도록 허용하는 이동 디바이스를 위한 애플리케이션은 일반적으로 "지갑 애플리케이션(wallet application)" 또는 "이동 지갑 클라이언트 애플리케이션(mobile wallet client application)"으로서 불리운다. 지불들과 관련 있는 애플리케이션은 일반적으로 "지불" 애플리케이션으로서 불리운다. 공통적인 무접촉 지불 애플리케이션들은 다음의 기술들 중 임의의 것을 사용하여 용이해진다: 아메리칸 익스프레스(American Express)® "ExpressPay", 디스커버(Discover)® "ZIP", 마스터카드(Mastercard)® "PayPass" 또는 비자(Visa)® "PayWave".

또한, NFC는 예를 들면, NFC 태그들(tags), 스마트 포스터들(smart posters) 또는 스마트 빌보드들(smart billboards)로부터 특가 오퍼들(offers), 로열티(loyalty) 또는 보상 정보를 수신하거나 또는 제품들에 대한 정보를 판독하기 위해 사용될 수 있다. 오퍼들, 로열티 및 보상들과 관련 있는 애플리케이션은 일반적으로 본 명세서에서 "상거래(commerce)" 애플리케이션으로서 불리운다.

지불 및 상거래 기술들을 이용하는 것과 연관된 하나의 기술적인 도전은 지불 정보를 전송하는 동일한 탭 이벤트(tap event)가 판매자 로열티 카드들, 오퍼들, 보상들 등과 연관된 부가적인 정보를 포함하도록 허용하기 위한 능력을 협력적으로 수반한다. 이를 위해, 기존의 NFC 판독기들 또는 NFC-가능 지불 POS 단말기들에서의 메시징(messaging) 기술들은 트랜잭션들을 수행하기 위해 사용된 이동 디바이스들로부터 지불 크리덴셜들(앞서 언급한 지불 프로토콜들을 사용하는) 및 부가적인 상거래 데이터(로열티, 오퍼들, 보상들 등) 양자를 검색 및/또는 수신하는 메시징 기술을 효과적으로 지원하기 위해 업그레이드(upgrade)될 것을 주장한다. 또 다른 기술적 도전은 상거래 요소들이 결과적으로 통상적인 POS 트랜잭션(예컨대, 구매)의 일부로서 제공될 수 있도록 이동 디바이스로 이들 상거래 요소들(예컨대, 오퍼들, 로열티 카드 크리덴셜들, 보상들 등)을 공개하는 것을 수반한다.

본 명세서에 제공된 예시적인 실시예들은 무접촉 프로토콜을 제공하기 위한 시스템들, 방법들, 및 컴퓨터 프로그램 제품들을 제공함으로써 상기-확인된 요구들을 충족시킨다.

일 실시예에서, 무접촉 트랜잭션들을 관리하기 위한 시스템은 적어도 하나의 프로세서(processor)를 포함한다. 활성화 요청이 수신된다. 이동 디바이스로부터의 제 1 탭이 식별된다. 상기 제 1 탭은 상기 이동 디바이스가 상기 시스템에 대해 미리 결정된 근거리 내에 위치될 때 발생한다. 제 1 애플리케이션에 대응하는 AID를 포함하는 제 1 선택 명령어는 상기 이동 디바이스에 송신된다. 상기 제 1 선택 명령어에 기초한 제 1 응답은 상기 이동 디바이스로부터 수신된다. 지원된 데이터 유형들을 표시하는 정보를 포함하는 데이터 요청이 상기 이동 디바이스에 송신된다. 상기 데이터 요청에 기초하며 트랜잭션 데이터를 포함하는 제 2 응답이 상기 이동 디바이스로부터 수신된다.

또 다른 실시예에서, 무접촉 트랜잭션들을 관리하기 위한 방법은 활성화 요청을 수신하는 단계; 이동 디바이스로부터 제 1 탭을 식별하는 단계로서, 상기 제 1 탭은 상기 이동 디바이스가 단말기에 대해 미리 결정된 근거리 내에 위치될 때 발생하는, 상기 제 1 탭을 식별하는 단계; 제 1 애플리케이션에 대응하는 AID를 포함하는 제 1 선택 명령어를 상기 이동 디바이스에 송신하는 단계; 상기 이동 디바이스로부터 상기 제 1 선택 명령어에 기초한 제 1 응답을 수신하는 단계; 지원된 데이터 유형들을 표시하는 정보를 포함하는 데이터 요청을 상기 이동 디바이스에 송신하는 단계; 및 상기 이동 디바이스로부터 상기 데이터 요청에 기초한 제 2 응답을 수신하는 단계로서, 상기 제 2 응답은 트랜잭션 데이터를 포함하는, 상기 제 2 응답을 수신하는 단계를 포함한다.

또 다른 실시예에서, 비-일시적 컴퓨터-판독 가능한 매체는 그것 상에 저장된 지시들의 시퀀스들(sequences)을 가지며, 상기 지시들의 시퀀스들은 하나 이상의 프로세서들로 하여금: 활성화 요청을 수신하게 하고;

이동 디바이스로부터 제 1 탭을 식별하게 하는 것으로서, 상기 제 1 탭은 상기 이동 디바이스가 단말기에 대해 미리 결정된 근거리 내에 위치될 때 발생하는, 상기 제 1 탭을 식별하게 하고; 제 1 애플리케이션에 대응하는 AID를 포함하는 제 1 선택 명령어를 상기 이동 디바이스에 송신하게 하고; 상기 제 1 선택 명령어에 기초한 제 1 응답을 상기 이동 디바이스로부터 수신하게 하고; 지원된 데이터 유형들을 표시하는 정보를 포함하는 데이터 요청을 상기 이동 디바이스에 송신하게 하며; 상기 이동 디바이스로부터 상기 데이터 요청에 기초한 제 2 응답을 수신하게 하는 것으로서, 상기 제 2 응답은 트랜잭션 데이터를 포함하는, 상기 제 2 응답을 수신하게 한다.

본 명세서에 제공된 본 발명의 예시적인 실시예들의 특징들 및 이점들은 다음의 도면들과 함께 취해질 때 이하에 제시된 상세한 설명으로부터 보다 명백해질 것이다.
도 1은 대표적인 실시예에 따른 플랫폼 아키텍처(platform architecture)의 그래픽(graphic) 표현이다.
도 2는 대표적인 실시예에 따른 단일 탭 타이밍(timing) 도를 예시한다.
도 3은 대표적인 실시예에 따른 이중 탭 및 트랜잭션 후 데이터 송신을 포함하는 상거래 프로세스 흐름을 예시한 타이밍 도를 도시한다.
도 4는 대표적인 실시예에 따른 이중 탭, 및 트랜잭션 후 데이터 및 지불 송신들을 포함한 상거래 프로세스 흐름을 예시한 타이밍 도를 도시한다.
도 5는 예시적인 실시예에 따른 대표적인 다중-블록(block) 데이터 흐름을 예시한다.
도 6은 본 발명의 예시적인 실시예에 따른 지갑 애플리케이션을 위한 그래픽 사용자 인터페이스(interface)에 의해 발생된 윈도우들(windows) 또는 스크린 샷들(screen shots)을 예시한다.
도 7은 본 발명의 실시예에 따른 대표적인 인스턴트 오퍼 구현을 예시한 흐름도를 예시한다.
도 8은 본 발명의 예시적인 실시예에 따른 컴퓨터 시스템 상에 배치된 기능 모듈들(modules)의 협력적 다이어그램(diagram)이다.

본 명세서에 제공된 예시적인 실시예들은 이제 예시적인 판매자 트랜잭션에 대하여 본 명세서에 설명되는, 무접촉 프로토콜을 제공하기 위한 시스템들, 방법들 및 컴퓨터 프로그램 제품들에 관한 것이다. 이러한 설명은 본 명세서에 제공된 예시적인 실시예들의 애플리케이션을 제한하도록 의도되지 않는다. 사실상, 다음의 설명을 판독한 후, 대안적인 실시예들에서 다음의 예시적인 실시예들을 구현하는 방법(예컨대, 대량 수송 단말기 및 이동 디바이스 사이에서의 무선 통신 연결을 요구하는 대량 수송 트랜잭션들을 수반하는)이 관련 기술(들)에서의 숙련자에게 명백할 것이다.

용어들("애플리케이션", "애플릿(applet)", "위젯(widget)") 및/또는 이들 용어들의 복수의 형태는 애플리케이션(다른 애플리케이션들에 독립적으로 또는 그것들과 함께 기능하는) 또는 지시들 또는 코드의 세트 또는 서브세트를 나타내기 위해 본 명세서에 상호 교환 가능하게 사용되며, 이것은 하나 이상의 프로세스들(예컨대, 이동 디바이스, 카드 판독기, 단말기, 판매 시점 관리(POS) 시스템, 또는 서버(server) 내의)에 의해 실행될 때 프로세서(들)로 하여금 특정 태스크들(tasks)을 수행하게 한다. 예를 들면, 지갑 애플리케이션은 금융, 로열티, 오퍼, 멤버십(membership), 또는 계좌 데이터를 저장, 프로세스, 액세스, 또는 송신하는 것과 같은 트랜잭션- 또는 인터페이스-관련 기능들을 행하게 하기 위해 사용될 수 있다. 또한 지갑 애플리케이션은 아메리칸 익스프레스®로부터의 ExpressPay, 디스커버® Network Zip^SM, 마스터카드® PayPass^TM 및 비자 payWave^TM 지불 애플릿들과 같은, 하나 이상의 지불 애플리케이션들과 통합하거나 또는 상호작용할 수 있다.

일반적으로, 상거래-관련 서비스들은 여러 개의 상이한 플랫폼들 상에서 이용 가능한 애플리케이션들의 묶음을 통해 이용 가능해진다. 제 1 애플리케이션(또는 애플리케이션들의 묶음)은 이동 상거래(MoCom) 플랫폼 내의 서버 상에 탑재하여 존재한다. MoCom 플랫폼은 로열티 계좌들 및 오퍼들을 포함하여, 소비자 데이터의 관리를 책임지고 있다. 또한, MoCom 플랫폼은 오퍼들에 대한 캠페인(campaign) 관리기로서 작용하여, 지갑 애플리케이션 내의 이용 가능한 판매자 포탈들(portals)을 통해 소비자에게 이용 가능해진 오퍼들을 위한 원격 데이터 저장소를 제공한다.

제 2 애플리케이션은 지갑 애플리케이션의 형태로 이동 디바이스에 탑재하여 존재한다. 지갑 애플리케이션은 지갑 애플리케이션이 이동 디바이스의 보안 요소(SE; secure element)에 탑재된 부가적인 리소스들(resources)을 액세스할 수 있는 부가적인 상거래 애플리케이션 서비스들 및 소비자의 1차 사용자 인터페이스(UI; user interface)를 제공한다.

제 3 애플리케이션은 자바카드(JavaCard) 애플릿의 형태로 이동 디바이스의 보안 요소에 탑재하여 존재한다. 이러한 애플릿은 로열티 및 오퍼 데이터와 같은 상거래-관련 데이터를 저장하며 데이터가 관리될 수 있는 인터페이스를 제공한다. 애플릿은 국제 표준 기구(ISO; International Standards Organization) 7816-4에 정의된 바와 같이 애플리케이션 프로토콜 데이터 유닛(APDU; Application Protocol Data Unit) 명령어들의 사용을 통해 액세스 가능하다.

제 4 애플리케이션은 NFC-가능 판독기(본 명세서에 간단히 "판독기(reader)"로서 불리우는)에 탑재하여 존재한다. 판독기는 독립형 디바이스이거나 또는 판매 시점 관리(POS) 단말기에 부착(및 그에 의해 관리)될 수 있다. 이러한 애플리케이션은 APDU 명령어/데이터 교환 태스크들을 최적화하는 특정 태스크들을 수행하는, 이동 디바이스 상에서의 보안 요소와의 인터페이스에 대한 액세스를 용이하게 하거나 또는 이를 제공한다. 예를 들면, 그것은 판독기(즉, "탭")에 근접한 이동 디바이스의 배치를 따르는 로열티 또는 오퍼 정보의 판독을 포함한다.

제 5 애플리케이션(또는 애플리케이션들의 묶음)은 POS 단말기 및 임의의 부가적인 판매자-특정 하드웨어(hardware)/소프트웨어(software)를 포함하여, 판매자 POS 시스템에 탑재하여 존재한다. 이들 애플리케이션들은 판독기를 통해 이동 디바이스 상에서의 보안 요소로부터 수신된 지불/로열티/오퍼들/보상들과 관련 있는 데이터를 관리한다. 대부분의 경우들에서, 이러한 데이터는 그 후 대응하는 MoCom 또는 판매자 특정 플랫폼(들)으로 포워딩(forwarding)될 것이다.

도 1은 대표적인 실시예에 따른 플랫폼 아키텍처의 그래픽 표현이다. 도 1에 도시된 바와 같이, 시스템(100)은 무접촉(예컨대, 근거리 또는 NFC) 판독기(120) 및 이동 지갑 플랫폼(130)에 통신적으로 결합된 이동 디바이스(110)를 포함한다. 또한 판독기(120)는 POS 단말기(140)에 통신적으로 결합된다. POS 단말기(140)는 판독기(120)와 동일한 하우징(housing) 내에 있을 수 있다. 대안적으로, POS 단말기(140) 및 판독기(120)는 서로와 통신적으로 결합되지만 이들 구성요소들의 각각은 별도로 하우징된다.

이동 디바이스(110)는 예를 들면, 셀룰러(cellular) 전화기 등일 수 있으며, 프로세서(111a), 메모리(memory)(111b), 무접촉 프론트엔드(CLF; contactless frontend)(111c), 기저대역 모뎀(111d), 및 디스플레이(display)(도시되지 않음)와 같은 사용자 인터페이스를 포함한다. 기저대역 모뎀(111d)은 이동 네트워크 통신들을 위해 사용되는 디지털 모뎀(digital modem)이다. CLF(111c)는 무접촉 또는 NFC 통신들의 아날로그(analog) 측면 및 무접촉 송신 링크(link)의 통신 프로토콜 계층들을 핸들링(handling)하는 회로이다. 또한 CLF(111c)는 예를 들면, 무접촉 트랜잭션들을 실행하기 위해 이동 디바이스(110)에 포함된 판독기(120) 및 보안 요소(또는 SE)(112) 사이에서 데이터를 교환하기 위해 사용된다.

보안 요소(112)는 범용 집적 회로 카드(UICC; Universal Integrated Circuit Card), 내장된 SE 카드, 보안 마이크로 보안 디지털(microSD) 카드 등으로서 구현될 수 있다. 보안 요소(112)는 일반적으로 그것이 전용 메모리를 포함한, 자립적 시스템이기 때문에 안전한 것으로 고려되며, 독립적인 검사에 의해 검증되는 하드웨어 및 소프트웨어 안정화 기술들에 의해 보호된다.

보안 요소(112)는 (예컨대, 그것 상에 저장된) 하나 이상의 상거래 애플릿들(113)을 포함한다. 각각의 상거래 애플릿(113)은 상거래 서비스 제공자(SP; service provider)에 의해 발행된 계좌 및 상거래 서비스와 연관된다. 서비스 제공자는 서비스들을 고객들 또는 소비자들에 제공하는, 회사, 조직, 엔티티(entity) 등이다. 서비스 제공자들의 예들은, 은행, 판매자들, 카드 협회들, 마케팅(marketing) 회사들, 및 교통 당국들과 같은 계좌-발행 엔티티들을 포함한다. 서비스는 지불 서비스, 신용, 직불, 체킹(checking), 기프트(gift), 오퍼 또는 로열티 서비스, 수송 패스(pass) 서비스 등과 같은 서비스 제공자에 의해 제공되거나 또는 허용되는 활동, 능력, 기능, 작업 또는 사용일 수 있다.

상거래 서비스 제공자는 하나 이상의 별개의 상거래 애플릿들(113)을 보안 요소(112) 상으로 공급할 수 있다(또는 공급하였다). 또한, 다른 독립적인 서비스 제공자들은 그것들 자신의 상거래 애플릿(들)(113)을 보안 요소(112) 상으로 공급할 수 있다(또는 공급하였다). 일반적으로, 상거래 애플릿(113)은 이러한 데이터가 관리될 수 있는 APDU 인터페이스를 제공하는, 로열티 및 오퍼들 관련 데이터 양자를 저장한다. 상거래 애플릿(113)은 다수의 로열티/오퍼 서비스들이 로열티/오퍼 데이터 관리를 위한 메커니즘들(mechanisms)(예컨대, 보안 요소, 이동 디바이스)을 공유하도록 허용하는, 일반 저장 컨테이너(container)로서 동작한다. 메모리 제약들 및 성능 요건들이 보안 요소(112) 상에 저장될 수 있는 로열티/오퍼들 데이터의 양을 제한한다면, 부가적인 데이터는 이동 디바이스 메모리(111b)에 저장되며 상거래 위젯(115)을 통해 소비자에 의해 관리될 수 있다. 예를 들면, 오퍼와 관련 있는 임의의 그래픽 이미지들이 보안 요소 메모리 할당을 최적화하기 위해 메모리(111b)에 저장될 수 있다. 로열티/오퍼 데이터 관리는 대응하는 오퍼 플랫폼(131), 로열티 플랫폼(132), 또는 보상 플랫폼(133)에 의해 핸들링될 수 있다.

상거래 애플릿(113)은 주어진 판매자와 관련 있는 모든 데이터의 저장/관리를 가능하게 하는 캐싱(caching)된 판매자 데이터 표를 포함한다. 이것은 주어진 판매자를 위한 상거래 데이터가 지갑 애플리케이션에 의해 보안 요소(112) 또는 이동 디바이스(110)에 사전-로딩(loading)되도록 허용한다. 캐싱된 판매자 데이터 표에 포함되는 대표적인 상거래 요소들(및 태그 길이 값(TLV; Tag Length Value) 인코딩(encoding) 동안 사용된 그것들의 대응하는 태그 값들)이 이하에 정의된다. 이러한 데이터는 기록 지향 데이터 버퍼(buffer)에 저장된다. 대표적인 실시예에서, 판매자 식별자(Merchant Identifier)는 탐색/검색 태스크들을 위한 키 필드(key field)로서 사용된다. 선택적으로, 인덱스(index)(또는 해시 테이블(hash table))가 성능을 개선하기 위해 생성될 수 있다.

하나 이상의 상거래 애플릿들(113)이 예를 들면, 보안 요소(112)의 제조 및/또는 구성 동안 보안 요소(112) 상으로 로딩될 수 있으며 그것의 사용이 상거래 트랜잭션들을 행할 수 있게 하기 위해 개인화될 수 있다. 상거래 애플릿(113)은 상거래 애플리케이션 프로그래밍 인터페이스(API; application programming interface)(123)를 통해 판독기(120)와 인터페이스한다. 대표적인 실시예에서, 상거래 애플릿(113)은 자바카드 애플릿의 형태에 있으며 ISO 7816-4에 정의된 바와 같이 APDU 명령어들의 사용을 통해 액세스 가능하다. 특히, 상거래 애플릿(113)은 NFC ISO 14443 프로토콜을 통해 ISO 7816 명령어들을 사용하여 보안 요소(112)를 통해 판독기(120)에 상거래 요소들을 전달한다.

또한 보안 요소(112)는 각각의 지불 애플릿(117)이 지불 서비스 제공자에 의해 발행된 계좌 및 지불 서비스와 연관되는 하나 이상의 지불 애플릿들(117)을 포함할 수 있다. 또한 하나 이상의 지불 애플릿들(117)은 예를 들면, 보안 요소(112)의 제조 및/또는 구성 동안 보안 요소(112) 상으로 로딩될 수 있으며 그것의 사용이 지불 트랜잭션들을 행할 수 있게 하기 위해 개인화될 수 있다. 지불 애플릿(117)은 API(124)를 통해 판독기(120)와 인터페이스한다. 대표적인 실시예에서, 지불 애플릿(117)은 자바카드 애플릿의 형태에 있으며 ISO 7816-4에 정의된 바와 같이 APDU 명령어들의 사용을 통해 액세스 가능하다. 또한 지불 애플릿(113)은 NFC ISO 14443 프로토콜을 통해 ISO 7816 명령어들을 사용하여 보안 요소(112)를 통해 판독기(120)에 지불 요소들을 전달한다.

앞서 언급한 디바이스들 사이에서의 다른 통신들은 다른 중재 시스템들, 하드웨어, 및/또는 소프트웨어와의 또는 그것들을 통한 통신들을 포함할 수 있으며 그러한 통신들은 데이터를 수신, 전달, 및/또는 관리하는 것을 포함할 수 있다는 것이 이해되어야 한다.

이동 디바이스(110) 상에 저장된 지갑 애플리케이션(114)은 이동 디바이스(110)의 프로세서에 의해 실행될 때, 이동 디바이스(110)로 하여금 예를 들면, 무접촉 상거래 및/또는 지불 트랜잭션들과 같은 트랜잭션들을 프로세싱하기 위한 기구로서 동작하게 하는 지시들을 포함한다. 지갑 애플리케이션(114)은 ISO 7816-4에 정의된 바와 같은 APDU 명령어들의 사용을 통해, 상거래 API(116)를 통해 상거래 애플릿(113)과 통신하며 지불 API(118)를 통해 지불 애플릿(117)으로 전달한다.

상거래 위젯(115)은 예를 들면, 이동 디바이스의 디스플레이 또는 사용자 인터페이스와의 상호작용들을 통해, 상거래 요소들(예컨대, 로열티 카드 크리덴셜들, 오퍼들 및 보상들)을 관리하기 위해 소비자들을 위한 인터페이스를 제공하는 지갑 애플리케이션(114)의 구성요소이다. 상거래 위젯(115)은 예를 들면, 이동 디바이스(예컨대, 111b)의 메모리에서의 핸드셋(handset) 상에 존재하는 상거래 요소들의 마스터 리스트(master list)를 유지한다. 사용될 준비가 된 것으로 식별되어 온 오퍼들의 서브세트는 결과적으로 무접촉 판독기(120) 및 POS 단말기(140)에 전달되도록 보안 요소(112)로 이동된다. 로열티 계좌 식별자들과 같은, 민감 정보가 보안 요소(112) 상에 저장될 수 있다.

지불 위젯(119)은 예를 들면, 이동 디바이스의 디스플레이 또는 사용자 인터페이스와의 상호작용들을 통해, 지불 요소들(예컨대, 신용 또는 직불 카드 크리덴셜들)을 관리하기 위해 소비자들을 위한 인터페이스를 제공하는 지갑 애플리케이션(114)의 구성요소이다.

판독기(120)는 판독기 상거래 애플리케이션(121)(본 명세서에 간단히 "판독기 애플리케이션"으로서 불리우는) 및 POS 인터페이스(122)를 포함한다. 판독기(120)는 두 개의 인터페이스들을 관리하나: 하나의 인터페이스는 이동 디바이스(110)에서의 보안 요소(112)와 함께이며 다른 인터페이스는 판독기 인터페이스(141) 및 상거래 애플리케이션 데이터 핸들러(142)를 포함하는 POS 단말기(140)와 함께이다. 판독기(120)의 기능은 판독기(120)가 독립형이며 지불 단말기 또는 판매자 POS에 연결되거나, 또는 그 안에 통합되는지에 관계없이 동일하다. 또한 무접촉 지불 기능은 판독기(120)에 포함되지만 도시되지 않는다.

또한 이동 디바이스(110)는 이동 지갑 플랫폼(130)에 통신적으로 결합되며, 이것은 결과적으로 오퍼 플랫폼(131), 로열티 플랫폼(132) 및 보상 플랫폼(133)에 통신적으로 결합된다. 총괄하여, 오퍼 플랫폼(131), 로열티 플랫폼(132) 및 보상 플랫폼(133)은 이동 상거래(MoCom) 플랫폼(134)으로서 불리울 수 있으며 본 명세서에 개별적으로 및 총괄하여 MoCom 서버(이제 도시됨)로 불리우는, 하나 이상의 서버들 상에 구현된다.

일 실시예에서, 고객은 판독기(120)를 구비한 POS에서 무접촉 트랜잭션을 행하기 위해 이동 디바이스(110)를 사용할 수 있다. 고객은 이동 디바이스(110)의 CLF(111c)로 하여금, 예를 들면, NFC ISO 14443 프로토콜들을 사용하여 판독기(120)와 통신하게 하는 무접촉 판독기(120)(즉, 탭들)의 미리 결정된 요구된 근거리 내에 이동 디바이스(110)를 배치한다. 또한 판독기(120)는 무접촉 트랜잭션들을 실행하기 위해 이동 디바이스(110) 상에서 지갑 애플리케이션(114), 상거래 애플릿(113), 및/또는 지불 애플리케이션들과 통신한다.

보안 요소는 보안 요소(112) 내에 현재 저장된 이용 가능한 크리덴셜들의 디렉토리(directory)로서 작용하는 근거리 지불 시스템 환경(PPSE; Proximity Payment System Environment)을 이용한다. 각각의 크리덴셜은 지불 애플리케이션과 연관되며 PPSE에 저장된 대응하는 애플리케이션 식별자(AID; application identifier)를 할당받는다. 보안 요소(112)를 포함한 NFC 가능-이동 디바이스가 NFC-가능 무접촉 판독기의 부근에 위치될 때, 무접촉 판독기는 크리덴셜을 판독하며 트랜잭션을 완료한다. 그러나, 그렇게 하기 전에, 판독기는 초기화된다.

이동 디바이스(110) 상에서, PPSE는 보안 요소(112) 상에 저장된 지불 애플리케이션들의 리스트를 유지하기 위해 사용된 애플리케이션이며, 그것들을 시스템들 또는 디바이스들에 대해 가시적이거나 또는 가시적이지 않게(즉, 액세스 가능하게) 만듦으로써 이동 디바이스(112) 상에 저장된 각각의 지불 애플리케이션에 대한 액세스 가능성을 제공한다.

판독기 초기화

판독기(120)의 초기화가 이제 보다 상세히 설명될 것이다. 일 실시예에서, 판독기(120)는 이동 디바이스에서의 어떤 애플리케이션이 선택되는지를 제어하기 위해 엔트리 포인트 관리기(EPM; Entry Point Manager)로서 불리우는 기능을 구현한다. 이 실시예에서, EPM은 판독기(120)가 상거래 트랜잭션을 수행하는 애플리케이션을 선택하기 위한 명령어 또는 지불 트랜잭션을 수행하는 명령어를 이동 디바이스(110)에 전송할지 여부를 제어한다. 상거래 애플리케이션을 선택하기 위한 명령어는 본 명세서에서 "상거래 선택"으로서 불리운다. 지불 애플리케이션을 선택하기 위한 명령어는 본 명세서에서 "PPSE 선택"으로서 불리운다.

또한 EPM은 체크아웃(checkout) 프로세스 동안 판독기(120)를 위한 시작 모드 및 후속 애플리케이션 스위칭(switching)을 제어한다. 따라서 EPM은 상거래 트랜잭션을 위한 상거래 선택 명령어 및 지불 트랜잭션들을 위한 PPSE 선택 명령어 사이에서의 스위칭을 용이하게 한다(판독기(120)에서).

판독기 상에서 상거래 트랜잭션을 시작

판독기는 이하에서 추가로 상세히 설명되는, 여러 개의 모드들에 따라 판독기 상에서의 상거래 트랜잭션을 개시하도록 구성될 수 있다. "자동 시작"으로서 불리우는, 일 모드에서, 판독기 애플리케이션(121)은 판독기(120) 상에서의 디폴트(default) 애플리케이션이다. 디폴트 애플리케이션은 판독기 애플리케이션(121)이 제 1 탭 옵션(즉, 이동 디바이스(110) 및 무접촉 판독기(120) 사이에서의 초기 결합 통신 시)으로서 소비자에게 이용 가능하도록 허용한다.

"수동 시작"으로서 불리우는, 또 다른 모드는 수동 개입이 판독기 상거래 애플리케이션(121)을 개시하기 위해 사용되도록 허용한다. 수동 개입은 POS 단말기(130)(예컨대, POS 단말기 인터페이스를 사용함으로써 개시된)로부터의 또는 상거래 위젯(115)을 사용함으로써 이동 디바이스 상에서 상거래 애플리케이션을 선택하는 소비자로부터의 명령어의 형태일 수 있다.

"트랜잭션 후 데이터를 가진 지불"로서 불리우는, 또 다른 모드는 지불들이 활동 시스템에서 어떻게 핸들링되는지를 제어하는 것을 수반한다. 예를 들어, 판매자가 트랜잭션 후 데이터의 공급을 지원한다면, 판매자 데이터의 지불 및 수신은 트랜잭션에 대한 최종 합계가 산출된 후와 같이, 동일한 탭 이벤트에 의해 성취될 수 있다.

또 다른 모드는 "지불 우선"으로서 불리운다. 지불 우선 옵션은 상거래 데이터(예컨대, 로열티 데이터, 오퍼 데이터, 보상 데이터 등)를 획득하기 위해 지불을 위한 PPSE 선택 명령어, 및 그 후 상거래 선택 명령어를 개시하기 위해 자동 시작 모드 및/또는 수동 시작 모드와 함께 작동한다. 상거래 데이터는 본 명세서에서 "상거래 요소들"로서 상호 교환 가능하게 불리운다.

자동 시작 모드

도 1을 참조하면, 자동 시작 모드는 POS 체크아웃 프로세스의 처음에 판독기(120) 상에서 상거래 기능을 제공한다. 이동 디바이스(110)가 판독기(120)를 탭핑할 때, 판독기 애플리케이션(121)은 판독기(120)로 하여금 무접촉 트랜잭션을 실행하기 위해 사용될 상거래 애플리케이션에 대응하는 AID를 포함한 "상거래 선택(Select Commerce)" 메시지를 이동 디바이스(110)에 전송하게 한다. 메시지가 이동 디바이스(110)에 의해 수용된다면, 그것은 반응으로 긍정 응답 메시지를 전송한다. 다음으로, 판독기(120)는 "상거래 데이터 획득(Get Commerce Data" 명령어를 이동 디바이스(110)에 전송한다. 상거래 데이터 획득 명령어는 상거래 트랜잭션을 수행하기 위해 보안 요소(112)가 사용하는 판매자 특정 데이터를 포함한다. 또한, 상거래 데이터 획득 트랜잭션의 성공적인 완료 시 제어가 이동 디바이스(110)로 넘어간다. 판독기(120)가 "상거래 선택" 메시지에 대한 부정 응답을 수신한다면, 그것은 제어를 다시 EPM으로 전달한다.

수동 시작 모드

여전히 도 1을 참조하면, 수동 시작 모드에서, 판독기(120)는 소비자 또는 POS 단말기(140)로부터의 요청에 응답하여 판독기 애플리케이션(121)을 시작한다. 이러한 수동 시작 모드에서, 체크아웃 프로세스의 처음에, 판독기(120)는 PPSE 선택 상태에 있다. 소비자 개시 상거래 트랜잭션을 위해, 소비자는 고객 응대 디바이스(예컨대, 상거래 위젯(115))에서 상거래 애플리케이션을 선택한다. 고객 응대 디바이스는 그 후 EPM을 통해 판독기 애플리케이션(121)을 시작하기 위해 판독기(120)에 명령어를 전송한다. POS 단말기 개시 상거래 트랜잭션을 위해 POS 단말기(140)는 판독기 애플리케이션(121)을 초기화하도록 판독기(120)에 명령한다. 일 실시예에서, 이것은 POS 단말기(140) 상에서의 인터페이스를 통해 계산원에 의해 개시된다.

일단 판독기 상거래 애플리케이션(121)이 판독기(120) 상에서 시작된다면, 상거래 애플리케이션은 상기 자동 시작 모드에 설명된 바와 같이 기능할 것이다.

트랜잭션 후 데이터를 가진 지불

트랜잭션 후 데이터를 가진 지불 모드에서, 지불 트랜잭션은 트랜잭션 후 데이터가 POS 단말기(140), 판독기(120), 및 보안 요소(112) 사이에서 전달되도록 이루어질 수 있다. 이러한 옵션은 상거래 프로토콜이 소비자 체크아웃의 처음에 시작하도록 허용하지만, 지불은 최종 트랜잭션 합계가 산출될 때까지 판독기(120)에 의해 요청되지 않는다.

POS 단말기(140)는 예를 들면, 트랜잭션 식별자(ID) 및 상환 쿠폰 ID들을 갖는 "트랜잭션 후(Post Transaction)" 명령어를 판독기(120)에 전송한다. 판독기(120)는 그 후 지불을 위한 탭에 대한 요청을 송신한다. 탭은 판독기(120)가 먼저 보안 요소(112)로부터 지불 크리덴셜을 요청하며 그 후 판독기 애플리케이션(121)으로 하여금 보안 요소(112)로 상거래 데이터(예컨대, 쿠폰 데이터)를 전송하게 하도록 허용한다. 양 기능들 모두는 판독기(120)에서 이동 디바이스(110)에 의해 단일 탭에서 수행된다.

우선 지불

우선 지불 모드에서, 지불은 상거래 트래잭션 이전에, 먼저 이루어질 수 있다. 이러한 옵션은 지불/PPSE 프로세스가 임의의 상거래 프로세싱에 앞서야 하는 상황을 수용한다. 우선 지불 모드는 상기 논의된 자동 및 수동 시작 모드들 모두와 함께 작동한다. 지불 및 상거래 프로세싱은 단일 탭에서 성취된다.

대표적인 상거래 프로세스 흐름들

정상 상거래 프로세스 흐름(단일 탭)

도 2는 대표적인 실시예에 따른 단일 탭 타이밍 도(200)를 예시한다. 다음의 프로세스 흐름은 구매되는 아이템들(items)이 POS에서 스캐닝(scanning)됨에 따라 시작될 수 있다. 편의상, 판독기(120)(도 1) 및 POS 단말기(140)(도 1)는 단일 구성요소로서 예시되며 총괄하여 지불 단말기(201)로서 불리운다. 각각의 구성요소(즉, 판독기(120) 또는 POS 단말기(140))는 적용 가능할 때 개별적으로 나타내어진다.

판매자 POS 시스템(202)은 지불 단말기(201)의 동작을 제어하는 판매자에 의해 동작되는 판매자 서버일 수 있다. 대표적인 실시예에서, 판매자 POS 시스템(202)은 아이템들이 스캐닝되기 전에, 아이템들이 스캐닝될 때 또는 아이템들이 스캐닝된 후 판독기를 활성화시키도록("판독기 활성화(Activate Reader)") 지불 단말기(201)에 명령한다. 각각의 경우에서, 판독기(120)는 단계(250)("'탭' 요청(Request 'tap')")에 도시된 바와 같이, 판독기(120)에 근접하여 이동 디바이스(110)를 위치시키도록 사용자(또는 소비자)에게 요청한다. 판독기(120)에 근접하여 이동 디바이스(110)를 위치시키기 위한 사용자에 대한 요청에 응답하여(단계(250)), 소비자는 단계(251)에 도시된 바와 같이, 판독기(120) 상으로 이동 디바이스(110)를 탭핑한다.

일단 NFC 연결이 이동 디바이스(110) 및 판독기(120) 사이에서 수립된다면, 다음의 명령어 교환들은 지불 트랜잭션 및 상거래 트랜잭션 양자 모두의 서비스 초기화 및 프로세싱을 위해 개시된다. 보안 요소(112) 및 판독기(120) 사이에서의 지불 트랜잭션 초기화 및 프로세싱 교환들은 단계들(260)을 포함하며 보안 요소(112) 및 판독기(120) 사이에서의 상거래 트랜잭션 초기화 및 프로세싱 교환들은 단계들(262)을 포함한다. 단계들(260)은 단계들(262) 전에, 나중에, 또는 실질적으로 동시에 수행될 수 있다.

먼저 단계들(262)을 참조하면, 이동 디바이스가 판독기(120)를 탭핑한 후, 판독기(120)는 그것이 보안 요소(112) 내의 어떤 상거래 애플릿과 협력하고자 하는지(예컨대, 상거래 애플릿(113))를 표시하는 특정한 상거래 AID("상거래 AID 선택(Select Commerce AID)")와 함께 상거래 선택 명령어를 보안 요소(112)에 전송한다. 이에 응답하여, 보안 요소(112)는 긍정 또는 부정 응답을 전송한다. 부정 응답(도시되지 않음)은 판독기(120)가 판독기 애플리케이션(121)(도 1)을 종료하고 제어를 EPM(도시되지 않음)으로 넘기는 것을 야기한다. 응답이 긍정이라면("긍정 응답(Positive Response)"), 판독기(120)는 그 후 임의의 판매자 능력 데이터, 및 판독기(120)에 의해 지원되는 판독기 상거래 애플리케이션(121)의 버전(version), 위치, 날짜 및 시간 정보에 의해 지원되는 임의의 부가적인 로열티, 오퍼 또는 보상 기법들, 및 판매자/상점 식별자와 같은, 식별 정보를 특정하는 명령어("상거래 데이터 획득")를 보안 요소(112)에 전송한다.

보안 요소(112)는 판독기(120)로부터 수신된 상거래 데이터 획득 명령어에서의 필드들에 기초하여 판독기(120)("로열티 및 오퍼 데이터(Loyalty & Offers Data")로 대응하는 상거래 요소들(예컨대, 로열티 데이터, 오퍼 데이터, 보상 데이터)을 리턴(return)한다. 일 실시예에서, 상거래 애플릿(113)은 상거래 데이터를 포함한 패키지(package)(예컨대, 로열티 데이터, 오퍼 데이터, 또는 보상 데이터를 포함한 버퍼 또는 버퍼들의 세트)를 형성한다. 또 다른 실시예에서, 버퍼는 보안 요소(112)에서의 메모리 공간을 사용하여 사전-형성된다.

단계들(260)을 참조하면, 일 실시예에서, 판독기(120)는 PPSE 요청("PPSE 선택(PPSE Select)")을 보안 요소(112)에 전송함으로써 지불 프로세싱을 시작한다.

단계(264)("성공 표시 판독(Read Success Indication)")에 도시된 바와 같이, 상거래 AID 선택 및 PPSE 선택 요청들이 성공적이면, 지불 단말기(201)는 그것이 수신한 상거래 애플리케이션 데이터 및 지불 크리덴셜들을 프로세싱("지불 및 상거래 데이터(Payment & Commerce Data)")을 위해 판매자 POS 시스템(202)으로 포워딩한다. 판매자 POS 시스템(202)은 결과적으로 로열티 식별자 및 오퍼들(도시되지 않음)을 기록하며 단계(266)에 도시된 바와 같이 제품 스캐닝이 계속됨에 따라 임의의 적용 가능한 할인들을 적용한다. 이는 상거래 애플리케이션 프로세스를 마치고 지불 프로세싱을 진행한다.

일단 스캐닝이 완료되고 트랜잭션 양이 지불을 위해 승인된다면, 지불 플랫폼(203)에 대한 지불 권한 요청이 이루어진다("지불 권한 요청(Payment Auth Request)"). 결과적으로, 지불 플랫폼(203)은 지불이 허가되었는지 여부를 표시하는 권한 결과("권한 결과(Authorization Result)")를 리턴한다.

다시 단계들(260)을 참조하면, 일 실시예에서, 보안 요소(112)로의 판독기(120)에 의한 PPSE 선택 요청은 보안 요소(112)로 하여금 어떤 지불 애플릿(및 그러므로 대응하는 지불 네트워크)이 지불 트랜잭션을 수행하기 위해 사용되어야 하는지를 표시하는 PPSE 지불 AID를 리턴하게 한다("PPSE 지불 AID(PPSE Payment AID)"). 이에 응답하여, 판독기(120)는 그것이 특정한 애플릿을 지원함을 표시하는 AID 선택("AID 선택(Select AID)")을 전송한다. 지불 애플릿(예컨대, 도 1, 117)과 연관된 파일 제어 정보(FCI; File control information)가 보안 요소(112)에 의해 판독기(120)에 전송된다. 유사하게, 다른 지불 및 카드 정보가 보안 요소(112)에 의해 판독기(120)에 전송된다("지불/카드 데이터(Payment/Card Data)").

도 3은 대표적인 실시예에 따른 이중 탭 및 트랜잭션 후 데이터 송신을 포함한 상거래 프로세스 흐름을 예시한 타이밍 도(300)를 도시한다. 이 실시예는 판매자가 이동 디바이스로 다시 전달하기 위한 데이터를 가질 때 사용될 수 있다. 편리함을 위해, 판독기(120)(도 1) 및 POS 단말기(140)(도 1)는 단일 구성요소로서 예시되며 총괄하여 지불 단말기(301)로 불리운다. 각각의 구성요소(즉, 판독기(120) 또는 POS 단말기(140))는 적용 가능할 때 개별적으로 나타내어진다. 일반적으로, POS 단말기(140)(도 1)는 명령어("트랜잭션 후 명령어(Post Transaction Command)")를 판독기(120)에 전송함으로써 제 2 탭에 대한 요청을 개시한다. 판독기(120)는 결과적으로, 소비자로부터의 제 2 탭을 요청한다.

판매자 POS 시스템(302)은 지불 단말기(301)의 동작을 제어하는 판매자에 의해 동작된 판매자 서버일 수 있다. 대표적인 실시예에서, 판매자 POS 시스템(302)은 아이템들이 스캐닝되기 전에, 아이템들이 스캐닝될 때, 또는 아이템들이 스캐닝된 후 판독기(120)를 활성화시키도록("판독기 활성화(Activate Reader)") 지불 단말기(301)에 명령한다. 각각의 경우에서, 판독기(120)는 단계(350)("'탭' 요청(Request 'tap')")에 도시된 바와 같이, 판독기(120)에 근접하여 이동 디바이스(110)를 위치시키도록 사용자에게 요청한다. 판독기(120)에 근접하여 이동 디바이스(110)를 위치시키기 위한 사용자에 대한 요청에 응답하여(단계(350)), 소비자는 단계(351)에 도시된 바와 같이, 판독기(120) 상으로 이동 디바이스(110)를 탭핑한다.

일단 NFC 연결이 이동 디바이스(110) 및 판독기(120) 사이에서 수립된다면, 다음의 명령어 교환들은 지불 트랜잭션 및 상거래 트랜잭션 양자 모두의 서비스 초기화 및 프로세싱을 위해 개시된다. 보안 요소(112) 및 판독기(120) 사이에서의 지불 트랜잭션 초기화 및 프로세싱 교환들은 단계들(360)을 포함하며 보안 요소(112) 및 판독기(120) 사이에서의 상거래 트랜잭션 초기화 및 프로세싱 교환들은 단계들(362)을 포함한다. 단계들(360)은 단계들(362) 전에, 나중에, 또는 실질적으로 동시에 수행될 수 있다.

먼저 단계들(362)을 참조하면, 이동 디바이스(110)가 판독기(120)를 탭핑한 후, 판독기(120)는 그것이 보안 요소(112) 내에서의 어떤 상거래 애플릿과 협력하고자 하는지(예컨대, 상거래 애플릿(113))를 표시하는 특정한 상거래 AID와 함께 상거래 선택 명령어("상거래 AID 선택")를 보안 요소(112)에 전송한다. 이에 응답하여, 보안 요소(112)는 긍정 또는 부정 응답을 전송한다. 부정 응답(도시되지 않음)은 판독기(120)가 판독기 애플리케이션(121)(도 1)을 종료하고 제어를 EPM(도시되지 않음)으로 넘기는 것을 야기한다. 응답이 긍정이라면("긍정 응답"), 판독기(120)는 그 후 임의의 판매자 능력 데이터 및 판독기(120)에 의해 지원되는 판독기 상거래 애플리케이션(121)의 버전, 위치, 날짜 및 시간 정보에 의해 지원되는 임의의 부가적인 로열티 및 오퍼 기법들, 및 판매자/상점 식별자와 같은, 식별 정보를 특정하는 명령어를 보안 요소(112)에 전송한다("상거래 데이터 획득"). 보안 요소(112)는 판독기(120)로부터 수신된 상거래 데이터 획득 명령어에서의 필드들에 기초하여 판독기(120)로 대응하는 상거래 요소들(예컨대, 로열티 및 오퍼들 데이터)을 리턴한다("로열티 및 오퍼들 데이터"). 일 실시예에서, 이것은 데이터의 패키지(근본적으로 오퍼들 및 로열티 데이터를 포함한 버퍼 또는 버퍼들의 세트)를 형성하는, 상거래 애플릿(113)에 의해 성취된다. 또 다른 실시예에서, 버퍼는 보안 요소(112)에서의 메모리 공간을 사용하여 사전-형성될 수 있다.

다음으로 단계들(360)을 참조하면, 일 실시예에서, 보안 요소(112)에 대한 판독기(120)에 의한 PPSE 선택 요청은 보안 요소(112)로 하여금 어떤 지불 애플릿(및 그러므로 지불 네트워크)이 지불 트랜잭션을 수행하기 위해 사용되어야 하는지를 표시하는 PPSE 지불 AID를 리턴하게 한다("PPSE 지불 AID"). 이에 응답하여, 판독기(120)는 그것이 특정한 애플릿을 지원함을 표시하는 AID 선택을 전송한다("AID 선택"). 지불 애플릿(예컨대, 117)과 연관된 FCI는 보안 요소(112)에 의해 판독기(120)에 전송된다. 유사하게, 다른 지불 및 카드 정보가 보안 요소(112)에 의해 판독기(120)에 전송된다("지불/카드 데이터"). 단계(364)에 도시된 바와 같이, 상거래 AID 선택 및 PPSE 선택 요청들이 성공적이라면, 지불 단말기(301)는 그것이 수신한 상거래 애플리케이션 데이터 및 지불 크리덴셜들을 프로세싱을 위한 판매자 POS 시스템(302)으로 포워딩한다("지불 및 상거래 데이터"). 판매자 POS 시스템(302)은 결과적으로, 로열티 식별자 및 오퍼들(도시되지 않음)을 기록하며 단계(366)에 도시된 바와 같이 제품 스캐닝이 계속됨에 따라 임의의 적용 가능한 할인들을 적용한다.

일단 스캐닝이 완료되고 트랜잭션 양이 지불을 위해 승인된다면, 지불 플랫폼(303)에 대한 지불 권한 요청이 이루어진다("지불 권한 요청"). 결과적으로, 지불 플랫폼(303)은 지불이 이루어졌는지 여부를 표시하는 권한 결과("권한 결과")를 리턴한다.

지불 단말기(301)로 되돌려 보낼 데이터가 있다면, 판매자 POS 시스템은 정확하게 포맷팅(formatting)된 TLV들을 갖고, 명령어, "트랜잭션 후 데이터"를 생성하며 데이터를 판독기(120)로 포워딩한다. 트랜잭션 후 명령어의 수신 시, 지불 단말기(301)는 단계(368)에 도시된 바와 같이("제 2 탭 요청"), 소비자로부터 제 2 탭을 요청할 것이다.

단계(369) 및 단계들(370)을 참조하면, 이동 디바이스(110)가 단계(369)에 도시된 바와 같이 제 2 시간 동안 판독기(120)의 근거리 내에 위치될 때, 판독기(120)는 그것이 보안 요소(112) 내에서의 어떤 상거래 애플릿과 협력하고자 하는지(예컨대, 상거래 애플릿(113))를 표시하는 특정한 상거래 AID와 함께 상거래 선택 명령어("상거래 AID 선택")를 보안 요소(112)에 전송한다.

부정 응답이 수신된다면, 판독기(120)는 판독기 상거래 애플리케이션(121)을 종료한다. 긍정 응답이 수신된다면, 판독기(120)는 POS 단말기(140)로부터의 트랜잭션 후 데이터 명령어에서 수신된 데이터를 보안 요소(112)로 포워딩한다("트랜잭션 후 데이터"). 이는 이러한 트랜잭션을 위한 상거래 절차를 끝낸다.

도 4는 대표적인 실시예에 따른 이중 탭, 및 트랜잭션 후 데이터 및 지불 송신들을 포함한 상거래 프로세스 흐름을 예시한 타이밍 도(400)를 도시한다. 이 시나리오에서, 지불 및 트랜잭션 후 데이터는 바구니가 합산되며 모든 할인들이 적용된 후 프로세싱된다. 이러한 흐름의 사용은 그것 상에 설정된 특정한 비트(예컨대, "트랜잭션 후를 가진 지불")를 갖는 판독기 시작 모드 데이터 요소에 의해 제어된다.

편의상, 판독기(120)(도 1) 및 POS 단말기(140)(도 1)는 단일 구성요소로서 예시되며 총괄하여 지불 단말기(401)로서 불리운다. 각각의 구성요소(즉, 판독기(120) 또는 POS 단말기(140))는 적용 가능할 때 개별적으로 나타내어진다. 일반적으로, 판매자 POS 시스템(402)은 트랜잭션 후 데이터 명령어를 판독기(120)에 전송함으로써 제 2 탭에 대한 요청을 개시한다. 판독기(120)는 결과적으로, 소비자로부터의 제 2 탭을 요청한다.

판매자 POS 시스템(402)은 지불 단말기(401)의 동작을 제어하는 판매자에 의해 동작된 판매자 서버일 수 있다. 대표적인 실시예에서, 판매자 POS 시스템(402)은 아이템들이 스캐닝되기 전에, 아이템들이 스캐닝될 때 또는 아이템들이 스캐닝된 후, 판독기를 활성화시키도록 지불 단말기(401)에 명령한다("판독기 활성화"). 각각의 경우에, 판독기(120)는 단계(450)에 도시된 바와 같이("'탭' 요청"), 판독기(120)에 근접하여 이동 디바이스(110)를 위치시키도록 사용자에게 요청한다. 판독기(120)에 근접하여 이동 디바이스(110)를 위치시키기 위한 사용자에 대한 요청에 응답하여(단계(450)), 소비자는 단계(451)에 도시된 바와 같이, 판독기(120) 상으로 이동 디바이스(110)를 탭핑한다.

일단 NFC 연결이 이동 디바이스(110) 및 판독기(120) 사이에 수립된다면, 다음의 명령어 교환들이 개시된다. 명령어 교환들은 지불 트랜잭션 및 상거래 트랜잭션 양자 모두의 서비스 개시 및 프로세싱을 위해 수행된다. 보안 요소(112) 및 판독기(120) 사이에서의 지불 트랜잭션 초기화 및 프로세싱 교환들은 단계들(472)을 포함하며, 보안 요소(112) 및 판독기(120) 사이에서의 상거래 트랜잭션 교환 및 프로세싱 교환들은 단계들(462 및 474)을 포함한다.

먼저 단계들(462)을 참조하면, 이동 디바이스가 판독기(120)를 탭핑한 후, 판독기(120)는 보안 요소(112) 내의 어떤 상거래 애플릿과 협력하고자 하는지(예컨대, 상거래 애플릿(113))를 표시하는 특정한 상거래 AID와 함께 상거래 선택 명령어("상거래 AID 선택")를 보안 요소(112)에 전송한다. 이에 응답하여, 보안 요소(112)는 긍정 또는 부정 응답을 전송한다. 부정 응답(도시되지 않음)은 판독기(120)가 판독기 애플리케이션(121)(도 1)을 종료하고 제어를 EPM(도시되지 않음)으로 넘기는 것을 야기한다. 응답이 긍정이라면("긍정 응답"), 판독기(120)는 그 후 임의의 판매자 능력 데이터 및 판독기(120)에 의해 지원되는 판독기 상거래 애플리케이션(121)의 버전, 위치, 날짜 및 시간 정보에 의해 지원되는 임의의 부가적인 로열티 및 오퍼 기법들, 및 판매자/상점 식별자와 같은, 식별 정보를 특정하는 명령어를 보안 요소(112)에 전송한다("상거래 데이터 획득"). 보안 요소(112)는 판독기(120)로부터 수신된 상거래 데이터 획득 명령어에서의 필드들에 기초하여 판독기(120)로 대응하는 상거래 요소들(예컨대, 로열티 및 오퍼들 데이터)을 리턴한다("로열티 및 오퍼들 데이터"). 일 실시예에서, 이것은 데이터의 패키지(예컨대, 오퍼들 및 로열티 데이터를 포함한 버퍼 또는 버퍼들의 세트)를 형성하는, 상거래 애플릿(113)에 의해 성취된다. 또 다른 실시예에서, 버퍼는 보안 요소(112)에서의 메모리 공간을 사용하여 사전-형성될 수 있다.

단계(464)에서, 판독기(120)는 트랜잭션이 완료되며 핸드셋이, 판독기(120)로 하여금 상거래 애플리케이션 데이터를 POS 단말기(140), 및 차례로 프로세싱을 위한 판매자 POS 시스템로 포워딩하게 하는, 지불 단말기(401)로부터 제거될 수 있음을 소비자에게 표시한다("로열티 및 오퍼들 데이터"). 점원은 장바구니를 계속해서 프로세싱할 수 있다.

판매자 POS 시스템(402)은 로열티 식별자 및 오퍼들(도시되지 않음)을 기록하며 단계(466)에 도시된 바와 같이 제품 스캐닝이 계속됨에 따라 임의의 적용 가능한 할인들을 적용한다. 바구니 합계가 산출된 후, 판매자 POS 시스템(402)은 지불을 위한 요청을 지불 단말기(401)에 전송하며 트랜잭션 후 데이터를 지불 단말기(401)에 전송한다(데이터가 전송하기 위해 이용 가능하다면)("트랜잭션 후 데이터 및 지불 요청 전송").

단계(468)에서, 지불 단말기(140)는 지불을 위한 탭을 요청한다. 판독기(120)는 결과적으로 판독기 필드를 활성화시킨다. 이동 디바이스(110)가 판독기(120)의 필드에서 검출될 때, 지불 프로세싱은 단계들(472)에 도시된 바와 같이 수행된다. 특히, 보안 요소(112)에 대한 판독기(120)에 의한 PPSE 선택 요청은 보안 요소(112)로 하여금 어떤 지불 애플릿(및 그러므로 지불 네트워크)이 지불 트랜잭션을 수행하기 위해 사용되어야 하는지를 표시하는 PPSE 지불 AID를 리턴하게 한다("PPSE 지불 AID"). 이에 응답하여, 판독기(120)는 그것이 특정한 애플릿을 지원함을 표시하는 AID 선택 명령어를 전송한다("AID 선택"). 지불 애플릿(예컨대, 117)과 연관된 FCI는 보안 요소(112)에 의해 판독기(120)에 전송된다. 유사하게, 다른 지불 및 카드 정보가 보안 요소(112)에 의해 판독기(120)에 전송된다("지불/카드 데이터").

단계들(474)을 참조하면, 지불 단말기(401)가 판매자 POS 시스템(402)으로부터 트랜잭션 후 데이터를 수신한다면, 판독기(120)는 이동 디바이스가 두 번 판독기(120)를 탭핑한 후 상거래 애플리케이션(121)(도 1)을 시작하며 특정한 상거래 AID와 함께 상거래 선택 명령어("상거래 AID 선택")를 보안 요소(112)에 전송한다. 상거래 AID 선택은 보안 요소(112) 내의 어떤 상거래 애플릿이 판독기(120)와 협력하기 위해 사용되어야 하는지를 식별한다. 이에 응답하여, 보안 요소(112)는 긍정 또는 부정 응답을 전송한다. 부정 응답(도시되지 않음)은 판독기(120)가 판독기 애플리케이션(121)(도 1)을 종료하고 제어를 EPM(도시되지 않음)으로 넘기는 것을 야기한다. 응답이 긍정("긍정 응답")이라면, 판독기(120)는 정확하게 포맷팅된 TLV들을 갖고, 보안 요소(112)에 트랜잭션 후 데이터("트랜잭션 후 데이터")를 전송한다. 이것은 이러한 트랜잭션을 위한 상거래 프로세싱을 끝낸다.

상거래 AID 선택 및 PPSE 선택 요청들이 성공적이라면, 지불 단말기(401)는 그것이 수신한 지불 애플리케이션 데이터 및 지불 크리덴셜들을 프로세싱을 위한 판매자 POS 시스템(402)으로 포워딩한다("지불/카드 데이터"). 결과적으로, 판매자 POS 시스템은 지불 권한 요청을 지불 플랫폼(403)에 전송한다("지불 권한 요청"). 결과적으로, 지불 플랫폼(403)은 지불이 허가되었는지 여부를 표시하는 권한 결과(권한 결과)를 리턴한다.

상거래 및 지불 크리덴셜들 및 정보가 성공적으로 판독되었다면, 판독기(120)는 단계(478)에 도시된 바와 같이("판독 성공 표시"), 지불 단말기(140)상의 인터페이스를 통해 상거래 위젯(115)(도 1) 또는 지불 위젯(119)(도 1)에 통지를 제공할 수 있다.

상거래 메시지 규격들

데이터 인코딩

일 실시예에서, 모든 명령어/응답 데이터는 BER-TLV(ISO 7816-4 별첨 D) 포맷을 사용하여 인코딩된다. 몇몇 경우들에서, TLV(태그(Tag), 길이(Length), 값(Value))이 내포될 수 있다(내장 TLV). TLV 인코딩 포맷의 유연한 특성으로 인해, 태깅(tagging)된 데이터는 임의의 순서로 위치될 수 있다. 이것은 인입 및 송출 페이로드들(payloads) 양자 모두를 위한 데이터를 포맷팅할 때 참이다. 또한, 이러한 데이터는 레코드 지향 표들에 저장된다. 그 안에 저장된 TLV 인코딩된 데이터 요소들의 순서는 중요하지 않지만; 몇몇 데이터는 인덱스/탐색 성능을 강화하기 위해 레코드의 처음에 위치될 수 있다. 따라서, 본 문서에 제공된 레코드 데이터 표들은 참조 목적들을 위한 샘플들(samples)로서 공급된다.

태그는 하나 이상의 후속 바이트들 상에 인코딩된 원시 데이터 객체를 표현한 "사설(private)" 태그 클래스(class) 및 태그 유형을 사용하여 인코딩된다. 그러므로, 제 1 바이트(태그 클래스)는 0xDF로 설정된다. 모든 경우들에서, 데이터 요소 태그는 단일 바이트 상에서 정의된다. 그러므로, 제 2 태그 바이트는 0으로 설정된 최상위 비트(b8)를 가진다. 이것은 128개까지의 태그 값들(0x00 내지 0x7F)을 허용한다.

길이 인코딩은 쇼트(short) 또는 롱(long) 형태들 양자 모두를 지원한다. 길이가 128 바이트들 미만(<)일 때, 최상위 비트(b8)는 0으로 설정되며 실제 길이는 나머지 비트들(b7 내지 b1)에서 특정된다. 길이가 128 바이트들 초과(>)일 때, 최상위 비트(b8)는 1로 설정되며(길이 마스크 = 0x80) 나머지 비트들(b7 내지 b1)은 길이 필드에서 후속 바이트들의 수를 정의한다. 이들 후속 바이트들은 값 필드에서의 바이트들의 수와 동일한 정수를 인코딩한다.

BER-TLV 예

인입 데이터가 8 바이트들의 길이 및 (0x1122334455667788)의 값을 가진 0x21 (소비자 ID)의 태그 값을 사용한다고 가정하면, 데이터는 표 1에 도시된 바와 같이 인코딩된다:

태그	길이	값
DF 21	08	11 22 33 44 55 66 77 88
DF 21	81 08	11 22 33 44 55 66 77 88
DF 21	82 00 08	11 22 33 44 55 66 77 88

TVL 인코딩은 길이 표시기가 다수의 바이트들로 표현되도록 허용한다. 바람직하게는 다중-바이트 길이가 지원된다. 쇼트 형태에서, 길이 필드는 비트(8)가 0으로 설정되며 비트들(7 내지 1)이 값 필드에서의 바이트들의 수를 인코딩하는 단일 바이트로 구성된다. 따라서 하나의 바이트는 0에서 127까지의 임의의 수를 인코딩한다. 0에서 127까지의 임의의 수는 Lc 및 Le 필드들에서와 같이 BER-TLV 길이 필드에서 동일한 방식으로 인코딩된다. 인코딩은 0, 128 이상에 대해 상이하다. 예를 들면, 이하에 설명된 상거래 데이터 획득 명령어에서의 데이터 객체들의 코딩을 참조하자.

롱 형태에서, 길이 필드는 2 이상의 바이트들로 구성된다. 제 1 바이트의 비트(8)는 1로 설정되며 비트들(7 내지 1)은 동일하지 않고, 따라서 길이 필드에서의 후속 바이트들의 수를 인코딩한다. 이들 후속 바이트들은 값 필드에서 바이트들의 수를 인코딩한다. ISO/IEC 7816은 1, 2, ... 5 바이트들까지(표 2)의 길이 필드들을 지원하는 ASNI ISO/IEC 7816의 기본 인코딩 규칙들에 의해 특정된 "무한 길이"를 사용하지 않는다. ISO/IEC 7816에서, 값 '80' 및 '85' 내지 'FF'는 길이 필드들의 제 1 바이트에 대해 유효하지 않다.

ISO/IEC 7816에서의 BER-TLV 길이 필드들

	제 1 바이트	제 2 바이트	제 3 바이트	제 4 바이트	제 5 바이트	N
1 바이트	'00' 내지 '7F'	- - - -				0 내지 127
2 바이트들	'81'	'00' 내지 'FF'	- - -			0 내지 255
3 바이트들	'82'	'0000' 내지 'FFFF'		- -		0 내지 65 535
4 바이트들	'83'	'000000' 내지 'FFFFFF'			-	0 내지 16 777 215
5 바이트들	'84'	'00000000' 내지'FFFFFFFF'				0 내지 4 294 967 295

상거래 선택애플릿

일 실시예에서, 프로세싱은 판독기(120)가 판독기(120)의 필드에서의 이동 디바이스(110)를 검출하며 NFC 통신들이 시작될 때 시작한다. 그때, 판독기(120)는 상거래 애플릿을 선택하기 위한 명령어, 특히 "상거래 선택" 명령어를 보안 요소(112)에 전송한다. 상거래 선택 명령어(또한 "상거래 애플릿 선택" 명령어로서 불리우는)는 ISO 78016-3 규격에 정의된 바와 같이 표준화된다. 예시적인 상거래 선택 명령어 구조가 표 3에 도시된다:

상거래 애플릿 선택

CLA	INS	P1	P2	Lc	데이터	Le
00	A4	04	00	09	A00000048510010101	00

이동 디바이스(110)에서의 보안 요소(112)는 "상거래 선택" 명령어를 검증하며 적절한 응답을 되돌려 보낸다. 예시적인 응답들(또한 "상태 코드들"로서 불리우는)이 표 4에 도시된다:

상태 코드들

SW1	SW2	설명
90	00	명령어의 성공적인 실행
67	00	잘못된 데이터 길이
69	01	지원되지 않는 애플리케이션 ID
69	99	이용 가능하지 않은 애플리케이션
6A	82	설치되지 않은 애플리케이션

'90 00'(:명령어의 성공적인 실행")이 아닌 모든 응답들은 상거래 애플리케이션(121)(도 1)으로 하여금 판독기(120)에서 종료되고 제어를 EPM으로 넘기게 한다.

상거래 데이터 획득

판독기 애플리케이션(121)의 시작 및 판독기(120) 및 보안 요소(112) 사이에서의 통신들이 개시할 때, 판독기(120)는 상거래 데이터를 획득하기 위해 명령어, "상거래 데이터 획득"을 이동 디바이스(110)에 전송한다. 대표적인 상거래 데이터 획득 명령어는 이하에서 표 5 및 표 6에 정의된다. 이 예에서, 특정 로열티 및 오퍼들 데이터가 요청되고 있다. "판매자 능력" 필드는 어떤 필드들이 요청 및 응답 데이터에 존재할 필요가 있는지를 결정하기 위해 판독기(120)에 의해 이용된다.

날짜 및 시간 스탬프(stamp) 정보는 선택적이다. 일 실시예에서, 날짜 시간은 POS와 동기화한다. 이러한 정보가 POS로부터 이용 가능하지 않은 경우에, POS 단말기(140)로부터의 날짜/시간이 사용될 수 있다. 날짜 및 시간이 이용 가능하지 않다면, 판독기(120)는 날짜 시간 스탬프 데이터 요소를 전송하지 않을 것이다.

대표적인 실시예에서, 상거래 데이터 획득 요청에 포함된 데이터 요소들은 셋업(setup) 시간에 판독기(120) 또는 POS 단말기(140)에서 사전 구성된다. 데이터는 판독기(120)가 설치되고 구성된 후 수정될 수 있다.

상거래 데이터 획득

CLA	INS	P1	P2	Lc	데이터	Le
90	50	00	00	xx	판매자 ID/ 상점 ID [+ 로열티 ID들 + 쿠폰 유형들 + 날짜/시간-스탬프 + 애플리케이션 버전 + 판매자 능력]	00

명령어 데이터

데이터 요소	바이트 크기	값	요청
판매자 식별자 태그	2	0xDF 31	Y
식별자 길이	1	xx
판매자 식별자	xx	[판매자ID]
판매자상점_ID 태그	2	0xDF 32	Y
판매자_상점_ID 길이	1	xx
판매자_상점_ID	xx	(상점ID/위치)
2차 로열티를 위한 로열티_ID 태그 #1	2	0xDF 41	선택적
식별자 길이 #1	1	xx
로열티ID #1	xx	[로열티 ID] (16진수)
.......
2차 로열티를 위한 로열티_IDr 태그 #X	2	0xDF 41	선택적
로열티 식별자 길이 #X	1	xx
로열티ID #X	xx	로열티 ID (16진수)

날짜_시간_스탬프 태그	2	0xDF 11	선택적
날짜_시간_스탬프 길이	1	0x07
날짜_시간_스탬프	7	BCD(yyyymmddhhmmss)
상거래_앱_버전 태그	2	0xDF 12	Y
상거래_앱_버전 길이	1	0x02
상거래_앱_버전 데이터	2	[주 + 부] 16진수

판매자_능력 태그	2	0xDF 33	Y
판매자_능력 길이	1	0x02
판매자_능력 데이터	2	2 바이트들 16진수

단말기_시동_모드 태그	2	0xDF 34	선택적
단말기_시동_모드 길이	1	0x02
단말기_시동_모드 데이터	1	1 바이트들 16진수
합계:	<var>

표 7은 상거래 데이터 획득 명령어에 의해 리턴될 수 있는 가능한 상태 워드(Status Word) 값들을 정의한다.

상태 코드들

SW1	SW2	설명
90	00	명령어의 성공적인 실행
61	xx	이어질 보다 많은 데이터
67	00	잘못된 데이터 길이
69	09	내부 오류

'61 xx' 또는 '90 00'이 아닌 임의의 응답은, 에러를 기록하며 상거래 위젯(115)으로 포워딩하기 위한 데이터를 저장한 후, 판독기(120)가 상거래 애플리케이션(121)을 종료하고 제어를 EPM으로 넘기는 것을 야기할 것이다.

상거래 데이터 획득 요청이 정확하게 포맷팅된다면, 보안 요소(112) 상에서의 상거래 애플릿(113)은 요청에서의 버전 번호에 기초하여 판독기(120)에 대한 응답 데이터를 포맷팅하기 위해 판매자 식별자("판매자_ID"), 로열티 식별자("로열티_ID") 및 오퍼 유형 코드("오퍼_유형_코드")에 기초하여 데이터를 필터링(filtering)한다. 상거래 애플릿(113)은 지갑에서의 구성에 기초하여 하나 이상의 로열티 ID 및 다수의 오퍼들 메시지들을 리턴할 수 있다. 표 8은 대표적인 응답 데이터를 열거한다:

예시적인 응답 데이터

데이터 요소	바이트 크기	값
소비자_ID 태그	2	0XDF21
소비자_ID 길이	1	0x10
소비자_ID 데이터	16	[소비자 ID]

로열티_ID 태그 #1	2	0xDF41
로열티_ID 길이 #1	1	xx
로열티 식별자 #1	xx	[로열티 ID]
로열티_계좌_코드 태그 #1	2	0xDF43
로열티_계좌_코드 길이 #1	1	xx
로열티_계좌_코드 #1	xx	[계좌 코드]

로열티_ID 태그 #2	2	0xDF 41
로열티_ID 길이 #2	1	xx
로열티_ID 데이터 #2	xx	[로열티 ID]
로열티_계좌_코드 태그 #2	2	0xDF43
로열티_계좌_코드 길이 #2	1	xx
로열티_계좌_코드 코드 #2	xx	[계좌 코드]
.......
오퍼_ID 태그 #1	2	0xDF51
오퍼_ID #1 ID 길이	2	X'81 xx'
오퍼_ID #1 ID 값	xx	[쿠폰 ID]
오퍼_코드 #1 코드 태그	2	0xDF53
오퍼_코드 #1 코드 길이	2	0x'81xx'
오퍼_코드 #1 코드 값	xx	[쿠폰 코드]

오퍼_ID 태그 #2	2	0xDF51
오퍼_ID #2 ID 길이	2	0x'81xx'
오퍼_ID #2 ID 값	xx	[쿠폰 ID]
오퍼_코드 #2 코드 태그	2	0xDF53
오퍼_코드 #2 코드 길이	2	0x'81xx'
오퍼_코드 #2 코드 값	xx	[쿠폰 코드]
.......
합계:	<var>

다음은 대표적인 응답 데이터 파싱(parsing) 샘플이다. NFC 판독기(또는 POS 단말기)는 소비자, 로열티 및/또는 오퍼 데이터를 포함할 수 있는 데이터의 스트링(string)으로 이러한 상거래 데이터를 POS 시스템에 전달한다. 판매자 POS 시스템은 그 후 로열티 및 오퍼 데이터를 획득하기 위해 데이터를 파싱할 수 있으며, 판매자의 규격들로 데이터를 프로세싱할 수 있다.

DF 21 10 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF DF 41 06

18 DB 6E 23 F4 0B DF 43 0D 02 31 38 44 42 36 45 32 33 46 34 30 42

DF 51 08 88 77 66 55 44 33 22 05 DF 53 09 02 42 41 31 38 37 36 35

34 DF 51 08 88 77 66 55 44 33 22 06 DF 53 0C 02 41 39 39 39 39 31

33 33 35 37 38 DF 51 08 88 77 66 55 44 33 22 07 DF 53 10 02 5A 58

31 37 39 35 36 37 35 34 38 33 31 43 46 DF 51 08 88 77 66 55 44 33

22 08 DF 53 0C 02 31 38 30 30 38 37 32 30 30 30 31 DF 51 08 88 77

66 55 44 33 22 09 DF 53 33 02 57 4B 52 50 31 32 33 34 35 36 37 38

39 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 50 57 50 57 50

57 50 57 50 57 50 57 50 57 50 57 50 57 50 57 50 40 A1

데이터 파싱 예

DF 21 10 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF

(소비자 ID)

DF 41 06 18 DB 6E 23 F4 0B (MoCom 로열티 ID)

DF 43 0D 02 31 38 44 42 36 45 32 33 46 34 30 42

(소비자 로열티 코드)

DF 51 08 88 77 66 55 44 33 22 05 (MoCom 오퍼 ID) #1

DF 53 09 02 42 41 31 38 37 36 35 34 (판매자 오퍼 코드) #1

DF 51 08 88 77 66 55 44 33 22

트랜잭션 후 데이터

상기 설명된 바와 같이, 트랜잭션 후 데이터 명령어는 판매자 POS 시스템(MPOS; merchant POS system)으로부터 데이터를 다시 수신하기 위해 메커니즘을 제공한다. 이러한 명령어는 판매자 POS 단말기(140)에 의해 개시되며 바람직하게는 판매자 능력 필드에서 지원된다. 대표적인 실시예에서, 이러한 명령어는 255 바이트들의 최대 데이터 크기를 가진 데이터의 단일 프레임으로 구성된다. 데이터의 콘텐츠(contents)는 표준 TLV 포맷팅을 사용하지만 또한 가변적일 수 있다. 이러한 명령어는 동적 조정 또는 트랜잭션 후 통합을 가능하게 한다. 부가적인 데이터 태그들은 POS 단말기/MPOS에서 이동 디바이스(110) 내의 보안 요소(112)로의 부가적인 데이터의 송신을 위해 정의될 수 있다. 대표적인 트랜잭션 후 데이터 명령어("트랜잭션 후 데이터")는 표 9 및 표 10에 예시된다:

트랜잭션 후 데이터 명령어

CLA	INS	P1	P2	Lc	데이터	Le
90	52	00	00	xx	<TLV 인코딩된 트랜잭션 후 데이터>	00

명령어 데이터

데이터 요소	바이트 크기	값	요청
트랜잭션 ID	2	0x DF 61	선택적
트랜잭션 ID 길이	1	xx
트랜잭션 ID 데이터	xx	판매자 발생 트랜잭션 ID
오퍼_ID 코드 #1	2	0XDF 51	선택적
오퍼_ID 길이 #1	1	xx
오퍼_ID 데이터 #1	xx	쿠폰 ID
.......
오퍼_ID 코드 #X	2	0xDF 51	선택적
오퍼_ID 길이 #X	1	xx
오퍼_ID 데이터 #X	xx	쿠폰 ID
합계:	<var>

다중-블록 데이터 핸들링

도 5는 예시적인 실시예에 따른 대표적인 다중-블록 데이터 흐름을 예시한다. 보안 요소(112)가 전송할 255 바이트들 이상의 데이터를 가질 때, 응답 획득 명령어(C0)가 나머지 응답 데이터를 검색하기 위해 사용된다. 특히, 이러한 명령어는 상거래 애플릿(113)이 예를 들면, 255 바이트들 이상의 응답 데이터를 전송해야 할 때 나머지 데이터를 획득하기 위해 사용된다.

도 5를 참조하면, 사용자가 판독기(120)로 상거래-가능 이동 디바이스(110)를 탭핑한 후, 판독기(120)는 상거래 선택 명령어를 이동 디바이스(110)의 보안 요소(112)에 전송한다. 긍정 응답('90 00')은 판독기(120)로 하여금 상거래 데이터 획득 명령어를 전송하게 한다. 이에 응답하여, 보안 요소(112)는 로열티 및 오퍼들 데이터를 리턴한다. 도 5에 도시된 바와 같이, 상거래 데이터 획득 응답 상태 SW1 플래그는 '61'로 설정되며 SW2 플래그는 '00'으로 설정된다.

응답 획득 명령어는 상거래 데이터 획득 응답에서의 SW1 플래그가 '61'로 설정될 때 트리거(trigger)된다. 이 예에서, SW2 플래그는 이동 디바이스(110) 상에서의 상거래 애플릿(113)이 얼마나 많은 데이터가 전송되기 위해 남겨지는지를 알 수 없기 때문에 '00'으로 설정된다. 또한 응답 획득 명령어에 대한 후속 응답은 제 2 응답 획득 명령어로 하여금 판독기(120)에 의해 이동 디바이스(110)로 전송되게 하는, '61'로 설정된 SW1 플래그를 포함한다.

이러한 시퀀스(sequence)는 상거래 데이터 획득 응답의 SW1 플래그가 '61'이 아닌 임의의 값으로 설정될 때 종료될 것이다. 예를 들면, 도 5에 도시된 바와 같이 응답 획득 명령어에 응답하여 '90'의 SW1 값은 정상 완료를 표시할 것이다. 임의의 다른 SW1 값은 오류로서 로깅(logging)될 수 있다.

표 11은 응답 데이터 획득 APDU 명령어를 위한 대표적인 설정들을 정의한다:

응답 데이터 획득

CLA	INS	P1	P2	Lc	데이터	Le
90	C0	00	00	00	<없음>	00

나머지 데이터의 실제 길이는 가변적이다. 그러므로, Le 데이터 길이는 0x00일 수 있으며; 상거래 애플릿(113)이 가변 길이 응답을 관리하도록 허용한다.

표 12는 응답 데이터 획득 APDU 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들("상태 코드들")을 정의한다.

상태 코드들

판독기 구성 데이터

일 실시예에서, 판독기(120)의 설치 및 구성 동안, 특정 판매자 및 상거래 특정 데이터가 판독기(120)에 로딩(loading)되며 저장된다. 이러한 데이터는 판독기(120)로부터 상거래 데이터 획득 명령어에 채우기 위해 판독기(120)에 의해 사용된다. 이들 데이터 요소들은 새로운 특징들 및 기능들이 이용 가능해짐에 따라 업데이트될 수 있다.

상거래 AID

상기 설명된 바와 같이, 상거래 AID는 상거래 선택 명령어에 전송된다. 명령어가 이동 디바이스(110)에 의해 수용된다면, 상거래 애플릿(113)이 시작되며 APDU 명령어/응답 흐름들은 판독기(120) 및 보안 요소(112) 사이에서 시작될 것이다. 대표적인 실시예에서, 상거래 AID 값은 A00000048510010101이다. 이 값은 판독기(120) 상에서 하드코딩(hardcoding)될 수 있다. 일 실시예에서, 판독기(120)는 부분 선택을 지원하도록 요구되지 않는다.

판매자_ID

판매자 식별자(판매자_ID (DF31))는 판독기(120) 상으로 로딩될 수 있다. 판매자 ID는 서비스 제공자에 의해 할당된 값이다. 일 실시예에서, 이 값은 MoCom 플랫폼 운영자에 의해 할당된다. 이것은 상거래 애플릿(113)이 로열티 및 쿠폰 데이터를 필터링하도록 허용하기 위해 요구되며, 적절한 아이템들을 판독기(120)에 전송한다.

판매자_상점_ID

판매자 상점 식별자 값(판매자_상점_ID (DF32))은 판독기(120)로 로딩되며 서비스 제공자에 의해 할당된 값이다. 이 값은 예를 들면, 보고 목적들을 위해 사용될 수 있다.

로열티_ID

로열티 식별자 값(로열티_ID (DF41))은 다수의 로열티 ID들이 탭 동안 요청될 때 사용된다. 이것은 판매자 능력들 (DF33)에서의 2차 로열티를 설정함으로써 성취된다. 이것은 상거래 애플릿(113)이 상거래 데이터 획득 명령어에 응답하여 부가적인 로열티 번호들을 리턴하도록 허용한다. 다수의 (예컨대, 5) 부가적인 로열티_ID들이 상거래 데이터 획득 요청에서 코딩될 수 있다.

오퍼_유형_코드들

오퍼 유형 코드들(오퍼 유형 코드들 (DF54))이 판독기(120) 상으로 로딩된다. 오퍼 유형 코드들에 할당된 값들은 서비스 제공자에 의해 할당된다. 이 값은 오퍼들을 필터링하기 위해 상거래 애플릿(113)에 의해 사용되며 단지 적절한 아이템들만을 판독기(120)에 전송한다. 다수의 오퍼_유형_코드들이 정의될 수 있으며 상거래 데이터 획득 명령어에서의 보안 요소(112)에 전송될 수 있다.

상거래_애플리케이션_버전

상거래 애플리케이션 버전 번호(상거래_애플리케이션_버전)는 판독기(120) 상에서의 애플리케이션이 코딩되며 보증되는 상거래 판독기 규격의 버전을 표현하기 위해 판독기(120) 상으로 로딩될 수 있다.

판매자_능력들

판매자 능력들 값은 특정한 판매자에 의해 지원된 상거래 특징들을 표현한다. 또한 이러한 데이터 요소는 상거래 데이터 획득 명령어를 포맷팅하기 위해 판독기(120)에 의해 사용될 수 있다.

단말기_시작_모드

단말기 시작 모드 명령어(단말기 시작 모드 (DF34))는 상거래 애플리케이션(121)을 시작하기 위해 사용된 메커니즘을 제공하도록 판독기(120)에 명령한다. 이러한 데이터 요소는 보안 요소(112)에 전송되지 않는다. 또한 이러한 데이터 요소는 핸드셋(handset) 상에서 보안 요소(112) 및 판독기(120) 사이에서의 프로세싱 흐름들을 정의하기 위해 사용될 것이다.

상거래 데이터 획득 필드들

표 13은 상거래 선택 및 상거래 서비스들 획득 명령어들을 포맷팅하기 위해 판독기(120)에 의해 요구된 데이터의 대표적인 정의를 제공한다:

데이터 요소	태그	최대 크기 바이트들	데이터 포맷
상거래 AID		09	16진수
판매자 ID	DF31	8	16진수
판매자 상점 ID	DF32	32	ASCCI
로열티 식별자 #1 내지 X	DF41	8	BCD
날짜 및 시간 스탬프	DF11	7	BCD
규격 버전(주/부)	DF12	2	16진수
판매자 능력들	DF33	2	이진수
상거래 시작 모드	DF34	2	이진수

상거래 애플릿 버전 포맷

상거래 애플릿 버전 값은 주 버전(xx)을 포함한 제 1 바이트 및 부 버전(xx)을 포함한 제 2 바이트의 2-바이트 16진수 필드이다. 이들 필드들은 판독기(120) 상에 구현되는 판독기 상거래 기술 규격의 특정 버전에 따라 업데이트된다. 대표적인 실시예에서, 상거래 애플리케이션의 제 1 공식 릴리즈(release)는 0x0100이다.

판매자 능력들

판매자 능력들 필드(판매자 능력들 필드 (DF 33))는 어떤 상거래 기능들이 판매자에 의해 구현되는지를 결정한다. 판독기(120)는 이동 디바이스(110)로 이러한 필드를 전달할 수 있으며, 이동 디바이스(110)는 상거래 데이터 응답 프레임으로서 불리우는, 응답 프레임을 형성하기 위해 정보를 사용한다. 표 14는 대표적인 판매자 능력들을 예시한다:

판매자 능력 데이터 상거래 시작 모드 포맷

바이트	비트	값	NFC 판독기 기능
1	8 MSB	1=판매자 로열티 지원 0=아니오	비트(8)가 판독기 상에 있다면, 판매자를 위한 요구된 판매자 ID 및 선택적으로 로열티 ID를 전송할 것이다
1	7	1=2차 로열티 0=아니오	비트(8)는 그것 상에 있어야 한다. 부가적인 로열티 ID들은 상거래 데이터 획득 요청에 포함된다
1	6	1=오퍼들 지원 0=아니오	오퍼 유형 필드들은 상거래 데이터 획득 요청에 포함된다
1	5	1=부가적인 오퍼 지원 0=아니오	판매자는 상거래 획득 요청에서 부가적인 오퍼들을 요청할 수 있다
1	4	1=무접촉 지불 지원 0=아니오	몇몇 판매자들은 무접촉 지불들이 아닌 단지 상거래만들 수용하기 위해 선택할 수 있다. 이러한 비트 설정은 정보 전용이다. 그것은 PPSE 프로세스가 발생하는 것을 중지하지 않을 것이다.
1	3	1=기업 판매자 ID 0=아니오
1	2	1=클라우드 기반 오퍼 0=아니오	판매자가 클라우드 기반 오퍼들을 지원할 수 있다는 것을 표시한다 (미래)
1	2	0	미래 사용을 위해 예약됨

1	1	1=트랜잭션 후 데이터 지원 0=아니오	판독기는 POS로부터 상환 데이터를 수신하며 그것을 핸드셋으로 포워딩할 것이다
2	8-1	0	미래 사용을 위해 예약됨

상거래 시작 모드 포맷

상거래 시작 모드 포맷 값(상거래 시작 모드 (DF34))은 메커니즘이 판독기(120) 상에서 상거래 애플리케이션(121)을 시작하기 위해 사용될 것을 판독기(120)에 표시한다. 일 실시예에서, 이러한 데이터 요소는 상거래 데이터 획득 명령어에서 이동 디바이스(110)로 전송되지 않는다. 또 다른 실시예에서, 이러한 데이터 요소는 선택적이다. 표 15는 대표적인 시작 모드들이 상거래 애플리케이션(121)을 시작하기 위해 사용될 수 있다는 것을 예시한다. 대표적인 실시예에서, 비트들(7 및 8)은 배타적이며 단지 하나의 비트만이 한 번에 턴 온(turn on)된다:

상거래 시작 모드

바이트	비트	값	판독기 기능
1	8 MSB	1=자동 시작 0=아니오	검사의 시작에서, 판독기는 제 1 탭에서의 상거래 AID를 요청할 것이다
1	7	1=수동 시작 0=아니오	판독기는 단지 몇몇 사용자 개입 후 상거래 AID를 선택할 것이다
1	6	1=트랜잭션 후 데이터를 가진 지불 0=아니오	지불 및 트랜잭션 후 데이터는 탭 2 상에서 발생할 것이다
1	5	우선 지불	지불 PPSE는 자동 또는 수동 시작 모드들에서 선행할 것이다
1	4-1	0	미래 사용을 위해 예약됨
2	8-1	0	미래 사용을 위해 예약됨

판독기 메시지 포워딩

이동 디바이스(110)로부터 상거래 애플리케이션 데이터를 판독하는 동안, 판독기(120)는 POS 단말기(140) 상에 존재하는 판매자 POS 시스템 또는 POS 애플리케이션으로 데이터를 포워딩한다. 판독기(120)는 APDU 헤더들을 벗기며 이동 디바이스(110)로부터의 데이터를 블록-해제한다. 태깅된 TLV 프레임들은 그 후 적절한 프로토콜에 싸여지며 프로세싱을 위해 POS 단말기 상에서 구동하는 판매자 POS 시스템 또는 POS 애플리케이션으로 포워딩된다.

상거래 응답 데이터 설명

판독기(120)와의 성공적인 상호 작용 동안, 데이터는 POS 판매자 시스템(또는 POS 단말기)으로 리턴될 것이다. 이러한 정보는 통상적으로 판매자가 정의하며 소비자의 지갑으로 로딩한 몇몇 수의 오퍼들 및/또는 소비자 로열티 수로 구성될 것이다.

소비자 ID

소비자 식별자(소비자 ID)는 지갑 활성화 프로세스 동안 소비자에 할당되는 고유 식별자이다. 통상적으로, 소비자 ID는 소비자가 새로운 이동 디바이스 또는 상이한 이동 네트워크로 그녀의 지갑을 이동할지라도 소비자에 머무를 것이다. 바람직한 실시예에서, 핸드셋이 전송할 로열티 또는 오퍼들 데이터가 없을지라도, 소비자 ID는 모든 상거래-관련 상호작용 상에서 이동 디바이스로부터 판독기로 전송된다. 소비자 ID의 프리젠테이션(presentation)은 지불-전용 탭과 관련 있는 특정 동작들을 트리거하기 위해 판매자 POS 시스템에 의해 사용될 수 있다.

로열티 ID

로열티 식별자(로열티 ID)는 탭 이벤트 동안 요청된 각각의 소비자 로열티 번호와 함께 전송된다. 로열티 ID는 MoCom 플랫폼에 의해 할당된 각각의 판매자 로열티 프로그램에 할당된 고유 값이다. 대부분의 경우들에서, 판독기에 의해 수신된 로열티 ID는 상거래 데이터 획득 명령어에 의해 구성된 판매자 ID에 일치할 것이다. 판매자 시스템에 의한 이러한 정보의 사용은 선택적이다.

소비자 로열티 코드

소비자 로열티 코드(소비자 로열티 코드)는 특정 판매자 로열티 프로그램을 위해 소비자에 할당된 로열티 번호에 일치한다. 지갑 애플리케이션(114)은 다수의 로열티 번호들이 탭에 존재하도록 허용한다. 시스템이 다수의 소비자 로열티 코드들에 대해 셋 업 된다면, 각각의 소비자 로열티 코드는 그것의 고유 로열티 ID에 의해 선행될 것이다.

오퍼 ID

이동 상거래 오퍼 식별자(오퍼 ID)는 상거래-관련 세션(session) 동안 전송된 각각의 소비자 오퍼 번호와 함께 전송된다. 오퍼 ID는 소비자 지갑으로 전달된 각각의 오퍼에 할당된 고유 값이다. 일 실시예에서, MoCom 플랫폼에 의해 발생된 어떤 두 개의 오퍼 ID들도 동일한 값을 갖지 않을 것이다.

판매자 오퍼 코드

판매자 오퍼 코드("판매자 오퍼 코드" 또는 "오퍼 번호")는 판매자에 의해 발생되며 다양한 수단들을 통해 소비자의 지갑 애플리케이션으로 로딩된다. 이러한 번호는 프로세싱을 위해 판매자 POS 시스템 상에 정의되는 동일한 오퍼에 일치한다. 단일 상거래 트랜잭션 동안 제공된 다수의 판매자 오퍼들(예컨대, 10)이 있을 수 있다. 판매자 시스템은 개개의 판매자 오퍼들을 추출하기 위해 인입 데이터를 파싱한다.

상거래 응답 데이터 필드들

표 16은 성공적인 상거래 트랜잭션 후 상거래 POS 시스템으로 리턴될 수 있는 대표적인 데이터 요소들을 정의한다:

데이터 요소	태그	최대 크기 바이트들	데이터 포맷
소비자 ID	DF 21	16	BCD
로열티 ID	DF 41	8	16진수
소비자 로열티 코드	DF 43	32	ASCII, 16진수, BCD
오퍼 ID	DF 51	8	BCD
판매자 오퍼 코드	DF 53	48	ASCII, 16진수, BCD

일 실시예에서, 데이터 요소 "단말기 시작 모드"는 판독기(120)에 전달되지만 보안 요소(112)로 전달되지 않을 것이다. 판독기(120)는 상거래 선택 및 PPSE 선택 명령어들이 보안 요소(112)로 전송될 때를 제어하기 위해 이 정보를 사용한다.

판독기 상거래 애플리케이션 기능

다음의 섹션은 판독기(120) 내의 상거래 애플리케이션이 수행하는 기능들의 리스트를 제공한다. 이들 기능들의 일부는 자동화되는 반면, 다른 것들은 POS 단말기 또는 판매자 POS로부터의 API 호출을 통해 트리거된다.

상거래 AID 선택 명령어

상거래 애플리케이션이 판독기(120) 상에서 시작되며 디바이스가 판독기(120)의 필드에서 검출된 후, 전송된 제 1 명령어는 상거래 AID 선택이다. 명령어는 ISO에 의해 할당된 RID 값 및 상거래 서비스 제공자에 의해 발생된 PIX 값을 포함할 것이다. 상거래 AID 값은 A00000048510010101이다. 이 값은 판독기(120) 상에서 하드코딩되어야 한다.

상거래 데이터 획득 명령어

상거래 서비스 데이터 획득 명령어는 보안 요소(112)로의 일반적인 데이터 요청이다. 상거래 데이터 요청은 정보를 상거래 애플릿(113)으로 전달하는 많은 요구된 및 선택적 필드들을 가진다. 상거래 애플릿(113)은 판독기(120)에 전송될 필요가 있는 데이터 요소들을 형성하기 위해 이 정보를 사용한다. 판독기(120)는 어떤 선택적 필드들이 핸드셋으로의 요청에 포함될 필요가 있는지를 결정하기 위해 판매자 능력 레코드들(records)에서의 필드들을 사용한다.

트랜잭션 후 데이터

트랜잭션 후 데이터 명령어는 MPOS로부터 다시 데이터를 수신하기 위해 메커니즘을 제공하기 위해 생성되었다. 이러한 명령어는 255 바이트들의 최대 데이터 크기를 가진 데이터의 단일 프레임으로 구성된다. 데이터의 콘텐츠는 표준 TLV 포맷팅을 사용하지만, 콘텐츠는 가변적일 수 있다. 부가적인 데이터 태그들은 POS 단말기/MPOS에서 이동 디바이스(110)에서의 보안 요소(112)로의 부가적인 데이터의 송신을 위해 정의될 수 있다.

NFC 오류 복구

바람직한 실시예에서, 판독기(120)는 핸드셋이 NFC 필드로부터 너무 이르게 제거될 때 발생된 판독기 오류로부터 복구할 수 있다. 판독기(120)는 "비프(beep)"를 출력하는 스피커(speaker) 또는 광(light)들을 통해서와 같이 광학적 표시를 제공하는 디스플레이(display)와 같은 고장 인터페이스를 통해 소비자에게 판독 오류를 시그널링(signaling)한다. 소비자는 다시 탭핑하도록 요청되며 오류 동안 진행 중이었던 트랜잭션이 재시작된다. 상거래 트랜잭션 및 PPSE 트랜잭션과 같이, 다수의 트랜잭션들이 프로세싱되는 경우에, 판독기(120)는 실행되는 마지막 프로세스를 복구하려고 시도할 것이다.

큰 데이터 블록 지원

대표적인 실시예에서, 판독기(120)는 단일 탭 프로세스에서 이동 디바이스(112)로 및 그로부터 다수의 255-바이트 블록들의 데이터를 판독 및 기록한다.

날짜 및 시간 스탬프 지원

판독기(120)가 판매자 POS 시스템에 대한 연결성을 가질 때, 날짜 및 시간은 트랜잭션의 시작 시 POS 단말기로부터 검색될 수 있다.

TLV 마스터 태그 리스트

표 17은 상거래 기반 애플리케이션들에 의해 사용된 타겟/최대 바이트 크기들 및 대응하는 태그 값들 및 데이터 요소들을 정의한다. 부가적인 값들은 제한된/고정된 값 범위를 갖고 이들 요소들에 제공된다.

APDU 명령어들

상거래 서비스들
공유된 데이터 요소들
데이터 요소	태그	최대 크기	설명
날짜_시간_스탬프	0xDF11	7	날짜/시간 스탬프(yyyymmddhhmmss)
상거래_앱_버전	0xDF12	2	지원된 상거래 애플리케이션 버전 번호
소비자 데이터 요소들
데이터 요소	태그	최대 크기	설명
소비자_ID	0xDF21	16	MoCom 플랫폼 특정 소비자 식별자
소비자_키	0xDF22	16	MoCom 플랫폼 발생 소비자 특정 3DES 키
소비자_인증서	0xDF23	8	MoCom 플랫폼 발생 소비자 서명/인증서
판매자 데이터 요소들
데이터 요소	태그	최대 크기	설명
판매자_ID	0xDF31	8	MoCom 플랫폼 특정 판매자 식별자
판매자_상점_ID	0xDF32	32	MoCom 플랫폼 특정 판매자 상점 식별자 ASCII 문자 데이터
판매자_능력	0xDF33	2	지원된 상거래 애플리케이션 서비스들
NFC 판독기_시작_모드	0xDF34	2	NFC 가능 지불 단말기 시작 모드(초기화 동안 판매자 POS 시스템에 의해 제공된)
판매자 능력들
데이터 요소	값	최대 크기	설명
MERCAP_판매자_ 로열티	0x80	1	상거래 데이터 획득 요청은 애플릿에 의해 수신된 로열티 데이터를 결정하기 위해 사용된 유효한 판매자 식별자를 포함한다.
MERCAP_부가_ 로열티	0x40	1	상거래 데이터 획득 요청은 부가적이 로열티 식별자들을 포함한다. 부가적인 로열티 데이터는 특정된 로열티 ID(들)에 의해 결정된다.
MERCAP_판매자_ 오퍼들	0x20	1	오퍼 유형 필드들이 상거래 데이터 획득 요청에 포함된다.
MERCAP_부가_ 오퍼들	0x10	1	상거래 데이터 획득 요청은 애플릿에 의해 수신된 오퍼 데이터를 결정하기 위해 사용된 유효한 판매자 식별자를 포함한다.
MERCAP_지불	0x08	1	판매자가 무접촉 지불들 지원한다는 것을 표시한다.
MERCAP_기업	0x04	1	기업 판매자 ID에 대한 지원을 표시한다
MERCAP_클라우드	0x02	1	클라우드 기반 오퍼들 및 로열티에 대한 지원을 표시한다
MERCAP_상환	0x01	1	NFC 판독기는 오퍼 상환 명령어를 통해 애플릿으로의 오퍼 상환 데이터(POS로부터)의 송신을 지원한다.
서비스 제공자 플랫폼 데이터 요소들
플랫폼_서명	0x71	8	원격 검증 목적들(데이터 무결성/진정성)을 위해 플랫폼으로부터 비롯된 명령어/데이터에 첨부된 MoCom 플랫폼 발생 MAC/서명
플랫폼_키	0x72	16	MoCom 플랫폼 키
플랫폼_인증서	0x73	8	MoCom 플랫폼 인증서
로열티
로열티 데이터 요소들
데이터 요소	태그	최대 크기	설명
내장된_TLV_ 로열티_데이터	0xDF40	xx	내장된 TLV 로열티 데이터 태그
로열티_ID	0xDF41	8	MoCom 플랫폼 특정 로열티 식별자
로열티_상태	0xDF42	1	로열티 카드/계좌 상태(이하 참조)
로열티_계좌_ 코드	0xDF43	32	로열티 계좌(바코드 데이터)
로열티_MAC_ 서명	0xDF44	8	진실성/진정성 검증을 위한 MoCom 플랫폼 특정 MAC/서명
트랜잭션 로그
트랜잭션 데이터 요소들
데이터 요소	태그	최대 크기	설명
내장된_TLV_ 트랜잭션_로그	0xDF60	xx	트랜잭션 로그 레코드 데이터 태그
트랜잭션_ID	0xDF61	16	트랜잭션 ID (POS에 의해 할당된)
트랜잭션_상태	0xDF62	3	트랜잭션 로그 레코드 데이터 태그
오퍼들
오퍼 데이터 요소들
데이터 요소	태그	최대 크기	설명
내장된_TLV_ 오퍼_데이터	0xDF50	xx	내장된 TLV 오퍼 데이터 태그
오퍼_ID	0xDF51	8	MoCom 플랫폼 특정 오퍼 식별자
오퍼_상태	0xDF52	1	오퍼 상태(이하 참조)
오퍼_코드	0xDF53	130	오퍼(UPC/EPC/GS1 데이터바(Databar)) 바코드 데이터
오퍼_유형_코드	0xDF54	9	오퍼 유형(이하 참조)
오퍼_MAC_ 서명	0xDF55	8	MoCom 플랫폼 특정 데이터 보안 서명
오퍼_업데이트_플래그	0xDF56	1	업데이트 플래그(동기화 상태)

표 18은 상거래 애플릿(113)에 의해 지원된 대표적인 APDU 명령어들의 마스터 리스트들을 제공한다.

명령어	CLA	INS	P1	P2	Lc	데이터	Le
상거래 데이터 획득	90	50	00	00	xx	날짜/시간 스탬프 + 판매자 ID + 상점 ID [+ 상거래 애플리케이션 버전 + 판매자 능력들 + 트랜잭션 ID + 로열티 ID들 + 오퍼 코드들]	00
트랜잭션 후 데이터	90	52	00	00	xx	<TLV-인코딩된 트랜잭션 데이터>	00
나머지 데이터 획득	90	C0	00	00	xx	없음

특수하게 포맷팅된 데이터 요소들

상거래 데이터 페이로드에 포함된 데이터 요소들은 그 요소를 위해 사용된 데이터 인코딩을 식별하는 포맷 바이트를 포함할 수 있다. 데이터 인코딩은 판매 시점 관리(the point of sale)에서의 호환성을 보장하기 위해 판매자에 의해 특정된다. 포맷팅된 데이터 값은 상거래 플랫폼에 의해 지갑 애플리케이션(114)에 공급된다. 따라서, 어떤 부가적인 해석/포맷팅도 플랫폼(130), 지갑(114), 보안 요소(112), 및 판독기(120)/POS 단말기(140)(총괄하여 "지불 단말기"로서 불리우는) 사이에 필요하지 않다. 데이터를 적절히 해석하며 프로세싱을 위해 그것을 판매자 시스템에 공급하는 것이 지불 단말기(또는 판매자 POS 시스템)의 역할이다.

대표적인 실시예에서, 다음의 데이터 요소들은 다음의 포맷 값을 포함한다:

● 로열티 계좌 코드 (DF 43)

● 오퍼 코드 (DF 53)

표 19는 가능한 포맷 바이트 값들 및 그것들의 대응하는 인코딩 규칙을 정의한다:

포맷 바이트	인코딩 규칙	설명
0x00	16진수	데이터의 각각의 바이트는 (원(raw)) 16진수 포맷으로 인코딩된다.
0x01	이진 코딩된 십진법(BCD; Binary Coded Decimal)	각각의 니블(nibble)은 단일 숫자를 표현한다. 따라서, 단지 십진 값들이 특정된다. 홀수(길이)의 숫자들을 포함한 데이터 스트림(stream)은 데이터 스트림의 제 1 니블에서 16진수 값 'F'을 포함한다.
0x02	ASCII	각각의 바이트는 이와 같이 해석되며 그것의 대응하는 CHAR 값으로서 핸들링되는 ASCII 값을 나타낸다. 대부분의 경우들에서, 이들 데이터 스트림들은 프로세싱을 위해 판매자 POS 시스템으로 전달되기 전에 스트링(String)으로 변환된다.

제 1 니블에서 16진수 값 'F'을 포함하는 BCD 인코딩된 데이터 값은 홀수의 숫자들을 포함한 데이터 스트림을 식별할 것이다. 따라서, BCD 데이터 스트림(12345)은 다음과 같이 3 바이트 버퍼에 인코딩된다: 0 xF12345.

대표적인 구현들

도 6은 본 발명의 예시적인 실시예에 따른 지갑 애플리케이션을 위한 그래픽 사용자 인터페이스에 의해 발생된 윈도우들(windows) 또는 스크린 샷들(screen shots)을 예시한다. 이러한 대표적인 구현을 위해, 이동 디바이스(110)는 메모리(111b)에 저장된 몇몇 교환할 수 있는 오퍼들 및 로열티 카드들을 가진다.

지갑 홈 스크린(601)은 판매자 타일들(tiles)(604)의 스트립(strip)을 특징으로 삼는다. 타일은 이동 지갑에 존재하는 교환 가능한 객체(예컨대, 교환 가능한 오퍼 또는 로열티 카드)를 가진 모든 판매자를 위해 존재한다. 사용자는 예를 들면, 특정한 판매자를 찾기 위해 타일들을 통해, 좌측 및 우측으로 스와이핑(swiping)할 수 있다. 일단 특정한 판매자가 발견된다면, 타일은 판매자 오퍼 뷰(view)(602)를 열기 위해 선택된다. 이것은 이를테면 일직선으로 대기하면서, 또는 이전에(예컨대, 상점을 통해 브라우징(browsing)하면서), 트랜잭션을 이루기 전에 또는 트랜잭션을 이루기 직전에 행해질 수 있다.

판매자 오퍼 뷰(602)는 지갑에 이용 가능한 교환 가능한 오퍼들(603)의 리스트를 보여준다. 비-상환 가능한 프로모션들(promotions)이 또한 보여질 수 있다. 존재한다면, 로열티 카드(605)가 또한 보여지며 판매자 오퍼 뷰(602)로부터 액세스 가능해진다.

선택된 판매자가 상거래-가능 판매자가 아니라면, 상거래 트랜잭션을 위한 오퍼들을 로딩하기 위해 제공된 옵션이 없을 수 있다. 그러나, 판매자가 상거래-가능 판매자이면, 오퍼들이 상거래 트랜잭션을 위해 로딩되도록 허용하는 하나 이상의 버튼들(buttons) 또는 아이콘들(icons)(606a, 606b)이 제공된다.

사용자는 오퍼(예컨대, 606a)를 선택할 수 있으며, 그 후 스크린의 최하부에서 "완료" 바를 선택할 수 있다.

대표적인 실시예에서, 오퍼들의 수에 대한 제한은 보안 요소(112)(예컨대, 10개의 오퍼들)에 의해 시행될 수 있으며, 상거래 위젯(115)의 사용자 인터페이스는 사용자가 오퍼들을 활성화시키면서 이러한 제한을 시행한다. "완료" 바는 선택된 오퍼들을 보안 요소(112)로 로딩하기 위한 트리거이다. 보안 요소(112)에서 또 다른 판매자로부터의 오퍼들이 있다면, 그것들은 새로운 오퍼들이 로딩되는 것과 동시에 제거될 수 있으며-이것은 임의의 주어진 시간에 112에 존재하는 하나의 판매자로부터의 오퍼들만이 있음을 보장한다.

보안 요소 로드가 완료될 때, 사용자는 판독기(120)로 이동 디바이스(110)를 탭핑한다. 무엇이 다음에 발생하는지는 몇 개의 인자들에 의존한다. 탭핑되는 판독기가 상거래 요소들을 프로세싱할 수 없다면, 선택된 지불 카드가 전송되지만, 어떤 상거래 요소들(예컨대, 오퍼들 또는 로열티 크리덴셜들)도 전송되지 않는다. 어떤 다른 정보도 없이, 지불 크리덴셜들이 전송되었음을 표시하는 탭-후 메시지가 판독기 인터페이스를 통해 제공된다.

탭핑되는 판독기가 상거래 요소들을 프로세싱할 수 있지만, 판매자-ID가 선택된 판매자와 일치하지 않는다면, 오퍼들이 전송되지 않을 것이다. 보안 요소(112)에서의 상거래 애플릿(113)은 이러한 판매자-ID를 위한 로열티 카드를 탐색하며 존재한다면, 로열티 크리덴셜들을 송신할 수 있다. 이벤트가 발생하였음을 표시하고, 판매자를 식별하며, 지불 크리덴셜들뿐만 아니라 로열티 크리덴셜들이 전송되었음(그것들이 이용 가능하였다면)을 보고하는 탭-후 메시지가 인터페이스를 통해 제공된다.

탭핑되는 판독기가 상거래-가능 판독기이며 판매자-ID가 선택된 판매자에 일치한다면, 판매자를 위한 선택된 오퍼들 및 (존재한다면) 로열티 카드 크리덴셜들이 전송된다. 이동 디바이스(110)는 오퍼들 및 로열티(존재한다면)가 지불들과 함께 전송되었음을 확인하는 탭-후 메시지를 상거래 위젯(115)을 통해 사용자 인터페이스에 제공할 수 있다.

탭에 이어서, 보안 요소(112)로 로딩되었던 오퍼들은 사용자가 그것들을 제거하거나 또는 또 다른 판매자로부터 오퍼들을 선택할 때까지 보안 요소(112)에 남겨진다. 대안적으로, 오퍼들이 만료되면, 그것은 지갑 유지가 수행될 때 보안 요소(112)로부터 제거된다. 대표적인 실시예에서, 선택된 판매자는 사용자가 상이한 판매자를 선택할 때까지 지갑 홈 페이지 상에서 "활성" 판매자인 채로 있을 것이다.

인스턴트 오퍼 구현

도 7은 본 발명의 실시예에 따른 대표적인 인스턴트(instant) 오퍼 구현을 예시한 흐름도를 예시한다. 이 실시예에서, 이동 상거래(MoCom; mobile commerce) 플랫폼은 지갑 애플리케이션을 사용함으로써 오퍼들을 선택하기 위해 사용자들을 위한 메커니즘을 구현하기 위해 판매자 POS 시스템과 함께 통합될 수 있으며 및/또는 인스턴트 오퍼들 판매자들이 소비자들에게 이용 가능해진다.

이동 디바이스 상에서 구동하는 지갑 애플리케이션은 소비자들로 하여금 구매들을 지불하며 지불 단말기를 통해 로열티 및 오퍼들을 제공하도록 허용하기 위해 사용될 수 있다. 소비자가 오퍼를 상환할 수 있는 하나의 방식은 체크아웃 시 제공될 지갑 애플리케이션을 통해 오퍼를 선택하는 것에 의한다.

또한 소비자들은 지갑 애플리케이션을 통해 즉시 상환될 수 있는 오퍼들을 제공받을 수 있다. 이러한 오퍼들은 본 명세서에서 "인스턴트 오퍼들(instant offers)"로서 불리운다. 이러한 피처(feature)는 판매자들로 하여금 구매들을 하기 위해 지갑 애플리케이션을 구동하는 이동 디바이스를 사용하는 소비자들을 보상하도록 허용한다. 소비자들은 다른 이유들 중에서도, 그것들이 지갑 애플리케이션을 통해 오퍼를 구체적으로 선택할 필요가 없기 때문에, 인스턴트 오퍼로부터 이득을 얻는다. 구현에 따라, 인스턴트 오퍼는 지갑 애플리케이션으로부터 소비자에 의해 명시적으로 선택된 오퍼와 함께 사용될 수 있다. 오퍼가 소비자에 의해 선택되는지 또는 "즉시" 제공되는지 여부에 관계없이, 이동 디바이스로부터(예컨대, 보안 요소(112)로부터) 검색된 소비자 식별자("소비자 ID") 값은 인스턴트 오퍼를 검색 및 교환하기 위한 키(key)로서 사용된다.

도 7을 참조하면, 일 실시예에서, 소비자는 체크아웃 시 제공될 오퍼들을 지갑 애플리케이션으로부터 선택한다. 블록(702)에서, 지불이 POS에서 요청된다. 블록(704)에서, 지불이 무접촉 지불이 아니라고 결정된다면, 블록(706)에서, 지불 프로세스는 대안적 수단을 통해(예컨대, 현금을 사용함으로써) 완료되며 체크아웃 프로세스는 완료된다. 블록(704)에서 지불이 무접촉 지불일 것이라고 결정된다면, 이동 디바이스 사용자는 판독기(예컨대, 상기 설명된 판독기(120))로 그 또는 그녀의 이동 디바이스를 탭핑하도록 요청된다.

이에 응답하여, 이동 디바이스가 판독기로 탭핑된다. 탭 이벤트 동안, 다수의 데이터 요소들이 상기 설명된 바와 같이 이동 디바이스 상에서의 보안 요소 및 판독기 사이에 전달될 수 있다. 일 실시예에서, 지불 카드 데이터, 소비자 ID, 로열티 번호, 및 오퍼 코드들이 판독기의 탭 동안 판독기로 전달된다. 이 실시예에서, 소비자 ID는 탭이 지불을 위해 선택된 어떤 오퍼들도 없이 유일한 트랜잭션일지라도 판독기에 전송된다.

블록(708)에서 MoCom 소비자 ID가 존재하지 않는다고 결정된다면, 블록(706)에서 지불 프로세스가 완료되며 체크아웃 프로세스가 지불을 프로세싱함으로써 완료된다.

블록(708)에서 MoCom 소비자 ID가 존재한다고 결정된다면, 블록(710)에서 MoCom 오퍼가 존재하는지 여부(예컨대, 지갑 애플리케이션을 통해 사용자에 의해 선택된 오퍼)에 대한 결정이 이루어진다. 블록(710)에서, MoCom 오퍼가 존재한다는 결정이 이루어지면, 블록(712)에서 MoCom 인스턴트 오퍼가 또한 정의되었는지 여부에 대한 결정이 이루어진다. 블록(712)에서 MoCom 인스턴트 오퍼가 정의되었다고 결정된다면, MoCom 오퍼(즉, 지갑 애플리케이션 인터페이스를 통해 사용자에 의해 선택된 오퍼) 및 MoCom 인스턴트 오퍼 양자 모두가 블록(714)에 도시된 바와 같이, 프로세싱된다. 일단 MoCom 오퍼 및/또는 MoCom 인스턴트 오퍼가 프로세싱된다면, 이들 오퍼들과 연관된 지불이 단계(706)에 도시된 바와 같이 프로세싱된다.

블록(710)에서 MoCom 오퍼가 존재하지 않는다고 결정이 이루어진다면, 블록(716)에서, MoCom 인스턴트 오퍼가 정의되었는지 여부에 대한 결정이 이루어진다. 그렇지 않다면, 지불은 단계(706)에 도시된 바와 같이 완료된다. 블록(716)에서 MoCom 인스턴트 오퍼가 존재한다는 결정이 이루어진다면, MoCom 인스턴트 오퍼는 블록(718)에 도시된 바와 같이 프로세싱되며 MoCom 인스턴트 오퍼와 연관된 지불이 블록(706)에 도시된 바와 같이 프로세싱된다.

블록(712)에서 MoCom 인스턴트 오퍼가 정의되지 않았다는 결정이 이루어진다면, 표준 MoCom 오퍼가 블록(720)에 도시된 바와 같이 프로세싱되며 블록(706)에서 프로세싱된 지불이 완료된다.

판매자 POS 시스템은 인스턴트 오퍼의 사용을 트리거하기 위해 소비자ID의 존재를 사용할 수 있다. 오퍼는 예를 들면. MoCom 시스템을 사용하여 판매자가 정의하는 센트들(cents) 오프(off) 또는 퍼센티지(percentage) 오프 유형 오퍼일 수 있다. 이것은 예를 들면, 특정 아이템의 구매를 위해 적용될 수 있다. 대표적인 구현에서, 판매자는 지갑 오퍼가 탭 동안 제공될 때 인스턴트 오퍼 기능을 턴 오프 또는 턴 온하는 옵션을 제공받는다.

인스턴트 오퍼는 판매자에 의해 정의될 수 있으며 그 후 그것의 소매 위치들로 분배될 수 있다. 또한 오퍼는 연관된 특정 시작 및 종료 날짜를 가질 수 있다. 상이한 지리적 영역들로 인스턴트 오퍼들을 분배하기 위한 능력이 또한 고려될 수 있다.

상거래 애플릿 패키지/애플릿/인스턴스 관리

다음 섹션은 상거래 애플릿(113)(도 1)의 다운로드(download)/설치 동안 사용된 AID 값들 및 애플리케이션 특정 파라미터들(parameters)을 정의한다. 표 20은 AID들을 정의한다.

AID들

설명	AID
패키지 AID	A0 00 00 04 85 10 01 01
애플릿 AID	A0 00 00 04 85 10 01 01 00
인스턴스(instance) AID	A0 00 00 04 85 10 01 01 01

애플릿-특정 설치 파라미터들

상거래 애플릿의 개시 상거래 서비스들 데이터 특성들은 애플릿-특정 설치 파라미터들을 통해 공급될 수 있다. 이러한 데이터는 표준 자바카드(JavaCard) AID 및 설치 파라미터들을 따른다.

이들 파라미터들은 표 21에 도시된 바와 같이 코딩되어야 한다.

애플릿 설치 파라미터들

프로비저닝 데이터	바이트 크기	디폴트 값
로열티 기록들의 최대 수	2	20
사전-로딩 판매자 기록들의 최대 수	2	1
트랜잭션 기록들의 최대 수	2	3
합계:	6

메모리 요건들

대표적인 메모리 규격들이 이하의 표 22에 열거된다. 제 1 메모리 규격, "패키지 다운로드"는 상거래 애플릿 패키지를 다운로딩하기 위해 요구되는 비-휘발성(EEPROM) 메모리 공간의 적절한 양을 표시한다. 제 2 메모리 규격, "인스턴스화"는 상거래 애플릿의 새로운 인스턴스를 인스턴스화하기 위해 요구되는 메모리의 양을 표시한다. 최종 메모리 요건, "임시 데이터 공간"은 상거래 애플릿의 각각의 인스턴스에 의해 사용되는 휘발성(RAM) 메모리의 양을 표시한다.

애플릿 메모리 요건들

메모리	바이트 크기
패키지 다운로드	9396
인스턴스화	6260
임시 데이터 공간	518

데이터 관리

이용 가능한 상거래(예컨대, 로열티, 오퍼들, 보상들 등) 데이터는 보안 요소(112)에 탑재한 상거래 애플릿(113) 내에 저장된다. 관련 상거래 데이터의 모두는 3개의 별개의 데이터 표들에 저장된다. 이들 데이터 표들은 상거래 애플릿(113)에 의해 관리된다. 부가적인 상거래 데이터는 핸드셋에 탑재한 대응하는 상거래 위젯(115) 내에 저장/관리될 수 있다.

일 실시예에서, 본 명세서에 정의된 데이터 요소들은 가변 길이를 가진다. 그러므로, 모든 요소들(고정된 길이를 가진 것들이 포함된)은 최대 길이를 할당받을 것이다. 그 결과, 모든 길이들 및 바이트 크기 참조들은 최대 값들로서 해석되어야 한다.

상거래 데이터

상거래 애플릿(113)은 모든 상거래 서비스 애플리케이션들에 의해 공유되는 몇 개의 데이터 필드들을 관리한다. 이들 데이터 필드들은 영구 데이터 변수들에 저장된다. 대표적인 데이터 요소, 소비자 ID가 표 23에 정의된다. 소비자/플랫폼 키들 및 인증서들과 같은, 부가적인 요소들이 또한 저장될 수 있다.

변수	유형	설명
소비자ID	바이트[]	특정 MoCom 소비자/사용자에 할당된 고유 소비자 ID

로열티 데이터 표

또한 상거래 애플릿(113)은 모든 소비자 로열티 데이터의 저장/관리를 가능하게 하는 로열티 데이터 표들을 포함한다.

표 24는 로열티 데이터 표에 포함되는 데이터 요소들(및 TLV 인코딩 동안 사용된 그것들의 대응하는 태그 값들)을 정의한다.

로열티 데이터

데이터 요소	태그 값	바이트 크기	TLV 인코딩 오버헤드
로열티_프로그램_ID	0xDF41	8	3
로열티_계좌_코드	0xDF43	32	3
합계:		40	6
최소 TLV 인코딩된 기록 크기		46

데이터는 레코드 지향 데이터 버퍼에 저장되며, 여기에서 로열티 식별자("로열티 ID")는 탐색/검색 태스크들을 위한 키 필드로서 이용된다.

대표적인 실시예에서, TLV 데이터 오버헤드(Overhead)는 BER-TLV 인코딩 포맷에 의해 요구된 바와 같이 요소 데이터 오버헤드(2-바이트 태그 및 3-바이트 길이) 당 5 바이트들(의 최대치)을 포함한다.

대안적인 실시예에서, 인덱스(또는 해시 표)는 로열티 ID 탐색 태스크의 속도를 높이기 위해 내부적으로 생성될 수 있다.

캐싱된 판매자 데이터 표

또한 상거래 애플릿(113)은 주어진 판매자와 관련 있는 모든 데이터의 저장/관리를 가능하게 하는 판매자 캐싱된 데이터 표를 포함한다. 이러한 피처는 주어진 판매자를 위한 상거래 데이터가 성능을 개선하기 위해 지갑 애플리케이션(114)에 의해 사전-로딩되도록 허용한다.

표 25는 캐싱된 판매자 데이터 표에 포함되는 데이터 요소들(및 TLV 인코딩 동안 사용된 그것들의 대응하는 태그 값들)을 정의한다.

캐싱된 판매자 데이터

데이터 요소	태그 값	바이트 크기	TLV 인코딩 오버헤드
판매자_ID	0xDF31	8	3
로열티_프로그램_ID	0xDF41	8	3
로열티_계좌_코드	0xDF43	32	3
오퍼_ID	0xDF51	8	3
오퍼_코드	0xDF53	130	3
.......
최대		104	6
최소 TLV 인코딩된 기록 크기:		110

데이터는 레코드 지향 데이터 버퍼에 저장되며, 여기에서 판매자 식별자("판매자 ID")는 탐색/검색 태스크들을 위한 키 필드로서 이용된다. 인덱스(또는 해시 표)는 판매자 ID 탐색 태스크의 속도를 높이기 위해 내부적으로 생성될 수 있다.

대표적인 실시예에서, TLV 데이터 오버헤드는 BER-TLV 인코딩 포맷에 의해 요구된 바와 같이 요소 데이터 오버헤드(2-바이트 태그 및 3-바이트 길이) 당 5 바이트들(의 최대치)을 포함한다.

트랜잭션 로그

상거래 애플릿(113)은 판매자 판매 시점 관리(point-of-sale)에서 MoCom 플랫폼 내에서의 사용을 추적하기 위해 사용되는 트랜잭션 로그(log)를 포함한다. 상거래 위젯(115) 및 보안 요소(112) 동기화 태스크들 동안, 이러한 트랜잭션 로그는 MoCom 플랫폼과의 나중 오버-디-에어("OTA"; over-the-air) 동기화를 위해 상거래 위젯(115)까지 송신된다.

트랜잭션 로그의 실제 콘텐트는 판매자 판매 시점 관리에서의 트랜잭션 프로세스 동안 판독기(120)에 의해 제공된 상거래 데이터 획득 명령어 데이터/파라미터들에 의존한다. 상거래 데이터 획득 APDU 명령어를 통해 판독기(120)에 의해 상거래 애플릿(113)으로 전송된 데이터 페이로드의 정확한 사본이 그 상거래 트랜잭션의 레코드 내에 저장된다.

트랜잭션 상태는 상거래 데이터 프로세싱의 논리적 결과에 기초하여 결정된다. 데이터/프로세싱 오류가 상거래 애플릿(113) 내에서 검출된다면, 대응하는 내부 오류 코드가 트랜잭션 로그에 첨부될 수 있다.

다음의 표는 트랜잭션 로그에 포함되는 데이터 요소들(및 TLV 인코딩 동안 사용된 그것들의 대응하는 태그 값들)을 정의한다.

트랜잭션 로그 데이터

데이터 요소	태그 값	바이트 크기	TLV 인코딩 오버헤드
상거래 데이터 획득 명령어 파라미터(들)/데이터	xx	255	4
트랜잭션_상태	0xDF62	3	3
합계:		266	7
최대 TLV 인코딩된 레코드 크기:		273

데이터가 레코드 지향 데이터 버퍼에 저장된다. 가변적인 상거래 데이터 획득 명령어 데이터 크기가 지원된다.

TLV 데이터 오버헤드는 BER-TLV 인코딩 포맷에 의해 요구된 바와 같이 요소 데이터 오버헤드(2-바이트 태그 및 3-바이트 길이) 당 5 바이트들(의 최대치)을 포함한다.

오류 관리

대표적인 실시예에서, 오류 검출 및 관리가 2 레벨들로 핸들링된다. 먼저, APDU 명령어의 응답은 2-바이트 상태 워드 결과 값을 포함한다. 이들 응답들은 ISO 7816-4에 의해 표준화되고 구술된다. 그러나, 오류 핸들링의 제 2 레벨은 상거래 서비스 애플릿에 의해 내부적으로 관리된다. 제 2 레벨의 관리는 APDU 명령어에 응답하여 표준 0x6909 상태 워드의 발행을 포함한다. 이러한 응답에 이어서, 클라이언트(client)는 2-바이트 내부 오류 코드를 획득하기 위해 제 2 명령어("내부 오류 코드 획득")를 발행할 수 있다. 이러한 코드는 표 27에 상호-참조될 수 있다. 표 27은 오류가 애플릿 내에서 발생한 장소 및 이유에 대한 세부사항들을 제공한다.

특히, 표 27은 상거래 애플릿에 의해 지원된 내부 오류 코드 획득 APDU 명령어에 의해 리턴된 모든 가능한 내부 오류 코드들의 마스터 리스트를 제공한다.

내부 오류 코드들

오류 코드	오류 설명
0x0101	SSE_내부_오류_애플릿_비_제공
0x0102	SSE_내부_오류_명령어_비_허용_경유_무접촉_인터페이스
0x0103	SSE_내부_오류_명령어_비_허용_무효_상황 정보

0x0201	SSE_설치_무효_설치_파라미터_길이

0x0301	SSE_파싱_명령어_데이터_인식불가능_상거래_태그
0x0302	SSE_파싱_명령어_데이터_인식불가능_소비자_ID_길이
0x0302	SSE_파싱_명령어_데이터_인식불가능_판매자_ID_길이
0x0302	SSE_파싱_명령어_데이터_인식불가능_판매자_위치_길이
0x0303	SE_파싱_명령어_데이터_인식불가능__날짜_시간_스탬프_길이
0x0304	SSE_파싱_명령어_데이터_인식불가능_판매자_상거래_앱_버전_길이
0x0305	SSE_파싱_명령어_데이터_인식불가능_판매자_능력들_길이
0x0306	SSE_파싱_명령어_데이터_인식불가능_로열티_ID_길이
0x0307	SSE_파싱_명령어_데이터_인식불가능_로열티_계좌_코드_길이
0x0308	SSE_파싱_명령어_데이터_인식불가능_오퍼_ID_길이
0x0309	SSE_파싱_명령어_데이터_인식불가능_오퍼_유형_코드_길이
0x030A	SSE_파싱_명령어_데이터_인식불가능_트랜잭션_ID_길이
0x030B	SSE_파싱_명령어_데이터_인식불가능_캐싱된_판매자_데이터_오퍼_카운트_길이
0x030C	SSE_파싱_명령어_데이터_인식불가능_캐싱된_판매자_데이터_길이
0x030D	SSE_파싱_명령어_데이터_인식불가능_상거래_태그

0x0A01	SSE_획득_응답_나머지_데이터_인식불가능_요약_상태

0x0B01	SSE_검증_요구된_파라미터들_인식불가능_파라미터_태그
0x0B02	SSE_검증_요구된_파라미터들_날짜_시간_스탬프_비_제공
0x0B03	SSE_검증_요구된_파라미터들_펀매자_ID_비_제공
0x0B04	SSE_검증_요구된_파라미터들_판매자_상점_ID_비_제공
0x0B05	SSE_검증_요구된_파라미터들_판매자_상거래_앱_버전_비_제공
0x0B06	SSE_검증_요구된_파라미터들_판매자_능력들_비_제공
0x0B07	SSE_검증_요구된_파라미터들_로열티_ID_비_제공
0x0B08	SSE_검증_요구된_파라미터들_로열티_계좌_코드_비_제공
0x0B0A	SSE_검증_요구된_파라미터들_소비자_ID_비_제공
0x0B0B	SSE_검증_요구된_파라미터들_캐싱된_판매자_데이터_오퍼_카운트_비_제공
0x0B0C	SSE_검증_요구된_파라미터들_내장된_TLV_캐싱된_판매자_데이터_비_제공

0x0C01	SSE_획득_상거래_데이터_무효_지갑_상태

0x0E01	SSE_업데이트_캐싱된_판매자_데이터_실패된_CMD_버퍼_길이_초과

0x1101	LME_무효_로열티_태그
0x1102	LME_무효_로열티_ID_길이
0x1103	LME_무효_로열티_계좌_코드_길이

0x1201	LME_획득_로열티_데이터_레코드_비_발견
0x1202	LME_획득_로열티_데이터_불충분_버퍼_길이

0x1301	LME_업데이트_로열티_ID_비_특정

0x1401	LME_삭제_로열티_ID_비_특정
0x1402	LME_삭제_로열티_데이터_레코드_비_발견

0x1501	LME_획득_로열티_레코드_불충분_버퍼_길이

0x3101	TLVME_최대_데이터_길이_초과

0x3201	TLVME_첨부_실패된_무효_길이

0x3301	TLVME_획득_다음_태그_실패된_무효_상황 정보_비_현재_태그

0x3401	TLVME_획득_TLV_객체_실패된_무효_태크_클래스
0x3402	TLVME_획득_TLV_객체_실패된_무효_길이
0x3403	TLVME_획득_TVL_객체_실패된_TLV_길이_비_지원

0x3501	TLVME_획득_다음_요소_실패된_무효_태그_클래스
0x3502	TLVME_획득_다음_요소_실패된_TLV_길이_비_지원
0x3503	TLVME_획득_다음_요소_실패된_무효_길이
0x3504	TLVME_획득_다음_요소_실패된_버퍼_길이_초과

0x4101	DME_데이터관리기_무효_레코드_번호
0x4102	DME_데이터관리기_무효_레코드_길이
0x4103	DME_데이터관리기_레코드_비_초기화
0x4104	DME_데이터관리기_레코드_상점_풀(FULL)
0x4105	DME_데이터관리기_무효_데이터_길이
0x4106	DME_데이터관리기_불충분_버퍼_크기

0x4201	DME_데이터관리기_1차_인덱스_비_활성
0x4202	DME_데이터관리기_1차_인덱스_키_비_특정
0x4203	DME_데이터관리기_무효_1차_인덱스_키_길이

0xA201	SUE_비_설치_파라미터들_발견
0xA202	SUE_불충분_애플리케이션_파라미터_버퍼_길이
0xA203	SUE_비_애플리케이션_특정_설치_파라미터들_발견

0xD101	SSE_보안_진실성_실패
0xD102	SSE_보안_무효_암호_데이터_길이
0xD103	SSE_보안_무효_키_데이터_길이
0xD104	SSE_보안_무효_변형_데이터_길이

0xDC00	SSE_보안_암호_예외_비정의된_이유
0xDC01	SSE_보안_암호_예외_부정_값
0xDC02	SSE_보안_암호_예외_비초기화_키
0xDC03	SSE_보안_암호_예외_비_상기(SUCH)_알고리즘
0xDC04	SSE_보안_암호_예외_인식불가능_이니트(INIT)
0xDC05	SSE_보안_암호_예외_부정_사용

상거래 서비스들

다음 섹션은 상거래 애플릿(113)을 통해 이용 가능한 APDU 명령어들의 상세한 설명을 제공한다.

APDU 명령어들

상거래 애플릿(113)과의 모든 통신들/데이터 교환들은 ISO 7816 표준들에 정의된 바와 같이 APDU 명령어들을 통해 수행될 것이다. 부가적인 제한들 및 데이터 핸들링이 이하에 설명된다.

명령어 사용 제한들

보안 이유들을 위해, 이용 가능한 상거래 서비스 명령어들의 서브세트가 특정 연결 모드들에 제한될 수 있다. 일 실시예에서, "접촉 (지갑) 모드"로서 불리우는, 상기 표 18에 정의된 APDU 명령어들의 모두가 이용 가능하다. 그러나, 무접촉 모드에서, 다음의 명령어들이 허용된다:

● 버전 획득

● 내부 오류 코드 획득

● 응답 (나머지 데이터) 획득

● 상거래 데이터 획득

임의의 다른 APDU 명령어가 무접촉 모드에서 전송된다면, 예외가 던져지며 내부 오류 코드는 대응하는 무효 명령어 모드 값(0x0102)으로 설정된다.

일 실시예에서, 상거래 데이터 획득 명령어는 단지 지갑 애플리케이션(114)이 개방될 때 성공적으로 실행될 수 있다. 지갑 애플리케이션(114)이 소비자에 의해 시작되거나 또는 종료될 때, 그것이 모니터링, 관리 및/또는 보안 기능들을 수행할 수 있도록 지갑 동반 애플릿(WCAp; wallet companion applet)에 통지하는 것이 지갑 애플리케이션(114)의 책임이다. WCAp 애플릿은, 결과적으로 공유된 인터페이스를 통해 지갑 애플리케이션 상태의 상거래 애플릿을 통지한다. WCAp 애플릿들은 "보안 요소들 상에서의 보안 및 관리 애플리케이션들을 위한 시스템들, 방법들 및 컴퓨터 프로그램 제품들"이라는 제목의, 미국 특허 출원 번호 제13/857,400호에 논의되며, 그것은 본 명세서에 전체적으로 참조로서 통합된다.

데이터 페이로드 관리

상거래 애플릿(113)은 모든 요구된 파라미터들이 데이터 페이로드에 포함되었음을 검증한다. 그러나, 대부분의 경우들에서, 모든 비-관련 데이터 요소들이 무시될 수 있으며 명령어는 여전히 정상적으로 프로세싱할 것이다. 일 실시예에서, 길이 예상(Le) 값은 상거래 애플릿(113)에 의해 검증되지 않는다. 값은 0으로 가정될 수 있어서, 상거래 애플릿(113)이 응답을 통해 모든 이용 가능한 데이터를 전송하도록 허용한다.

버전 획득

버전 획득 명령어는 현재 로딩된 상거래 애플릿(113)의 버전 정보를 획득하기 위해 사용된다. 버전은 3 바이트들(xx.yy.zz)로 저장될 것이며, 여기에서 xx = 릴리즈 버전, yy = 주(major) 버전 (웨이브(Wave)) 번호, 및 zz = 부(minor) 버전 번호이다. 이러한 정보는 예를 들면, 애플릿 개발 또는 패키징 동안 특정된 MoCom 플랫폼 시스템에 의해 할당되거나 또는 코드 내에서의 정적 값으로서 저장되며, 변경될 수 없다.

표 28은 버전 획득 APDU 명령어를 위한 설정들을 정의한다:

내부 획득 버전

CLA	INS	P1	P2	Lc	데이터	Le
90	10	00	00	00	<없음>	3

일 실시예에서, 어떤 데이터도 상거래 애플릿에 전송되지 않는다. Lc 데이터 길이는 0x00이다.

버전 정보는 3-바이트 응답 내에 포함된다. Le 데이터 길이는 0x03이다. 0x00의 길이가 또한 허용된다. 대표적인 응답 데이터 요소들이 표 29에 정의된다:

응답 데이터

데이터 요소	바이트 크기	값
상거래 규격 버전 태그	1	0xDF12
상거래 규격 버전 길이	1	3
상거래 규격 버전 값	3	[버전 (xx.yy.zz)]
합계:	5

표 30은 이러한 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

SW1	SW2	설명
90	00	명령어의 성공적인 실행
67	00	잘못된 데이터 길이
69	09	내부 오류

공급 애플릿

애플릿 임시 명령어, "프로비전 애플릿(Provision Applet)"은 소비자 ID 및 선택적으로 관련된 보안 데이터(키 값 및 인증서들)를 포함하여, 소비자 관련 데이터의 프로비저닝(또는 업데이트)을 허용한다. 새로운/업데이트된 데이터 값들은 명령어 데이터를 통해 특정된다. 대표적인 실시예에서, 프로비전 애플릿 명령어는 단지 소비자 ID를 업데이트하기 위해서 사용될 수 있다.

표 31 및 표 32는 공급 애플릿 APDU 명령어를 위한 설정들을 정의한다:

공급 애플릿

CLA	INS	P1	P2	Lc	데이터	Le
90	12	00	00	XX	TLV-인코딩된 프로비저닝 데이터	00

표 31에 예시된, 인입 데이터는 TLV 인코딩된 프로비저닝 데이터로 구성된다. 그러므로, Lc 데이터 길이는 가변적이다.

일 실시예에서, 어떤 데이터도 상거래 애플릿(113)에 의해 리턴되지 않는다. Le 데이터 길이는 0x00이다.

명령어 데이터

데이터 요소	바이트 크기^*	값
프로비저닝 데이터 요소 태그	1	[요소 태그]
요소 데이터 길이	1	xx
요소 데이터 값	xx	[데이터]
.......
합계:	<var>

표 33은 공급 애플릿 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

소비자 정보 획득

소비자 정보 획득 명령어는 토큰(token) 소유자(즉, 소비자)와 관련 있는 정적 데이터의 서브세트를 획득하기 위해 사용된다. 이러한 데이터는 다음을 포함한다:

소비자 식별자

표 34는 소비자 정보 획득 APDU 명령어를 위한 설정들을 정의한다:

소비자 정보 획득

CLA	INS	P1	P2	Lc	데이터	Le
90	14	00	00	00	<없음>	00

어떤 데이터도 상거래 애플릿(113)에 전송되지 않는다. Lc 데이터 길이는 예를 들면 0x00이다. 애플릿에 의해 리턴된 요청된 소비자 정보의 실제 길이는 가변적이며, 이용 가능한 소비자 데이터에 특정한다. 그러므로, Le 데이터 길이는 0x00이며, 애플릿은 가변 길이 응답을 관리하도록 허용한다.

응답 데이터는 TLV 포맷팅된 데이터 스트림으로서 리턴된다. 또한 소비자 ID가 리턴될 수 있다.

응답 데이터

데이터 요소	바이트 크기	값
소비자 ID 태그	1	0XDF21
소비자 ID 길이	1	16
소비자 ID	16	[소비자 ID]
합계:	<var>

표 36은 이러한 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

상거래 데이터 획득

상거래 데이터 획득 명령어는 특정된 판매자/로열티 식별자들 및 지원된 오퍼 유형들에 기초하여, 특정된 판매자(또는 판매자들의 세트)를 위한 상거래 정보(예컨대, 로열티, 오퍼들 및 보상들)를 제공한다. 이러한 명령어는 판매자 POS 시스템(예컨대, POS 단말기)에 부착된 판독기(120)를 위한 단일 접촉 지점을 제공한다.

날짜/시간 스탬프, 판매자 ID, 상점 ID, 상거래 프로토콜 버전, 및 판매자 능력들 바이트가 인입 데이터의 일부로서 전송될 수 있다. 또한 부가적인 로열티 식별자들이 요청된 로열티 정보를 특정(필터링)하기 위해 전송될 수 있다. 애플릿은 특정된 판매자/로열티 프로그램 ID(들)에 대한, 로열티 데이터 표(표 5)를 탐색하며 대응하는 로열티 데이터를 검색할 것이다. 또한 부가적인 오퍼 유형 코드들이 요청된 오퍼 정보의 유형을 특정하기 위해 인입 데이터의 일부로서 전송될 수 있다. 상거래 애플릿(113)은 특정된 판매자 식별자/오퍼 코드(들)를 위한 캐싱된 판매자 데이터 표(표 25)를 탐색하며 대응하는 오퍼 데이터를 검색한다.

요구된 파라미터들은 다음을 포함한다:

● 날짜/시간 스탬프

● 판매자 ID

● 상점 ID

● 앱 버전

일단 송신이 성공적으로 완료된다면, 애플릿은 상거래 데이터 요청을 기록하는 그것의 트랜잭션 로그에 엔트리(entry)를 생성할 것이다.

표 37 및 표 38은 상거래 데이터 획득 APDU 명령어를 위한 설정들을 정의한다:

상거래 데이터 획득

CLA	INS	P1	P2	Lc	데이터	Le
90	50	00	00	xx		00

인입 데이터는 날짜/시간 스탬프(트랜잭션 로깅을 위해 사용된), 판매자 식별자, 상점 식별자, 판매자 능력들 바이트, 및 하나 이상의 부가적인 로열티 식별자들(판매자 위치에 의해 지원된 로열티 프로그램들을 표시하는), 및 부가적인 오퍼 코드들(판매자 위치에 의해 지원되는 오퍼들의 유형을 표시하는)을 포함하는, 선택적인 세트의 부가적인 데이터 요소들로 구성된다. 일 실시예에서, 판매자가 판매자 능력 파라미터를 특정하지 않는다면, 단지 판매자 기반 로열티 및 오퍼들만을 지원하는 디폴트 모드가 사용된다.

이용 가능한 로열티/오퍼들 관련 데이터에 특정한 애플릿에 의해 리턴된 요청된 상거래 데이터의 실제 길이는 가변적이다. 그러므로, Le 데이터 길이는 0x00이며, 애플릿은 가변 길이 응답을 관리하도록 허용한다.

명령어 데이터

데이터 요소	바이트 크기	값
날짜/시간 스탬프 태그	1	0xDF11
날짜/시간 스탬프 길이	1	7
날짜/시간 스탬프	7	[날짜/시간 스탬프]
판매자 ID 태그	1	0xDF31
판매자 ID 길이	1	8
판매자 ID	8	[판매자 ID]
상점 ID 태그	1	0x32
상점 ID 길이	1	32
상점 ID	32	[상점 ID]
상거래 버전 태그	1	0xDF12
상거래 버전 길이	1	3
상거래 버전 데이터	2	[상거래 앱 버전]
판매자 능력 태그	1	0xDF33
판매자 능력 길이	1	2
판매자 능력 데이터	1	[판매자 능력 코드]
트랜잭션 ID 태그	1	0xDF61
트랜잭션 ID 길이	1	16
트랜잭션 ID	16	[트랜잭션 ID]
부가적인 로열티 ID 태그	1	0xDF41
부가적인 로열티 ID 길이	1	8
부가적인 로열티 ID	8	[로열티 ID]
.......
부가적인 오퍼 유형 태그	1	0xDF54
부가적인 오퍼 유형 길이	1	9
부가적인 오퍼 유형 코드	9	[오퍼 유형 코드]
.......
합계:	<var>

응답 데이터는 TLV 포맷팅된 데이터 스트림으로서 리턴된다. McCom 플랫폼-특정 소비자 식별자 및 모든 관련 있는 로열티/오퍼들 데이터가 단일 데이터 페이로드에서 리턴된다.

소비자 ID

소비자 ID는 TLV 포맷으로 전송되며, 여기에서 데이터는 태그 소비자_ID(0XDF21)를 사용하여 전송된다. 일 실시예에서, 오류가 검출되지 않는다면, 소비자 ID는 항상 리턴될 것이다.

로열티

일 실시예에서, 로열티 데이터의 각각의 인스턴스는 다음의 TLV 인코딩된 데이터 요소들로 이루어질 것이다:

● 로열티 식별자

● 로열티 계좌 코드

이러한 데이터 스트림 내에서, 제 1 태그는 로열티 식별자 태그(T) 바이트(0xDF41)를 포함할 것이다. 길이(L) 바이트는 로열티 식별자의 길이를 특정할 것이다. 값(V)은 즉시 이어질 대응하는 로열티 데이터를 위한 L 길이의 실제 로열티 식별자를 포함할 것이다.

제 2 태그는 로열티 계좌 코드 태그(T) 바이트(0xDF43)를 포함해야 한다. 길이(L) 바이트는 이전 로열티 식별자에 연계된 계좌 코드 데이터의 총 길이를 특정할 것이다. 값(V)은 L 길이의 실제 로열티 데이터를 포함할 것이다.

로열티 데이터 표 내에 발견된 임의의 부가적인 로열티 식별자들은 이러한 동일한 포맷을 사용하여 TLV 인코딩된 데이터 페이로드에 첨부된다.

오퍼들

오퍼 데이터의 각각의 인스턴스는 다음의 TLV 인코딩된 데이터 요소들로 이루어질 것이다:

● 오퍼 ID

● 오퍼 코드

이러한 데이터 스트림 내에서, 제 1 태그는 오퍼 ID 태그(T) 바이트 (0xDF51)를 포함한다. 길이(L) 바이트는 오퍼 ID의 길이를 특정한다. 값(V)은 즉시 이어질 대응하는 오퍼 데이터에 대한 오퍼 ID를 포함한다.

제 2 태그는 바람직하게는 오퍼 코드 태그(T) 바이트 값(0xDF53)을 포함한다. 길이(L) 바이트는 오퍼 유형 코드의 길이를 특정한다. 값(V)은 대응하는 오퍼 ID에 대한 오퍼 코드 데이터를 포함한다.

오퍼 데이터 표 내에 발견된 임의의 부가적인 오퍼 식별자들은 이러한 동일한 포맷을 사용하여 TLV 인코딩된 데이터 페이로드에 첨부된다. 대표적인 응답 데이터가 표 39에 정의된다.

응답 데이터

데이터 요소	바이트 크기	값
소비자 식별자 태그	1	0XDF21
소비자 식별자 길이	1	16
소비자 식별자	16	[소비자 ID]
로열티 식별자 태그	1	0xDF41
식별자 길이	1	8
로열티 식별자	8	[로열티 ID]
로열티 계좌 코드 태그	1	0xDF43
계좌 코드 길이	1	32
로열티 계좌 코드	32	[계좌 코드]
.......
오퍼 ID 태그	1	0xDF51
오퍼 ID 길이	1	8
오퍼 ID 값	8	[오퍼 ID]
오퍼 코드 태그	1	0xDF53
오퍼 코드 길이	1	130
오퍼 코드 값	130	[오퍼 코드]
.......
합계:	<var>

상거래 애플릿(113)은 총 데이터 길이가 256 바이트들을 초과할 때 다수의 응답 패킷들의 송신을 관리한다(응답 획득 명령어를 사용하여). 표 40은 응답 획득 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

SW1	SW2	설명
90	00	명령어의 성공적인 실행
61	00	응답 획득을 통해 이용 가능한 명령어 w/ 부가적인 데이터의 성공적인 실행
67	00	잘못된 데이터 길이
69	09	내부 오류

트랜잭션 후 데이터

트랜잭션 후 데이터 명령어는 판매자 PoS 시스템 또는 지불 단말기가, 상환된 쿠폰들, 새로운 오퍼들, 전자-영수증들, 또는 다른 향상된 상거래 데이터를 포함한, 트랜잭션-후 데이터를 리턴할 수 있는 방법을 제공한다.

표 41 및 표 42는 트랜잭션 후 데이터 APDU 명령어에 대한 설정들을 정의한다:

트랜잭션 후 데이터

CLA	INS	P1	P2	Lc	데이터	Le
90	52	00	00	xx	<TLV-인코딩된 트랜잭션 데이터>	00

인입 데이터는 TLV 인코딩된 프로비저닝 데이터 및 진실성 목적들을 위한 플랫폼 서명으로 구성된다. 그러므로, Lc 데이터 길이는 가변적이다.

데이터는 상거래 애플릿(113)에 의해 리턴될 필요가 없다. Le 데이터 길이는 0x00이다.

명령어 데이터

데이터 요소	바이트 크기	값
트랜잭션 후 데이터 요소 태그	1	[요소 태그]
요소 데이터 길이	1	xx
요소 데이터 값	xx	[데이터]
.......
합계:	<var>

표 43은 트랜잭션 후 데이터 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

트랜잭션 로그 획득

트랜잭션 로그 획득은 트랜잭션 로그에 저장된 모든 데이터를 획득하기 위해 사용된다. 이러한 명령어는 통상적으로 위젯(widget) 및 보안 요소 데이터 동기화 태스크들의 목적을 위해 상거래 위젯에 의해 사용된다.

표 44는 트랜잭션 로그 획득 APDU 명령어를 위한 설정들을 정의한다:

트랜잭션 로그 획득

CLA	INS		P1	P2	Lc	데이터	Le
90	54		00	0x	00	<없음>
P2 값		애플릿 동작
0x00		정상 프로세싱
0x01		트랜잭션 로그 제거. 어떤 데이터도 송신되지 않음.
0x02		트랜잭션 로그 상태 획득

일 실시예에서, 어떤 데이터도 상거래 애플릿에 전송되지 않는다. Lc 데이터 길이는 0x00이다. 애플릿에 의해 리턴될 트랜잭션 데이터의 실제 길이는 트랜잭션 레코드들의 수 및 대응하는 트랜잭션 로그 데이터의 가변 길이에 의존하여, 가변적이다. 그러므로, Le 데이터 길이는 0x00일 수 있으며, 상거래 애플릿(113)이 가변 길이 응답을 관리하도록 허용한다.

바람직하게는, 응답 데이터는 TLV 포맷팅된 데이터 스트림으로서 리턴된다.

트랜잭션 로그 응답 데이터

각각의 트랜잭션 로그 레코드는 모든 관련된 데이터 요소들에 앞서 내장된-TLV 트랜잭션 로그 태그로 구성된다. 트랜잭션 레코드에 포함된 데이터 요소들은 판매자 판매 시점 관리(point-of-sale)에서 상거래-가능 지불 단말기(NFC 판독기)에 의해 요청된 대응하는 상거래 데이터 획득 명령어 동안 제공된 것들의 미러(mirror)이다. 부가적인 트랜잭션 로그 레코드들은 동일한 포맷을 사용하여 데이터에 첨부된다. 표 45는 대표적인 응답 데이터를 예시한다.

응답 데이터

데이터 요소	바이트 크기	값
내장된 TLV 트랜잭션 레코드 태그	1	0xDF60
내장된 TLV 트랜잭션 레코드 길이	3	xx
TLV-인코딩된 트랜잭션 데이터	xx	xx
.......
합계:	<var>

일 실시예에서, 상거래 애플릿(113)은 총 데이터 길이가 256 바이트들을 초과할 때 응답 획득 명령어를 사용하여 다수의 응답 패킷들의 송신을 관리한다.

트랜잭션 로그 상태 응답 데이터

트랜잭션 로그 상태가 요청될 때, 상거래 애플릿은 내장된 TLV 데이터 페이로드 내의 상태 정보로 응답한다. 이러한 데이터는 마지막 트랜잭션 동안 전송된 이용 가능한 트랜잭션 로그 레코드들의 수, 로열티 및 오퍼 레코드들을 포함한다. 이것은 공유된 인터페이스를 통해 WCAp에 제공된 동일한 데이터 페이로드이다. 표 46은 대표적인 응답 데이터를 예시한다.

응답 데이터

데이터 요소	바이트 크기	값
내장된 TLV 트랜잭션 상태 태그	1	0xE4
내장된 TLV 트랜잭션 레코드 길이	1	0x0C
트랜잭션 레코드 카운트 태그	1	0xDB
트랜잭션 레코드 카운트 길이	1	0x02
트랜잭션 레코드 카운트 값	2	xx
마지막 트랜잭션 로열티 카운트 태그	1	0xDC
마지막 트랜잭션 로열티 카운트 길이	1	0x02
마지막 트랜잭션 로열티 카운트 값	2	xx
마지막 트랜잭션 오퍼 카운트 태그	1	0xDD
마지막 트랜잭션 오퍼 카운트 길이	1	0x02
마지막 트랜잭션 오퍼 카운트 값	2	xx
합계:	14

표 47은 트랜잭션 로그 획득 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

SW1	SW2	설명
90	00	명령어의 성공적인 실행
61	00	응답 획득을 통해 이용 가능한 명령어 w/ 부가적인 데이터의 성공적인 실행
67	00	잘못된 데이터 길이
6B	00	잘못된 P1/P2 파라미터
69	09	내부 오류

내부 오류 코드 획득

내부 오류 코드 획득 명령어는 상거래 서비스들 애플릿에 의해 생성된 마지막 내부 오류 코드를 수신하기 위해 사용된다. 이러한 코드는 오류의 보다 특정된 설명을 제공하는, 내부 오류 코드들 표(표 26)와 상호-참조될 수 있는 값을 제공한다. 이러한 명령어는 보다 상세한 진단 및 오류 해결을 위해 사용된다.

표 48은 내부 오류 코드 획득 APDU 명령어를 위한 설정들을 정의한다:

내부 오류 코드 획득

CLA	INS	P1	P2	Lc	데이터	Le
90	70	00	00	00	<없음>	02

일 실시예에서, 어떤 데이터도 애플릿에 전송되지 않는다. Lc 데이터 길이는 0x00이다. 오류 코드는 2-바이트 응답 내에 포함된다. 그러므로, Le 데이터 길이는 0x02이다.

다음의 표는 이러한 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

로열티 서비스들

로열티 데이터 획득

표 50 및 표 51에 정의된 로열티 데이터 획득 명령어는 특정된 로열티 식별자에 기초하여 저장된 로열티 정보를 획득하기 위해 사용된다. 2-바이트 로열티 식별자는 요청된 로열티 정보를 특정하기 위해 인입 데이터의 일부로서 전송될 수 있다. 상거래 애플릿(113)은 특정된 판매자/로열티 ID에 대한 로열티 데이터의 표를 탐색하며 대응하는 로열티 데이터의 모두를 검색한다.

로열티 데이터 획득

CLA	INS	P1	P2	Lc	데이터	Le
90	30	00	00	xx	[TLV-인코딩된 로열티 ID]	00

(선택적) 인입 데이터는 요청된 로열티 정보를 표시하는 TLV 인코딩된 로열티 식별자로 구성될 것이다. Lc가 0x00으로 설정되면(어떤 데이터 인입 데이터도 특정되지 않음), 모든 이용 가능한 로열티 식별자들이 리턴된다.

애플릿에 의해 리턴된 요청된 로열티 데이터의 실제 길이는 요청된/이용 가능한 로열티 데이터에 특정하여 가변적이다. 그러므로, Le 데이터 길이는 0x00이며, 애플릿은 가변 길이 응답을 관리하도록 허용한다.

명령어 데이터

데이터 요소	바이트 크기	값
로열티 식별자 태그	1	0xDF41
로열티 식별자 길이	1	8
로열티 식별자	8	[로열티 ID]
합계:	<var>

응답 데이터(표 51)는 TLV 포맷팅된 데이터 스트림으로서 리턴된다. 관련 있는 로열티 데이터의 모두는 단일 데이터 페이로드에 리턴된다.

일 실시예에서, 로열티 데이터 덤프(dump)가 요청된다면(Lc = 0x00), 모든 로열티 식별자들의 리스트는 LV(태그 없음) 포맷으로 리턴된다. 따라서, 단지 각각의 엔트리를 위한 로열티 식별자만이 데이터 페이로드에 포함된다.

로열티 데이터의 각각의 인스턴스는 다음의 데이터 요소들을 포함한다:

● 로열티 식별자

● 로열티 계좌 코드

응답 데이터

데이터 요소	바이트 크기	값
로열티 식별자 태그	1	0xDF41
식별자 길이	1	8
로열티 식별자	8	[로열티 ID]
로열티 계좌 코드 태그	1	0xDF43
계좌 코드 길이	1	xx
로열티 계좌 코드	xx	[계좌 코드]
합계 (최대):	<var>

표 53은 이러한 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

업데이트 로열티 데이터

업데이트 로열티 데이터 명령어는 특정된 판매자 로열티 데이터를 부가하거나 또는 업데이트하기 위해 사용된다. 데이터는 TLV 포맷팅된 데이터 스트림으로서 전송된다. 특정된 로열티 식별자가 존재한다면, 대응하는 로열티 데이터 요소들이 업데이트된다. 로열티 식별자가 존재하지 않는다면, 새로운 데이터 레코드가 로열티 데이터 표에 생성된다. 표 54 및 표 55는 로열티 데이터 업데이트 APDU 명령어를 위한 설정들을 정의한다:

로열티 데이터 업데이트

CLA	INS	P1	P2	Lc	데이터	Le
90	32	00	00	xx	TLV-인코딩된 로열티 데이터	00

인입 데이터는 TLV 인코딩된 로열티 데이터로 이루어질 것이다. 그러므로, Lc 데이터 길이는 가변적이다. 일 실시예에서, 어떤 데이터도 애플릿에 의해 리턴되지 않는다. Le 데이터 길이는 0x00이다.

명령어 데이터

데이터 요소	바이트 크기	값
로열티 식별자 태그	1	0xDF41
식별자 길이	1	8
로열티 식별자	8	[로열티 ID]
로열티 계좌 코드 태그	1	0xDF43
계좌 코드 길이	1	xx
로열티 계좌 코드	Xx	[계좌 코드]
합계:	<var>

표 56은 이러한 명령어에 의해 복구될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

로열티 데이터 삭제

로열티 데이터 삭제 명령어는 특정된 판매자 로열티 데이터를 삭제하기 위해 사용된다. 1-바이트 판매자 코드는 명령어 데이터를 통해 특정된다. 대안적으로, P2 바이트는 모든 기존의 오퍼들을 퍼징(purging)하기 위해 사용될 수 있다. P2가 0xFF로 설정된다면, 전체 오퍼 데이터 저장소는 삭제된다.

표 57 및 표 58은 로열티 데이터 삭제 APDU 명령어를 위한 설정들을 정의한다:

로열티 데이터 삭제

CLA	INS	P1	P2	Lc	데이터	Le
90	34	00	xx	xx	TLV-인코딩된 로열티 ID	00

인입 데이터는 TLV-인코딩된 로열티 식별자로 구성된다. 그러므로, Lc 데이터 길이는 가변적이다.

명령어 데이터

데이터 요소	바이트 크기	값
로열티 식별자 태그	1	0xDF41
로열티 식별자 길이	1	xx
로열티 식별자	Xx	[로열티 ID]
합계:	<var>
P2 값	애플릿 동작
0x00	정상 프로세싱
0xFF	로열티 표 퍼징(모든 레코드들 삭제)

표 59는 로열티 데이터 삭제 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

판매자 캐싱된 데이터 서비스들

캐싱된 판매자 데이터 획득

캐싱된 판매자 데이터 획득 명령어는 특정 판매자에 관계된 모든 이전 로딩된 데이터를 획득하기 위해 사용된다. 판매자 식별자는 요청된 사전-로딩된 데이터를 특정하기 위해 인입 데이터의 일부로서 전송될 수 있다. 제공된다면, 상거래 애플릿은 특정된 판매자 ID에 대한 캐싱된 판매자 데이터의 표를 탐색하며 대응하는 데이터의 모두를 검색한다. 또한 이러한 명령어는 상거래 서비스들 애플릿 내에 저장된 모든 캐싱된 판매자들에 대한 정보를 획득하기 위해 사용될 수 있다.

표 60은 캐싱된 판매자 데이터 획득 APDU 명령어를 위한 설정들을 정의한다:

캐싱된 판매자 획득 데이터

CLA	INS	P1	P2	Lc	데이터	Le
90	56	00	00	xx	<없음>	00

일 실시예에서, 어떤 데이터도 애플릿에 전송되지 않는다. Lc 데이터 길이는 0x00이다. 애플릿에 의해 리턴된 요청된 캐싱된 판매자 데이터의 실제 길이는 요청된/이용 가능한 캐싱된 판매자 데이터에 특정하여, 가변적이다. 그러므로, Le 데이터 길이는 0x00이며; 애플릿이 가변 길이 응답을 관리하도록 허용한다.

응답 데이터(표 61)가 TLV 포맷팅된 데이터 스트림으로서 리턴될 수 있다. 캐싱된 데이터의 모두는 단일 데이터 페이로드에 리턴된다. 캐싱된 판매자 데이터의 각각의 인스턴스는 다음의 대응하는 캐싱된 판매자 데이터 요소들(이용 가능하다면)을 포함한다:

● 판매자 식별자

● 로열티 식별자

● 로열티 계좌 코드

● 오퍼 식별자(들)

● 오퍼 코드(들)

응답 데이터

데이터 요소	바이트 크기	값
판매자 ID 태그	1	0xDF31
판매자 ID 길이	1	8
판매자 ID	8	[판매자 ID]
로열티 ID 태그	1	0xDF41
로열티 ID 길이	1	8
로열티 ID 값	8	[로열티 ID]
로열티 계좌 코드 태그	1	0xDF43
로열티 계좌 코드 길이	1	32
로열티 계좌 코드 값	32	[로열티 계좌 코드]
.......
오퍼 ID 태그	1	0xDF51
오퍼 ID 길이	1	xx
오퍼 ID 값	Xx	[오퍼 ID]
오퍼 코드 태그	1	0xDF53
오퍼 코드 길이	1	xx
오퍼 코드 값	Xx	[오퍼 코드]
.......
합계:	<var>

대표적인 실시예에서, 캐싱된 판매자 데이터는 지갑 애플리케이션에 의해 로딩/관리될 것이며 그 특정 판매자에 관계된 다수의 오퍼 ID들/코드들을 포함할 수 있다. 그러나, 애플릿은 응답 데이터 앞에 소비자 식별자를 붙이며 상거래 데이터 획득 명령어에 의해 요청된 임의의 부가적인 로열티/오퍼 데이터를 첨부할 것이다.

표 62는 이러한 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

캐싱된 판매자 데이터 업데이트

캐싱된 판매자 데이터 업데이트 명령어는 특정된 판매자를 위한 캐싱된(빠른-응답) 데이터를 업데이트하기 위해 사용된다. 데이터는 상거래 데이터 획득 명령어에 의해 리턴된 응답 데이터와 유사하게, TLV 포맷팅된 데이터 스트림으로서 전송된다. 이러한 명령어는 주어진 판매자의 상거래 데이터 획득 응답을 사전-로딩하기 위해 사용된다.

표 63 및 표 64는 캐싱된 판매자 데이터 업데이트 APDU 명령어를 위한 설정들을 정의한다:

캐싱된 판매자 데이터 업데이트

CLA	INS		P1	P2	Lc	데이터	Le
90	58		00	0x	xx	TLV-인코딩된 캐싱된 판매자 데이터]	02
P2 값		애플릿 동작
0x00		정상 프로세싱
0x01		APDU 체인(Chain)(데이터는 CMD 버퍼에 첨부될 것이다)
0Xff		캐싱된 판매자 데이터 삭제 [Lc = 0]

인입 데이터는 내장된 TLV 인코딩된 캐싱된 판매자 데이터로 구성된다. 그러므로, Lc 데이터 길이는 가변적이다.

상거래 애플릿은 캐싱된 판매자 데이터 버퍼에 남아있는 이용 가능한 바이트들의 수를 포함한 2 바이트 응답을 리턴한다. 그러므로, Le 데이터 길이는 0x02(또는 0x00)이다.

명령어 데이터

데이터 요소	바이트 크기	값
판매자 ID 태그	1	0xDF31
판매자 ID 길이	1	8
판매자 ID 값	8	[판매자 ID]
캐싱된 판매자 데이터 오퍼 카운트 태그	1	0x57
캐싱된 판매자 데이터 오퍼 카운트 길이	1	1
캐싱된 판매자 데이터 오퍼 카운트 값	1	[CMD 오퍼 카운트]
내장된 TLV 캐싱된 판매자 데이터 태그	1	0x58
내장된 TLV 캐싱된 판매자 데이터 길이	Xx	xx
오퍼 ID 태그	1	0xDF51
오퍼 ID 길이	1	xx
오퍼 ID 값	Xx	[오퍼 ID]
오퍼 코드 태그	1	0xDF53
오퍼 코드 길이	1	xx
오퍼 코드 값	Xx	[오퍼 코드]
.......
합계:	<var>

명령어에 의해 리턴된 응답 데이터(표 65)는 캐싱된 판매자 데이터 버퍼에 이용 가능한 나머지 바이트들의 수를 표현하는 2-바이트 (쇼트) 값으로 구성된다. 이것은 지갑 애플리케이션(114)으로 하여금 얼마나 많은 캐싱된 오퍼들이 상거래 서비스들 애플릿에 "맞을(fit)" 수 있는지를 관리하도록 허용한다.

응답 데이터

데이터 요소	바이트 크기	값
이용 가능한 캐싱된 판매자 데이터 버퍼 (바이트들) 크기	2	xx
합계:	2

표 66은 이러한 명령어에 의해 리턴될 수 있는 가능한 상태 워드 값들을 정의한다.

상태 코드들

표 67은 본 명세서에 설명된 예시적인 측면들에 따라 상거래 기반 애플리케이션들에 의해 사용된 데이터 요소들 및 대응하는 태그 값들 및 타겟/최대 바이트 크기들을 정의한다. 부가적인 값들은 제한된/고정된 값 범위를 갖고 이들 요소들을 위해 제공받는다.

상거래 서비스들
공유된 데이터 요소들
데이터 요소	태그	최대 크기	설명
날짜_시간_스탬프	0x11	7	날짜/시간 스탬프
상거래_앱_버전	0x12	3	지원된 상거래 앱 버전 번호
소비자 데이터 요소들
데이터 요소	태그	최대 크기	설명
소비자_ID	0x21	16	MoCom 플랫폼 특정 소비자 식별자
소비자_키	0x22	16	MoCom 플랫폼 발생된 소비자 특정 3DES 키
소비자_인증서	0x23	8	MoCom 플랫폼 발생 소비자 서명/인증서
판매자 데이터 요소들
데이터 요소	태그	최대 크기	설명
판매자_ID	0x31	8	MoCom 플랫폼 특정 판매자 식별자
판매자_상점_ID	0x32	32	MoCom 플랫폼 특정 판매자 상점 식별자
판매자_능력	0x33	2	지원된 상거래 앱 서비스들
판독기_시작_모드	0x34	2	NFC 가능 지불 단말기 시작 모드(이니트(init) 동안 판매자 POS 시스템에 의해 제공된)
판매자 능력들
데이터 요소	값	최대 크기	설명
MERCAP_판매자_로열티	0x80	1	상거래 데이터 획득은 애플릿에 의해 수신된 로열티 데이터를 결정하기 위해 사용된 유효한 판매자 식별자를 포함한다.
MERCAP_부가_로열티	0x40	1	상거래 데이터 획득 요청은 부가적인 로열티 식별자들을 포함한다. 부가적인 로열티 데이터는 특정된 로열티 ID(들)에 의해 결정된다.
MERCAP_판매자_오퍼들	0x20	1	오퍼 유형 필드들은 상거래 데이터 획득 요청에 포함된다.
MERCAP_부가_오퍼들	0x10	1	상거래 데이터 획득은 애플릿에 의해 수신된 오퍼 데이터를 결정하기 위해 사용된 유효 판매자 식별자를 포함한다.
MERCAP_지불	0x08	1	판매자는 무접촉 지불을 지원한다.
MERCAP_클라우드	0x02	1	판매자는 클라우든 상환을 지원한다. 단지 소비자 ID만이 클라우드에서의 해결을 위해 애플릿에 의해 리턴될 것이다.
MERCAP_상환	0x01	1	판매자 및 지불 단말기는 트랜잭션 후 명령어를 통해 애플릿으로의 오퍼 상환 데이터(ECR로부터)의 송신을 지원한다.
MoCom 플랫폼 데이터 요소들
플랫폼_서명	0x71	8	원격 검증 목적들(데이터 무결성/진실성)을 위해 플랫폼으로부터 비롯된 명령어/데이터에 첨부된 MoCom 플랫폼 발생 MAC/서명
플랫폼_키	0x72	16	MoCom 플랫폼 키
플랫폼_인증서	0x73	8	MoCom 플랫폼 인증서
로열티
로열티 데이터 요소들
데이터 요소	태그	최대 크기	설명
내장된_TLV_ 로열티_데이터	0x40	xx	내장된 TLV 로열티 데이터 태그
로열티_ID	0x41	8	MoCom 플랫폼 특정 로열티 식별자
로열티_상태	0x42	1	로열티 카드/계좌 상태(이하 참조)
로열티_계좌_ 코드	0x43	32	로열티 계좌(바코드 데이터)
로열티_MAC_ 서명	0x44	8	진정성/진실성 검증을 위한 MoCom 플랫폼 특정 MAC/서명
로열티 상태
데이터 요소	값	최대 크기	설명
로열티_상태_비활성화	0x00	1	로열티 계좌 비활성. 이용 가능하지 않음.
로열티_상태_활성	0x01	1	로열티 계좌 활성. 사용을 위해 이용 가능함.
트랜잭션 로그
트랜잭션 데이터 요소들
데이터 요소	태그		최대 크기	설명
내장된_TLV_트랜잭션_로그	0x60		xx	트랜잭션 로그 레코드 데이터 태그
트랜잭션_ID	0x61		16	트랜잭션 ID (ECR에 의해 할당됨)
트랜잭션_상태	0x62		11	트랜잭션 상태; 상태 바이트(이하 참조), 2-바이트 상태 워드, 2-바이트 내부 오류 코드, 2-바이트 수의 이용 가능한 트랜잭션 레코드들, 2-바이트 마지막 트랜잭션 로열티 카운트, 2-바이트 마지막 트랜잭션 오퍼 카운트를 포함함
트랜잭션 상태
데이터 요소	값		최대 크기	설명
트랜잭션_상태_성공적	0x00		1	상거래 데이터가 수신됨. 결과 계류 중
트랜잭션_상태_실패	0x01		1	오류 검출됨. 내부 오류 코드 첨부됨..
오퍼들
오퍼 데이터 요소들
데이터 요소	태그	최대 크기	설명
내장된_TLV_오퍼_데이터	0x50	xx	내장된 TLV 오퍼 데이터 태그
오퍼_ID	0x51	8	MoCom 플랫폼 특정 오퍼 식별자
오퍼_상태	0x52	1	오퍼 상태(이하 참조)
오퍼_코드	0x53	48	오퍼(UPC/EPC/GS1 데이터바) 바코드 데이터
오퍼_유형_코드	0x54	9	오퍼 유형(이하 참조)
오퍼_MAC_서명	0x55	8	MoCom 플랫폼 특정 데이터 보안 서명
오퍼_업데이트_플래그	0x56	1	업데이트 플래그(동기화 상태)
캐싱된_판매자_데이터_오퍼_카운트	0x57	1	캐싱된 판매자 데이터 내에서의 오퍼 카운트
내장된_TLV_캐싱된_판매자_ 데이터	0x58	xx	내장된 TLV 캐싱된 판매자 (오퍼) 데이터
오퍼 상태
데이터 요소	값	최대 크기	설명
오퍼_상태_비활성화	0x00	1	데이터 저장소에 존재하지만, 상환을 위해 이용 가능하지 않은 오퍼.
오퍼_상태_활성	0x01	1	데이터 저장소에 존재하는 오퍼. 상환을 위해 이용 가능함.
오퍼_상태_만료	0x10	1	만료된 오퍼
오퍼_상태_제출	0x20	1	오퍼가 상환을 위해 제공되었다. 결과 계류 중.
오퍼_상태_상환	0x40	1	오퍼가 상환되었다.
오퍼 유형
데이터 요소	값	최대 크기	설명
오퍼_유형_클래스_01	0x01	1	오퍼 클래스: 판매자 특정 (판매자 ID 첨부됨)
오퍼_유형_클래스_02	0x02	1	오퍼 클래스: CPG
오퍼_유형_클래스_03	0x03	1	오퍼 클래스: Misc

특수하게 포맷팅된 데이터 요소들

상거래 데이터 페이로드에 포함된 데이터 요소들 중 몇 개는 그 요소를 위해 사용된 데이터 인코딩을 식별하는 포맷 바이트를 포함한다. 데이터 인코딩은 판매 시점 관리에서의 호환성을 보장하기 위해 판매자에 의해 특정된다. 포맷팅된 데이터 값은 MoCom 플랫폼에 의해 지갑 애플리케이션에 공급된다. 따라서, 어떤 부가적인 해석/포맷팅도 플랫폼, 지갑, 보안 요소, 및 지불 단말기 사이에서 필요하지 않다. 데이터를 적절히 해석하고 그것을 프로세싱을 위해 판매자 시스템에 공급하는 것이 지불 단말기(또는 판매자 POS 시스템)의 역할이다.

다음의 데이터 요소들은 포맷 바이트를 포함할 것이다:

● 로열티 계좌 코드

● 오퍼 코드

표 68은 가능한 포맷 바이트 값들 및 그것들의 대응하는 인코딩 규칙을 정의한다:

포맷 바이트	인코딩 규칙	설명
0x00	16진수	데이터의 각각의 바이트는 (원) 16진수 포맷으로 인코딩된다.
0x01	이진 코딩된 십진법(BCD)	각각의 니블은 단일 숫자를 표현한다. 따라서, 단지 십진 값들이 특정된다. 홀수(길이)의 숫자들을 포함한 데이터 스트림은 데이터 스트림의 제 1 니블에서 16진수 값 'F'을 포함한다.
0x02	ASCII	각각의 바이트는 이와 같이 해석되며 그것의 대응하는 CHAR 값으로서 핸들링되는 ASCII 값을 나타낸다. 대부분의 경우들에서, 이들 데이터 스트림들은 프로세싱을 위해 판매자 POS 시스템으로 전달되기 전에 스트링으로 변환될 것이다.

컴퓨터 판독 가능한 매체 구현

예를 들면, 도 1 내지 도 7에 도시되거나 또는 그것과 관련되어 논의된 시스템들 및 절차들 또는 그것의 임의의 부분 또는 기능과 같이 상기 설명된 예시적인 실시예들은 하드웨어, 소프트웨어 또는 그 둘의 조합을 사용함으로써 구현될 수 있다. 구현은 하나 이상의 컴퓨터들 또는 다른 프로세싱 시스템들에 있을 수 있다. 이들 예시적인 실시예들에 의해 수행된 조작들은 흔히 인간 운영자에 의해 수행된 정신 작용들과 연관된 용어들로 나타내어지지만, 어떤 인간 운영자도 본 명세서에 설명된 동작들 중 임의의 것을 수행하도록 요구되지 않는다. 다시 말해서, 동작들은 기계 동작들로 완전히 구현될 수 있다. 본 명세서에 제공된 예시적인 실시예들의 동작을 수행하기 위한 유용한 기계들은 범용 디지털 컴퓨터들 또는 유사한 디바이스들을 포함한다.

도 8은 본 발명의 예시적인 실시예들 중 몇몇에 따라, 일반 및/또는 특수 목적 컴퓨터(800)의 블록도이다. 컴퓨터(800)는 예를 들면, 다른 것들 중에서 특히, 사용자 디바이스, 사용자 컴퓨터, 클라이언트 컴퓨터 및/또는 서버 컴퓨터일 수 있다.

컴퓨터(800)는 제한 없이 프로세스 디바이스(810), 메인 메모리(main memory)(825), 및 상호 연결 버스(interconnect bus)(805)를 포함할 수 있다. 프로세서 디바이스(810)는 제한 없이 단일 마이크로프로세서(microprocessor)를 포함할 수 있거나, 또는 다중-프로세서 시스템으로서 컴퓨터(800)를 구성하기 위한 복수의 마이크로프로세서들을 포함할 수 있다. 메인 메모리(825)는 다른 것들 중에서 특히, 프로세서 디바이스(810)에 의한 실행을 위한 지시들 및/또는 데이터를 저장한다. 메인 메모리(625)는 동적 랜덤 액세스 메모리(DRAM; dynamic random access memory)의 뱅크들(banks), 뿐만 아니라 캐시 메모리(cache memory)를 포함할 수 있다.

컴퓨터(800)는 대량 저장 디바이스(830), 주변 디바이스(들)(840), 휴대용 저장 매체 디바이스들)(850), 입력 제어 디바이스(들)(880), 그래픽스 서브시스템(860), 및/또는 출력 디스플레이(870)를 더 포함할 수 있다. 설명적인 목적들을 위해, 컴퓨터(800)에서의 모든 구성요소들이 버스(805)를 통해 결합되는 바와 같이 도 8에 도시된다. 그러나, 컴퓨터(800)는 그렇게 제한되지 않는다. 컴퓨터(800)의 디바이스들은 하나 이상의 데이터 수송 수단을 통해 결합될 수 있다. 예를 들면, 프로세서 디바이스(810) 및/또는 메인 메모리(825)는 로컬 마이크로프로세서 버스를 통해 결합될 수 있다. 대량 저장 디바이스(830), 주변 디바이스(들)(840), 휴대용 저장 매체 디바이스(들)(850), 및/또는 그래픽스 서브시스템(860)은 하나 이상의 입력/출력(I/O) 버스들을 통해 결합될 수 있다. 대량 저장 디바이스(830)는 프로세서 디바이스(810)에 의한 사용을 위해 데이터 및/또는 지시들을 저장하기 위한 비휘발성 저장 디바이스일 수 있다. 대량 저장 디바이스(830)는 예를 들면, 자기 디스크 드라이브(magnetic disk drive) 또는 광 디스크 드라이브를 갖고 구현될 수 있다. 소프트웨어 실시예에서, 대량 저장 디바이스(830)는 메인 메모리(825)로 대량 저장 디바이스(830)의 콘텐츠를 로딩하기 위해 구성된다.

휴대용 저장 매체 디바이스(850)는 컴퓨터(800)로 및 그로부터 데이터 및 코드를 입력 및 출력하기 위해, 예를 들면, 콤팩트 디스크 판독 전용 메모리(CD-ROM; compact disc read only memory)와 같은, 비휘발성 휴대용 저장 매체와 함께 동작한다. 몇몇 실시예들에서, 메타데이터에 내부 식별자를 저장하기 위한 소프트웨어는 휴대용 저장 매체 상에 저장될 수 있으며, 휴대용 저장 매체 디바이스(850)를 통해 컴퓨터(800)로 입력될 수 있다. 주변 디바이스(들)(840)는 예를 들면, 컴퓨터(800)에 부가적인 기능을 부가하도록 구성된 입력/출력(I/O) 인터페이스와 같은, 임의의 유형의 컴퓨터 지원 디바이스를 포함할 수 있다. 예를 들면, 주변 디바이스(들)(840)는 네트워크(820)와 컴퓨터(800)를 인터페이싱하기 위한 네트워크 인터페이스 카드를 포함할 수 있다.

입력 제어 디바이스(들)(880)는 컴퓨터(800)의 사용자를 위해 사용자 인터페이스의 일 부분을 제공한다. 입력 제어 디바이스(들)(880)는 키패드(keypad) 및/또는 커서(cursor) 제어 디바이스를 포함할 수 있다. 키패드는 영숫자 문자들 및/또는 다른 키 정보를 입력하기 위해 구성될 수 있다. 커서 제어 디바이스는 예를 들면, 마우스(mouse), 트랙볼(trackball), 스타일러스(stylus), 및/또는 커서 방향 키들을 포함할 수 있다. 텍스트 및 그래픽 정보를 디스플레이하기 위해, 컴퓨터(800)는 그래픽스 서브시스템(860) 및 출력 디바이스(870)를 포함할 수 있다. 출력 디스플레이(870)는 음극선관(CRT; cathode ray tube) 디스플레이 및/또는 액정 디스플레이(LCD; liquid crystal display)를 포함할 수 있다. 그래픽스 서브시스템(860)은 텍스트 및 그래픽 정보를 수신하며, 출력 디스플레이(870)로의 출력을 위해 정보를 프로세싱한다.

컴퓨터(800)의 각각의 구성요소는 일반 및/또는 특수 목적 컴퓨터의 컴퓨터 구성요소의 광범위한 카테고리를 나타낼 수 있다. 컴퓨터(800)의 구성요소들은 여기에 제공된 특정 구현들에 제한되지 않는다.

본 발명의 예시적인 실시예들의 부분들은, 컴퓨터 기술에서의 숙련자들에 의해 명백한 바와 같이, 종래의 범용 컴퓨터, 특수화된 디지털 컴퓨터 및/또는 본 발명의 교시들에 따라 프로그램된 마이크로프로세서를 사용함으로써 편리하게 구현될 수 있다. 적절한 소프트웨어 코딩은 본 발명의 교시들에 기초하여 숙련된 프로그래머들에 의해 쉽게 준비될 수 있다.

또한 몇몇 실시예들은 애플리케이션-특정 집적 회로들, 필드 프로그램 가능한 게이트 어레이들(field programmable gate arrays)의 준비에 의해, 또는 종래의 구성요소 회로들의 적절한 네트워크를 상호 연결함으로써 구현될 수 있다.

몇몇 실시예들은 컴퓨터 프로그램 제품을 포함한다. 컴퓨터 프로그램 제품은 컴퓨터로 하여금 본 발명의 예시적인 실시예들의 절차들 중 임의의 것을 수행하게 하거나, 또는 그것을 제어하게 하기 위해 사용될 수 있는 그것 상에 또는 그것 내에 저장된 지시들을 가진 저장 매체 또는 미디어(media)일 수 있다. 저장 매체는 제한 없이, 플로피 디스크(floppy disk), 미니 디스크(mini disk), 광 디스크(optical disk), 블루-레이 디스크(Blu-Ray Disc), DVD, CD-ROM, 마이크로-드라이브(micro-drive), 자기-광학 디스크, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, 플래시 메모리(flash memory), 플래시 카드, 자기 카드, 광학 카드, 나노시스템들(nanosystems), 분자 메모리 집적 회로, RAID, 원격 데이터 저장장치/아카이브(archive)/웨어하우징(warehousing), 및/또는 지시들 및/또는 데이터를 저장하기에 적합한 임의의 다른 유형의 디바이스를 포함할 수 있다.

컴퓨터 판독 가능한 매체 또는 미디어 중 임의의 하나 상에 저장되면, 몇몇 구현들은 일반 및/또는 특수 컴퓨터 또는 마이크로프로세서의 하드웨어 양자 모두를 제어하기 위해, 및 컴퓨터 또는 마이크로프로세서로 하여금 본 발명의 예시적인 실시예들의 결과들을 이용하는 인간 사용자 또는 다른 메커니즘과 상호 작용할 수 있게 하기 위한 소프트웨어를 포함한다. 이러한 소프트웨어는 제한 없이 디바이스 드라이버들, 운영 시스템들, 및 사용자 애플리케이션들을 포함할 수 있다. 궁극적으로, 이러한 컴퓨터 판독 가능한 미디어는 상기 설명된 바와 같이, 본 발명의 예시적인 측면들을 수행하기 위한 소프트웨어를 더 포함한다.

상기 설명된 절차들을 구현하기 위한 소프트웨어 모듈들(modules)이 일반 및/또는 특수 목적 컴퓨터 또는 마이크로프로세서의 프로그래밍 및/또는 소프트웨어에 포함된다.

본 발명의 다양한 예시적인 실시예들이 상기 설명되었지만, 그것들은 제한이 아닌, 예컨대 제공된다는 것이 이해되어야 한다. 형태 및 세부사항에서의 다양한 변화들이 여기에서 이루어질 수 있다는 것이 관련 기술(들)에서의 숙련자들에게 명백하다. 따라서, 본 발명은 상기 설명된 예시적인 실시예들 중 임의의 것에 의해 제한되지 않아야 하며, 단지 다음의 청구항들 및 그것들의 등가물들에 따라서만 정의되어야 한다.

또한, 도면들은 단지 예시적인 목적들을 위해 제공된다는 것이 이해되어야 한다. 본 명세서에 제공된 예시적인 실시예들의 아키텍처(architecture)는 충분히 유연하며 구성 가능하고, 따라서 그것은 첨부한 도면들에 도시된 것이 아닌 방식들로 이용되며 내비게이션(navigation)될 수 있다.

뿐만 아니라, 요약의 목적은 미국 특허 상표국 및 일반적으로 대중, 및 특히 특허 또는 법적 용어들 또는 어법에 친숙하지 않은 과학자들, 엔지니어들 및 전문가들이 출원의 기술적 개시의 특성 및 본질을 피상적인 검사로부터 빠르게 결정할 수 있게 하는 것이다. 요약은 임의의 방식으로 본 명세서에 제공된 예시적인 실시예들의 범위에 대하여 제한적인 것으로 의도되지 않는다. 청구항들에 나열된 절차들은 제공된 순서로 수행될 필요가 없다는 것이 또한 이해될 것이다.

Claims

이동 디바이스, 판독기 및 판매 시점 관리(POS; point of sale) 시스템 간의 지불 트랜잭션 외에도 무접촉 상거래 트랜잭션을 관리하기 위한 시스템에 있어서, 상기 시스템은:
적어도 하나의 프로세서를 포함하며, 상기 프로세서는:
트랜잭션의 개시와 연관하여 활성화 요청을 수신하고;
이동 디바이스로부터 제1 탭(tap)을 식별하고 -상기 제1 탭은 상기 이동 디바이스가 상기 판독기에 대한 근거리 내에 위치될 때 발생하며-;
상기 이동 디바이스로부터 상기 제1 탭을 식별하는 것에 응답하여, 제1 상거래 애플리케이션에 대응하는 선택 상거래 애플리케이션 식별자(AID)를 포함하는 제1 선택 상거래 명령을 상기 이동 디바이스에 송신하고;
상기 이동 디바이스로부터 상기 제1 선택 상거래 명령에 기초한 제1 응답을 수신하고;
머천트(merchant) 특정 정보를 포함하는 데이터 요청을 상기 이동 디바이스에 송신하고;
상기 이동 디바이스로부터 상기 데이터 요청에 기초한 제2 응답을 수신하고 -상기 제2 응답은 상기 머천트 특정 정보에 대응하는 상거래 요소들을 포함함 -;
상기 머천트 특정 정보에 대응하는 상기 상거래 요소들 중 하나 이상이 상기 트랜잭션에 적용된 후에 머천트 POS 시스템으로부터 트랜잭션-후(post-transaction) 데이터를 수신하고;
상기 이동 디바이스로부터 제2 탭을 식별하고 -상기 제2 탭은 상기 이동 디바이스가 상기 판독기에 대한 근거리 내에 위치될 때 발생하며-;
상기 이동 디바이스로부터의 상기 제2 탭을 식별하는 것에 응답하여, 상기 이동 디바이스로 지불 AID 요청을 송신하고;
지불 애플리케이션에 대응하는 AID를 상기 이동 디바이스로부터 수신하고;
상기 지불 애플리케이션에 대응하는 상기 AID를 포함하는 선택 지불 명령을 상기 이동 디바이스에 송신하고;
상기 이동 디바이스로부터 상기 지불 애플리케이션에 대응하는 파일 제어 정보(FCI; file control information)를 수신하고;
상기 이동 디바이스로부터 지불 데이터를 수신하고;
상기 제1 상거래 애플리케이션에 대응하는 상기 AID를 포함하는 제2 선택 상거래 명령을 상기 이동 디바이스에 송신하고;
상기 제2 선택 상거래 명령에 기초하여 제3 응답을 상기 이동 디바이스로부터 수신하고;
상기 이동 디바이스에 상기 트랜잭션-후 데이터를 송신하고;
상기 이동 디바이스로부터 상기 트랜잭션-후 데이터에 기초하여 제4 응답을 수신하고;
상기 제1 선택 상거래 명령, 상기 선택 지불 명령, 및 상기 제2 선택 상거래 명령이 성공적으로 프로세싱되었는지 여부를 결정하고;
상기 지불 데이터를 상기 POS 시스템에 송신하도록 동작 가능한 것을 특징으로 하는 무접촉 상거래 트랜잭션을 관리하기 위한 시스템.
청구항 1에 있어서,
상기 적어도 하나의 프로세서는:
상기 제1 선택 상거래 명령이 성공적으로 프로세싱되었는지 여부를 결정하고;
상기 상거래 요소들을 상기 판매 시점 관리 시스템에 송신하도록 더 동작 가능한 것을 특징으로 하는 무접촉 상거래 트랜잭션을 관리하기 위한 시스템.
이동 디바이스, 판독기 및 판매 시점 관리(POS; point of sale) 시스템 간의 지불 트랜잭션 외에도 무접촉 상거래 트랜잭션을 관리하기 위한 방법에 있어서, 상기 방법은:
적어도 하나의 프로세서에 의해, 트랜잭션의 개시와 연관하여 활성화 요청을 수신하는 단계;
상기 적어도 하나의 프로세서에 의해, 이동 디바이스로부터 제1 탭(tap)을 식별하는 단계 -상기 제1 탭은 상기 이동 디바이스가 상기 판독기에 대한 근거리 내에 위치될 때 발생하며-;
상기 이동 디바이스로부터 상기 제1 탭을 식별하는 것에 응답하여, 상기 적어도 하나의 프로세서에 의해, 제1 상거래 애플리케이션에 대응하는 선택 상거래 애플리케이션 식별자(AID)를 포함하는 제1 선택 상거래 명령을 상기 이동 디바이스에 송신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 이동 디바이스로부터 상기 제1 선택 상거래 명령에 기초한 제1 응답을 수신하는 단계;
상기 적어도 하나의 프로세서에 의해, 머천트(merchant) 특정 정보를 포함하는 데이터 요청을 상기 이동 디바이스에 송신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 이동 디바이스로부터 상기 데이터 요청에 기초한 제2 응답을 수신하는 단계 -상기 제2 응답은 상기 머천트 특정 정보에 대응하는 상거래 요소들을 포함함 -;
상기 적어도 하나의 프로세서에 의해, 상기 머천트 특정 정보에 대응하는 상기 상거래 요소들 중 하나 이상이 상기 트랜잭션에 적용된 후에 머천트 POS 시스템으로부터 트랜잭션-후(post-transaction) 데이터를 수신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 이동 디바이스로부터 제2 탭을 식별하는 단계 -상기 제2 탭은 상기 이동 디바이스가 상기 판독기에 대한 근거리 내에 위치될 때 발생하며-;
상기 이동 디바이스로부터의 상기 제2 탭을 식별하는 것에 응답하여, 상기 적어도 하나의 프로세서에 의해, 상기 이동 디바이스로 지불 AID 요청을 송신하는 단계;
상기 적어도 하나의 프로세서에 의해, 지불 애플리케이션에 대응하는 AID를 상기 이동 디바이스로부터 수신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 지불 애플리케이션에 대응하는 상기 AID를 포함하는 선택 지불 명령을 상기 이동 디바이스에 송신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 이동 디바이스로부터 상기 지불 애플리케이션에 대응하는 파일 제어 정보(FCI; file control information)를 수신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 이동 디바이스로부터 지불 데이터를 수신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 제1 상거래 애플리케이션에 대응하는 상기 AID를 포함하는 제2 선택 상거래 명령을 상기 이동 디바이스에 송신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 제2 선택 상거래 명령에 기초하여 제3 응답을 상기 이동 디바이스로부터 수신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 이동 디바이스에 상기 트랜잭션-후 데이터를 송신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 이동 디바이스로부터 상기 트랜잭션-후 데이터에 기초하여 제4 응답을 수신하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 제1 선택 상거래 명령, 상기 선택 지불 명령, 및 상기 제2 선택 상거래 명령이 성공적으로 프로세싱되었는지 여부를 결정하는 단계;
상기 적어도 하나의 프로세서에 의해, 상기 지불 데이터를 상기 POS 시스템에 송신하는 단계를 포함하는 것을 특징으로 하는 무접촉 상거래 트랜잭션을 관리하기 위한 방법.
청구항 3에 있어서,
상기 적어도 하나의 프로세서에 의해, 상기 제1 선택 상거래 명령이 성공적으로 프로세싱되었는지 여부를 결정하는 단계; 그리고
상기 적어도 하나의 프로세서에 의해, 상기 상거래 요소들을 상기 판매 시점 관리 시스템에 송신하는 단계를 더 포함하는 것을 특징으로 하는 무접촉 상거래 트랜잭션을 관리하기 위한 방법.
하나 이상의 프로세서로 하여금 이동 디바이스, 판독기 및 판매 시점 관리(POS; point of sale) 시스템 간의 지불 트랜잭션 외에도 무접촉 상거래 트랜잭션을 관리하게 하는 명령어들의 시퀀스들(sequences)을 저장한 비-일시적 컴퓨터-판독 가능한 매체에 있어서,
상기 명령어들의 시퀀스들은 상기 하나 이상의 프로세서들로 하여금:
트랜잭션의 개시와 연관하여 활성화 요청을 수신하게 하고;
이동 디바이스로부터 제1 탭(tap)을 식별하게 하고 -상기 제1 탭은 상기 이동 디바이스가 상기 판독기에 대한 근거리 내에 위치될 때 발생하며-;
상기 이동 디바이스로부터 상기 제1 탭을 식별하는 것에 응답하여, 제1 상거래 애플리케이션에 대응하는 선택 상거래 애플리케이션 식별자(AID)를 포함하는 제1 선택 상거래 명령을 상기 이동 디바이스에 송신하게 하고;
상기 이동 디바이스로부터 상기 제1 선택 상거래 명령에 기초한 제1 응답을 수신하게 하고;
머천트(merchant) 특정 정보를 포함하는 데이터 요청을 상기 이동 디바이스에 송신하게 하고;
상기 이동 디바이스로부터 상기 데이터 요청에 기초한 제2 응답을 수신하게 하고 -상기 제2 응답은 상기 머천트 특정 정보에 대응하는 상거래 요소들을 포함함 -;
상기 머천트 특정 정보에 대응하는 상기 상거래 요소들 중 하나 이상이 상기 트랜잭션에 적용된 후에 머천트 POS 시스템으로부터 트랜잭션-후(post-transaction) 데이터를 수신하게 하고;
상기 이동 디바이스로부터 제2 탭을 식별하게 하고 -상기 제2 탭은 상기 이동 디바이스가 상기 판독기에 대한 근거리 내에 위치될 때 발생하며-;
상기 이동 디바이스로부터의 상기 제2 탭을 식별하는 것에 응답하여, 상기 이동 디바이스로 지불 AID 요청을 송신하게 하고;
지불 애플리케이션에 대응하는 AID를 상기 이동 디바이스로부터 수신하게 하게 하고;
상기 지불 애플리케이션에 대응하는 상기 AID를 포함하는 선택 지불 명령을 상기 이동 디바이스에 송신하게 하고;
상기 이동 디바이스로부터 상기 지불 애플리케이션에 대응하는 파일 제어 정보(FCI; file control information)를 수신하게 하고;
상기 이동 디바이스로부터 지불 데이터를 수신하게 하고;
상기 제1 상거래 애플리케이션에 대응하는 상기 AID를 포함하는 제2 선택 상거래 명령을 상기 이동 디바이스에 송신하게 하고;
상기 제2 선택 상거래 명령에 기초하여 제3 응답을 상기 이동 디바이스로부터 수신하게 하고;
상기 이동 디바이스에 상기 트랜잭션-후 데이터를 송신하게 하고;
상기 이동 디바이스로부터 상기 트랜잭션-후 데이터에 기초하여 제4 응답을 수신하게 하고;
상기 제1 선택 상거래 명령, 상기 선택 지불 명령, 및 상기 제2 선택 상거래 명령이 성공적으로 프로세싱되었는지 여부를 결정하게 하고;
상기 지불 데이터를 상기 POS 시스템에 송신하게 하는 것을 특징으로 하는 비-일시적 컴퓨터-판독 가능한 매체.
청구항 5에 있어서,
상기 명령어들의 시퀀스들은 추가로 상기 하나 이상의 프로세서들로 하여금:
상기 제1 선택 상거래 명령이 성공적으로 프로세싱되었는지 여부를 결정하게 하고; 그리고
상기 상거래 요소들을 상기 판매 시점 관리 시스템에 송신하게 하는 것을 특징으로 하는 비-일시적 컴퓨터-판독 가능한 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제