KR20030019404A

KR20030019404A - 거래 시스템 및 방법

Info

Publication number: KR20030019404A
Application number: KR1020027016214A
Authority: KR
Inventors: 윌슨 하우 기어프 궤
Original assignee: 윌슨 하우 기어프 궤
Priority date: 2000-05-25
Filing date: 2001-05-25
Publication date: 2003-03-06
Also published as: EP1305750A1; US20040030659A1; WO2001090987A1; AU2001259013A1

Abstract

본 발명은 온라인 네트워크를 통한 구매자와 판매자간의 금융거래를 인증하는 방법 및 시스템을 제공한다. 상기 방법은 상기 구매자에 관한 고유 정보를 포함하는 구매자로부터의 거래 요청을 수신하는 단계와; 그리고 상기 거래 요청을 인증하며, 만일 인증이 이루어지면 상기 구매자에게 상기 구매자가 금융 거래를 행하기 위해 이용하는 거래 번호 - 이 거래 번호는 상기 구매자의 신용/지불 카드 번호와는 다르다 - 제공하는 단계를 포함한다.

Description

거래 시스템 및 방법{TRANSACTION SYSTEM AND METHOD}

인터넷과 같은 온라인 네트워크의 도래로, 온라인 환경에서의 상거래가 점점 더 일반화되고 있다. 지금, 유저들에게 전자 상거래를 통해 구매될 수 있는 대량의 상품 및 서비스들을 제공해주는 수많은 온라인 사이트들이 존재한다.

온라인 상거래 시작시, 그러한 거래의 유저들은 그들의 익명성 및 프라이버시 뿐만 아니라 특히 그들의 신용카드 번호 및 그 만료기간 정보의 공개에 관하여 그들의 개인적인 금융 정보의 손상 방지 보장을 요구하고 있다.

예컨대, 특정 사이트로부터 상품 및 서비스를 원하는 유저들은 일반적으로 판매자에게 그들의 신용 또는 지불 카드 세부사항들을 제시할 것을 요구받는다. 이러한 방식의 문제점은 판매자들이 유저의 신용 세부사항들을 악용할 수 있는 가능성이 있다는 점이다. 예컨대, 만일 개인의 신용 카드 번호 및 만료일이 나쁜 판매자 또는 컴퓨터 해커와 같은 불순한 사람에 의해 입수되게 되면 그 사람은 카드의 실제 소유자의 동의없이 그 카드 번호 및 만료일을 이용하여 온라인을 통해 구매를행할 수 있다는 점이다.

신용카드 사기는 판매자들에게도 특별히 문제가 되는바, 대부분의 신용 제공자들은 "카드 정보는 타인에게 제시되지 말아야 하는" 정책을 고수하므로, 모든 사기성 거래에 대해 온라인 판매자들이 책임을 지게된다. 그러므로, 이러한 정책으로 인해 많은 온라인 판매자들이 수입에 상당한 손실을 입게된다.

유저의 관점에서 볼 때, 유저의 신용카드 번호가 도난 당했을 때, 신용 제공자는 그 번호 및 새로운 계정 개설을 불능상태로 한다. 이러한 과정은 시간 소모적이며, 일단 그 번호가 불능상태로 되면 그 신용카드 번호는 더이상의 거래를 위해 사용될 수 없기 때문에 계정 소유자를 곤란한 상황에 처하게 한다.

보안 문제를 해결하기 위한 기존의 한 방법은 보안 전자거래(SET:Secure Electronic Transaction) 기술이다. 이 기술은 거래를 행하기 전, 유저의 컴퓨터 시스템에 설치된 스마트 카드 판독기를 통해 신용카드에 대한 인증 절차를 거칠 것을 요한다. 이것은 거래승인을 위해 판매자에게 신용카드를 제시하는 것과 온라인 측면에서 서로 균등하다. 비록 이 기술은 온라인 거래 인증의 상당한 보안 형태를 제공하는 것으로 생각 되지만은, 특수한 카드 판독기의 설치가 요구되기 때문에, 그러한 판독기의 설치없이는 다른 컴퓨터 시스템으로부터 상품 및 서비스를 구매할 수 없으므로 신용카드에 대한 유저들의 보안적 사용이 제한된다.

더욱이, 일반적으로 유저들은 온라인 거래를 위한 그러한 특수한 하드웨어이용을 수락하기를 꺼려해왔다.

또 하나의 방법은 먼저 암호화를 행하고 이어서 온라인 판매자에 의해 인증을 받는 디지털 보증을 통해 유저에 대해 인증을 행하는 것이다. 이 기술의 한계점은 현재까지 이러한 보증을 위한 산업계 전반을 커버하는 단일 표준이 없음으로써 유저들이 다양한 판매자들과 다양한 타입의 서로 다른 디지털 보증 과정을 거쳐야만 한다는 것이다. 또한, 이 시스템은 불법 판매자들이 그러한 보증을 허락되지 않은 거래에 악용할 수 있다.

그러므로, 유저들에게 향상된 익명성, 프라이버시 및/또는 보안성을 제공하는 거래 시스템 및/또는 방법이 요구된다.

본 발명은 종래기술의 문제점들중 적어도 하나를 극복하거나 또는 경감하고자 하는 것이다.

본 발명은 상거래 분야, 보다 특별하게는 온라인 환경에서의 전자 상거래 분야에서의 시스템 및/또는 방법에 관한 것이다. 본 발명은 인터넷 뱅킹 및 전자 상거래 운영 시스템에 특별히 응용된다.

본 발명의 예시적인 실시예들을 첨부도면을 참조로 하여 상세히 설명하기로 한다.

도 1은 본 발명의 일실시예에 따른, 금융 거래를 행하는 시스템과 이용을 위한 판매자의 온라인 사이트에서의 주문 형태의 예를 보인 도면.

도 2는 본 발명의 일실시예에 따른, 판매자의 온라인 사이트에서 주문을 행하기위해 기입될 지불 정보의 유형에 대한 예를 보인 도면.

도 3은 본 발명의 일 실시예에 따른, 신용 제공자와 접속을 제공하기위해 유저에게 제시되는 원도우의 예를 보인 도면.

도 4는 본 발명의 실시예에 따른, 온라인 거래에서 사용을 위한 거래 번호의 유저에게로의 제공을 보인 도면.

도 5는 본 발명의 일 실시예에 따른, 유저가 판매자 사이트에서 거래번호를 이용하여 거래를 완료하는 예를 보인 도면.

도 6은 본 발명의 제 1실시예에 따른, 금융거래를 행하는 시스템의 개략도.

도 7은 유저 신원을 설정하는 방식을 예시하는 도 6의 시스템의 세부사항에 대한 개략도.

도 8은 거래번호의 제공을 예시하는 도 6의 시스템의 세부사항에 대한 개략도.

도 9는 신용인증에서 거래 번호의 요청시간의 포함을 예시하는 도 6의 시스템의 세부사항에 대한 개략도.

도 10은 본 발명의 또 다른 실시예에 따른, 금융 거래를 행하는 시스템에서 거래 번호들의 예약 리스트의 개략도.

도 11은 도 10의 예약 리스트로의 엑세스가 초기화되는 방식을 예시한 도면.

도 12는 본 발명의 또다른 실시예에 따른, 거래 번호를 선택하기 위해 모프코드의 발생 및 이용을 예시한 도면.

도 13은 본 발명의 또다른 실시예에 따른, 거래 번호의 유저에게로의 전송을 예시한 도면.

도 14는 본 발명의 또다른 실시예에 따른, 유저들간의 예약된 리스트의 거래번호들의 교환을 예시한 도면.

도 15a 및 도 15b는 본 발명의 또 다른 실시예에 따른, 금융 거래를 행하기 위한 시스템에서 핫스폿을 유저 식별 정보에 삽입하는 것을 예시한 도면.

도 16은 본 발명의 또 다른 실시예에 따른, 금융 거래를 행하기 위한 시스템에서 유저 식별 정보에 개인 정보를 첨가하는 것을 예시한 도면.

도 17a, 도 17b 및 도 17c는 본 발명의 또 다른 실시예에 따른, 금융 거래를 행하는 시스템에서 패스워드 필드에 삽입된 개인 정보를 유저 식별 정보에 첨가하는 것을 예시한 도면.

본 발명의 제 1양상에 따르면, 온라인 네트워크를 통한 구매자와 판매자간의 금융거래를 인증하는 방법이 제공되는바, 이 방법은 상기 구매자에 관한 고유 정보를 포함하는 구매자로부터의 거래 요청을 수신하는 단계와; 그리고 상기 거래 요청을 인증하며, 만일 인증이 이루어지면 상기 구매자에게 상기 구매자가 금융 거래를 행하기 위해 이용하는 거래 번호 - 이 거래 번호는 상기 구매자의 신용/지불 카드번호와는 다르다 - 제공하는 단계를 포함한다.

그러나, "구매자"는 지불 납입을 행하고자 하는 모든 유저를 의미하며, "판매자"는 구매자가 지불 납입을 행하는 대상이 되는 모든 당사자들을 의미함을 이해할 수 있을 것이다. 물론, 상기 지불은 상품이나 서비스에 대해 행해질 수 있으며, 또한 과거의 구매에 대해 지불이 완료되도록 청구서에 대해 지불을 행함으로써 기존 채무에 대해 지불을 완료하도록 의도될 수 있다. 또한, 당업자이면, (일반적으로 사용될때마다 매번 다르게 언급되는, "변형 번호", "변형 계정번호", "변형 지불 번호" 또는 "변형 카드 번호"로서 또한 언급될 수 있는) 상기 거래 번호는 구매자의 "실제" 신용/지불 카드 또는 계정 번호와 어떤 관계를 가질 필요는 없거나 또는 그러한 "실제" 신용/지불 카드 번호가 존재해야 함을 요하지 않음을 알 수 있을것이다. 예컨대, 신용 계정은 본 발명의 방법 (또는 하기의 시스템)에 의해 배타적으로 동작될 수 있고 그리고 전형적으로 요구에 따라 발생되는 거래 번호들은 그 계정을 액세스 하는데 사용될 수 있는 번호들로만 될 수 있을 것으로 상상된다. 또한, 이 거래 번호는 구매자의 신용/지불 카드 번호로 부터 발생 되거나 또는 이로부터 변형될 필요가 없다.

바람직하게, 판매자는 구매자의 신용 제공자와 금융 거래를 완료하기위해 상기 거래번호를 이용한다.

바람직하게, 본 발명은 상기 구매자에 의해 공급된 패스워드 또는 문구(phrase)로부터 상기 거래번호를 생성하는 단계를 포함한다. 보다 바람직하게, 상기 방법은 구매자에의해 공급된 패스워드 또는 문구로부터 일단의 거래번호들을 생성하고, 상기 일단의 거래번호들로부터 상기 거래번호를 선택하는 단계를 포함한다.

본 발명의 제 2양상에 따르면, 온라인 환경에서 구매자와 판매자사이에 금융거래를 행할 수 있게 하는 시스템이 제공되는바, 이 시스템은 구매자로부터 고유의 유저 식별 정보를 수신하여 이 정보 데이터를 근거로 구매자를 인증하는 구매자 인증 수단과; 그리고 구매자가 상기 금융 거래를 행하는 데 이용되는, 구매자의 신용/지불 카드 번호와 다른 거래 번호를 생성하는 거래번호 생성기를 포함한다.

바람직하게, 상기 거래번호는 임의로 생성되며, 거래의 인증하에서만 이용될 수 있도록 생성된다. 이는 각 거래마다 재생성되어, 거래마다 변하기 때문이다.

그러므로, 구매자에 의한 인증 요청하에서 신용 제공자에 의해 발생되는 신용카드 번호를 가짐으로 해서 보안 및 프라이버시 거래가 이루어질 수 있다. 다시 말해서, 판매자는 그렇지 못한 경우 악용될 수도 있는 개인 신용사항들을 유용할 수가 없다.

따라서, 본 발명의 장점은 구매자가 판매자에게 신용카드 번호를 전혀 제시할 필요가 없다는 점이다.

본 발명의 또 다른 양상에 따르면, 온라인 네트워크를 통한 구매자와 판매자간의 금융거래를 인증하는 방법이 제공되는바, 여기서 구매자는 SIM 카드를 갖는 이동 전화로부터 거래를 요청하며, 상기 SIM 카드 및/또는 전용 PIN을 통해 구매자의 신용을 인증하는 단계를 포함한다.

본 발명의 또 다른 양상에 따르면, 구매자와 판매자사이에 금융 거래를 인증하는 방법이 제공되는바, 이 방법은 구매자로부터 거래 번호 요청 - 이 요청은 상기 구매자에 관한 식별 정보를 포함하고 있다 - 을 수신하는 단계와; 그리고 상기 요청을 인증하여, 만일 인증이 이루어지면, 상기 구매자가 금융거래를 행하는 데 사용하도록 상기 거래 번호를 상기 구매자에 제공하는 단계를 포함한다.

본 발명의 또 다른 양상에 따르면, 구매자가 판매자와 금융거래를 행하는 방법이 제공되는바, 상기 방법은 상기 구매자가 거래번호에 대한 요청 - 이 요청은 상기 구매자에 관한 식별 정보를 포함한다 - 을 제시하는 단계와; 만일 상기 요청에 대해 인증이 이루어지면 상기 구매자가 상기 거래 번호를 수신하는 단계와; 그리고 상기 금융 거래를 행하도록 상기 거래 번호를 상기 판매자에게 제공하는 단계를 포함한다.

본 발명의 또 다른 양상에 따르면, 구매자와 판매자 사이에 금융거래를 행하게 하는 시스템이 제공되는바, 상기 시스템은 상기 구매자로부터 거래번호에 대한 요청 - 이 요청은 식별 정보를 포함한다 - 을 수신하고 상기 식별 정보에 근거하여 상기 구매자를 인증하는 구매자인증 수단과; 그리고 상기 구매자가 상기 금융거래를 행하는데 이용하도록, 상기 구매자와 관련된 거래 번호를 생성하는 거래번호 생성기를 포함한다.

본 시스템은 온라인 환경 (WAP 인에이블 전화. 단문 메시징 서비스 (SMS) 또는 어떤 다른 전화 데이터 프로토콜에 의한 WAP를 비롯한 인터넷을 통하는 환경)에서 특별히 응용될 수 있을 뿐만 아니라 전화나 또는 심지어 사람을 통해 거래들을 행하는 데도 이용될 수 있다. 중요한 특징으로서, 필요로 할 때마다 바로 요청에 의해 구매자에게 거래 번호가 생성되거나 주어진다. 따라서, 이 거래번호는 전화를 통해 입수할 수 있으며, 따라서 통상적인 신용 카드 번호로 할 수 있는 것과 같이 전화 또는 사람에 의하여 이용될 수 있다.

바람직하게, 상기 거래번호는 상기 구매자의 신용/지불 계정 또는 카드 번호와는 다르다.

따라서, 구매자가 사용되는 신용/지불 계정과 관련된 "실제(geneue)" 번호(즉, 그렇지 못한 경우, 직접 만나(face-to face) 거래를 행할 때 사용할 수 있는 번호)와는 다른 번호를 항상 제시할 수 있도록 함으로써, 상기 실제 번호가 판매자에게 제공되거나 또는 판매자의 서버에 저장되지 않게 된다. 판매자의 서버는 알려지지 않거나 혹은 종종 보안성이 빈약하다. 비록 모든 판매자의 서버들이 보안성을 갖는다 하더라도, 구매자의 실제 번호의 복제물이 그러한 판매자의 많은 서버들에 잠정적으로 존재되어야 한다는 것은 바람직하지 못하다.

한 실시예에서, 상기 거래번호는 상기 구매자의 실제 계정 또는 카드 번호의 적어도 일부를 포함할 수 있다.

대안적으로, 상기 거래번호는 상기 구매자의 공통 계정 또는 카드 번호의 적어도 일부를 포함할 수 있다. 바람직하게, 상기 공통 계정 또는 카드 번호는 특정금융 기관 또는 특정 판매자에 특정하게 부여된다.

바람직하게, 상기 거래번호는 소정의 선택 코드 또는 필요시 생성되는 선택코드에 따라 기존의 그러한 거래 번호들의 세트로부터 선택된다.

바람직하게, 상기 거래 번호들의 세트는 언제든지 단일 유저에 특정하게 부여된다.

다른 실시예에서, 상기 방법은 상기 거래 번호를 수신하고, 상기 거래번호에 적어도 하나의 핫스폿(hotspot)을 추가하여 상기 거래 번호를 변경하고 그리고 그렇게 변경된 상기 거래 번호를 상기 판매자에 제공하는 단계를 포함한다.

본 발명의 또 다른 양상에 따르면, 구매자와 판매자사이에 금융거래를 행하는 방법이 제공되는바, 이 방법은 구매자 계정 정보를 상기 판매자에게 제공하는 단계와; 상기 판매자가 신용 발행자(또는 신용 발행자의 대행사)에 거래 승인을 요청하는 단계와; 상기 신용 발행자가 상기 구매자에게 인증 요청을 전송하는 단계와; 그리고 상기 구매자가 상기 신용 발행자에게 인증 데이터를 전송함으로써 상기 인증에 응답하는 단계를 포함한다.

바람직하게, 상기 인증 코드는 상기 인증 요청에 대한 응답을 포함한다.

따라서, 만일 예컨대 상기 인증 요청이 (WAP, 이메일, SMS 등에 의해) 유저의 전화에 전송되면, 유저는 간단히 그의 전화에 대한 응답기능을 이용하여 그 거래의 인증을 확인할 수 있다.

대안적으로, 그리고 보다 보안성을 위해, 상기 인증 요청은 유저에 의해 거래가 인증되도록 하기위한 인증데이터에 포함되어야 하는 (PIN과 같은) 패스워드를 포함할 수 있다.

바람직하게, 상기 인증 데이터는 상기 인증 요청에 포함되지않은 (PIN과 같은)소정의 패스워드를 포함해야만 한다.

일 실시예에서, 상기 방법은 상기 인증데이터를 상기 계정 정보를 가진 상기 카드 발행자에게 전송하는 단계를 포함한다. 예컨대, 상기 계정정보는 신용 계정번호 또는 공통 신용 발행자 번호를 포함해야 하는바, (신용 발행자의 서버에 로그인함으로써 얻어지는 PIN이 되는) 그 번호 및 인증 데이터는 판매자의 신용 상세 콘솔 스크린에 입력될 수 있다.

바람직하게, 상기 방법은 상기 인증요청을 상기 신용 발행자로부터 상기 구매자에게 전송하기전에 초기 유효성 테스트를 수행하는 단계를 포함한다.

따라서, 신용 발행자는 예컨대 상기 계정 정보가 유효한지 여부를 체크해야만 한다.

바람직하게, 인증 데이터는 상기 구매자에 의해 제시된 패스워드 또는 문구의 전체 또는 요청 부분을 포함한다.

한 실시예에서, 상기 인증데이터는 상기 구매자에의해 공급된 패스워드 또는 문구의 소정의 제 1부분 및 상기 패스워드 또는 문구의 요청된 제 2부분을 포함한다. 상기 제 2부분의 선택은 매 로그인마다 임의적으로 효과적으로 변경될 수 있다.

바람직하게, 상기 제 1부분은 상기 구매자에 의해 상기 패스워드 또는 문구와 함께 사전 제시된 핫스폿에 의해 한계가 정해진다.

본 발명의 또다른 양상에 따르면, 구매자와 판매자사이에 금융거래를 행하는 방법이 제공되는바, 상기 방법은 상기 판매자로부터 거래승인 요청을 수신하는 단계와; 상기 구매자에게 인증요청을 전송하는 단계와; 그리고 상기 구매자로부터 인증 데이터를 수신하는 단계를 포함한다.

본 발명의 한 양상에서, 온라인 또는 다른 통신 환경에서 유저의 신원을 서버에 인증하는 방법이 제공되는바, 이 방법은 관련 유저 식별 정보를 갖는 유저 계정을 설정하고 상기 유저로부터 패스워드를 수신하는 단계와; 상기 패스워드 및 상기 패스워드로부터 추론되는 코드에 근거하여 일단의 의사-패스워드를 생성하는 단계와; 상기 유저 식별 정보를 포함하는 유저 장치측의 상기 유저로부터 로그인 요청을 수신하는 단계와; 상기 일단의 의사-패스워드들로부터 임의의 의사-패스워드를 활성화시켜 한 세트의 하나 이상의 번호들 - 이 번호들은 규칙에 의해 상기 코드로부터 추론된다 - 을 생성하는 단계와; 유저 장치에 상기 세트의 번호들을 전송하는 단계와; 상기 패스워드를 상기 유저 장치에 기입하고, 상기 유저장치에서 상기 규칙과 반대인 규칙 및 상기 패스워드에 따라 상기 세트의 번호를 변경하여 변경된 세트의 번호를 생성하는 단계와; 상기 변경된 세트의 번호 - 이 번호들은 만일 상기 패스워드가 상기 유저에 의해 정확하게 기입되었다면 상기 코드를 포함한다 -를 상기 서버에 전송하는 단계와; 그리고 상기 선택된 의사-패스워드를 해제하고 상기 변경된 세트의 번호가 상기 코드를 포함하면 유저 로그인을 실행시키는 단계를 포함한다.

바람직하게, 상기 패스워드는 상기 패스워드에 있거나 또는 이와 상대적인 위치를 갖는 핫스폿을 포함한다.

바람직하게, 상기 방법은 상기 핫스폿 위치를 토대로 상기 세트의 번호에 상기 코드를 위치시키는 단계를 포함한다.

바람직하게, 상기 코드는 상기 핫스폿의 상기 위치와는 독립적인 상기 패스워드로부터 추론되는 제 1 해시값 및 상기 핫스폿의 상기 위치로부터 추론되는 제 2 해시값으로부터 생성된다.

바람직하게, 상기 방법은 세션 특정 규칙에 의해 상기 코드를 생성하는 단계를 포함한다.

본 발명의 또다른 양상에서, 온라인 또는 다른 통신 환경에서 유저의 신원를서버에 인증하는 방법이 제공되는바, 이 방법은 상기 유저에 관한 공유 정보를 포함하는 로그인 요청을 상기 유저로부터 수신하는 단계와; 상기 로그인 요청을 인증하고 만일 인증되면 상기 유저가 상기 서버에 로그인하기위해 사용하는 로그인번호를 상기 유저에 제공하는 단계를 포함한다.

본 발명의 제 1실시예에 따르면, 한 시스템이 제공되는데, 이 시스템에 의해 신용카드와 같은 전자 지불 카드가 다수의 유저에 제공되며, 이 카드에 나타난 번호는 그 시스템하에서 발행된 모든 그러한 카드에 공통적이다. 이 목적을 위해, 상기 번호는 공용번호(universal number)로서 언급하기로 한다. 뱅크 또는 다른 신용기관과 같은 하나 이상의 적절한 신용제공자들이 이들 카드를 발행할 수 있다.

이 카드들은 대안적인 식별 수단을 통해 개별화된다. 예컨대, 유저는 고유 유저 ID 및/또는 패스워드를 가질 수 있다.

그러한 신용/지불 카드들을 활용하는 방법의 한 예로서, 온라인을 통해 구매를 하고자 하는 유저는 특정 판매 사이트에 접속한다. 이 유저는 컴퓨터, 이동전화 또는 어떤 다른 네트워크 접속장치와 같은 적절한 수단에 의해 상기 사이트에 액세스한다. 이어서, 유저는 도 1에 보인바와 같이 주문 형태로 적절한 상품/서비스를 표시하거나 또는 전자 "장바구니(shopping trolley)"에 상품 및/또는 서비스를 담음으로써 구매 상품 및/또는 서비스를 선택할 수 있다. 판매자는 유저가 "구매"버튼등을 누름으로써 거래를 행하였다는 표시를 유저로부터 기다린다.

만일 유저가 판매자에게 일반적인 지불 정보를 이미 제공하지 않았다면, 판매자는 그 정보를 요청할 것이다. 예컨대, 유저는 도 2에 보인바와 같이 지불형태를 제시받는다. 이에 관하여, 카드 또는 계정번호 필드에 입력된 번호는 공용번호이다. 도 2에서 사용되는 공용번호는 순전히 본 발명의 예시를 위한 목적에서의 번호일뿐 그 어떠한 번호로도 될 수 있다.

공용번호를 입력함으로써, 이 신용/지불 시스템의 모든 유저들이 동일한 신용/지불 카드번호를 공유할 수 있을때 유저의 프라이버시가 유지되며, 따라서 이 번호로 카드 소유자의 신원을 구분하거나 또는 차별화하는 것은 불가능하다.

판매자 사이트는 상기 제시된 번호가 공용번호였음을 인식할 수 있을 것이다. 바람직하게, 한 명령이 판매자의 사이트로부터 유저의 브라우저로 전송되어 콘솔 프로그램을 자동실행시키며, 이 프로그램은 유저와 신용 제공자의 시스템간에 보안 접속을 설정하고 또한 도 3에 보인 바와 같이 콘솔 프로그램이 유저에게 제시되도록 한다.

그러나, 대안적으로, 이 콘솔 프로그램은 자동화될 필요가 없으며, 유저가 (플러그-인 프로그램의 경우) 그의 브라우저내에서 또는 독립형(stand-alone) 프로그램을 실행시킴으로써 이 프로그램을 수동으로 실행시킬 수 있다.

콘솔 프로그램의 중첩 콘솔 스크린 또는 원도우는 유저가 인증서버와 통신할 수 있게 하는 그래픽 인터페이스를 제공한다. 이 인증서버는 바람직하게 하나 이상의 신용 제공자들과는 독립적이다. 다시말해서, 제 3자가 인증서버 및 하나 이상의 신용 제공자들에 대해 관련 신용인증을 제어할 수 있다. 대안적으로, 인증서버는 신용제공자의 직접적인 제어하에 놓인다.

이에 관하여, 본 발명의 실시예에 따르면, 유저는 유저 이름 및 패스워드와 같은 그의 고유 정보를 입력할 수 있다. 유저와 인증서버간의 이와같은 통신은 보안접속이므로 판매자는 유저이름 또는 패스워드에 엑세스 할 수 없다.

인증서버가 유저로부터 고유 정보를 수신하면, 이 서버는 일반적인 방식으로그 정보를 검증한다. 만일 인증이 긍정적이면, 구매자와 판매자간의 거래에 이용되는 한번 사용의 거래번호가 생성된다. 이 거래번호는 임의로 생성되거나 또는 소정 리스트의 번호로부터 검색된다. 인증서버에 의해 수행되는 각각의 연속적인 인증에 대해서 새로운 거래번호가 생성된다. 이 번호는 바람직하게는 상기 인증 서버에 의해 생성되며, 다른 수단 또는 상기 인증서버와 관련된 다른 서버에 의해서도 생성될 수 있다. 또한, 상기 거래번호는 단 한번 사용을 위해 생성된다는 점에서 한번사용을 위한 것으로 설명되고 있지만은, 일단 특정번호가 생성되면 이 번호가 다시는 결코 재생성되지 않는 것임을 의미하는것으로 의도되지는 않는다. 동일 번호가 서로다른 거래들에서 재생성 및 사용될 수 있다.

바람직하게, 상기 거래번호는 도 4에 예시한 바와 같이 인증서버로부터 유저에게 전송된다. 유저는 임박한 거래에서 도 5에 예시한 바와 같이 "카드 또는 계정번호" 필드에서 상기 번호를 변경하거나 또는 대체함으로써 이 거래번호를 사용할 수 있다. 그러나, 바람직하게는 상기 콘솔 프로그램은 유저의 손쉬운 사용을 위해 상기 거래번호를 상기 "카드 또는 계정" 필드에 자동으로 입력한다. 주문을 행하기 위해, 유저는 "YES : Place Order" 필드를 활성화시킬수 있다.

거래번호는 바람직하게 두개의 성분으로 구성되는바, 첫번째 계열의 숫자는 뱅크 또는 카드 발행자를 표시하고, 마지막 계열의 숫자는 현재의 거래에 고유한 거래번호를 표시한다. 예컨대, 거래번호 "4569, 4093, 6011 0523"은 뱅크 코드 "4569 4093 6" 및 거래번호 "011 0523"으로 구성될 수 있다. 이어서, 판매자는 승인을 위해 거래번호를 포함하는 거래 세부사항을 제시함으로써 일반적으로 신용카드 거래를 처리한다. 바람직하게, 인증서버는 이 승인 또는 그와 관련된 다른 서버를 제공한다. 그러므로, 제 3자가 인증서버를 제어하는 경우에, 제 3자의 인증 시스템은 그 거래가 승인 또는 거부되었는지를 판매자의 서버에 신호한다.

본 제 1실시예의 시스템 구조 및 그의 동작이 도 6내지 도 9에 개략적으로 도시되어 있다. 도 6에 관하여, 이 시스템은 지불 게이트웨이(10)를 포함하며, 이 게이트웨이는 유저 ID 및 패스워드 데이터 인터페이스(14)를 가진 인증서버(12), 신용 인증 시스템(16) 및 카드 발행자 호스트 시스템(18)을 포함한다. 유저의 컴퓨터(20) 및 판매자 서버(22)는 서로, 그리고 인터넷(24)을 통해 본 실시예의 시스템과 통신한다.

유저 컴퓨터(20)와 판매자 서버(22)간의 통신은 SSL(보안 소켓 레이어) 데이터 암호화 전송이다. 판매자 서버(22)와 지불 게이트웨이(10)간의 (인증 및 데이터 캡춰를 위한) 통신은 SSLv3 인증 암호화 전송이다. 지불 게이트웨이(10), 인증 시스템(16) 및 카드 발행자 호스트 시스템(18)간의 전송은 인증/데이터 캡춰 전송을 구성 한다.

도 7에 관하여, (도 1의 주문 양식과 유사한) 주문 양식(26)은 판매자 서버(22)에 의해 유저 컴퓨터(20)에 제공된다. 전술한 바와 같이, 유저가 공통 번호를 제공하고 이 번호가 판매자 서버(22)에 의해 식별될때, 판매자 서버(22)는 콘솔 프로그램(28)을 실행하며, 이 콘솔 프로그램은 유저에게 유저 이름 및 패스워드정보를 입력하도록 프롬프트한다. 이 정보는 SSL 데이터 암호화 전송(30)으로서 지불 게이트웨이(10)를 통해 인증서버(12)에 전송된다. 도 8에 관하여, 만일 유저에의해 제공된 유저 이름 및 패스워드의 세부사항이 진실이면, 인증서버(12)는 유저의 ID를 인증하며, 유저의 계정 세부사항(32)을 액세스한다. 이어서, 인증서버(12)는 거래번호(34)를 생성하고 이 거래번호를 SSL 데이터 암호화 전송(36)에 의해 유저 컴퓨터(20)에 전송한다.

도 4 및 도 5에서 설명한 바와 같이, 유저는 수신된 거래 번호를 주문양식(26)에 삽입한다. 이 주문 양식은 판매자 서버(22)에 전송되고, SSLv3 암호화 전송에 의해 이 판매자 서버로부터 인증을 위해 신용 인증서버(16)로 전송된다. 도9에 관하여, 만일 신용 요청이 신용 인증서버(16)에 의해 인증되면, 신용 인증 서버(16)는 SSLv3인증 암호화 전송(40)으로서 신용 인증(38)을 지불 게이트웨이(10)에 전송한다. 이어서, 지불 게이트웨이(10)는 신용 인증(38)을 판매자 서버(22)에 전송한다. 그러나, 중요하게, 신용 인증(38)은 "발행시간" 필드(42) 즉, 거래번호가 발행된 시간을 포함한다, 이 실시예에서, 신용 인증(38)을 판매자 서버(22)에 전송하기에 앞서, 지불 게이트웨이(10)는 거래번호가 발행된 시간을 지불 게이트웨이(10)가 신용 인증(38)을 수신한 시간과 비교한다. 이들 두 시간간의 차이가 소정의 최대치보다 작은 경우에, 신용 인증(38)은 판매자 서버(22)로 전송될 것이다.

따라서, 신속하게 이용되지 않으면 거래 번호가 효과적으로 만료할 때 레벨보안이 추가된다. 결과적으로, 거래번호는 유한 시간동안 한번 이용되고 그리고 유효해지며, 이들 보안 측정들중 어느것이 또한 유효해진다.

그러므로, 본 발명은 유저의 실제 신용정보에 관한 정보를 밝히거나 노출시킴이 없이 유저의 신용카드 계정을 이용할 수 있게 하여, 판매자 및 판매자의 잠정적인 해커로부터 온라인 프라이버시를 보장해준다. 특히, 유저는 거래를 행하는 동안 익명 상태에 있게 될 수 있다. 또한, 만일 해커가 판매자의 서버 및 (만일 거래정보가 판매자 서버에 저장된다면) 그 판매자 서버에 저장된 거래 정보에 액세스를 얻는다하더라도, 이 정보는 재사용될 수 없는 거래 번호들로 구성되기 때문에 사용할 수 없게된다.

본 발명은 또한 동작의 안전성 및 관리의 용이성을 제공하는데 , 이는 단일 신용카드는 카드 발행자가 다수의 유저들을 관리하는 것을 간단하고 효과적으로 해주기 때문이다. 또한, 인증이 유저 ID 및 패스워드를 통해 이루어지는 경우, 거래를 인증하는데 어떤 형식의 디지털 보증이 필요없게 되는바, 이는 비용 및 작업량을 감소시켜준다. 또한, 인증 정보는 유저 및/또는 신용 제공자에 의해 쉽게 변경될 수 있는바, 이는 또한 시스템을 용이하게 이용할 수 있게 해준다.

본 발명의 추가적인 특징은 허락된 각 인증에 대해 유저에게 거래 확인을 제공하는것이다. 이 거래확인은 이메일 어드레스 및/또는 무선 엑세스 프로토콜(WAP)이동 전화 브라우저, SMS 또는 다른 어떤 네트워크 접속 어드레스와 같은 하나 또는 그 이상의 미리 선택된 어드레스를 통해 유저에게 제공된다. 이 거래 확인은 본질적으로, 발생된 거래에 대한 확인이 된다.

이 "거래 확인"은 카운터 체크로서, 유저의 인증 절차동안에는 관계하지 않는바, 부정한 유저는 실제 유저가 통보 받게 되는 이메일 계정을 알 수 없게 된다. 그러므로, 만일 부정 거래가 발생하는 경우, 실제 유저는 이메일을 통해 허락되지않은 거래를 통보 받을 수 있어 이에 대한 조치를 취할 수 있게 된다.

추가적인 특징으로서, 유저의 신원이 판매자에 노출되지 않도록 하기 위해, 유저에게 편리한 특정 숍(shop) 또는 카페(cafe)와 같은 사전 정해진 위치에 제공될 배송을 유저가 요청할 수 있게 하는 것이다. 이러한 방식은 특정 숍 또는 카페의 지원이 이루어지도록 요청할 수 있다.

대안적으로, 유저는 그를 다른 유저와 구별하거나 또는 그의 주문을 다른 사람이 행한 주문과 구별하기위해 "가상 어드레스"를 입력할 수 있다. 가상 어드레스는 그의 주된 기능이 위치가 아닌 신원을 특정하는 것이기 때문에 실제 어드레스이거나 또는 실제 어드레스가 아닐 수 있다. 이는 심볼 "＆"와 같은 그러한 적절한 ASCⅡ 분리 문자에 의해 상기 가상 어드레스와 분리된 고유 PIN (Personal Identification Number)과 함께 가상 어드레스를 입력함으로써 이루어진다. 이 문자는 분리기로서 역할을 하여, 상기 가상 어드레스 및 PIN(또는 이와 등가물) 모두는 동일 입력 필드에 기입될 수 있다. 대안적으로, 만일 모든 어드레스들이 어떤 방식(예컨대, 번호에서 끝이 없는)에서 균일하고 그리고 (예컨대, 배타적으로 숫자로 구성된)PIN 역시 그러하다면, 이 시스템은 PIN으로부터 상기 가상 어드레스를 구분할 수 있으며, 상기 분리기는 생략될 수 있다.

그러므로, 예컨대, 만일 본 실시예에서 상기 가상 어드레스가 "34 Moon Avenue, The Moon"이고 상기 PIN이 "1234" 이면, 유저는 프롬프트시 "34 Moon Avenue, The Moon＆1234"를 입력할 수 있다.

알선자(courier)와 같은 그러한 상인(vendor), 카페 또는 심지어 선택되거나또는 신용있는 판매자는 이용 당 약간의 비용으로 구매자(유저)에게 그러한 공통 어드레스의 이용을 제공한다. 그러한 지불 카드의 모든 유저들은 동일한 가상 어드레스를 이용할 수 있는바, 각 유저들은 그의 고유한 PIN을 토대로 서로로부터 구별될 수 있다. 중앙 서버는 알선 회사가 제공하는 다양한 서로 다른 공통의 가상 어드레스를 인식하고, 처리를 위해 알선 회사의 서버에 배송한다. 그러면, 알선 회사의 서버는 "＆"가 분리된 PIN을 찾고, 이 PIN을 알선자의 고객(궁극적인 구매자 또는 유저)의 실제 어드레스가 있는 저장된 데이터 베이스와 비교하여 판매자의 제품보관소로부터 구매자의 실제 어드레스로 후속 배송을 행한다.

본 발명의 다른 실시예에 따르면, 신용카드는 오프라인으로도 이용될 수 있다. 본 실시예에서, 이 카드는 또다른 고유의 오프라인 신용 카드(OEC) 번호를 갖는다. 이 OEC 번호는 상기 카드의 마그네틱 스트라이프 및/또는 이 카드에 내장된 스마트 칩에 저장될 수 있다. 이 신용카드 소유자는 이 카드를 오프라인으로 이용할 수 있어, OEC 번호는 비록 그 번호가 노출되었다 하더라도 그 어떤 온라인 거래에 사용될 수 없게 해준다. 온라인 및 오프라인 거래를위한 개별 인증 네트워크는 상기 OEC 번호가 그 어떤 온라인 거래를 위해 사용될 수 없게 해줌으로써 오직 "카드 제시를 통한" 거래에서만 이용될 수 있게 해준다.

본 실시예에서, 각 온라인 및 OEC 거래는 등록될 수 있고, 그의 세부사항이 이메일 계정, 이동 전화 WAP 어드레스 또는 SMS와 같은 그러한 유저의 특정 어드레스에 제공된다. 이는 유저에게 온라인 거래 이건 오프라인 거래 이건 간에 관계없이 수행된 모든 거래에 대한 완전한 정보를 부여함으로써, 유저가 원할 시 그의 온라인 및/또는 오프라인 계정을 불능으로하거나 또는 활성화 할 수 있다.

전술한 바와 같이, 본 발명은 WAP 인에이블 이동 전화 또는 SMS를 통해 이루어질 수 있다. 제 1실시예에서, 유저는 전술한바와 같은 방식으로 전화를 통해 유저 ID 또는 PIN을 입력할 수 있다. 일단 검증되면, 유저는 판매자에게 제공된 이동전화 브라우저에서 전화번호를 수신하여 거래를 완수할 수 있다.

본 발명의 대안적인 실시예에서, SIM 카드를 갖는 WAP 인에이블 이동 전화에서 실시될 수 있는바, 이는 하기에 설명하기로 한다. 특정 거래에 대한 인증을 얻기위하여, 유저의 전화와 SIM 카드 인증 서버 사이에 보안 접속이 설정된다. 제 3자가 하나 또는 그 이상의 신용 제공자로부터의 허가하에서 이 서버를 제어하는데, 이는 신용 제공자가 선택적으로 제어할 수도 있다. 신용 제공자는 또한 유저의 통신 서비스 제공자가 될 수도 있다.

이 사이트에서, 유저는 그의 SIM 카드를 통해 인증을 받는다. 보다 확실한 보안을 위해, 유저는 그의 SIM 카드 뿐만아니라 유저에 의한 PIN 입력을 이용하여 인증될 수 있다. 만일 인증이 긍정적이면, 거래 번호가 발생된다. 이 거래번호는 보안 접속을 통해 유저에 전송되어, 전술한 실시예에서 언급한 방식으로 판매자와 함께 거래를 완수한다.

대안적으로, 거래번호를 유저에 제공하는 대신에, 이 거래번호는 인증서버(또는 이와 관련된 다른 서버)에 유지될 수 있으며, 일단 이 번호가 인증서버에 의해 수신되면 판매자의 주문 양식과 관계하게된다. 이어서, 거래는 만일 적용 가능한 경우 인증서버에 의해 허가된다. 그 번호가 판매자에게 전송되고 거래를 위한신용카드 번호로서 유지되며, 또한 거래 확인이 유저의 사전 선택된 이메일 및/또는 이동 전화 어드레스를 통해 유저에게 전송된다. 이 대안적인 검증 프로세스는 본 발명의 전술한 실시예에 적용될 수 있다. 포괄적인 발명 개념내에서 여러 가지변경 및 추가들이 가능한바, 당업자이면 잘 알 수 있을 것이다.

본 발명의 다른 실시예에 따르면, 예컨대, 콘솔 스크린을 나타내는 대신에, 유저의 신용 제공자 서버 또는 이 서버에 의해 제어되는 다른 서버에 링크가 제공되어 그 사이트에서 인증을 완수한다.

또한, 온라인 판매자는 스스로 본 발명의 공용 지불 카드를 제공할 수 있다.

더욱이, 유저로부터 고유 정보를 얻는 것은 유저가 그의 이름 및 패스워드를 입력함에 의해 발생해야 함을 필요로 하지 않는다. 예컨대, 인증은 설치된 하드웨어/소프트웨어 형태로 인증 서버가 처리를 해야하는 일부 고유 특징의 자동적인 검출에 의해 유저 입력없이도 이루어질 수 있다.

추가로, 하나 이상의 공용 번호를 갖는 것이 가능하여, 다수의 유저들이 각각의 공용 번호를 사용할 수 있다. 예컨대, 다수의 서로다른 신용 제공자들은 본 발명을 이용할 수 있으며, 각 신용 제공자는 그가 그의 고객에게 제공하는 그 자신의 공용 번호를 가질 수 있다.

도 10에 관하여, 본 발명의 또다른 실시예에 따르면, 거래 번호는 두 단계의 프로세스를 통해 유저/구매자에게 제공된다. 인증 서버(12)는 각 유저(구매자)(42)에 대해, 이러한 목적을 위해 예약된 데이터베이스에 이미 발생된 가능한 거래 번호들의 리스트(44)를 유지한다. 도 11에 관하여, 유저(42)는 요구되는 고유 식별정보(즉, 유저 이름 및 패스워드)를 콘솔 스크린(28)에 입력하고, "OK"를 클릭하여 그 정보를 인증 서버(12)에 전송한다. 도 12에 관하여, 인증서버(12)는 (상기 ID 정보는 유효한 것으로 가정하면서) 기호열, 본 예에서는 "＆jd(fkwse@2)"로 구성되는 선택 또는 "모프" 코드(46)를 제공하거나 발생함으로써 응답한다. 이어서, 모프코드(46)는 인증 서버(12)에 의해 사용되어, 예약 리스트(44)에 있는 거래 번호들 중 어느 번호가 사용되는지를 선택(본 예에서는 거래 번호(48)가 사용됨)한다. 이 선택은 적절한 방법에 의해 이루어질 수 있는바, 모프 코드로부터 체크섬이 발생될 수 있으며, 이의 값은 사용될 거래번호들의 예약 리스트에 있는 엔트리를 특정한다. 대안적으로, 모프 코드(46)는 임의 수 발생기의 시드(seed)로서 이용될 수 있으며, 결과적인 임의 수는 사용될 거래 번호들의 예약된 리스트에 있는 어떤 엔트리를 특정한다.

대안적으로, 이용가능한 거래 번호들의 예약된 리스트에 의존하지 않고, 모프 코드(46)는 거래 번호를 생성하도록, 각 문자의 Ascii 값에 근거하여 공용(또는 공용) 번호에 추가될 수 있다.

도 13에 관하여, 그렇게 특정된 거래 번호(48)는 이제 활성화되고 즉, 유저(42)에 의한 사용이 유효한 것으로 기록되고, (판매자에 후속 제시를 위해) 유저에 전송 (이는 원도우(52)에 디스플레이 된다) 되거나 또는 이전의 실시예들에서 언급한 바와 같이 (도시되지 않은) 판매자에 직접 전송된다.

거래 완료후, 활성화된 거래 번호(48)는 비활성화되어 쓸모없게 된다.

어떠한 후속 로그온에서, 인증서버(12)는 발행된 모프 코드가 이전의 유저로의 어떤 모프 코드와는 다름을 확신하고, 각 거래를 위해 선택된 거래 번호를 임의 추출한다.

도 14에 관하여, 각 유저에 대한 예약 번호 데이터베이스는 또한 또 다른 유저의 그것과 주기적으로 교환하여, 카드 소유자의 제시된 거래번호가 오로지 단 한번 사용하고 버려지게 하여 각 거래에 대해 보안이 유지되도록 한다. 따라서, 유저(42)의 예약 리스트(44)는 유저(56)의 예약 리스트(54)와 교환될 수 있어, 다수의 유저를 갖는 전형적인 시스템에서 유저(42)는 예약 리스트(54)를 그리고 유저(56)는 예약 리스트(44)를 선택적으로 가질수 있으며, 이 예약 리스트들은 주기적으로 유저들사이에 임의로 재할당될 수 있다.

상기 실시예들중 어느 것에서 또 다른 보안 레이어로서, 유저에 의해 인증서버에 전송될 요청된 고유 식별 정보(즉, 유저 이름 및 패스워드)는 하나 또는 그 이상의 "핫스폿"을 포함할 수 있다. 각 핫스폿은 유저 이름 또는 패스워드의 문자들중 어느 문자 다음의 원하는 위치를 더블 클릭함으로써 유저 이름 또는 패스워드내로 삽입된다. 그러한 핫스폿은 일반적으로는 유저에 의해 유저 이름/패스워드 세부사항과 함께 기록되지않으며, 실제로 본 발명에 따라, 컴퓨터 스크린에 보여질 필요가 없다. 그러나, 이들은 - 유저 이름 및 패스워드와 같은 방식으로 - 유저 및 신용 제공자들에 의해 동의된다.

도 15a에 관하여, 먼저, 유저 이름(58) 및 패스워드(60)가 - 인증 서버(12)또는 판매자 서버(22)의 프롬프트에서 - 이러한 목적을 위해 제공된 콘솔 스크린(28)에 통상적인 방식으로 입력된다. 도 15b에 관하여, 유저는 핫스폿을 삽입하기 위해 다수의 위치에서(본 예에서는 유저 이름 (58) 및 패스워드(60)의 8번 문자뒤에서) 더블 클릭한다. 각 핫스폿은 사실 각 유저 이름 또는 패스워드의 일부로서 간주될 수 있다. 예시된 실시예에서, 핫스폿의 위치는 "1"문자로 표시되어 있다. 그러나, 핫스폿이 입력된후 어떠한 가시적 문자들도 디스플레이 되지 않도록 하는 것이 바람직하다.

이러한 핫스폿은 또한 거래번호 자체에 추가될 수 있다. 이 거래번호는 전형적으로 팝업 윈도우 또는 콘솔에서 유저에 의해 수신될 것이다. 그러면, 유저는 거래번호를 복사하여 이를 판매자 서버에 의해 제공된 온라인 주문 콘솔내에 페이스트한다. 이를 행하기전(또는 이를 행한 후 그러나 판매자의 주문 양식에서 "OK"번튼을 선택하기전) 유저는 하나 또는 그 이상의 핫스폿을 (사전에 신용 제공자와 배열된) 소정위치를 더블 클릭함으로써 상기 거래 번호에 삽입될 수 있다. 본 실시예에서, 이들 핫스폿이 없으면 상기 거래번호는 불완전하며, 유효하지 않은 것이된다.

선택적으로, (핫스폿을 갖거나 갖지않는) 일반적인 유저 이름 및 패스워드에 추가하여, 유저는 규칙적인 간격으로 각 로그온마다 또는 인증 서버(12)가 비정상적인 로그온 시간이나 로그온 행위를 검출할때 질문을 받을 수 있다. 이와같은 소위 "오늘의 질문"은 상기 유저 이름 및 패스워드에 추가하여, 제 2레벨의 패스워드로서 역할을 한다. 나이, 주소와 같은 유저 개인의 세부사항 또는 가장 기억에 남는 순간 이나 가장 좋아하는 자동차와 같은 상기 목적을 위해 특별히 고안된 정보들이 "오늘의 질문" 패스워드에 대한 대답이 되도록 선택될 수 있다. (인증 서버/당사자를 등록하거나 또는 여기에 처음으로 로그온하기 위한) 초기 유저 등록 동안, 유저는 일련의 질문을 받고, 그 대답은 유저의 이름/패스워드 정보에 추가로 "오늘의 질문" 로그온 필드를 구성할 것임을 통보받는다.

이들 질문은 유저가 로그온하기 위해 입력해야 하는 유저 이름 및 패스워드를 동반하도록 회전되며, 유저는 정상적인 로그온 시도에서 다른 "오늘의 질문"에 답하도록 요구받는다.

이러한 "오늘의 질문"의 회전은 키보드 또는 키패드장치를 통한 로그온 인증과 관련된 보안 레벨을 효과적으로 증대시켜준다.

따라서, 도 16에 관하여, 인증 서버(12)로의 로그인에서, 유저에게 각각 유저 이름 및 패스워드에 대한 일반적인 필드(64, 66)을 포함하는 로그인 콘솔 스크린(62)이 제시된다.

추가로, 콘솔 스크린(62)은 유저가 "OK" 버튼을 선택하기전 필드(70)에 정답을 삽입함으로써 응답해야 하는 "오늘의 질문(68)"을 포함한다. 유저는 패스워드와 이 대답이 정확한 경우에만 인증 서버(12)로 로그온되어 (전술한 바와 같이) 거래번호를 제공받는다.

하나의 대안적인 방법에서, "오늘의 질문"에 대한 응답은 유저에 의해 패스워드와 같은 필드에 입력된다. 따라서, 도 17a에 관하여, 유저에게는 다시 로그인 콘솔 스크린(74)이 제시되는바, 상기 콘솔 스크린은 (핫스폿을 갖거나 갖지않은) 각각 유저 이름 및 패스워드에 대한 입력필드(76 및 78)를 포함한다. 콘솔 스크린(74)은 또한 "오늘의 질문"(80)을 포함한다. 이 도면에 보인 바와 같이, 유저는 일반적인 방식으로 필드(76 및 78)에 유저이름 및 패스워드를 입력한다.

도 17b에 관하여, 패스워드가 입력되면, 필드 분리기(82)가 패스워드 필드(78)에서 패스워드 뒤에 삽입된다. 이 필드 분리기(82)는 패스워드 철자가 정확히 입력되었는지 여부에 관계없이 정확한 패스워드 문자의 수(본 예에서는 9)가 검출되면 인증 서버(12)에 의해 자동으로 삽입된다.

도 17c에 관하여, 유저는 이후 필드 분리기(82) 바로 다음에, "오늘의 질문"(80)에 대한 대답(84)을 입력하는데, 이때 유저는 대답(84)이 단지 패스워드의 연장인 것 처럼 패스워드를 입력한 후 바로 대답(84)을 계속해서 타이프한다. 대답(84)은 패스워드와 동일한 방법으로 마스크된다. 도시된 예에서, 그렇게 입력된 대답(84)은, 예를 들어 "오늘의 질문"(80)이 "당신의 생일이 언제입니까? [ddmmyyyy]"였을 경우 요구되는 대답이 될 "21061965"로 읽혀질 수 있다. 유저가 요구되는 대답(84)을 입력한 후에는, "OK" 버튼(86)을 선택하여 로그온을 완료한다. 도 16과 관련하여 설명된 바와 같이, "오늘의 질문"(80)은 규칙적으로 회전되며, 초기 유저 등록 동안 유저로부터 얻어진 정보에 기초한다.

도 15a 및 15b에 관하여 상기 설명된 것과 유사한 다른 대안적인 접근에 있어서, 신원 확인은 또한 핫스폿과 함께 패스워드를 요구하지만(패스워드와 핫스폿은 유저에 의해 초기에 제공된다), 이러한 패스워드 및 핫스폿은 시스템에 의해 인증 서버 또는 다른 것에 저장되지 않는다. 이러한 접근에서, 상기 시스템은 두 개의 "해시" 값들(패스워드로부터의 제 1 값 및 핫스폿 위치로부터의 제 2 값) 및 (패스워드 및 핫스폿 위치로부터의) 의사-패스워드들의 커다란 풀을 초기에 발생시키고 이후의 이용을 위하여 저장한다. 이는 유저의 계정이 바람직하게는 인증 서버상에서 설정될 때 이루어진다. 이러한 해시값들 및 의사-패스워드들을 발생시키는 데에는 어떠한 적절한 규칙들 또는 알고리즘들이 이용될 수 있다.

의사-패스워드의 풀로부터 활성화를 위한 의사-패스워드를 선택하는 데에 이용되는 규칙 또는 규칙들은 RSA 보안으로부터의 MD5와 같은 어떠한 적절한 기존의 알고리즘들로부터 조정될 수 있다. 그러나, 어떤 의사-패스워드가 선택될 것인 지를 결정하는 데에 서로 다른 규칙들 또는 알고리즘들의 많은 라이브러리가 이용되기 때문에, 규칙 또는 알고리즘을 결정하는 해킹이 훨씬 더 어려워진다.

이에 따라, 예를 들어 유저는 패스워드/핫스폿 "ace │ 3"(여기서 문자 " │ "는 핫스폿의 위치를 나타낸다)을 입력하며, 이를 기초로 시스템은 패스워드로부터 10,000의 제 1 해시값, 핫스폿 위치로부터 4의 제 2 해시값, 및 의사-패스워드들의 풀을 발생시킬 수 있다:

이러한 의사-패스워드들중 어떤 것도 -초기에는- 활성화되지 않으며, 어떤것도 로그인시 패스워드에 대하여 프롬프트될 때 유저에 의해 입력될 수 있는 패스워드로서 유효하지 않다.

유저가 로그인하고자 할 때에는, 먼저 로그인 대화 박스 유저 이름 필드에 적절한 유저 ID(예를 들어, "ace_sing")를 입력한다.

유저가 로그인 대화 박스 내의 패스워드 입력 필드에 패스워드를 입력하면, 유저 ID는 인증 서버로 전송된다. 인증 서버는 의사-패스워드들의 풀중 하나를 선택하여 활성화시키고, 제 1 해시값으로부터 두 개의 번호들, 즉 인증 서버 상에 저장될 제 1 번호(X) 및 유저 클라이언트 장치/단말기로 전송될 제 2 번호(Y)를 발생시킴으로써 응답한다. X 및 Y는 세션에 특정되는 두 개의 개별적인 규칙들 또는 알고리즘들에 의해 발생된다. 이러한 알고리즘들의 라이브러리는 제 1 해시값으로부터의 패스워드 X 및 Y간의 관계를 예측하기가 더 어려워지도록 효과적으로 임의로 순환될 것이다. 또한, 결과적으로 X 및 Y는 각 로그인 세션에서 이전의 X 및 Y 값들과 거의 확실하게 다를 것이다.

본 예에서, 그리고 이러한 특정한 세션에서, 알고리즘은 다음과 같을 수 있다:

X = (제 1 해시값) × 2/4 및

Y = (제 1 해시값) × 2/8,

결과적으로, 본 예에서 또한, 제 1 해시값은 10,000이고, X=5,000이며, 그리고 Y=2,500이다.

인증 서버는 이후 X 및 Y 값들 간의 관계(Z)를 나타내는 제 3 값을 결정한다. 가장 간단한 경우, 이는 단지 X와 Y 간의 차이가 될 수 있다. 따라서, 본 예에서 , Z=X-Y=2,500이다.

다른 알고리즘이 이용되어 이러한 Z값으로부터 팩터(R)를 계산하며, Z는 이후 R에 따라, 바람직하게는 R의 값 만큼 Z를 감소 또는 증가시킴으로써 변경된다. 이에 따라, 본 예에서는 2,500의 Z로부터 32.55의 R값을 생성하는 알고리즘이 이용된다고 가정하자. 이러한 경우, Z'가 Z-R이면, Z'=2,500-32.55=2,467.45이다.

지금까지, 상기 시스템은 X, Y, Z, R 및 Z'를 발생시킴에 있어서 제 1 해시값 만을 이용하였다. 그러나, 상기 시스템은 이제 Z'값이 번호들의 시퀀스 내에 있어야 하는 정확한 지점을 결정하기 위하여 (핫스폿 위치로부터의) 제 2 해시값을 이용하여, 패스워드, ace3 내의 5개의 가능한 핫스폿들(즉, " │ ace3", "a │ ce3", "ac │ e3", "ace │ 3" 및 "ace3 │")을 나타낸다. 다른 알고리즘 또는 알고리즘들을 이용하여, 서버는 Z의 값으로부터, Z의 미리 결정된 최대 편차와 가까운 또는 그 내에서 4개의 (즉, 가능한 위치들의 수 보다 1이 적은) 번호들을 발생시킨다. Z-2,500인 본 예에서, 이들은 다음과 같이 될 수 있다:

제 2 해시값(본 예에서는 4)은 시스템이 이러한 번호의 시퀀스 내의 어디에 "지정된" 위치에 Z'를 위치시킬 것인 지를 결정한다.

이러한 번호의 시퀀스는 이후, 유저가 자신의 컴퓨터에 최초 패스워드 및 핫스폿을 입력하는 동안, 클라이언트 장치(예를 들어, 유저 컴퓨터)로 전송된다. 핫스폿이 정확하게 입력되면, 번호 시퀀스 내의 모든 번호들:

은 R값, 32.55 만큼 증가 또는 감소됨으로써(본 예에서는 증가된다), 변형된 번호 시퀀스:

를 생성한다.

즉, Z가 R 만큼 감소되어 Z'를 생성했다면, 번호 시퀀스는 R 만큼 증가하여 변형된 번호 시퀀스를 생성해야 한다(그 반대의 경우도 마찬가지이다).

변형된 번호 시퀀스는 인증 서버로 전송되며, 인증 서버는 제 2 해시값(즉, 4)에 의해 표시되는 변형된 번호 시퀀스 내의 지점에 위치되는 번호(즉, 2,500)를 추출하며, 그리고 이 번호와 (저장된 또는 X 및 Y로부터 재생된) Z의 값을 비교한다.

본 예에서 R 및 Z'의 값들은 명확성을 위하여 선택된 것으로서, 실제 동작시 Z' 및 R의 값들은 바람직하게는 (인증 서버로 역전송될 변형된 번호 시퀀스를 얻기 위하여, 모든 번호들이 여전히 동일한 R값 만큼 증가 또는 감소함에도 불구하고)번호 시퀀스가 인식가능한 패턴을 나타내지 않도록 발생된다.

중요하게는, 패스워드 내의 가능한 핫스폿들을 나타내는 번호 시퀀스(패스워드 "ace3"의 예에서는 5)는 항상 다르고, 번호들의 스스로의 값이 서로 간에 조금씩 다르기 때문에, 시스템 도청(tapping) 및 번호 시퀀스의 검사에 의해 핫스폿의실제 위치를 알아내기가 어렵다. 따라서, 해커는 제 1, 2 해시값들을 알고 있다고 할지라도 시스템을 접속할 수 없다.

인증 서버가 변경된 번호 시퀀스 내의 지정된 위치에서의 번호와 Z가 매치한다고 검출하면, 선택된 의사-패스워드가 해제되고, 유저는 인증되며 로그인이 계속된다.

이에 따라, 유저의 관점에서는 단일 패스워드가 이용될 수 있기 때문에, 유저는 변경된 패스워드들을 기억할 필요가 없다. 하지만, 핫스폿 위치는 안전성을 부가하기 위하여 주기적으로 변경될 것이다.

이에 따라, 이러한 접근에서, 상기 시스템은 다음과 같은 세 개의 고장 안전메커니즘들을 갖는다:

i) 시스템 접속은 단일 패스워드에 의존하는 것이 아니라, 의사-패스워드들의 커다란 풀로부터의 의사-패스워드에 의존한다.

ii) 이러한 의사-패스워드 풀로부터의 단일 의사-패스워드의 선택은 어떠한 적절한 알고리즘에 의해 결정될 수 있으며, 따라서 초기 패스워드와 핫스폿 간의 관계, 및 어떠한 특정한 로그인에 대한 풀로부터의 궁극적인 의사-패스워드는 본질적으로 제 3 자에 의해 예측될 수 없다.

iii) 선택적으로, 유저의 핫스폿의 위치는 바람직하게는 각 로그인 마다 동일함에도 불구하고, 그 핫스폿의 위치를 나타내는 번호들 또는 문자들은 핫스폿의 위치가 쉽게 해독되지 못하도록 각 로그인 마다 변경될 수 있다.

다른 유사한 접근에서, 유저가 제공하는 패스워드는 시스템에 의해 두 개의부분들을 포함하는 것으로서 처리된다. 이는 유저에 의해 규정되는 핫스폿에서, 또는 시스템에 의해 규정되는 위치에서 이루어질 수 있다. 시스템에 의해 규정되는 경우, 분할 위치는 (예를 들어, n번째 기호 후에, 또는 제 2 위치가 m개의 기호들을 포함하도록) 고정되거나, 또는 지정되며 가능하게는 유저가 패스워드에 대하여 프롬프트될 때 마다 변할 수 있다. 이에 따라, 예를 들어 유저는 패스워드 "PASSWORD123"을 제공하고, 제 2 부분이 네 개의 기호들, 즉 "D123"을 포함하도록 상기 패스워드가 분할될 것임을 시스템에 의해 통지받는다(또는 핫스폿에 의해 지정된다). 이에 따라, 이러한 마지막 네 개의 기호들은 전체 패스워드로부터 "절단(cut-away)"되는 것으로서 설명될 수 있다.

시스템이 사용에게 패스워드를 입력할 것을 프롬프트하면, 유저는 단지 제 1 부분 만을, 즉 절단된 부분을 뺀 패스워드 또는 본 예에서는 "PASSWOR"를 입력해야한다.

상기 시스템은, 바람직하게는 정확한 제 1 부분이 입력된 경우에만, 유저에게 제 2 또는 절단된 부분에 대한 정보를 입력할 것을 프롬프트한다. 요구되는 정보는, 예를 들어 제 2 부분 전체(본 예에서는 "D123"), 제 2 부분의 세 번째 기호와 같은 특정한 기호(본 예에서는 "2"), 또는 제 2 부분의 기호들의 다른 어떠한 조합들이 될 것이다.

바람직하게는, 상기 시스템은 유저가 제 1 부분을 정확하게 입력한 직후, 그리고 제 2 부분에 대하여 요구되는 정보를 프롬프트하기 전에, (도 17B에 도시된 필드 분리기(82)와 유사한) 패스워드 점(dot)을 입력한다.

다른 접근에서는, 유저는 "오늘의 질문" 또는 패스워드에 대한 대답 대신, "패스어구(Passphrase)"를 프롬프트한다. 이러한 패스어구는 유저에 의해, 바람직하게는 계정이 설정될 때와 같은 초기에 제공된다. 유저가 로그인을 시도할 때 마다, 시스템은 유저에게 (패스워드처럼) 전체 패스어구 또는 패스어구의 지정된 부분 또는 부분들을 입력할 것을 요구한다. 예를 들어, 패스어구가 "이것은 나의 패스어구이다"였고, 그리고 유저가 패스어구의 세 번째 단어를 입력할 것을 프롬프트되면, 유저는 그의 신원을 확증하기 위하여 "나의"를 입력해야 할 것이다.

선택적으로, 상기 시스템은 각 로그인시 초기에 입력될 패스어구의 특정 부분을 지정하고, 이 부분이 정확히 입력된 후에만 패스워드 점을 디스플레이하며, 그리고 상기 설명한 바와 같이 패스어구의 하나 또는 그 이상의 다른 부분들을 입력할 것을 유저에게 프롬프트한다.

본 발명의 또 다른 실시예에 따르면, 유저가 금융 거래를 어디(인터넷 또는 다른 곳에서의 물리적인 상점)에서 수행하는 지에 상관없이, 유저는 개인의 신용 또는 차변 카드와 함께 WAP 또는 SMS 인에이블 이동 전화를 이용하고, 자신의 개인신용 (지불) 카드 번호를 판매자에게 알려준다. WAP 전화의 경우, 신용 인증 요구를 수신하게 되면, 신용 카드 발행인 서버는 iWAPGS 서버로 하여금, 임박한 거래의 유저의 WAP 이동 전화에 경보를 전송하게 하며, 유저는 거래가 실제로 (다른 어떠한 당사자가 아닌) 유저에 의해 이루어지고 있음을 증명하는 (그리고 인증하는) (바람직하게는 미리 협의된 PIN) 인증 코드를 카드 발행인에게 전송함으로써 응답하며, 결과적으로 카드 발행인 서버는 거래를 완료할 수 있게 된다. 인증 코드가 제시되는 경우에만, 카드 발행인이 거래를 승인할 것이다. 일단 거래가 완료되면, 유저는 카드 보유자에게 완료된 거래 정보의 세부사항들을 알려주는 제 2 iWAPGS 거래 통지를 수신한다.

실제로, 인터넷 및 카드 제시(card-present) 거래들에 있어서, 유저의 신용카드 번호는 유저가 WAP 이동 전화를 통하여 인증 코드를 제시할 때 까지, 이용할 수 없다. 이러한 시스템은 카드 소득 은폐(card skimming)와 같은 사기적인 실행들로부터 (웹-기반 카드 사기 보다 훨씬 더 높은) 카드 제시 카드 사기를 잠재적으로 감소시킬 수 있다. 이러한 WAP 지불 카드 시스템은 또한 상기 설명된 "모프 코드"접근에 이용되도록 실시될 수 있다.

iWAPGS 서버 거래 시스템은 또한, 컴퓨터 유저가 특정한 컴퓨터 서버/네트워크에 로그인하고자 할 때와 같은, 유사한 거래 기반 컴퓨터 프로세스들에 대하여 적응될 수 있다. 유저가 유저 ID 및 패스워드를 이용하여 로그인하고자 할 때, 목표 서버는 또한 (iWAPGS 서버를 통하여) 유저의 이동 전화에 경보를 전송하며, 유저는 SMS 또는 WAP 프로토콜을 이용하여 단순히 "예" 또는 "아니오" 확인, 또는 미리 협의된 확인 PIN 번호로 응답하여, 서버로 시도된 접속을 확인 또는 부정한다.

유저가 정확한 이동 전화를 통하여 유효한 확인 대답으로 응답할 때에만, iWAPGS 서버는 유저가 로그인하고자 하는 컴퓨터 서버/네트워크로의 유저 접속을 허가한다. 이러한 접근은, 공통/범용 지불 카드 시스템에 대한 지불 인증 및 결제(clearance) 이전에 이동 전화를 통하여 유저(이 경우에서는 구매자)로부터의 확인 응답을 기다리는 iWAPGS 서버와 유사하다.

본 발명의 다른 실시예에 따르면, 유저는 금융 거래를 달성하고자 하는 목적으로 판매자에게 지불 번호로서 (상기 설명된) 범용 또는 공통 번호를 전송한다. 그러나, 이러한 공통 지불 번호를 제시하기 전에, 유저는 먼저 (카드 발행인에 의한) 인증을 위하여 웹 서버를 로그온한다. 유저가 먼저 로그온하여 카드 발행인 서버로부터 인증을 얻지 않은 채 제시되는 공통 번호는 어떠한 거래에 대해서도 이용될 수 없다. 인증에 의해, 카드 발행인은 거래 PIN 번호를 발생시키는 바, 이 거래 PIN 번호는 한 거래에 대해서만 유효하며 거래가 완료된 후에는 버려진다. 이러한 거래 PIN 번호는 판매자의 온라인 구매 신청 양식 (또는 유저에게 지불 번호, 선적주소 등과 같은 정보를 제시할 것을 요구하는 다른 어떠한 전자 신청 양식) 상의, 지불 또는 신용 카드 번호 데이터가 아닌 기존의 데이터 필드들중 (미리 결정된) 어떠한 것 내에 (바람직하게는 자동으로) 위치된다. 유저 (또는 바람직하게는 유저의 전자 지갑 프로그램)은, 예를 들어 "이름" 필드에 PIN 번호를 입력하고, PIN 번호에 의존하여 유저를 확인할 수 있다.

PIN 번호가 기존의 데이터 필드들중 미리 결정된 하나에 자동으로 위치되면, PIN 번호는 카드 발행 서버가 "이름" 필드와 같은 기존의 데이터 필드로부터 PIN을 정확하게 확인할 수 있도록, "＆"와 같은 ASCⅡ 기호 (또는 다른 어떠한 적절한 기호)에 의해 분리된다. 이는, 카드 발행 서버가 실제로, "＆"의 ASC Ⅱ 기호에 의해 분리되는 판매자의 쇼핑 카트 그리고/또는 온라인 구매 신청 양식에 입력하도록 구매자에 의해 요구되는 데이터 필드들중 하나에 고유의 한번 이용의 거래 번호 그리고/또는 PIN을 배정하였을 때, 유저로 하여금 (카드 발행 서버/웹사이트에 의한 인증 후) 공통 신용 카드 번호를 판매자에게 제시할 수 있게 한다.

따라서, 유저는 공통 지불 번호를 이용하며, 로그온을 통하여 자신의 신원이 인증된 후에는, 카드 발행 서버에 그 거래에 대하여 판매자에게 전송되는 공통 번호와 함께 이용하기 위한 다른 거래 PIN을 발행할 것을 명령한다. 이렇게 되면, 공통 번호 및 (실제로는, 온라인 신청 양식 내의 미리 선택된 데이터 내에서 함께 캡슐화되는) 거래 PIN 번호는 임박한 거래의 인증에 이용된다.

상기 공통 번호는 유사한 지리적인 위치, 국가, 또는 다른 어떠한 공통 유사성에 속하는 카드 보유자들의 그룹에 할당된 연속적인 번호들의 열로 구성될 수 있다. 이러한 공통 번호를 이용하게 되면, 카드 보유자에게 어떠한 개인적인 금융 정보를 노출시키지 않고 익명으로 온라인 구매를 할 수 있게 하는 잇점을 제공한다.

이에 따라, 유저들은 공통 지불 카드 번호를 공유할 수 있으며, 그럼에도 불구하고 각 유저는 여전히 정확하게 구별되고, 이들의 거래도 인증 및 승인된다.

당업자에 의해 본 발명의 정신 및 범위 내에서 변형이 쉽게 이루어질 수 있다. 이에 따라, 본 발명은 상기에서 예로서 설명한 특정한 실시예들에 한정되지 않는 다는 것을 알 수 있을 것이다.

Claims

온라인 네트워크를 통한 구매자와 판매자간의 금융거래를 인증하는 방법으로서,

상기 구매자에 관한 고유 정보를 포함하는 구매자로부터의 거래 요청을 수신하는 단계와; 그리고

상기 거래 요청을 인증하며, 만일 인증이 이루어지면 상기 구매자에게 상기 구매자가 금융 거래를 행하기위해 이용하는 거래 번호 - 이 거래 번호는 상기 구매자의 신용/지불 카드 번호와는 다르다 - 제공하는 단계를 포함하는 방법.
제 1항에 있어서,

상기 판매자는 구매자의 신용 제공자와 금융 거래를 완료하기위해 상기 거래번호를 이용하는 것을 특징으로 하는 방법.
제 1 또는 제 2항에 있어서,

상기 거래 번호는 한번의 거래를 위해서만 이용되는 것을 특징으로 하는 방법.
제 3항에 있어서,

상기 거래 번호는 임으로 생성되는 것을 특징으로 하는 방법.
제 1 내지 제 4항중 어느 한 항에 있어서,

상기 구매자는 이동 전화로부터 상기 거래 요청을 행하는 것을 특징으로 하는 방법.
제 5항에 있어서,

상기 구매자에 관한 고유 정보는 상기 이동 전화의 SIM 카드 및/또는 상기 구매자가 입력한 PIN을 통해 얻어지는 것을 특징으로 하는 방법.
제 1내지 제 6항중 어느 한 항에 있어서,

이메일 어드레스와 같은 하나 또는 그 이상의 미리 배열된 네트워크 접속 어드레스들을 통해 신용/지불 카드 소유자에게 전송될 거래 확인을 발생하는 단계를 더 포함하는 것을 특징으로 하는 방법.
온라인 환경에서 구매자와 판매자 사이에 금융거래를 행할 수 있게 하는 시스템으로서,

구매자로부터 고유 유저 식별 정보를 수신하여, 이 정보 데이터를 근거로 상기 구매자를 인증하는 구매자 인증 수단과; 그리고

상기 구매자가 상기 금융 거래를 행하기위해 이용하는 거래번호 - 이 거래번호는 상기 구매자의 신용/지불 카드 번호와는 다르다 - 를 생성하는 거래 번호 생성기를 포함하는 시스템.
제 8항에 있어서,

상기 판매자로부터 상기 거래 번호를 수신하고 그리고 상기 판매자와 상기 구매자의 신용 제공자 사이에 추가의 거래를 행하도록 하는 금융 거래 인증 수단을 더 포함하는 것을 특징으로 하는 시스템.
온라인 환경에서 금융 거래를 행하는 시스템으로서,

물리적으로 동일한 신용 카드 번호를 갖는 복수의 신용 카드들과; 그리고 상기 카드들을 이용하여 행해지는 구매들을 인증하는 인증 서버를 포함하며,

상기 인증 서버는 상기 카드들의 유저들에 의해 제공되는, 상기 카드들과는 물리적으로 관계하지 않는 고유 정보를 인증하고 그리고 인증이 긍정적인 경우, 신용 카드 번호로서 판매자에게 제공될 거래 번호 - 이 거래 번호는 상기 물리적인 신용 카드 번호하는 다르다 - 를 유저에게 제공하는 시스템.
제 8항 또는 제 10항에 있어서,

상기 거래 번호는 임의로 생성되고, 한번의 거래를 위해서만 이용될 수 있는 것을 특징으로 하는 시스템.
제 8항 또는 제 10항에 있어서,

이메일 어드레스와 같은 하나 또는 그 이상의 미리 배열된 네트워크 접속 어드레스들을 통해 신용/지불 카드 소유자에게 전송될 거래 확인을 발생하는 거래 확인 발생 수단을 더 포함하는 것을 특징으로 하는 시스템.
제 10항 또는 제 11항에 있어서,

상기 복수의 신용 카드는 오프라인 신용 거래를 위해서만 사용될 오프라인 신용 카드 번호를 포함하는 것을 특징으로 하는 시스템.
제 13항에 있어서,

상기 오프라인 신용카드 번호는 마드네틱 스트라이프 및/또는 상기 카드에 내장된 칩에 저장되는 것을 특징으로 하는 시스템.
제 13항 또는 제 14항에 있어서,

상기 신용 카드는 온라인 거래 및 오프라인 거래를 위한 개별적인 신용 계정을 갖는 것을 특징으로 하는 시스템.
온라인 네트워크를 통한 구매자와 판매자 사이의 금융 거래 - 상기 상기 구매자는 SIM 카드를 갖는 이동 전화로부터 상기 거래를 요청한다 - 를 인증하는 방법으로서,

상기 SIM 카드 및/또는 고유 PIN을 통해 상기 구매자의 신용을 인증하는 단계를 포함하는 방법.
구매자와 판매자 사이의 금융 거래를 인증하는 방법으로서,

상기 구매자로부터 거래 번호 요청 - 이 요청은 상기 구매자에 관한 식별 정보를 포함하고 있다 - 을 수신하는 단계와; 그리고

상기 요청을 인증하여, 만일 인증이 이루어지면 상기 구매자가 금융 거래를 행하는데 사용하도록 상기 거래 번호를 상기 구매자에 제공하는 단계를 포함하는 방법.
구매자가 판매자와 금융거래를 행하는 방법으로서,

상기 구매자가 거래 번호에 대한 요청 - 이 요청은 상기 구매자에 관한 식별정보를 포함한다 - 을 제시하는 단계와;

만일 상기 요청이 인증되면, 상기 구매자가 상기 거래 번호를 수신하는 단계와; 그리고

상기 금융 거래를 행하도록 상기 거래 번호를 상기 판매자에게 제공하는 단계를 포함하는 방법.
제 16항 내지 제 18항중 어느 한 항에 있어서,

상기 거래 번호는 상기 구매자의 실제 계정 또는 카드 번호의 적어도 한 부분을 포함하는 것을 특징으로 하는 방법.
제 16항 내지 제 18항중 어느 한 항에 있어서,

상기 거래 번호는 상기 구매자의 공통 계정 또는 카드 번호의 적어도 한 부분을 포함하는 것을 특징으로 하는 방법.
제 20항에 있어서,

상기 공통 계정 또는 카드 번호는 특정 금융기관 또는 특정 판매자에 특정하게 부여되는 것을 특징으로 하는 방법.
구매자와 판매자 사이에 금융 거래를 행하게 하는 시스템으로서,

상기 구매자로부터 거래 번호에 대한 요청 - 이 요청은 식별 정보를 포함한다 - 을 수신하고 상기 식별 정보에 근거하여 상기 구매자를 인증하는 구매자 인증수단과; 그리고

상기 구매자가 상기 금융 거래를 행하는데 이용하도록, 상기 구매자와 관련된 거래 번호를 생성하는 거래 번호 생성기를 포함하는 시스템.
제 22항에 있어서,

상기 거래 번호는 상기 구매자의 신용/지불 계정 또는 카드 번호와 다른 것을 특징으로 하는 시스템.
제 22항 또는 제 23항에 있어서,

상기 거래 번호는 상기 구매자의 실제 계정 또는 카드 번호의 적어도 한 부분을 포함하는 것을 특징으로 하는 시스템.
제 22항 또는 제 23항에 있어서,

상기 거래 번호는 상기 구매자의 공통 계정 또는 카드 번호의 적어도 한 부분을 포함하는 것을 특징으로 하는 시스템.
제 25항에 있어서,

상기 공통 계정 또는 카드 번호는 특정 금융기관 또는 특정 판매자에 특정하게 부여되는 것을 특징으로 하는 방법.
구매자와 판매자 사이에 금융거래를 행하는 방법으로서,

상기 구매자 계정 정보를 상기 판매자에게 제공하는 단계와;

상기 판매자가 신용 발행자 또는 신용 발행자의 대행사에 거래 승인을 요청하는 단계와;

상기 신용 발행자가 상기 구매자에게 인증 요청을 전송하는 단계와; 그리고

상기 구매자가 상기 신용 발행자에게 인증 데이터를 전송함으로써 상기 인증에 응답하는 단계를 포함하는 방법.
제 27항에 있어서,

상기 인증 코드는 상기 인증 요청에 대한 응답을 포함하는 것을 특징으로 하는 방법.
제 27항에 있어서,

상기 인증 요청은 인증될 거래를 위한 인증 데이터에 상기 유저에 의해 포함되어야 하는 패스워드를 포함하는 것을 특징으로 하는 방법.
제 27항에 있어서,

상기 인증 데이터는 상기 인증 요청에는 포함되지 않은 소정의 패스워드를 포함하는 것을 특징으로 하는 방법.
제 27항에 있어서,

상기 계정 정보와 함께 상기 카드 발행자에 상기 인증 데이터를 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
제 32항에 있어서,

상기 인증 요청을 상기 신용 발행자로부터 상기 구매자에게 전송하기 전에 초기 유효성 체크를 수행하는 단계를 포함하는 것을 특징으로 하는 방법.
구매자와 판매자 사이에 금융거래를 행하는 방법으로서,

상기 판매자로부터 거래승인 요청을 수신하는 단계와;

상기 구매자에게 인증 요청을 전송하는 단계와; 그리고

상기 구매자로부터 인증 데이터를 수신하는 단계를 포함하는 방법.
제 1, 16, 17, 18, 27 또는 33항중 어느 한 항에 있어서,

비록 아직 사용되지 않았다 하더라도 상기 거래 번호가 이용될 수 없게 되도록, 소정의 시간 주기후 상기 거래 번호가 불능상태로 되게하는 단계를 포함하는 것을 특징으로 하는 방법.
제 1, 16, 17, 18, 27 또는 33항중 어느 한 항에 있어서,

상기 거래 번호는 기존 세트의 그러한 거래 번호들로 부터 선택되는 것을 특징으로 하는 방법.
제 35항에 있어서,

상기 거래 번호는 소정의 선택코드 또는 필요에 의해 발생된 선택 코드에 따라 상기 세트의 거래 번호들로 부터 선택되는 것을 특징으로 하는 방법.
제 35항에 있어서,

상기 세트의 거래 번호들은 언제든지 단일 유저에 특정한 것을 특징으로 하는 방법.
제 1, 17, 18, 27 또는 33항중 어느 한 항에 있어서,

상기 요청이 디스플레이를 갖는 장치로부터 제시될때, 상기 인증 정보는 하나 또는 그 이상의 핫스폿을 포함하며, 상기 핫스폿 각각은 상기 인증 정보의 문자에 인접한 각각의 소정 위치에 놓이는 것을 특징으로 하는 방법.
제 38항에 있어서,

상기 핫스폿 각각은 상기 각각의 소정의 위치를 더블 클릭하거나 또는 상기 각각의 소정 위치에 커서를 놓음으로써 입력되는 것을 특징으로 하는 방법.
제 38항 또는 39항에 있어서,

상기 각 스폿의 각 위치는 그것의 입력 후에는 보이지 않는 것을 특징으로 하는 방법.
제 38항 또는 39항에 있어서,

상기 거래 번호를 수신하고, 상기 거래번호에 적어도 하나의 핫스폿을 추가함으로써 상기 거래 번호를 변경하고, 그리고 이렇게 변경된 상기 거래 번호를 상기 판매자에 제공하는 단계를 포함하는 것을 특징으로 하는 방법.
제 8, 17, 18 또는 22항중 어느 한 항에 있어서,

상기 식별 정보는 대응 질문에 대한 사전에 제공되는 대답을 포함하고, 그러므로써 상기 방법은 상기 구매자가 상기 질문에 대답하고, 그리고 만일 상기 대답이 상기 식별 정보의 일부로서 제공되지 않으면 상기 상기 구매자에 대한 인증을 거부하는 단계를 포함하는 것을 특징으로 하는 방법.
제 42항에 있어서,

상기 질문 및 상기 대응하는 대답은 복수의 그러한 질문 및 대응 대답중 하나인 것을 특징으로 하는 방법.
제 8, 10 또는 22항중 어느 한 항에 있어서,

비록 아직 사용되지 않았다 하더라도 상기 거래 번호가 이용될 수 없게 되도록, 소정의 시간 주기후 상기 거래 번호를 불능상태로 되게하는 것을 특징으로 하는 시스템.
제 8, 16, 17 또는 18항중 어느 한 항에 있어서,

상기 거래 번호는 기존 세트의 그러한 거래 번호들로 부터 선택되는 것을 특징으로 하는 방법.
제 45항에 있어서,

상기 거래 번호는 소정의 선택코드 또는 필요에 의해 발생된 선택 코드에 따라 상기 세트의 거래 번호들로 부터 선택되는 것을 특징으로 하는 방법.
제 45항에 있어서,

상기 세트의 거래 번호들은 언제든지 단일 유저에 특정한 것을 특징으로 하는 방법.
제 1, 17, 18, 27 또는 33항중 어느 한 항에 있어서,

상기 요청은 어드레스 정보 및 권한부여 데이터를 포함하며, 상기 어드레스정보는 상기 구매자를 표시하고, 상기 권한부여 데이터는 추가의 당사자를 표시하는 것을 특징으로 하는 방법.
제 48항에 있어서,

상기 추가의 당사자는 상기 구매자의 고객인 것을 특징으로 하는 방법.
제 48 또는 49항에 있어서,

상기 어드레스는 정보는 가상 정보인 것을 특징으로 하는 방법.
제 48 또는 49항에 있어서,

상기 어드레스 정보는 실제 어드레스에 해당하는 것을 특징으로 하는 방법.
제 48 내지 51항중 어느 한 항에 있어서,

상기 어드레스 정보 및 상기 권한 부여 데이터를 수신하여 동일한 입력 필드에 입력하는 것을 특징으로 하는 방법.
제 52항에 있어서,

적어도 하나의 문자로 분리된 상기 어드레스 정보 및 상기 권한 부여 데이터를 수신하는 단계를 포함하는 것을 특징으로 하는 방법.
온라인 또는 다른 통신 환경에서 유저의 신원을 서버에 인증하는 방법으로서,

관련 유저 식별 정보를 갖는 유저 계정을 설정하고 상기 유저로부터 패스워드를 수신하는 단계와;

상기 패스워드 및 상기 패스워드로부터 추론되는 코드에 근거하여 일단의 의사-패스워드를 생성하는 단계와;

상기 유저 식별 정보를 포함하는 유저 장치측의 상기 유저로부터 로그인 요청을 수신하는 단계와;

상기 일단의 의사-패스워드들로부터 임의의 의사-패스워드를 활성화시켜 한 세트의 하나 이상의 번호들 - 이 번호들은 규칙에 의해 상기 코드로부터 추론된다- 을 생성하는 단계와;

유저 장치에 상기 세트의 번호들을 전송하는 단계와;

상기 패스워드를 상기 유저 장치에 기입하고, 상기 유저장치에서 상기 규칙과 반대인 규칙 및 상기 패스워드에 따라 상기 세트의 번호를 변경하여 변경된 세트의 번호를 생성하는 단계와; 상기 변경된 세트의 번호 - 이 번호들은 만일 상기 패스워드가 상기 유저에 의해 정확하게 기입되었다면 상기 코드를 포함한다 -를 상기 서버에 전송하는 단계와; 그리고

상기 선택된 의사-패스워드를 해제하고 상기 변경된 세트의 번호가 상기 코드를 포함하면 유저 로그인을 실행시키는 단계를 포함하는 방법.
제 54항에 있어서,

상기 패스워드는 상기 패스워드에 있거나 또는 이와 상대적인 위치를 갖는 핫스폿을 포함하는 것을 특징으로 하는 방법.
제 55항에 있어서,

상기 핫스폿 위치를 토대로 상기 세트의 번호에 상기 코드를 위치시키는 단계를 포함하는 것을 특징으로 하는 방법.
제 55항 또는 56항에 있어서,

상기 코드는 상기 핫스폿의 상기 위치와는 독립적인 상기 패스워드로부터 추론되는 제 1 해시값 및 상기 핫스폿의 상기 위치로부터 추론되는 제 2 해시값으로부터 생성되는 것을 특징으로 하는 방법.
제 54항 내지 제 57항중 어느 한 항에 있어서,

세션 특정 규칙에 의해 상기 코드를 생성하는 단계를 포함하는 것을 특징으로 하는 방법.
제 27항 또는 33항에 있어서,

상기 인증 데이터는 상기 구매자에 의해 제공된 패스워드 또는 문구의 요청된 부분 또는 그 전체로 구성된 것을 특징으로 하는 방법.
제 27항 또는 33항에 있어서,

상기 인증 데이터는 상기 구매자에 의해 제공된 소정의 패스워드 또는 문구의 제 1부분 및 상기 패스워드 또는 문구의 요청된 제 2부분으로 구성된 것을 특징으로 하는 방법.
제 60항에 있어서,

상기 제 1부분은 상기 구매자에 의해 사전에 상기 패스워드 또는 문구가 제공된 핫스폿으로 경계가 한정되는 것을 특징으로 하는 방법.
온라인 또는 다른 통신 환경에서 유저의 신원를 서버에 인증하는 방법으로서,

상기 유저에 관한 공유 정보를 포함하는 로그인 요청을 상기 유저로부터 수신하는 단계와;

상기 로그인 요청을 인증하고 만일 인증이 이루어지면 상기 유저가 상기 서버에 로그인하기위해 사용하는 로그인번호를 상기 유저에 제공하는 단계를 포함하는 방법.
온라인 또는 다른 통신 환경에서 유저의 신원를 서버에 인증하는 방법으로서,

상기 유저의 이동전화 또는 다른 휴대용 통신 장치에 인증 요청을 전송하는 단계와; 그리고

상기 유저가 상기 이동전화 또는 다른 휴대용 통신 장치로부터 적절한 응답을 전송함으로써 상기 요청에 응답하면, 유저 신원이 검증된 것으로 판단하는 단계를 포함하는 방법.
제 63항에 있어서,

상기 서버는 상기 이동전화 또는 다른 휴대용 통신 장치에 대응하는 게이트웨이를 통해 상기 요청을 전송하고 상기 응답을 수신하는 것을 특징으로 하는 방법.
제 64항에 있어서,

상기 게이트 웨이는 iWAPGS 서버인 것을 특징으로 하는 방법.
제 63항 내지 65항중 어느 한 항에 있어서,

상기 요청이 전송된 후 소정시간내에 상기 응답이 수신되어야 함을 요구하고 그리고 상기 요청에 대한 어떤 후속적인 응답은 부적절한 것으로 판단하는 단계를 포함하는 것을 특징으로 하는 방법.