KR20100016560A

KR20100016560A - 트랜잭션에 대한 당사자 인증 방법 및 시스템

Info

Publication number: KR20100016560A
Application number: KR1020097023807A
Authority: KR
Inventors: 데이비드 웬트커; 마이클 린델씨; 올리비어 브랜드; 제임스 디믹; 트리부완 에이. 씽 그레얼
Original assignee: 비자 유에스에이 인코포레이티드
Priority date: 2007-04-17
Filing date: 2008-04-16
Publication date: 2010-02-12
Also published as: EP2149084B1; CA2684614A1; US8156543B2; US20090325542A1; BRPI0810369B1; JP2010525461A; JP5520813B2; BRPI0810369B8; EP2149084A1; CN101711383A; WO2008131021A1; JP2017021816A; JP2014160487A; AU2008243004A1; US20100153272A1; KR101540417B1; BRPI0810369A2; CA2684614C; US9160741B2; EP2149084A4

Abstract

본 발명의 하나의 실시예는, 제시자와 연관된 계정과 연관된 별칭 식별자를 수신하는 단계, 상기 별칭 식별자를 사용하여 연관된 신뢰 당사자를 결정하는 단계, 상기 연관된 신뢰 당사자를 결정한 후 상기 신뢰 당사자에게 검증 요청 메시지를 송신하는 단계, 및 검증 응답 메시지를 수신하는 단계를 포함하는 방법에 관한 것이다.

Description

트랜잭션에 대한 당사자 인증 방법 및 시스템{Method and system for authenticating a party to a transaction}

-관련 출원에 대한 상호-참조(cross-references)

본 출원은 2007년 4월 17일에 출원된 미국 특허 출원 번호 60/912,406 - 이 출원은 이 문서에서 모든 목적들을 위해 참조로써 그 전체로 통합됨 - 에 관한 우선권 등의 이익을 주장하는 정규출원이다.

두 당사자들 간의 트랜잭션(transaction) (지불(payment) 또는 비지불 트랜잭션) 동안, 각 당사자는 사기를 피하기 위해 전형적으로 다른 쪽 당사자와 관련된 데이터 및/또는 신원(identity)을 인증하기를 원한다.

원격 통신 기기로부터 개시되고 수행되는 트랜잭션들은, 전통적인 대면(face-to-face) 인증(authentication) 절차들이 수행될 수 없기 때문에, 대면 트랜잭션들보다 더 위험할 수 있다. 예를 들어, 원격 트랜잭션을 수행할 때 소비자의 운전자 면허증에 관한 사진을 체크하는 것이 가능하지 않다.

전술한 것의 관점에서, 원격 트랜잭션 동안 소비자와 같은 개인의 신원 및 프로파일(profile) 데이터를 인증하는 시스템이 바람직할 것이다. 그 인증 시스템은 바람직하게 구현 및 사용이 용이할 것이고, 자원 투입을 최소로 요할 것이며, 그리고 시스템 참여자들 간에 높은 상호운용성(interoperability) 수준을 제공할 것이다.

트랜잭션과 연관된 또 하나의 문제는 일반적으로 상인들이 종종 구매 트랜잭션 동안 지불 카드(payment card) 정보를 수신한다는 것이다. 만약 상인이 정직하지 않다면, 소비자의 지불 정보가 더렵혀질 수 있다. 본 발명의 다른 실시예들은 상인들이 소비자 지불 정보를 보유하지 않도록 지불 트랜잭션들과 같은 트랜잭션들을 개시하기 위한 별칭 식별자(alias identifier)들의 사용에 관한 것이다.

본 발명의 실시예들은 상기의 문제들 및 다른 문제들을 개별적으로 그리고 집단적으로 해결한다.

본 발명의 실시예들은, 어떤 신원을 가짐으로서 그리고 어떤 해당 프로파일 데이터를 가짐으로서 자신을 다른 당사자("수용자(acceptor)")에게 제시하는 개인("제시자(presenter)")의 신원을 인증하고 그 개인의 프로파일 데이터를 유효성 확인(validating)하는 방법들 및 시스템들을 포함한다. 비록 본 발명의 실시예들이 원격 트랜잭션들에 제한되는 것은 아니지만, 본 발명의 실시예들은 대면 인증 절차를 수행하기 어려운 원격 트랜잭션들에서 유리하게 사용될 수 있다. 본 발명의 실시예들은 또한 신뢰 당사자(trusted party)가 제시자의 신원 및 프로파일 데이터를 인증할 수 있게 해 준다. 프로파일 데이터 프로비저닝(provisioning) 및 프로파일 업데이트와 같은 다른 기능들도 또한 수행될 수 있다.

하나의 실시예는, a) 제시자(예: 지불 카드를 소지한 소비자)의 계정(account)에 대한 계정 식별자(예: 지불 카드 계정 번호)와 연관된 별칭 식별자(예: 전화 번호)를 수신하는 단계; b) 상기 별칭 식별자를 사용하여 연관된 신뢰 당사자(예: 그 지불 카드를 발행한 은행)를 결정하는 단계; c) 상기 연관된 신뢰 당사자를 결정한 후에 상기 신뢰 당사자에게, 상기 신뢰 당사자 또는 상기 제시자가 인증 프로그램에 참여하는지 여부에 관한 정보를 요청하는 검증 요청 메시지(verification request message)를 송신하는 단계; 및 d) 상기 신뢰 당사자 또는 상기 제시자가 상기 인증 프로그램에 참여하는지 여부를 나타내는 검증 응답 메시지를 수신하는 단계;를 포함하는 방법에 관한 것이다.

본 발명의 또 하나의 실시예는, a) 제시자의 계정에 대한 계정 식별자와 연관된 별칭 식별자를 수신하기 위한 코드; b) 상기 별칭 식별자를 사용하여 연관된 신뢰 당사자를 결정하기 위한 코드; c) 상기 연관된 신뢰 당사자를 결정한 후에 상기 신뢰 당사자에게, 상기 신뢰 당사자 또는 상기 제시자가 인증 프로그램에 참여하는지 여부에 관한 정보를 요청하는 검증 요청 메시지를 송신하기 위한 코드; 및 d) 상기 신뢰 당사자 또는 상기 제시자가 상기 인증 프로그램에 참여하는지 여부를 나타내는 검증 응답 메시지를 수신하기 위한 코드;를 포함하는 컴퓨터 판독가능 매체에 관한 것이다.

본 발명의 또 하나의 실시예는, a) 제시자의 계정과 연관된 계정 식별자와 연관된 별칭 식별자를 제공하는 단계; b) 상기 별칭 식별자를 수신한 후에 인증 요청 메시지를 수신하는 단계: 및 c) 상기 인증 요청 메시지를 수신한 후에 인증 응답 메시지를 송신하는 단계;를 포함하는 방법에 관한 것이다.

본 발명의 또 하나의 실시예는, a) 제시자의 계정과 연관된 계정 식별자와 연관된 별칭 식별자를 제공하기 위한 코드; b) 상기 별칭 식별자를 제공한 후에 인증 요청 메시지를 수신하기 위한 코드; 및 c) 상기 인증 요청 메시지를 수신한 후에 인증 응답 메시지를 송신하기 위한 코드;를 포함하는 컴퓨터 판독가능 매체에 관한 것이다.

본 발명의 이러한 실시예들 및 다른 실시예들은 도면들과 이하의 설명을 참조하여 아래에서 더 상세하게 기술된다.

도 1은 본 발명의 일 실시예에 따른 시스템에 관한 블록 다이어그램(block diagram)을 보여주고 있다.

도 2는 본 발명의 또 하나의 실시예에 따른 시스템에 관한 또 하나의 블록 다이어그램을 보여주고 있다.

도 3은 본 발명의 또 하나의 실시예에 따른 또 하나의 시스템에 관한 또 하나의 블록 다이어그램을 보여주고 있다.

도 4a 및 도 4b (도 4b는 도 4a에 이어짐, 이하 '도 4'로 통칭함)는 지불 트랜잭션 전에 일어날 수 있는 등록 프로세스 구현예를 예시하는 흐름도를 보여주고 있다.

도 5a 및 도 5b (도 5b는 도 5a에 이어짐, 이하 '도 5'로 통칭함)는 지불 트랜잭션 동안 일어날 수 있는 등록 프로세스 구현예를 예시하는 흐름도를 보여주고 있다.

도 6은 지불 트랜잭션을 개시하기 위한 프로세스 구현예를 예시하는 흐름도를 보여주고 있다.

도 7a 및 도 7b (도 7b는 도 7a에 이어짐, 이하 '도 7'로 통칭함)는 인증 프로세스 구현예를 예시하는 흐름도를 보여주고 있다.

도 8은 지불 승인(payment authorization) 프로세스 구현예를 예시하는 흐름도를 보여주고 있다.

도 9a는 전화기 내 콤포넌트들을 예시하는 블록 다이어그램을 보여주고 있다.

도 9b는 전형적인 지불 카드에서 있을 수 있는 콤포넌트들을 보여주고 있다.

도 10은 컴퓨터 장치 내 콤포넌트들의 블록 다이어그램을 보여준다.

도면들에서, 같은 숫자들은 같은 요소들을 가리키며 같은 요소들에 관한 설명은 어떤 경우들에서는 반복되지 않을 수도 있다.

본 발명의 실시예들은, 어떤 신원을 가짐으로서 그리고 어떤 해당 프로파일 데이터를 가짐으로서 자신을 다른 당사자("수용자")에게 제시하는 개인("제시자")의 신원을 인증하고 그 개인의 프로파일 데이터를 유효성 확인하는 방법들 및 시스템들을 제공한다. 소비자는 제시자의 일 예일 수도 있다. 수용자는 서비스 제공자, 정부 기관(government agency), 상인, 또는 트랜잭션 절차를 밟기 전에 상기 제시자의 신원을 인증할 필요가 있을 수 있는 어떤 다른 엔티티(entity)일 수 있다. 신원의 인증은 어떤 개인이라고 주장하는 제시 당사자의 신원을 검증하는 것을 가리 킬 수 있다. 프로파일 데이터를 유효성 확인하는 것은 제시자에 의해 제공된 프로파일 데이터가 그 제시자와 실제로 연관되어 있는지를 확인하는 것을 가리킬 수 있다. 프로파일 데이터 프로비저닝 및 프로파일 업데이트와 같은 다른 기능들 또한 본 발명의 실시예들에서 수행될 수 있다. 이들 기능들은 개별적으로 또는 서로 결합되어 수행될 수 있다. 본 발명의 실시예들은 전통적인 대면 인증 절차들을 수행하기 어려운 원격 트랜잭션들을 수행하는데 유리하게 사용될 수 있다.

예시로, 본 발명의 일 실시예에서, 신용 카드(credit card)를 사용하여 구매를 하기 위해 상인을 호출하는 소비자는 트랜잭션이 진행되기 전에 인증될 수 있다. 신용 카드의 발행자(issuer)는 그 트랜잭션이 종결되기 전에 그 소비자 및 그 소비자의 프로파일 데이터를 인증할 수 있다 (발행자는 은행, 신용협동조합(credit union), 또는 소비자가 계정을 사용하여 트랜잭션을 수행할 수 있도록 소비자를 위하여 계정을 개설할 수 있는 다른 단체일 수 있다). 그 소비자 및 그 소비자의 데이터가 인증된 후에, 이 정보는 후속하여 상인에게 송신될 수도 있다. 그러면 상인은 발행자가 그 소비자 및 그 소비자의 데이터를 인증하였음을 알면서 그 트랜잭션의 절차를 밟을 수 있다. 어떤 경우들에서는, 만약 그 신용 카드의 발행자가 그 소비자 및 그 소비자의 데이터를 인증한다면, 그 발행자는 만약 그 트랜잭션이 나중에 부정한 것으로 판단된다면 위험성을 감수할 수도 있다. 따라서, 본 발명의 실시예들을 사용하여, 상인들 및 발행자들은 수행되는 트랜잭션이 인증된 것이라는 신뢰를 더 크게 가질 수 있다.

본 발명의 많은 특정 실시예들이 아래에서 더 상세하게 기술된다. 다음의 두 문자어들이 몇몇 경우들에서 사용된다:

ACS: Access Control Server <액세스 제어 서버> - 액세스 제어 서버는 원격 또는 대면의 구매 트랜잭션과 같은 트랜잭션 동안 제시자들(예: 소비자들, 카드소지자(cardholder)들)을 인증할 수 있는 능력을 발행자들에게 제공할 수 있다.

DS: Directory Server <디렉토리 서버> - 디렉토리 서버는 상인 플러그-인(merchant plug-in; MPI) 및 발행자들의 ACS 간에 등록 및 인증 정보를 담고 있는 메시지들을 라우팅하기 위해 사용될 수 있다.

IVR: Interactive Voice Response unit <대화식 음성 응답 유닛> - 대화식 음성 응답 유닛은 컴퓨터 장치가 보통의 전화 통화를 통해 음성 및 터치 톤(tone)들을 탐지할 수 있게 해 주는 전화 기술을 포함할 수 있다.

SMS: Short Message Service <단문 메시지 서비스> - 단문 메시지 서비스는 모바일 전화기들로 그리고 모바일 전화기들로부터 송신된 메시지들을 포함할 수 있다. 전형적인 SMS 메시지들은 사용자들로 하여금 메시지 당 160 문자들까지 송신할 수 있게 해 줄 수 있다.

MPI: Merchant Plug-In <상인 플러그-인> - 상인 플러그-인은 어떤 실시예들에서 매입자(acquirer) 도메인에서 동작하는 콤포넌트일 수 있다. 온라인 환경에서, 그것은 상인을 위하여 다양한 인증 기능들을 수행한다. 이러한 기능들은 인증이 카드 번호에 대하여 이용가능한지(available) 여부를 결정하는 기능, 및 인증 메시지 내 디지털 서명(digital signature)을 유효성 확인하는 기능을 포함한다. 상인 플러그-인은 상인에게 액세스가능한 적합한 소프트웨어 및/또는 하드웨어에 의해 구현될 수도 있다.

MSISDN: Mobile Subscriber ISDN Number <모바일 가입자 ISDN 번호> - 모바일 가입자 ISDN(integrated services digital network) 번호는 소비자의 전화 번호일 수 있다.

USSD: Unstructured Supplementary Service Data <비구조적 부가 서비스 데이터> - 비구조적 부가 서비스 데이터는 GSM(Global system for mobile communications) 네트워크의 채널들 상에서의 정보의 전송을 지원하기 위한 GSM 표준에 형성된 특성을 가진다. USSD는 세션 기반 통신 특성을 제공하고, 그에 의하여 다양한 어플리케이션들을 가능하게 한다.

WAP: Wireless Application Protocol <무선 어플리케이션 프로토콜> - WAP 브라우저들은 PC(personal computer) 기반 웹 브라우저의 기본 서비스들 모두를 제공할 수 있고, 모바일 전화기의 제약사항들(restrictions) 내에서 동작하도록 단순화될 수 있다.

상기에서 언급한 바와 같이, 본 발명의 실시예들은 특히 원격 트랜잭션을 수행하는데 유용하다. 원격 트랜잭션은, 모바일 방식 또는 지상통신선(land-line) 방식의 음성 호출, 단문 메시지 서비스(SMS) 메시지 등을 포함하는, 그러나 이에 제한되지 않는, 통신 방법들을 통해 수행될 수 있다. 다양한 데이터 전송 프로토콜들(예: TCP/IP)이 또한 사용될 수 있다. 원격 트랜잭션은, 모바일 전화기, 스마트폰(smartphone), 인터넷연결된 컴퓨터나 단말들, PDA(personal digital assistant) 등을 포함하는, 그러나 이에 제한되지 않는, 기기들로부터 개시될 수 있다.

본 발명의 실시예들은 모바일 전화기 및 원격 트랜잭션의 이용에 한정되는 것은 아니다. 본 발명의 실시예들은 또한 다양한 통신 기기들, 지불 루트들, 및 인증 루트들의 이용을 포함할 수도 있다. 통신 기기들, 지불 루트들, 및 인증 루트들의 몇 가지 예들이 아래에 제공된다.

브라우징 루트/ 환경/ 기기	지불 루트 또는 메커니즘	소비자 인증 루트
소비자가 데스크탑 또는 랩탑 컴퓨터와 같은 개인용 컴퓨터를 사용하여 상인의 웹 사이트를 브라우징. 예: 소비자는 인터넷 상에서 휴대용 음악 기기를 구매한다.	소비자는 자신의 개인용 컴퓨터를 사용하여 상인의 웹 사이트에 관한 웹 페이지 상에 자신의 전화 번호를 기입한다.	소비자는, 그 소비자에 의해 운용되는 모바일 또는 고정식 기기 상에서 실행되는 클라이언트 어플리케이션을 거쳐, 또는 소비자의 발행자나 다른 엔티티에 의해 구현된 임의의 다른 적합한 루트/프로세스를 거쳐, 인바운드(inbound) IVR 호출을 사용하여 인증될 수 있다.
메일 주문/ 전화 주문(Mail order/telephone order; MOTO). 예: 소비자는 레스토랑에 전화하여 피자를 구매한다.	상인의 콜 센터 에이전트는 소비자의 전화 번호를 입수하여 그것을 그 상인의 웹 사이트 상의 웹 페이지에 기입한다.	상기와 같음
IVR, 또는 USSD나 SMS와 같은 다른 자동화된 루트. 예: 소비자는 전화기를 사용하여 통신시간(airtime)을 구매한다.	소비자는 자동화 서비스(예: IVR을 통해)를 호출하고, 지불액을 선택하며, 그리고 자신의 모바일 전화 번호를 기입한다.	상기와 같음
대면(상인은 전화기와 같은 POS(point of sale) 단말에 지불 상세를 기입한다). 예: 소비자는 배관공에게 대면 트랜잭션에서 주어진 서비스들에 대하여 지불한다.	상인은 그 상인의 모바일 전화기로부터 트랜잭션을 개시한다. 예를 들어, 상인은 카드의 현재 상태에 대하여 소비자 지불 카드의 뒤에 소비자의 CVV-2 번호를 별도로 기입할 수도 있다.	상기와 같음
대면(소비자는 모바일 전화기 등에 지불 상세를 기입한다). 예: 소비자는 배관공에게 대면 트랜잭션에서 주어진 서비스에 대하여 지불함.	소비자는 자신의 모바일 전화기로부터 트랜잭션을 개시한다. 소비자는 상인의 전화 번호 및 지불액을 그 소비자의 모바일 전화기에 기입함으로써 끝마친다.	상기와 같음

이제 본 발명의 특정 실시예들이 도면들을 참조하여 기술될 수 있다. 하나의 실시예에서, 별칭 식별자가 수신된다. 그 별칭 식별자는 제시자(예: 소비자)의 계정에 대한 계정 식별자 (이를테면 계정 번호)와 연관된다. 그 별칭 식별자는 전화 번호일 수 있고 그 계정 식별자는 신용 카드 계정 번호와 같은 계정 번호일 수 있다. 그 별칭 식별자가 수신된 후에, 그 별칭 식별자를 사용하여 연관된 신뢰 당사자가 결정된다. 그 신뢰 당사자는 그 신용 카드 계정 번호를 그 제시자에게 발행한 발행자일 수 있다.

그러면 그 연관된 신뢰 당사자를 결정한 후에 검증 요청 메시지가 그 신뢰 당사자에게 송신될 수 있다. 그 검증 요청 메시지는 그 신뢰 당사자 또는 그 제시자가 인증 프로그램에 참여하는지를 검증하는 것을 요청한다. 예를 들어, 그것은 그 제시자 및 그 신뢰 당사자 중 한 쪽 또는 양쪽 모두가 그 인증 프로그램에 참여하는지를 검증하는 것을 요청할 수도 있다. 그 검증 요청 메시지가 송신된 후에, 검증 응답 메시지가 수신된다. 그 검증 응답 메시지는 그 신뢰 당사자 또는 그 제시자가 그 인증 프로그램에 참여하는지 여부를 나타낸다.

그 검증 응답 메시지를 수신한 후에, 인증 요청 메시지가 소비자에 의해 운용되는 통신 기기(예: 전화기)로 송신될 수도 있다. 그러면 그 소비자는 그 소비자를 인증하는 인증 응답 메시지의 송신을 개시할 수도 있다. 그 소비자가 인증된 후에, 그 소비자는 의도된 트랜잭션 절차를 밟을 수도 있다. 그 트랜잭션은 구매 트랜잭션, 자금 이체(money transfer) 등일 수 있다.

도 1은 본 발명의 일 실시예에 따른 시스템을 보여주고 있다. 도 1의 시스템은 인터넷 상에서 또는 전화기(예: 모바일 전화기)를 사용하여 일어나는 트랜잭션 과 같은 원격 트랜잭션을 수행하기 위해 이용될 수 있다.

그 시스템의 콤포넌트들은 제시자 도메인, 상호운용성 도메인, 및 신뢰 당사자 도메인 내에 있는 것으로 특징지어질 수 있다. 본 발명의 다른 실시예들에서는, 그 시스템의 콤포넌트들은 다른 도메인 유형들 또는 다른 도메인들에 존재할 수도 있다. 본 발명의 일 실시예에 따른 시스템은 단일 도메인 또는 임의의 적합한 도메인들의 조합에 임의의 개수의 콤포넌트들 또는 콤포넌트들의 조합을 포함할 수 있다. 도 1의 실시예에서, 인증 시스템은 상호운용성 도메인 및 발행자/신뢰 당사자 도메인에서 보여진 콤포넌트들을 포함할 수 있다.

도 1은 상인(22)과 통신하는 제시자(21)를 보여주고 있다. 상인(22)은 웹 페이지 인터페이스(23)를 제공할 수도 있고, 그 웹 페이지 인터페이스(23)는 발행자 룩업(look-up) 시스템(24)에 연결될 수도 있다. 발행자 룩업 시스템(24)은 상인 플러그-인(MPI, 28), 디렉토리 서버(27), 액세스 제어 서버(25), 제시자 파일 데이터베이스(presenter file database, 26) 뿐만 아니라 챌린지 인터페이스(challenge interface, 29)에 동작가능하게 연결될 수도 있다.

도 1에서, 제시자 도메인은 제시자(21) 및 상인(22)를 포함한다. 제시자(21)는, 자신의 신원이 인증되어질 그리고/또는 자신의 데이터가 유효성 확인되거나 프로비저닝될 사용자, 개인, 또는 소비자일 수 있다. 상인(22)은 수용자의 일 예이고 제시자(21)가 트랜잭션하려고 시도할 당사자일 수 있다. 제시자(21)는 직접 모바일 전화기나 컴퓨터 장치와 같은 통신 기기를 사용하여 또는 상인(22)을 거쳐 인증 시스템에 액세스할 수 있다.

데이터 인증 시스템은 인증 프로그램을 실행시킬 수 있고, 신뢰 당사자 또는 신뢰 당사자에 의해 운용되는 콤포넌트들을 포함할 수 있다. 그 신뢰 당사자는 제시자의 신원을 인증하고, 제시자(21)와 관련된 데이터를 유효성 확인하거나, 프로비저닝하거나, 또는 업데이터하는 엔티티일 수 있다. 어떤 실시예들에서, 신뢰 당사자는 은행, 신용 카드 또는 직불 카드(debit card) 발행 은행, 또는 신용 카드 또는 직불 카드 서비스 조직(예: Visa)일 수 있다. 예시로, 그 은행은 이 제시자에 의해 사용되는 신용 카드의 발행 은행일 수 있다. 제시자(21)는 그 은행의 고객일 수 있다. 신뢰 당사자는 제시자(21)와의 확립된 관계를 가질 수 있고 따라서 제시자의 프로파일 데이터를 가질 수 있는데, 이때 그 제시자의 프로파일 데이터는 제시자(21)를 인증하는데 사용될 수 있는 것이다. 그 제시자 프로파일 데이터는 그 제시자의 사회 보장 번호(social security number), 생일, 계정 번호, 발송 주소(shipping address), 선호사항들(preferences) 등을 포함할 수도 있다.

신뢰 당사자는 액세스 제어 서버(ACS, 25)를 소유하거나 운용할 수도 있는데, 그 액세스 제어 서버는, 인증 서비스에 관하여 무엇보다도 인증 프로그램에 대한 액세스권을 제어하고, 요청되는 데이터 서비스를 수행하며, 그리고 수용자들에게 디지털 서명된 통지들을 제공하는 컴퓨터 장치일 수 있다. 다수의 신뢰 당사자들이 ACS를 공유할 수도 있고 또는 그것은 단일의 신뢰 당사자와 연관될 수도 있다. 대안적으로, 신뢰 당사자는 각각이 제시자들의 부분집합과 연관된 다수의 액세스 제어 서버들을 가질 수도 있다.

이 문서에서 사용되는 것으로서, "서버"는 전형적으로 강력한 컴퓨터 또는 컴퓨터들의 클러스터(cluster)이다. 예컨대, 서버는 대형 메인프레임(mainframe), 미니컴퓨터 클러스터, 또는 한 유닛으로서 기능하는 일군의 서버들일 수도 있다. 하나의 예에서, 서버는 웹 서버에 연결된 데이터베이스 서버일 수도 있다. 또한, 서버는, 하나 이상의 클라이언트 컴퓨터들 또는 휴대용 전자 기기들의 요청들을 서비스하는 단일의 컴퓨터로서 행동할 수 있다.

제시자 파일 데이터베이스(26)는 신뢰 당사자에 의해 관리되거나 신뢰 당사자와 연관된 데이터베이스일 수 있다. 그것은 인증 프로그램에 성공적으로 등록된 제시자들에 관련된 정보를 저장할 수 있다. 이러한 정보는, 이를테면 프로그램 신원 번호와 계정 번호와 같은 식별자들, 프로파일 데이터, 및 패스워드(password)들을 포함한다.

상호운용성 도메인은 또한 디렉토리 서버(27)를 포함한다. 어떤 실시예들에서 상호운용성 도메인은 신뢰 당사자 및 수용자 양자 모두에 의해 사용되는 콤포넌트들을 포함할 수도 있다. 디렉토리 서버(27)는 제시자가 데이터 인증 서비스를 활용할 수 있는지 여부를 결정할 수 있다. 어떤 경우들에서, 디렉토리 서버(27)는 Visa와 같은 서비스 조직에 의해 운용될 수 있다.

데이터 인증 서비스 시스템 내 제시자, 신뢰 당사자 및 수용자 간의 각 관계는 광범위한 가능 서비스들이 제공될 수 있게 해 준다. 이러한 서비스들의 예들은 다음을 포함한다: 신원 인증, 프로파일 유효성 확인, 프로파일 데이터 프로비저닝, 및 프로파일 데이터 업데이트. 프로파일 유효성 확인에 관한 하나의 구현예는 제시자의 주소를 유효성 확인하도록 동작하고 프로파일 데이터 업데이트에 관한 하나의 구현예는 제시자의 계정 정보를 업데이트하도록 동작한다.

그 인증 시스템은 제시자(21) 및 상인(22) 간의 지불 관련 트랜잭션에서 그리고 비지불에서 사용될 수 있다. 지불 관련 트랜잭션에서, 금융 계정(financial account)으로부터의 인출(debit) 및 외상(credit)의 승인과 같은 부가적인 동작들이 또한 수행될 수 있다. 발행자 승인 및 결제 시스템(issuer authorization and settlement system)과 같은 부가적인 시스템도 또한 사용될 수 있다.

이제 제시자 등록 프로세스가 기술될 수 있다. 하나의 실시예에서, 제시자(21)는 인증 프로그램에 참여하기 위해 신뢰 당사자 측에 등록한다. 성공적인 등록 시에, 그 신뢰 당사자는 제시자(21)에게 프로그램 신원 번호(또는 다른 별칭 식별자) 및 인증 패스워드, 토큰(token), 또는 다른 인증 요소를 제공하거나 할당할 수 있다. 인증 패스워드, 토큰, 또는 다른 인증 요소는 신뢰 당사자가 제시자(21)의 신원을 인증할 수 있게 해 주는데 왜냐하면 오직 신뢰 당사자 및 제시자(21)만이 그 패스워드, 토큰, 또는 다른 인증 요소를 알기 때문이다. 별칭 식별자 및/또는 인증 요소는 일정한 방식으로 통신 기기(예: 전화기)에 관련될 수도 있다. 예를 들어, 그 별칭 식별자는 전화 번호일 수도 있고 그 인증 요소는 그 전화기를 위한 SIM 카드 번호일 수도 있다.

프로그램 신원 번호는 인증 프로그램을 사용하기 위해 적절히 등록되는 제시자들을 식별하는 번호이다. 프로그램 신원 번호 또는 별칭 식별자는 대체로, 제시자(21)와 연관된 계정 번호와 같은 계정 식별자에 연계될 수도 있다.

프로그램 신원 번호는 임의의 적합한 유형의 번호를 포함할 수 있다. 바람직 한 프로그램 신원 번호는 랜덤 번호 또는 일련의 번호들 중에서 발행되는 번호를 포함할 수 있다. 하나의 실시예에서, 프로그램 신원 번호는 전화 번호일 수 있다. 이는, 제시자(21)가 그 전화 번호를 가진 전화를 사용하여 음성 또는 단문 메시지 서비스(SMS) 메시지에 의해 인증 시스템과 상호작용(interact)하고 있는 경우에 편리하다. 프로그램 신원 번호는 트랜잭션 수행시 제시자의 계정 번호를 대신하여 사용될 수도 있다.

본 발명의 실시예들에서, 신원 번호는 대체로 통신 기기 또는 통신 서비스 주소 또는 식별자 (예: 전화 번호, 이메일 주소 등)에 해당할 수 있다. 만약 전화 번호가 신원 번호로서 사용된다면, 시스템은 제시자의 전화 번호를 자동적으로 판별하기 위한 자동 번호 식별(automatic number identification; ANI) 서비스와 같은 서비스를 사용할 수도 있다. 대안적으로, 제시자(21)는 자신의 음성을 사용하여 또는 자신의 전화 번호를 자신의 전화에 수동으로 입력함으로써 자신의 전화 번호를 제공하도록 요구될 수도 있다.

본 발명의 실시예들에서, 신원 번호는 계정 식별자(예: 계정 번호) 또는 수용자 식별 번호의 적어도 일부와 같은 부가적 정보를 포함할 수도 있다. 예를 들어, 만약 수행되어지고 있는 트랜잭션이 신용 카드를 수반한다면, 그 부가적 정보는 신용 카드 발행자의 은행 식별 번호(Bank Identification Number; BIN)일 수 있고, 여기서 그 은행 식별 번호는 카드 계정 번호의 처음 6개의 숫자들에 대응된다. 이 부가적인 식별 정보는 주어진 제시자 신원 번호와 다수의 계정들 또는 수용자들이 연관되어질 수 있는 경우에 유용하다.

등록 프로세스 동안, 제시자(21)는 신뢰 당사자에게 등록 데이터, 인증 데이터, 및 프로파일 데이터를 제시할 수 있다. 이들 데이터 유형들은 제시자의 신원을 검증하는데 사용될 수 있어, 신뢰 당사자는 제시자(21)를 인증할 수 있고 만약 그 제시자가 인증 프로그램에 참여하고 있는지를 결정할 수 있다. 인증 데이터는 후속 트랜잭션 동안 그 제시자를 인증하기 위해 사용될 수 있다. 인증 데이터의 예들은 패스워드, 칩 카드(chip card) 내 고유 데이터, 생체인식 데이터(biometric data) 등을 포함할 수 있다. 다양한 인증 데이터 유형들이 사용될 수 있다는 것이 이해되어야 할 것이다. 만약 이러한 데이터가 이미 신뢰 당사자 측의 파일 상에 있지 않다면, 프로파일 데이터가 사용될 수 있어 후속 트랜잭션 동안 프로파일 데이터를 유효성 확인하고 그리고/또는 프로비저닝할 수 있다.

제시자 등록 프로세스는 다양한 방식들로 일어날 수 있다. 예를 들어, 그 등록 프로세스는 온라인으로, 직접 대면식의 상호작용(person-to-person interaction)으로, 전화 대화로, 또는 메일을 통해 일어날 수 있다. 바람직한 온라인 등록 프로세스에서, 제시자는 등록 웹 사이트를 방문하여 프로그램 신원 번호(또는 다른 별칭 식별자) 및 인증요소를 획득하기 위하여 적합한 정보를 제공할 수 있다. 어떤 실시예들에서, 등록은 또한 미등록된 제시자가 트랜잭션을 수행하려고 시도하는 첫 번째 경우에 자동적으로 개시될 수 있다.

이제 데이터 인증 프로그램과 연관된 데이터 인증 프로세스가 도 1에 대하여 기술될 수 있다. 데이터 인증 프로그램은 상인(22)과 같은 수용자가 제시자(21)를 인증하기를 원하는 다양한 상황들에서 사용될 수 있다. 예컨대, 비지불 예에서, 제 시자(21)는 소 기업 면허(small business license)를 위한 신청서를 채우기 위해 정부 웹 사이트(이는 수용자 웹 사이트의 일 예이다)를 방문할 수 있다. 다양한 정부 기관들은 그들의 웹 사이트들을 통하여 온라인 서비스를 제공한다. 전형적으로, 정부 기관은 제시자(21)에 의해 기입된 정보(예: 이름, 주소 등)를 확인하기(confirm)를 원한다. 본 발명의 실시예들은 또한 지불 예에 대해서도 유사한 식으로 운용될 수 있다. 예를 들어, 다음의 예는, 고객이 상인(22)을 호출하여 주문을 하고, 그리고 나서 자신의 신용 카드로 그 주문에 대하여 지불하려고 하는 경우에서, 데이터 인증 프로그램의 동작을 기술한다.

제시자(21)는 물품이나 서비스에 대한 주문을 하기 위해 상인(22)을 호출함으로써 트랜잭션을 개시한다. 다른 실시예들에서, 제시자(21)는 SMS 메시지를 이용하여, 인터넷을 통해 웹 브라우저 또는 이메일을 이용하여, 기타 등등을 이용하여 상인(22)과 상호작용할 수 있다. 부가적으로, 고객 및 상인은 대면식으로 상호작용할 수 있다.

주문을 한 후에, 제시자(21)는, 셀룰러 전화 번호와 같은 신원 번호를, 될 수 있는 한 부가적 식별 정보 이를테면 BIN 및/또는 부가적 식별자로 늘려질 수 있는 신원 번호를, 상인(22)에게 제공한다. 이 정보는 제시자(21)의 계정 번호 대신에 상인(22)에게 제공될 수 있다. 셀룰러 전화 번호와 같은 신원 번호 또는 그 신원 번호의 일부들은 또한, 제시자(21)에 의해 수동적으로 제공되는 것보다는 오히려 ANI와 같은 시스템을 사용하여 자동적으로 판별될 수 있다.

그 신원 번호를 수신한 후에, 상인(22)은 그것을 데이터 인증 시스템에 기입 한다 (제시자(21)는 그 인증 시스템에 직접 그것을 제공하지 않는다는 것을 가정함). 상인(22)은 웹 페이지 인터페이스(23)의 이용을 통해 또는 어떤 다른 수단들을 통해 그 인증 시스템과 인터페이싱(interfacing)할 수도 있다. 예컨대, 상인(22)은 신원 번호를 웹 페이지 인터페이스(23)에 기입할 수도 있다. 다른 실시예들에서 제시자(21)는 웹 페이지 인터페이스(23)를 통하여 또는 어떤 다른 인터페이스를 통하여 그 시스템에 직접 그 신원 번호를 기입할 수 있다.

신원 번호가 웹 페이지 인터페이스(23)에 의해 수신된 후에, 발행자 룩업 시스템(24)은 그 신원 번호를 수신하여 그 신원 번호와 연관된 발행자를 판별한다. 일단 관련 발행자가 판별되면, 발행자 룩업 시스템(24)은 그 신원 번호를 그 발행자에게 전자적으로 송신한다. 그 발행자는, 그 신원 번호를 계정 번호로 변환하기 위해 사용되는 제시자 파일 데이터베이스(26)를 유지한다. 그러면 그 계정 번호 및 그 신원 번호는 발행자 룩업 시스템(24)에 의해 상인 플러그-인(MPI, 28)로 포워딩된다.

다음으로, 상인 플러그-인(MPI, 28)은 제시자(21)가 데이터 인증 프로그램에 참여하고 있는지 여부를 알도록 체크한다. 하나의 구현예에서, 2-상(two phase) 프로세스는 제시자(21)가 그 인증 프로그램에 참여하는지 여부를 알도록 체크하기 위해 사용된다. 그 2-상 프로세스에서, 디렉토리 서버(DS, 27) 및 액세스 제어 서버(ACS, 25)가 질의를 받는다(queried). 디렉토리 서버(27)는 신원 번호를 수신하여 그 신원 번호와 연관된 발행자가 그 데이터 인증 프로그램에 참여하고 있는지 여부를 판별한다. 제시자(21)는 그 발행자가 제시자(21)의 신원을 인증하여 그 제 시자에 관련된 데이터 서비스를 제공하려고 한다면 그 데이터 인증 프로그램을 사용할 수 있다. 그 신원 번호를 수신한 후에, 액세스 제어 서버(ACS, 25)는, 제시자(21)가 그 인증 프로그램에 등록되어 있는지 그리고 그 신원 번호와 연관된 기기 유형(예컨대 셀룰러 전화기)이 그 인증 시스템에 의해 지원되는지 여부를 판별한다.

만약 그 발행자가 그 데이터 인증 프로그램에 참여하지 않는다면, 또는 제시자(21)가 그 데이터 인증 프로그램에 등록되어 있지 않다면, 상인(22)은 트랜잭션을 종결시킬지 아니면 어떤 다른 방식으로 진행할지를 결정할 수 있다. 만약 그 발행자가 그 인증 프로그램에 참여하지만 제시자(21)가 등록되어 있지 않으면, 그러면 제시자(21)는 그 데이터 인증 프로그램에의 등록 기회를 제공받을 수도 있다.

그 발행자 및 제시자(21)가 그 데이터 인증 프로그램에 참여하고 있다면, 그리고 그 신원 번호와 연관된 기기가 프로그램에서 사용될 수 있다면, 그러면 액세스 제어 서버(ACS, 25)는 원격 인증 요청 메시지를 생성하는데, 그 메시지는 상인 플러그-인(MPI, 28)으로 송신된다 (예: 만약 MPI가 매입자 또는 다른 신뢰 당사자에 의해 호스팅(hosting)되는 경우).

그러면 상인(MPI, 28)은 챌린지 인터페이스(29)를 거쳐 제시자(21)에게 인증 챌린지(challenge)를 발행한다. 이를 행하기 위해, 그것은 제시자의 지불 카드 번호를 그 신원 번호와 연관시킨다. 그 신원 번호가 셀룰러 전화기에 대응된다면, 전화 번호가 그 신원 번호로부터 추출되고 제시자의 전화기로 인증 챌린지를 송신하도록 사용된다. 비구조적 부가 서비스 데이터(USSD) 프로토콜이, 챌린지 인터페이 스 모듈(29)을 사용하여 고객의 셀룰러 전화기로 인증 챌린지를 송신하기 위해 사용될 수 있다. 관련 기술분야에서 숙련된 자들은 다른 프로토콜들 또는 통신 방법들이 사용될 수도 있다는 것을 인식할 것이다. 예를 들어, 그 인증 챌린지는 SMS 메시지, 사전녹음된 자동 전화 호출, 또는 대화식 채팅 메시지일 수도 있다.

제시자(21)는, 그 인증 챌린지를 수신한 경우에, 기결정된 인증 데이터로 응답한다. 예를 들어, 만약 그 인증 챌린지가 SMS 메시지를 거쳐 발행되면, 제시자(21)는 패스워드를 포함하는 응답 SMS 메시지를 송신할 수도 있다. 만약 그 인증 챌린지가 전화 호출에 의한 것이면, 제시자(21)는 전화기 키패드를 사용하거나 또는 자신의 음성을 사용하여 패스워드를 제공할 수도 있다. 대안적으로 다른 인증 데이터 유형들 이를테면 생체인식 데이터, 칩 카드 데이터 등이 사용될 수 있다.

일단 상인 플러그-인(MPI, 28)이 제시자의 인증 데이터를 수신하면, 트랜잭션 데이터(예: 카드 계정 번호 및 유효기간 데이터(expiration data)를 포함하는 카드 데이터)가 첨부되어 발행자의 액세스 제어 서버(ACS, 25)로 송신된다. 발행자의 액세스 제어 서버(ACS, 25)는 그 인증 데이터를 유효성 확인하고 그 유효성 확인의 결과를 상인 플러그-인(MPI, 28)으로 보고한다. 그러면 상인 플러그-인(MPI, 28)은, 예컨대 웹 페이지 인터페이스(23)를 통하여, 그 검증 결과에 관하여 상인(22)에게 통보한다. 만약 그 검증이 성공적이라면, 상인(22)은 제시자의 계정 식별자(예: 계정 번호) 또는 그것의 일부를 제공받을 수 있다. 그러면 발행자는 트랜잭션 상세에 관하여 통보받을 수 있고 그 트랜잭션은 완료되게 진행될 수 있다.

그 트랜잭션이 완료되면, 메시지들은 그 신원 번호에 대응되는 제시자 기기 (예: 전화기) 및 상인(22)에게, 웹 인터페이스(23)를 사용하여 송신될 수도 있다. 예를 들어, 제시자(21)가 적절히 인증되었고 그 트랜잭션이 성공적으로 완료되었음을 나타내는 메시지가, 제시자의 전화 번호를 사용하여 제시자의 전화기로 송신될 수도 있다. 도 1에서 묘사된 모든 메시지들은 보안 수준을 높이기 위해 암호화될 수 있다는 점이 이해되어야 할 것이다.

본 발명의 실시예들은 또한 제시자(21) 및 상인(22)이 직접 친히(in person) 트랜잭션하고 있도록 구현될 수 있다. 상인(22)은, 제시자(21)보다는 오히려 상인(22)과 연관된 신원 번호를 제공함으로써 시스템과 상호작용할 수 있다. 상인(22)은 또한 제시자(21)의 신원 번호를 그 시스템에게 제공할 수 있다. 제시자(21)는 자기 자신의 기기 상에서 인증 챌린지를 수신할 수 있고 상기에서 기술된 바와 같이 인증 데이터로 응답할 수 있다. 또 하나의 실시예에서 제시자(21)는 상인의 신원 번호 및 그 트랜잭션에 대한 지불액을 제공함으로써 그 시스템과 상호작용할 수 있다.

본 발명의 실시예들에서, 제시자(21)는 다수의 지불 카드들(예: 둘 이상의 신용 카드들)을 가질 수 있다는 점을 유념하여야 한다. 하나의 실시예에서, 제시자(21)가 무선 전화기와 같은 통신 기기를 사용하고 있다면, 제시자(21)는 선택할 수 있는 주 계정 번호(primary account number; PAN)들의 리스트를 제시받을 수 있다. 제시자의 현재 전화 번호는 디폴트 주 계정 번호에 대응되어, 제시자(21)가 그 전화 번호로 트랜잭션을 수행할 때, 결국 그 디폴트 주 계정 번호는 그 트랜잭션을 수행하는데 사용될 수 있다. 또 하나의 실시예에서, 주 계정 번호들의 리스트가 제 시자(21)에게 제시될 수도 있고 제시자(21)는 트랜잭션을 수행하기 전에 그 트랜잭션에서 사용될 계정 번호를 선택한다. 이 경우에, 그 전화 번호와 연관된 어떠한 디폴트 계정 번호도 존재하지 않을 수도 있다. 다른 또 하나의 실시예에서, 그 리스트에서의 각각의 주 계정 번호와 연관된 다른 별칭 식별자가 있을 수 있다. 예를 들어, 별칭 식별자들은 단순히 3개의 서로 다른 주 계정 번호들에 대하여, "card1", "card2", 및 "card3" 일 수도 있다.

도 2는 본 발명의 또 하나의 실시예에 따른 또 하나의 시스템에 관한 블록 다이어그램을 보여준다. 메시지 흐름들 또한 보여진다. 도 2의 콤포넌트들 중 일부는 도 1의 콤포넌트들의 일부와 유사하다. 도 2는 부가적으로 전화 회사(Telco, 58) 인터페이스 - 이는 차례로 가상 카드소지자 리디렉트 모듈(virtual cardholder redirect module, 56)에 연결된다 - 에 연결된 인터페이스 요소(60) 뿐만 아니라 상인의 콜 센터(42)와 통신하는 모바일 전화기(40)를 보여주고 있다. 발행자(12) 및 매입자(14)도 또한 도 2에 명확하게 보여진다.

이 실시예에서, 제시자(21)는 신용 카드(또는 어떤 다른 지불 기기)를 사용하여 상인(22)과의 구매 트랜잭션을 개시한다. 비록 신용 카드 트랜잭션이 상세하게 묘사되어 있지만, 트랜잭션은 대안적으로 가액 저장 카드(stored value card), 직불 카드, 비접촉식(contactless) 전화기, 스마트 카드 등으로 수행될 수 있다.

제시자(21)는 자신의 모바일 전화기(40)를 사용하여 상인의 콜 센터(42)에 전화한다 (단계 1). 그러면 제시자(21)는, 모바일 전화기(40)와 연관된 전화 번호의 일부 또는 전체를 포함할 수도 있는 신원 번호와 같은 별칭 식별자를 제공한다 (예: 음성으로, 전화 번호를 전화기(40)에 입력함으로써 등등). 부가적인 식별자 정보는 제시자(21)가 소지한 신용 카드의 신용 카드 번호와 연관된 BIN 등을 포함할 수도 있다. 또 하나의 별칭 식별자 유형은 사용되어지고 있는 특정 신용 카드에 대해 제시자(21)에 의해 지정된 별명(nickname) 또는 다른 별칭일 수도 있다. 그 경우 상인(22)은 별칭 식별자들 중 하나 이상을 그 상인의 웹 페이지 인터페이스(23)에 기입할 수 있다 (단계 2).

상인 플러그-인(MPI, 28)은 그 별칭 식별자를 수신하고, 그것은 검증 요청 메시지(VE Req(m)) 내에서 디렉토리 서버(DS, 48)에게 송신된다 (단계 3). 그 검증 요청 메시지를 수신한 후에, 디렉토리 서버(48)는, 인증이 제시자(21)에 대하여 이용가능한지 여부를 판별하기 위해 액세스 제어 서버(25)에 질의한다 (단계 3). 이 예에서, 검증 요청 메시지(VE Req(m))는 모바일 전화기(40)의 전화 번호와 같은 별칭 식별자를 포함한다.

액세스 제어 서버(ACS, 25)는, 검증 응답 (VE Res (m)) 메시지(단계 4)를 상인 플러그-인(MPI, 28)에게, 그 메시지를 디렉토리 서버(48)를 통해 전함으로써, 송신하여 응답한다. 그 검증 응답 메시지를 수신한 후에, 상인 플러그-인(MPI, 28)은 디렉토리 서버(DS, 48)를 통해 액세스 제어 서버(ACS, 25)에게 지불 인증 요청 메시지(PA Req (m))를 송신한다 (단계 5). 그러면 액세스 제어 서버(ACS, 25)는 모바일 인증 요청 메시지를 생성하고 (단계 6), 이는 가상 카드소지자 리디렉트 모듈(56)을 거쳐 전화 회사(Telco) 인터페이스(58)로 전해진다. 그렇게 하기 위해, 디렉토리 서버(DS, 48)는 제시자의 신용 카드 번호를 자신의 전화 번호와 재연관시 키고(re-associate), Telco 인터페이스(58)를 거쳐 제시자(21)에게 액세스가능한 인터페이스 요소(60)와 접촉한다 (단계 6 및 단계 7). 인터페이스 요소(60)는 모바일 전화기(40) 상의 사용자 인터페이스를 포함할 수 있고, 또는 그것은 모바일 전화기(40)와 다른 기기 상의 사용자 인터페이스를 포함할 수 있다.

그러면 그 인증 요청 메시지는 기결정된 패스워드 또는 다른 인증 데이터로 응답할 것을 제시자(21)에게 촉구하는 것으로서 제시자(21)에게 송신된다 (단계 7). 단계(8)에서, 사용되어지고 있는 신용 카드와 연관된 카드 번호가 그 인증 데이터에 재부착되고 보충 응답 메시지가 Telco 인터페이스(58)를 거쳐 발행자의 액세스 제어 서버(ACS, 25)로 송신된다. 단계(9)에서, 제시자(21)로부터의 패스워드를 포함하는 인증 응답 메시지를 수신한 후에, 발행자(12)는 그 패스워드를 유효성 확인한다. 발행자(12)가 그 패스워드를 유효성 확인하면, 그것은 상인 플러그-인(MPI, 28)에게 지불 인증 응답(PA Res(m)) 메시지를 송신한다 (단계 9).

어떤 실시예들에서, 지불 인증 응답(PA Res(m)) 메시지는 제시자(21)에 관한 부가적 정보(예: 발송 주소, 이메일과 같은 연락 정보, 선호사항들 등)를 포함할 수도 있다. 예를 들어, 제시자(21)의 발송 주소는 발행자의 ACS(25)로부터 상인 플러그-인(MPI, 28)로 송신될 수도 있다. 어떤 실시예들에서, 상인(22)은 유리하게도 이러한 부가적 정보를 보유해야 할 필요가 없다. 따라서, 발행자(12)에 의해 이전에 수집되었던 어떠한 적합한 정보도 제시자(21)에 의해 트랜잭션이 개시된 후에 상인(22)에게 송신될 수도 있다.

단계(10)에서, 상인(22)의 종업원은 웹 페이지 인터페이스(23)를 사용하여 인증 프로세스의 결과에 관하여 통보받는다. 단계(11)에서, 응답 메시지(11)가 상인 플러그-인(MPI, 28)로부터 상인의 매입자(14)로 송신된다. 매입자(30)는 Telco 인터페이스(58)를 거쳐 제시자(21)에게 그리고 웹 인터페이스(23)를 거쳐 상인(22)에게 모두 메시지들을 송신함으로써 (단계 12) 트랜잭션을 완료한다.

대안적인 실시예에서, 제시자(21)는 상인의 콜 센터(42)를 통할 필요 없이 웹 페이지 인터페이스(23)를 거쳐 상인의 웹사이트와 상호작용할 수 있다. 제시자(21)는 "지불 페이지(payment page)"로 자신의 신원 번호를 기입할 수 있고 후속하여 인터페이스 요소(60) 상에 인증 챌린지를 수신할 것이다.

도 2에서 보여진 프로세스 흐름은 다수의 이점들을 가진다. 예를 들어, 도 2에서, 비록 상인(22)에 제시자(21)가 사용하고 있는 신용 카드의 실제 계정 번호를 전혀 알거나 소지하고 있지 않을지라도, 제시자(21)는 빠르고 효율적인 방식으로 적절하게 인증된다. 이는 제시자(21)에게 부가적인 보안을 제공하는데, 왜냐하면 어떤 상인 또는 상인의 종업원이 제시자의 지불 계정 번호를 부정하게 사용할 수 있기 때문이다.

본 발명의 또 하나의 실시예에 따른 시스템에 관한 또 하나의 블록 다이어그램이 도 3에 보여진다. 그 시스템은 제시자 도메인에 있는 모바일 전화기(72)를 포함한다. 상인 플러그-인 인터페이스(74)는 매입자 도메인에 있으며, 그리고 매입자 도메인에서 트랜잭션 개시 콤포넌트(84)와 통신하고 있다. 디렉토리 서버(76) 및 보고 서버(78)가 상호운용성 도메인에 있고, 액세스 제어 서버(80) 및 등록 서버(82)가 발행자 도메인에 있다. 모바일 인증 콤포넌트(86) 및 모바일 등록 콤포넌 트(88)는 이 실시예에서 매입자 도메인, 상호 운용성 도메인, 및 제시자 도메인에서 작동될 수 있다.

대안적으로 모바일 전화기(72)는 데이터를 송신 및/또는 수신할 수 있는 임의의 적합한 통신 기기(예: 고정식 전화기, 인터넷 상의 PC 등)일 수 있다. 상기에서 언급한 바와 같이, 소비자(또는 제시자)는 모바일 전화 번호, 모바일 전화 번호와 검사 숫자(check digit)(들)의 합, 또는 어떤 다른 적합한 별칭 식별자에 기반하여 트랜잭션을 개시할 수 있다. 별칭 식별자는 지불 계정 번호를 위한 대용물로서 사용될 수 있다. 소비자는 또한 트랜잭션을 개시하기 위해 그리고/또는 트랜잭션을 인증하기 위해 자신의 모바일 전화기 또는 모바일 번호/별칭을 사용할 수 있다. 소비자는 또한 인증 프로그램에 등록하기 위해 자신의 전화 번호를 사용할 수도 있다.

제시자의 요청 시에, 트랜잭션 개시 콤포넌트(84)는 상인이 지불 프로세스를 개시할 수 있게 해 줄 수 있다. 트랜잭션 개시 콤포넌트(84)는 하드웨어 및 소프트웨어의 임의의 적합한 조합 형태일 수도 있다. 어떤 경우들에서, 그것은 상인에 의해 운용되는 하드웨어에 (예: POS 단말에 또는 POS 단말과 연결되어) 존재할 수도 있다. 트랜잭션 개시 콤포넌트(84)는 인터넷 환경에서 웹 페이지가 표준 MPI와 통신하는 것과 같은 방식으로 상인 플러그-인(MPI, 74)와 통신할 수 있다.

선행 실시예들에서처럼, 유리한 점으로, 트랜잭션이 개시될 때 제시자의 지불 카드 번호가 상인에게 제공되지 않는다. 대신에 그 트랜잭션은, 모바일 트랜잭션 표시자(indicator)에 관하여, 제시자의 전화 번호 / 별칭, 또는 다른 식별자에 기반하여 개시된다.

트랜잭션 개시 콤포넌트(84)는 어떤 범위의 트랜잭션 개시 시나리오들을 용이하게 할 수 있다. 그 시나리오들은, 소비자의 모바일 번호가 상인 플러그-인(MPI, 74)에게 자동적으로 전해질 수 있게 하는 시나리오들, 그리고 소비자의 모바일 번호가 수동으로 입력되어질 수 있게 하는 시나리오들로 나누어질 수 있다. 상기에서 언급한 바와 같이, 모바일 전화 번호는 IVR, USSD, SMS, 또는 WAP을 이용하여 상인 플러그-인(MPI, 74)에게 자동적으로 전해질 수도 있다. 대안적으로, 그 전화 번호는 시스템에 수동으로 입력될 수도 있다. 예를 들어, 그것은, PC에 있는 콜 센터 에이전트, 수용자 기기로서 자신의 모바일 전화기를 사용하는 모바일 상인 등에 의해, 인증 시스템에 수동으로 입력될 수도 있다. 트랜잭션 개시 콤포넌트(84)는 또한 트랜잭션의 상태에 관해 제시자에게 통보하기 위해 상인에게 백워드 통신 채널(backwards communication channel)을 제공할 수 있다.

상인 플러그-인(MPI, 74)은 다수의 기능들을 수행할 수 있다. 예를 들어, 그것은, 카드 번호를 사용하지 않고 모바일 번호에 기반하여 트랜잭션을 처리하는 것을 용이하게 할 수 있다. 그것은 또한 검증 메시지에 모바일 채널/기기 식별자를 포함시키는 것을 용이하게 할 수 있고, 그에 의해 발행자로 하여금 모바일 채널을 거쳐 트랜잭션을 인증할 것을 촉구한다. 그것은 또한 새로운 제시자들을 그들 각자의 발행자들 측에 온라인 등록하는 것을 가능하게 하기 위해 상인에게 백워드 통신을 제공할 수 있다.

디렉토리 서버(DS, 76)도 또한 다수의 기능들을 제공한다. 그것은 모바일 번 호 및/또는 다른 별칭 식별자를 BIN에 맵핑할 수 있고 인증 요청이 관련 발행자에게 라우팅될 수 있게 해 줄 수 있다. 모바일 번호 및/또는 별칭 식별자 및/또는 BIN 번호는, 만약 소비자가 자신의 카드, 전화 번호 또는 별칭 식별자를 변경하기를 원한다면, 액세스 제어 서버(ACS, 80)로부터 업데이트될 수 있다 (그리고 그 역도 가능함). 또한, 트랜잭션 개시 콤포넌트(84) 및 상인 플러그-인(MPI, 74)과 관련하여, 디렉토리 서버(DS, 76)는 새로운 제시자들을 관련 발행자들 측에 온라인 등록하는 것을 용이하게 할 수 있다.

보고 서버(78)는 보고서(report)를 제공한다. 그것은 또한 모바일 번호 및/또는 별칭 식별자를 기록할 수 있다.

액세스 제어 서버(ACS, 80)는 다수의 기능들을 수행할 수 있다. 예를 들어, 식별된 트랜잭션의 수신 시에, 그것은 모바일 인증 콤포넌트(86)를 거쳐 모바일 전화기(72)에게 인증 요청 메시지를 송신하는 것을 개시할 수 있다. 긍정적인 인증 응답 메시지를 수신한 경우, 액세스 제어 서버(ACS, 80)는 제시자의 모바일 전화 번호를 그 제시자의 등록된 PAN으로 변환할 수 있다.

모바일 인증 콤포넌트(87)는 트랜잭션 인증을 위해 제시자 및 액세스 제어 서버(ACS, 80) 간의 양방향 모바일 채널을 제공한다. 그 양방향 채널은 제시자의 모바일 전화기(72) 상에 로딩되는 클라이언트 어플리케이션 또는 IVR이나 WAP을 포함할 수도 있다.

등록 서버(82)는 등록 기능을 제공하고 모바일 전화 번호 및/또는 이러한 데이터를 위한 별칭 필드(field)를 포함한다.

모바일 등록 콤포넌트(88)는 제시자와 등록 서버(82) 간의 양방향 모바일 채널을 제공한다. 이 채널은 인증 프로그램에 제시자를 등록하기 위해 사용되고, 제시자의 등록된 모바일 전화기(72)가 정확한지를 보증하기 위해 사용된다. 예로 들 수 있는 모바일 채널들은 제시자의 모바일 전화기 상에 로딩되는 클라이언트 어플리케이션 또는 IVR이나 WAP을 포함할 수도 있다. 그 채널은 모바일 인증 콤포넌트(86)와 동일하거나 또는 그에 기반할 수도 있다.

도 4는 지불 트랜잭션을 개시하기에 앞서 제시자가 데이터 인증 프로그램에 등록하는 프로세스 흐름을 보여주고 있다. 이 예에서, 제시자는 모바일 채널을 통하여 특정 계정을 등록할 수 있다.

도 4를 참조하면, 제시자는 자신의 모바일 전화기(72)를 이용하여 발행자의 인증 프로그램에 발행자와 연관된 계정을 등록한다. 이를 행하기 위해, 모바일 전화기(72)는 발행자의 모바일 등록 콤포넌트(88)와 통신할 수도 있다 (단계 101). 모바일 등록 콤포넌트(88)는 들어오는 등록 요청을 번역하고 그것을 발행자의 등록 서버(82)로 포워딩한다 (단계 102). 발행자 등록 서버(82)는 모바일 전화기(72)에 관한 MSISDN이 모바일 채널을 통해 전해졌는지를 알도록 체크한다 (단계 103).

만약 모바일 전화기(72)에 관한 MSISDN이 모바일 채널을 거쳐 제공된다면, 그러면 발행자의 등록 서버(82)는 그 제시자로부터 추가적인 계정 데이터를 요청하고 계정 데이터 요청을 모바일 등록 콤포넌트(88)로 송신한다 (단계 104). 모바일 등록 콤포넌트(88)는 그 모바일 채널 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 105). 모바일 전화 기(72)를 사용하여, 그때 그 제시자는 모바일 등록 콤포넌트(88)에게 그 계정 데이터를 되돌려 준다 (단계(106)). 그러면 모바일 등록 콤포넌트(88)는 그 계정 데이터를 번역하고 그것을 발행자의 등록 서버(82)로 포워딩한다 (단계 107).

대안 흐름 A에서 보여지는 바와 같이, 만약 MSISDN이 모바일 채널에 의해 제공되지 않으면, 발행자의 등록 서버(82)는 모바일 등록 콤포넌트(88)에 요청을 송신함으로써 그 제시자로부터의 MSISDN을 포함한 추가적인 계정 데이터를 요청한다 (단계 A-1). 그리고 나서 모바일 등록 콤포넌트(88)는 그 모바일 채널 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 A-2). 모바일 전화기(72)를 사용하여, 그때 그 제시자는 모바일 등록 콤포넌트(88)에게 그 계정 데이터 및 MSISDN을 반환하여 송신해 준다 (단계 A-3). 그러면 모바일 등록 콤포넌트(88)는 그 계정 데이터 및 MSISDN을 번역하고 그것을 발행자의 등록 서버(82)에 포워딩한다 (단계 A-4). 이 정보가 수신된 후에, 발행자의 등록 서버(82)는 모바일 등록 콤포넌트(88)로 등록 확인 요청을 송신한다 (단계 A-5). 모바일 등록 콤포넌트(88)는 메시징 모바일 채널(예: SMS, USSD) 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 A-6). 그 제시자는 확인 요청을 수신하고, 그것을 수락하며 그것을 모바일 등록 콤포넌트(88)로 되돌려 준다 (단계 A-7). 모바일 등록 콤포넌트(88)는 확인 응답을 번역하고 그것을 발행자의 등록 서버(82)로 포워딩한다 (단계 A-8). 그러면 발행자의 등록 서버(82)는 계류 중인 제시자의 등록 상태를 업데이트한다 (단계 A-9).

어떤 포인트에서, 등록 서버(82)는 제시자의 등록 상태의 유효성을 체크한다 (단계 108).

만약 제시자의 등록이 수락가능하다면, 그러면 발행자의 등록 서버(82)는 모바일 등록 콤포넌트(88)로 패스워드 생성 요청을 송신할 수 있다 (단계 109). 모바일 등록 콤포넌트(88)는 모바일 채널 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 110). 모바일 전화기(72)를 사용하여, 제시자는 패스워드를 제공하고 그것을 모바일 등록 콤포넌트(88)에게 되돌려준다 (단계 111). 모바일 등록 콤포넌트(88)는 그 패스워드를 번역하고 그것을 발행자의 등록 서버(82)로 포워딩한다 (단계 112). 그러면 발행자의 등록 서버(82)는 모바일 등록 콤포넌트(88)로 등록 통지를 송신한다 (단계 113). 모바일 등록 콤포넌트(88)는 모바일 채널 및 제시자의 기기 성능에 따라 그 통지를 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 114). 그러면 발행자의 등록 서버(82)는 제시자의 계정 데이터의 일부로써 액세스 제어 서버(80)를 업데이트한다 (단계 115).

대안 흐름 B에서, 제시자의 등록이 실패하였다. 발행자의 등록 서버(82)는 등록 통지 오류(error)를 모바일 등록 콤포넌트(88)로 송신한다 (단계 B-1). 모바일 등록 콤포넌트(88)는 모바일 채널 및 제시자의 기기 성능에 따라 그 오류 메시지를 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 B-2).

대안 흐름 C는 발행자 생성 패스워드(issuer generated password)에 관련된다. 이 프로세스 흐름에서, 발행자의 등록 서버(82)는 (예: 제시자에 의한 입력 없 이) 고유의 패스워드를 생성한다 (단계 C-1). 발행자의 등록 서버(82)는 생성된 패스워드를 모바일 등록 콤포넌트(88)로 송신한다 (단계 C-2). 모바일 등록 콤포넌트(88)는 모바일 채널 및 제시자의 기기 성능에 따라 그 메시지를 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 C-3).

도 5는 모바일 채널 상에서의 지불 트랜잭션 동안의 등록을 위한 흐름도를 보여준다. 도 5를 참조하면, 제시자는 트랜잭션 개시 콤포넌트(84)를 거쳐 지불 트랜잭션을 개시한다 (단계 201). 트랜잭션 개시 콤포넌트(84)는 트랜잭션 상세를 번역하여 그것을 상인 플러그-인(MPI, 74)로 포워딩한다 (단계 202). 그리고 나서, 초기 지불 트랜잭션 절차 - 이는 도 6에 보여지고 아래에서 더 상세하게 기술된다 - 가 실행된다. 상인 플러그-인(MPI, 74)은 반환된 제시자의 등록 상태를 체크한다. 만약 그 제시자가 등록되어 있으면, 그러면 흐름은 지불 인증 프로세스의 실행에 관련하여 단계 218로 진행한다 - 이는 도 7에 보여지고 아래에서 더 상세하게 기술된다.

만약 그 제시자가 등록되어 있지 않으면, 상인 플러그-인(MPI, 74)은 트랜잭션 개시 콤포넌트(84)에게 BIN 정보에 대한 요청을 송신한다 (단계 204). 트랜잭션 개시 콤포넌트(84)는 모바일 채널 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 205). 모바일 전화기(72)를 사용하여, 제시자는 요청된 BIN 정보를 제공하고 그것을 트랜잭션 개시 콤포넌트(84)에게 되돌려 준다 (단계 206). 트랜잭션 개시 콤포넌트(84)는 요청된 계정 데이터를 번역하고 그것을 상인 플러그-인(MPI, 74)로 포워딩한다 (단계 207). 그 러면 상인 플러그-인(MPI, 74)은 수집된 계정 데이터를 디렉토리 서버(76)로 전함으로써 발행자의 참여 상태를 요청한다 (단계 208). 이 정보를 수신한 후에, 디렉토리 서버(76)는 발행자의 등록 상태를 체크한다 (단계 209). 그리고 나서 디렉토리 서버(76)는 상인 플러그-인(MPI, 74)로 발행자의 등록 상태를 되돌려 주도록 송신한다 (단계 210). 상인 플러그-인(MPI, 74)은 발행자의 등록 상태를 체크한다 (단계 211).

만약 발행자가 인증 프로그램에 참여한다면, 상인 플러그-인(MPI, 74)은 제시자 등록 요청을 디렉토리 서버(76)로 라우팅한다 (단계 212). 그러면 BIN 및 전화 번호는 그 제시자를 적절히 등록하기 위해 발행자에게 전해진다. 그때 디렉토리 서버(76)는 그 제시자 등록 요청을 액세스 제어 서버(ACS, 80)로 라우팅한다 (단계 213). 액세스 제어 서버(ACS, 80)는 그 제시자 등록 요청을 발행자의 등록 서버(82)로 라우팅한다 (단계 214). 그러면 발행자의 등록 서버(82)는 제시자 등록 요청을 모바일 등록 콤포넌트(58)로 송신한다 (단계 215). 모바일 등록 콤포넌트(88)는 모바일 채널 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 216). 그러면 도 4의 제시자 등록 프로세스가 실행될 수 있다 (단계 217). 성공적인 제시자 등록 시에, 지불 트랜잭션은 도 7의 프로세스에 따라 인증된다 - 이는 아래에서 더 상세하게 기술된다 - (단계 218).

발행자가 인증 프로그램에 참여하고 있지 않은 경우에, 상인 플러그-인(MPI, 74)은 "발행자 미등록(issuer not registered)" 유형의 오류 메시지를 트랜잭션 개 시 콤포넌트(84)로 송신한다. 트랜잭션 개시 콤포넌트(84)는 모바일 채널 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 2A-1). 이 경우에서, 인증은 수행되지 않고 지불 트랜잭션이 폐기될 수 있다.

도 6은 제시자가 지불 트랜잭션을 개시하는 프로세스에 대한 흐름도를 보여준다. 그 프로세스는 제시자가 모바일 채널 상에서 상인/매입자와의 지불 트랜잭션을 개시할 것을 결정할 때 시작된다. 그것은 지불 트랜잭션이 모바일 채널 상에서 성공적으로 개시될 때 (아직 인증되지 않음) 끝날 수 있다. 이 프로세스는 또한 예외(exception)들 및 오류들이 고려될 수 있는 다른 경로들을 가진다.

도 6을 참조하면, 제시자는 트랜잭션 개시 콤포넌트(84)를 거쳐 자신의 모바일 전화기(72)를 사용하여 지불 트랜잭션을 개시한다 (단계 301). 트랜잭션 개시 콤포넌트(84)는 지불 개시 요청을 번역하고 그것을 상인 플러그-인(MPI)로 포워딩한다 (단계 302). 상인 플러그-인(MPI)은 MSISDN(모바일 전화 번호)가 모바일 채널을 통해 전해졌는지를 검증한다 (단계 303). 그리고 나서 상인 플러그-인(MPI, 64)은 등록 검증 요청(VE req) 메시지를 디렉토리 서버(76)로 송신한다 (단계 304). 이 메시지를 수신한 후에, 디렉토리 서버(76)는 제시자의 등록 상태에 대하여 액세스 제어 서버(ACS, 76)에 질의한다 (단계 305). 액세스 제어 서버(ACS, 76)는 디렉토리 서버(DS, 76)에게 제시자 등록 상태를 반환한다 (단계 306). 디렉토리 서버(76)는 상인 플러그-인(MPI, 74)에게 등록 검증 응답(VE res) 메시지를 반환한다 (단계 307). 등록 응답 상태를 수신한 후에, 제시자는 도 5에 묘사된 등록 프로세 스를 시작할 수 있다 (지불 트랜잭션 동안의 등록).

만약 MSISDN이 모바일 채널에 의해 제공되지 않는다면, 그러면 상인 플러그-인(MPI, 74)은 트랜잭션 개시 콤포넌트(84)를 통해 제시자의 MSISDN을 요청한다 (단계 3A-1). 트랜잭션 개시 콤포넌트(84)는 모바일 채널 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 3A-2). 그러면 제시자는 트랜잭션 개시 콤포넌트(84)로 MSISDN을 되돌려 주도록 송신한다 (단계 3A-3). 트랜잭션 개시 콤포넌트(84)는 MSISDN을 번역하고 그것을 상인 플러그-인(MPI, 74)로 포워딩한다 (단계 3A-4).

도 7은 제시자가 인증이 필요한 지불 트랜잭션을 개시한 프로세스를 보여주고 있다. 그 프로세스는 제시자가 지불 트랜잭션을 개시한 때 시작하고 그 트랜잭션을 종료하기 위해 인증될 준비가 되어 있다. 인증 이후에, 승인이 일어날 수 있다.

도 7을 참조하면, 상인 플러그-인(MPI, 74)은 액세스 제어 서버(80)로 지불자 인증 요청(payer authentication request, PA req) 메시지를 송신한다 (단계 401). 그러면 액세스 제어 서버(80)는 모바일 인증 콤포넌트(86)로 인증 요청 (MSISDN과 연관된 하나 이상의 계정 식별자들이 있을 수도 있다)을 송신한다 (단계 402). 이 메시지를 수신한 후에, 모바일 인증 콤포넌트(86)는 모바일 채널 및 제시자의 기기 성능에 따라 그 요청을 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 403).

모바일 전화기(72)를 사용하여, 제시자는 요청된 인증 데이터(예: 패스워드) 를 제공하고 그리고 모바일 인증 콤포넌트(86)에게 그 인증 데이터를 포함한 응답을 되돌려 주도록 송신한다 (단계 404). 모바일 인증 채널은 그 응답을 번역하고 포워딩하며 유효성 확인을 위해 액세스 제어 서버(ACS, 80)로 그것을 전해 준다 (단계 405). 그러면 액세스 제어 서버(ACS, 80)는 그 인증 응답을 수신하고, 수신된 인증 데이터를 체크한다 (단계 406). 그리고 나서 액세스 제어 서버(ACS, 80)는 상인 플러그-인(MPI, 74)에게 지불자 인증 응답(PA Res) 메시지를 되돌려 주도록 송신한다 (단계 407). 그러면 상인 플러그-인(MPI, 74)은 그 인증 응답 메시지를 체크한다 (단계 408).

만약 소비자가 인증되면, 그때는 즉시 승인이 적절한지 여부에 관한 결정이 이루어진다. 만약 즉시 승인이 적절하다면, 그때는 프로세스는 도 8에서 보여진 승인 프로세스로 진행할 수도 있고, 이는 아래에서 더 상세하게 기술된다 (단계 4B-1). 만약 즉시 승인이 적절하지 않다면, 그때 상인 플러그-인(MPI, 74)은 모바일 인증 콤포넌트(86)로 지불 계류중 통지 메시지(payment pending notification message)를 송신한다 (단계 409). 모바일 인증 콤포넌트(86)는 모바일 채널 및 제시자의 기기 성능에 기반하여 그 통지를 수정하고 그것을 제시자의 모바일 전화기(410)로 송신한다. 그러면, 도 8에서 보여지는 (그리고 아래에서 더 상세하게 기술되는) 바와 같은 지불 트랜잭션 승인 프로세스가 실행된다 (단계 411).

도 7의 대안 흐름 A는 제시자가 인증되지 않을 때 일어날 수 있다. 발행자들의 인증 규칙들에 따라, 액세스 제어 서버(ACS, 80)는 모바일 인증 콤포넌트(86)를 거쳐 제시자에게 인증 요청을 재발행할 수 있고 또는 제시자에게 인증 시도 회수가 도달되었음을 통지할 수도 있다. 만약 인증 시도 회수가 도달되었다면, 상인 플러그-인(MPI)은 모바일 인증 콤포넌트(86)로 "인증 시도 한도 도달 (authentication attempts limit reached" 통지 유형을 송신한다 (단계 4C-1). 모바일 인증 콤포넌트(86)는 모바일 채널 및 제시자의 기기 성능에 따라 그 통지를 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 4C-2). 만약 인증 시도 회수가 도달되지 않았으면, 그때는 프로세스는 단계(402)로 되돌아가 진행될 수도 있고, 인증 시도 회수가 도달된 때까지 계속될 수도 있다.

도 8은 인증된 지불 트랜잭션이 승인될 것을 필요로 하는 프로세스를 묘사할 수 있다. 승인은 즉시적(immediate)일 수 있고 또는 다르게 될 수 있다(differed). 프로세스는 제시자가 지불 트랜잭션을 인증한 때 시작한다. 그 프로세스는 지불 승인이 성공적일 때 끝난다.

도 8을 참조하면, 상인 플러그-인(MPI)은 승인 시스템(70)으로 지불 승인 요청을 송신한다 (단계 501). 승인 시스템(70)은 지불 승인을 처리한다 (단계 502). 그리고 나서 승인 시스템(70)은 액세스 제어 서버(ACS, 80)로 지불 승인 응답을 전송한다 (단계 503). 액세스 제어 서버(ACS, 80)는 상인 플러그-인(MPI, 74)으로 그 지불 승인 응답을 전송한다 (단계 504). 그러면 상인 플러그-인(MPI, 74)은 그 지불 승인 응답을 체크한다 (단계 505).

만약 지불 트랜잭션이 승인된 경우이면, 상인 플러그-인(MPI, 74)은 모바일 인증 콤포넌트(86)로 지불 수락 통지 메시지(payment accepted notification message)를 송신한다 (단계 506). 모바일 인증 콤포넌트(86)는 모바일 채널 및 제 시자의 기기 성능에 따라 그 통지를 수정하고, 그것을 제시자의 모바일 전화기(72)로 송신한다 (단계 507).

만약 지불 트랜잭션이 거절되고(declined) 승인되지 않는다면, 그때는 상인 플러그-인(MPI, 74)은 모바일 인증 콤포넌트로 지불 거절 통지 메시지(payment declined notification message)를 송신한다 (단계 5A-1 및 5A-2). 모바일 인증 콤포넌트는 모바일 채널 및 제시자의 기기 성능에 따라 그 통지를 수정하고 그것을 제시자의 모바일 전화기(72)로 송신한다.

Ⅲ. 휴대용 소비자 기기들 및 컴퓨터 장치들

도 9 및 도 10은 본 발명의 실시예들에 따른 시스템들에서 사용되는 컴퓨터 장치들에서 있을 수도 있는 서브시스템들 및 휴대용 컴퓨터 기기들에 관한 블록 다이어그램들을 보여주고 있다. 상기에서 기술된 일부 실시예들에서, 제시자는 신용 카드와 같은 지불 카드 및 전화기나 다른 통신 기기를 가지고 있을 수도 있어서, 인증 챌린지들을 수신할 수 있다. 다른 실시예들에서, 제시자는 전화기를 사용하여 지불 트랜잭션을 수행할 수도 있고 전화기를 사용하여 지불 데이터를 제공하면서 인증 챌린지에 대한 인터페이스로서 작용할 수 있다. 카드 및 전화기는 휴대용 소비자 기기의 예이고 본 발명의 실시예들은 이들 특정 휴대용 소비자 기기들에 제한되지 않는다.

바람직한 휴대용 소비자 기기는 임의의 적합한 형태일 수도 있다. 예를 들어, 적합한 휴대용 소비자 기기는 그것이 소비자의 지갑 및/또는 주머니에 맞을 수 있도록 (예: 주머니 크기) 핸드헬드식(hand-held)이고 간결할 수 있다. 그것은 스 마트 카드, (자기 스트립(magnetic strip)을 가지고 있고 마이크로프로세서를 가지고 있지 않은) 보통의 신용 카드 또는 직불 카드, 키체인 기기(keychain device) (이를테면 Exxon-Mobile 사에서 상업적으로 입수가능한 Speedpass^TM) 등을 포함할 수 있다. 휴대용 소비자 기기의 다른 예들은 셀룰러 전화기, PDA, 페이저(pager), 지불 카드, 보안 카드(security card), 액세스 카드(access card), 스마트 미디어(smart media), 트랜스폰더(transponder), 및 기타 등등을 포함한다. 휴대용 소비자 기기는 또한 직불 기기(예: 직불 카드), 신용 기기(예: 신용 카드), 또는 가액 저장 기기(예: 가액 저장 카드)일 수 있다.

전화기(32') 형태의 바람직한 휴대용 소비자 기기는 도 9a에서 보여지는 바와 같이 몸체 및 컴퓨터 판독가능 매체를 포함할 수도 있다 (도 9a는 다수의 콤포넌트들을 보여주고 있고, 본 발명의 실시예들에 따른 휴대용 소비자 기기들은 이러한 콤포넌트들의 임의의 적합한 조합 또는 부분집합을 포함할 수도 있다). 컴퓨터 판독가능 매체(32(b))는 몸체(32(h)) 내에 있을 수도 있고, 또는 그것으로부터 분리가능할 수도 있다. 몸체(32(h))는 플라스틱 기판(plastic substrate), 하우징(housing), 또는 다른 구조 형태일 수도 있다. 컴퓨터 판독가능 매체(32(b))는 데이터를 저장하는 메모리일 수도 있고 그리고 자기 선(magnetic stripe), 메모리 칩, 고유의 유도 키(uniquely derived key)들, 암호화 알고리즘들 등을 포함하는 임의의 적합한 형태일 수도 있다. 메모리는 또한 바람직하게는, 금융 정보, 운송 정보(transit information)(예: 지하철 또는 철도 패스의 경우), 액세스 정보(예: 액세스 배지(access badge)의 경우) 등과 같은 정보를 저장한다. 금융 정보는, 은행 계정 정보, 은행 식별 번호(BIN), 신용 또는 직불 카드 번호 정보, 계정 잔액 정보, 유효 일자, 소비자 정보 이를테면 이름이나 생년월일 등과 같은 정보를 포함할 수도 있다. 이 정보 중 어느 것이라도 전화기(32')에 의해 전송될 수도 있다.

메모리 내 정보는 또한 전통적으로 신용 카드와 연관된 데이터 트랙(data track)들의 형태일 수도 있다. 이러한 트랙들은 트랙 1(Track 1) 및 트랙 2(Track 2)를 포함한다. 트랙 1("국제 항공 운송 협회 (International Air Transport Association)")은 트랙 2보다 더 많은 정보를 저장하고, 카드소지자의 이름 뿐만 아니라 계정 번호 및 다른 임의의 데이터를 담을 수 있다. 이 트랙은 때때로 신용 카드로 예약을 확보할 때 항공사들에 의해 사용된다. 트랙 2("미국 은행 협회 (American Banking Association)" - ABA)는 현재 가장 보편적으로 사용되는 것이다. 이것은 ATM 및 신용 카드 체크기(checker)에 의해 읽혀지는 트랙이다. ABA는 이 트랙의 명세사항들(specifications)을 설계하였고 모든 세계 은행들은 그것을 준수하여야 한다. 그것은 카드소지자의 계정, 암호화된 PIN, 거기에 더하여 다른 임의의 데이터를 담을 수 있다.

컴퓨터 판독가능 매체(32(b)) 또는 메모리는 상기에서 기술된 단계들 중 어느 것을 임의의 적합한 순서로 수행하기 위한 코드를 포함할 수도 있다. 예를 들어, 컴퓨터 판독가능 매체(32(b))는, a) 제시자의 계정과 연관된 계정 식별자와 연관된 별칭 식별자를 제공하기 위한 코드; b) 상기 별칭 식별자를 제공한 후에 인증 요청 메시지를 수신하기 위한 코드; 및 c) 상기 인증 요청 메시지를 수신한 후에 인증 응답 메시지를 송신하기 위한 코드를 포함할 수도 있다.

전화기(32')는 비접촉식 요소(32(g))를 더 포함할 수도 있는데, 여기서 그 비접촉식 요소는, 안테나와 같은 관련 무선 전송(예: 데이터 전송) 요소를 가진 반도체 칩(또는 다른 데이터 저장 요소)을 포함할 수도 있다. 비접촉식 요소(32(g))는 전화기(32')와 연관되고(예: 전화기(32') 내에 엠베디드되고) 셀룰러 네트워크를 거쳐 전송된 데이터 또는 제어 명령들은 비접촉식 요소 인터페이스(미도시)에 의해 비접촉식 요소(32(g))에 적용될 수도 있다. 비접촉식 요소 인터페이스는 모바일 기기 회로 (및 따라서 셀룰러 네트워크) 및 선택사항인 비접촉식 요소(32(g)) 간에 데이터 및/또는 제어 명령들의 교환을 허용하도록 기능한다.

비접촉식 요소(32(g))는 전형적으로 표준화된 프로토콜 또는 데이터 전송 메커니즘(예: ISO 14443/NFC)에 따른 근거리 통신(near field communications; "NFC") 기능(또는 근거리 통신 매체)을 이용하여 데이터를 전송하고 수신할 수 있다. 근거리 통신 기능은 단거리 영역 통신 기능 예컨대 RFID, 블루투스(Bluetooth^TM), 적외선, 또는 전화기(32') 및 문의 기기(interrogation device) 간에 데이터를 교환하는데 사용될 수 있는 다른 데이터 전송 기능이다. 따라서, 전화기(32')는 셀룰러 네트워크 및 근거리 통신 기능 양자를 거쳐 데이터 및/또는 제어 명령들을 송수신하고 전송할 수 있다.

전화기(32')는 또한 전화기(32')의 기능들을 처리하는 프로세서(32(c))(예: 마이크로프로세서), 및 전화 번호와 다른 정보와 메시지들을 소비자들이 볼 수 있 게 해 주는 디스플레이(32(d))를 포함할 수도 있다. 전화기(32')는 또한 소비자(또는 제시자)가 그 기기 내에 정보를 입력할 수 있게 해 주는 입력 요소들(32(e)), 소비자가 음성 통신, 음악 등을 들을 수 있게 해 주는 스피커(32(f)), 및 소비자가 자신의 음성을 전화기(32')를 통해 전송할 수 있게 해 주는 마이크로폰(32(i))을 더 포함할 수도 있다. 전화기(32')는 또한 무선 데이터 전송(예: 데이터 전송)을 위한 안테나(32(a))를 포함할 수도 있다.

상기에서 언급한 바와 같이, 어떤 실시예들에서, 제시자 또는 소비자는 직불, 신용, 또는 스마트카드의 형태의 휴대용 소비자 기기를 사용할 수도 있다. 카드 형태의 휴대용 소비자 기기는 또한 선택사항으로 자기 스트립과 같은 기술특징을 가질 수도 있다. 이러한 기기들은 접촉식 또는 비접촉식 모드 중 어느 하나로 동작할 수 있다.

카드(32'') 형태의 휴대용 소비자 기기의 예가 도 9a에 도시되어 있다. 도 9a는 플라스틱 기판(32(m))을 보여주고 있다. POS 단말과 같은 액세스 기기와 인터페이싱하는 비접촉식 요소(32(o))는 플라스틱 기판(32(m)) 상에 있거나 또는 그 기판 내에 엠베디드될 수도 있다. 계정 번호, 유효 일자, 및 소비자 이름과 같은 소비자 정보(32(p))는 카드 상에 프린트되거나 양각될 수도 있다. 또한, 자기 선(32(n))도 또한 플라스틱 기판(32(m)) 상에 있을 수 있다.

도 9b에서 보여지는 바와 같이, 카드(32'')는 자기 선(32(n)) 및 비접촉식 요소(32(o)) 양자 모두를 포함할 수도 있다. 다른 실시예들에서, 자기 선(32(n)) 및 비접촉식 요소(32(o)) 양자 모두가 카드(32'')에 있을 수도 있다. 다른 실시예 들에서, 자기 선(32(n)) 또는 비접촉식 요소(32(o)) 중 어느 하나가 카드(32'')에 있을 수도 있다.

이전에 묘사된 도면들(예: 도 1 내지 도 3)에서의 다양한 참여자들 및 요소들은 이 문서에서 기술된 기능들을 용이하게 하는 하나 이상의 컴퓨터 장치들을 사용하여 동작할 수 있다. 도면들 내의 요소들 중 어느 것도 이 문서에서 기술된 기능들을 용이하게 하는 임의의 적합한 수의 서브시스템들을 사용할 수도 있다. 이러한 서브시스템들 또는 콤포넌트들의 예들이 도 10에 도시되어 있다. 도 10에 도시된 서브시스템들은 시스템 버스(775)를 거쳐 상호연결된다. 프린터(774), 키보드(778), 고정 디스크(fixed disk, 779) (또는 컴퓨터 판독가능 매체를 포함하는 다른 메모리), 모니터(776) - 이는 디스플레이 어댑터(782)에 연결됨 -, 및 다른 것들과 같은 부가적인 서브시스템들이 보인다. 주변 기기들 및 입력/출력(I/O) 기기들 - 이들은 I/O 콘트롤러(771)에 연결됨 - 은 시리얼 포트(777)와 같은 관련 기술분야에서 알려진 임의의 개수의 수단들에 의해 컴퓨터 시스템에 연결될 수 있다. 예를 들어, 시리얼 포트(777) 또는 외부 인터페이스(781)는 인터넷과 같은 광역 네트워크, 마우스 입력 기기, 또는 스캐너에 컴퓨터 장치를 연결시키는데 사용될 수 있다. 시스템 버스를 통한 상호연결은 중앙 프로세서(773)가 각 서브시스템과 통신할 수 있게 해 주고 시스템 메모리(772) 또는 고정 디스크(779)로부터의 명령들의 실행 뿐만 아니라 서브시스템들 간의 정보의 교환을 제어할 수 있게 해 준다. 시스템 메모리(772) 및/또는 고정 디스크(779)는 컴퓨터 판독가능 매체를 구현할 수도 있다. 이들 요소들 중 어느 것이라도 이전에 기술된 기술특징들에 있을 수도 있다. 예를 들어, 이전에 기술된 디렉토리 서버 및 액세스 제어 서버는 도 10에 도시된 이들 콤포넌트들 중 하나 이상을 구비할 수도 있다.

본 발명의 일 실시예에 따른 컴퓨터 판독가능 매체는 상기에서 기술된 기능들 중 어느 것이라도 수행하기 위한 코드를 포함할 수도 있다. 예를 들어, 이전에 기술된 디렉토리 서버는, a) 제시자의 계정과 연관된 계정 식별자와 연관된 별칭 식별자를 제공하기 위한 코드; b) 상기 별칭 식별자를 제공한 후에 인증 요청 메시지를 수신하기 위한 코드, 및 c) 상기 인증 요청 메시지를 수신한 후에 인증 응답 메시지를 송신하기 위한 코드를 포함하는 컴퓨터 판독가능 매체를 포함할 수 있다. 디렉토리 서버는 또한 그 컴퓨터 판독가능 매체에 연결된 프로세서를 구비할 수도 있고, 여기서 그 프로세서는 그 컴퓨터 판독가능 매체 상의 컴퓨터 코드에 의해 구현되는 명령들을 실행한다.

이 문서에서 활용된 용어들 및 표현들은 설명의 관점에서 사용된 것이고 제한하려는 관점에서 사용된 것은 아니며, 이러한 용어들 및 표현들의 사용에 있어, 도시되고 기술된 기술특징들이나 그 기술특징들의 부분들에 관한 균등물들을 제외하려는 의도는 없으며, 청구된 본 발명의 범위 내에서 다양한 변경예들이 가능함이 인식되어야 한다. 또한, 본 발명의 범위로부터 벗어남이 없이, 본 발명의 임의의 실시예의 어느 하나 이상의 기술특징들은 본 발명의 어떤 다른 실시예의 어느 하나 이상의 다른 기술특징들과 결합될 수도 있다.

또한, 상기에서 기술된 본 발명은 모듈 방식 또는 집적 방식의 컴퓨터 소프트웨어를 이용하는 제어 로직의 형태로 구현될 수 있다는 것이 이해되어야 할 것이 다. 이 문서에서 제공된 개시내용 및 교시내용들에 비추어, 관련 기술분야에서 보통의 숙련도를 가진 자는 하드웨어 및 하드웨어와 소프트웨어의 조합을 이용하여 본 발명을 구현하는 다른 방식들 및/또는 방법들을 알 것이고 인식할 것이다.

"한(하나의)" 또는 "그"라고 기재된 것은 다른 의미로 명확히 표시되지 않으면 "하나 또는 그 이상(하나 이상)"을 의미하려는 것이다.

상기에서 언급된 모든 특허들, 특허 출원들, 공개 문헌들, 및 설명들은 모든 점에서 그들 전체로 참조에 의해 이 문서에 통합된다. 어떤 것도 선행 기술인 것으로 인정되지 않는다.

Claims

a) 제시자(presenter)의 계정(account)에 대한 계정 식별자와 연관된 별칭 식별자(alias identifier)를 수신하는 단계;

b) 상기 별칭 식별자를 사용하여 연관된 신뢰 당사자(trusted party)를 결정하는 단계;

c) 상기 연관된 신뢰 당사자를 결정한 후에 상기 신뢰 당사자에게, 상기 신뢰 당사자 또는 상기 제시자가 인증 프로그램에 참여하는지 여부에 관한 정보를 요청하는 검증 요청 메시지를 송신하는 단계; 및

d) 상기 신뢰 당사자 또는 상기 제시자가 상기 인증 프로그램에 참여하는지 여부를 나타내는 검증 응답 메시지를 수신하는 단계;를 포함하는 방법.
제1항에 있어서,

상기 별칭 식별자는 전화 번호인, 방법.
제1항에 있어서,

상기 신뢰 당사자는 상기 계정을 유지시키는 금융 기관인, 방법.
제1항에 있어서,

상기 제시자에게 인증 요청 메시지를 송신하는 것을 개시하는 단계;를 더 포 함하는 방법.
제1항에 있어서,

상기 방법은 상기 제시자에게 인증 요청 메시지를 송신하는 것을 개시하는 단계;를 더 포함하며, 액세스 제어 서버(access control server)는 상기 제시자에게 상기 인증 요청 메시지를 후속하여 송신하는, 방법.
제1항에 있어서,

상기 별칭 식별자를 수신하는 단계 이전에, 상기 제시자는 모바일 전화기를 사용하여 상기 별칭 식별자를 송신하는, 방법.
제1항에 있어서,

상기 a) 내지 d) 단계들은 디렉토리 서버(directory server)에 의해 수행되는, 방법.
제7항에 있어서,

상기 신뢰 당사자는 상기 계정 식별자를 발행한 발행자(issuer)인, 방법.
a) 제시자(presenter)의 계정(account)에 대한 계정 식별자와 연관된 별칭 식별자(alias identifier)를 수신하기 위한 코드;

b) 상기 별칭 식별자를 사용하여 연관된 신뢰 당사자(trusted party)를 결정하기 위한 코드;

c) 상기 연관된 신뢰 당사자를 결정한 후에 상기 신뢰 당사자에게, 상기 신뢰 당사자 또는 상기 제시자가 인증 프로그램에 참여하는지 여부에 관한 정보를 요청하는 검증 요청 메시지를 송신하기 위한 코드; 및

d) 상기 신뢰 당사자 또는 상기 제시자가 상기 인증 프로그램에 참여하는지 여부를 나타내는 검증 응답 메시지를 수신하기 위한 코드를 포함하는 컴퓨터 판독가능 매체.
프로세서; 및

상기 프로세서에 연결된, 제9항의 컴퓨터 판독가능 매체 시스템을 포함하는 디렉토리 서버(directory server).
a) 제시자(presenter)의 계정(account)과 연관된 계정 식별자와 연관된 별칭 식별자(alias identifier)를 제공하는 단계;

b) 상기 별칭 식별자를 제공한 후에 인증 요청 메시지를 수신하는 단계; 및

c) 상기 인증 요청 메시지를 수신한 후에 인증 응답 메시지를 송신하는 단계를 포함하는 방법.
제11항에 있어서,

상기 별칭 식별자는 전화 번호인, 방법.
제11항에 있어서,

상기 별칭 식별자는 상기 제시자의 음성을 사용하여 제공되는, 방법.
제13항에 있어서,

상기 인증 요청 메시지는 상기 제시자에 의해 운용되는 전화기에서 수신되는, 방법.
제14항에 있어서,

상기 인증 응답 메시지는 패스워드(password) 또는 핀 넘버(pin number)를 포함하는, 방법.
제11항에 있어서,

상기 별칭 식별자는 대면 트랜잭션(face-to-face transaction)에서 상인에게 제공되는, 방법.
제11항에 있어서,

상기 별칭 식별자는 상인에 대하여 원격에 위치한 통신 기기를 사용하여 상기 상인에게 제공되는, 방법.
a) 제시자(presenter)의 계정(account)과 연관된 계정 식별자와 연관된 별칭 식별자(alias identifier)를 제공하기 위한 코드;

b) 상기 별칭 식별자를 제공한 후에 인증 요청 메시지를 수신하기 위한 코드; 및

c) 상기 인증 요청 메시지를 수신한 후에 인증 응답 메시지를 송신하기 위한 코드를 포함하는 컴퓨터 판독가능 매체.
프로세서;

상기 프로세서에 연결된 안테나;

상기 프로세서에 연결된 마이크로폰; 및

상기 프로세서에 연결된, 제18항의 컴퓨터 판독가능 매체를 포함하는 전화기.
제19항에 있어서,

상기 프로세서에 연결된 비접촉식 요소(contactless element)를 더 포함하는 전화기.