KR20080014035A

KR20080014035A - 교통 시스템에서 비접촉식 지불 카드를 사용하는 방법 및시스템

Info

Publication number: KR20080014035A
Application number: KR1020077029155A
Authority: KR
Inventors: 버트 에이. 빌헬름; 올리버 스틸리; 아담 글룩
Original assignee: 마스터카드 인터내셔날, 인코포레이티드
Priority date: 2005-05-16
Filing date: 2006-05-16
Publication date: 2008-02-13
Also published as: AU2006247449A1; US20080156873A1; CA2608707A1; RU2007146708A; WO2006124808A2; WO2006124808A3; EP1913545A2; EP1913545A4; JP2008541303A; RU2421812C2

Abstract

교통 시스템의 자동 요금 징수 솔루션은 상업적 지불 카드 산업에 의한 스마트 지불 카드(예컨대, 마스터카드의 PayPass 카드)의 사용을 이용한다. 상업적 카드 발급자와 은행에 의해 고객에게 발급된 스마트 지불 카드는, 비접촉식 지불 카드를 위한 ISO 14443 표준과 같은 공통 또는 공개 산업 표준에 따른다. 교통 서비스에 대한 액세스를 원하는 카드 소지자는, 교통 시스템 입구에 있는 RFID-가능 카드 리더기에 자신의 스마트 카드를 제시한다. 카드 소지자는, 자신의 스마트 카드가 "핫" 카드 리스트(즉, 분실된 카드, 도난당한 카드, 또는 연체된 카드)에 등재되어 있지 않다면, 신속한 액세스가 승인된다. 카드 트랜잭션 레코드를 준비해서, 카드 리더기로부터 교통 지불 플랫폼과 주고 받는다. 교통 지불 플랫폼은, 통상의 카드 지불 전자 네트워크에 의해 카드 트랜잭션의 인증, 청산 및 정산을 위한 카드 발급자 및 은행에 링크된다.

Description

교통 시스템에서 비접촉식 지불 카드를 사용하는 방법 및 시스템{METHOD AND SYSTEM FOR USING CONTACTLESS PAYMENT CARDS IN A TRANSIT SYSTEM}

본 발명은, 교통 시스템에서 비접촉식 지불 카드를 사용하는 방법 및 시스템에 관한 것이다.

관련 출원

본 출원은 2005년 5월 16일에 제출된 미국 가특허 출원 60/681,513호, 2005년 9월 16일에 제출된 미국 가특허 출원 60/717,626호의 우선권을 주장하며, 상기 문헌의 전체 내용이 인용에 의해 본 명세서의 일부로 된다.

스마트 카드 기술은 우리의 일상 생활에서 빠르게 보급되어가고 있다. 스마트 카드(smart card)는 마이크로프로세서 및 메모리 칩에 내장되는 카드이거나, 프로그램 고정식 로직(non-programmable logic)을 가진 메모리 칩이 있는 경우에는 이 메모리 칩에 내장되는 카드이다. 마이크로프로세서에 내장된 카드는, 카드에 있는 정보를 추가, 삭제 및 그외 다른 방식으로 처리할 수 있으며, 메모리 칩에 내장된 카드[예컨대, 선불 전화 카드(pre-paid phone cards)]는 미리 규정된 동작만을 수행할 수 있다. 스마트 카드는, 자기 스트라이프 카드(magnetic stripe cards)와 달리, 필요한 모든 기능과 정보를 카드에 담을 수 있다. 따라서, 스마트 카드는 트랜잭션(transaction)이 이루어질 때에 원격 데이터베이스에 액세스할 필요가 없다.

스마트 카드는, 본 기술분야에서는 일반적으로 "마이크로프로세서 카드" 또는 "칩 카드"라고 불리기도 하며, 통상적인 자기 스트라이프 카드보다, 메모리의 기억 용량이 더 크고 데이터의 보안이 더 확실하다. 스마트 카드는, 최대 8 킬로바이트의 RAM, 346 킬로바이트의 ROM, 256 킬로바이트의 프로그램가능(programmable) ROM, 및 16 비트 마이크로프로세서를 포함할 수 있다. 스마트 카드는, 직렬 인터페이스를 사용하여, 카드 리더기(card reader) 등의 외부 소스로부터 전원을 공급받는다. 프로세서는, 암호화(cryptography) 등의 애플리케이션을 위한 한정된 명령어 세트를 사용한다. 스마트 카드는, 다양한 애플리케이션에 사용하는데, 특히 큰 수(large numbers)의 조작을 필요로 하는 암호화를 내장하는 애플리케이션에 사용된다. 따라서, 스마트 카드는, 안전한 디지털 아이덴티티(secure digital identity)를 갖는 카드에 대한 메인 플랫폼(main platform)이 되어 왔다. 가장 일반적인 스마트 카드의 애플리케이션은 다음과 같다:

* 신용 카드

* 전자 화폐(electronic cash)

* 컴퓨터 보안 시스템

* 무선 통신(wireless communication)

* 로열티 시스템(loyalty systems) (예컨대, 비행 횟수 포인트)

* 뱅킹(banking)

* 위성 텔레비전(satellite TV)

* 정부 신분증명(government identification)

딜리버링 시큐리티(delivering security) - 인증된 카드 소지자에 의한 허가된 사용에 대해서만 액세스가 허용되는 것을 보장하는 것으로서, 스마트 카드의 기본적인 속성이다. 스마트 카드가 딜리버링 시큐리티에 효과적이라는 것은, 스마트 카드가, 특히 금융 서비스와 모바일 폰에 널리 채택되고 있는 이유, 스마트 카드의 성장이 폭발적인 이유, 그리고 스마트 카드의 사용이, 개인 신분증명 카드, 페이(pay) TV/엔터테인먼트에 대한 액세스, 헬스 케어 서비스(health care service) 및 운송(transportation) 등과 같은 다른 애플리케이션에 대해 급격하게 확장될 것으로 예상되는 이유로부터 알 수 있다.

기차, 도시 철도(메트로), 버스, 페리(ferry) 및 톨게이트(tolls)를 포함하는 운송 및 교통 시스템은 매일 수 백만명의 사람이 이용하고 있다. 현대의 대도시에서는, 비용 효율이 높고, 능률적이며, 신뢰성 있는 교통 체계(transit)가 필요하다. 스마트 카드는, 이러한 교통 환경에서 지폐와 동전을 사용하지 않을 수 있는 장점이 있다. 스마트 카드에 의한 지불(payment)은, 빠르고 신뢰성이 있을 뿐만 아니라, 장비 유지에 필요한 비용을 절감하는 데에도 도움이 된다. 전세계의 앞선 교통 시스템은 스마트 카드 기술에 기반을 둔 새로운 지불 메커니즘(payment mechanism)으로 옮겨가고 있다.

비접촉식(contactless) 스마트 카드 및 카드 리더기/단말기에 사용하기 위한 RFID 기술이 몇 가지 있다. 비접촉식 시스템의 기본적인 요소는 비접촉식 리더기 [즉, PCD(Proximity Coupling Device)]와 트랜스폰더(transponder)이다. 비접촉식 리더기는 전자 회로에 연결된 안테나이다. 트랜스폰더는, 유도성 안테나(inductive antenna)와, 이러한 안테나의 끝에 연결된 집적 회로를 포함하여 구성되어 있다. 리더기와 트랜스폰더를 조합하면 트랜스포머(transformer)로서 작용한다. 전자기장을 만드는 1차 코일(리더기 안테나)을 통해 교류 전류가 흐르고, 이에 의해 2차 코일(트랜스폰더 안테나)에 전류가 유도된다. 트랜스폰더는, 비접촉식 리더기(PCD)에 의해 전송된 전자기장[RF 전계(RF field)]을, 다이오드 정류기에 의해 직류(DC) 전압으로 변환한다. 이러한 DC 전압은 트랜스폰더의 내부 회로에 전원을 공급한다. 비접촉식 리더기의 안테나 및 트랜스폰더의 안테나의 구성과 튜닝에 의해, 하나의 디바이스에서 다른 디바이스에의 결합 효율(coupling efficiency)이 정해진다. 트랜스폰더는 비접촉식 지불 카드일 수 있다.

비접촉식 지불 카드 시스템이 실용화되고 상업적으로 허용되기 위해서, 비접촉식 지불 카드는, 모든 또는 대부분의 RFID-가능한 지불 단말기(RFID-enabled payment terminals)에서 상호 운용(interoperable)이 이루어져야 하는데, 이러한 카드와 단말기가 특정의 카드 공급자/발급자, 판매자 또는 단말기 제조업자의 독점인 기술적 특징을 가지고 있는 경우라도, 마찬가지로 상호 운용이 이루어져야 한다. 상호 운용성(interoperability)은 산업 전반에 사용할 수 있는 것이 바람직하다. 이를 달성하기 위해, 산업 표준 기구 및 그룹[예컨대, ISO(International Organization for Standards 및 IEC(International Electro Technical Committee)]은 비접촉식 스마트 카드 지불 기술의 구현을 위한 자발적인 산업 표준을 공식화해 왔다. ISO/IEC에 의해 규정되고 있는 이러한 산업 표준의 예들 중 3가지는, 각각 밀착형(Close Coupling), 근접형(Proximity) 및 근방형(Vicinity) 카드에 적용할 수 있는 ISO/IEC 10536 표준, ISO/IEC 14443 표준, ISO/IEC 15693 표준이다.

최근, 본 발명의 양수인인 마스터카드 인터내셔널 인코포레이티드[MasterCard International Incorporated: 이하 간단히 "마스터카드" (MasterCard)라고 함]는, 근접형(비접촉식) 지불 카드 기술의 구현을 위한, 독점적인 사양인 MasterCard PayPass^TM ISO/IEC 14443 Implementation Specification("PayPass")을 개발했다. 페이패스(PayPass)는, RFID-가능한 비접촉식 지불 플랫폼(RFID-enabled contactless payment platform)으로서, 사용자가 트랜잭션의 처리를 위해 특정의 리더기 앞에서 기기를 가볍게 대거나 흔드는 것이다. 페이패스(PayPass) 구현은, ISO 14443 표준에 따라 이루어지며, 본 발명의 원리를 나타내는 예를 제공한다. 예컨대, 2005년 7월 15일에 제출된 미국 특허 출원 제11/182,354호, 제11/182,357호, 제11/182,358호, 제11/182,356호, 제11/182,355호 및 제11/182,351호를 참조하라. 상기 문헌들은 인용에 의해 본 명세서에 포함된다. 양수인인 마스터카드는, 신용(credit), 직불(debit) 및 선불(prepaid) 지불 솔루션(payment solutions)을 포함하는 마스터카드 페밀리의 브랜드를 사용한, 공개 지불 솔루션(open payment solution)을 제공하는 글로벌 리더이다. 또한, 마스터카드는, 특히 교통 수단의 필요에 따른 선불 방식의 자체 브랜드(Prepaid Private Label) 지불 프로그램을 가능하게 하는 좋은 위치에 있다. 페이패스 구현 은, 통상적으로 적은 금액(예컨대, 미국 달러로 50달러 미만)으로, 신속한 서비스 및 높은 처리율을 필요로 하는 상인(merchants)의 요구를 만족시키는 것을 목표로 한다. 예컨대, 2005년 1월자의 MasterCard Payment Card Industry Data Security Standard (https://sdp.mastercardintl.com/pdf/pcd_manual.pdf)와, 2005년 8월 개정된 2005년 7월자의 MasterCard's Security Rules and Procedures (www.mastercardmerchant.com/acquirers/index.html)를 참조하기 바라며, 이들 공개 문헌은 그 전체 내용이 본 명세서에 인용에 의해 포함되는 것으로 한다. 또한, 페이패스(PayPass) 특징에 대한 다른 공개 문헌은, https://mbe2stl101.mastercard.net/hsm2stl101/public/login/ebusiness/mobile_commerce/paypass/documentation/index.jsp를 참고하면 된다.

이하, 교통 시스템 환경에서 사용되는 지불 솔루션(payment solutions)을 향상시키는 것에 대하여 고려한다. 바람직한 지불 솔루션은 "공개"(open) 솔루션, 즉 사용자가, 교통 시스템 이상으로 광범위하게 상업적으로 사용되어 온 교통 시스템/스마트 카드에 특정된, 비접촉식 액세스 카드를 사용하여 교통 시스템에 액세스할 수 있는 솔루션이다.

본 발명은 교통 시스템에 사용하기 위한 자동 운임 징수(AFC: automatic fare collection) 시스템 및 방법을 제공한다.

예컨대, AFC 시스템은, 상업적 카드 발급자에 의해 발급된 RFID-가능한 비접촉식 지불 카드의 사용에 기초한다. RFID-가능한 비접촉식 지불 카드는 비접촉식 지불 카드에 대한 공개 산업 표준(open industry standards)(예컨대, ISO 14443 표준)에 따른다. AFC 시스템은, 교통 시스템 지불 구역(transit system pay areas) 및 교통 지불 플랫폼(transit payment platform)의 입구에 배치된 RFID-가능한 카드 리더기를 포함한다. RFID-가능한 카드 리더기는 단말기 또는 스테이션 컨트롤러(terminal or station controller)와 인터페이스로 연결될 수 있다. AFC 시스템은 또한, 카드로 지불이 행해지는 산업 분야(payment-by-card industry)에 공통인 전자 네트워크(electronic networks)를 통해 트랜잭션 지불 인증(authorization), 청산(clearing) 및 정산(settlement)을 수행하도록 이루어진 교통 지불 플랫폼 또는 애플리케이션을 포함한다.

교통 시스템의 지불에 의해 개폐되는 게이트(gated pay areas)에 대한 액세스를 얻고자 하는 고객은, 자신의 비접촉식 지불 카드(예컨대, MasterCard의 PayPass 카드)를, 운임 지불을 위한 RFID-가능한 카드 리더기에 의해 판독되도록 제시한다. 카드 리더기/단말기 컨트롤러는, 판독한 비접촉식 지불 카드 데이터를 핫 카드(hot card)(즉, 분실된, 도난당한, 기한 만료된, 지불 연체된 것으로 보고된 카드)의 리스트와 비교해서, 교통 시스템의 지불에 의해 개폐되는 게이트에 대한 고객의 액세스를 승인 또는 거절한다. 1회 운임 탑승(single fare rides)의 경우, 트랜잭션 지불(transaction payment)은, 카드 발급자가 가진 고객의 카드 계정(예컨대, 신용 계정 또는 직불 계정)에 청구된다.

교통 지불 플랫폼은 또한, 고객이 자신의 비접촉식 지불 카드에 링크된 사전 적립(pre-funded) 교통 계정을 등록 또는 설정할 수 있도록 구성될 수 있다. 사전 적립 계정은, 예컨대 정액권 요금(pay-per-ride ticket fare), 최대 탑승 횟수 티켓 요금(maximum number of rides per ticket fare), 및 무제한 탑승권 요금(unlimited ride ticket fare)에 대응하는, 통화 잔고(currency balances)(예컨대, 금액), 탑승 자격 밸런스(ride entitlement balances)(예컨대, 탑승 횟수), 또는 시간 밸런스(time balances)를 가질 수 있다. 이러한 비접촉식 지불 카드에 의한 운임 트랜잭션(fare transactions)의 경우, 교통 지불 플랫폼은, 트랜잭션 중인 고객의 비접촉식 지불 카드와 연관된 사전 적립 교통 계정에 대해, 트랜잭션 지불을 정산(settle)한다.

본 발명의 다른 특징이나 장점에 대해서는, 첨부 도면과 이하의 상세한 설명으로부터 더 명백하게 될 것이다.

도 1은, 본 발명의 원리에 따른, 교통 시스템의 전자 지불 솔루션의 논리적 구성요소를 나타내는 블록도이다.

도 2는 본 발명의 원리에 따른, 운임 지불을 위한 페이패스(PayPass) 카드의 사용에 기초하는 교통 시스템의 자동 운임 징수 구조의 예를 나타내는 블록도이다.

도 3은, 본 발명의 원리에 따른, 자동 운임 징수를 위한 교통 시스템 인프라구조와 인터페이스로 연결된 스마트 카드 지불 플랫폼의 구성요소를 개략적으로 나타내는 도면이다.

도 4는, 본 발명의 원리에 따른, 교통 시스템에서의 사용을 위한 고객의 스마트 카드를 등록하기 위한 과정에 포함하는 단계의 예를 나타내는 흐름도이다.

도 5는, 본 발명의 원리에 따른, 운임 지불을 위한 교통 시스템의 카드 리더기에 고객이 스마트 카드를 제시한 경우의 운임 트랜잭션을 처리하기 위한 과정에 포함되는 단계의 예를 나타내는 흐름도이다.

본 발명은, 교통 시스템의 자동 운임 징수(AFC: automatic fare collection) 솔루션을 제공한다. 스마트 카드의 사용을 기반으로 하는 이러한 AFC 솔루션에 의하면, 자동 운임 징수 시스템 및 방법이 교통 시스템 내에 구현될 수 있다. 이러한 자동 운임 징수 시스템 및 방법은, 예컨대 통화 취급 비용, 티켓 판매기, 개찰구 유지 비용, 운임 매체 조달 비용(예컨대, 플라스틱/종이 운임 카드), 및 설치된 티켓 부스 중 운영중인 부스의 수를 감소시킴으로써, 운영 비용을 줄이는 장점을 가질 수 있다. AFC 솔루션은, 비접촉식 지불 기기의 공통 또는 공개 산업 표준(예컨대, ISO 14443 표준)에 따르는 스마트 카드(예컨대, 마스터카드의 PayPass)를 기반으로 한다.

도 1은, 교통 시스템의 전자 지불 솔루션(electronic payment solution)(100)의 논리적 및 구조적 구성 요소를 나타내는 블록도이다. 도 1의 전자 지불 솔루션(100)은, 마스터카드의 페이패스(PayPass) 구현에 기초한다. 이러한 전자 지불 솔루션(100)에서, 카드 발급자(card issuer)(120)는 페이패스(PayPass) 카드(110)를 카드 소유자에게 발급한다. 고객은, 교통 시스템의 지불에 의해 개폐되는 게이트(gated pay areas)에 들어가기 위해서, 예컨대 개찰구(132)(예컨대, 지하철 개찰구 또는 게이트)에서 운임을 지불하기 위한 페이패 스(PayPass) 카드를 제시할 수 있다. 개찰구(132)에는, 자동 운임 징수(AFC)를 위해 고객에 의해 제시되는 페이패스(PayPass) 카드를 전자적으로 판독하기 위한 RFID-가능한 카드 리더기(130)가 제공된다. 카드 리더기(130)는, 선택적인 단말기 컨트롤러(150)와 페이패스 교통 지불 플랫폼(PayPass Transit Payment Platform)(160)을 통해 교통 시스템의 지불 호스트(payment host)(140)에 전자적으로 링크되어 있다. 고객의 운임 지불은, 예컨대 소매 산업(retail industry)에서 페이패스(PayPass) 신용 카드 또는 직불 카드 지불 트랜잭션을 처리하는데 사용되는 현재의 카드 지불 방식과 유사하게, 전자적으로 처리될 수 있다. 이를 위하여, 카드 발급기(120) 및 그외 다른 엔티티(entities) 또는 조직(organization)에, 통상적인 카드 지불 전자 네트워크(payment-by-card electronic network)(190)를 통해 교통 에이전시 지불 호스트(Transit Agency Payment Host)(170)가 링크된다. 트랜잭션 지불 처리 단계(예컨대, 트랜잭션/지불 인증 요구, 승인, 및 정산 단계들)는, 카드 지불 전자 네트워크(190)에 의해서도 링크된 매입자(acquirer)(170) 및 페이패스(PayPass) 카드 회사(180)(즉, 마스터카드) 등의 통상적인 전자 지불 인프라구조 엔티티를 포함할 수 있다.

전자 지불 솔루션(100)의 구현에 있어서, 고객은 자신의 페이패스(PayPass) 카드에 링크된 사전 적립식 교통 계정을 설정 및 등록할 수 있다. 실제로, 고객은, 교통 시스템의 지불에 의해 개폐되는 게이트(gated pay areas)에 들어가기 위해, 교통 개찰구(transit turnstile)(132)에 설치된 카드 리더기(130)에 자신의 페이패스(PayPass) 카드(110)를 제시 또는 "가볍게 갖다 댄다"(tap). 카드 내의 부 호화된 데이터가 판독되어, 단말기 컨트롤러(150)로 전송된다. 단말기 컨트롤러(150)는, 카드에 대해 허용 또는 거절로 응답한다. 이에 따라, 고객은 개찰구를 통과할 액세스가 승인되거나 거부된다. 단말기 컨트롤러(150) 소프트웨어는 페이패스 교통 지불 플랫폼(PayPass Transit Payment Platform)(160)에 대해 트랜잭션 데이터 기록을 주고 받는다. 페이패스 교통 지불 플랫폼(160)은, 카드 단말기 소프트웨어의 계속된 유지뿐만 아니라 트랜잭션에 대한 필요한 인증 및 일괄 정산(batch settlement) 처리 기능을 제공한다.

페이패스(PayPass) 구현의 선택은 예시에 불과하며, 본 발명의 원리는 다른 일반적인 산업이나 전용 표준(proprietary standards)하에서 운영되는 전자 지불 디바이스 및 시스템에 더 일반적으로 적용될 수 있다는 것을 알 수 있다. 다른 전자 지불 디바이스 및 시스템은, American Express ExpressPay and Visa Wave 등과 같은 비접촉식 카드에 기반을 둘 수 있다. 페이패스(PayPass) 구현은, 교통 환경에 공개 지불 방식(open payments)을 초래했으며, 스마트 카드에 기반을 둔 지불 솔루션에 대한 채택을 계획하고 있거나 이미 채택을 시작한 교통 엔티티(transit entity)에 새로운 옵션을 제공한다. 페이패스(PayPass) 구현은, 공개 지불 솔루션을 사용하여 교통 엔티티와 이들의 고객 모두에게 이익을 주도록 구성될 수 있는 장점을 가진다.

또한, 본 발명의 전자 지불 솔루션의 애플리케이션은, 지하철 교통 시스템, 즉 뉴욕주의 대도시 교통 기관("MTA": Metropolitan Transportation Authority)에 의해 운영되고 있는 뉴욕 도시 교통("NY Transit")을 참조하여 설명하고 있다. MTA/NY 교통의 선택은 예시에 불과하며, 본 발명의 전자 지불 솔루션은, 임의의 다른 교통 시스템[예컨대, 스탠튼 아일랜드 철도(Staten Island Railway, 롱아일랜드 철도(Long Island Rail Road), 롱아일랜드 버스(Long Island Bus), 메트로 노스 철도(Metro-North Railroad), 및 브리지스 앤 터널스(Bridges & Tunnels)]에서도 사용될 수 있다.

전자 지불 솔루션(100)은, 여러 개의 교통 시스템(예컨대, 지하철, 버스, 철도 등)에 걸쳐 통합된 AFC 애플리케이션용으로 설계될 수 있으며, AFC를 위한 MTA의 브리지스 앤 터널스 운영에 채택된, E-ZPass 솔루션 등과 같은 다른 전자 지불 솔루션과도 통합될 수 있다.

도 1을 다시 참조하면, 전자 지불 솔루션(100)은, 임의의 적적한 수의 여러 가지 카드 타입과 카드 분포 모델(card distribution model)에서도 동작이 가능할 수 있다. 이러한 여러 가지 카드 타입의 교통 기능성(transit functionality)이, 교통 지불 플랫폼(Transit Payment Platform)(140)의 적절한 설계에 의해 가능하게 된다.

적절한 수의 카드 타입과 카드 분포 모델은, 스마트 카드의 사용을, 교통 시스템의 승객 수의 비율을 넓히는 것이 경제적 의미가 있도록 하는 데까지 확장시키는 관점에서 선택될 수 있다. 선택된 카드 타입에는, 예컨대 1회 탑승(single-ride)이며 시간 기반(time based)(무제한 탑승)의 동작 모드를 지원하는 카드, 및/또는 정액 탑승(pay-per-ride) 동작 모드를 지원하는 금액 기반의 카드(value based cards)가 포함될 수 있다.

가능한 카드 분포 모델의 예는 다음과 같다:

(1) 은행 발급 카드[예컨대, 마스터카드의 페이패스(MasterCard PayPass)]

은행은 카드 소지자가 범용으로 사용할 수 있는 페이패스(PayPass) 가능한 표준 신용 카드 또는 직불 카드를 상인에게 발급할 수 있다. 이러한 페이패스(PayPass) 카드는, MTA 시스템을 이용한 여행에도 사용될 수 있으며, 그 지역에 잘 가지 않는 여행자나 방문자뿐만 아니라 정기 통근자의 필요도 만족시킬 수 있다. 페이패스(PayPass) 카드는, MTA 환경 내에서만 사용될 수 있는(E-ZPass와 유사한 방식으로), 정액 방식의 사전 적립 교통 계정(pay-per-ride pre-funded transit account)을 설정하기 위해 교통 시스템에 등록될 수 있다. 등록된 페이패스(PayPass) 카드는, 금액 기반의(정액 탑승 방식) 상품 또는 시간 기반의(무제한 탑승 방식) 상품에 대한 정규의 메트로카드(MetroCard)의 기능을 수행할 수 있다. 등록되지 않은 페이패스(PayPass) 카드는, MTA 내에서, 1달에 몇 번 안 되는 탑승을 위해 게이트에서 지불하는 데에 사용될 수 있다.

(2) MTA/은행 공동 브랜드 카드(예컨대, MTA/MasterCard PayPass의 공동 브랜드인 MetroCard)

공동 브랜드 카드는 "통근자"(commuter) 카드, "도시"(city) 카드 또는 "트래블"(travel) 카드로서 은행에 의해 판매 및 발급될 수 있다. MTA 시스템 내에서, 공동 브랜드 카드는, 금액 기반의(정액 방식) 상품 또는 시간 기반의(무제한 탑승 방식) 상품에 대한 자기 스트라이프 기술에 기초한 정규의 메트로카드(MetroCard) 티켓의 기능과 유사한 기능을 갖는다. 이 카드는 MTA 환경 외에서 는 일반적인 은행 지불 카드로서 사용될 것이다. 모든 카드 소지자는, 등록시에 카드 소지자의 선택에 따라 금액 기반(정액 방식)으로 할 것인지 시간 기반(무제한 탑승 방식)으로 할 것인지에 따라, 이동을 위한 교통 시스템에 자동으로 등록된다.

(3) 페이패스(PayPass)에 의해 촉진된 MTA 자체 브랜드 카드:

MTA 자체 브랜드 카드(MTA private label card)는, 시스템의 정기적인 사용자에 해당하지만 자신의 트래블 카드(travel cards)를 은행 지불 카드에 통합하길 원하지 않는 탑승객을 대상으로 할 수 있다. MTA와 그 대리 판매업자들은 발급 파트너(issuing partner)를 통해 이러한 자체 브랜드 카드를 배포할 수 있다. 이 카드 상품은 금액 기반(정액 탑승 방식)의 상품 또는 시간 기반(무제한 탑승 방식)의 상품에 대한 정규의 메트로카드(MetroCard)의 기능과 유사한 기능을 갖는다.

MTA 자체 브랜드 카드는, MTA 환경 내에서만 사용될 수 있는 전형적인 선불 카드(prepaid card)이다. MTA 자체 브랜드 카드는, 은행 고객들 및/또는 트래블(travel)을 위한 개별의 지불 카드를 선호하는 사람들에게 적합한 것일 수 있다. 고객들은, 카드를 얻기 위해 요금을 지불하거나 및/또는 적립(deposit)할 수 있다. 모든 카드 소지자는, 금액 기반(정액 탑승 방식) 또는 시간 기반(무제한 탑승 방식)으로, 트래블을 위한 교통 지불 플랫폼(Transit Payment Platform)에 자동으로 등록될 수 있다.

실제로, 마스터카드(MasterCard)와 그 회원인 은행은, 미국 전역에서 신속한 트랜잭션을 위한 RFID-가능한 페이패스(PayPass) 개념을 진행시키게 될 것이다. 뉴욕시 외의 다른 곳에서 채택이 됨에 따라, 한 구역에서 이용가능한 교통 기 능(transit capabilities)을 다른 곳과 링크시키기 시작하는 것이 가능하게 될 수 있다. 처음에는, 이러한 것이 지역에 기초해서 이루어질 수 있지만, 전역으로 확대될 가능성이 있다. 따라서, 미국의 다른 곳에서 온 방문자도, 기존의 페이패스(PayPass) 카드를 사용해서 MTA 시스템을 사용할 수 있을 것이다. 이것은 MTA에 대한 비용을 절감할 것이며, 또한 탑승객을 위한 시스템의 전반적인 효용성을 향상시킬 것이다. MTA가 페이패스(PayPass) 솔루션을 채택하면, 탑승객은 자신의 마스터카드 페이패스(MasterCard PayPass) 카드를 사용하여 올버니(Albany)에서 뉴욕시로 이동할 수 있게 될 것이다.

마스터카드의 페이패스(PayPass)에 기초한 전자 지불 솔루션(100)의 구현 예는, 교통 시스템에 의해 사용되는 기존의 요금 구조 및 카드나 티켓의 종류와 일치하도록 또는 호환가능하도록 구성될 수 있다. 참고자료(appendix) A는 MTA/NY 교통에 대한 요금 구조를 보여준다. 또한 참고자료 B는, 앞서 설명한 3가지 카드 종류의 각각에 의해 지원되는 교통 요금 구조 특징의 비교를 표의 형식으로 나타낸 것이다.

전자 지불 솔루션(100)은, 많은 AFC 구조 또는 체계를 지원하도록 구성될 수 있다. AFC 구조의 예로서, "호스트 플러스 디스트리뷰티드 네거티브 파일"(Host plus Distributed Negative file)은 표준 페이패스(PayPass) 카드의 사용에 기초하고 있다. 이러한 구조에서는, 특별한 교통 애플리케이션을 지불 카드에 로딩할 필요가 없다. 고객은 요금 징수를 위한 개찰구(130) 또는 리더기(132)에 표준 페이패스(PayPass) 카드(110)를 제시한다. 개찰구(130)는, 카드 데이터[예컨대, 개인 계정 번호, 유효 기한(expiry date), 카드 유효성 검사 코드(card validation code)]를 확인하고, 카드가 네거티브 파일 또는 핫 리스트(hot list)에 등재되어 있는지 여부를 검사한다. 카드가 네거티브 파일에 등재되어 있다면, 개찰구(130)/단말기(150)는, 교통 시스템의 지불에 의해 개폐되는 게이트(gated pay areas)에 대한 고객의 액세스를 거부한다. 카드가 네거티브 파일에 등재되어 있지 않다면, 개찰구(130)/단말기(150)는, 교통 시스템의 지불에 의해 개폐되는 게이트(gated pay areas)에 대한 고객의 액세스를 허용하도록 게이트를 동작시킨다. 개찰구(130)/단말기(150)는, 1회 탑승(single-ride) 트랜잭션, 정액 탑승(pay-per-ride) 트랜잭션 및 무제한 탑승(unlimited ride) 트랜잭션을 처리하도록 구성될 수 있는, 교통 지불 플랫폼(160)에, 카드 사용과 관련된 미처리 트랜잭션(raw transaction) 데이터 기록을, 동시에 또는 나중에 제공한다. 교통 지불 플랫폼(160)은, 교통 시스템(예컨대, MTA)으로부터 미처리 트랜잭션을 수신하고, 등록되어 있는 고객 계정에 대해 수신한 트랜잭션을 처리한다. 교통 지불 플랫폼 호스트(140)는, 적절한 시기에, 1회 탑승의 트랜잭션 데이터를 추가의 처리를 위해 매입자(acquirer)(170)에 제공할 수 있다. 교통 지불 플랫폼 호스트(140)는, 예컨대 단말기 컨트롤러(150)를 통해 개찰구(130)에 분배되는 네거티브 파일을 생성해서 유지한다.

다른 AFC 구조의 예로서, "호스트 플러스 디스트리뷰티드 인타이틀먼트"(Host plus Distributed Entitlements)는, 표준 페이패스(PayPass) 카드의 사용에 기초한다. 이 구조에서, 교통 지불 플랫폼 호스트(140)는, 자격에 대한 포지티 브 파일(positive file of entitlements)을 교통 시스템의 개찰구(130)에 분배한다. 자격(entitlements)은, 유효한 무제한 탑승 카드(valid unlimited ride card), 및 포지티브한 사전 적립식 잔고(positive pre-funded balance)를 갖는 유효한 금액 기반의 카드의 리스트로서 표시될 수 있다. 고객이 요금 징수를 위한 개찰구(130)/리더기(132)에 표준 페이패스(PayPass) 카드(110)를 제시하면, 개찰구(130)는, 카드 데이터의 유효성을 확인하고, 카드가 자격 파일(entitlement file)에 기록되어 있는지 여부를 검사한다. 카드가 자격 파일에 기록되어 있다면, 개찰구(130)는, 교통 시스템의 지불에 의해 개폐되는 게이트(gated pay areas)에 대한 고객의 액세스를 허용하도록 게이트를 작동시킨다. 카드가 자격 파일에 기록되어 있지 않다면, 개찰구(130)는, 교통 시스템의 지불에 의해 개폐되는 게이트(gated pay areas)에 대한 고객의 액세스를 거절한다. 개찰구(130)는, 카드와 관련된 미처리 트랜잭션 데이터 기록을 교통 지불 플랫폼 호스트(140)에, 동시에 또는 나중에 제공할 수 있다. 교통 지불 플랫폼 호스트(140)는, 트랜잭션을 처리하고, 개찰구(130)에 다시 분배하기 위한 자격 파일 및 잔고를 갱신한다.

호스트 플러스 디스트리뷰티드 인타이틀먼트(Host plus Distributed Entitlements) 구조는 호스트 플러스 네거티브 파일 구조에서 가능한 미납 탑승(unpaid ride) 상황을 감소시킬 수 있는 장점이 있다. 그러나, 호스트 플러스 디스트리뷰티드 인타이틀먼트(Host plus Distributed Entitlements) 구조에서 사용되는 자격 파일은 용량이 크게 될 수 있다. 용량이 큰 자격 파일은, 호스트 플러스 네거티브 파일 구조에서 사용된 더 작은 용량의 네거티브 파일에 필요한 메모리 에 비해, 개찰구(130)/단말기 컨트롤러(150)에 추가의 메모리를 필요로 할 것이다.

호스트 플러스 네거티브 파일 구조와 마찬가지로, 호스트 플러스 디스트리뷰티드 인타이틀먼트 구조는 표준 페이패스(PayPass) 카드를 사용한다. 카드에 로딩해야 하는 특별한 교통 애플리케이션이 필요하지 않다.

또 다른 예시적인 구조로서, "페이패스 카드에 대한 호스트 플러스 스마트 티켓팅 애플리케이션"(Host plus Smart Ticketing Application on PayPass card)은, 특별한 교통 애플리케이션으로 강화된 표준 페이패스(PayPass) 카드를 사용한다. 이 특별한 교통 애플리케이션은, 실시간의 탑승객 행위(real-time rider activity)를 기록하고, 숨겨진 사전 적립된 잔고(shadow pre-funded balance)를 기록한다. 카드의 사전 적립된 잔고/자격은, 고객에 의해, 예컨대 MTA 페이패스(PayPass) 가능한 판매기에서, 갱신될 수 있다. 이러한 구조에서, 개찰구(130)/리더기(132)는, 카드에 저장된 탑승객의 행위 기록을 판독 및 갱신하도록 구성된다. 탑승객 행위의 기록은, 미납 탑승과 무제한 탑승 티켓의 남용(abuse)을 방지하는데 사용될 수 있다. 고객이 요금 징수를 위한 개찰구(130)/리더기(132)에 표준 페이패스(PayPass) 카드(110)를 제시한 경우, 개찰구(130)는 카드 데이터의 유효성을 확인하고, 카드가 네거티브 파일 또는 자격 파일에 등재되어 있는지 여부를 검사한다. 또한, 앞서 설명한 2개의 AFC 구조에서와 유사한 방식으로, 자동 요금 징수 트랜잭션 처리가 이루어질 수 있다.

도 2는, 호스트 플러스 디스트리뷰티드 네거티브 파일 AFC 구조를 일반 대중 교통 시스템에서 구현한 예에 해당하는 AFC 솔루션(200)을 나타낸다. 이러한 솔루 션의 구조적인 요소에는, 페이패스(PayPass) 발급자(290) 등의 엔티티와, 표준 페이패스(PayPass) 카드/디바이스(210), 게이트 리더(220), 티켓 판매기(230), 버스 요금 박스(240), 스테이션 컨트롤러(250), 교통 시스템 호스트(260), 교통 지불 플랫폼(270), 페이패스(PayPass) 카드 발급자(290), 리파워 호스트(rePower Host)(280), 및 전자 지불 네트워크[마스터카드 네트워크(MasterCard Network)(292)]와 같은 소프트웨어 및 하드웨어 요소를 포함한다.

AFC 솔루션(200)에서, 페이패스(PayPass) 카드/디바이스(210)는 ISO 14443 스마트 카드 또는 마스터카드 페이패스(PayPass) 애플리케이션을 포함하는 다른 디바이스[예컨대, 키팝(key fob)]가 될 수 있다. 게이트 리더기(220)는 ISO 14443 카드 리더기 및 페이패스(PayPass) 단말기 애플리케이션과 함께 확대된 통상의 개찰구 또는 게이트가 될 수 있다. 마찬가지로, 버스 요금 박스(240)는, ISO 14443 카드 리더기 및 페이패스(PayPass) 단말기 애플리케이션과 함께 확대된 통상의 버스 요금 박스가 될 수 있다. 티켓 판매기(230)는 지하철 역에서 MTA에 의해 현재 채택되어진 것들과 유사한 통상적인 티켓 판매기가 될 수 있다. 스테이션 컨트롤러(250)는 페이패스(PayPass) 트랜잭션을 처리하고 네거티브 파일을 취급하도록 변경된 통상의 스테이션 컨트롤러가 될 수 있다. 교통 시스템 호스트(260)는 MTA에 의해 사용되는 기존의 시스템 호스트가 될 수 있다. 교통 요금 지불 트랜잭션은, 교통 시스템 호스트(260)와 트랜잭션 지불 플랫폼(270)을 통해 마스터카드 네트워크(292)까지 경로 설정될 수 있다. 마스터카드 네트워크(292)는 미국과 전세계에서의 마스터카드의 트랜잭션을 처리하고 이에 대한 경로를 설정하도록 현재 채택되 어 있다. 이와 다르게, 요금 지불 트랜잭션은 별도의 게이트웨이 호스트[예컨대, 네트워크 게이트웨이(Network Gateway)(296)]를 통해 경로가 설정될 수 있다. 네트워크 게이트웨이(296)를 요금 지불 트랜잭션에 대한 경로 설정을 위해 다르게 사용하면, MTA에 의해 사용되는 기존의 시스템 호스트에 대한 처리 부하 또는 영향을 최소로 할 수 있다.

마스터카드 네트워크(292)는, 교통 지불 플랫폼(270), 선택적인 리파워 호스트(280), 페이패스(PayPass) 발급자(290), 및 페이패스(PayPass) 판매자 PoS(294)를 링크시킨다. 페이패스(PayPass) 발급자(290)는 페이패스(PayPass) 신용 카드 또는 직불 카드의 통상적인 발급자(예컨대, 마스터카드 회원 은행)가 될 수 있다. 도 2에서, 페이패스(PayPass) 판매자 PoS(294)는 마스터카드의 페이패스(PayPass) 신용 카드 및 직불 카드의 거래 허용(merchant acceptance)을 위한(예컨대, 소매상의 상인-고객 판매를 수행하기 위한) MTA 외부의 판매 인프라구조의 지점을 나타낸다.

교통 지불 플랫폼(270)은, MTA/NY 교통 및 다른 교통 시스템(예컨대, 교통 시스템(298))을 위한 1회 탑승, 정액 탑승, 및 무제한 탑승 트랜잭션을 운영하도록 적절하게 구성된 호스트 시스템이 될 수 있다. 교통 지불 플랫폼(270)은, MTA 교통 시스템 호스트(260) 또는 다른 네트워크 게이트웨이(296)로부터 미처리 트랜잭션(raw rtansactions)을 수신하고, 수신한 미처리 트랜잭션을 등록된 카드 소지자 계정에 대해 처리한다. 교통 지불 플랫폼(270)은 1회 탑승 트랜잭션을 적당한 시기에 제3자(예컨대, 매입자)에게 제공할 수 있다. 또한, 교통 지불 플랫폼(270) 은, 스테이션 컨트롤러(250)에 분배하기 위한 MTA 교통 시스템 호스트(260)에 되돌려 주는 네거티브 파일을 생성 또는 유지한다.

선택적인 리파워 호스트(280)는, 금액 기반의 카드 계정 및 시간 기반(사전 적립식)의 카드 계정에, 자동으로 또는 요청에 따라, 재로딩(reload)하도록 구성된 것이면 어떠한 호스트 시스템이라도 될 수 있다. 리파워(rePower)는 금액을 사전 적립식 계정(pre-funded accounts)에 로딩하기 위해 마스터카드가 브랜드화한 것이다. 리파워 호스트는, 예컨대, 인터넷, 문자 메시지 또는 전화를 통해 재로딩 요청을 용이하게 하는 적절한 인터페이스를 가질 수 있다. 리파워 호스트(280)는 링크된 교통 지불 플랫폼(270)에 갱신된 재로딩 정보를 제공한다.

고객이 요금 지불을 위해 페이패스(PayPass) 카드/디바이스(210)를 제시하면, AFC 솔루션(200)은, 요금 타입(예컨대, 1회 탑승, 금액 기반의 정액 탑승, 또는 시간 기반)에 따라, AFC를 위한 예시적인 페이패스(PayPass) 교통 카드 처리 과정(300)을 사용할 수 있다. 게이트 리더기(220) 및/또는 교통 지불 플랫폼(270)에서 생기는 처리 단계 및 결과를 표 1에 나타낸다.

하기 표 1은 페이패스(PayPass) 교통 카드 처리 과정(300)이다.

표 1에 나타낸 바와 같이, 페이패스(PayPass) 교통 카드 처리 과정(300)은, 페이패스(PayPass) 카드의 사용에 대한 검사를 2개의 단계로 행하는 것을 포함한다. 먼저, 제시된 카드를 게이트(220)에서 네거티브 파일과 비교하는 검사를 행한다(단계 312). 다음으로, 제시된 카드가 교통 지불 플랫폼(320)에서 검사된다[지불 인증 단계(322a, 323a), 및 탑승 자격 검사 단계(324a)]. 어느 검사에서든 실패가 있으면, 카드는 네거티브 파일에 등재될 수 있다.

교통 지불 플랫폼 검사는 비동기적으로(즉, 카드를 제시한 시점보다 늦게) 이루어질 수 있다. 따라서, 나중의 교통 지불 플랫폼 검사가 실패하는 경우라도, 첫번째 "게이트" 검사를 통과한 카드를 가진 카드 소지자는 교통 시스템의 지불에 의해 개폐되는 게이트(gated pay areas)에 대한 액세스를 얻게 될 수 있다.

제시된 카드가 네거티브 파일에 존재하는지를 확인하는 것에 추가로, 게이트(220)에서 수행된 게이트 검사(단계 312)에는, 카드 데이터의 포맷이 정확한지와 카드의 유효 기한이 만료되지 않았는지에 대한 확인도 포함될 수 있다. 게이트 검사는 또한, 다른 확인, 예컨대, 벨로시티 프로파일링(velocity profiling)(즉, 제시된 카드가 동일한 교통 스테이션에서 같은 날에 고정된 횟수보다 많이 사용되지 않았는지)과 같은 확인을 포함할 수 있다.

마찬가지로, 교통 지불 플랫폼 검사는, 제시된 카드가 기한이 만료되지 않았는지와 분실 또는 도난당한 것으로 보고된 카드 리스트에 등재되어 있지 않은지에 대한 확인을 포함할 수 있다. 교통 서비스 센터에 분실 또는 도난당한 것으로 보고된 MTA 자체 브랜드 카드의 경우, 서비스 센터(service agent)는 분실 또는 도난당한 것으로 보고된 카드의 교통 지불 플랫폼 리스트를 갱신할 수 있다. 마스터카드 브랜드의 카드인 경우, 교통 지불 플랫폼(270)은, 마스터카드의 글로벌 분실/도난 카드 파일(MasterCard's global lost/stolen cards file)에 접근할 수 있으며, 이 파일을 제시된 카드가 분실 또는 도난당한 것으로 보고되지 않았다는 것을 확인하는데 사용할 수 있다.

교통 지불 플랫폼(270)은, 요금 방식 규칙(fare plan rules)[예컨대, 루트(routes) 또는 라인(lines) 사이에서의 환승(transfer)에 관련된 규칙]을 구현하기 위해, 트랜잭션 데이터 기록을 추가로 검사하도록 구성될 수 있다. 이러한 규칙을 구현하기 위한 적절한 시기에, 교통 지불 플랫폼(270)은, 추가적인 지불 트랜잭션을 생성할 수 있다. 요금 규칙을 구현하도록 설계된 검사는 요금 트랜잭션의 종류에 따라 달라질 수 있다. 예를 들어, 1회 탑승 트랜잭션의 경우, 추가의 검사에는, 1개월당 최대 탑승 횟수가 초과되지 않았는지(예컨대, 10번)와, 지불이 카드 발급자에 의해 인증되었는지에 대한 확인이 포함될 수 있다. 정액 방식의 탑승 트랜잭션(pay-per-ride transactions)의 경우, 추가의 검사에는, 카드 소지자의 사전 적립된 교통 계정 잔고가 탑승에 대한 결제에 충분한지에 대한 확인이 포함될 수 있다. 무제한 탑승 트랜잭션의 경우, 추가의 검사에는, 카드 소지자의 무제한 이동 기한이 만료되지 않았는지와 카드가 제한된 기간[예컨대, 자기 스트라이프 기술을 사용한, MTA 메트로카드(MetroCard)의 경우 일반적으로 18분] 내에 동일한 스테이션에서 1번 이상 제시되지 않았는지에 대한 확인이 포함될 수 있다.

AFC 솔루션(200)은, 카드 소지자가 부정한 방식으로(improperly) 시스템에 대한 액세스를 얻는 것을 방지하기 위해, 카드의 핫 리스트(hot list)(즉, 네거티브 파일)에 의존한다. 카드가 네거티브 파일에 등재되어 있다면, 교통 시스템의 지불에 의해 개폐되는 게이트는 열리지 않을 것이다. 실질적으로, 부정한 액세스를 방지하는 이러한 방법의 효과는, 네거티브 파일이 갱신되는 횟수와 교통 시스템 전체를 통해 분배된 횟수에 좌우된다. 갱신된 네거티브 파일은, 날마다 적당하게 분배될 수 있다. 그러나, 갱신/분배를 더 빈번하게 하면, 미납 요금 탑승자가 생기는 상황을 줄일 수 있을 것이다.

AFC 솔루션(200)은, 또한 적절한 시기에 네거티브 파일로부터 카드 리스트를 제거 또는 삭제하도록 구성된다. 예를 들어, 정액 탑승 방식의 카드가 로딩되거나 또는 무제한 탑승 방식의 카드가 갱신되면, 네거티브 파일에서의 이에 대응하는 엔트리가 제거된다. 갱신된 네거티브 파일은, 이 네거티브 파일의 다음 분배 이후에만 효력을 나타낼 수 있다. 매일 분배하는 스케줄의 경우, 이것은, 정액 탑승 방식/무제한 탑승 방식의 카드가 다음날에 대해서만 이동하는 것에 대해 유효하다는 것을 의미한다. 네거티브 파일을 더 빈번하게 갱신 및 분배하는 것이 바람직할 수 있다.

도 2는 사전 적립된 교통 계정에 금액을 로딩하기 위한 마스터카드의 브랜드화된 설비인 리파워 호스트(280)를 나타낸다. 카드 소지자는, 인터넷을 통해 또는 교통 계정 설정 과정의 일부로서, 일정한 형태로 채워 넣음으로써 리파워로 등록할 수 있다. 등록한 이후에, 카드 소지자는, 인터넷, 전화, 셀폰 무선 메시지, 이메일 또는 IVRU를 통해, 자신의 사전 적립된 교통 계정을 충전(top-up)할 수 있다. 리파워 설비는 또한 ATM, PoS 기기, 머신 및 가능하면 기존의 티켓 판매기(ticketing agents)까지 확장될 수 있다.

AFC 솔루션(200)은, 자동 충전 옵션(automatic top-up otion)을 카드 소지자에게 제공하도록 구성될 수 있다. 이러한 자동 충전 옵션은, 계정 잔고가 소정의 레벨 이하로 내려가면, 관련된 직불 카드 또는 신용 카드로부터 사전 적립된 교통 계정에 금액을 보충하는 것이다. 금액을 로딩하기 위한 트랜잭션에 있어서, 리파워 호스트(280)는, 먼저 미납 탑승에 대한 요금을 공제하거나, 또는 이와 달리 교통 계정에 대한 지정된 로드 금액(load amount)에 상환액(refunds)을 추가할 수 있다. 또한, 재로딩된(re-loaded) 카드와 관련된 네거티브 파일 엔트리가 삭제된다.

마찬가지로, 무제한 탑승 티켓이 판매 또는 갱신되면, 판매 금액에 미납 요금이 추가된다. 또한, 갱신된 무제한 탑승 티켓과 관련된 네거티브 파일 엔트리가 삭제된다.

AFC 솔루션(200)은 교통 시스템 동작의 다른 통상적인 특징에 영향을 줄 수 있다. 그러나, AFC 솔루션(200)은, 영향을 받은 특징을 향상시키거나 수용하도록 변경될 수 있다. 예를 들어, AFC 솔루션(200) 하에서, 교통 시스템 탑승객은 차내 기차 승무원이 검사할 수 있는 통상적인 종이 티켓을 가지지 않을 것이다. 만일 차내 검사가 필요하면, AFC 솔루션(200)은 차내 기차 승무원 또는 티켓 검사 요원에게 휴대형 페이패스(PayPass) 카드 리더기를 제공할 수 있다. 이 휴대형 페이패스 카드 리더기는 차내 탑승객이 제시한 페이패스 카드를 검사하는데 사용될 수 있다. 휴대형 페이패스 카드 리더기에는, 탑승객의 요금 자격 또는 지불이, 예컨대 교통 시스템 호스트에서 승인될 수 있도록 하는 이동 통신 기능이 제공될 수 있다.

AFC 솔루션(200)은 트랜잭션과 지불의 2가지 타입의 정산(settlement)을 포함할 수 있다. 그 중 첫 번째 타입의 정산은, 페이패스 발급자(290)에 의해 인증된 1회 탑승 트랜잭션에 관한 것이다. 이러한 트랜잭션에 대한 정산은, 제3자(예컨대, 도 1의 매입자)를 통해, 교통 지불 플랫폼에 대해 그리고 MTA에 대해 수행될 수 있다. 이와 달리, 1회 탑승 트랜잭션 정산은 트랜잭션 집계(transaction aggregation) 또는 사전 인증된(pre-authorized) 금액의 사용을 포함할 수 있다. 탑승객 또는 계정 소유자(account-holder)에 의해 몇 개의 1회 탑승 트랜잭션을 집계하는 트랜잭션 집계는, 효과적인 정산을 제공할 수 있다.

두 번째 타입의 정산은, 정액 탑승 방식 또는 무제한 탑승 방식의 페이패스 카드를 사용하여 이루어진 탑승용 트랜잭션에 관한 것이다. 이러한 타입의 정산은, 교통 지불 플랫폼(270)과 MTA 사이에서 직접 수행된다. 이를 위하여, 교통 지불 플랫폼(270)의 오퍼레이터와 MTA 사이에서, 적절한 상업적인 약속(commercial arrangement)이 설정될 수 있다.

이상 설명한 내용은 본 발명의 원리를 예시적으로 나타낼 뿐이며, 당업자라면 본 발명의 범위를 벗어남이 없이 다양한 변경이 가능하다는 것을 알 수 있을 것이다. 예를 들어, MTA/NY 교통 지하철에 사용되는 AFC 솔루션(200)은, MTA 버스 또는 다른 운송 모드로 용이하게 확장될 수 있다. 이러한 확장에 있어서, 버스 또는 다른 차량이나 접근 지점(points of access)에는, 기존의 요금 박스/티켓 확인 기기(ticket validator)(240)에 부착된 스마트 카드 리더기가 설치될 수 있다. 트랜잭션은, 장치 내에 저장되어 있다가, 버스가 기지(base)로 되돌아가면, 호스트 시스템에 다운로드될 것이다. 또한, 예를 들어, AFC 솔루션의 원리는, 페이패스 카드 구조에 대한 호스트 플러스 스마트 티켓팅 애플리케이션의 구현 및 호스트 플러스 디스트리뷰티드 인타이틀먼트 구조의 구현까지 용이하게 확장될 수 있다. 이에 대해서는, 간략화를 위해 본 명세서에서 더 이상 구체적으로 설명하지 않는다.

도 3은, MTA/NY 교통(Transit)에서 페이패스에 기초한 AFC 솔루션의 실시(demonstration)와 관련된, 페이패스 교통 지불 플랫폼(510)과 지하철 개찰구 인프라구조(520)의 필요한 기능을 나타낸다. 마찬가지로, 첨부자료 C(Appendix C)는 주요한 구성요소의 각각에 대한 기능 및 처리 단계를 나열하고 있다.

지하철 개찰구 인프라구조(Subway Turnstile Infrastructure)(520): 모든 페이패스 리더기(522) 및 단말기(524)의 하드웨어 및 소프트웨어는 공개된 마스터카드 페이패스 사양에 바람직하게 부합한다. 페이패스 리더기(522) 및 단말기(524)는 정보에 대한 인증되지 않은 액세스를 방지하기 위해, 정보를 안전하게(예컨대, 암호화된 형태로) 저장 및 전달하는 것이 바람직하다. 페이패스 리더기(522) 및 단말기(524)는, 통신 사고에 대비해서, 2주일치 분량의 정보를 저장 또는 기록해 놓을 수 있는 것이 바람직하다. 이러한 기록(예컨대, 에러 기록 및 트랜잭션 기록)이 꽉 차게 되면, 기록된 정보가 단말기(524)로부터 업로드될 때까지 데이터가 중복해서 기록되지는 않을 것이다. 페이패스 리더기(522) 및 단말기(524)는, 페이패스 교통 지불 플랫폼(510)과 통신을 행할 때에, 기기 상태 정보(예컨대, 기기가 정상적으로 기능하고 있는지에 대한 정보)를 제공하는 것이 바람직하다.

페이패스 교통 지불 플랫폼(510): 페이패스 교통 지불 플랫폼(510)은 개찰구 액세스를 위한 페이패스 트랜잭션만을 처리한다. 모든 기존의 개찰구 액세스 레거시 기능(turnstile access legacy functions)은 기존의 교통 판매 인프라구조(transit agency infrastructure)[예컨대, 스테이션 컨트롤러(504), 티켓 판매기(506)]를 계속해서 이용할 수 있다.

페이패스 교통 지불 플랫폼(510)은, 페이패스 트랜잭션과 관련된 활동의 관리를 위한 애플리케이션을 갖는다. 이러한 애플리케이션에는, 고객 계정 관리(602, 604), 계정 유지(512), 지불 처리(514), 파일 관리(516), 및 네트워크 관리(158) 애플리케이션이 포함될 수 있다. 페이패스 교통 지불 플랫폼(510)은, 페이패스 트랜잭션의 처리를 지원하면서, MTA 시스템과 상호작용할 수 있다. 페이패스 교통 지불 플랫폼(510)은, 매일의 활동(daily activity)[예컨대, 인증 취득(authorizations obtained), 적립을 위한 트랜잭션 정산(transactions settled for funding), 개찰구 활동(turnstile activity) 등]을 MTA에 보고하기 위한 적절한 관리 보고 기능을 가질 수 있다.

페이패스 교통 지불 플랫폼(510)은, 사전 적립된 고객 계정과 사후 적립된 고객 계정을 각각 관리하기 위한 고객 계정 관리 애플리케이션(602, 604)을 갖는다. 2가지 타입의 계정에 대한 트랜잭션은 상이한 지불 처리 과정(즉, 트랜잭션 인증 및 청산 과정)을 갖는다.

페이패스 교통 지불 플랫폼(510)은, 개찰구를 통한 입장(admittance)을 위한 사전 적립 계정에 페이패스 카드 번호를 링크시키는 기능[사전 등록(pre-registration)]을 갖는 것이 바람직하다. 적립 옵션(funding options)에는, 자동 로딩, 카드 소지자가 요청한 웹사이트 재로딩, SMS 등이 포함될 수 있다. 또한, 페이패스 교통 지불 플랫폼(510)은, 카드 소지자가 자신들의 사전 적립 계정을 설정 및 유지하기 위한 메커니즘을 갖는 것이 바람직하다. 페이패스 교통 지불 플랫폼(510)은, 카드 소지자가 집계된 사후 적립 트랜잭션 및/또는 사전 적립 트랜잭션과 관련된 탑승 이력(ride history), 및 사전 적립 계정 "충전"(top-up) 활동과 관련된 트랜잭션 이력을 획득할 수 있도록 하는 웹 기반의 고객 인터페이스를 제공할 수 있다. 웹 기반의 고객 인터페이스(web based customer interface)는 또한 카드 소지자로 하여금 사전 적립 계정을 등재(enroll) 및 미등재(un-enroll)할 수 있도록 해준다.

도 4는, 발급 은행에 의해 페이패스 카드가 메일로 발송되는 고객이 교통 시스템에서의 사용을 위해 페이패스 카드를 사전 등록하고, 페이패스 카드를 사전 적립 교통 계정에 링크시킬 수 있는 프로세스(400)를 나타낸다. 프로세스(400)의 단계 41에서, 은행은 페이패스 카드를 카드 소지자(cardholder)에게 메일로 발송한다. 단계 42에서, 카드 소지자는 카드를 교통 시스템에 등록할지를 선택한다. 카드 소지자가 카드를 등록하지 않기로 한다면, 카드 소지자는 교통 시스템에 대해 사후 지불 요금 트랜잭션용의 카드를 계속해서 사용할 수 있다. 카드 소지자가 카드를 등록하기로 한다면, 페이패스 교통 지불 플랫폼(510)은, 단계 43에서, 자동 신용 서비스(ACS: Automated Credit Service)에서 카드와 관련된 사전 적립 계정을 설정한다. 카드 소지자는 또한, 단계 44에서, 사전 적립 계정을 위한 자동 재로딩 특징(automatic reload features)을 동작시키도록 선택할 수 있다. 카드 소지자가 자동 재로딩을 동작시키는 것으로 선택하지 않는다면, 사전 적립 계정에 1회 금액(one-time value)이 할당된다(단계 46). 이와 반대로, 카드 소지자가 자동 재로딩 특징을 동작시키기로 선택한다면, 단계 45에서, 자동 재로딩에 대해 계정 로딩 제한이 설정된다. 단계 45는, 카드 소지자의 자격 여부(qualifications)를 검사하기 위해 통상의 주소 확인 서비스(AVS: address verification service)를 이용할 수 있다. 카드 발급 은행에는, 3번 연속해서 등록을 시도하면 AVS 검사가 실패하는 것이라고 통보될 수 있다. 그러나, 검사가 실패한 카드는 핫 리스트에 자동으로 등재되지 않을 수 있다. 카드 발급 은행은, 필요한 정보를 가질 것이며, 핫 리스트에 카드가 등재되는지 또는 AVS 검사 파라미터를 리셋할 것인지를 선택할 수 있다.

카드를 사전 등록하면, 페이패스 교통 지불 플랫폼(510)은, 카드 소지자로 하여금 교통 에이전시가 규정한 요금 옵션[즉, 대량 구매 할인(discount bulk purchase), 5장을 사면 1장 무료(buy 5 get one free) 등]을 선택할 수 있도록 하는 교통 에이전시의 요금 규칙(참고자료 A(Appendix A)를 참조)에 대한 액세스가 가능하다.

페이패스 교통 지불 플랫폼(510)은 사전 적립 계좌에 대한 "충전" 활동에 관련된 인증(authorization) 및 청산(clearing) 기능을 수행할 수 있는 것이 바람직하다. 교통 에이전시는 이러한 트랜잭션을 위한 상인이 될 수 있으며, 이미 적당한 관계의 기존의 상인/매입자 관계가 이용될 수 있다. 페이패스 교통 지불 플랫폼(510)은 모든 사전 적립 계정에 대한 잔고를 유지 및 관리할 수 있다. 사전 등록된 카드 계정 잔고가 고갈되고 재로딩되지 않은 경우, 카드는 네거티브 파일에 추가될 것이다. 사전 적립 기능을 더 이상 사용하길 원하지 않고 그 대신에 사후 적립 기능을 이용하고자 하는 카드 소지자에 대해서 취소 기능(cancellation facility)이 제공될 수 있다. 자동 로딩 기능이 미리 설정되었다면, 카드 소지자에게는 자동 로딩 기능만 또는 자동 로딩 기능과 사전 적립 계정 자체의 두 가지 모두를 취소하는 선택권이 주어질 수 있다. 사전 적립 계정은 18분 내에 최대 6명의 탑승객에 대해 "패스 백"(pass back)을 허용할 수 있다. 사전 적립 페이페스 기기가 분실된 것으로 보고되면, 카드 소지자는, 잔액이 남아 있으면, 새로운 페이패스 계정으로 송금된 잔액을 가질 수 있다.

사후 적립 계정의 경우, 페이패스 교통 지불 플랫폼(510)은, 일련의 미리 규정된 업무 규칙에 기초하여 나중에 청산 및 인증을 위한 지불 카드 트랜잭션을 집계(aggregate)할 수 있는 것이 바람직하다. 시연 프로젝트(demonstration project)에 대해, 마스터카드, 교통 에이전시, 및 카드 발급자는 서로 공동으로 규칙을 세울 수 있다. 사후 적립 계정은 18분 내에 최대 6명의 탑승객에 대해 "패스 백"(pass back)을 허용할 수 있다.

사후 적립 트랜잭션(post-funded transactions)에 대한 인증 처리 과정은 다음과 같다:

임의의 트랜잭션을 개시할 때에, 페이패스 교통 지불 플랫폼(510)은, 개찰구에서 사용된 카드에 대해, 미리 설정된 사전 적립 계정이 있는지 여부를 검사할 수 있으며, 사전 적립 계정이 발견되지 않은 경우에, 트랜잭션은 사후 적립된 것으로 간주할 수 있다.

제1 사후 적립 트랜잭션의 경우, 페이패스 교통 지불 플랫폼(510)은 인증을 수행할 수 있다. 이러한 인증은, 이하의 집계 업무 규칙(aggregation business rules)에 개시된 금액에 대해서 행해질 수 있다. 만일 카드 발급자가 이러한 인증 요청을 거절한다면, 계정은 네거티브 파일에 추가될 것이다.

이러한 인증을 얻게 되면, 카드는 적절한 업무 규칙에 따라 교통 시스템에서 사용될 수 있다.

사후 적립 트랜잭션의 집계를 위한 적절한 업무 규칙은, 이하에 언급하는 조건들 중 어느 것이라도 합치되거나 그 이상이 되면, 청산을 위해 송금될, 집계된 트랜잭션 금액을 요구한다.

(1) 탑승이 10번 이루어졌다.

(2) 첫 번째 탑승 이후 최대 1달의 반이 지났다. 그달의 제1 일 및 제15 일에, 적어도 2주일 동안 개설되었던 사후 지불 집계 금액이 게시될 수 있다.

(3) 트랜잭션이 허용되었지만 그 전에 집계 금액이 인증을 위해 보낸 후에 카드가 핫 리스트에 게시된다(posted).

이러한 조건들은 파라미터에 기초한다. 파라미터는, 페이패스 교통 지불 플랫폼(510)을 통해 설정될 수 있으며, 페이패스 리더기/단말기에 다운로드될 수 있다. 집계 업무 규칙 조건 중 임의의 하나에 부합되면, 페이패스 교통 지불 플랫폼(510)은 청산 트랜잭션(clearing transaction)을 생성할 수 있다. 카드를 다음에 사용하는 경우(사후 정산), 페이패스 교통 지불 플랫폼(510)은 그 카드가 알려지지 않은 것으로(unknown)으로 처리하고, 인증 요청을 처리할 수 있다.

페이패스 교통 지불 플랫폼(510)은 인증 및 청산 기능을 수행하기 위한 네트워크에 액세스할 수 있는 것이 바람직하다. 교통 에이전시는 이러한 트랜잭션을 위한 상인이고, 기존의 상인/매입자 관계는 이미 적당하게 되어 있는 것으로 한다. 페이패스 교통 지불 플랫폼(510)은, 모든 트랜잭션의 감사 추적(audit trail)을 제공할 수 있으며, 플랫폼 및 개찰구에서 일어나는 상호작용을 제공할 수 있는 것이 바람직하다. 이러한 데이터는 지정된 지원 시스템 및 파일 포맷으로 이출(exportable)될 수 있다.

페이패스 교통 지불 플랫폼(510)은, 포지티브(자격(entitlement)) 파일 및 네거티브 파일을 유지 및 관리한다. 네거티브 파일은 무효 카드(hot card)[예컨대, 분실된, 도난당한, 및 "회수 불가 발급"(NRI: Never Received in Issuance) 카드]에 등재하는데 사용된다. 네거티브 파일은 단말기(524)에 정기적으로 다운로드되는데, 4시간마다 다운로드되는 것이 바람직하다. 페이패스 교통 지불 플랫폼(510)은, 카드 발급자가 제공한 데이터, 마스터카드에서 제공한 데이터, 및/또는 페이패스 교통 지불 플랫폼 활동에 기초하여 하루에 여러 번, 네거티브 파일을 갱신할 수 있다(예컨대, 자신의 사전 적립 계정 잔고가 모두 고갈된 카드가 네거티브 파일에 추가될 수 있다). 발급 은행이 카드를 핫 리스트에서 제거하고자 하는 요청이 이루어질 때(예컨대, 이전에 핫 리스트에 추가되었던 연체 고객이 자신의 요금을 지불한 경우), 또는 고갈된 사전 적립 계정이 다시 적립된 경우에, 카드가 핫 리스트에서 빠질 수 있다.

페이패스 교통 지불 플랫폼(510)과 단말기 시스템은 페이패스 기기의 사용을 추적하기 위해 벨로시티 파일(velocity file)을 유지할 수 있다. 이 벨로시티 파일은 하루 중에 여러 번 교통 에이전시로 보내질 수 있다. 페이패스 교통 지불 플랫폼은, 예컨대 MTA에 의해 제공 및 유지되는 다이얼업 전화선(dial up phone line)을 통해, 단말기와의 통신을 요청받을 수 있다.

도 5는, 고객이 교통 시스템의 카드 리더기에 요금 지불을 위해 페이패스 카드를 제시한 경우의, AFC 프로세스(700)에 포함되는 단계의 예를 나타낸다. 단계 71에서, 카드의 은행 식별 번호(BIN: bank identification number)가 검사된다. BIN이 맞다면, 단계 72에서, 카드가 핫 리스트에 있는지가 검사된다. 단계 71 및 단계 72에서 검사 결과 중 하나라도 실패라면, 트랜잭션이 거절된다(단계 73). 단계 71과 단계 72에서의 검사 결과가 성공이라면, 트랜잭션이 게시되고(posted)(단계 74), 페이패스 교통 지불 플랫폼으로 보내서 처리한다(단계 75).

페이패스 교통 지불 플랫폼은, 단계 76에서, 카드와 관련된 사전 적립 계정이 있는지 여부를 판정한다. 사전 적립 계정이 있는 경우, 페이패스 교통 지불 플랫폼은, 단계 77에서, 사전 적립 계정 활동(pre-funded account activity)을 수행한다. 카드와 관련된 사전 적립 계정이 없는 경우, 페이패스 교통 지불 플랫폼은, 단계 78에서, 카드와 관련된 축적(accumulation) 또는 집계(aggregation) 계정이 있는지 여부를 판정한다. 카드와 관련된 축적 계정이 없는 경우, 페이패스 교통 지불 플랫폼은, 단계 79에서, 카드와 관련된 축적 계정을 개설한다. 카드와 관련된 축적 계정이 있는 경우, 페이패스 교통 지불 플랫폼은, 단계 80에서, 트랜잭션을 축적 계정에 축적한다. 마지막으로, 페이패스 교통 지불 플랫폼은, 단계 81에서, 업무 규칙 조건이 트리거될 때, 집계를 위한 정산/청산 기록을 준비한다.

본 발명에 의하면, 앞서 언급한 AFC 솔루션을 구현하기 위한 소프트웨어(즉, 명령어)가 컴퓨터로 판독가능한 매체에 제공될 수 있다. (본 발명에 따라 앞서 설명한)각각의 단계와, 이들 단계의 임의의 조합은 컴퓨터 프로그램 명령에 의해 구현될 수 있다는 것을 알 수 있다. 이러한 컴퓨터 프로그램 명령은 머신(machine)을 생성하기 위해 컴퓨터 또는 다른 프로그램가능한 장치에 로딩될 수 있는데, 이러한 명령이 컴퓨터나 다른 프로그램가능한 장치에서 실행되며, 앞서 언급한 AFC 솔루션의 기능을 구현하기 위한 수단을 생성하는 것에 의해 이루어진다. 이러한 컴퓨터 프로그램 명령은 특정한 방식으로 기능을 수행하도록 컴퓨터 또는 다른 프로그램가능한 장치를 제어할 수 있으며, 이것은 컴퓨터로 판독가능한 메모리에 저장된 명령이 상기 언급한 AFC 솔루션의 기능을 구현하는 명령어 수단을 포함하는 제조업자의 물품을 생산하는 식으로 이루어진다. 컴퓨터 프로그램 명령어는, 컴퓨터나 다른 프로그램가능한 장치에서 실행되는 명령이 앞서 언급한 AFC 솔루션의 기능을 구현하기 위한 단계를 제공하는 식으로, 컴퓨터로 구현된 프로세스를 생성하기 위해 일련의 동작 단계가 컴퓨터나 다른 프로그램가능한 장치에서 수행되도록, 컴퓨터나 다른 프로그램가능한 장치에 로딩될 수도 있다. 상기 언급한 AFC 솔루션을 구현하기 위한 명령어가 제공되는 컴퓨터로 판독가능한 매체에는, 펌웨어, 마이크로 컨트롤러, 마이크로 프로세서, 집적 회로, ASICS, 및 그외 다른 이용가능한 매체를 포함하며, 이에 한정되지 않는다는 것을 알 수 있을 것이다.

참고자료 A(Appendix A)

MTA 요금 구조

● 1회 탑승(single-ride) - 정상 요금(full fare) - $2

● 1회 탑승 - 할인 요금 - $1

● 정액 탑승(pay-per-ride) 메트로카드 (정상 요금 또는 할인 요금으로 사전 적립 방식의 이동)

● $4에서 $80까지 원하는 탑승 횟수만큼 구입

● 카드에 $10 이상 적립하고 20% 보너스를 받음

● 지하철과 버스 또는 버스 간의 자동 무료 환승

● (지하철에서 지하철로 또는 처음 출발할 때 탔던 버스로의 환승 제외)

● (카드 유효기간 만료시까지, 원하는 만큼 충전)

● (한번에 최대 4명분을 지불하는데 사용될 수 있음)

● 무제한 탑승(unlimited ride) 메트로카드 (사전 적립, 주어진 기한 내에서 무제한 이동)

● 1일 자유 이용 패스(1-Day Fun Pas)

● 7일짜리 (7-Day)

● 30일짜리

● 7일짜리 고속 버스 포함(Express Bus Plus)

● 30일 무제한 탑승(JKF 에어트레인만 해당)

● (충전 없음 - 새로운 시기마다 새로운 카드를 구매)

● (18분 동안 동일한 지하철 역 또는 동일한 버스 루트에서 사용할 수 없음

(한 번에 한 사람만 사용할 수 있음)

참고자료 B

표 - 지원되는 카드 및 교통 지불의 가능한 유형

참고자료 C

주요 구성요소의 기능/처리

이 참고자료는 시스템의 주요 구성요소에 대한 처리 효과의 비한정적(non-exhaustive)이며 예시적인 리스트이다.

게이트 처리( Gate Processing )

● 카드 판독(PAN + 만료일(Expiry Date) + CVC)

● 카드 확인 (국부적)

● PAN 체크섬(checksum) OK

● 만료일이 경과되지 않았는지 검사

● 카드 날짜를 국부적인 네거티브 파일과 비교하는 검사

● 카드 확인이 OK이면 게이트를 개방

● 트랜잭션 레코드를 포맷

● 역 + 게이트 + 카드 날짜 + 트랜잭션 종류(엔트리만) + 날짜/시간 스탬프

스테이션 컨트롤러 처리

● 네거티브 파일의 수신

● 네거티브 파일 조회에 응답

● 트랜잭션 레코드의 저장 및 전송(forward)

● 새로운 교통 지불 플랫폼으로 페이패스(PayPass) 트랜잭션을 전달

● 현재의 큐빅 플랫폼(current Cubic platform)으로 기존의 메트로카드 트랜잭션을 전달

교통 지불 플랫폼 처리

● 테이블 유지

● 요금(fares)

● 액티브 스테이션(active station)

● 시스템 내의 게이트 - 요금 제어 영역(fare control area)에 의해

● 카드 종류

● 요금 방식(Fare Plan)

● 이동 규칙

● 카드 + 요금 방식 등록

● 카드 계정/자격(Card Account/Entitlement)

● 계정 정보에 대한 카드 소지자의 질의

● 요금 방식 갱신

● 카드 차단(예컨대, 분실된/도난당한)

● 네거티브 파일(negative file) 유지

● 새로운 엔트리 추가

● 엔트리의 정리(cleanup entries)

● 네거티브 파일의 분배

● 트랜잭션 배치 수신/유효성 검사

● 배치(batch)의 유효성 검사

● 트랜잭션의 유효성 검사

● 정렬(PAN, 날짜/시간, 스테이션/게이트)

● 트랜잭션 배치의 처리(주의사항 1번)

● 이동 트랜잭션(journey transaction) 생성 및 이동 요금(journey fare) 계산

● (예외상황 처리(handle exception))

● 정액 탑승 트랜잭션 처리

● 무제한 탑승 트랜잭션 처리

● 1회 탑승 트랜잭션 처리

● (하나 이상의 신용/직불 이동이 집계될 수 있는지 질의?)

● 리파워로부터 재로딩 처리

● 매입자 인터페이스(acquirer interface)(직불/신용 트랜잭션의 경우)

● 위기 관리(risk management)/부정 검출(fraud detection)

● 결제(settlement)

● MTA에 의한 결제

● 매입자에 의한 결제

● 리파워(rePower)에 의한 결제

● 고객 서비스

Claims

교통 시스템(transit system)에서 자동 요금 징수(automated fare collection)를 위한 방법으로서,

상기 교통 시스템의, 지불에 의해 개폐되는 개폐 지불 영역(gated pay areas)에 대한 액세스를 얻기 위해 고객이 제시하는 비접촉식 지불 카드(contactless payment card)를, 단말기 컨트롤러에 연결된 RFID-가능 카드 리더기(RFID-enabled card reader)를 사용하여 판독하는 단계;

판독된 상기 비접촉식 지불 카드를 카드 리스트를 가진 파일에 대해 평가(evaluating)해서, 상기 교통 시스템의 상기 지불에 의해 개폐되는 개폐 지불 영역에 대한 고객의 액세스를 승인(granting)하거나 거절(denying)하는 단계;

카드 트랜잭션 레코드(card transaction record)를 준비해서(preparing), 교통 지불 플랫폼(transit payment platform)과 통신하는(communicating) 단계; 및

상기 교통 지불 플랫폼에서, 상기 교통 시스템이 상기 교통 시스템의 지불 영역(transit system pay area)에 대한 고객의 승인된 액세스에 관한 요금을 자동으로 징수할 수 있도록 상기 카드 트랜잭션 레코드를 처리하는 단계

를 포함하는 자동 요금 징수 방법.
제1항에 있어서,

상기 교통 지불 플랫폼으로부터, 상기 RFID-가능 카드 리더기에 연결된 단말 기 컨트롤러에, 상기 카드 리스트를 가진 상기 파일을 통신하는(communicating) 단계를 더 포함하며,

상기 카드 리스트에는 분실된 카드, 도난당한 카드 및 연체된 카드가 포함되는, 자동 요금 징수 방법.
제1항에 있어서,

상기 교통 지불 플랫폼에서 상기 카드 트랜잭션 레코드를 처리하는 단계는, 고객이 제시한 상기 비접촉식 지불 카드의 발급자(issuer)에 링크(link)된 상업적인 카드 지불 전자 네트워크(commercial payment-by-card electronic network)를 통한 카드 트랜잭션의 인증(authorization), 청산(clearing), 및 정산(settlement)을 포함하는, 자동 요금 징수 방법.
제3항에 있어서,

비접촉식 지불 카드와 트랜잭션 지불 처리를 위한 공개(open) ISO 산업 표준에 부합되도록 하는(conforming) 단계를 더 포함하는, 자동 요금 징수 방법.
제3항에 있어서,

상기 고객이 제시한 상기 비접촉식 지불 카드의 발급자에 링크된 상업적인 카드 지불 전자 네트워크를 통한 카드 트랜잭션의 상기 인증, 청산, 및 정산은, 집계된(aggregated) 카드 트랜잭션의 인증을 포함하는, 자동 요금 징수 방법.
제1항에 있어서,

상기 교통 지불 플랫폼에서, 상기 교통 시스템이 상기 교통 시스템의 지불 영역에 대한 고객의 승인된 액세스에 관한 요금을 자동으로 징수(collect)할 수 있도록 상기 카드 트랜잭션 레코드를 처리하는 단계는, 상기 고객이 제시한 상기 비접촉식 지불 카드가 미등록된 카드인지, 또는 사전 적립 교통 지불 계정(pre-funded transit payment account)과 관련하여 미리 등록된 카드인지를 판정하는 단계를 포함하는, 자동 요금 징수 방법.
제6항에 있어서,

상기 사전 적립 지불 계정과 관련하여 등록된 카드에 대해, 상기 교통 시스템이 상기 교통 시스템의 지불 영역에 대한 고객의 승인된 액세스에 관한 요금을 자동으로 징수할 수 있도록 상기 교통 지불 플랫폼에서 상기 카드 트랜잭션 레코드를 처리하는 단계는, 상기 사전 적립 교통 지불 계정의 잔고(balance)를 확인(checking)하고, 상기 사전 적립 교통 지불 계정으로부터 요금 지불(fare payment)을 획득하는(obtaining) 단계를 포함하는, 자동 요금 징수 방법.
제7항에 있어서,

상기 사전 적립 교통 지불 계정의 잔고가 상기 사전 적립 교통 지불 계정으로부터 상기 요금 지불을 획득하기에 충분하지 않은 경우, 분실된, 도난당한 및 연 체된 카드 리스트에 상기 카드를 추가하는 단계를 더 포함하는, 자동 요금 징수 방법.
제6항에 있어서,

상기 사전 적립 교통 지불 계정은 탑승 자격 계정(ride entitlement account)이며,

상기 사전 적립 교통 지불 계정의 잔고를 확인하는 단계는, 탑승 자격의 이용가능성을 확인하는 단계를 포함하고,

상기 사전 적립 교통 지불 계정으로부터 요금 지불을 획득하는 단계는 상기 계정으로부터 탑승 자격을 공제하는(deducting) 단계를 포함하는, 자동 요금 징수 방법.
제1항에 있어서,

상기 교통 시스템이 상기 교통 시스템의 지불 영역에 대한 고객의 승인된 액세스에 관한 요금을 자동으로 징수할 수 있도록 상기 교통 지불 플랫폼에서 상기 카드 트랜잭션 레코드를 처리하는 단계는, 교통 시스템 요금 스케줄(fare schedule)을 구현하는(implementing) 단계를 포함하는, 자동 요금 징수 방법.
교통 시스템의 지불 영역에 대한 액세스를 얻기 위해 상업적 카드 발급자가 발급한 RFID-가능 스마트 카드를 제시하는 고객으로부터 요금을 징수하기 위한, 교 통 시스템의 자동 요금 징수 시스템에 있어서,

상기 자동 요금 징수 시스템은,

교통 지불 플랫폼;

상기 교통 시스템의 지불 영역(pay area)의 앞쪽에 있는(leading) 게이트에 배치되며, 고객이 제시한 상기 RFID-가능 스마트 카드를 비접촉식으로 판독하도록 구성된 RFID-가능 카드 리더기; 및

상기 RFID-가능 카드 리더기와 인터페이스하는 단말기 컨트롤러

를 포함하며,

상기 단말기 컨트롤러와 상기 RFID-가능 카드 리더기는, 카드 리스트를 갖는 파일에 대해 상기 카드 리더기에 의해 판독된 상기 스마트 카드를 허용 또는 거부하도록 해서, 상기 게이트를 통한 상기 고객의 액세스를 승인하거나 거절하도록 구성되고, 또한 카드 트랜잭션 레코드를 생성하여 상기 교통 지불 플랫폼과 통신하도록 구성되어 있으며,

상기 교통 지불 플랫폼은, 상기 교통 시스템의 지불 영역에 대한 상기 고객의 승인된 액세스에 관한 요금을 상기 교통 시스템이 자동으로 징수할 수 있도록, 상기 카드 트랜잭션 레코드를 처리하도록 구성된, 자동 요금 징수 시스템.
제1항에 있어서,

상기 교통 지불 플랫폼은 지불 카드 트랜잭션의 인증, 청산 및 정산을 위한 카드 지불 전자 네트워크에 링크된 인증/청산 애플리케이션을 포함하는, 자동 요금 징수 시스템.
제12항에 있어서,

상기 스마트 카드와 상기 카드 지불 전자 네트워크는 비접촉식 지불을 위한 공개 ISO 산업 표준에 따르는, 자동 요금 징수 시스템.
제1항에 있어서,

상기 교통 지불 플랫폼은, 분실된, 도난당한 또는 연체된 카드를 포함하는 카드 리스트를 유지하도록(maintain) 구성된(designed) 파일 애플리케이션(file application)을 포함하는, 자동 요금 징수 시스템.
제1항에 있어서,

상기 교통 지불 플랫폼은, 상기 카드 리스트, 관련 요금 및 탑승 자격을 유지하도록 구성된 파일 애플리케이션을 포함하는, 자동 요금 징수 시스템.
제1항에 있어서,

상기 교통 지불 플랫폼은, 스마트 카드를 사전 적립 교통 계정에 링크시킬 수 있는 고객 계정 관리 애플리케이션(customer account management application)을 포함하는, 자동 요금 징수 시스템.
제16항에 있어서,

상기 교통 지불 플랫폼은, 상기 카드 트랜잭션을 사전 적립 계정 트랜잭션과 사후 적립(post-funded) 계정 트랜잭션 중 하나로서 처리하도록 구성된 고객 지불 애플리케이션(customer payment application)을 포함하는, 자동 요금 징수 시스템.
제1항에 있어서,

상기 교통 지불 플랫폼은, 상기 RFID-가능 카드 리더기와 상기 단말기 컨트롤러에 대해 구성 갱신(configuration updates)을 제공하도록 구성된 네트워크 관리 애플리케이션을 포함하는, 자동 요금 징수 시스템.
제1항에 있어서,

상기 교통 지불 플랫폼은, 교통 시스템의 요금 스케줄에 따라 트랜잭션 요금을 구현하도록 구성된 계정 유지 애플리케이션(account maintenance application)을 포함하는, 자동 요금 징수 시스템.
제1항에 있어서,

상기 교통 지불 플랫폼은, 계정 특징(account features) 및 트랜잭션 리포트(transaction reports)를 제공하도록 구성된 교통 고객 인터페이스(transit customer interface)를 포함하는, 자동 요금 징수 시스템.