KR20180029227A - 전자 거래를 위한 보안 및 사용자 인증 - Google Patents

Abstract

제한된 수명의 보안 코드들을 생성, 전파, 제어 및 프로세싱하는 시스템 및 방법이 사용자들을 인증하기 위해, 특히 지불 거래와 같은, 전자 금융 거래를 위해 사용된다. 복수의 계좌들 또는 다른 보안 시스템들에 걸쳐 사용할 수 있는 단일 보안 코드를 제공하는 것이 고찰되고, 보안 코드 각각은 제한된 수명을 갖는다. 보안 코드 각각은 난수 생성기로부터의 난수이다. 사용자 각각에 대한 각각의 보안 코드들은 각각의 제한된 지속기간의 보안 코드 유효 기간에 대응한다. 따라서, (각각이 각각의 유효 기간들을 갖는) 랜덤하게 선택된 보안 코드들의 각각의 세트들과 복수의 사용자들을 연관시키는 표 또는 매트릭스가 생성되고, 이 매트릭스는 각각의 엔티티들, 보안 액세스를 필요로 하는 사용자 각각에 제공된다. 동시에, 적어도 현재 보안 코드가 사용자 각각에 제공되고, 액세스되는 각각의 엔티티들이 어떤 사용자로부터의 코드가 현재 유효한지를 추적할 수 있는 방법이다.

Description

전자 거래를 위한 보안 및 사용자 인증

본 발명은 가장 일반적으로 어떤 형태의 액세스가 목표되는 엔티티와 전자 거래를 인게이지하기 위한 준비 동작 (prelude) 으로서 사용자 인증에 관한 것이다. 보다 구체적으로, 본 발명은 본 명세서에 개시된 바와 같이 생성되고 관리된 보안 코드의 사용에 의해 전자 거래들 및 다른 보안된 전자 액세스를 위한 시스템들 및 방법들에 관한 것이다.

신뢰성 있는 사용자 인증이 매우 중요한 일 예는 전자 지불 거래 분야이다.

신용, 직불 및 선불 온라인 카드 사기는 온라인 쇼핑 및 제 3 자 지불 거래량이 증가함에 따라 증가하고 있다. 새로운 기술이 EMV (Europay, Mastercard, 및 Visa - 즉 "칩이 삽입된 (chipped)" 카드들) 의 사용 및 카드 단말 암호화를 통해 판매자 POS (Point of Sale) 단말들에서 "카드 제시" 사기를 해결하지만, 온라인 "CNP (Card Not Present)" 사기 문제에 대한 현재 보안 수단은 불충분하다.

CNP 사기는 미국이 추정한 사기 손실이 신용 카드 거래에 대해서만 2013년에 28 억 달러로 규모가 크고 성장하고 있고, 향후 10 년간 온라인 사기 신용 카드 구매에 대해 두 자릿수 성장이 기대되고, 2018 년에 64 억 달러까지로 추정된다.

직불 및 선불 카드 사기는 달러 손실 수치를 악화시킨다. 사기가 증가함에 따라, 금융 기관 (FI) 이 사기 복구, 관리, 및 동작들을 위해 보다 많은 비용을 지불해야 한다. 금융 기관들은 또한 카드소지자의 불만 및 잠재적인 고객 손실에 직면한다. 따라서 시장 영향이 상당하다.

이에 더하여, ACH (automated clearinghouse) 차변 (debit) 지불은 가상 수표 (Check Not Present) 거래들이 증가함에 따라 성장한다. ACH 차변은 비용이 적게 들지만, 계좌 소유주에 대한 제한된 제어를 수반한다. 판매자/판매자/수취인은 종종 소비자가 판매자와 지불을 확립할 때 개인의 수표 계좌에 액세스하도록 광범위한 (그리고 종종 비제한적인) 승인을 받는다.

(CNP 거래에서의 사용을 포함하는) 지불 카드 분야에서, (예를 들어, 전화를 통해 일어나는) CNP 거래 동안, 인증 카드를 손에 들고 또는 카드 보유자가 카드를 손에 들고 있다는 지표를 (판매자 또는 다른 수취인에 대해) 확립함으로써, 미리 결정된 지불 거래가 일어난다는 신뢰성을 상승시키기 위해 지불 카드와 짧은 (통상적으로 3 또는 4 자릿수) 숫자 코드를 연관시키는 것이 공지되어 있다.

몇몇 타입들의 이들 종래의 보안 코드들이 있다.

제 1 타입의 종래의 보안 코드는 일반적으로 CVV1 ("card verification value") 으로 지칭된다. 이 코드는 기술분야에서 때때로 CVC1 ("card validation code") 로 대안적으로 지칭된다. 이 코드는 카드의 자기 스트립에 보이지 않게 인코딩되고 예를 들어, 카드 제시 거래 동안 판매자에게 속한 POS 단말에 카드를 스와이핑할 때 (swipe), 회수된다 (retrieve). 이는 거래의 일부로서 전달되고, 카드 발행자에 의해 입증된다 (verified). CVV1 코드의 입증은 지불 카드가 카드를 스와이핑하는 판매자 (또는 다른 엔티티) 에 의해 실제로 물리적으로 핸들링된다는 것을 뒷받침한다.

CVV1 코드는 카드의 자기 스트립에 레코딩되기 때문에 고정되고, 또한 미리 결정된 지불 카드에 특정된다. 카드가 물리적으로 복제되고 자기 스트립 데이터가 카피되면, CVV1 코드는 인증되지 않은 사용자에 의해서도 유효하고 가용한 것으로 남아 있을 것이다.

제 2 타입의 종래의 보안 코드는 일반적으로 CVV2 (또는 때때로 CVC2) 로 지칭된다. CVV2 코드는 카드 계좌 번호와 이격되어 지불 카드 상 (예를 들어, 후면의 사인 스트립 위, 또는 때때로 계좌 번호로부터 이격되어 전면) 에 인쇄된 고정된 번호이다. CVV2 코드는 CNP 거래 (예컨대 제화 또는 서비스의 전화 또는 온라인 구매) 를 위해 사용되고, 거래를 개시하는 사람이 카드를 소지한다고 또는 카드의 물리적 기록 (카드 상의 CVV2 코드와 함께) 을 본다는 것을 나타내도록 의도된다. 오용의 다른 형태들 중에서, CVV2 코드의 사용은 자기 스트립 정보가 부정하게 카피되고 (기술적으로 말하면, 상대적으로 단순한 단계) 그 후 CNP 거래에 사용되는 상황을 방지하는 것을 돕는다. 대부분의 CNP 거래들은 CVV2 코드의 부가적인 지식을 요구할 것이다. 산업적 관습에 따라, CVV2 코드는 전자 지불 거래 동안 판매자들 또는 수취인들에 의해 저장되지 않는다. 그 결과, 판매자 또는 수취인에 의해 (예를 들어, 고객 지불 카드 계좌 번호들을 포함하는) 거래 정보가 해킹되거나 그렇지 않으면 도용된다면, 이 정보는 대응하는 CVV2 코드의 지식 없이 덜 가용해진다.

CVV1 코드와 같이, CVV2 코드는 고정되고 (즉, 미리 결정된 물리적 지불 카드에 대해 변경불가능), 그리고 단일 지불 카드와 고유하게 연관된다. (관습적으로 또는 판매자들과 지불 프로세서들 간 동의 표시에 의해) CVV2 코드가 이론적으로 유지되지 않지만, 코드를 부정하게 카피하거나 유지하는 나쁜 사람들이 예방되지 못할 수 있다. 관습적으로 활용되었지만, CVV2 코드는 지불 카드의 전면에 분명하게 증명되어, 카드가 도용된다면 부정하게 사용가능하다는 것을 주의해야 한다.

PIN (Personal Identification Numbers) 의 사용은 또한 일반적으로 예를 들어, 직불 카드들의 사용과 연관된 것으로 공지된다. 종래의 예에서, 지불 카드는 카드의 자기 스트립으로부터 계좌 정보를 판독하기 위해 스와이핑되고, PIN은 사용자에 의해 키패드 또는 다른 입력 디바이스 상에 수동으로 입력된다. 카드 정보 및 입력된 PIN의 송신을 허용하는, 통신 링크가 뱅크 또는 금융 기관과 확립된다.

관습적으로, 미리 결정된 PIN 코드는 보통 단일 각각의 지불 카드 또는 사용자가 액세스를 얻기 원하는 다른 전자 엔티티 또는 시스템과 연관된다. 이는 사용자가 관리해야 하고, 기억해야 하고, 보안을 유지 (즉, 분실 및/또는 승인되지 않은 액세스로부터 보호) 해야 하는 개인의 보안 코드들의 확산을 더 악화시킨다.

FI들, 판매자들, 및 소비자들은 모두, 사기를 최소화하고, 데이터 침해에 대한 노출을 감소시키고, 브랜드 평판 리스크를 완화시키고, 거래가 발생할 때, 승인될 때 및 승인되는 방법, 및 돈이 이동될 때의 제어를 증가시킴으로써 거래 리스크들을 감소시키는 솔루션을 원한다.

따라서, 승인되지 않은 거래들 또는 사기 손실들로부터 FI들 및 판매자들의 돈을 절약하고, 거래에 대한 보다 큰 제어를 계좌 보유자들에게 제공하고, 인증 프로세스 및 거래 완료의 마찰을 최소화하고, 보다 강한 보안 절차들의 채택을 개선하는 종래 기술의 일부 문제들을 해결하는 보안 솔루션을 찾는 것이 바람직하다.

FI들은 지불 카드 또는 수표 거래들의 탈중개 (disintermediation) 를 위협하는 (즉, 보다 안전하거나 상이한 거래 방법론을 구축할 수도 있는 제 3 자 침입자에 대한 거래를 손실할 리스크) 온라인 구매 거래량, 시장 점유율 및 계좌 보유자들을 희생시키지 않을 것이다. 판매자들은 포기된 구매, 입금 취소 (chargeback) 및 논쟁되는 거래들을 최소화하기 원한다. 바람직한 솔루션은 기존의 프로세스들의 활용을 최대화할 것이고, 쉽게 통합되고, 스케일링가능하고, 인증 프로세스 속도를 희생시키지 않을 것이다.

매력적인 솔루션은 온라인 구매 거래에 대한 모든 당사자들: FI들, 카드 보유자들, 계좌 보유자들 및 판매자들의 요구를 해결할 것이다. 바람직하게, 이러한 솔루션은 CNP 사기를 감소시킬 것이고, FI 노출을 제한할 것이고, 사기, 논쟁 및 입금취소 비용을 감소시킬 것이고, 카드 보유자 및 계좌 보유자에게 추가된 이점들을 제공할 것이다.

본 발명은 가장 일반적으로, 사용자가 액세스하기 원하는, 보안된 엔티티, 특히, 전자 엔티티, 예컨대 보안된 컴퓨터 네트워크들 또는 개인 또는 상업적 웹사이트와 상호작용 또는 액세스하는 사용자 인증을 위한 시스템들 및 방법들에 관한 것이다. 그러나, 본 발명은 명백하게 보안된 건물 등과 같은 개인에 의한 물리적 액세스를 위한 시스템들에 적용될 수 있다. 본 발명의 특정한 양태는 사용자 인증에 사용된 보안 코드들의 생성, 전파 및 관리에 관한 것이다.

특히 본 발명의 비제한적인 예에서, 본 발명은 전자 거래, 특히 전자 지불 거래 시 사용자 인증 프로세스의 보안성을 증가시키지만, 또한 요구된 보안 코드들의 채택 부담을 최소화하고 요구된 보안 코드들을 사용하고 관리하는 사용자 편의를 최대화하는 시스템들 및 방법에 관한 것이다.

본 발명은 각각의 지불 모드에 결부된 몇몇 보안 코드들 각각을 갖는 대신 (신용 카드들, 직불 카드들, 당좌 계좌, 등과 같은) 사용자에게 속한 지불 모드들의 범위에 걸쳐 사용가능한 사용자 인증을 위한 단일의 제한된 수명의 랜덤화된 보안 코드에 관한 것이다. 이는 사용자가 기억해야 하고 보호해야 할 보안 코드들의 수를 편리하게 감소시킨다.

그러나, 동시에, 보안 코드는 제한된 수명 (예를 들어, 하루) 을 갖고, 이에 따라 변화되어, 코드가 임의의 미리 결정된 순간에 분실되면 보안 노출을 감소시킨다. 또한, 사기성 사용 등의 사인들이 검출되면 코드가 용이하게 변화될 수 있고, 또는 카드 분실 또는 (즉, 특정한 계좌 또는 지불 모드들에 대한) 제한된 사기성 사용의 검출에 응답하여 필요할 수도 있기 때문에, (복수의 계좌들 또는 지불 모드들 중) 특정한 계좌들 또는 지불 모드들이 선택적으로 (또는 자동으로) 로킹 및 언로킹될 수 있다.

본 발명의 예에서, 복수의 각각의 사용자들 (예를 들어, 지불 계좌 보유자들) 이 랜덤하게 생성된 보안 코드들의 각각의 세트들과 연관되는 가상 매트릭스가 생성된다. 보안 코드 각각은 미리 결정된 사용자와 연관된 세트의 다른 보안 코드들의 유효성과 중첩하지 않는 (또는 이하에 설명된 바와 같이, 최소로 중첩하는) 특정한 유효 기간을 갖는다. (사용자들 및/또는 보안 코드들의 현재 세트에 대한) 매트릭스의 현재 버전은 지불 프로세서들 또는 금융 기관들에 주기적으로 분배되어, 인증에 참조될 수 있다. 동시에, 미리 결정된 사용자에 대한 적어도 현재 유효한 보안 코드는 이 사용자에게 전달된다.

본 발명의 특정한 예에서, 매트릭스 상의 정보 (특히, 보안 코드들) 는 매트릭스가 각각의 지불 프로세서들에 분배되기 전에 (예를 들어, 해시 함수를 사용하여) 수학적으로 모호해진다 (obfuscate). 바람직하게, 난독화 방법은 지불 프로세서 각각에 대해 고유한 각각의 해시 솔트들을 사용하는 것과 같이, 지불 프로세서 각각에 대해 고유하다.

실제로, 전자 지불 거래 프로세스 요청은 전자 지불 거래 요청을 개시하는 주장에 따라 (allegedly) 인증된 사용자의 인증을 위한 보안 코드들 중 하나와 함께 관련된 지불 프로세서에 의해 수신된다. 전자 지불 거래 프로세스 요청 시간에 대응하는 유효 기간 동안, 지불 프로세서에 의해 주장에 따라 인증된 사용자에 대응하는 현재 매트릭스의 보안 코드와 수신된 보안 코드가 비교된다. 이 비교에 따라 거래가 승인되거나 승인되지 않는다.

본 발명은 작성된 기술과 함께, 첨부된 도면들을 참조하여 보다 명확하게 이해될 것이다.
도 1은 전자 지불 거래의 다양한 "참가자들"과 연관된 하드웨어 배치들 간의 상호접속들을 예시하는 고레벨 개략적인 예시이다.
도 2는 본 발명에 따른 다양한 지불 프로세싱 엔티티들 간의 관련된 상호작용들을 포함하는, 보안 코드들의 그룹들을 생성하는 프로세스를 예시한다.
도 2a는 일시적으로 공지된 랜덤 패턴들의 매트릭스가 생성되는 방법의 예를 예시한다.
도 3은 본 발명을 사용하기 위한 사용자의 최초 등록 프로세스를 예시한다.
도 3a 내지 도 3h는 다양한 계좌들을 그룹화하는 것을 포함하는 등록 프로세스의 변형 또는 보안이 모두에게 공통되도록 보안 코드를 필요로 하는 다른 구현예들을 예시한다.
도 4는 본 발명에 따른 보안 코드를 사용자에게 전달하는 프로세스를 예시한다.
도 5는 본 발명의 보안 코드를 사용하는, 신용 카드 또는 직불 카드 또는 수표를 사용한 전자 지불 단계들을 예시한다.
도 6은 전자 지불 거래를 인증하는 다른 단계들을 예시한다.
도 7은 도 6의 프레임워크 내에서, 제출된 보안 코드를 유효화하는 다른 단계들을 예시한다.
도 8은 도 6의 프레임워크 내에서, 거래 기록 및 거래 분석 단계들의 결과들을 예시한다.
도 9는 본 발명의 몇몇 다른 프로세스들로서 사용되는, 사용자에게 통지를 전송하는 프로세스를 예시한다.
도 10은 본 발명과 연관된 금융 계좌를 선택적으로 로킹 또는 언로킹하는 프로세스를 예시한다.
도 11은 지불 프로세서들 또는 금융 기관들로 통지들을 전송하는 프로세스를 예시한다.
도 12는 전자 지불 거래를 유효화하는 프로세스를 예시한다.

본 명세서에 개시된 본 발명의 다양한 양태들의 상세들은 본 명세서에서 특정한 언어의 부재시에도, 영향을 주는 최대한 확장 가능한 다양한 조합들로 본 발명의 광범위한 개념들에 적용가능한 것을 의미한다는 것이 이해될 것이다.

본 개시의 목적들을 위해, 이하의 정의들은 일반적으로, 본 명세서에서 더 수정될 수도 있는 것으로 의도된다.

"계좌 (account)"는 제화들 및 서비스들의 구매 및 판매를 목적으로 자금을 이동시킬 수 있고 자금을 보관하는 모든 금융 관계들이다. 통상적으로, 계좌들은 이로 제한되지 않지만, 당좌, 예금, 여신 한도 (lines of credit), 신용 카드, 직불 카드, 선불 카드 (급여 대장, 증여, 및 상여를 포함), 전자 지갑 (digital wallets), 자사 브랜드 ACH 카드, 비결합 직불 카드 (decoupled debit card), 구매를 위해 사용된 가상의 또는 물리적 카드 또는 수표를 사용하거나 사용하지 않는 계좌, EFT (electronic fund transfers), 또는 다른 수단에 의한 자금 이송을 포함할 수 있다.

"거래 (transaction)"는 온라인 또는 오프라인으로 일어날 수도 있는 컴퓨터 매개된 네트워크들을 통해 수행된, 사업간, 가정간, 개인간, 정부간, 그리고 다른 공공 또는 사설 조직들간 돈의 이동이다.

"지불 프로세서 (payment processor)"는 전자 지불 요청을 수신하고 전자 지불 요청의 상세들을 검토하고 관련된 금융 기관 (예컨대 카드 발행 은행) 으로부터 판매자 또는 수취인으로의 자금의 이동을 핸들링하는 중개인으로서 역할을 하는 엔티티를 지칭한다. 나타낸 바와 같이, 지불 프로세서는 예를 들어, 카드 지불 프로세서 또는 수령 예치 (Receiving Depository) 금융 기관 또는 은행일 수 있다. 이는 또한 지불 프로세서 액티비티에 수반된 정도로 ACH (Automated Clearing House) 및 연방 준비제도 (Federal Reserve) 를 포괄하는 것을 포괄하는 것을 의미한다. 그러나, 본 명세서의 개시의 간략함을 위해, 용어 "지불 프로세서"는 이 설명의 맥락으로 제한되는 것으로 의도되지 않고, 이러한 맥락으로 기본적으로 사용될 것이다.

도 1은 본 발명이 통합되는 전자 지불 거래들을 수행하는 시스템을 개략적으로 예시한다.

도 1에 예시된 주 엘리먼트들은 서로 직접 또는 조작가능하게 (operably) 통신할 수도 있다. 또 다른 엘리먼트와 "조작가능한 통신"되도록, 중개 엘리먼트들이 명시적으로 나타날 필요가 없지만, 2 개의 엘리먼트들 간의 통신 경로간 중개 엘리먼트들의 가능성을 포괄하도록 의도된다. 예시된 엘리먼트들 (예컨대 중앙 시스템) 의 "그룹화 (groupings)"는 근접도가 명백하게 허용가능하지만, (종래의 네트워킹 원리의 제한들 내의) 임의의 물리적 근접도를 필요로 한다는 것을 의미하지 않는다는 의미에서 개략적이다. 또한, 도 1의 엘리먼트들 간 통신 "링크들"은 엘리먼트들의 일반적인 연관성을 반영하도록 의도되고, 제한적인 또는 특히 배타적인 것을 의미하지 않는다 (즉, 도 1에 예시되지 않은 다른 통신 링크들이 예시된 엘리먼트들 사이에 제시할 수도 있다).

도 1에 나타낸 바와 같이, "중앙 시스템"은 본 발명에 따른 동작들의 기본적인 부분을 수행하는 엘리먼트들을 포함한다. 중앙 데이터베이스 서버 (1) 는 예를 들어 그리고 제한 없이: 계좌 보유자 등록 프로파일들 및 통지 우선도 또는 조건부 거래 규칙들 또는 계좌 로킹 우선도와 같은 우선도 및 대응하는 정보; 참여하는 지불 프로세서들에 분배하기 위해, 뿐만 아니라 계좌 보유자의 프로파일에 등록된 모든 계좌들에 활성인 현재 보안 코드의 등록된 계좌 보유자들에 통지하기 위해, 본 명세서에서 이하에 설명된 바와 같이 생성된 (때때로 본 명세서에서 일시적으로 공지된 랜덤 패턴들로 지칭된) 생성된 보안 코드들; 등록된 계좌들에 대해 시도된 거래들에 관한 정보를 포함하는, 본 발명을 지지하는 데이터를 중앙에 보유하는 클라우드 내 또는 사내 (on-premise) 데이터 센터들에 보유된, 전용 또는 가상의 하드웨어 시스템에 호스팅된 데이터 저장부이다. 중앙 데이터베이스 서버 (1) 의 예는 리모트 시스템 상 가상 서버의 생성 및 동작을 가능하게 하는, Amazon Relational Database Service (때때로 Amazon RDS로서 지칭됨) 이다. 물리적 서버 상의 구현예는 또한 본 발명에 따라 효과적일 것이다.

HSM (Hardware Security Module) (2) 은 클라우드 또는 사내 데이터센터에 보유될 수도 있고, 본 발명에 따른 동작 동안 생성되고 프로세싱된 센서티브 정보를 암호화 또는 해시하도록 사용된 암호화 키들을 안전하게 생성, 저장 및 관리하도록 사용된다. 이하에 설명된 바와 같이, 보안 코드 매트릭스를 채우기 위한 진성 난수 (true random number) 생성에 또한 사용될 수도 있다 (즉, 개별 보안 코드 각각이 각각의 유효 기간을 갖는, 각각의 보안 코드들 세트들을 사용자들과 연관시키는 매트릭스). HSM (2) 의 상업적으로 가용한 구현예는 예를 들어, Amazon Web Services로부터 가용하고, 예를 들어, Luna SA 소프트웨어 (버전 5) 를 사용하는 SafeNet, Inc.로부터의 Luna SA 7000 HSM 적용예들에 기초한다. 기술분야에 공지된 "진성" 난수 생성은 생성된 수의 랜덤성을 최대화하기 위해 과학적으로 랜덤한 물리적 현상 (예컨대 무선 수신기에 의해 검출된 대기 잡음 또는 방사성 붕괴) 에 의존하고, 따라서, 본 발명에 사용하기 위한 바람직한 방법이다.

중앙 애플리케이션 서버 (3) 는 시스템의 사업 로직을 구현하는 함수들 및 절차들을 효과적으로 실행하도록 전용된, 클라우드 또는 사내 데이터 센터 내에 보유된, 중간층 (middle-tier) 애플리케이션 서버 또는 서버들의 모음이다. ("중간층"은 일반적으로 애플리케이션의 사업 로직을 수행하고 사용자 인터페이스와 웹서버들 사이에 동작가능하게 위치된 애플리케이션 서버 및 다층 아키텍처의 일부로서 데이터베이스 서버(들)를 지칭한다.) 이는 이들 소프트웨어 모듈들을 실행하기 위해 필요한 프레임워크들을 보유하고, 필요한 데이터 중심 동작들을 지지하도록 중앙 데이터베이스 서버 (1) 에 연결한다. 이는 또한 계좌 보유자 등록들, 계좌 보유자 우선도를 관리하고, 또는 프로세서들 (또는 발행자 또는 금융 기관들) 로부터 거래 정보를 수신하기 위해 중앙 데이터베이스 서버 (1) 와 통신하는 외부 클라이언트들 또는 벤더들 (vendors) 에 대한 API (Application Program Interface) 호출들을 호스팅한다. 이들 프로세스 기술 목적들을 위해, 또한 통지 서버 (9), (예를 들어, 이메일 교환 서버들, SMS 통합 관리자들 (aggregators), 경보 서비스들을 푸시하는 모바일 애플리케이션들, 또는 이들 서비스들 중 전부 또는 일부를 통합하는 웹 서비스 제공자들, 예를 들어 Amazon Web Services 솔루션의 일부로서 Amazon Simple Notifications Service) 를 통해 계좌 보유자 통지들 또는 B2B (Business-to-business) 통신과 같은 상이한 애플리케이션 특징들을 충족시키도록 파일들 또는 데이터 페이로드들을 송신하기 위해 다른 벤더들로 아웃바운드 연결하는 책임이 있다. 이들 함수들 중 일부는 또한 보다 깊은, 보다 분산된 다층 아키텍처를 위해 별도의 하드웨어 시스템들에서 구현될 수 있다. 중앙 애플리케이션 서버 (3) 의 상업적으로 가용한 예는 Amazon Elastic Compute Cloud (때때로 Amazon EC2로 공지됨) 이지만, 물리적 서버 구현예가 또한 본 발명에 따라 적절할 것이다.

도 1에 나타낸 바와 같은 예시적인 "지불 프로세서" (또는 전자 지불 프로세싱을 수반하는 유사하게 위치된 금융 기관) 에서, 결국 복수의 다양한 데이터베이스들을 핸들링하고 프로세싱하는, 하나 이상의 데이터베이스 서버들 (4, 6) 이 제공된다. 일반적으로, 지불 프로세서는 이미 종래의 동작들을 수행하기 위해 하나 이상의 데이터베이스 서버들 (및 서버들 상에서 실행되는 데이터베이스들) 을 소유할 것이다. 본 발명에 따른 지불 프로세서에서 특정한 동작들이 또한 데이터베이스-서버 상주이고, 기존 하드웨어 상에서 구현될 수 있거나 원한다면, 독립적인 데이터베이스 서버 (또는 서버들) 상에서 구현될 수 있다. 적절한 접속성을 사용하여, 요구된 구현예는 지불 프로세서에 국부적일 필요는 없고, 예를 들어, 중앙 시스템에 국부적으로 위치되거나 또 다른 물리적 위치에 위치될 수 있다. 이러한 맥락으로, 본 발명의 본 개시는 개시의 간략함 및 명확성을 위해, 물리적으로 독립된 유닛들이라면, 지불 프로세서와 연관된 2 개의 서버들의 예로서 진술된다. 그러나, 본 명세서에 기술된 바와 같이, 모든 전술한 고려사항들은 본 발명에 적용되고, 일 데이터베이스 서버에 귀착되는 기능성은 다른 데이터베이스 서버에서 구현될 수 있다.

이에 따라, 지불 프로세서는 중앙 시스템 (즉, 중앙 데이터베이스 서버 (1), HSM (2), 및 애플리케이션 서버 (3) 을 포함하는) 과 통신하는 본 발명에 따른 보안 코드 데이터베이스 서버 (4) 를 가질 수도 있다. 보안 코드 데이터베이스 서버 (4) 의 상업적으로 가용한 예는 Dell 13G PowerEdge R730xd이다. 보안 코드 데이터베이스 서버 (4) 는 전자 지불 거래를 수행하는 동안 본 발명에 따라 생성되고 등록된 계좌 보유자들에 의해 입력된 보안 코드들의 검증을 포함하여, 참여하는 지불 프로세서들로 하여금 본 발명에 따른 거래들을 완료하게 하는데 필요한 데이터 및 절차들을 포함하는 데이터 저장소의 예를 나타낸다. 이들 예들은 별도의 하드웨어 시스템, 전용 또는 가상, 클라우드 또는 사내 데이터 센터 내, 또는 지불 프로세서의 기존 데이터베이스 서버 상의 기존의 데이터베이스 예 (즉, 지불 프로세서의 이전에 제시하는 장비 내로 통합된) 내부에서 구현될 수 있다. 지불 프로세서는 또한 하나 이상의 고유한 이전에 제시하는 데이터베이스 서버들 (6) 을 가질 것이다. 데이터베이스 서버 (6) 는 일반적으로 참여하는 지불 프로세서 또는 금융 기관에 의해 소유되고 그리고/또는 동작되고, 전용 또는 가상 하드웨어 시스템에 호스팅되고, 클라우드 또는 사내 데이터 센터들에 보유되는 데이터 저장소이고, 일반적으로 거래 인증 (즉, 본 발명에 따르는지 여부) 을 프로세싱하는데 필요한 데이터 및 방법들을 포함한다.

대표적인 계좌 보유자 (또는 달리 말하면, 하나 이상의 금융 계좌들을 갖고 전자 지불 거래를 통해 제화 또는 서비스들 등에 지불하려는 소비자) 가 5에 예시된다. 통상적으로, 계좌들은 이로 제한되는 것은 아니지만, 당좌, 예금, 여신 한도 (lines of credit), 신용 카드, 직불 카드, 선불 카드 (급여 대장, 증여, 및 상여를 포함), 전자 지갑 (digital wallets), 자사 브랜드 ACH 카드, 비결합 직불 카드 (decoupled debit card) (즉, 일 엔티티에 의해 발행되었지만 또 다른 엔티티와 연관된 계좌 (보통 자금원) 와 링크된 계좌), 구매를 위해 사용된 가상의 또는 물리적 카드 또는 수표를 사용하거나 사용하지 않는 계좌, EFT (electronic fund transfers), 또는 다른 수단에 의한 자금 이송을 포함할 수 있다. 특히, 지불 카드들에 대해, 본 발명은 개루프 카드, 폐루프 카드, 단일 로드 (load) 카드, 및 재충전가능 (reloadable) 카드에 적용하는 것을 의미한다. 기술분야에 공지된 바와 같이, "개루프" 지불 카드는 (Visa®, American Express®, 등과 같이) 판매자들 사이에 일반적으로 승인되는 카드 타입들을 지칭하는 한편, "폐루프" 지불 카드들은 (백화점 발행 신용카드들과 같은) 제한된 판매자 네트워크 또는 판매자들의 그룹으로 한정된다.

계좌 보유자 (5) 는 가끔 금융 거래, 특히 전자 지불 거래를 완료할 수도 있다. "거래"는 온라인 또는 오프라인으로 일어날 수도 있는 컴퓨터 매개 네트워크들을 통해 수행된 사업간, 가정간, 개인간, 정부간 및 다른 공공 또는 사설 조직들간 돈의 이동이다.

계좌 보유자 (5) 는 개인용 전자 디바이스, 예컨대 제한 없이, 데스크탑 또는 랩탑 컴퓨터, 태블릿 컴퓨터, 스마트폰, 휴대 전화, 또는 임의의 다른 휴대용 또는 고정된 디바이스로부터 목표된 금융 거래를 개시할 수도 있다. 대안적으로, 거래는 (전화 또는 대면) "실제 (live)" 고객 서비스 에이전트를 통해 실행될 수 있다.

본 발명의 시스템과의 상호작용을 위해 적절한 인터페이스는 (예로서) 본 발명에 따라, 통지 우선도 또는 조건부 거래 또는 계좌 로킹 우선도들을 포함하는, 등록 프로파일 및 우선도를 관리하기 위해; 본 발명에 따라 거래들, 등록 프로파일 변화들에 관한 경보들 및 통지들을 수신하기 위해, 또는 본 발명에 따라 현재 보안 코드를 획득하기 위해; 계좌 상태 또는 시스템 거동을 관리하기 위한 요청을 개시, 예컨대 거래에 참여하는 계좌를 영구적으로 또는 일시적으로, 전체적으로 또는 조건부로 로킹, 또는 해외 여행 또는 지불 카드 또는 디바이스가 손상, 대미지, 분실 또는 도용되었다는 것을 발행 은행에 알리기 위해, 중앙 애플리케이션 서버 (3) 에 호스팅된 API (Application Programming Interface) 에 접속하고 직접 또는 간접 호출들을 발행하는 웹사이트, 모바일 또는 데스크탑 애플리케이션 또는 애플릿, 또는 문자 메시지들을 포함할 수도 있다.

계좌 보유자 (5) 는 구매 또는 다른 지불 거래를 위해 그리고 거래 인증 요청을 제출하기 위해 가끔 판매자 (또는 수취인) (7) 또는 중간 청구 엔티티 (미도시) 와 상호작용할 수도 있다. 거래 인증은 웹사이트, 모바일 또는 데스크탑 애플리케이션 또는 음성 통신 (예를 들어, 사람 에이전트, 또는 자동 음성 인식 시스템) 을 통해, 또는 지문 또는 음성 인식 또는 망막 스캔과 같은, 생체 스캔을 사용하여 판매자 또는 수취인 (7) 에게 거래 정보를 전달하는 디바이스를 통해 수행된 고객 미제시 거래 인증 요청 (예를 들어, 카드 미제시 (Card Not Present) 거래); 또는 계좌 보유자 (5) 가 구매 또는 지불을 위해 지불 카드, 수표, 디바이스, 칩, 또는 금융 계좌의 임의의 표현과 함께 판매자 (또는 수취인) (7) 에게 개인적으로 나타나는, 고객 제시 거래 (예를 들어 카드 제시 거래) 를 포함할 수도 있다.

본 발명의 목적들을 위한 판매자 (또는 수취인) (7) 는 예를 들어, 계좌 보유자 (5) 에 의해 개시된 카드 거래 인증을 완료하기 위해 사용된 디바이스 또는 애플리케이션에 의해 직불, 신용, 수표 또는 ACH와 같은 지불 방법들을 수용하는 임의의 엔티티이다. 이는 계좌 보유자 (5) 가 액세스하거나 동작시키는 디바이스 상에 설치된 웹 애플리케이션 또는 모바일 애플리케이션으로 나타낼 수 있다. 이는 또한 몇몇 예들을 명명하기 위해, 계좌 보유자가 카드에 포함된 정보 또는 이의 물리적 또는 가상 표현을 타이핑하거나 스캐닝함으로써 또는 계좌 보유자의 생체정보를 스캐닝함으로써 거래 정보를 입력하는, (판매 단말 지점과 같은) 판매자 위치의 물리적 디바이스일 수 있다. 본 발명의 특정한 예에서, 판매자 (7) 는 예를 들어, HP Moonshot ProLiant m350을 동작시킬 수도 있다.

본 발명에 따라, 계좌 보유자 (5) 와 인터페이싱하는 웹 사이트 또는 웹 애플리케이션을 호스팅하기 위해 예를 들어, 하나 이상의 부가적인 웹 서버들 (8) 이 필요할 수도 있다. 상기 언급된 예의 Amazon EC2가 또한 본 명세서에서 사용될 수 있다. 웹 서버 (8) 는 클라우드 또는 사내 데이터센터의 중앙 시스템 내에 위치될 수 있다. 웹 서버 (8) 는 대안적으로 지불 프로세서의 로컬 네트워크의 일부일 수 있다. 기능은 등록들을 관리하기 위해 계좌 보유자 (5) 로부터 입력을 수신하고, 등록 및 다른 관련 정보, 예컨대 본 발명에 따른 현재 보안 코드를 계좌 보유자 (5) 에게 제시하기 위해 애플리케이션들, 웹사이트들, 또는 API들을 호스팅하는 제 3 자 엔티티들에 의해 제공될 수도 있다.

마지막으로, 통지 서버 (9) (예를 들어, 그리고 제한 없이, HP Moonshot ProLiant m800) 는 계좌 보유자 (5) 에게 통지들을 전달 또는 푸시하기 위한 중개자로서 역할을 하는 임의의 서버일 수도 있다. 이러한 서버들 또는 서버들의 그룹의 일부 예들은 이메일 메시지들을 프로세싱 및 전달하기 위한 교환 서버들일 수 있고 또는 SMS 문자 메시지들을 프로세싱하고 계좌 보유자 (5) 에게 속한 휴대 전화로 전달하기 위한 SMS 통합 관리자의 서버일 수 있고, 또는 함께 이들 서비스들의 전부 또는 일부를 통합하는 웹 서비스 제공자 (예를 들어, Amazon Web Services 솔루션 내 Amazon Simple Notifications Service) 일 수 있다.

다음은 도 1에 나타난 서버 상호작용들/접속들의 개요이다. 본 발명에 따른 다양한 프로세스들의 구체적인 설명에 대해 보다 상세히 많이 논의될 것이다.

<A>: 중앙 데이터베이스 서버 (1) 는 하드웨어 기간 진성 난수 생성기 (RNG) 로부터 진성 난수들을 검색하기 위해, 또는 본 발명에 따라 생성된 보안 코드들과 같은, 센서티브 정보를 해시 또는 암호화하기 위한 암호 키들을 안전하게 저장하고 검색하기 위해, 예를 들어 SQL CLR 어셈블리를 통해, HSM (2) API들로의 호출들을 발행한다.

<B>: 계좌 보유자 등록 변경들을 제출하기 위해, 또는 지불 프로세서들로부터 수신된 거래 정보를 업데이트하기 위해, 또는 계좌 보유자들에게 통지들을 전송하거나 계좌 보유자 등록 변경들 또는 새로운 보안 코드들 (Temporary Known Random Patterns) 과 같은 관련된 정보로 지불 프로세서들을 업데이트하기 위한 정보를 검색하기 위해 중앙 애플리케이션 서버 (3) 는 중앙 데이터베이스 서버 (1) 에 접속한다.

<C>: 이 경우 계좌 보유자 등록 변경들 또는 새로운 보안 코드들 (Temporary Known Random Patterns) 로 프로세서의 데이터베이스 서버 (4) 를 업데이트하기 위해, 또는 지불 프로세서에 의해 수집된 정보 또는 프로세서의 데이터베이스 서버 (4) 내에서 생성된 변화들을 검색하고 이를 중앙 데이터베이스 서버 (1) 에 저장하기 위해, 프로세서의 데이터베이스 서버 (4) 중앙 애플리케이션 서버 (3) 는 가능하면 지불 프로세서의 네트워크 내 일 서버 또는 다층 서버들을 통해 프로세서의 데이터베이스 서버 (4) 와 통신한다.

<D>: 계좌 보유자 (5) 는 등록 프로파일들 또는 사용자 우선도들을 생성, 삭제, 또는 수정하기 위해 그리고 현재 보안 코드와 같은 시스템으로부터 정보를 검색하기 위해 계좌 보유자에 의해 사용된 통신 수단 (예를 들어, 데스크탑 또는 랩탑 컴퓨터, 스마트폰, 또는 휴대용 태블릿 컴퓨터) 중 하나 또는 다수를 통해 웹 서버 (8) 의 예에 호스팅된 웹 애플리케이션들과 인터페이싱한다.

<E>: 웹 서버 (8) 에 의해 수집된 정보 (예를 들어, 등록 변경들) 는 API 호출들을 통해 중앙 애플리케이션 서버 (3) 로 송신된다. 웹 서버 (8) 는 또한 시스템으로부터 정보를 검색하고 계좌 보유자 (5) 에게 제시하기 위해 중앙 애플리케이션 서버 (3) 로의 API 호출들을 발행한다.

<F>: 중앙 애플리케이션 서버 (3) 는 현재 보안 코드, 또는 계좌 보유자의 등록 프로파일 하에 등록된 계좌들을 수반하는 거래들 및 액티비티에 관한 정보와 같은 경보를 계좌 보유자 (5) 에게 푸시하기 위해 통지 서버 (9) 에 접속된다.

<G>: 통지 서버는 이메일 메시지들, SMS 텍스트 메시지들, 또는 모바일 애플리케이션 푸시 경보들과 같은 경보들을 계좌 보유자 (5) 에게 푸시한다.

<H>: 계좌 보유자는 제화들 또는 서비스들에 대한 지불 거래를 수행하기 위해, 판매자 또는 수취인 (7) 인터페이스와 리모트로, 예컨대 판매자의 웹 사이트를 통해, 스마트폰, 태블릿, 또는 워치와 같은 휴대용 디바이스 상에 설치된 모바일 또는 리모트 애플리케이션을 통해, 자동화된 전화 시스템 또는 사람 에이전트를 통해, 또는 판매자 위치의 물리적 단말을 통해 상호작용한다.

<I>: 판매자 또는 수취인 (7) 은 적용가능한 네트워크들 및 채널들을 통해 계좌 보유자 (5) 에 의해 제출된 거래 정보를, 승인 또는 거절을 위해 프로세서의 데이터베이스 서버 (6) 에 의해 프로세싱되도록 전송한다.

<J>: 본 발명에 따라 수행될 수 있는, 거래들의 경우, 프로세서의 데이터베이스 서버 (6) 는 거래 인증 요청의 일부로서 입력되는, 본 발명에 따라 보안 코드를 유효화하기 위해, 프로세서의 보안 코드 데이터베이스 서버 (4) 와 통신한다. 프로세서의 데이터베이스 서버 (6) 는 또한 프로세서의 데이터베이스 서버 (4) 로 거래 정보를 통신할 수 있고, 또는 지불 프로세서의 보안 코드 데이터베이스 서버 (4) 는 계좌 보유자 (5) 에 의해 수신된 또는 중앙 애플리케이션 서버 (3) 에 의해 생성된 정보를 프로세서의 데이터베이스 서버 (6) 로 전송할 수 있다.

도 2는 본 발명에 따라 보안 코드들을 생성하는 프로세스, 특히, 복수의 계좌 보유자들 (5) (때때로 본 명세서에서 "사용자들"로 참조됨) 과 각각의 몇몇 보안 코드들의 세트들을 연관시키는 결합된 매트릭스를 생성하는 프로세스를 예시한다. (본 개시의 목적들을 위해, 보안 코드들의 세트 각각은 본 명세서에서 때때로 "패턴들" 또는 "랜덤 패턴들" 또는 "일시적으로 공지된 랜덤 패턴들"과 같이 다양하게 지칭될 수도 있다.)

본 발명의 특정한 예에서, 각각의 보안 코드들은 제한된 수명 또는 유효 기간 (반드시 그러한 것은 아니지만, 보통, 날짜 또는 시간들의) 을 갖는 수학적으로 난수들이다. 난수들은 생성될 보안 코드들의 시퀀스들에서 예측불가능성을 최대화하도록 (기술분야에 공지된 바와 같은) 진성 난수 생성기에 의해 생성되는 것이 바람직하다.

본 발명의 다른 양태에서, 보안 코드들의 각각의 유효 기간들은 시간적으로 순차적이어서, 실제로, 보안 코드들 중 하나가 만료된 후, 계좌 보유자에 의해 사용될 수 있는 "다음" 보안 코드 (시간 순) 가 있다. 유효 기간들은 실질적으로 어떠한 시간적 중첩도 갖지 않은 순수하게 순차적일 수도 있지만, 일 유효 기간의 종점과 후속하는 유효 기간의 시점 사이에 (유효 기간의 길이와 비교하여) 상대적으로 작은 시간적 중첩 (예를 들어, 유효 기간이 하루일 때 1 시간 중첩) 을 구축하는 것이 유용할 수 있다. 즉, 일 보안 코드는 "다음" 보안 코드의 유효 기간의 시점 동안 짧은 시간 동안 유효하게 남아 있을 수도 있다. 이러한 중첩하는 유효 기간을 제공하는 이유는 거래가 일 유효 기간의 종점 전의 짧은 시간에 입력되고(예를 들어, 날짜 기준으로 유효 기간의 종점은 밤 12시일 때 11.30 p.m.), 이론적으로 계좌 보유자의 후속 보안 코드 제출을 요청하는, 밤 12시 이후까지 전자 지불의 실제 처리를 지연시키는 본 명세서에 개시된 바와 같은 정보 교환 또는 다른 프로세싱에 예상치 못한 지연이 있다면, 고객 (즉, 사용자/계좌 보유자) 의 모든 짜증 또는 불만을 회피하기 위한 것이다. 상대적으로 짧은 중첩은 계좌 보유자의 사용 편의성을 보장하는 한편, 한번에 유효한 것으로 계류 중인 2 이상의 보안 코드를 갖는 보안 리스크를 최소화하는 것을 밸런싱하는 것을 의미한다.

도 2 및 도 2a에 도시된 바와 같은, 새로운 매트릭스의 생성은 중앙 애플리케이션 서버 (3) 에서 개시된다 (예를 들어, 스케줄링된 빈도로 실행되는 소프트웨어 잡 (job) 애플리케이션에 의해). 이 비제한적인 예의 목적들을 위해, 매일의 동작이 가정되지만, 하루 동안 몇번, 또는 매일보다 짧게 자주 (예를 들어, 3 일에 한번, 예를 들어) 실행되도록 스케줄링될 수 있다.

일반적인 의미의 그룹들의 사용자들 또는 다른 개인들의 본 발명에 따른 매트릭스는 사용을 위해 보안 코드-보호된 액세스를 필요로 하거나 달리 전자 엔티티에 액세스한다. 일반적으로, 미리 결정된 매트릭스는 본 발명에 다른 시스템에 참여하는 미리 결정된 지불 프로세서와 연관된 모든 사용자들/고객들/지불인/등 (예를 들어, 지불 프로세서와 연관된 모든 지불 카드 보유자들) 을 포함한다. 부가적인 보안 코드들의 세트들이 (예를 들어, 사기성 액티비티가 검출되는 경우) 원래 할당된 보안 코드들의 세트들을 대체해야 할 수도 있을 때 가용한, 일종의 여분으로 생성될 수도 있다. 그러나, 본 명세서에 개시된 바와 같은 본 발명의 특성으로 인해, 이하에 더 논의될 수도 있는 바와 같이, 미리 결정된 보안 코드들의 세트와 2 이상의 사용자들을 연관시키는 것이 또한 본 발명의 범위 내에 있다.

다시, 예시의 목적들을 위해, 본 발명은 기본적으로 전자 지불 거래들의 인증의 맥락에서 본 명세서에 기술되었지만, 전자 엔티티들, 예컨대 개인 네트워크들, 정부 기관 웹사이트들, 등으로의 다른 종류의 전자적으로 인증된 액세스에 적용될 수 있다.

일반적으로, 매트릭스는 미리 결정된 세트의 각각의 보안 코드들 각각이 특정한 하루 중에 시간 길이 기간, 또는 특정한 하루와 같이 특정한 제한된 유효 기간을 갖는, 각각의 보안 코드들의 세트들을 규정하도록 난수들에 의해 채워진다. 보안 코드들의 세트들 각각은 고유의 식별자와 연관된다. 일단 이 방식으로 매트릭스가 채워지면, 사용자들은 고유 식별자들 중 하나 (본 명세서에서 패턴 ID로 지칭됨) 와 연관되어 이 식별자와 매칭하는 보안 코드들의 세트와 연관되게 된다. 이러한 기준으로, 미리 결정된 순간에 미리 결정된 사용자가 특정한 보안 코드들의 세트와 연관되고, 거래들을 승인하기 위해 사용자가 사용해야 하는 현재 유효한 코드는 적용가능한 유효 기간 (예를 들어, 특정한 하루) 에 대해 식별될 수 있다.

보안 코드 생성 프로세스는 바람직하게 미리 결정된 유효 기간에 대해 모든 패턴 ID들을 순환하고 이 유효 기간에 대한 패턴 ID 각각에 대해 (미리 결정된 길이의, 예컨대 4 자릿수) 새로운 난수 값을 할당한다. 이어서 다음 유효 기간에 대해 각각의 패턴 ID들 모두에 대한 난수 값들의 제 2 세트를 생성하도록, 하나씩 (one by one), 제 3 세트, 제 4 세트, 등을 생성하도록 진행하기 전에, 진행한다.

즉, 매트릭스는, 제 1 패턴 ID에 대한 난수들의 완전한 세트, 이어서 제 2 패턴 ID에 대한 완전한 세트, 이어서, 제 3, 제 4, 제 5, 등이 아니라, 바람직하게 각각의 상이한 패턴 ID들에 대한 난수를 생성함으로써 어셈블된다. 그 결과, 우연히 (예를 들어, HSM (2) 내) 난수 생성기에 의해 생성된 난수들의 시퀀스에 대해 사용되는 임의의 종류의 인식가능한 예측 가능성이 있다면, 예측 가능성은 단일 사용자에 대한 난수들의 세트 내가 아니라 상이한 사용자들 사이에 확산될 것이다. 이는 도 2a를 참조하여 이하에 예시된다.

도 2에서 알 수 있는 바와 같이, 반복 각각에 대한 이 난수 생성의 제 1 단계는 RNG, 예컨대 HSM (Hardware Security Module) (2) 으로부터 새로운 난수 값을 획득하는 것 (101) 이다. HSM (2) 는 바람직하게 진짜 RNG를 제공하지만, 의사-난수 생성기를 포함하여, 임의의 다른 종류의 RNG, 하드웨어 또는 소프트웨어 기반 RNG가 이 목적을 위해 사용될 수 있다. 예를 들어 진짜 난수를 제공하는 웹 서비스 또는 난수를 생성하기 위한 소프트웨어 또는 하드웨어 기반 알고리즘으로의 인터페이스를 제공하는 제 3 자 이진 애플리케이션, 또는 데이터베이스 엔진이 또한 사용될 수 있다.

HSM (2) 상의 RNG는, 단계 106에서, 예를 들어, 현재 반복 날짜 (또는 임의의 다른 목표된 시간 기간) (105) 에 대응하는 현재 반복의 패턴 ID (104) 에 할당되는 새로운 난수 값 (103) 을 생성한다. 이 예는 각각의 패턴 ID (104) 각각에 대해 날짜 (105) 각각에 대한 하나의 난수 값 (103) 을 생성한다. 그러나, 복수의 난수 값들은 특정한 날짜 또는 기간 기간에 엮일 수도 있거나 엮이지 않을 수도 있는 패턴 ID 각각에 할당될 수 있고, 또는 하루보다 짧거나 긴 시간 기간과 연관될 수 있다. 난수 값들은 또한 특정한 이벤트 또는 프로세스의 발생 빈도 또는 특정한 프로세스 식별자와 연관될 수 있다. 도 2에 개략적으로 나타낸 바와 같이, 난수 값들 (103) 을 생성하는 프로세스는 일련의 패턴 ID들의 제 1 레벨에서 반복적이고, 이어서 다음 유효 기간으로 증분된다 (본 명세서에서, 예로서, 유효 기간은 날짜이다).

도 2a는 매트릭스를 채우는 바람직한 프로세스를 예시하는 본 발명에 따른 매트릭스의 개략적인 표현이다. 왼쪽 열은 각각 난수 보안 코드들의 세트 (행 단위) 와 연관된 패턴 ID들 (0 내지 99999의 범위로 간략화됨) 을 포함한다. 본 명세서에서, 예를 들어, 패턴 ID 각각에 대한 난수 각각은 날짜별 유효성 기준 (1일, 2일, 3일, 등) 이다. 주 커서 ("7일" 열에 대해 어두운 하향 화살표) 로 인덱싱된 날짜 각각에 대해, 보조 커서 (본 명세서에서, 예를 들어, 패턴 ID 3에 대응하는 행) 는 다음 랜덤하게 생성된 보안 코드를 채우기 위해 패턴 ID들 각각을 통해 이동한다 (도 2의 "패턴 ID 각각에 대해" 단계들의 그룹에 대응). 따라서, 도 2a에서, 마지막으로 생성된 코드는 (패턴 ID 3; 7일) 에서 0166이다. 이어서 보조 커서가 다음 패턴 ID (즉, 4) 로 이동할 것이고 (패턴 ID 4; 7일) 에 대해 새로운 랜덤 코드를 생성하고, 7일에 대한 매트릭스의 모든 패턴 ID들에 대해 계속되고, 이어서 주 커서가 다음 날짜 열 (즉, 8일) ("날짜 각각에 대해"로 나타낸 도 2의 반복의 다음 레벨에 대응) 로 전진할 것이고, 난수 할당이 반복될 것이다. 그 결과, 상기 언급된 바와 같이, 임의의 미리 결정된 사용자에 대한 (즉, 임의의 미리 결정된 패턴 ID에 대한) 랜덤화된 보안 코드들의 세트가 남용된다면 (misappropriate), 일어날 수도 있는 난수 생성시 랜덤성의 결여 또는 임의의 패턴들이 행 단위 방향으로 명백하지 않을 것이다.

고객들/사용자들보다 많은 패턴들 (즉, 보안 코드들의 세트들) 이 매트릭스에 대해 생성될 수 있다는 것을 주의한다. 이는 예를 들어, 최초 보안 코드들의 세트가 절충되는 것으로 나타난다면 코드들의 대체 세트로서 고객에 의해 사용하는데 "여분의" 코드들의 세트들이 가용하게 할 수 있다. 예를 들어, 새로운 패턴 ID의 재할당에 대해 도 4에 대한 이하의 개시를 참조하라.

그러나, 고객들/사용자들보다 적은 패턴들이 생성되는 상황이 또한 본 발명에 따라 고려될 수 있다. 이러한 경우에서, 2 이상의 사용자가 미리 결정된 패턴 ID와 연관될 수도 있다. 따라서 예를 들어, 2 명의 사용자들이 엄격하게 말하면 다른 사람의 보안 코드들을 알 수도 있지만, 실제적으로, 일반적으로 어떤 사용자가 또 다른 사용자와 자신의 보안 코드들의 세트를 "공유"한다는 것을 알 것이라는 가능성이 매우 없고, 그리고 사용자들을 패턴 ID들에 할당하는 것이 사용자들에게 사실상 불투명하다는 것을 염두에 두고, 어떤 사용자가 공통 보안 코드들의 세트를 갖는다는 것을 구체적으로 알 가능성이 훨씬 더 없기 때문에, 보안 리스크는 여전히 낮다.

이들 난수 값들의 생성은 선택가능하게 교차 참조되거나 그렇지 않으면 매트릭스로부터 배제될 값들의 리스트와 비교될 수 있다. 예를 들어, 특정한 문화적으로 불쾌하거나 그렇지 않으면 민감한 값들 (예컨대, 서양 문화권에서 "13" 또는 일부 동양 문화권에서 "4") 이 배제될 수도 있다. 필요할 수도 있기 때문에, RNG-생성된 값은 배제 리스트에 대해 검토될 것이고, 발견된다면, 생성된 값이 배제 리스트에 없을 때까지 대체 값들 생성하도록 RNG에 대한 새로운 호출이 이루어진다.

일단 보안 코드들의 완전한 매트릭스 (일시적으로 공지된 랜덤 패턴들) 가 채워지면, 이어서 단계 107에서 중앙 데이터베이스 서버 (1) 상에 저장되도록 전송되고, 이 예에서 중앙 데이터베이스 서버 (1) 는 단계 108에서 매트릭스를 데이터베이스 표 내로 로딩한다. 매트릭스는 또한 다른 포맷들로, 예컨대 파일 시스템 내에 또는 픽토그램 표현 (pictographic representation) 으로 저장될 수 있다.

기술된 프로세스의 목적들을 위해, 이 플로우차트에 도시된 바와 같이 생성된 이 일시적으로 공지된 랜덤 패턴들의 매트릭스는 도 3의 단계 211로 도시된 바와 같이 등록된 계좌 보유자 각각에 패턴 ID를 할당하도록 사용되어, 새로운 랜덤 보안 코드가 계좌 보유자 (5) 에 의해 개시된 거래에 사용될 수 있다.

본 발명에 따라 지불 프로세서들이 지불 거래들을 지지할 수 있도록, (가끔 업데이트될 수도 있고 그렇지 않으면 개정될 수도 있기 때문에) 동일한 버전의 매트릭스가 단계 109에서 참여하는 지불 프로세서 각각에 분배된다. 바람직하게, 참여하는 지불 프로세서의 매트릭스의 버전 각각은 분배되기 전에 이 지불 프로세서에 고유한 방식으로 해시된다. 이어서 고유하게 해시된 매트릭스는 이 지불 프로세서와 연관된 보안 코드 데이터베이스 서버 (4) 상의 지불 프로세서 각각에 의해 국부적으로 로딩된다.

매트릭스 내 난수 값들은 바람직하게 산업 표준들 및 규칙들에 의해 신뢰성 있고 안전한 것으로 승인되는 SHA (Secure Hash Algorithm) 를 활용하여 해시된다. 예를 들어, SHA-512가 본 발명의 이 양태에 따라 사용될 수 있다. SHA-512를 포함하여, 몇몇 보안 해시 알고리즘들이 예를 들어, 2012년 3월 공개된, Federal Information Processing Standards Publication 180-4에 개시되고, 이의 내용들은 관련 특허청에 의해 허용되는 범위로 본 명세서에 참조로서 인용된다. 매트릭스의 난수 값들을 지불 프로세서들 또는 은행들로 송신되기 전에 해시하기 위해, 지불 프로세서 각각은 예를 들어, 110 단계 110에서 (HSM (2) 으로부터, 예를 들어) 고유 해시 솔트 (111) 가 할당되거나 그렇지 않으면 연관된다. 이 해시 솔트 (111) 는 또한 거래 인증 프로세스에서 사용하기 위해 각각의 지불 프로세서 각각으로 보안 및 암호화된 방식으로 전달된다. 기술분야에 공지된 바와 같이, "해시 솔트"는 미리 결정된 해시 프로세스를 위한 수학적 기준이다. 미리 결정된 문자열 (예를 들어, 본 발명의 숫자 보안 코드들 중 하나) 에 대해, 미리 결정된 해시 알고리즘을 사용하여 적용된, 미리 결정된 해시 솔트는 항상 동일한 해시된 버전의 문자열을 발생시킬 것이라는 것을 주의한다.

각각의 고유 해시 솔트들 (111) (즉, 각각의 지불 프로세서 각각에 대한 고유 해시 솔트) 를 사용하여, 동일한 매트릭스의 고유 해시된 카피들이 상이한 지불 프로세서들 (단계 112) 에 대해 생성되고, 매트릭스 각각은 난수들의 고유하게 해시된 표현들을 포함한다. 따라서, 패턴 ID 각각에 대해 생성되고 할당된 난수들의 실제 세트들은 이들을 등록된 계좌 보유자들에게 전달하기 위해 단지 중앙 데이터베이스 서버 (1) 에서 깨끗하게 유지된다. 지불 프로세서 각각은 보안 코드 데이터베이스 (4) 의 대응하는 예들에서 임의의 다른 지불 프로세서의 해시된 표현과 상이한 "지불 프로세서의" 이들 값들의 구별된 해시된 표현을 보유만 할 것이다 (단계 113).

도 3은 본 발명에 따른 계좌 보유자 (5) 가 시스템에 등록하는 방법의 프로세스를 예시한다. 계좌 보유자 (5) 는 등록 요청을 개시한다. 계좌 보유자 등록 프로파일이 이미 제시한다면 (201), 계좌 보유자 (5) 는 단계 212에서 기존 프로파일에 새로운/부가적인 계좌들을 등록하도록 진행할 수 있다. 그렇지 않으면, 새로운 계좌 보유자 등록이 필요하다면, 계좌 보유자 (5) 는 등록 프로파일을 생성하는데 필요한 정보를 입력하도록 단계 202로 진행한다. 이 정보는 예를 들어, 풀 네임 (full name), 청구지 주소, 연락 정보 (예컨대 모바일 전화 번호 또는 이메일 주소), 및 통지 우선도들을 포함할 수도 있다. 이 정보는 입력된 계좌 보유자 정보를 검증하기 위해 서브프로세스 (203) 에 의해 중앙 애플리케이션 서버 (3) 에서 유효화된다. 이 서브프로세스 (203) 는 주소 검증, 검증 서비스들 식별 (Identity Verification Services), 및 다른 타입의 고객 검증 (Know-Your-Customer) 단계들을 포함할 수도 있다.

일단 입력된 계좌 보유자 정보가 검증 단계를 통과하면 (단계 204), 일시적인 랜덤 문자숫자 또는 숫자 코드가 205에서 생성되고, 계좌 보유자 (5) 가 이메일 주소 또는 제공된 모바일 전화 번호와 연관된 물리적 디바이스에 액세스하는지 여부를 검증하기 위해, 입력된 이메일 주소 또는 모바일 전화 번호를 통해 통지 서브프로세스 (800) 를 통해 계좌 보유자에게 전달된다. 단계 206에서 (제한된 수명을 갖는) 일시적인 코드의 수신시, 계좌 보유자 (5) 는 단계 207에서 등록 애플리케이션 서비스로 재송신할 것을 요청받고, 이어서 중앙 애플리케이션 서버 (3) 에 의해 검증된다. 계좌 보유자에 의해 입력된 일시적인 코드가 단계 205에서 생성된 코드와 매칭하고 시간 상 여전히 유효하다면 (단계 208), 수집된 계좌 정보는 계좌 보유자 프로파일을 생성하도록 사용되고 (단계 209) 단계 210에서 중앙 데이터베이스 서버 (1) 상에 저장된다. 등록 프로파일이 중앙 데이터베이스 서버 (1) 에서 생성될 때, 패턴 ID (104) (예를 들어, 도 2a 참조) 가 211에서 새로 생성된 계좌 보유자 프로파일에 할당되고, 새로 생성된 계좌 보유자 프로파일에 의해 계좌 보유자 (5) 가 보안 코드들의 매트릭스에서 식별될 것이다. 이어서 계좌 보유자 (5) 가 도 4에 도시된 바와 같이 제공될 보안 코드들을 구동할 것이다. 이어서 계좌 보유자는 통지 우선도들에 따른 프로파일 생성 결과들의 서브프로세스 (800) (도 9 참조) 를 통해 통지되고, 통지 우선도들은 제공된 모바일 전화 번호로의 SMS 텍스트 메시지, 제공된 이메일 주소로의 이메일 메시지, 또는 모바일 애플리케이션 푸시 통지 중 하나 이상을 포함할 것이다. 이 계좌 보유자 등록 결과 통지는 이로 제한되는 것은 아니지만, 고유 계좌 보유자 프로파일 식별자, 및 전자 지불 거래들을 할 때 사용할 코드를 포함하는 서비스와 상호작용하는데 필수적인 정보를 포함할 수 있다.

일단 계좌 보유자 프로파일이 제시하면, 계좌 보유자 (5) 는 자신의 계좌 보유자 프로파일과 하나 이상의 계좌들을 연관시키도록 (212) 진행할 수 있다. 계좌 등록 프로세스 (212) 는 새로운 계좌를 식별하는 단계 (213) (예컨대 직불, 신용, 또는 당좌 계좌) 및 계좌 정보를 입력하는 단계 (단계 214) 를 포함할 수도 있다. 은행 계좌는 계좌 번호 및 은행의 RTN (Routing and Transit Number) 을 포함한다. 카드 계좌는 전체 카드 번호 (통상적으로 15 내지 16 자릿수, 때때로 보다 적고 때때로 보다 큰 자릿수), 만기일, 임의의 형태 또는 형상의 물리적 카드 상에 인쇄된 임의의 검증 코드, 또는 EMV (Europay, MasterCard, 및 Visa) 의 경우 디지털 검증 코드, 또는 적용가능하다면 가상 카드를 포함할 수도 있다.

중앙 애플리케이션 서버 (3) 는 입력된 정보가 유효한지 여부를 검증한다. 카드의 BIN (Bank Identification Number) 또는 계좌의 ABA RTN (routing number) 을 대응하는 은행 또는 지불 프로세서 (본 발명에 따른 시스템을 지원하는 서명된 금융 기관들 및/또는 지불 프로세서들에 대한 교차 참조) 에 맵핑하는 종래에 가용한 리소스들을 사용하여, 미리 결정된 계좌는 본 발명의 시스템에 참여하기 위해 215에서 적합성이 검토된다.

계좌가 적합하다면 (단계 215), 시스템은 입력된 계좌가 계좌 보유자에게 합법적으로 소유되는지 검증하도록 서브프로세스 (216) 로 진행하고, 그렇지 않으면, 계좌가 추가될 수 없다는 통지 서브프로세스 (800) 를 통해 계좌 보유자에게 통지된다. 계좌 검증 단계는 계좌 보유자 정보를 검증하는 웹 서비스 (예를 들어, 지불 프로세서, 또는 카드 발행자, 또는 또 다른 제 3 자에 의해 동작되는) 에 대한 호출, 주소 검증 및 CVV 검증을 포함할 수 있는 0 달러 값 인증 요청, 또는 계좌의 진정성을 검증하기 위해 인증된 협회에 의해 제공된 임의의 다른 서비스를 포함할 수도 있다. 은행 계좌의 경우, 검증 프로세스는 계좌 보유자 수신된 양을 확인함으로써 검증할 일련의 소량의 시도 보증금, 예를 들어 1 내지 99 센트의 랜덤한 양의 2 개의 보증금들을 포함할 수 있다.

217에서 계좌가 계좌 보유자 (5) 에게 유효하게 소유된다는 검증 후, 시스템은 218에서 계좌 보유자 프로파일에 이 계좌를 추가하고, 219에서 중앙 데이터베이스 서버 (1) 상에 저장하도록 진행한다. 계좌의 지불 프로세서 또는 은행 ID 정보가 221에서 중앙 데이터베이스 서버 (1) 를 조사함으로써 단계 220에서 검색된다. ID 정보 222를 사용하여 시스템은 지불 프로세서에 의해 제공된 API를 호출함으로써, 또는 지불 프로세서의 시스템 상으로 송신되고 로딩된 파일에 의해, 또는 미리 결정된 새로운 계좌의 추가를 기록하도록 이들 시스템을 업데이트하기 위해 지불 프로세서에 의해 제공된 임의의 다른 수단에 의해 223에서 지불 프로세서의 데이터베이스 서버 (6) 로 이 정보를 전송한다. 지불 프로세서로 송신된 정보는 계좌 보유자의 등록 프로파일 정보 및 특히 프로세서로 하여금 미래 거래 인증 요청들의 보안 코드들의 현재 매트릭스의 계좌 보유자의 보안 코드를 유효화하게 하는 등록 프로파일 정보를 연관된 패턴 ID를 포함한다.

마지막으로, 계좌 보유자는 통지 서브프로세스 (800) 를 통해 통지받고 224에서 계좌 등록의 확인을 수신한다.

보안 코드들을 생성하고 관리하기 위한 현재 개시된 방법 및 시스템은 전자 지불 보안 및 금융 거래 보안 이외의 도메인들에 사용될 수 있다. 예를 들어, 웹 사이트, 실험실, 사무실, 등이 부가적인 인증 또는 액세스 제어 메커니즘으로서 고용인들에게 매일 보안 코드를 전달하기 위해 본 발명을 구현할 수도 있다. 상이한 영역들에서, 본 발명에 따른 코드들은 판매자, 서비스 제공자 또는 다른 타입들의 정부 또는 개인 협회들로부터 신용 거래, 새로운 계좌들 또는 서비스들을 적용하기 위해 계좌 보유자들에 대한 아이덴티티의 부가적인 증명으로서 구현될 수 있다.

계좌 보유자는 상기 기술된 바와 같이, 단일 도메인 내에서 또는 많은 (특히, 많은 관련되지 않은) 도메인들에 걸쳐 사용하기 위해 본 발명에 따른 일일 보안 코드를 수신하도록 등록할 수 있다. 예를 들어, 계좌 보유자는 2 개의 상이한 발행자들/프로세서들로부터, 뿐만 아니라 계좌 보유자의 작업 공간 액세스 제어 시스템, 등에 대해 신용 카드들을 등록할 수도 있다. 상기 기술된 바와 같이 복수의 등록 프로파일들을 갖는 계좌 보유자는 각각 본 발명에 따른 각각의 보안 코드를 갖는 하나 이상의 그룹들로 프로파일들을 그룹화하는 것을 선택하기 원할 수도 있다. 즉, 따라서 계좌 보유자는 계좌 보유자가 등록하는 모든 상이한 구현예들에 매일 유효한 단일 (또는 적어도, 보안 코드들을 필요로 하는 도메인들의 총 수와 비교하여 보다 적은) 보안 코드를 사용할 수 있다.

구현예들의 이러한 그룹화의 예에서, 보안 코드 등록 프로파일 (SCRP: Security Code Registration Profile) 은 개인 사용자 및 단일 금융 계좌, 또는 보안 액세스를 필요로 하는 비금융 계좌의 단일 예이다. 이로 제한되는 것은 아니지만, 비금융 계좌들은 웹사이트 액세스, 컴퓨터 사인-온 스크린들, 또는 물리적 액세스 제어 상황을 포함한다. 본 발명에서, SCRP는 단일 프로세서의 데이테베이스의 단일 계좌 보유자의 프로파일이다.

기억해야 하고 사용하기 위한 보안 코드들의 수를 감소시키는 동안 보다 쉬운 사용을 인에이블하기 위해, 복수의 신용 카드들, 직불 카드들, 금융 계좌들, 및 보안 로그인들이 원하는 바에 따라 그룹화될 수 있다. 일단 그룹화되면, 그 그룹의 모든 SCRP들은 동일한 패턴 ID를 가질 것이고, 매일 동일한 보안 코드를 수신할 것이다. 이러한 방식으로, 예를 들어, 개인은 모든 직불 카드들 및 신용 카드들에 대해 동일한 보안 코드를 수신할 수 있다.

그룹화는 단일 개인으로 제한되지 않아야 한다. 예를 들어, 가족이 동일 그룹의 전체 가족의 신용 카드들 및 직불 카드들을 갖도록 선택할 수 있고, 모든 가족 구성원들이 모든 신용 카드들 및 직불 카드들에 대해 매일 동일한 보안 코드를 가질 수 있다.

또 다른 예에서, 법인 신용 카드들을 갖는 모든 고용인들이 그룹화될 수 있고, 각각의 법인 신용 카드들 각각에 대해 동일한 보안 코드를 매일 수신할 것이다. 또 다른 예에서, 군대 분대/소대/부대/등의 모든 구성원들이 자신의 소대의 멤버쉽을 확인할 방법으로서 동일한 보안 코드를 매일 수신할 수 있다.

개인들은 몇몇 그룹들의 구성원들일 수 있고, 뿐만 아니라 어떠한 그룹의 구성원들도 아닌 SCRP를 갖는다. 그룹 및 비그룹 SCRP 각각에 대해, 개인은 고유 보안 코드를 수신할 것이다. 예를 들어, 사람은 "가족 그룹"의 모든 신용 카드들, 직불 카드들; "회사 그룹"의 단일 사업용 신용 카드; 및 "그룹화되지 않은" 당좌 계좌를 가질 수 있다. 이 경우, 본 발명에 따라 사람은 매일 3 개의 고유 보안 코드들을 수신할 것이다.

그룹화 기준은 시스템에 의해, 또는 계좌 보유자 각각에 의해, 또는 그룹들의 그룹에 대해 허가된 관리자에 의해 이전에 확립된 규칙들에 의해 결정될 수도 있다. 예를 들어, 자동 그룹화 규칙들은 2 개의 계좌 보유자 프로파일들이 동일한 이메일, 전화, 또는 다른 이전에 검증된 콘택트 정보를 공유한다면, 매칭 프로파일에 대해 매일 생성되고 전달된 코드들이 그룹화될 것이고 동일한 매일로 싱크될 것이다.

또 다른 예에서, 등록된 계좌 보유자는, 인증된 계좌 보유자 또는 그룹 관리자의 인증시 특정한 구현예에 대해 매일 통일한 코드를 수신하기 위해, 또 다른 계좌 보유자의 프로파일과 그룹화될 초대 요청을 개시할 능력이 부여된다.

도 3a는 계좌 보유자의 프로파일이 또 다른 계좌 보유자 또는 그룹과 함께, 자동으로 또는 온디맨드 (on-demand), 그룹화될 때, 도입된 고레벨 단계들을 예시한다.

그룹 할당 프로세스 231이 개시될 때, 계좌 보유자에 의해 온디맨드 요청되면 232, 그룹에 합류하려는 인증 요청 233이 개시된다. 계좌 보유자가 요청한 그룹에 합류하도록 인증되면 (234), 계좌 보유자의 등록 프로파일 예가 단계 235에서 할당되고, 통지 프로세스 800이 그룹 할당 프로세스 내 모든 관련 이해 당사자에게 통지하기 위해 개시된다. 그러나 단계 234에서 계좌 보유자가 요청된 그룹에 대해 인증되지 않는 것으로 생각되면, 액션이 취해지지 않고 계좌 보유자는 단계 236마다 현재 할당된 그룹에 남는다. 통지 단계 800은 또한 이 시나리오에서 요청된 그룹에 액세스하려고 시도하는 인증되지 않은 이해 당사자들에게 경고하도록 트리거된다.

그룹에 합류하려는 요청이 단계 232에서 온디맨드가 아닌 것으로 (즉, 자동으로) 식별되는 대안적인 경로에서, 그러면 계좌 보유자에 대해 자동 프로파일 그룹화 규칙들을 찾기 위한 프로세스가 단계 240에서 수행된다. 규칙들이 단계 241에서 확립된 기준에 매칭하는 것으로 발견되면, 계좌 보유자의 등록 프로파일 예가 단계 242에서 기존 그룹에 자동으로 할당되고 이에 따라 통지들이 단계 800에서 전송된다. 그렇지 않으면, 액션이 취해지지 않고 계좌 보유자는 단계 236 마다 현재 또는 새롭게 할당된 그룹에 남고, 통지들은 단계 800에서 개시된다.

상기 참조된 그룹들의 일부 예들은 도 3b 내지 도 3g에 후속하여 예시된다. 예를 들어 도 3b는 단일 보안 코드 등록 프로파일, 이 예에서, 저절로 고유의 그룹 G1에 속하는 신용 카드 P1C1을 갖는 단일 개인 P1을 예시한다. 이는 계좌 P1C1이임의의 다른 등록된 계좌와 보안 코드를 공유하지 않는다는 것을 의미한다. 즉, 패턴 ID들 및 이들의 연관된 보안 코드들이 의도적으로 매칭하지 않는다.

보안 코드 등록 프로파일 (SCRP) 각각은 특정한 보안 코드에 임의의 미리 결정된 시간 기간이 할당된 패턴 ID이 할당된다는 것을 주의해야 한다. 무한 수의 보안 코드들이 가용하기 때문에, 숫자가 매우 크더라도 임의의 미리 결정된 순간적인 2 개의 상이한 패턴 ID들이 자신들에게 할당된 동일한 보안 코드를 가질 것이라는 것이 합리적으로 가능하다.

도 3c는 모두 함께 단일 그룹 G2에 그룹화되는, 3 개의 상이한 신용 카드 SCPR들 (P2C1, P2C2, P2C3), 뿐만 아니라 하나의 직불 카드 SCRP P2D1을 갖는 단일 계좌 보유자 P2를 예시한다. 이는 본 발명에 따라, 이들 SCRP들 하에서 등록된 모든 4 개의 계좌들이 매일 그룹 G2에 대응하는 동일한 보안 코드를 수신할 것이라는 것을 의미한다. 이러한 시나리오의 실제 예는 지갑의 모든 카드들이 매일 동일한 보안 코드를 수신하기 원하는 계좌 보유자이다.

도 3d는 저절로 그룹 G3인 하나의 신용 카드 SCRP P3C1, 뿐만 아니라 2 개의 다른 신용 카드 SCRP들 (P3C2, P3C3), 및 하나의 직불 카드 SCRP P3D1을 갖고, 이들 3 개는 그룹 G4에 함께 그룹화되는 단일 계좌 보유자 P3을 도시한다. 이는 계좌 보유자가 하나 이상의 SCRP들이 하나의 그룹으로 그룹화되고, 하나 이상의 나머지들이 별도의 그룹으로 그룹화되도록 선택할 수도 있어서, 2 개의 그룹들이 매일 별도의 보안 코드를 수신하는 예를 도시한다. 예를 들어 계좌 보유자는 개인의 모든 카드에 대해 유효한 단일 보안 코드를 매일 수신하기 위해 함께 그룹화된 모든 개인용 신용 카드 및 직불 카드 및 개인 계좌들에 유효한 보안 코드와 상이한 보안 코드를 수신하는 사업용 신용 카드 및 직불 카드 계좌들에 대해 별도의 그룹을 가질 수도 있다.

도 3e는 상이한 개별 계좌 보유자들에게 속한 상이한 SCRP들이 또한 매일 동일한 보안 코드를 수신하도록 함께 그룹화될 수 있는 예를 도시한다. 이 도면은 예를 들어 상이한 보안 코드 등록 프로파일들 하의 계좌들의 세트에 대해 매일 동일한 보안 코드를 수신하기 원하는 가족, 사업, 조직, 또는 소셜 그룹의 구성원들에 의해 사용될 수 있다. 이 예에서, 계좌 보유자 P4에게 속하는 신용 카드 SCRP들 P4C1, 뿐만 아니라 계좌 보유자 P5의 신용 카드 SCRP P5C1, 및 둘 다 계좌 보유자 P6에게 속한 SCRP P6C1 및 P6D1는 모두 단일 그룹 G5 하에 등록된다. 따라서 계좌 보유자 P4, P5, 및 P6은 각각 매일 동일한 보안 코드를 수신한다.

상기에 이전에 표현된 바와 같이, 보안 코드들은 전자 지불 보안 및 금융 거래 보안 이외의 도메인들 또는 애플리케이션들에서 사용될 수 있다. 도 3f는 예를 들어 사무실 건물에 물리적으로 액세스하기 위해, 또는 보안된 공공 또는 사설 네트워크 상의 웹사이트 또는 네트워크에 가상으로 액세스하려고 사용된 보안 코드일 수 있는, 액세스 코드 SCRP들을 갖는 복수의 개별 계좌 보유자들 P7 내지 P11을 예시한다. 이 예시에서, 개별 계좌 보유자들 P7, P9, P10, 및 P11에 각각 속한 모든 액세스 코드 SCRP의 P7A2, P9A1, P10A1, 및 P11A1은 매일 동일한 보안 코드를 수신하기 위해 단일 그룹 G7에 함께 그룹화된다. 동시에, 개별 계좌 보유자 P7은 또한 상이한 개인 계좌 보유자 P8에게 속한 또 다른 SCRP P8A1와 공유된, 별도의 그룹 G6에 속한 별도의 SCRP P7A1을 보유한다. SCRP들 P7A1 및 P8A1은 또한 둘 다 동일한 그룹 G6과 연관되는 한 매일 동일한 보안 코드를 수신한다. 이 예에서, 단일 계좌 보유자 P7은 등록되고 상이한 개별 계좌 보유자들과 상이한 그룹들 G6 및 G7의 복수의 SCRP들을 보유한다. 이러한 예의 실제 애플리케이션은 상이한 네트워크들 상에서 2 개의 상이한 역할들, 예를 들어 "제한된 사용자" 및 "관리자-사용자"를 연기하고, 역할 각각에 대해, 그룹 각각에 대해 다른 개인들과 공유된, 상이한 보안 코드를 필요로 하는 개인일 수 있다.

본 명세서에 예시된 또 다른 도메인은 소셜 그룹, 예를 들어 비밀 소셜 클럽에 액세스, 허가를 얻거나 소셜 그룹에 속한 것으로 단순히 인식되거나 식별되는 개별 계좌 보유자들에 의해 사용되는 보안 코드일 수 있는 소셜 코드로서 참조된다. 도 3g는 복수의 개별 계좌 보유자들 P12, P13, P14, P15, 및 P16 각각이 모두 매일 동일한 보안 코드를 수신한다는 것을 보증하는, 모두 동일한 그룹 G8의 각각의 소셜 코드 SCRP들 P12S1, P13S1, P14S1, P15S1, P16S1을 갖는 것을 예시한다.

도 3h는 본 발명을 구현하기 위해 SCRP들 및 SCRP들이 할당된 그룹들이 도표 형태로 표현되고 데이터베이스에 저장될 수 있는 방법의 예를 도시한다. 표 T1은 SCRP, 계좌가 속한 (엔티티) 의 PID, 및 할당된 그룹 GroupId (예를 들어, G1, G2, G3, 등) 의 예 각각을 보유한다. 표들 T2A, T2B, 및 T2C는 각각 어떤 보안 코드 패턴 PatternID가 미리 결정된 날짜 기간 (즉, 유효 기간) 의 그룹 GroupId 각각에 할당되는지 보유하는 표의 세그먼트들이다. 날짜 기간은 할당된 PatternID가 유효한 기간 각각의 시작 날짜 및 종료 날짜를 지정하는 "From date" 그리고 "To date"로 나타낸다. 이어서 PatternID 각각은 날짜 Day1Code, Day2Code, 등 각각에 대해 상이한 보안 코드를 할당하는 표 T3에 나타난다. 즉, 날짜 각각은 어떤 그룹 GroupId, SCRP가 할당되는지를 조사하기 위해 이들 표들을 자세히 고찰하고 (traverse); 이어서 미리 결정된 날짜/시간 기간 동안 어떤 PatternID가 이 GroupId에 대해 유효한지 조사하고; 이어서 이 특정한 날짜/시간 기간 (이 예에서 날짜) 에 대해 어떤 보안 코드가 할당되는지 조사함으로써 특정한 SCRP에 대해 어떤 보안 코드가 유효한지 결정될 수 있다. GroupId 및 날짜 조합은 GroupId 각각에 대해 PatternID 할당이 회전하는 방법에 무관하게, 항상 동일한 보안 코드 (날짜/시간 기간 변화의 짧은 지속 기간 동안 2 개의 코드들) 를 렌더링한다. 따라서, 동일한 GroupId 할당을 공유하는 2 개의 SCRP들은 또한 매일 동일한 보안 코드를 공유하는 것이 보증된다.

도 4는 규칙적으로 대응하는 활성 보안 코드(들)를 등록된 계좌 보유자들에게 제공하는 프로세스 동안 일어나는 단계들을 기술한다.

계좌 보유자의 프로파일과 연관된 현재 활성 보안 코드를 수신하기 위해, 계좌 보유자 (5) 는 보안 코드를 요청할 수 있거나 중앙 애플리케이션 서버 (3) 로부터 구동된 자동 푸시를 통해 보안 코드를 자동으로 수신할 수 있다.

계좌 보유자 (5) 에 의해 코드가 요청되면, 요청 301이 계좌 보유자 (5) 로부터, 예를 들어, 디바이스 설치된 애플리케이션을 통해 또는 적어도 계좌 보유자에 대한 현재 보안 코드를 검색하기 위해 결국 중앙 애플리케이션 서버 (3) 에서 API와 통신하는 웹 애플리케이션을 호출함으로써 (예컨대 지불 프로세서 또는 계좌 보유자의 온라인 뱅킹 웹사이트 페이지로부터의 API 호출), 또는 모바일 발신된 SMS 텍스트 메시지를, 텍스트 메시지들을 중앙 애플리케이션 서버 (3) 로 지향시고 이어서 계좌 보유자 (5) 에게 (현재 보안 코드를 포함하는) SMS 응답을 개시하는 시스템-제공된 SMS 짧은 코드로 전송함으로써, 전송된다.

계좌 보유자 (5) 로부터의 요청은 계좌 보유자를 식별하는 Profile ID 302, 및 요청이 발신되는 디바이스 또는 애플리케이션을 식별하는 소스 식별자를 포함해야 한다. Profile ID는 계좌 보유자 (5) 와 연관된 등록 프로파일을 고유하게 식별해야 한다. 디바이스의 소스 식별자는 요청을 전송하는데 사용된 모바일 전화 번호 또는 모바일 애플리케이션 식별자, 또는 이 요청을 수행 (즉, 전송) 하는데 사용된 디바이스에 엮인 임의의 다른 ID일 수 있다. 바람직하게, 요청은 요청의 승인을 유효하게 하기 위해 소스 식별자 (Source ID) 및 Profile ID를 포함한다.

계좌 보유자 프로파일을 찾기 위해 (단계 303), 중앙 애플리케이션 서버 (3) 는 계좌 보유자 프로파일을 조사하도록 (단계 304) 중앙 데이터베이스 서버 (1) 의 프로세스를 호출한다. 인증 보안을 최대화하기 위해, 프로세스는 먼저 등록된 사용자 또는 계좌 보유자와 연관되는 것으로 공지된 인증된 디바이스/입력 소스로서 Source ID를 검증한다. 수신된 Source ID를 사용하여 계좌 보유자 프로파일이 305에서 발견되고, 요청 내에 계좌 보유자에 의해 표시된 Profile ID는 식별된 계좌 보유자 프로파일에 대해 유효하면 (단계 306), 중앙 애플리케이션 서버 (3) 는 보안 코드 요청을 충족시키도록 진행한다 (단계 307). 그렇지 않으면, Profile ID가 식별된 계좌 보유자 프로파일과 매칭하지 않으면, 통지 서브프로세스 (800) 는 무효 보안 코드 요청이 수신되었다고 계좌 보유자에게 통지하도록 사용된다. 서브프로세스 (800) 는 SMS 메시지, 또는 이메일 메시지와 같은 계좌 보유자 프로파일에 명시된 하나 이상의 통지 우선도들을 사용할 수 있다.

계좌 보유자 (5) 는 교번적으로 시스템으로부터 수신된 통지에 대해 응답 또는 현재 보안 코드를 갱신하거나 대체하기 위한 요청 (예를 들어, 의심스러운 사기성 액티비티의 경우) 을 개시할 수 있다. 이 경우, 중앙 데이터베이스 서버 (1) 는 대응하는 계좌 보유자의 등록 프로파일에 상이한 패턴 ID (104) 를 할당하고, 이 업데이트를 모든 참여하는 지불 프로세서들에 푸시한다. 그 후 계좌 보유자는 새로운 패턴 ID (및, 사실상, 새로운 근본적인 매트릭스) 와 연관된 새로운 현재 보안 코드를 통지 받는다 (단계 800).

현재 보안 코드의 자동화된 주기적인 "푸시"를 위해, 요청 (312) 은 업데이트된 보안 코드 통지가 제공되기 적합한 중앙 데이터베이스 서버 (1) 의 복수의 계좌 보유자들 (5) 을 조사하기 위해 자동으로 전송된다 (단계 313). 이들 업데이트들의 빈도는 업데이트들이 전송되는 날짜일 수 있기 때문에, 계좌 보유자들에 의해 선택될 수 있다. 일단 자동 업데이트들을 필요로 하는 계좌 보유자들의 그룹이 확립되면, 서브프로세스 (도 4에서 "계좌 보유자 각각에 대해"로 라벨링됨) 가 계좌 보유자들 각각에게 현재 보안 코드를 통지하도록 실행된다.

계좌 보유자에게 통지 또는 경보를 전송하기 위해 (상기의 어떤 경우든), 중앙 애플리케이션 서버 (3) 는 미리 결정된 계좌 보유자의 보안 코드를 조사하기 위한 요청 307을 개시한다 (단계 308). 계좌 보유자의 등록 Profile ID로부터, 대응하는 패턴 ID가 검색되고, 현재 유효 기간 (예를 들어, 현재 날짜) 에 대해 이 패턴 ID에 대응하는 보안 코드가 일시적으로 공지된 랜덤 패턴 매트릭스 또는 표로부터 풀링된다. 이어서 계좌 보유자 (5) 는 현재 보안 코드를 통지받는다 (800).

이러한 현재 보안 코드의 통지는 단순히 웹 또는 데스크 탑 또는 모바일 애플리케이션 요청 또는 계좌 보유자의 디바이스에 설치된 웹 브라우저 플러그인 애플리케이션을 리턴할 수 있다. 보안 코드는 또한 계좌 보유자의 이전에 확립된 통지 우선도들에 기초하여, 예를 들어, 계좌 보유자에 대해 등록되고 유효화된 모바일 전화 번호로의 SMS 텍스트 메시지, 또는 이메일 메시지, 또는 모바일 애플리케이션 푸시 통지를 통해 전달될 수 있다.

본 발명의 변형에서, 새로운 보안 코드를 사용자에게 제공하는 프로세스는 사용자가 사실상 완전히 새로운 보안 코드들의 세트와 연관되도록 패턴 ID를 주기적으로 변화시키는 것 (즉, 미리 결정된 보안 코드들의 세트 내 보안 코드를 업데이트를 업데이트하기만 하는 것이 아니라) 을 부가적으로 통합할 수 있다. 예를 들어, 주기적인 기준으로 (예를 들어, 7 일마다), 서브프로세스 (본 명세서에 예시되지 않음) 가 사용될 수 있고, 새로운 패턴 ID를 모든 사용자에게 규칙적으로 재할당한다. 예를 들어, 패턴 ID들이 숫자이면, (가능하지만 필수적이지는 않은 HSM (2) 에서 사용된 것과 동일한) RNG는 사용자에게 재할당될 패턴 ID들의 가용한 범위 내 랜덤한 새로운 패턴 ID를 생성하도록 사용될 수 있다.

패턴 ID들을 주기적으로 재할당하는 것은 바람직하게 임의의 미리 결정된 사용자와 임의의 미리 결정된 보안 코드의 연관의 랜덤성을 더 상승시키고, 따라서 해킹, 패턴 공제 (deduction), 및 사용자의 보안 코드들을 액세스하고 그리고/또는 미래의 보안 코드들을 예측하기 위한 다른 노력들을 막아내는 것을 돕는다.

도 5는 고레벨 판매자 또는 수취인 지불 인터페이스들에 대한 계좌 보유자 (5) 에 의해 이루어진 전자 지불 인증 요청, 예를 들어, 구매 진행을 예시한다. 본 명세서의 주 초점은 도 6에 대해 보다 상세히 나중에 기술되는 거래 인증 서브프로세스 (500) 에 대한 호출이다.

구매 또는 전자 지불 거래 요청 등의 개시 시점에, 계좌 보유자 (5) 는 판매자 또는 수취인 (7) 과의 거래를 완료하기 위해 지불 인증 요청을 개시하기 위해 필수적인 정보를 제출한다 (단계 401).

계좌가 계좌 보유자 (5) 의 프로파일과 이전에 연관된 계좌와 관련된다고 가정하면, 계좌 보유자 (5) 는 일반적으로 거래 요청의 일부로서 현재 유효한 보안 코드를 포함한다. 예를 들어, 보안 코드는 지불 카드의 종래의 CVV2 코드의 자리, 또는 CVV와 같은 다른 카드 정보의 자리, 또는 카드 번호와 연쇄하여, 또는 전자 토큰 또는 프록시 번호에 의해 구현된, 또는 본 발명에 따른 보안 코드를 수신하도록 구체적으로 전용된 별도의 필드와 같은 방식으로 제출될 수 있다.

수표 지불을 위해, 본 발명의 보안 코드는 수표의 메모 필드에 명시, 예를 들어, 수표의 메모 필드의 필드 지표를 가질 수 있다. 예를 들어, 본 발명에 따른 4 자릿수 보안 코드는 단어 또는 심볼을 앞에 붙일 수 있다. 양 측면의 미리 결정된 심볼 또는 문자로 제한될 수 있다, 예를 들어 "+4567+"에서 "+".

대안적으로, 보안 코드는 미리 규정된, 일반적으로 용인되고 예상되는 포맷에 따라 연장된 수표 번호를 효과적으로 생성하기 위해, 수표 상에 인쇄된 수표 번호와 연쇄될 수 있다. 예를 들어, 예를 들어, 456의 보안 코드와 함께 사용된, 수표 번호 101은 실제로 통상의 수표 번호 필드에 "101456"으로 인쇄될 수 있다. 수표는 연장된 수표 번호 "101456"을 수신하는 은행에 의해 ACH 파일에서 통상의 방식으로 프로세싱될 것이다.

다른 예들에서, 보안 코드는 입력 필드에 계좌 보유자가 수동으로 기록함으로써 또는 실제 사람에게 구두로, 또는 음성 인식 시스템을 통해 별도로 제공될 수 있다. 그러면 판매자는 ACH 요청 파일 (예를 들어, 부록 또는 입력 상세 필드들) 의 정보를 포함한다.

판매자 또는 수취인 (7) 은 계좌 보유자 (5) 에 의해 제출된 정보를 수신하는 종래의 지불 인터페이스를 갖는다. 계좌 보유자 (5) 가 카드 또는 수표 402를 사용하는지 여부에 따라, 그리고 판매자가 온라인으로 접속되었다면, 시스템은 관련 지불 프로세서 (도 1의 6 참조) 를 통해 전자 지불 인증 요청 405 을 즉시 전송하거나, ACH 이송 요청 403을 스케줄링하고, 형성하고, 나중에 ACH 이송 요청 403을 판매자 또는 수취인 (7) 과 대응하는 지불 프로세서, 수신 은행, 또는 ACH 요청들을 프로세싱하기 위한 다른 금융 기관 사이에 이전에 확립된 채널들을 통해, 관련된 지불 프로세서로 전송한다. 이는 판매자 또는 수취인 (7) 과 프로세서 또는 수신 은행 사이의 지불 게이트웨이 서비스 제공자, 지불 프로세싱 네트워크, 연방 준비 은행 또는 전자 지불 네트워크, 또는 임의의 다른 서비스 또는 서버 중개자를 포함할 수 있다.

이어서 지불 프로세서는, 도 6에 대해 이하에 상세히 기술된, 카드 지불 요청을 수신함으로써 또는 ACH 거래 요청 404의 프로세싱의 일부로서, 거래 인증 서브프로세스 (500) 를 개시한다. 이 서브프로세스 (500) 는 거래 인증 요청을 승인하거나 거절하고 그 결과 406을 판매자 또는 수취인 (7) 의 요구에 적절한 방식으로 단계 407에서 판매자 또는 수취인 (7) 로 다시 전송한다. 판매자 또는 수취인 (7) 은 계좌 보유자 인터페이스 409에서 인증 결과를 계좌 보유자 (5) 에게 통지한다.

도 6은 거래 인증의 서브프로세스 (500) 를 예시한다. 도 5에 따라 카드 또는 수표 지불 프로세스 (400) 가 개시될 때, 지불 프로세서 또는 수신 은행은 502에서 거래 타입 및 계좌가 본 발명에 따른 프로세싱에 적합한지 여부를 결정한다. 지불 프로세서는 거래가 본 발명에 따른 프로세싱에 적합한지 결정하기 위해 필요한 정보를 포함하는 (예를 들어, 지불 프로세서와 연관된 서버들 중 하나, 예컨대 보안 코드 데이터베이스 서버 (4) 또는 데이터베이스 서버 (6) 에 위치된) 데이터베이스 표 또는 구성 파일을 쿼리함으로써, 또는 지불 프로세서의 네트워크 내 또는 도 1에 예시된 중앙 시스템에 리모트로 (상대적으로) 호스팅된 API에 대한 호출을 발행함으로써 이를 수행한다. 적합성은 또한 예를 들어 ISO 8583 필드들 중 하나의 거래 인증 요청 페이로드, 또는 수신된 NACHA ACH 파일에 포함된 특정한 지표들을 검사함으로써 결정될 수 있다.

502에서 거래가 본 발명에 따른 프로세싱으로 검정되지 않는다면, 지불 프로세서는 509에서 정상적인 (즉, 종래의, 본 발명의 보안 코드를 사용하지 않는) 인증 승인 프로세스를 계속한다. 그렇지 않으면, 프로세서의 데이터베이스 서버 (6) 는 거래 검증 프로세스를 개시하기 위해 지불 프로세서의 보안 코드 데이터베이스 서버 (4) (프로세서의 네트워크에 국부적일 수 있거나 리모트 위치에) 설치되고 구현된 애플리케이션 또는 프로세스에 대한 호출을 발행한다. 프로세서의 데이터베이스 서버 (6) 는 예를 들어, 리모트 저장된 절차 호출, 또는 연장된 저장된 절차, 또는 지불 프로세서의 보안 코드 데이터베이스 (4) 에 액세스하는 프로세서의 데이터베이스 서버 (6) 에 설치된 어셈블리와 인터페이싱하는 SQLCLR을 발행함으로써 지불 프로세서의 보안 코드 데이터베이스 (4) 와 인터페이싱한다. 대안적으로, 프로세서의 데이터베이스 서버 (6) 는 결국 지불 프로세서의 보안 코드 데이터베이스 (4) 에 액세스하는 로컬 또는 리모트 서비스 또는 API와 통신한다.

인증 요청의 일부로서 프로세서의 데이터베이스 서버 (6) 로부터 수신된 정보는 문제의 계좌가 지불 프로세서의 보안 코드 데이터베이스 (4) 상에 저장된 활성 계좌 보유자 등록 프로파일과 연관되는지 결정하도록 검사된다. 지불 프로세서의 데이터베이스 서버 (6) 로부터 수신된 거래 데이터는 계좌 보유자 및 사용된 카드 또는 계좌와 연관된 유효 보안 코드를 검색하기 위해 계좌 보유자의 등록 Profile ID 및 대응하는 패턴 ID (104) 를 조사하도록 사용된다. 본 명세서에 기술된 구현예에 따른 일 예에서, 이 거래 데이터는 계좌 보유자 (5) 에 의해 사용된 실제 카드 번호 또는 은행 계좌 번호 (민감한 금융 정보의 유포를 더 제한하기 위해) 대신 계좌 별칭 604 (도 7 참조) 을 포함할 수도 있다. 이러한 의미에서 계좌 별칭은 카드 또는 은행 계좌 번호들의 유포를 최소화하기 위해, 기본적으로 내부 기준에 따라, 지불 프로세서에 의해 사용된 카드 번호 또는 은행 계좌 번호의 표현이다. 계좌 보유자를 알 필요는 없다. 보통, 토큰 또는 프록시 번호가 지불 프로세서에 의해 사용되지만, 본 발명에 따라, (바람직하지 않지만) 카드 번호 또는 은행 계좌 번호 자체가 또는 프로파일 ID 또는 패턴 ID 자체가 사용될 수 있다.

일단 거래 인증 요청에 사용되는 계좌가 등록된 것으로 확인되면 (503), 지불 프로세서의 보안 코드 데이터베이스 서버 (4) 는 또한 계좌가 로킹되었는지 (504) 따라서 거래 인증 요청들에 부적합한지를 결정한다. 계좌는 계좌 보유자에 의한 요청시 로킹될 수도 있고, 또는 시스템에 의해 검출된 사기성 액티비티의 사인들에 기초하여 영구적으로 또는 일시적으로, 자동으로 로킹될 수도 있다. 이 검출은 내부 분석 및 알고리즘들, 또는 제 3 자 사기 또는 리스크 관리 규칙 시스템, 또는 상업적으로 가용한 FICO® Falcon Platform과 같은 제 3 자 리스트 관리 서비스로 수행될 수도 있다. 계좌가 지불 프로세서의 보안 코드 데이터베이스 (4) 에서 로킹된 것으로 플래그되면, 보고 및 기록 유지를 위해 무효 거래 시도가 로그될 것이다 (510). 계좌 보유자 (5) 는 또한, 예를 들어 필요하다면 차단 문제를 정정하기 위해, 통지받을 것이다.

504에서 계좌가 로킹되는 것으로 플래그되지 않고 (505에서 결정된 바와 같이) 보안 코드가 거래 요청 501에 적절히 포함되면, 지불 프로세서의 보안 코드 데이터베이스 서버 (4) 는 서브프로세스 (600) 에서 수신된 보안 코드를 유효화하도록 진행한다 (이하의 도 7의 논의 참조). 서브프로세스 (600) 가 보안 코드가 유효하다는 지표를 506에서 리턴하면, 거래 상세들을 유효화하기 위한 서브프로세스 (1100) 가 이어진다 (도 12 참조).

본 명세서에서 505에서 "보안 코드가 제시되었나?" 결정으로 주의가 이동된다. 단계 505에서 (즉, 거래 인증 요청의 일부로서 제출된) 보안 코드가 존재하지 않아도 다른 인자들, 결국 본 발명의 보안 코드의 처리를 포함하지 않는 인증 프로세스 (509에서) 에 기초하여 거래의 상세들을 유효화하도록 프로세스는 여전히 서브프로세스 (1100) 로 바로 분기한다는 것을 주의한다. 이러한 방식으로, 본 발명에 따른 보안 코드가 특정한 거래에 대해 검토되지 않아도, 본 명세서에 개시된 바와 같은 다른 보안 기능들이 여전히 사용될 수 있다.

유효 거래 상세 서브프로세스 (1100) 가 지불 거래 요청이 유효하다고 결정하면 508, 지불 프로세서의 보안 코드 데이터베이스 서버 (4) 는 지불 프로세서의데이터베이스 서버 (6) 로 성공적으로 리턴되고, 정상적인 코스의 509에서 거래 인증 요청 승인으로 계속된다.

본 발명에 따른 유효 프로세스는 전자 지불 거래 인증 프로세스의 일부일 뿐만 아니라, 본 발명에 따른 유효 프로세스는 지불 프로세서에 의한 최종 거래 인증을 필수적으로 발생시키지 않을 수도 있다.

그러나, 유효 거래 상세 서브프로세스 (1100) 에 따라 506에서 보안 코드 유효화가 실패하거나 508에서 거래가 무효한 것으로 간주되면, 무효 거래 시도는 보고 및 기록 유지를 위해 509에 로그되고, 정정 액션이 적절히 취해질 수 있도록 계좌 보유자에게 통지된다. 계좌 보유자의 검증된 디바이스(들)로 전송된 통지는 정확한 보안 코드를 사용하여 다시 시도할 수 있도록 계좌 보유자에 의해 합법적으로 시도되는 경우 유효 보안 코드를 포함할 수 있다. 무효 시도를 계좌 보유자에게 통지하는 것은 또한, 예를 들어, 단순히 로킹 인스트럭션 (900) 으로 수신된 통지에 응답함으로써 문제의 계좌에 대한 임의의 다른 거래 시도들을 신속하고 용이하게 로킹할 가능성을 포함하여, 이 계좌의 사기성 사용을 방지할 액션을 취할 기회를 계좌 보유자 (5) 에게 제공한다. 이 통지 교환은 계좌 보유자의 프로파일 상의 유효화된 등록된 모바일 전화 번호에 대한 SMS 텍스트 메시지를 통해, 또는 계좌 보유자에 의해 소유된 디바이스 상에 설치되고 적절히 등록되고 이전에 유효화된 애플리케이션을 통해 발생할 수 있다.

지불 프로세서는 509에서 승인 프로세스를 계속하거나 511에서 거래 인증을 거절하도록 권고된 후, 프로세서 데이터베이스 서버 (6) 는 시스템에 레코딩되고 서브프로세스 (700) 에서 더 분석되도록 최종 거래 인증 결과들을 다시 전송할 수도 있다.

도 7은 도 6의 거래 인증 서브프로세스 (500) 동안 개시될 때, 보안 코드가 본 발명에 따라 유효화되는 서브프로세스 (600) 를 예시한다. 서브프로세스 (600) 는 계좌 보유자 (5) 에 의해 제출된 보안 코드가 유효한지 또는 무효한지 여부를 결정한다.

지불 프로세서의 보안 코드 데이터베이스 서버 (4) 는 거래 인증 요청 (500) 의 일부로서 계좌 보유자 (5) 에 의해 제출된, 601에서 수신된 보안 코드 유효화 요청을 수신한다. 보안 코드 (601) 는 603에서 해시된 수신된 보안 코드를 획득하기 위해, 산업적으로 용인된 SHA (Secure Hash Algorithm), 예컨대 SHA-512를 사용하여 602에서 해시된다. 보다 구체적으로, 수신된 보안 코드 (601) 는 매트릭스가 원래 생성될 때 매트릭스 내 보안 코드들을 해시하도록 사용된 해시 솔트와 매칭하는 동일한 지불 프로세서-특정 해시 솔트 (111) 를 사용하여 해시되어, 지불 프로세서에서 유지될 때 해시 솔트 (111) 가 매트릭스가 생성될 때 매트릭스 내 보안 코드들이 해시되는 해시 알고리즘을 미러링하기 위해 사용된다.

지불 계좌가 유효화될 거래와 연관된다는 것을 나타내는 계좌 별칭 (604) 을 사용하여, 보안 코드 데이터베이스 서버 (4) 는 단계 605에서 대응하는 패턴 ID를 조사한다. 패턴 ID (606) 는 단계 609에서 발견된 패턴 ID (606) 에 대응하는 해시된 값을 조사하기 위해 프로세서의 보안 코드 데이터베이스 서버 (4) 에 저장된 해시된 매트릭스의 국부적으로 저장된 버전에 대해 검색하도록 사용된다. 패턴 ID 606에 대응하는 보안 코드들의 그룹의 정확한 보안 코드는 각각의 보안 코드가 갱신되어야 할 때 (즉, 미리 결정된 보안 코드의 유효성이 만료될 때 후속하는 보안 코드로) 를 결정하는, 계좌 보유자에 의해 선택된 저장된 컷-오프 시간 608과 함께 지불 거래의 날짜 및 시간 607을 활용함으로써 결정된다. 이 조사 동작 609의 결과는 수신된 계좌 별칭 (604) 과 연관된 현재 보안 코드의 해시된 기준 버전 (610) 을 획득한다. 이 해시된 값은 단계 611에서 공지된 방식으로 제출된 해시된 보안 코드의 버전 603과 비교된다.

제출된 보안 코드와 (매트릭스에) 저장된 보안 코드가 해시되는 동안, 제출된 보안 코드와 (매트릭스에) 저장된 보안 코드 사이의 인증 비교가 이루어진다는 것을 주의해야 한다. 즉, 각각의 지불 프로세서에 의해 유지될 때, 매트릭스의 보안 코드들은 항상 해시된 (즉, 모호한) 형태로 유지된다. 더욱이, 해시는 "일방향"이다 ― 명확한 형태로 근원적인 정보를 획득하기 위해 반전될 수 없다―. 이에 따라, 보안 코드들은, 지불 프로세서의 보안 코드 데이터베이스가 해킹되거나 그렇지 않으면 침투되어도, 보안 코드들의 매트릭스의 해시된 버전만이 각각의 지불 프로세서들에 대해 국부적으로 위치되기 때문에 더 보호된다. 이러한 방식의 해시는 고객 보안 코드들에 액세스할 수도 있는 정직하지 않은 지불 프로세서 고용인들 또는 다른 "내부의 (in house)" 개인의 잠재적인 문제를 해결하는 것을 돕는다.

ACH 또는 수표 거래를 인증하기 위해, (예를 들어, 수표의) 날짜뿐만 아니라, 시간이 인증 요청에 명시될 수도 있다 (메일 지연들 또는 순차적인 프로세싱의 지연들과 같은 인자들을 고려함). 이 경우, 제출된 보안 코드는 컷오프 시간과 무관하게, 날짜 동안 유효한 매트릭스의 모든 보안 코드에 대해 유효화될 것이다. 실제 거래 승인이 수표의 준비 및 제출 후에 발생할 수도 있기 때문에, 프로세싱의 현재 날짜 이전의 1, 7, 30, 또는 아마도 90 일까지의 날짜들에 대한 보안 코드들을 조사해야 할 수도 있다.

수신된 해시된 값 (603) 및 해시된 값 (610) 이 국부적인 버전의 지불 프로세서-특정 매트릭스로부터 매칭하면 (단계 612), 프로세스는 제출된 보안 코드가 유효하다는 것을 나타낸다 (613). 그렇지 않으면, 시스템은 614에서 코드가 무효라는 것을 나타낸다.

도 8은 도 6에 언급된 서브프로세스 (700) 의 단계들 (거래 결과들을 기록하고 분석) 을 예시한다. 이 데이터는, 예를 들어, 지불 프로세서 측에서 수신되고 프로세싱되는 거래 요청과 동시에 또는 거의 동시에 수신될 수 있다. 그렇지 않으면, 이 정보는 주기적으로 생성된 보고서에, 예를 들어 하루의 끝에 축적될 수 있다.

거래 인증 서브프로세스 (500) 가 완료되면, 요청은 701에서 거래 상세들을 기록하기 위해 프로세서의 보안 코드 데이터베이스 서버 (4) 에 의해 이루어질 수도 있다.

단계 702에서, 거래가 실시간 또는 즉각적인 통지들을 필요로 하거나 그렇지 않으면 검정하는지 여부에 대한 결정이 지불 프로세서의 보안 코드 데이터베이스 서버 (4) 에서 이루어진다. 예시적인 통지는 계좌 보유자 (5) 에 대한 통지가 요구되도록, 무효 보안 코드가 거래시 제출되는지 그렇지 않으면 본 발명에 따른 프로세싱에 적합한지일 수 있다. 그 결과, 중앙 애플리케이션 서버 (3) 에 의해 노출된 API들을 호출함으로써 메시지가 중앙 애플리케이션 서버 (3) 로 포스팅된다.

중앙 애플리케이션 서버 (3) 가 703에서 거래 통지를 수신할 때, 통지가 계좌 보유자 (5) 에게로 전송되어야 하는지 여부에 대한 결정이 단계 704에서 이루어진다. 통지가 요청되면, 계좌 보유자에게 통지하기 위한 서브프로세스 (800) 가 실행된다. (이하의 도 9 참조)

거래 사기 분석 705가 또한 종래의 알고리즘들 및 다른 표준 분석들을 사용하여, 선택가능하게 이루어질 수 있다. 사기 분석은 특정한 수 또는 조건들의 세트가 만족된다면 사기를 나타내도록 설계된 내부 규칙들의 세트로 구성될 수도 있고, 또는 분석이 외부 제 3 자 사기 또는 리스크 관리 서비스 (본 명세서에서 미도시) 로 통과될 수도 있다. 선택가능하게, 근원적인 계좌를 자동으로 로킹하거나 관련된 현재 보안 코드를 무효화하는 것을 포함하여, 문제의 지불 방법을 보장하기 위한 액션이 취해질 수도 있다.

단계 704와 유사하게, 단계 706은 계좌 보유자가 사기 분석 결과들에 대해 통지 받아야 하는지 여부를 고찰하고, 그렇다면, 사기 통지 서브프로세스 (707) 가 이어진다. 서브프로세스 (707) 는 본 명세서에 상세히 설명되지 않지만, 일반적으로 (이하에 기술된) 통지 서브프로세스 (800) 가 아니라 특정한 메시지 페이로드들과 유사하다.

702에서 중간 또는 실시간 통지들에 대한 거래가 마킹되지 않는다면, 708에서 거래는 나중에 709에서, 배치 (batch) 프로세스, 등의 중앙 애플리케이션 서버 (3) 로 전송될 보고서에 포함되도록 마킹되거나 스케줄링된다. 이는 통상적으로 마지막 배치 파일이 생성된 후 수신된 새로운 상세들의 델타들을 갖는 배치 파일을 나타낸다. 이어서 중앙 애플리케이션 서버 (3) 는 지불 프로세서의 보안 코드 데이터베이스 (4) 로부터 수신된 배치 파일들을 프로세싱하고, 저장을 위해 단계 711에서 중앙 데이터베이스 (1) 로 전송한다. 수신된 거래 상세들은 미래의 리뷰, 기록 유지, 및 분석을 위해, 예를 들어, 기업 정보 수집 프로세스들 (business intelligence processes), 보고, 또는 청구를 위해 단계 712에서 기록된다.

도 9는 계좌 보유자 (5) 에게 통지들을 전송하기 위한 서브프로세스 (800) 의 단계들을 예시한다. 서브프로세스 (800) 는 예를 들어, 다른 것들 중에서 도 3, 도 4, 및 도 8을 참조하여 본 명세서에 언급된다.

통지가 계좌 보유자 (5) 에게 푸시될 때, 801에서 요청은 메시지 페이로드 (즉, 통지를 요구하는 (802) 구체적인 상세들 또는 정보) 와 함께 중앙 애플리케이션 서버 (3) 로 전송된다. 예를 들어, 보안 코드가 계좌 보유자 (5) 로의 통지에 푸시될 때, 요청 801은 보안 코드, 계좌 보유자 (5) 를 식별하는 정보, 및 가능한 정보 또는 전송될 통지의 종류의 지표를 포함한다.

중앙 애플리케이션 서버 (3) 는 803에서 (804에서) 계좌 보유자의 통지 전달 우선도들을 조사하기 위해 중앙 데이터베이스 (1) 와 통신한다. 선택된 바람직한 통지 전달 방법들 805의 리스트는, 예를 들어, 이메일 (또는 특정한 통지 저장소), SMS, 앱을 통한 푸시 통지, 페이저 메시지, 등 중 하나 이상을 포함할 수 있다.

선택가능하게, 통지 템플릿은 목표된 방식으로 통지를 포맷할 수 있도록, 806에서 중앙 애플리케이션 서버 (3) 에 의해 요청될 수 있다. 적용가능하다면, 템플릿 정보는, 가능하면 이전에 명시된 계좌 보유자 우선도에 기초하여, 807 및 808에서 중앙 데이터베이스 (1) 상의 계좌 보유자 (5) 에 대해 조사될 수 있다.

이러한 의미의, 예를 들어, 현재 보안 코드를 송신하기 위한, 통지 템플릿은 "{이름}씨, 당신의 오늘 보안 코드는 {보안-코드}입니다"일 수 있다. 통지의 가변 콘텐트 (예컨대 나타낸 바와 같이, 계좌 보유자의 이름) 는 예를 들어, 상기 논의된 통지 상세들 802로부터 풀링될 수 있고 단계 809에서 필요에 따라 템플릿 내로 치환된다. 치환 단계 809는 "Maddy씨, 당신의 오늘 보안 코드는 364입니다"와 같은 실제 메시지 콘텐트 810을 생성하고, 이는 예를 들어 목표된 통신 방법(들) (이메일 813, SMS 815, 또는 앱 푸시 통지 817) 을 통해 단계 811에서 계좌 보유자 (5) 에게 전송된다. 템플릿을 포함하는 통지들은 몇몇 언어들 중 하나일 수도 있고, (예를 들어, 영어 외의) 다른 문자 세트들의 사용이 고려된다.

도 10은 본 발명에 따라 등록된 지불 계좌들을 선택적으로 로킹하거나 언로킹하는 서브프로세스 (900) 를 예시한다. 이러한 맥락에서 "로킹된" 또는 "언로킹된"의 언급은 본 발명에 따라 사용될 계좌의 현재 능력 (또는 무능) 을 제어하는 것을 뜻하는 것을 의미한다.

서브프로세스 (900) 는 계좌 보유자 (5) 로 하여금 복수의 협회들에 의해 발행되고 단일 애플리케이션 또는 서비스와 인터페이싱함으로써 복수의 지불 프로세서들 또는 수신 은행들에 의해 핸들링된 복수의 계좌들을 관리하게 한다. 일 예에서, 계좌 보유자는 계좌들의 하나 이상의 의심스러운 사기성 사용이 있는지, 또는 연관된 지불 카드 또는 수표 책이 분실되었는지, 또는 심지어 계좌(들)에 대한 미성년자 (minor) 의 액세스의 부모의 제어의 맥락에서, 자신의 하나 이상의 계좌들을 조사하기 원할 수도 있다.

계좌 보유자 (5) 가 자신의 등록된 계좌들 중 하나 이상을 로킹 (또는 언로킹) 하기로 901에서 결정하면, 계좌 보유자 (5) 는 예를 들어, 계좌 보유자의 등록 프로파일와 연관된 Profile ID (902), 문제의 계좌(들)의 ID (903), 및 선택가능하게 요청이 개시된 디바이스의 ID (예를 들어, 계좌 보유자 (5) 에 의해 사용된 스마트폰의 모바일 전화 번호) 로 구성된 요청을 전송한다. 요청은 중앙 애플리케이션 서버 (3) 로 전송되고 904에서 유효화된다. 일단 요청이 유효화되면, 계좌 보유자 프로파일은 중앙 데이터베이스 (1) 을 조사한다 (단계 905).

본 발명에 따라 계좌 ID (identification) ("계좌 ID") 는 일반적으로 계좌 보유자의 관련된 계좌 각각에 대응하는 표현을 기억하기 간단하고 쉽고, 본 발명에 따른 거래들을 위해 계좌 보유자가 자신의 프로파일 내 다양한 계좌들 간을 구별하는 것을 돕는데 사용된다. 계좌 ID는 계좌 보유자 (5) 에 의해 미리 결정된 숫자 또는 문자 숫자 단어 또는 구일 수도 있다. 예를 들어, 계좌 ID는 예를 들어, 계좌 보유자의 프로파일 내 "Visa Card 4572" 또는 "BofA 은행 계좌 1721"을 식별하기 위한 순차적인 번호, 또는 문자, 또는 문자들과 숫자들의 조합일 수 있다. 이 계좌 ID는 또한 예를 들어 카드 번호 또는 은행 계좌 번호의 일부일 수 있다. 계좌 ID는 또한 계좌 보유자의 프로파일 하의 모든 계좌들이 로킹/언로킹되는 단축 지표로서 키워드 또는 숫자, 예를 들어 "ALL"일 수 있다.

일단 계좌 보유자 프로파일이 위치되고 계좌들이 유효한 것으로 표시되면 (906에서), 문제의 계좌 각각의 로킹/언로킹된 상태를 변화/업데이트하기 위한 반복적인 프로세스가 있다 (도 10에서 "계좌 각각에 대해"로 나타낸 단계들의 그룹).

로킹/언로킹되는 계좌 각각에 대해, 중앙 애플리케이션 서버 (3) 는 계좌 보유자 (5) 에 의해 요청된 바와 같이 중앙 데이터베이스 (1) 의 계좌의 상태를 로킹 또는 언로킹 (908) 으로 변화시키기 위한 프로세스를 907에서 시작한다. 이어서 중앙 애플리케이션 서버 (3) 가 909에서 지불 프로세서 또는 다른 관련된 금융 기관을 호출하고, 중앙 데이터베이스 (1) 에서 검사 (910) 에 대응한다. 일단 관련된 지불 프로세서 911이 위치되면, 중앙 애플리케이션 서버 (3) 는 지불 프로세서의 보안 코드 데이터베이스 서버 (4) 로 하여금 계좌의 상태를 업데이트하게 하는 업데이트 요청을 전송하고 913에서 수행된다.

계좌 보유자 통지 서브프로세스 (800) 를 사용하여, 계좌 보유자 (5) 는 요청된 로킹/언로킹 동작의 결과들을 통지 받고, 계좌 보유자 (5) 는 확인 (914) 를 수신한다.

계좌(들)를 로킹하기 위한 요청들은, 특정한 조건 예컨대 고정된 시간 기간 동안 한동안 로킹과 같이, 설정된 시간 기간으로 주기적으로 로킹되거나 하루 동안 특정하게 로킹되는 것을 겪을 수 있다. 예를 들어, 계좌 보유자 (5) 는 계좌가 로킹될 것을 요청할 수도 있고, 주중 7:00 pm 내지 9:00 pm 동안, 그리고/또는 2016년 3월 29일 내지 2016년 4월 5일 동안, 모든 연관된 거래가 승인되는 것을 방지한다. 일부 경우들에서, 특정한 날짜에 이루어진 은행 검사의 경우에서와 같이, (시간 단위가 아니라) 날짜 단위 시간 기간들만을 특정하는 것이 가능할 수도 있다.

조건들은 또한 예를 들어, 특정한 판매자들, 판매자 타입들 (예를 들어, 영화관은 아님), 또는 지리적 영역들에 적용될 수 있다.

도 11은 도 10의 서브프로세스 (900) 와 다소 유사한 지불 프로세서들 및 관련된 금융 기관들로 전송된 통지들에 대한 서브프로세스 (1000) 의 단계들을 예시한다.

계좌들을 로킹 또는 언로킹하기 위한 요청들을 넘어, 계좌 보유자 (5) 는 예를 들어, 대응하는 지불 카드가 분실 또는 도난되었다는 것을 관련된 지불 프로세서들 중 하나에 통지하거나 계좌 보유자 (5) 가 해외 여행 계획을 가지고 있다는 것을 미리 알리기 (이에 따라 사기 분석들이 조정될 수 있도록) 원할 수도 있다. 또 다른 예에서, 계좌 보유자 (5) 는 예를 들어, 당좌 계좌에 대해 새로운 수표북 또는 카드가 손상되었다면 대체 지불 카드에 대한 요청을 전달하기 원할 수도 있다.

계좌 보유자 (5) 가 문제의 계좌들에 대한 Profile ID (1002) 및 하나 이상의 계좌 ID들 (1003) 과 함께 요청 또는 다른 통신을 제출할 때 (1001), 서브프로세스 (1000) 가 개시된다. 중앙 애플리케이션 서버 (3) 는 1003에서 요청 (1001) 을 프로세싱하고, (사용자 및 계좌 ID들을 사용하여) 1004에서 요청을 유효화한다. 일단 유효화되면, 계좌 보유자 프로파일은 1005에서 중앙 데이터베이스 (1) 를 조사한다.

통지 요청 (1001) 가 1006에서 유효화될 때, 프로세스는 요청된 (중앙 애플리케이션 서버 (3), 중앙 데이터베이스 (1), 및 지불 프로세서의 데이터베이스 서버 (6) 에 걸친 단계들의 그룹으로 나타낸 바와 같이, 그리고 "계좌 각각에 대해"로 라벨링됨) 상태 또는 우선도들을 업데이트하거나 스케줄링하도록 식별된 계좌 각각을 통해 반복된다. 계좌 ID는 시스템으로 하여금 계좌 보유자의 프로파일의 계좌들을 식별하게 하도록 계좌 보유자 (5) 에 의해 미리 결정된 숫자 또는 문자 숫자 단어 또는 구일 수 있다. 도 10에서 상기 논의된 바와 같은 계좌 ID를 구성하는 동일한 고려사항들이 여기에 적용된다.

식별된 계좌 각각에 대해, 중앙 애플리케이션 서버 (3) 는 단계 1007에서 계좌 보유자 (5) 에 의해 요청된 방식으로 계좌의 상태를 변화시키도록 (단계 1008) 중앙 데이터베이스 (1) 에서 프로세스를 작동시킨다 (invoke). 단계 1009에서, 중앙 애플리케이션 서버 (3) 는 문제의 계좌에 대응하는 지불 프로세서 또는 은행에 요청하고, 이는 관련된 지불 프로세서 (1011) 를 획득하기 위해 중앙 데이터베이스 (1) 에서의 조사 단계 (1010) 에 대응한다. 일단 문제의 계좌에 대한 관련된 지불 프로세서 (1011) 가 식별되면, 중앙 애플리케이션 서버 (3) 는 계좌의 상태를 업데이트하기 위해 (단계 1013 참조) 지불 프로세서의 데이터베이스 서버 (6) 로 요청 (1012) 을 전송한다.

이어서 계좌 보유자 (5) 가 (통지 서브프로세스 (800) 를 사용하여) 요청된 동작(들)의 결과(들)를 통지 받고 요청이 수행될 적절한 때에 확인 (1014) 을 수신한다.

마지막으로, 도 12는 예를 들어, 거래 인증에 관련한 서브프로세스 (500) (상기 도 6) 에서 언급된 바와 같이, 서브프로세스 (1100) (유효 거래 상세) 의 단계들을 예시한다.

서브프로세스 (500) 가 지불 프로세서의 보안 코드 데이터베이스 (4) 에서 기원될 때, 또는 거래의 상세들이 계좌 보유자의 등록 프로파일에서 이전에 확립된 임의의 적용가능한 규칙들에 대해 유효화되어야 할 때, 거래 상세들을 유효화하기 위한 이 서브프로세스 (1100) 는 지불 프로세서의 보안 코드 데이터베이스 (4) 에서 실행된다.

Profile ID 1101가 결정되면, 계좌 보유자의 등록 프로파일이 발견되고 (1102) 적용할 임의의 계좌 보유자-확립된 거래 규칙들이 있다는 결정이 이루어진다 (1103). 적용가능한 거래 규칙들이 없다면, 서브프로세스 (1100) 가 종료되고, 거래 상세들 프로세스가 "통과되었다" (즉, 완료되었다) 는 것을 나타낸다.

그렇지 않으면, 적용가능한 규칙들 (예를 들어, 거래량/제한들 (1106), 판매인 관련 상세들 (예컨대 판매자 명, 또는 임의의 적용가능한 상업적 판매자 카테고리 코드) (1107), 재발되는 거래 플래그/지표 (1108), 또는 임의의 다른 거래 관련 상세들 (1109), 예컨대 국부적인 거래 날짜 및 시간, 및 제품 또는 서비스 구매 정보) 이 실행되고 통상적으로, 거래 인증 서브프로세스 (500) 를 프로세싱하는 지불 프로세서로부터 서브프로세스에 입력될 때 수신된 거래 상세들을 사용하여, 1105에서 적용가능한 것으로 유효화된다.

다른 상세에서, 본 명세서에서 고려되는 거래 유효화 규칙들의 예들은 비제한적으로, 다음을 포함한다.

거래 계좌 제한: 계좌 보유자 (5) 는 등록된 계좌에 대한 임의의 미리 결정된 거래 시도에 대한 최대 또는 상위 제한들이 미리 규정될 수도 있다. 예를 들어, 계좌 보유자는 계좌 보유자의 등록 프로파일에 등록된 미리 결정된 신용 카드 에 대해 예를 들어, $500.00 이상의 임의의 거래 시도를 거절하기 원할 수도 있다.

판매자 또는 판매자 카테고리 제약: 계좌 보유자는 시도된다면, 특정한 판매자 또는 판매자 카테고리에 대한 거래들을 금지하는 것을 선택할 수도 있다. 반대로, 계좌 보유자는 하나 이상의 계좌들이 특정한 구체적인 판매자들, 또는 특정한 판매자 카테고리들에서만 사용될 수 있다는 것을 명시할 수 있다. 계좌 보유자는 또한 등록된 계좌가 임의의 다른 판매자 또는 판매자 카테고리에서 배타적으로 사용되고, 임의의 다른 판매자 또는 판매자 카테고리에서 시도된 임의의 거래들을 거절되는 판매자 또는 판매자 카테고리의 리스트를 명시할 수 있다. 예를 들어, 계좌 보유자는 식료품 또는 가스와 같이 특정한 아이템들, 또는 특정한 위치들 또는 판매자 카테고리들을 구매할 때만 사용되고 승인되게 선택할 수도 있고, 또는 예를 들어 술집에서 시도된 모든 구매들을 거절하는 것과 같이 특정한 판매자 카테고리들을 제한하기 원할 수도 있다.

재발되는 거래 규칙들: 계좌 보유자는 특정한 판매자들 또는 청구인들로부터 재발되는 거래들을 승인하거나 거절할지 여부를 결정할 수도 있고 또는 재발하는 거래들이 승인되어야 하는 수 및 빈도를 명시할 수도 있다. 계좌 보유자는 모든 재발하는 거래들에 대해 계좌 보유자의 등록 프로파일에 대한 거래 유효화 규칙 설정으로 명시되지 않는 한, 등록된 계좌에 대해 거절되는 것으로 선택할 수도 있다. 예를 들어, 계좌 보유자가 계좌가 특정한 전기 회사로부터의 분기별로 $1200.00 미만, 그리고 특정한 케이블 TV 제공자로부터 매월 $150.00 이하의 재발하는 거래들만을 용인하는 것으로 명시할 수도 있다. 계좌 보유자는 제거될 때까지 활성이도록, 또는 만료 날짜, 또는 승인될 할부 수를 명시하도록 설정될 수도 있다.

다른 규칙들 또는 이들의 임의의 조합이 또한 명시될 수 있다. 예를 들어, 재발하는 거래 규칙들은 판매자 카테고리 제한들, 또는 최대 거래량을 포함할 수도 있다.

거래 유효화 규칙들이 1105에서 검토된 후, 1110에서 거래가 모든 적용가능한 규칙들을 통과한다면, 프로세스는 1104에서 "통과" 결과를 리턴한다. 그렇지 않으면, "실패" 결과를 리턴하고 (1111), 부가적으로 계좌 보유자는 선택가능하게 통지 서브프로세스 (800) 를 통해 유효화 실패를 통보받을 수도 있다.

이 구현예의 변형은 또한 계좌 보유자로 하여금 거래 승인 프로세스에 능동적으로 참여하게 하기 위해, 규칙 유효화가 실패하는 경우 계좌 보유자와 실시간 통신을 수반할 수 있다. 예를 들어, 재발하는 ACH 지불이 수신되고 계좌 보유자가 특정한 지불 타입에 대한 규칙들을 설정하지 않으면, 계좌 보유자로부터 승인을 요청하거나 거절을 확인하기 위해 그리고 가능하면 특정한 수취인 또는 청구인으로부터 임의의 다른 거래 시도 시점에서 재발하는 거래 규칙들을 설정하기 위해, 계좌 보유자는 자동화된 또는 실제 에이전트 전화 호출, 또는 예를 들어, SMS 텍스트 메시지, 또는 모바일 애플리케이션 푸시 통지를 통해 통지받을 수 있다. 예를 들어 계좌 보유자로 하여금 입력된 무효한 보안 코드를 교정하게 하기 위해, 대부분의 경우 수표 또는 ACH 지불들과 같은 오프라인 거래들과 같은 오프라인 거래들의 프로세싱 동안 계좌 보유자의 다른 실시간 통신이 또한 거래 인증 요청 동안 발생할 수도 있다.

본 발명이 본 발명을 설명하고 예시할 목적을 위해 특정한 구체적인 예들을 참조하여 상기 기술되었지만, 본 발명은 이들 예들의 구체적인 상세들만을 참조하는 것으로 제한되지 않는다는 것이 이해되어야 한다. 보다 구체적으로, 당업자는 수정 및 발전들이 바람직한 실시예들에서 수행될 수 있다는 것이 용이하게 이해할 것이다.

본 발명은 전자 지불 거래들의 맥락에서 상기 기술되었지만, 개시된 개념은 보다 일반적으로 근원적인 보안 코드의 노출을 감소시키는 사용자 인증을 요구하는 센서티브 전자 네트워크들 또는 다른 전자 엔티티들에 대한 보안된 전자 액세스에 적용될 수 있다. 예를 들어, 본 발명은 세금 반환 신청시 사용자 인증을 허용하는 조세 당국을 상대하거나 환불 등을 발행하는 것과 관련하여 조세 당국과 상호작용할 때 사용자 인증을 위해 적용될 수 있다. 보다 일반적으로, 본 발명은 상기 기술된 복수의 금융 엔티티들을 사용하는 것과 동일한 방식으로, 복수의, 예를 들어, 정부 기관들 (세금, 면허, 법집행, 등) 과 상호작용하기 위해 사용자로 하여금 단일 보안 코드를 편리하게 사용하게 할 수 있다. 본 발명은 액세스될 (예를 들어 API를 통해 액세스될) 엔티티로부터 리모트로 포함되고 실행될 수 있고, 예를 들어, Profile ID, 요청자 ID (사용자가 액세스하려고 찾는 엔티티에 대응하고, 지불 프로세서 ID에 대한 전술한 기술과 유사), 요청자의 패스워드, 및 사용자에 의해 제출될 보안 코드를 수신할 것이다.

본 발명이 본 발명을 설명하고 예시할 목적을 위해 특정한 구체적인 예들을 참조하여 상기 기술되었지만, 본 발명은 이들 예들의 구체적인 상세들만을 참조하는 것으로 제한되지 않는다는 것이 이해되어야 한다. 보다 구체적으로, 당업자는 본 발명의 범위를 벗어나지 않고 수정 및 발전들이 바람직한 실시예들에서 수행될 수 있다는 것이 용이하게 이해할 것이다.

Claims (32)

1. 금융 엔티티로 하여금 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법에 있어서,
   복수의 사용자들을 각각의 고유한 보안 코드들의 세트들과 연관시키는 이전에 확립된 매트릭스를 수신하는 단계로서, 상기 보안 코드들 각각의 세트 각각은 유효 기간을 갖는, 상기 이전에 확립된 매트릭스를 수신하는 단계;
   전자 지불 거래의 프로세싱을 위한 요청을 수신하는 단계로서, 상기 요청은 인증을 위한 보안 코드를 포함하고, 상기 수신된 보안 코드는 상기 복수의 사용자들 중 일 사용자와 주장되는 것으로 (allegedly) 연관되는, 상기 요청을 수신하는 단계;
   상기 전자 지불 거래의 상기 프로세싱을 위한 요청의 시간에 대응하는 상기 유효 기간 동안 상기 복수의 사용자들 중 주장되는 일 사용자에게 대응하는 상기 금융 엔티티에 의해 보유된 상기 이전에 확립된 매트릭스 내 상기 보안 코드와 상기 수신된 보안 코드를 비교하는 단계; 및
   상기 대응하는 유효 기간 동안 상기 수신된 보안 코드와 상기 매트릭스 내 상기 대응하는 보안 코드 간의 대응 관계 또는 대응 관계의 결여에 따라 상기 거래를 승인하거나 승인하지 않는 단계를 포함하는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
2. 제 1 항에 있어서,
   상기 제한된 수명의 보안 코드는 상기 사용자에게 속하는 복수의 전자 지불 모드들에 공통되는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
3. 제 2 항에 있어서,
   상기 사용자의 지불 모드들은 당좌 계좌, 신용 카드 계좌, 자동화된 어음 교환 거래, 직불 카드 계좌, 선불 신용 카드 계좌, 기프트 카드 계좌, 및 지불을 나타내지 않는 수표 중 하나 이상을 포함하는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
4. 제 2 항에 있어서,
   상기 복수의 지불 모드들에 대응하는 복수의 금융 엔티티들은 상기 사용자에 대해 미리 결정된 보안 코드가 미리 결정된 유효 기간 내에 모든 사용자의 지불 모드들에 사용될 수 있도록 동일한 매트릭스의 보안 코드들이 각각 제공되는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
5. 제 4 항에 있어서,
   상기 복수의 금융 엔티티들 중 미리 결정된 일 엔티티에 고유한 해시 솔트 (hash salt) 를 갖는 보안 코드들의 매트릭스가 상기 금융 엔티티들 중 상기 미리 결정된 일 엔티티에 의해 수신되기 전에, 보안 코드들의 매트릭스 각각의 상기 코드들을 해시하는 단계를 포함하는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
6. 제 5 항에 있어서,
   상기 수신된 보안 코드를 상기 이전에 확립된 매트릭스 내 상기 대응하는 보안 코드를 비교하는 단계가 관련 유효 기간 동안 그리고 상기 사용자에 대한 상기 매트릭스의 상기 해시된 보안 코드와 해시된 수신된 상기 보안 코드를 비교하는 것을 포함하도록, 상기 보안 코드들의 매트릭스를 해시하도록 사용된 것과 동일한 해시 솔트를 사용하여 상기 수신된 보안 코드를 해시하는 단계를 더 포함하는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
7. 제 1 항에 있어서,
   상기 매트릭스 내 보안 코드 각각은 난수 생성기 (random number generator) 에 의해 생성되는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
8. 제 1 항에 있어서,
   상기 유효 기간은 하루 (one calendar day) 인, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
9. 제 1 항에 있어서,
   현재 유효 기간에 대한 상기 보안 코드를 상기 사용자에게 전달하는 단계를 더 포함하는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
10. 제 1 항에 있어서,
    현재 보안 코드는 선택적으로 무효화될 수도 있는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
11. 제 1 항에 있어서,
    현재 보안 코드는 유효 기간이 종료되기 전에 선택적으로 교체될 수도 있어, 여전히 계류중인 유효 기간 동안 상기 교체된 보안 코드를 포함하는 해시된 보안 코드들을 포함하는 새로운 매트릭스의 생성을 발생시키는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
12. 제 2 항에 있어서,
    하나 이상의 상기 사용자의 지불 모드들은,
    상기 사용자로부터 로킹 (lock)/언로킹 (unlock) 요청, 사용자의 아이덴티티의 증명, 및 로킹/언로킹될 지불 모드 또는 모드들을 수신하는 단계;
    새로운 로킹되거나 언로킹된 상태의 지불 모드 또는 모드들 각각과 연관된 금융 기관 및/또는 지불 프로세서에 알리는 단계; 및
    상기 사용자로 상기 로킹 또는 언로킹을 확인하는 단계
    에 의해 선택적으로 로킹 및 언로킹될 수 있는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
13. 제 1 항에 있어서,
    상기 사용자의 보안 코드의 인증에 더하여 미리 결정된 거래에 미리 규정된 거래 승인 규칙들을 적용하는 단계를 더 포함하는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
14. 제 13 항에 있어서,
    상기 거래 승인 규칙들은,
    거래량들에 대한 제한들;
    특정한 판매자들 또는 판매자 카테고리들과의 거래에 대한 규제들 (restrictions); 및
    재발하는 (recur) 거래들에 대한 규제들 중 하나 이상을 포함하는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
15. 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법에 있어서,
    각각의 고유 패턴 ID들 (identifications) 과 복수의 사용자들을 연관시키는 단계;
    패턴 ID 각각에 대한 난수 보안 코드들의 세트를 생성하는 단계로서, 세트 각각의 보안 코드 각각은 상이한 유효 기간에 대응하여 각각의 보안 코드들의 세트들과 상기 복수의 사용자들을 연관시키는 매트릭스를 획득하고, 보안 코드 각각은 각각의 유효 기간에 대응하는, 상기 패턴 ID 각각에 대한 난수 보안 코드들의 세트를 생성하는 단계;
    상기 매트릭스 내 상기 복수의 사용자들 중 적어도 하나의, 하나 이상의 지불 모드와 연관된 각각의 지불 프로세스들로 상기 매트릭스를 전달하는 단계; 및
    전자 지불 거래들의 인증에 사용하기 위해 상기 사용자들 각각에 적어도 현재 유효한 보안 코드를 전달하는 단계로서, 상기 인증은 전자 지불 거래의 시간에 대한 상기 관련된 유효 기간 동안 그리고 상기 사용자에 대한 상기 매트릭스 내 상기 보안 코드와 상기 전자 지불 거래의 일부로서 상기 사용자에 의해 제출된 보안 코드를 비교하는 것을 포함하는, 상기 보안 코드를 전달하는 단계를 포함하는, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
16. 제 15 항에 있어서,
    상기 보안 코드들의 유효 기간은 날짜, 시간, 또는 날짜와 시간으로 측정되는, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
17. 제 15 항에 있어서,
    상기 보안 코드들의 상기 유효 기간은 하루인, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
18. 제 15 항에 있어서,
    적어도 현재 유효한 보안 코드를 전달하는 단계는 상기 현재 유효한 보안 코드 및 후속하여 유효할 하나 이상의 보안 코드들을 전달하는 것을 포함하는, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
19. 제 15 항에 있어서,
    적어도 현재 유효한 보안 코드를 전달하는 단계는 사용자 요청 시 적어도 현재 유효한 보안 코드를 전달하는 단계 및 적어도 현재 유효한 보안 코드를 밀어내는 (pushing out) 단계 중 하나 이상을 포함하는, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
20. 제 15 항에 있어서,
    상기 적어도 하나의 지불 모드는 당좌 계좌, 신용 카드 계좌, 자동화된 어음 교환 거래, 직불 카드 계좌, 선불 신용 카드 계좌, 기프트 카드 계좌, 및 지불을 나타내지 않는 수표 중 하나 이상을 포함하는, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
21. 제 15 항에 있어서,
    난수 보안 코드들의 세트를 생성하는 단계는, 후속하는 유효 기간에 대한 상기 복수의 사용자들 각각에 대한 각각의 보안 코드를 생성하기 전에, 미리 결정된 유효 기간에 대한 상기 복수의 사용자들 각각에 대한 각각의 보안 코드를 생성하는 것을 포함하는, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
22. 제 15 항에 있어서,
    상기 상이한 유효 기간은 시간적으로 순차적인, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
23. 제 22 항에 있어서,
    제 1 보안 코드에 대한 유효 기간의 종점과 제 2 후속하는 보안 코드에 대한 상기 유효 기간의 시점 사이에 일시적인 중첩이 있는, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
24. 제 15 항에 있어서,
    상기 매트릭스는 상기 각각의 지불 프로세서들에 고유한 각각의 해시 솔트들을 사용하여, 상기 매트릭스를 상기 각각의 지불 프로세서들에 전달하기 전에 해시되는, 전자 지불 거래 시 사용자 인증을 위해 제한된 수명의 보안 코드들을 생성 및 분배하는 방법.
25. 단일 각각의 보안 코드를 사용하여 각각의 사용자로 하여금 복수의 전자 엔티티들과 상호작용하게 하도록 복수의 제한된 수명 및 사용자 특정 보안 코드들의 세트들을 생성하고 관리하는 방법에 있어서,
    난수 생성기를 사용하여 미리 결정된 자릿수 길이의 복수의 난수들을 생성하는 단계;
    상기 각각의 생성된 난수들을 사용하여 상기 복수의 보안 코드들의 세트 각각의 매트릭스를 채우는 (populating) 단계로서, 보안 코드들 세트 각각의 보안 코드 각각은 상기 매트릭스 내 각각의 유효 기간과 연관되고, 보안 코드들 세트 각각은 고유 식별자를 갖는, 상기 난수들로 매트릭스를 채우는 단계;
    각각의 사용자와 각각의 상기 보안 코드들의 세트를 연관시키는 단계;
    상기 복수의 전자 엔티티들과 상호작용하게 하도록 상기 보안 코드들을 사용하여 상기 복수의 전자 엔티티들 각각에 대한 상기 보안 코드들의 매트릭스의 사본을 생성하고 상기 복수의 전자 엔티티들 각각에 대응하는 상이하고 고유한 해시 솔트를 사용하여 사본 각각의 상기 보안 코드들을 수학적으로 해시하여, 복수의 고유하게 해시된 버전들의 보안 코드들의 매트릭스를 획득하는 단계;
    상기 보안 코드들의 매트릭스의 각각의 고유하게 해시된 버전들을 상기 각각의 전자 엔티티들로 전달하고, 그리고 상기 각각의 전자 엔티티들로 상기 대응하는 해시 솔트를 개별적으로 통신하는 단계; 및
    각각의 사용자와 연관된 상기 보안 코드들의 세트의 적어도 현재 유효한 보안 코드를 각각의 사용자에게 전달하는 단계를 포함하는, 복수의 제한된 수명 및 사용자 특정 보안 코드들의 세트들을 생성하고 관리하는 방법.
26. 제 25 항에 있어서,
    상기 전자 엔티티들은 은행 엔티티들, 지불 프로세서 엔티티들 및 보안 컴퓨터 네트워크들 중 하나 이상을 포함하는, 복수의 제한된 수명 및 사용자 특정 보안 코드들의 세트들을 생성하고 관리하는 방법.
27. 제 25 항에 있어서,
    상기 매트릭스 내 상기 난수들을 해시하기 위해 보안 해시 알고리즘이 사용되는, 복수의 제한된 수명 및 사용자 특정 보안 코드들의 세트들을 생성하고 관리하는 방법.
28. 제 25 항에 있어서,
    상기 보안 코드 각각의 유효 기간은 미리 선택된 24 시간인, 복수의 제한된 수명 및 사용자 특정 보안 코드들의 세트들을 생성하고 관리하는 방법.
29. 제 25 항에 있어서,
    상기 각각의 세트의 각각의 보안 코드들의 상기 유효 기간은 시간적으로 순차적인, 복수의 제한된 수명 및 사용자 특정 보안 코드들의 세트들을 생성하고 관리하는 방법.
30. 금융 엔티티로 하여금 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법에 있어서,
    각각의 고유 보안 코드들의 세트들과 복수의 사용자들을 연관시키는 이전에 확립된 매트릭스를 수신하는 단계로서, 상기 세트 각각의 보안 코드들은 유효 기간을 갖고, 보안 코드 각각은 미리 결정된 매트릭스에 고유하게 대응하는 고유 해시 솔트로 수학적으로 해시되는, 상기 이전에 확립된 매트릭스를 수신하는 단계;
    전자 지불 거래 프로세싱 요청을 수신하는 단계로서, 상기 요청은 인증을 위한 보안 코드를 포함하고, 상기 수신된 보안 코드는 상기 복수의 사용자들 중 일 사용자와 주장되는 것으로 연관되는, 상기 전자 지불 거래 프로세싱 요청을 수신하는 단계;
    상기 수신된 매트릭스와 연관된 해시 솔트와 동일한 해시 솔트를 사용하여 상기 수신된 보안 코드를 해시하는 단계;
    상기 전자 지불 거래 프로세스 요청 시간에 대응하는 상기 유효 기간 동안 상기 복수의 사용자들 중 상기 주장된 일 사용자에 대응하는 상기 금융 엔티티에 의해 보유된 상기 이전에 확립된 매트릭스 내 상기 해시된 보안 코드와 상기 해시된 수신된 보안 코드를 비교하는 단계; 및
    상기 대응하는 유효 기간 동안 상기 해시된 수신된 보안 코드와 상기 매트릭스 내 상기 대응하는 해시된 보안 코드 간의 대응 관계 결여 또는 대응 관계에 따라 상기 거래를 승인하거나 승인하지 않는 단계를 포함하는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
31. 제 30 항에 있어서,
    상기 매트릭스는 미리 결정된 자릿수 길이의 복수의 난수들을 생성하도록 난수 생성기를 사용하여 채워지는, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.
32. 제 31 항에 있어서,
    상기 난수 생성기는 진성 난수 (true random number) 생성기인, 전자 지불 거래를 인증하게 하도록 제한된 수명의 보안 코드를 사용하는 방법.

Images