KR101687702B1 - 최적결제방법 추천시스템 및 최적결제방법 추천방법 - Google Patents

Abstract

본 발명은, 사용자 자신이 보유한 지불수단을 최대한 활용하여 최소 비용으로 구매하고자 하는 상품 또는 서비스를 구매할 수 있도록 하면서, 동시에 사용자가 복수 개의 보유 지불수단에 대한 복잡한 혜택조건 및 실제 혜택여부를 고민하지 않을 수 있도록 사용자의 인지적 부담을 상당히 감소시킬 수 있는 최적결제방법 추천시스템 및 최적결제방법 추천방법에 관한 것이다. 구체적으로, 본 발명은, 사용자가 보유한 복수 개의 지불수단을 조합하여 혜택이 큰 지불수단의 조합에 대한 정보를 제공하는 최적결제방법 추천시스템으로서, 클라이언트 디바이스 내에 포함되며, 사용자로부터 구매대상정보 및 최적결제방법 추천요청에 대한 정보를 포함하는 입력신호를 수신하고, 혜택이 큰 지불수단의 조합을 결정하는 최적결제방법 추천알고리즘을 실행하기 위한 기본정보들을 저장하며, 상기 최적결제방법 추천알고리즘의 결과정보를 사용자에게 제공하는 클라이언트 애플리케이션; 및 상기 클라이언트 애플리케이션 및 대외기관과 데이터 연동하고, 상기 입력신호 및 상기 기본정보들을 기반으로 상기 최적결제방법 추천알고리즘을 실행하는 서버 시스템;을 포함하며, 상기 최적결제방법 추천알고리즘은, 상기 복수 개의 지불수단 각각에 대한 상품설계정보 및 상세 이력정보를 기반으로 하여 상기 결과정보를 결정하는 것을 특징으로 하는 최적결제방법 추천시스템을 제공할 수 있다.

Description

최적결제방법 추천시스템 및 최적결제방법 추천방법{SYSTEM FOR RECOMMENDING OPTIMAL PAYMENT OPTION AND METHOD FOR RECOMMENDING OPTIMAL PAYMENT OPTION USING THE SAME}

본 발명은 최적결제방법 추천시스템 및 최적결제방법 추천방법에 관한 것으로서, 사용자 자신이 보유한 지불수단을 최대한 활용하여 최소 비용으로 구매하고자 하는 상품 또는 서비스를 구매할 수 있도록 하면서, 동시에 사용자가 복수 개의 보유 지불수단에 대한 복잡한 혜택조건 및 실제 혜택여부를 고민하지 않을 수 있도록 사용자의 인지적 부담을 상당히 감소시킬 수 있는 최적결제방법 추천시스템 및 최적결제방법 추천방법에 관한 것이다.

현대에서 소비자들은 현금 이외에 매우 다양한 지불수단을 동시에 사용하고 있으며, 매우 다양한 지불수단들마다 상품 또는 서비스 구매시에 적용되는 할인 혜택이 다양하므로, 현대의 소비자들은 자신이 보유한 다양한 지불수단들에 포함된 혜택을 효율적으로 잘 활용할 수 있는지에 대해 많은 관심을 보이고 있다.

종래에도, 소비자가 보유한 복수 개의 지불수단 중에서 구매하고자 하는 상품 또는 서비스에 대한 할인혜택에 대한 정보를 알려주는 결제수단 추천서비스가 존재하여 왔다.

그러나, 종래기술에 따른 결제수단 추천서비스는 단순히 구매하고자 하는 상품 또는 서비스에 대해 소비자가 보유한 각 지불수단의 혜택범위에 대한 정보 만을 제공할 뿐, 실제로 각 지불수단이 구매대상에 대해 또는 가맹점에서 할인혜택의 적용이 가능한지에 대한 정보는 알려주지 않는 문제점이 존재하여 왔다.

구체적으로, 각 지불수단의 경우 혜택을 받기 위해서는 전월실적 또는 가용 혜택 잔여 횟수 등(즉, 혜택조건 또는 혜택부여조건)을 고려하여야 하는데, 종래기술에 따른 결제수단 추천서비스의 경우 각 지불수단의 혜택범위에 대한 정보만을 제공하므로, 소비자가 자신의 전월 실적이 얼마인지 그리고 가용혜택 잔여횟수가 얼마인지 일일이 별도로 검토해야하는 번거로움이 존재하여 왔고, 이로 인해 사용자의 결제수단 추천서비스에 대한 사용빈도가 급격히 감소되는 문제점이 존재하여 왔다.

따라서, 본 발명의 목적은 종래기술에 따른 문제점을 해결하는 최적결제방법 추천시스템 및 최적결제방법 추천방법을 제공하는 것이다.

구체적으로, 본 발명의 목적은 사용자가 각 지불수단의 혜택조건 또는 혜택부여조건을 별도로 검토하지 않고도 사용자 자신이 보유한 지불수단을 최대한 활용하여 최소 비용으로 구매하고자 하는 상품 또는 서비스를 구매할 수 있도록 하는 최적결제방법 추천시스템 및 최적결제방법 추천방법을 제공하는 것이다.

또한, 본 발명의 또 다른 목적은 사용자가 보유한 복수 개의 지불수단 중 하나의 지불수단만을 제공하는 것이 아니라 최저 가격으로 구매가능한 지불수단 조합에 대한 정보를 제공할 수 있는 최적결제방법 추천시스템 및 최적결제방법 추천방법을 제공하는 것이다.

또한, 본 발명의 또 다른 목적은 복잡한 최적결제방법 추천알고리즘을 고속 연산처리할 수 있도록 하는 최적결제방법 추천시스템 및 최적결제방법 추천방법을 제공하는 것이다.

본 발명의 일 실시예에 따르면, 본 발명은, 사용자가 보유한 복수 개의 지불수단을 조합하여 혜택이 큰 지불수단의 조합에 대한 정보를 제공하는 최적결제방법 추천시스템으로서, 클라이언트 디바이스 내에 포함되며, 사용자로부터 구매대상정보 및 최적결제방법 추천요청에 대한 정보를 포함하는 입력신호를 수신하고, 혜택이 큰 지불수단의 조합을 결정하는 최적결제방법 추천알고리즘을 실행하기 위한 기본정보들을 저장하며, 상기 최적결제방법 추천알고리즘의 결과정보를 사용자에게 제공하는 클라이언트 애플리케이션; 및 상기 클라이언트 애플리케이션 및 대외기관과 데이터 연동하고, 상기 입력신호 및 상기 기본정보들을 기반으로 상기 최적결제방법 추천알고리즘을 실행하는 서버 시스템;을 포함하며, 상기 최적결제방법 추천알고리즘은, 상기 복수 개의 지불수단 각각에 대한 상품설계정보 및 상세 이력정보를 기반으로 하여 상기 결과정보를 결정하는 것을 특징으로 하는 최적결제방법 추천시스템을 제공할 수 있다.

또한, 바람직하게는, 상기 클라이언트 애플리케이션은, 입력부와 출력부를 포함하는 인터페이스 모듈과, 상기 기본정보들을 저장하는 로컬 데이터베이스와, 상기 입력신호 및 상기 기본정보들을 가공 또는 처리하고 상기 입력신호 및 상기 기본정보들을 서버 시스템으로 전달하는 로컬 수행모듈을 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 입력부는 음성인식부 및 필기체인식부 중 적어도 하나 이상을 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 로컬 데이터베이스에 저장되는 기본정보들은, 사용자가 보유한 복수 개의 지불수단에 대한 정보를 나타내는 사용자 보유지불수단 정보, 상기 복수 개의 지불수단 각각에 대한 상세 이력정보, 상기 사용자 보유지불수단 정보에 대응되는 상기 상세 이력정보를 상기 로컬 수행모듈을 이용하여 통계 데이터로 가공한 이력 통계정보, 각각의 사용자 보유지불수단의 혜택범위 및 혜택조건을 포함하는 상품설계정보 및 과거 결제 방법 추천리스트 결과 및 사용자의 최종 선택에 대한 피드백 정보를 포함하는 히스토리 정보를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 로컬 수행모듈은, 상기 입력정보로부터 구매대상정보의 키워드를 추출하고, 상기 클라이언트 애플리케이션과 상기 서버 시스템 사이에서 데이터를 연동하고, 상기 클라이언트 디바이스 내에 포함되며 상기 클라이언트 애플리케이션과는 상이한 애플리케이션과 데이터 연동하도록 구성되는 것을 특징으로 한다.

또한, 바람직하게는, 상기 상이한 애플리케이션은 사용자가 보유한 복수 개의 지불수단에 대한 정보를 포함하는 전자지갑 애플리케이션인 것을 특징으로 한다.

또한, 바람직하게는, 상기 로컬 수행모듈은, 상기 인터페이스 모듈과 상기 서버 시스템 사이의 요청-응답 중개 처리기능 및 상기 서버 시스템과 연동해 상기 로컬 데이터베이스에 포함되는 기본정보들을 입력, 수정 및 삭제 처리하는 기능을 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 로컬 수행모듈은, 상기 로컬 데이터베이스에 포함되는 기본정보들을 통계 데이터로 가공처리하는 통계가공처리기능을 더 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 시스템은, 데이터 저장소인 서버 데이터베이스와, 상기 로컬 수행모듈과 데이터 연동하며 상기 최적결제 추천알고리즘을 수행하는 서버 수행모듈과, 대외기관과 데이터 연동하는 게이트웨이를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 데이터베이스는, 사용자가 보유한 복수 개의 지불수단 각각이 가지는 혜택종류에 대한 정보, 혜택범위에 대한 정보 및 혜택조건에 대한 정보를 포함하는 상품설계 메타정보와, 구매하고자 하는 상품 또는 서비스의 가맹점에서 상기 복수 개의 지불수단 각각이 혜택을 받을 수 있는지 여부에 대한 정보, 상기 복수 개의 지불수단을 복합적으로 사용가능한지 여부에 대한 정보, 복합적으로 사용하는 경우 적용순서에 대한 정보 및 상기 가맹점에서의 각 지불수단의 최대 혜택범위에 대한 정보를 포함하는 가맹점 혜택 정책 정보와, 상기 가맹점과 상기 가맹점의 업종을 매칭하여 테이블화한 업종-가맹점 테이블 정보를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 데이터베이스는, 개인별 과거 최적결제방법 추천리스트에 대한 정보 및 최종 선택안에 대한 정보를 포함하는 피드백 정보를 더 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 수행모듈은, 각 지불수단의 상세 사용이력에 대한 정보 및 적립이력에 대한 정보를 포함하는 상세 이력정보에 대한 사용자의 상세 이력정보 요청에 대해 대외기관과 연동하여 데이터를 중개하는 기능과, 상기 서버 데이터베이스 내의 상품설계 메타정보에 포함되는 사용자 보유 지불수단에 대한 정보를 상기 로컬 수행모듈로 전달하는 기능과, 상기 최적결제방법 추천알고리즘을 수행하는 기능과, 상기 최적결제방법 추천알고리즘의 결과정보를 상기 클라이언트 애플리케이션으로 전달하는 기능을 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 수행모듈은, 과거의 피드백 정보로부터 개인 선호도 또는 의사결정패턴을 학습하는 기능을 더 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 수행모듈은, 상기 인터페이스 모듈로부터 입력된 상기 입력신호 및 상기 구매대상정보로부터 추출된 키워드 및 상기 서버 데이터베이스에 저장된 정보 중 적어도 하나의 정보에 기초하여 상기 최적결제방법 추천알고리즘을 수행하기 위한 기본정보들을 생성하고, 상기 키워드에 기초하여 (업종-가맹점) 쌍(pair)에 대한 정보를 생성한 후, 상기 복수 개의 지불수단에 대해 보유지불수단별 혜택유무 및 혜택범위를 계산 및 적용하여 복수 개의 지불수단의 조합을 결정하여 제1 결과정보를 생성하고, 상기 제1 결과정보에 가맹점별 정책에 대한 정보를 계산 및 적용하여 복수 개의 지불수단의 조합을 재결정하여 제2 결과정보를 생성하도록, 상기 최적결제방법 추천알고리즘을 수행하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 수행모듈은 상기 제2 결과정보를 혜택이 큰 순서대로 리스트로 정리하여 상기 로컬 수행모듈을 통하여 상기 인터페이스 모듈에 표시되도록 하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 기본정보들은, 상기 입력신호에서 추출된 키워드에 대한 정보, 로컬 데이터베이스의 테이블화된 보유지불수단에 대한 정보, 로컬 데이터베이스의 테이블화된 이력 통계정보, 사용자의 GPS위치정보를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 수행모듈은, 상기 최적결제방법 추천알고리즘이 완료되면 상기 서버 데이터베이스에 저장된 기본정보들을 모두 삭제하는 것을 특징으로 한다.

본 발명의 다른 일 실시예에 따르면, 본 발명은, 사용자가 보유한 복수 개의 지불수단을 조합하여 혜택이 큰 지불수단의 조합에 대한 정보를 제공하는 최적결제방법 추천방법으로서, 클라이언트 디바이스의 클라이언트 애플리케이션을 통하여 사용자가 구매하고자하는 상품 또는 서비스에 대한 구매대상정보 및 최적결제방법 추천요청에 대한 정보를 포함하는 입력신호를 입력받은 후, 혜택이 큰 지불수단의 조합을 결정하는 최적결제방법 추천알고리즘을 실행하기 위한 기본정보들을 서버 시스템으로 전달하는 클라이어트 애플리케이션 처리단계; 상기 클라이언트 애플리케이션과 데이터 연동하는 서버 시스템을 통하여 상기 기본정보들에 기초하여 상기 최적결제방법 추천알고리즘을 실행하는 서버 시스템 처리단계; 및 상기 서버 시스템에서 실행된 상기 최적결제방법 추천알고리즘의 결과 정보를 클라이언트 애플리케이션으로 전달하여 상기 결과 정보를 사용자에게 제공하는 최적결제방법 추천리스트 제공단계;를 포함하며, 상기 최적결제방법 추천알고리즘은, 상기 복수 개의 지불수단 각각에 대한 상품설계정보 및 상세 이력정보를 기반으로 하여 상기 결과정보를 결정하는 것을 특징으로 하는 최적결제방법 추천방법을 제공할 수 있다.

또한, 바람직하게는, 상기 상세 이력정보는, 각 지불수단에 대한 사용자의 실제 사용이력에 대한 정보 및 누적된 포인트 또는 마일리지에 대한 정보를 포함하는 적립이력정보를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 최적결제방법 추천알고리즘은 상기 결과정보를 결정하는 기준으로서 상기 상세 이력정보를 통계 데이터로 가공한 이력 통계정보를 더 사용하고, 상기 이력 통계정보는 각 지불수단에 대한 전월 실적에 대한 정보 및 전월 할인적용 횟수에 대한 정보를 포함하고, 상기 상품설계정보는 각 지불수단의 혜택부여 조건에 대한 정보를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 클라이언트 애플리케이션 처리단계는, 인터페이스 모듈을 통하여 구매대상정보 및 최적결제방법 추천요청에 대한 정보를 포함하는 입력신호를 수신하여 상기 입력신호에서 키워드를 추출하는 입력단계; 상기 입력단계에서 입력된 입력신호 및 정보를 클라이언트 애플리케이션에 포함되는 로컬 수행모듈을 이용하여 대외기관에 상세 이력정보를 요청하는 이력정보 요청단계; 상기 이력정보 요청단계에 의해 대외기관으로부터 수신된 상기 상세 이력정보를 로컬 데이터베이스에 저장하고 상기 상세 이력정보를 가공한 이력 통계정보를 생성한 후 상기 이력 통계정보를 로컬 데이터베이스에 저장하는 데이터 저장단계; 및 상기 로컬 수행모듈을 사용하여 상기 서버 시스템의 서버 수행모듈에 최적결제방법 추천알고리즘에 대해 실행요청하는 실행 요청단계;를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 입력단계는, 상기 인터페이스 모듈에 포함되는 음성인식부 또는 필기체인식부를 통하여 실행되는 것을 특징으로 한다.

또한, 바람직하게는, 상기 인터페이스 모듈은 텍스트인식부를 더 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 시스템 처리단계는, 상기 클라이언트 애플리케이션을 통하여 입력된 정보에 기초하여 최적결제방법 추천알고리즘을 수행하기 위한 기본정보들을 상기 서버 시스템의 서버 데이터베이스에 저장하는 기본정보 저장단계; 서버 수행모듈을 이용하여, 상기 기본정보들 중에서 상기 클라이언트 애플리케이션을 통해 상기 입력신호에서 추출된 키워드에 기초하여 사용자가 구매하고자하는 상품 또는 서비스에 대해 (업종-가맹점) 쌍(pair)에 대한 정보를 생성하는 단계; 서버 수행모듈을 이용하여, 상기 상품설계정보, 사용자 보유 지불수단 정보 및 이력 통계정보를 기반으로 상기 복수 개의 지불수단에 대해 보유지불수단별 혜택유무 및 혜택범위를 계산 및 적용하여 복수 개의 지불수단의 조합을 결정하는 제1 결정단계; 서버 수행모듈을 이용하여, 상기 제1 혜택적용단계의 결과값에 가맹점별 정책에 대한 정보를 계산 및 적용하여 복수 개의 지불수단의 조합을 재결정하는 제2 결정단계; 및 서버 수행모듈을 이용하여, 상기 제2 결정단계의 결과정보를 혜택이 큰 순서대로 정리하는 리스트형성단계;를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 기본정보들은, 상기 입력신호에서 추출된 키워드에 대한 정보, 로컬 데이터베이스의 테이블화된 보유지불수단에 대한 정보, 로컬 데이터베이스의 테이블화된 이력 통계정보, 사용자의 GPS위치정보를 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 시스템 처리단계는, 상기 추천리스트 제공단계 후 사용자가 결정한 지불수단의 조합에 대한 정보를 포함하는 피드백 정보를 수신하는 피드백 단계; 및 상기 피드백 단계에서 수신된 상기 피드백 정보를 서버 데이터베이스의 개인별 과거 추천 리스트 및 최정 선택안 피드백 정보에 저장하고 상기 피드백 정보를 로컬 데이터베이스의 히스토리 정보에 저장하는 패턴학습단계;를 더 포함하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 추천리스트 제공단계는, 상기 패턴학습단계의 히스토리 정보를 추가로 반영하여 추천리스트를 사용자에게 제공하는 것을 특징으로 한다.

또한, 바람직하게는, 상기 서버 시스템 처리단계는, 상기 서버 시스템 처리단계가 완료되면 상기 서버 데이터베이스에 저장된 기본정보들을 모두 삭제하는 삭제단계;를 더 포함하는 것을 특징으로 한다.

또한, 본 발명의 또 다른 일 실시예에 따르면, 본 발명은, 전술한 최적결제방법 추천방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공할 수 있다.

전술한 과제해결수단에 의하면, 본 발명은 사용자가 각 지불수단의 혜택조건 또는 혜택부여조건을 별도로 검토하지 않고도 사용자 자신이 보유한 지불수단을 최대한 활용하여 최소 비용으로 구매하고자 하는 상품 또는 서비스를 구매할 수 있다. 이로 인해, 본 발명은 사용자의 인지적 부담을 최소화하면서 최저 가격으로 상품 또는 서비스를 구매할 수 있도록 할 수 있다.

또한, 본 발명은 사용자가 보유한 복수 개의 지불수단 중 하나의 지불수단만을 제공하는 것이 아니라 최저 가격으로 구매가능한 지불수단 조합에 대한 정보를 제공할 수 있다.

또한, 본 발명은 클라이언트 애플리케이션과 서버 시스템으로 이원화 구조로 최적결제방법 추천알고리즘을 수행함으로써, 복잡한 최적결제방법 추천알고리즘을 고속 연산처리할 수 있다.

도 1은 본 발명의 일 실시예에 따른 최적결제방법 추천시스템에 대한 개력적인 구성블록도이다.
도 2는 본 발명의 일 실시예에 따른 클라이언트 애플리케이션에 대한 개략적인 구성블록도이다.
도 3은 본 발명의 일 실시예에 따른 인터페이스 모듈에 대한 개략적인 구성블록도이다.
도 4는 본 발명의 일 실시예에 따른 인터페이스 모듈에 구비되는 UI구성의 개념적 예시도 및 플로우챠트이다.
도 5는 본 발명의 일 실시예에 따른 로컬 데이터베이스에 저장되는 데이터 테이블 사이의 관계에 대한 개략적인 블록도이다.
도 6은 본 발명의 일 실시예에 따른 로컬 데이터베이스에 저장되는 각각의 데이터 테이블과 로컬 수행모듈 사이의 관계에 대한 개략적인 블록도이다.
도 7은 본 발명의 일 실시예에 따른 최적결제방법 추천방법에 대한 개략적인 플로유챠트이다.
도 8은 본 발명의 일 실시예에 따른 서버 시스템에 대한 개략적인 구성블록도이다.
도 9는 지불수단의 상품설계 메타정보에 대한 예시적인 테이블이다.
도 10은 가맹점별 프로모션 정보에 대한 예시적인 테이블이다.
도 11은 가명점별 할인혜택 정책에 대한 예시적인 테이블이다.
도 12는 업종-가맹점 매핑 정보에 대한 예시적인 테이블이다.
도 13은 업종-가맹점 쌍을 형성하는 과정에 대한 개략적인 플로우챠트이다.
도 14는 사용자 보유 지불수단과 (업종-가맹점) 쌍에서의 혜택 적용 여부를 표시한 예시적인 테이블이다.
도 15는 (업종-가맹점) 쌍이 1:N으로 매칭되는 경우에 대한 예시적인 테이블이다.
도 16은 최적결제방법 추천알고리즘의 결과정보에 대한 예시도이다.

이하, 본 발명의 바람직한 실시예를 첨부한 도면을 참조하여 당해 분야의 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 설명하기로 한다. 첨부된 도면들에서 구성에 표기된 도면번호는 다른 도면에서도 동일한 구성을 표기할 때에 가능한 한 동일한 도면번호를 사용하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어 관련된 공지의 기능 또는 공지의 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략하기로 한다. 그리고 도면에 제시된 어떤 특징들은 설명의 용이함을 위해 확대 또는 축소 또는 단순화된 것이고, 도면 및 그 구성요소들이 반드시 적절한 비율로 도시되어 있지는 않다. 그러나 당업자라면 이러한 상세 사항들을 쉽게 이해할 것이다.

이하에서는, 본 발명의 일 실시예에 따른 최적결제방법 추천시스템 및 최적결제방법 추천방법에 대해 보다 명확하게 설명하기 위하여 주로 다양한 샘플 또는 다양한 예시를 제시하고 있으며, 이러한 샘플 또는 예시는 본 발명의 이해를 돕기 위한 것으로서 본 발명은 이에 제한되지 않음은 당연하다.

도 1은 본 발명의 일 실시예에 따른 최적결제방법 추천시스템에 대한 개력적인 구성블록도이다.

도 1에 도시된 바와 같이, 본 발명의 일 실시예에 따른 사용자맞춤 최적결제방법 추천시스템은, 클라이언트 애플리케이션을 포함하는 클라이언트 디바이스와 서버 시스템을 포함한다.

여기서, 클라이언트 애플리케이션이란, 스마트폰, 태블릿PC 등과 같이 소비자가 휴대하는 휴대용 디바이스(즉, 클라이언트 디바이스)에 설치되는 앱(또는 네이티브 앱(native app)) 또는 웹(또는 모바일 웹)을 말한다.

서버 시스템이란, 클라이언트 디바이스를 대신하여 고속 연산을 대행하거나, 대외기관과의 연동을 통해 필요한 대용량 데이터의 수집 및 저장 역할을 하는 시스템을 말한다. 여기서, 대외기관이란 금융기관 또는 서비스사업자 또는 카드회사의 서버 등을 의미한다.

도 2는 본 발명의 일 실시예에 따른 클라이언트 애플리케이션에 대한 개략적인 구성블록도이고, 도 3은 본 발명의 일 실시예에 따른 인터페이스 모듈에 대한 개략적인 구성블록도이고, 도 4는 본 발명의 일 실시예에 따른 인터페이스 모듈에 구비되는 UI구성의 개념적 예시도 및 플로우챠트이다.

도 2에 도시된 바와 같이, 클라이언트 애플리케이션은 3개의 논리적 영역으로 구성되고, 상기 3개의 논리적 영역은 인터페이스 모듈, 로컬 수행모듈 및 로컬 데이터베이스를 포함한다.

인터페이스 모듈은 사용자로부터 최적 결제를 위한 요청사항 입력을 받아들이고, 또한 최적 결제 추천 결과를 사용자에게 출력(예를 들어, 표시)하는 인터페이스 영역이다.

도 3에 도시된 바와 같이, 인터페이스 모듈은 입력부 및 출력부를 포함한다.

상기 입력부는 음성인식부 및/또는 필기체인식부 및/또는 텍스트 입력부를 포함한다. 또한, 상기 입력부는 음성 인식 기능을 위해서 음성인식 솔루션 및/또는 필기체 인식을 위해서 필기체인식 솔루션을 직접 내장(embed)할 수 있거나 또는 운영체제(OS)가 지원하는 API(Application Programming Interface)를 사용하여 이러한 음성인식 및 필기체인식 기능을 구현할 수도 있다.

이로 인해, 사용자는 입력부를 사용하여 입력 방법으로 자연어(대화) 형태의 음성을 사용할 수도 있고, 필기체 입력을 할 수도 있다.

상기 인터페이스 모듈은 사용자가 입력부를 통하여 어떤 입력 방법을 사용하든 인식된 내용으로부터 핵심 키워드를 추출하고 상기 핵심 키워드를 로컬 수행모듈로 전달한다.

이때, 상기 인터페이스 모듈은 GPS(Global Positioning System)를 활용한 위치 정보를 추출하고 상기 위치 정보를 포함하여 수행모듈로 전달한다.

인터페이스 모듈의 입력부에 대해서는 도 4에 예시적으로 도시되어 있다.

예를 들어, 사용자가 음성인식부를 통하여 "2명이서 영화 볼 건데 어디로 가는게 좋을까?"라고 입력한 경우, 상기 인터페이스 모듈은 'keywords = 영화, 2명'이라는 핵심 키워드를 추출하고, 상기 핵심 키워드를 로컬 수행모듈로 전달한다.

또한, 사용자가 필기체인식부를 통하여 "까페라떼 2잔"이라고 입력할 경우, 상기 인터페이스 모듈은 "keywords = 까페라떼, 2"라는 핵심 키워드를 추출하고 상기 핵심 키워드를 로컬 수행모듈로 전달한다.

게다가, 입력부는, 사용자가 자신이 가진 지불수단 확인 및 각 지불수단의 사용이력(예. 전월 카드사용실적, 영화할인 사용 횟수, 등) 등에 대한 단순 정보 조회성 질의에 대한 사용자의 입력신호를 수신할 수 있다.

여기서, 상기 지불수단은 현금 이외의 결제수단으로서 예를 들어 통신사 가입 고객이라면 1년 동안 정해진 금액 내에서 할인혜택을 받을 수 있는 통신사멤버쉽카드, 항공사/백화점/대형마트/프랜차이즈 등의 각종 포인트마일리지카드(예를 들어, CJ ONE 카드, 해피포인트카드, 대한항공마일리지카드 등), 신용카드, 직불카드, 체크카드, 할인쿠폰, 소셜커머스 쿠폰, 각 가맹점에서 자체적으로 추진하는 프로모션 쿠폰(예를 들어, GS25 편의점에서 실행하는 유제품 2+1 프로모션 쿠폰), 매회 이용시마다 적립되며 일정 횟수 이상 적립되면 1회 무료 이용 혜택이 주어지는 스탬프(예를 들어, 커피전문점 또는 헤어전문점 등) 등을 모두 포함한다.

출력부는 시각적 정보를 표시하는 디스플레이부, 청각적 정보를 표시하는 음향출력부 및 촉각적 정보를 제공하는 햅틱부 중 적어도 하나 이상을 포함할 수 있다.

출력부는 서버 시스템으로부터 획득된 결과를 사용자에게 출력한다. 구체적으로, 후술할 서버 시스템에서는 사용자가 최초 요청한 예상 구매건에 대해 최적 결제 방법 추천 결과를 생성하고 이렇게 생성된 최적결제방법 추천결과를 클라이언트 애플리케이션으로 전달하면, 상기 출력부는 음향출력부 및/또는 디스플레이부 등을 통하여 이러한 결과값을 표현하는 기능을 수행한다.

이를 통하여, 서버 시스템에서는 해당 사용자에 맞게 최적 결제 방법으로 예측된 최상위 몇 개의 방법을 할인혜택이 가장 큰(즉, 최종 지불금액이 가장 작은) 순서대로 리스트를 생성하여 상기 리스트를 클라이언트 애플리케이션으로 전달하게 되는데, 사용자는 화면에 표시된 결제방법 중 어느 방법을 선택할지를 최종 결정할 수 있다.

여기서 최적 결제 방법으로서의 몇 개라는 것은, 사용자가 가진 지불수단을 조합하면 다양한 경우의 수를 만들어낼 수 있고 각 경우의 수에 따라 할인받을 수 있는 혜택이 달라질 수도 있고 또는 같은 혜택의 할인을 받더라도 지불수단 조합이 여러 가지가 발생할 수 있는데, 최종적으로 계산된 할인혜택 폭이 큰 방법부터 순서대로 몇 개를 선택한다는 뜻이다. ‘몇 개’를 선택할지는 시스템에 설정된 설정값에 따라 달라질 수 있고, 또는 사용자가 직접 결과값을 개수를 설정하게 할 수도 있다.

또한, 상기 출력부는 사용자의 단순 정보질의(예를 들어, 지불수단에 대한 정보조회 등)에 대해서도 출력 기능을 수행한다.

도 5는 본 발명의 일 실시예에 따른 로컬 데이터베이스에 저장되는 데이터 테이블 사이의 관계에 대한 개략적인 블록도이고, 도 6은 본 발명의 일 실시예에 따른 로컬 데이터베이스에 저장되는 각각의 데이터 테이블과 로컬 수행모듈 사이의 관계에 대한 개략적인 블록도이고, 도 7은 본 발명의 일 실시예에 따른 최적결제방법 추천방법에 대한 개략적인 플로유챠트이다.

도 5에 도시된 바와 같이, 로컬 데이터베이스는 클라이언트 애플리케이션 내의 데이터 저장소로서, 이하의 5가지 정보를 관리하는 테이블을 생성하여 저장한다.

a. 사용자 보유 지불수단 정보

b.각 지불수단별 상세 사용 또는 적립이력(주로 신용카드/포인트카드 등의 카드류 결제수단)를 포함하는 상세 이력 정보

c.상세 이력 정보를 가공한 이력 통계정보

d.보유한 각 지불수단에 대한 상품설계 정보(주로 카드류 결제수단이 대상이 됨)

e.과거의 결제 방법 추천 리스트 결과 및 사용자의 최종 선택에 대한 정보를 포함하는 히스토리 정보

우선, 로컬 데이터베이스는 서비스 사용자가 어떤 지불수단을 보유하고 있는지에 대한 정보를 저장한다. 이는 어떤 지불수단을 현재 사용자가 보유하고 있는지를 파악하기 위함이다.

예를 들어, 사용자가 다음과 같이 8개 지불수단을 보유하고 있다면, 상기 로컬 데이터베이스는 8개의 타이틀이 테이블을 생성하여 저장한다.

[신용카드] 신한LOVE카드, NH 마이원 BC카드, KB 혜담카드

[포인트마일리지카드] CJ ONE카드, 해피포인트카드, 롯데멤버스카드, 대한항공SkyPass 카드

[소셜커머스] 티몬 피자헛 50% 할인쿠폰 (2013.1.31일까지)

또한, 상기 로컬 데이터베이스는 상세 이력 정보를 생성하여 저장한다. 상기 상세 이력 정보는 각 지불수단별 상세 사용 및/또는 각 지불수단별 적립이력(주로 카드류 결제수단)에 대한 정보를 포함한다.

대부분의 카드류 결제수단은, 현금 등가에 해당하는 할인 혜택을 받기 위해서는 각 상품의 설계정보에 포함되어 있는 최적 요구조건을 만족시켜야 하는 경우가 많다. 예를 들어, 신용카드는 ‘전월 실적 OO 원이상, 영화할인 혜택은 월2회/연12회 이내’와 같은 조건을 가질 수 있으며, 포인트마일리지카드의 경우도 ‘최소 5000점 이상 보유 시 500포인트 단위로 사용 가능’과 같은 조건을 갖는 경우가 많다.

따라서, 본 발명에 따른 로컬 데이터베이스는 실제 상세 이력 정보(즉, 예를 들어, 사용자의 실제 사용 이력 및/또는 적립이력)을 서버시스템을 통하여 대외기관으로부터 전달받아 저장하므로, 본 발명은 해당 지불수단 혜택을 실제로 적용받을 수 있는지를 판단할 수 있다.

여기서, 로컬 데이터베이스는 서버시스템을 통하여 전달받은 상세 이력 정보를 실제로 저장하여 보관하는 반면, 후술하는 바와 같이 서버시스템은 상세 이력 정보를 로컬 데이터베이스로 전달한 후에는 상기 상세 이력 정보를 삭제한다.

이는, 현재 금융 데이터 취급과 관련해서는 엄격하게 사용자 본인의 디바이스가 아닌 비(非)금융기관이 보유하는 것을 금지하기 때문이다. 따라서, 본 발명은 서버 시스템에 저장하는 것이 아니라 클라이언트 디바이스에 상세 이력 정보를 저장하도록 구성한다.

상기 상세 이력 정보는 후술할 ‘상세 이력 정보를 가공한 이력 통계정보’의 추출을 위한 기본 백데이터(back-data)가 되며, 또한 사용자가 본인의 상세 구매이력을 조회할 때를 대비해서 관리되는 테이블화된 정보이다.

전술항 상세 이력 정보에 대한 데이터는 구매 이력 또는 적립 이력에 대한 개별 데이터를 말하는 반면, 상세 이력 정보를 가공한 이력 통계정보는 예를 들어 ‘전월 실적 O원’, ‘전월 할인적용 횟수 O회’와 같이 상세 이력 정보에 대한 데이터에 기반하여 가공된 정보를 의미한다.

상기 이력 통계정보는, 각 지불수단 별로 필요로 하는 통계치가 달라질 수 있는데, 따라서 후술하는 바와 같이 '보유한 각 지불수단에 대한 상품설계 정보(주로 카드류 결제수단)’와 의존적인(dependent) 관계에 있다.

예를 들어, 사용자가 신한 LOVE 카드, NH 마이원 BC카드, KB 혜담카드 3장을 보유하고 있다고 하면, 각 신용카드의 혜택설계방식이 다르기 때문에, 이 3가지 카드에 대해 일괄적으로 동일한 통계치를 추출하는 것은 의미가 없다.

즉, 상기 이력 통계정보는 각 지불수단의 혜택설계 정보에 따라 각기 다르게 통계값을 추출해야 생성된 정보이다.

보유한 각 지불수단에 대한 상품설계 정보는 전술한 바와 같이 상기 이력 통계정보를 만들기 위해 기반이 되는 정보이며, 동시에 사용자가 본인이 보유한 지불수단에 해당하는 상품설계정보(또는 혜택설계정보)를 조회하기 위한 목적으로도 사용되는 테이블화된 정보이다.

국내에 굉장히 많은 카드류 상품(즉, 카드류 결제수단)이 존재하지만, 로컬 데이터베이스의 테이블에서 관리되는 상품설계정보는 사용자 본인이 보유한 상품에 국한해서만 저장 및 관리된다. 카드류 결제수단 외에도 앞에서 언급했듯이 소셜커머스, 스탬프 등 사용자가 보유한 지불수단이라면 이에 대한 정보는 테이블화된 상품설계정보에 대한 데이터에 저장된다.

이하에서 서버시스템에 관한 부분에서 설명하겠지만, 인터페이스 모듈을 통해 최적 결제 방법 추천 요청이 들어오면 클라이언트 애플리케이션 내 로컬 수행모듈은 상기 요청을 서버 시스템으로 전달하고, 서버 시스템에서는 해당 사용자에 맞는 맞춤형 최적 결제 방법 대안을 가장 혜택이 큰 것부터 순서대로 몇 가지(리스트를 몇 개로 구성할지는 시스템 설정 변수값에 따라)를 만들어내고 이를 최종적으로는 인터페이스 모듈의 출력부로 출력하게 되며, 이렇게 서버 시스템에서 만들어진 최종 리스트와 그 리스트 중 사용자가 최종 결정한 결제 방법을 포함하는 정보를 테이블화된 히스토리 정보에 저장하고 축적한다.

이렇게 상기 히스토리 정보를 축적하는 이유는, 과거에 행해진 결제 방법 추천에 대해 사용자가 최종적으로 어떤 걸 선택했는지에 대한 피드백정보를 분석하면, 그 사용자의 선호도라든가 또는 선택의 패턴을 알 수 있기 때문에, 좀 더 진화된 개인 맞춤형 서비스로의 발전을 위한 분석의 기반 데이터가 되기 때문이다.

상기 히스토리 정보는 후술하겠지만, 서버 시스템에도 전달되어 향후 최적 결제 방법 추천 요청이 발생할 시 개인 맞춤형 추천 결과 도출을 위한 중요한 입력값이 된다.

로컬 수행모듈(local execution module)은 클라이언트 애플리케이션과 서버 시스템 사이에서 데이터를 연동하고, 또는 클라이언트 디바이스 내의 다른 애플리케이션 또는 다른 서비스(예를 들어, 스마트월렛 등과 같은 전자지갑, 또는 통합카드 서비스)와 데이터를 연동하고, 또는 request-response 중개 역할을 수행하고, 데이터 통계 생성 처리 등을 수행한다. 즉, 상기 로컬 수행모듈은 '처리 프로세스(process)'을 모두 포함하여 수행한다.

로컬 수행모듈은 ‘데몬(deamon)’ 형태로 항시 실행중인 모(母)프로세스(process)를 포함하고, 상기 로컬 수행모듈은 각종 작업 수행이 필요한 시점에 요청(request)을 받으면 포크(fork, 즉 프로세스를 복사)하여 자식 프로세스(child process)를 생성하며, 이들 자식 프로세스가 실질적인 기능을 수행하고 자신의 임무 수행 완료시 프로세스 종료(process kill)되는 구조를 가진다.

상기 로컬 수행모듈은 하기의 5가지 기능을 수행한다. 이러한 5가지 기능은 다음과 같다.

a. 사용자로부터 단순 정보조회 질의에 대한 로컬 데이터베이스 쿼리(query) 및 응답 처리 기능,

b. 클라이언트 디바이스 내 다른 서비스 또는 다른 애플리케이션에서 정보 입력/수정/삭제/조회 요청 처리 기능,

c. 인터페이스 모듈과 서버 시스템간 요청(request)-응답(response) 중개 처리 기능,

d. 서버 시스템과 연동해 클라이언트 애플리케이션 로컬 데이터베이스로 정보 입력/수정/삭제 처리 기능, 및

e. 클라이언트 애플리케이션 로컬 데이터베이스의 통계 가공 처리 기능

상기 '사용자로부터 단순 정보조회 질의에 대한 로컬 데이터베이스 쿼리(query) 및 응답 처리 기능'은 도 2에 도시된 바와 같이 인터페이스모듈을 통해 사용자가 본인이 가진 지불수단정보, 상세 이력 정보(각 지불수단의 사용이력 또는 통계정보) 등 각종 정보를 조회하는 기능이다.

상기 로컬 수행모듈에 포함되는 데몬 프로그램은 인터페이스모듈로부터 요청(request)을 받으면 프로세스 포크(fork)를 통해 자식 프로세스(child process)를 생성하며, 상기 자식 프로세스는 로컬 데이터베이스에 포함된 정보들(도 5 참고) 중 관련된 각 테이블을 조회하여 결과를 출력부로 전달하고 종료된다.

도 4에 도시된 인터페이스모듈의 입력부는 예시적인 것이며, 화면을 세분화하여 구성할 경우 각 해당 화면에 맞는 관련 테이블만을 조회하여 응답할 것이다.

상기 '클라이언트 디바이스 내 다른 서비스에서 정보 입력/수정/삭제/조회 요청 처리 기능'은 상기 로컬 수행모듈이 클라이언트 디바이스 내에서 전자지갑과 같은 다른 서비스 또는 다른 애플리케이션과 연동하여 데이터를 받아오면(즉 전자지갑에서 사용자의 지불수단이 추가/변경/삭제될 때 본 발명의 클라이언트 애플리케이션으로 트리거(trigger) 발생시킴), 상기 로컬 수행모듈이 '사용자 보유 지불수단 정보' 테이블(도 5 참고)에 데이터 추가(insert)/변경(update)/삭제(delete)처리를 실행하도록 수행된다.

본 발명은 최적 결제 방법 추천이 핵심이며, 본 발명과 별도로 최근 전자지갑 서비스가 다양하게 생겨나고 있는데 전자지갑 서비스는 그 특성상 오프라인 지갑을 디지털화한 것으로 각종 디지털화된 지불수단을 저장하고 있으므로, 본 발명에 따른 사용자맞춤 최적결제방법 추천시스템에서는 전자지갑의 정보를 가져다 쓰는 형태를 가정하고 있으며 전자지갑의 기능을 별도로 구현하지는 않는다.

그러나, 이렇게 전자지갑의 정보를 가져다 쓰는 형태에 대한 가정은 예시적인 것으로서, 본 발명은 이에 제한되지 않는다.

물론, 상기 클라이언트 애플리케이션의 로컬 수행모듈은 자체적으로 전자지갑 기능을 포함할 수도 있다.

상기 '인터페이스 모듈과 서버 시스템간 요청(request)-응답(response) 중개 처리 기능'은 인터페이스 모듈에서 음성입력 또는 필기체입력을 통해 ‘최적 결제 방법 추천 요청’이 들어오면, 로컬 수행모듈은 사용자 요청의 키워드(도 3 참고)를 추출하고, 도 6에 도시된 바와 같이 로컬 데이터베이스 내 관련 테이블에서 데이터를 추출한 후 상기 데이터를 서버 시스템으로 전달한다. 참고로, 도 6에서 원 안의 영문 소문자는 로컬 수행모듈이 포함하는 5가지 기능들을 의미한다.

로컬 수행모듈이 서버 시스템으로 상기 데이터를 전달하는 이유는, 클라이언트 디바이스에 비해 고속 대용량 처리가 가능하기 때문이다.

최적 결제 방법을 알고리즘으로 계산하기 위해서는, 현재 로컬 데이터베이스에 저장된 데이터 외에도 사용자가 궁극에 구매를 원하는 경우를 만족시킬 수 있는 모든 경우의 수에 대해 사용자가 보유한 지불수단을 적용했을 때 혜택 폭을 계산한 다음, 그 중 최적 대안을 골라내야 하기 때문에, 로컬 데이터베이스의 정보 만으로는 본 발명의 가장 핵심인 최적결제방법 추천알고리즘을 적용하기에 부족한 것도 또 다른 이유이다.

로컬 데이터베이스에 저장되어 있는 이력 통계정보를 같이 전달하는 이유는, 사용자의 결제 이력에 기반한 개인 맞춤형 결제 방법을 추천하기 위해 반드시 필요하기 때문이다. 전술한 바와 같이, 개인 금융 정보와 관련된 것은 본 발명에서 전부 클라이언트 디바이스 내에만 저장하고 있으므로 서버 시스템으로 전달할 필요가 있고, 이하의 '서버 시스템' 부분에서 설명하겠지만 서버 시스템은 알고리즘을 계산 완료하고 나면 통계 정보는 삭제한다.

단, 통계 정보를 전달하기 전에, 도 7의 ②에서 설명할 상세 이력/적립 이력 최신 정보(즉, 최신 상세 이력정보)를 받아온다. 단, 마지막 통계 생성 작업 시점을 서버 수행모듈로 전달해, 마지막 통계 시점 이후로 사용자가 사용한 추가 이력 정보가 있는 경우에 데이터를 받아온다. 그 이유는, 통계 가공 처리는 설정된 특정 시간에 배치작업으로 생성되는데, 그렇게 되면 최적 결제 방법 추천을 요청하는 현재 시점과 마지막 통계가 배치 작업으로 생성된 시점 사이에 사용자가 결제 이력이 발생했다든가 하면 통계 정보에 반영되어 있지 않을 수가 있기 때문이다. 즉, 마지막 통계 처리 작업 시점을 저장하고 있다가, 그 이후의 데이터에 대해 후술할 '클라이언트 애플리케이션 로컬 데이터베이스의 통계 가공 처리 기능'의 전체 과정을 다시 시작하도록 트리거(trigger) 역할을 하는 것이다.

상기 로컬 수행모듈이 서버 시스템으로부터 최적 결제 방법에 대한 추천 리스트 응답을 받으면, 상기 로컬 수행모듈은 도 5 또는 도 6에 도시된 바와 같이 테이블화된 '히스토리 정보'(즉, 과거의 결제방법 추천 리스트 결과 및 본인의 최종 선택에 대한 정보)에 상기 추천리스트를 입력한다. 그리고 상기 로컬 수행모듈은 상기 추천 리스트를 인터페이스모듈의 출력부를 통해 사용자에게 출력하고, 사용자가 추천 결과 중 만족해 하는 한 가지를 선택하게 되면 ‘사용자가 최종 선택한 결제 방법’이라는 피드백 결과 또한 '히스토리 정보'에 저장한다. 이때, 사용자가 어떤 결과를 선택했는지는 서버 시스템으로도 전달되고 프로세스는 종료된다. 서버 시스템에서는 이러한 정보들을 축적하고 분석하여 좀 더 진화된 개인 맞춤형 알고리즘을 발전시켜 나갈 수 있다. 사용자가 추천 결과에 대해 특별한 피드백을 남기지 않은 상태에서 종료하면, 상기 '히스토리 정보'에는 사용자 최종 선택 추천 결제 방법이 무엇인지는 표시되지 않을 수도 있다.

상기 로컬 수행모듈이 최적 결제 방법 추천 리스트를 테이블화된 '히스토리 정보'에 저장하면, 클라이언트 디바이스가 부적절하게 종료되어 사용자가 미처 추천 결과를 제대로 확인하지 못했거나, 또는 다시 추천 결과를 확인해 보고 싶을 때, 서버 시스템과의 연동 및 서버 시스템에서의 알고리즘 작동 과정을 다시 수행할 필요없이 바로 정보를 조회하게 할 수 있다.

상기 '서버 시스템과 연동해 클라이언트 애플리케이션 로컬 데이터베이스로 정보 입력/수정/삭제 처리 기능'은 클라이언트 애플리케이션과 서버 시스템 사이에 데이터를 연동하도록 수행된다.

상기 클라이언트 애플리케이션과 서버 시스템 사이의 데이터 연동에는 다음의 2가지가 있다.

첫 번째, '사용자로부터 단순 정보조회 질의에 대한 로컬 데이터베이스 쿼리 및 응답 처리 기능'에서 사용자가 질의를 요청할 때 응답할 수 있도록 각 지불수단의 상품설계(혜택설계) 정보를 로컬 데이터베이스에 저장하는 것으로서, 서버 시스템의 서버 데이터베이스에서 상기 상품설계 정보를 받아온다. '클라이언트 디바이스 내 다른 애플리케이션 또는 다른 서비스에서 정보 입력/수정/삭제/조회 요청 처리 기능'에서 언급한 것처럼, 예를 들어 다른 애플리케이션 또는 다른 서비스인 전자지갑에서 사용자의 지불수단이 추가/변경/삭제 등의 이유로 본 발명의 클라이언트 애플리케이션으로 데이터를 연동할 때, 그에 따른 보유 지불수단의 추가/변경/삭제 과정에 맞게 '서버 시스템과 연동해 클라이언트 애플리케이션 로컬 데이터베이스로 정보 입력/수정/삭제 처리 기능' 과정을 트리거(trigger)하여 서버시스템으로 연동하여 상기 서버시스템으로부터 새로운 지불수단에 맞는 상품설계(혜택설계) 정보를 받아오거나 또는 지불수단 자체가 삭제되었다면 로컬 데이터베이스에서도 삭제하게 된다.

도 5 또는 도 6에 도시된 바와 같이 테이블화된 상품설계정보에 저장되어 있는 이러한 정보들은, 도 5에 도시된 바와 같이 '보유한 각 지불수단의 상품설계정보'를 기반으로 하여 이력 통계정보를 생성할 때 통계 테이블의 구조, 즉 필요한 컬럼을 정의하는데 참조 정보로 필요하다.

두 번째로, 상세이력/결제이력을 포함하는 상세 이력정보를 대외기관(금융기관 또는 서비스사업자)으로부터 받아오기 위해 서버 시스템의 서버 수행모듈과 연동하는 경우이다. 이러한 연동 과정은, 로컬 수행모듈의 '인터페이스 모듈과 서버 시스템간 요청-응답 중개 처리' 기능 및 후술할 '클라이언트 애플리케이션 로컬데이터베이스의 통계 가공 처리 기능'을 실행하기 필요하다.

상기 '클라이언트 애플리케이션 로컬 데이터베이스의 통계 가공 처리 기능'은 클라이언트 애플리케이션을 만들 때 설정된 배치작업 주기에 따라, 백그라운드로 실행되는 과정이다.

대외기관인 각종 금융 기관 및 서비스 기관으로부터 서버 시스템을 통해 제공되는 로컬 데이터베이스의 '상세 이력정보'에 개별 이력이 축적은 되지만, 개별 이력을 무한정 저장할 수도 없을 뿐더러 개인 맞춤형 결제 방법 추천을 할 때마다 매번 개별이력을 재처리하는 작업을 하는 것은 비효율적이므로, 혜택 적용 여부를 판단해서 결제 방법 추천 대안을 만들어내는데 필요한 가공된 정보만을 사전에 생성해 놓는 과정이 필요하며, 이러한 과정을 실행하는 것이 '클라이언트 애플리케이션 로컬데이터베이스의 통계 가공 처리 기능'이다.

이러한 '클라이언트 애플리케이션 로컬데이터베이스의 통계 가공 처리 기능'은 설정된 주기에 따라 배치(batch)작업으로 통계를 만들어내는 것 외에, 상기 '인터페이스 모듈과 서버 시스템간 요청-응답 중개 처리 기능'에서와 같이 실시간으로 요청을 처리해야 할 필요가 있을 수 있다. 이 통계 테이블은, 마지막 통계 수행 시점 정보를 같이 저장하고 있다가 다음 통계 처리가 수행될 때 이 마지막 시점 이후로 처리할 수 있도록 구성한다.

도 7에 도시된 바와 같이, 클라이언트 디바이스의 클라이언트 애플리케이션과 서버 시스템 사이의 최적 결제방법 추천 요청-응답 과정에 대한 주요 워크플로우를 살펴보면 다음과 같다.

우선, 인터페이스 모듈의 입력부를 통하여 사용자의 입력신호를 수신(예를 들어, 최적결제방법 추천요청에 대한 정보 수신 및/또는 결제할 상품 또는 서비스에 대한 정보 수신)한 후, 핵심 키워드를 추출하여 로컬 수행모듈의 데몬 프로그램으로 전달한다.

이후, 로컬 수행모듈의 데몬 프로그램은 자식 프로세스를 포크한다.

이후, 로컬 수행모듈의 자식 프로세스는 서버 시스템의 서버 수행모듈에 최신 상세 이력정보를 요청하여 대외기관으로부터 획득된 상기 최신 상세 이력정보를 서버 수행모듈로부터 수신한다.

이후, 상기 상세 이력정보를 로컬 데이터베이스의 '상세 이력정보' 테이블에 저장한다.

이후, 상기 로컬 수행모듈은 상기 상세 이력정보 테이블의 데이터를 가공하여 통계정보를 생성하고 상기 통계정보를 로컬 데이터베이스의 '통계 정보' 테이블에 저장한다.

이후, 상기 로컬 수행모듈은 서버 시스템의 서버 수행모듈에 최적결제방법 추천 요청을 실행한다.

이후, 후술할 서버 시스템의 서버 수행모듈은 최적결제방법 추천알고리즘을 실행한다.

이후, 후술할 서버 수행모듈은 상기 최적결제방법 추천알고리즘의 결과값을 로컬 수행모듈로 전달한다.

이후, 상기 로컬 수행모듈은 상기 최적결제방법 추천알고리즘의 결과값을 인터페이스 모듈의 출력부로 전달하여 사용자에게 제공한다.

이후, 상기 인터페이스 모듈의 입력부가 사용자의 최종선택에 대한 정보를 수신하면, 상기 인터페이스 모듈은 상기 최종선택에 대한 정보를 로컬 수행모듈로 전달하고, 이후 상기 로컬 수행모듈은 상기 최종선택에 대한 정보를 서버 시스템의 서버 수행모듈로 전달한다.

이후, 상기 로컬 수행모듈은 상기 최종선택에 대한 정보에 기반하여 로컬 데이터베이스의 '히스토리 정보' 테이블에 상기 최종선택에 대한 정보 및/또는 사용자의 피드백 정보를 저장한다.

이하에서는, 서버 시스템에 대하여 보다 구체적으로 기술하기로 한다.

도 8은 본 발명의 일 실시예에 따른 서버 시스템에 대한 개략적인 구성블록도이고, 도 9는 지불수단의 상품설계 메타정보에 대한 예시적인 테이블이고, 도 10은 가맹점별 프로모션 정보에 대한 예시적인 테이블이고, 도 11은 가명점별 할인혜택 정책에 대한 예시적인 테이블이고, 도 12는 업종-가맹점 매핑 정보에 대한 예시적인 테이블이고, 도 13은 업종-가맹점 쌍을 형성하는 과정에 대한 개략적인 플로우챠트이고, 도 14는 사용자 보유 지불수단과 (업종-가맹점) 쌍에서의 혜택 적용 여부를 표시한 예시적인 테이블이고, 도 15는 (업종-가맹점) 쌍이 1:N으로 매칭되는 경우에 대한 예시적인 테이블이고, 도 16은 최적결제방법 추천알고리즘의 결과정보에 대한 예시도이다.

도 8에 도시된 바와 같이, 서버 시스템은 3개의 논리적 영역으로 구성되고, 상기 3개의 논리적 영역은 서버 시스템 내의 데이터 저장소인 서버 데이터베이스, 로컬 수행모듈과 데이터 연동하는 서버 수행모듈, 및 대외기관과 데이터 연동하는 게이트웨이를 포함한다.

서버 데이터베이스는 다양한 정보를 저장하는 데이터 저장소이고, 특히 상기 서버 데이터베이스는 이하의 4가지 데이터를 저장한다.

a. 상품설계(혜택설계) 메타 정보,

b. 가맹점의 혜택 적용 정책(policy) 정보 ,

c. 업종-가맹점 매핑 테이블,

d. 개인별 과거 추천 리스트 및 최종 선택안(案) 피드백 정보

상기 '상품설계 메타 정보'는 서버 데이터베이스에 테이블화하여 저장된다.

본 발명에서는, 현금을 제외한 신용카드(체크카드, 선불카드 포함), 통신사멤버쉽카드, 포인트마일리지카드, 할인쿠폰, 소셜커머스, 프로모션, 스탬프를 포함하는 7가지 지불수단을 조합하여 최적의 할인폭을 받을 수 있는 최적 결제 방법을 시스템에서 추천하는데, 각 지불수단은 어떤 혜택을 가지고 있으며 혜택을 적용받기 위한 조건은 무엇인지에 대한 총괄적인 정보를 가리켜서 메타 정보라고 지칭한다.

특히, 다른 지불수단에 비해 신용카드(체크카드, 선불카드 포함), 통신사멤버쉽카드, 포인트마일리지카드의 카드류 (대개 플라스틱 카드로 발급) 결제수단은 상품설계(혜택설계) 메타 정보가 훨씬 복잡하다는 특징이 있다.

또한, 국내 신용카드 종류만 3,000개 정도에 육박할 정도로 관리해야 될 메타 정보의 양은 방대하다.

보통 카드류 결제수단의 경우, 신용카드라면 각 신용카드사 웹사이트에서, 통신사멤버쉽카드라면 각 통신사 홈페이지에서, 포인트마일리지카드라면 각 서비스사 웹사이트에서 확인할 수가 있는데, 이러한 웹페이지에는 사람이 인식할 수 있는 텍스트(text)로만 대개 표현이 되어 있다. 하지만, 본 발명의 서버데이터베이스에는 알고리즘을 수행할 수 있도록, 텍스트로만 되어 있는 메타 정보를 테이블화하여 저장한다.

도 9는 2가지 종류의 신용카드에 대한 메타 정보를 서버데이터베이스 테이블에 저장할 수 있는 형태로 분리해 낸 예시를 보여준다. 첫 번째는 통합포인트 형태로 주어지는 카드 상품이며, 두 번째는 각 혜택을 별도 관리하는 카드 상품이다.

도 9에 도시된 테이블은 신용카드 중심으로 상품설계 정보를 테이블화하는 개념적 예시를 보여주었지만, 다른 지불 수단에 대해서도 각각의 지불수단 특성에 맞게 유사한 과정으로 테이블화하여 관리한다.

예를 들어, 도 10에 도시된 바와 같이, 프로모션 관련 메타 정보를 테이블화한 것으로, 도 9와는 테이블 구조가 다르다.

이러한 과정을 반복하여, 최종적으로 7개 지불수단 각각에 대해 도 9 또는 도 10과 같은 메타 정보 관리 테이블이 생성되어 서버 데이터베이스에 저장된다.

이렇게 서버 데이터베이스에서 테이블화된 상품설계 메타 정보는, 로컬데이터베이스에 저장된 '보유한 각 지불수단의 상품설계정보' 테이블로 공유되는 정보이다. 클라이언트 애플리케이션에서는 상기 정보를 참조하여 개인 구매이력의 통계 정보 테이블을 생성한다.

이하에서는. '가맹점의 혜택 적용 정책(policy) 정보'에 대해 기술하기로 한다.

도 9에 도시된 상품설계 메타정보는 지불수단 관점에서 혜택이 정리된 것인 반면, 각 가맹점은 여러 지불수단을 복합적으로 사용 가능한지, 복합적으로 적용시 적용 순서는 어떻게 할지, 각 지불수단은 최대 얼마의 혜택을 가질 수 있는지 등의 자체 정책(policy)을 가지고 있다.

예를 들어 도 10에 도시된 바와 같이, GS25 편의점은, 2+1 행사 대상 유제품을 구매하는 경우, 전체 제품 3개 중 1개에 대해서는 할인 혜택을 먼저 적용하고, 여기에 통신사멤버쉽카드 15%할인을 적용하고서 최종 결제를 하는데, 만일 사용자가 POP카드 라는 선불카드를 가지고 있다면 추가로 10%할인을 받을 수 있는 프로모션 행사를 진행 중이다.

반면, 아웃백스테이크하우스는 SKTelecom 고객인 경우 T멤버쉽캐쉬백 카드를 사용하면 20% 현장할인 혜택을 받을 수 있는데, 현장할인이 가능한 다른 신용카드(예.신한2030카드)와는 중복으로 사용이 불가능하다. 반면, 청구할인카드(예.NH 마이원BC카드)와는 중복 할인 혜택 적용이 가능하다.

이러한 가맹점별 할인 혜택 정책(policy)은, 최적 결제 추천을 위해 알고리즘이 작동할 때 주요하게 참조하는 핵심 정보 중 하나가 된다.

가맹점별 혜택 적용 정책(policy) 데이터베이스는 도 11과 같은 형태로 구성될 수 있다.

도 11에 도시된 바와 같이, 가맹점별 적용 순위가 같은 경우는, 같은 적용 순위간에는 한 가지만 적용 가능하다는 의미이다.

반면, 적용순위가 여러 가지 나열되어 있더라도, 사용자가 해당되는 조건을 만족시키지 않는다면(예.POP카드를 보유하지 않은 고객이 GS25에서 결제 시) 그 때는 혜택설계 정보는 그 사용자에게는 무의미하게 된다.

이하에서는, '업종-가맹점 매핑 테이블'에 대해 기술하기로 한다.

서버데이터베이스에서는 가맹점과 이들의 업종을 매핑시켜주는 테이블을 저장한 후 이를 관리한다.

도 12는 업종-가맹점 매핑 테이블의 개념적 예시를 보여준다.

이렇게 업종-가맹점 테이블을 관리하는 이유는, 사용자가 특정 가맹점을 지시하여 그 곳에서의 결제에 대한 최적 결제 방법 추천을 요청할 수도 있지만, 반면 업종(예.커피, 영화) 중심으로 구매를 하고자 할 수도 있기 때문이다.

또한, 카드류 결제수단의 상품설계(혜택설계) 정보를 검토할 경우, 외식/커피전문점 형태로 할인 혜택이 주어지기도 하는 반면, CGV/스타벅스와 같이 특정 가맹점을 지정해 혜택이 주어지기도 한다.

결국, 업종-가맹점 매핑 테이블은 최적 결제 방법 추천을 위한 중요한 기본 정보이다.

이하에서는, '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보'에 대해 기술하기로 한다.

서버 수행모듈이 최종적으로 최적결제방법 추천알고리즘을 수행하고 나면, 해당 사용자에 맞는 최적 결제 방법 추천 리스트를 생성하게 되고, 이 결과를 서버 데이터베이스에 저장한다.

그리고, 전술한 바와 같이, 클라이언트 애플리케이션으로 이 결과를 전달하고 그 중 사용자가 만족스럽다고 최종 선택한 방법에 대한 피드백이 또한 서버 데이터베이스로 전달된다. 이러한 정보를 저장하는 이유는, 정보가 축적되면 개인의 선호도 또는 의사결정 패턴을 알아낼 수 있고, 좀 더 정확한 개인 맞춤형 추천 정보를 생성해내는데 중요한 입력 변수가 되기 때문이다.

게이트웨이는, 서버 시스템과 대외기관 또는 외부 개인사용자 또는 가맹점 간의 데이터 연동을 중개하는 역할이다.

게이트웨이는 두 개의 내부 모듈로 구성되고, 상기 두 개의 내부 모듈은 대외기관 시스템 연동 모듈 및 외부에서 직접 정보를 입력가능한 웹페이지를 포함한다.

대외기간 시스템 연동모듈은 대외기관의 서버와 데이터를 연동하여 획득된 데이터를 서버 수행모듈 및/또는 서버 데이터베이스로 전달한다.

본 발명에서 서버 시스템이 대외기간 시스템 연동모듈을 통하여 대외기관과 연동하는 것은, 첫째 서버데이터베이스에 전술한 바와 같이 상품설계(혜택설계) 메타 정보의 테이블 구축을 위한 정보 획득 목적이며, 둘째 로컬데이터베이스의 테이블화된 상세 이력정보(각 지불수단별 상세 사용 또는 적립이력)에 해당하는 정보를 얻어오기 위한 목적이다.

상품설계(혜택설계) 테이블의 메타 정보는, 신용카드사/통신사/포인트마일리지카드 발급사와 직접 연동을 통해 획득할 수도 있고, 또는 국내 출시된 이러한 카드류 지불수단에 관한 상품을 묶어 이미 메타 정보를 취급하는 서비스를 전문으로 하는 업체가 존재하므로 이러한 전문업체들과 연동할 수도 있다.

카드류 지불수단에 관한 상품 외에도, 소셜커머스 메타사이트 업체와 연동하면 국내에 출시된 모든 소셜커머스 쿠폰에 대한 정보를 획득할 수 있다. (소셜커머스 메타사이트는, 티몬/쿠팡/그루폰 등의 소셜커머스 사이트에서 정보를 크롤링(crawling)으로 모아 원스톱으로 소셜커머스 정보를 확인할 수 있게 하는 서비스의 한 종류임)

할인쿠폰 역시 국내에 유통되는 할인쿠폰 정보만을 모아 검색서비스를 제공하는 업체가 있으며 이들과 연동하면 쉽게 할인쿠폰 관련 서버데이터베이스를 구축할 수 있다.

마찬가지로, 스탬프 서비스에 대해서도 모바일스탬프 플랫폼서비스 업체와 연동할 수 있고, 가맹점의 프로모션/행사 정보를 역시 취급하는 서비스 업체도 존재한다.

외부에서 직접 정보를 입력가능한 웹페이지는 필요 정보를 직접 입력할 수 있는 모듈이다.

외부에서 직접 정보를 입력가능한 웹페이지의 예로서, 게이트웨이에서는 중소 가맹점이 직접 자기의 프로모션/행사 정보 및 혜택 정보 등을 직접 본 발명의 서버 시스템에 등록할 수 있도록 ‘등록 페이지’를 제공한다. 이러한 중소 가맹점들의 혜택 행사도 소비자 입장에서는 중요한 정보 중 하나이지만, 시스템 대 시스템으로 연동할 능력을 갖추고 있지 못하므로, 이러한 등록 페이지를 제공하여 직접 판매자가 등록할 수 있게 하는 것은 필요한 수단이다. 이것은 중소 가맹점에게도 고객을 유인할 수 있는 마케팅 수단으로서 가치를 가진다.

이러한 웹페이지를 통해 정보를 등록하는 가맹점은, 도 12에 도시된 바와 같이 상기 가맹정의 프로파일(예를 들어, 주소, 업종 등)에 해당하는 정보도 입력하게 된다.

서버 수행모듈은, 클라이언트 애플리케이션 내의 로컬 수행모듈과 유사하게 서버 시스템 내에서 주요 작업 처리를 담당하는 모듈이다.

서버 수행모듈은 데몬(daemon) 프로그램 형태로 존재하며, 클라이언트 애플리케이션으로부터 요청이 들어올 때마다 포크(fork)하여 자식 프로세스(child process)를 생성하며, 기능 수행 완료시 종료(process kill)되는 구조이다.

서버 수행모듈이 수행하는 주요 기능은, 다음의 4가지이다.

a.사용자의 상세 사용 또는 적립 이력 요청에 대해 대외기관과 연동하여 데이터를 중개하는 기능,

b.서버데이터베이스 내의 상품설계(혜택설계) 메타 정보 중 사용자 보유 지불수단에 해당하는 정보 전달 기능,

c.최적결제방법 추천알고리즘 수행 및 클라이언트 애플리케이션으로 결과 전송 기능,

d.과거의 추천 결과에 대한 사용자 피드백으로부터 개인 선호도 또는 의사결정 패턴을 학습 기능

우선, 서버 수행모듈은 사용자의 상세 사용 또는 적립 이력 요청에 대해 대외기관과 연동하여 데이터를 중개하는 역할을 실행한다.

클라이언트 애플리케이션에서 전술한 바와 같이, 로컬 데이터베이스의 테이블화된 상세 이력정보에 입력할 지불수단의 상세 사용 또는 적립 이력 정보를 대외기관으로부터 가져와야 한다.

클라이언트 애플리케이션으로부터의 이 기능을 수행하기 위해 서버 수행모듈의 데몬으로부터 포크(fork)된 자식 프로세스(child process)는, 게이트웨이를 통해 대외기관(금융기관 또는 서비스사업자 등의 서버)과 연결되고 데이터를 수신하는 경우 다시 클라이언트 애플리케이션으로 전달하고 자식 프로세스는 종료된다.

서버 데이터베이스내에는 개인의 금융정보 관련된 어떤 것도 저장하지 않고, 단지 클라이언트 애플리케이션과 대외기관 간에 중개하는 역할만을 수행한다.

또한, 상기 서버 수행모듈은 서버데이터베이스 내의 상품설계(혜택설계) 메타 정보 중 사용자 보유 지불수단에 해당하는 정보를 로컬 수행모듈로 전달한다.

앞서 클라이언트 애플리케이션에서 전술한 바와 같이, 로컬 데이터베이스의 테이블(보유한 각 지불수단의 상품설계 정보)에 저장할 데이터, 즉 사용자가 보유한 지불수단에 해당하는 상품설계(혜택설계) 메타 정보를 서버 데이터베이스로부터 받기 위해 데이터 전송을 요청하는 경우에 상기 기능이 실행된다.

도 5에 관한 설명부분에서도 전술한 바와 같이, 클라이언트 애플리케이션에서는 자신이 보유한 지불수단에 한해 예를 들어 도 9에 도시된 것과 같은 메타 정보를 저장한 다음, 도 5에 도시된 바와 같이 이러한 메타 정보를 기준으로 통계 정보를 생성하고, 다시 통계 정보를 기반으로 도 7의 과정대로 사용자 맞춤형 최적 결제 추천을 수행할 수 있게 된다.

또한, 상기 서버 수행모듈은 최적결제방법 추천알고리즘 수행 및 클라이언트 애플리케이션으로 결과 전송 기능을 실행한다. 즉, 상기 서버 수행모듈은 최적결제방법 추천알고리즘을 실행한다.

우선, 상기 서버 수행모듈은 클라이언트 애플리케이션의 인터페이스 모듈로부터 입력된 정보에 기초하여 최적결제방법 추천알고리즘을 수행하기 위한 기본정보들을 메모리에 공간을 할당하여 저장한다.

도 7을 참고하면, 클라이언트 애플리케이션에서는 최적 결제 추천 요청을 위해 인터페이스 모듈로부터 입력된 1) 사용자 요청에서 추출한 키워드(keywords)와, 2) 로컬 데이터베이스의 테이블화된 보유지불수단에 대한 정보와, 3) 로컬 데이터베이스의 테이블화된 통계정보와, 4) 사용자의 GPS 위치정보를 로컬 수행모듈을 통하여 서버 수행모듈로 전달한다. 이때, 서버 수행모듈에서는 이러한 기본정보들을 수신하면 메모리(memory)에 공간을 할당(allocation)하고 저장한다. 왜냐하면, 이러한 기본정보들은 최적 결제 방법 추출을 위해 알고리즘을 수행하는 내내 가장 기초적인 정보이기 때문이다.

이후, 상기 서버 수행모듈은 클라이언트 애플리케이션으로부터 전달된 기본정보들 중 키워드에 기초하여 (업종-가맹점) 쌍(pair)을 생성한다.

도 13에 도시된 바와 같이, 본 발명에 따르면 최적 결제 방법 추천을 요청하는 사용자의 입력은 대체로 3가지로 구분된다. 즉, ‘무엇을 구매하려고 하는지’ 또는 ‘어디를 방문하려고 하는지’ 중 최소한 한 가지는 명시적으로 입력되어야 한다.

인터페이스 모듈의 입력부를 통해 전달되어지는 키워드를 업종-가맹점 매핑 테이블에 입력하여, 최종적으로 (업종-가맹점) 쌍을 생성한다.

예를 들어, 도 13에 도시된 바와 같이, ①('홈플러스 목동'이 입력된 경우) 및 ②('스타벅스 2잔'이 입력된 경우)의 경우는 키워드에서 가맹점을 알 수 있기 때문에 업종-가맹점 매핑 테이블로부터 ‘업종’을 알아내야 하는 반면, ③('영화표 2장'이 입력된 경우)의 경우는 업종으로 입력되었기 때문에 가맹점을 알아내야한다. 단, 이때 ③의 경우는, 전국에 존재하는 해당 업종의 모든 가맹점을 추출하는 것은 의미가 없기 때문에, 이 경우는 사용자의 GPS 위치정보에 기초하여 사용자의 현재 위치 주변으로 근처에 위치한 가맹점을 찾는 것으로 가정한다. 이런 경우를 대비해 서버 시스템에는 이미 ‘주변’이라는 상황을 인식하도록 ‘반경’이라는 조건을 설정값으로 가지고 있고, 이것을 적용하여 사용자 현재 위치 대비 업종-가맹점 매핑 테이블의 주소를 이용해 반경 내에 들어오는 해당 업종의 가맹점을 모두 추출한다. 단, 이 때 서버 시스템에서는 업종 별로 반경을 다르게 설정할 수도 있다. 그 이유는, 가맹점 분포 밀도가 높은 업종(커피, 편의점 등)도 있는 반면 그렇지 않은 업종도 있기 때문이다. 단, 특이한 점은, ③의 경우는 (업종:가맹점)=(1:n)의 관계가 성립된다는 점이다.(즉, 복수개 추출이 가능)

도 13의 ③에서 (업종:가맹점) 쌍이 추출되지 않는 경우는, 최적 결제 추천의 대상이 없으므로 고객에게는 최적 결제 방법 추천이 불가하다는 내용의 응답을 인터페이스모듈의 출력부를 통해 보내고, 서버 수행모듈의 프로세스는 종료한다.

이후, 상기 서버 수행모듈은 기본정보들에 기초하여 보유지불수단별 혜택유무 및 혜택범위를 계산한다. 여기서, 사용되는 기본정보들은 '사용자 보유 지불수단 정보' 및 '상세 이력정보를 가공한 이력 통계정보'이다.

구체적으로, 기본정보들을 메모리에 공간을 할당하여 저장하는 단계 및 (업종-가맹점) 쌍(pair)을 생성하는 단계까지의 과정을 통해, (업종:가맹점) 쌍이 만들어지고 나면, 기본정보들을 메모리에 공간을 할당하여 저장하는 단계에서 클라이언트 애플리케이션으로부터 넘겨받은 보유 지불수단과 현재까지 구매/적립 이력 통계를 활용해, 각 지불수단에 대해 이 (업종:가맹점)에서 적용이 가능한지, 가능하다면 얼마만큼 혜택이 주어지는지를 보유 지불수단별로 일단 각각 계산한다. 이때 서버 데이트베이스에 저장된‘상품설계(혜택설계) 메타 정보’에서 언급한 메타 정보 테이블들을 활용한다.

상기 (업종-가맹점) 쌍(pair)을 생성하는 단계에서 (업종:가맹점) 쌍을 구한 이유는, 가령 A 라는 신용카드 상품이 특정 가맹점 또는 프랜차이즈에 대해 혜택이 설계되기도 하지만 업종에 대해 혜택이 설계되기도 하기 때문에, 사용자가 보유한 지불수단이 어떤 조건에 해당될지 알 수 없기 때문이다.

예를 들어, 도 14에 도시된 바와 같이, 사용자A는 도 13에 도시된 ①의 경우에 해당되되 신용카드 3장(X1, X2, X3), 통신사멤버쉽카드 1장(X4), 포인트마일리지카드 4장(X5, X6, X7, X8)을 가지고 있는 사용자라 가정한다. 반면, 사용자B는 신용카드 2장(Y1, Y2), 통신사멤버쉽카드 1장(Y3), 포인트마일리지카드 2장(Y4, Y5), 소셜커머스쿠폰 1장(Y6), 할인쿠폰 1장(Y7)을 가지고 있다고 가정한다. 그리고 각 사용자의 (업종:가맹점) 쌍에서 적용 가능여부와 혜택 폭이 도 14에 예시적으로 표시되어 있다. 혜택 폭은 도 9에 도시된 상품설계(혜택설계) 메타 정보 테이블에 이미 저장되어 있다.

단, 도 10에 도시된 바와 같은 가맹점 자체 프로모션은 사용자가 특정 지불수단을 보유하지 않더라도 혜택을 받을 수 있는 것이기 때문에, 따라서 지불수단 보유와 별개로 가맹점에 해당 여부가 있다면 표시한다.

다른 방법으로, 도 15는 상기 보유지불수단별 혜택유무 및 혜택범위를 계산하는 단계를 동일하게 진행하되, 도 13에 도시된 ③에 해당되는 사용자C에 대해 보유지불수단별 혜택유무 및 혜택범위를 계산하는 단계를 진행한 결과를 보여준다. 즉, 도 14의 예시와 도 15의 예시가 다른 점은, (업종:가맹점)=(1:n)이기 때문에, 추출된 가맹점 리스트에 대해 모두 적용 여부를 체크한다는 점이다.

이후, 상기 서버 수행모듈은 상기 보유지불수단별 혜택유무 및 혜택범위를 계산하는 단계의 결과에 대해 가맹점별 정책(policy) 테이블(도 11 참고)에 기초하여 가맹점별 정책을 적용한다.

즉, 상기 서버 수행모듈은 할인 혜택이 여러 개 적용 가능해 보이더라도 중복이 불가능하지는 않은지, 또는 할인 적용시 순서가 있지는 않은지 등을 정책(policy) 테이블을 참조하여 최종 할인 혜택을 적용받는 결제 방법과 그 때의 최종 할인 폭을 계산하게 된다.

예를 들어, 도 14에 예시적으로 도시된 사용자B에 대해 해당 가맹점이 도 16에 예시적으로 도시된 것과 같은 가맹점별 정책(policy)을 가지고 있고, 따라서 상기 서버 수행모듈은 사용자B가 이 예시의 가맹점에서 본인의 보유 지불수단을 활용해 지불할 수 있는 경우의 수를 생성할 수 있다.

이후, 상기 서버 수행모듈은 가맹점별 정책(policy) 테이블에 기초하여 가맹점별 정책을 적용하는 단계의 결과값을 혜택폭이 큰 순서대로 재정리하여 재정리된 결과값을 클라이언트 애플리케이션로 전달한다.

구체적으로, 가맹점별 정책(policy) 테이블에 기초하여 가맹점별 정책을 적용하는 단계의 결과값을 혜택폭이 큰 순서대로 재정리(sorting)하고, 그 결과를 클라이언트 애플리케이션의 로컬 수행모듈을 거쳐 인터페이스 모듈의 출력부를 통해 사용자에게 최종적으로 제공한다.

이때, 보유한 지불수단의 경우의 수와, 가맹점의 정책에 따라서는, 도 16의 예시보다 매우 다양한 경우의 수가 발생할 수 있고, 이 경우 전술한 바와 같이 서버 시스템 내 설정값에 따라 혜택 폭이 가장 큰 상위 몇 개 만을 선택적으로 사용자에게 출력할 수도 있다.

이후, 서버 수행모듈은 상기 서버 수행모듈은 가맹점별 정책(policy) 테이블에 기초하여 가맹점별 정책을 적용하는 단계의 결과값에 대해 서버 데이터베이스에 저장된 '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보'를 적용한다. 이후, 상기 서버 수행모듈은 사용자에게 최종 전달할 최적 결제 방법 추천 리스트를 생성하고 상기 최적결제방법 추천리스트를 '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보' 테이블에 저장한다.

이를 통하여, 과거의 추천 결제 방법과 실제로 사용자가 최종 선택한 결과를 비교하여, 사용자가 할인 혜택 여부에 상관없이 특정 신용카드로만 집중적으로 사용하는지 아니면 항상 할인 혜택 폭이 제일 큰 추천 결제 방법을 선택하는지 여부를 알 수 있다.

따라서, 사용자의 최종 선호도 또는 의사결정 패턴을 감안하여야 사용자 맞춤의 최적 안을 생성할 수 있으므로, 본 단계를 적용했을 때 본 단계의 결과값(또는 결과 리스트)의 순서를 재조정해야 할 필요가 있을 경우(사용자에게 제일 임팩트가 크게 와닿을 결제 방법을 가장 상위로 배열), 이를 수행하여 사용자에게 내보낼 최종 최적 결제 방법 추천 리스트를 생성한다.

이후, 상기 서버 수행모듈은 최적결제방법 추천리스트에 대한 사용자의 피드백 정보를 전달받은 후 상기 피드백 정보를 '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보' 테이블에 저장한다.

즉, 사용자가 추천된 최종결제방법 추천리스트 중 최종 결정한 방법에 대해 일종의 ‘좋아요(Like)’ 또는 '확인(Confirm)' 과 같은 피드백 정보를 입력하면, 상기 피드백 정보는 로컬 수행모듈을 통하여 다시 서버 수행모듈로 전달되고 서버 데이터베이스의 '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보' 테이블에 저장된다.

이후, 서버 수행모듈은 프로세스를 종료된다.

이후, 상기 서버 수행모듈은 상기 기본정보들을 메모리에 공간을 할당하여 저장하는 단계에서 저장된 '기본정보들'을 모두 삭제한다.

즉, 상기 서버 수행모듈은 상기 기본정보들을 메모리에 공간을 할당하여 저장하는 단계에서 클라이언트 애플리케이션으로부터 전달받아 서버 시스템 메모리 공간에 임시 저장했던 사용자 정보 등을 모두 삭제한다.

이로써, 최적결제방법 추천알고리즘이 종료된다.

상기 서버 수행모듈의 마지막 기능으로서, 상기 서버 수행모듈은 과거의 추천 결과에 대한 사용자 피드백으로부터 개인 선호도 또는 의사결정 패턴을 학습하는 기능을 수행한다.

상기 최적결제방법 추천알고리즘에서 상기 서버 데이터베이스에 저장된 '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보'를 적용하는 단계에서 기술된 사용자 맞춤형 최적 결제 방법 우선순위 결정을 위해, 최적 결제 추천이 발생할 때마다 그 리스트를 서버데이터베이스에 저장하고, 또한 인터페이스 모듈의 출력부에 대한 설명 및 로컬 수행모듈의 '사용자 인터페이스와 서버 시스템간 요청-응답 중개 처리 기능'에 대한 설명에서 기술한 바와 같이 사용자가 그 추천된 리스트 중 최종 선택하는 경우 그 피드백 정보를 받아 저장한다.

예를 들어, 상기 서버 데이터베이스에 저장된 '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보'를 적용하는 단계에서 전술한 바와 같이, 어떤 사용자는 혜택 폭보다는 특정 카드를 집중적으로 사용할 수도 있으며(아마 카드 포인트 적립이 제1순위의 관심사인 경우일 수 있음), 또 어떤 사용자는 할인 혜택 폭에 가장 관심이 많을 수 있다.

따라서, 상기 서버 수행모듈은 이러한 고객 행동 및 의사결정 패턴을 정형화하여 서버 시스템 상에 룰(rule)로 정의하고 주기적으로 배치작업을 수행하여, 고객의 행동 및 의사결정의 특징을 추출한다.

예를 들어, 상기 룰은 다음과 같은 형태로 구성될 수 있는데, 최대 할인 폭의 역순으로 우선순위를 두고 초기에는 최적 결제 방법 추천 결과를 만들어 내는데, 이때 사용자의 피드백이 매번 추천된 제1순위, 즉 할인폭이 제일 큰 대안을 선택한다고 하면, 해당 사용자는 할인폭에 관심이 큰 사용자로 정의할 수 있게 된다. 또는 할인 폭 보다는 특정 카드 사용에 집중하는지, 또는 전월 주로 사용한 신용카드에 종속되어(correlated) 주로 사용하는 지 등, 몇 가지 고객 행동 패턴을 정의할 수 있다.

따라서, 상기 서버 수행모듈은 서버 데이터베이스에 저장된 '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보'에 대한 데이터에 대해 주기적으로 학습 과정을 반복적으로 실행하고, 고객 행동 패턴을 만들어 낸다.

서버 데이터베이스에서 테이블화된 '개인별 과거 추천 리스트 및 최종 선택안 피드백 정보'는 기본적으로 본 발명의 서비스를 사용하는 고객 리스트를 기반으로 각 고객의 선호도 패턴을 매칭시키는 형태이다.

전술한 과제해결수단에 의하면, 본 발명은 사용자가 각 지불수단의 혜택조건 또는 혜택부여조건을 별도로 검토하지 않고도 사용자 자신이 보유한 지불수단을 최대한 활용하여 최소 비용으로 구매하고자 하는 상품 또는 서비스를 구매할 수 있다. 이로 인해, 본 발명은 사용자의 인지적 부담을 최소화하면서 최저 가격으로 상품 또는 서비스를 구매할 수 있도록 할 수 있다.

또한, 본 발명은 사용자가 보유한 복수 개의 지불수단 중 하나의 지불수단만을 제공하는 것이 아니라 최저 가격으로 구매가능한 지불수단 조합에 대한 정보를 제공할 수 있다.

또한, 본 발명은 클라이언트 애플리케이션과 서버 시스템으로 이원화 구조로 최적결제방법 추천알고리즘을 수행함으로써, 복잡한 최적결제방법 추천알고리즘을 고속 연산처리할 수 있다.

이상에서 본 발명의 기술적 사상을 예시하기 위해 구체적인 실시 예로 도시하고 설명하였으나, 본 발명은 상기와 같이 구체적인 실시 예와 동일한 구성 및 작용에만 국한되지 않고, 여러가지 변형이 본 발명의 범위를 벗어나지 않는 한도 내에서 실시될 수 있다. 따라서, 그와 같은 변형도 본 발명의 범위에 속하는 것으로 간주해야 하며, 본 발명의 범위는 후술하는 특허청구범위에 의해 결정되어야 한다.

Claims (17)

1. 사용자가 보유한 복수 개의 지불수단을 조합하여 혜택이 큰 지불수단의 조합에 대한 정보를 제공하는 서버 시스템으로서,
   상기 사용자의 입력신호로부터 추출된 키워드에 따라 상기 사용자가 구매하고자 하는 상품 또는 서비스에 대한 업종-가맹점 쌍을 생성하고, 상기 업종-가맹점 쌍에 대해 사용 가능한 보유 지불 수단의 조합들을 혜택폭이 큰 순서대로 정렬한 결제방법 추천리스트를 생성하는 서버 수행 모듈; 및
   상기 키워드, 상기 업종-가맹점 쌍을 생성하기 위해 업종과 가맹점을 매칭한 업종-가맹점 매핑 테이블, 및 상기 결제방법 추천리스트를 저장하는 서버 데이터베이스를 포함하며,
   상기 키워드에 가맹점이 포함되지 않은 경우, 상기 서버 수행 모듈은 상기 사용자의 위치 정보 및 상기 키워드에 포함된 업종에 따라 결정되는 적어도 하나의 가맹점을 기초로 상기 결제방법 추천리스트를 생성하고,
   상기 서버 시스템은, 대외 기관과 연동하여 상기 보유 지불 수단에 포함된, 소셜커머스 메타사이트에 의해 복수의 소셜커머스 사이트들로부터 크롤링(crawling)으로 수집되는 소셜커머스 쿠폰, 국내에 유통되는 할인 쿠폰 및 가맹점별 프로모션에 대한 정보를 획득하는 서버 시스템.
2. 제1항에 있어서,
   상기 서버 수행 모듈은,
   상기 사용자의 보유 지불 수단, 상기 보유 지불 수단의 혜택 종류와 혜택 범위에 대한 정보인 상품 설계 메타 정보, 및 상기 사용자의 구매 및 적립에 대한 상세 이력정보를 가공한 이력 통계 정보를 기초로 상기 업종-가맹점 쌍에 대한 상기 보유 지불 수단 별 혜택 여부와 혜택 폭을 계산하고,
   상기 보유 지불 수단 별 혜택 여부와 혜택 폭, 및 상기 업종-가맹점 쌍에 대한 가맹점별 정책 테이블을 이용해, 상기 조합들 및 상기 조합들에 대응하는 혜택폭들을 생성하고,
   상기 조합들 및 상기 조합들에 대응하는 혜택폭들을 혜택폭이 큰 순서대로 정렬하여 상기 결제방법 추천리스트를 생성하는 서버 시스템.
3. 제2항에 있어서,
   상기 보유 지불 수단은, 신용카드, 통신사 멤버쉽카드, 포인트 마일리지 카드, 상기 할인 쿠폰, 상기 소셜커머스 쿠폰, 상기 가맹점별 프로모션, 오프라인 가맹점의 스탬프 중 적어도 하나를 포함하는 서버 시스템.
4. 제1항에 있어서,
   상기 키워드에 상기 가맹점이 포함된 경우, 상기 서버 수행 모듈은 상기 업종-가맹점 매핑 테이블을 이용해 상기 가맹점에 대응하는 하나의 업종을 선택하여 하나의 업종-가맹점 쌍을 생성하는 서버 시스템.
5. 제1항에 있어서,
   상기 키워드에 상기 가맹점이 포함되지 않은 경우, 상기 서버 수행 모듈은 상기 위치 정보에 기초하여 상기 사용자의 주변을 결정하고, 상기 업종-가맹점 매핑 테이블을 이용해 상기 주변 내에 위치한 n(n은 1이상의 정수) 개의 가맹점을 선택하여 상기 업종에 대응하는 상기 n 개의 업종-가맹점 쌍을 생성하는 서버 시스템.
6. 제5항에 있어서,
   상기 주변은 상기 업종에 따라 정해지는 반경에 의해 결정되는 서버 시스템.
7. 제1항에 있어서,
   상기 서버 데이터베이스는, 상기 결제방법 추천리스트에서 사용자가 선택한 결제 방법에 대한 피드백 정보를 더 저장하는 서버 시스템.
8. 제7항에 있어서,
   상기 서버 데이터베이스는, 상기 피드백 정보를 저장한 뒤 상기 서버 수행 모듈의 제어에 따라 상기 피드백 정보를 제외한 상기 사용자의 정보를 삭제하는 서버 시스템.
9. 제1항에 있어서,
   상기 서버 시스템은 대외기관, 외부 개인 사용자 또는 가맹점 간의 데이터 연동을 중개하는 게이트웨이를 더 포함하는 서버 시스템.
10. 사용자가 보유한 복수 개의 지불 수단들을 조합하여 혜택이 큰 지불 수단의 조합에 대한 정보를 제공하는 서버 시스템의 결제방법 추천방법으로서,
    상기 서버 시스템이, 상기 사용자의 입력신호로부터 추출된 키워드에 따라 상기 사용자가 구매하고자 하는 상품 또는 서비스에 대한 업종-가맹점 쌍을 생성하는 단계;
    상기 서버 시스템이, 상기 업종-가맹점 쌍에 대해 사용 가능한 보유 지불 수단의 조합들을 혜택폭이 큰 순서대로 정렬한 결제방법 추천리스트를 생성하는 단계; 및
    상기 서버 시스템이, 상기 결제방법 추천리스트를 클라이언트 디바이스를 통해 상기 사용자에게 제공하는 단계를 포함하며,
    상기 키워드에 가맹점이 포함되지 않은 경우, 상기 결제방법 추천리스트는 상기 사용자의 위치 정보 및 상기 키워드에 포함된 업종에 따라 결정되는 적어도 하나의 가맹점을 기초로 생성되고,
    상기 보유 지불 수단은, 대외 기관과 연동하여 획득된, 소셜커머스 메타사이트에 의해 복수의 소셜커머스 사이트들로부터 크롤링(crawling)으로 수집되는 소셜커머스 쿠폰, 국내에 유통되는 할인 쿠폰 및 가맹점별 프로모션을 포함하는 결제방법 추천방법.
11. 제10항에 있어서,
    상기 결제방법 추천리스트를 생성하는 단계는,
    상기 서버 시스템이, 상기 사용자의 보유 지불 수단, 상기 보유 지불 수단의 혜택 종류와 혜택 범위에 대한 정보인 상품 설계 메타 정보, 및 상기 사용자의 구매 및 적립에 대한 상세 이력정보를 가공한 이력 통계 정보를 기초로 상기 업종-가맹점 쌍에 대한 상기 보유 지불 수단 별 혜택 여부와 혜택 폭을 계산하는 단계;
    상기 서버 시스템이, 상기 보유 지불 수단 별 혜택 여부와 혜택 폭, 및 상기 업종-가맹점 쌍에 대한 가맹점별 정책 테이블을 이용해, 상기 조합들 및 상기 조합들에 대응하는 혜택폭들을 생성하는 단계; 및
    상기 서버 시스템이, 상기 조합들 및 상기 조합들에 대응하는 혜택폭들을 혜택폭이 큰 순서대로 정렬하여 상기 결제방법 추천리스트를 생성하는 단계를 포함하는 결제방법 추천방법.
12. 제11항에 있어서,
    상기 보유 지불 수단은, 신용카드, 통신사 멤버쉽카드, 포인트 마일리지 카드, 상기 할인 쿠폰, 상기 소셜커머스 쿠폰, 상기 가맹점별 프로모션, 오프라인 가맹점의 스탬프 중 적어도 하나를 포함하는 결제방법 추천방법.
13. 제10항에 있어서,
    상기 업종-가맹점 쌍을 생성하는 단계는,
    상기 서버 시스템이, 상기 키워드에 상기 가맹점이 포함된 경우, 업종-가맹점 매핑 테이블을 이용해 상기 가맹점에 대응하는 하나의 업종을 선택하여 하나의 업종-가맹점 쌍을 생성하는 단계를 포함하는 결제방법 추천방법.
14. 제10항에 있어서,
    상기 업종-가맹점 쌍을 생성하는 단계는,
    상기 서버 시스템이, 상기 키워드에 상기 가맹점이 포함되지 않은 경우, 상기 위치 정보에 기초하여 상기 사용자의 주변을 결정하고, 업종-가맹점 매핑 테이블을 이용해 상기 주변 내에 위치한 n(n은 1이상의 정수) 개의 가맹점을 선택하여 상기 업종에 대응하는 상기 n 개의 업종-가맹점 쌍을 생성하는 단계를 포함하는 결제방법 추천방법.
15. 제14항에 있어서,
    상기 주변은 상기 업종에 따라 정해지는 반경에 의해 결정되는 결제방법 추천방법.
16. 제10항에 있어서,
    상기 서버 시스템이, 상기 결제방법 추천리스트에서 사용자가 선택한 결제 방법에 대한 피드백 정보를 저장하는 단계를 더 포함하는 결제방법 추천방법.
17. 제16항에 있어서,
    상기 서버 시스템이, 상기 피드백 정보를 저장한 뒤 상기 피드백 정보를 제외한 상기 사용자의 정보를 삭제하는 단계를 더 포함하는 결제방법 추천방법.

Images