KR102154384B1

KR102154384B1 - 포털 인증

Info

Publication number: KR102154384B1
Application number: KR1020167027874A
Authority: KR
Inventors: 차오 시우
Original assignee: 알리바바 그룹 홀딩 리미티드
Priority date: 2014-04-14
Filing date: 2015-04-14
Publication date: 2020-09-10
Also published as: EP3132370A4; EP3132370A1; JP6668544B2; US20150295915A1; HK1213379A1; TW201539342A; WO2015160781A1; US10122704B2; CN108551675A; CN108551675B; JP2017514220A; TWI684153B; JP2019204519A; JP6552519B2; CN104980412B; KR20160144374A; CN104980412A

Abstract

사용자의 휴대가능 단말이 애플리케이션 서버에 의해 푸시된 인증 프롬프트 메시지를 수신하는 경우, 인증 프롬프트 메시지에 대응하는 인증 프롬프트 옵션이 휴대가능 단말에서 출력된다. 인증 프롬프트 옵션이 사용자에 의해 선택된 후 포털 인증이 개시된다. 포털 인증이 개시된 후 포털 서버에 의해 회신된 휴대가능 단말의 MAC 주소 정보가 획득된다. 애플리케이션 클라이언트 단말이 애플리케이션 서버 단말에 로그인하기 위한 사용자 이름 및 암호가 포털 인증을 위한 사용자 이름 및 암호로서 사용된다. 포털 서버에 의해 회신된 휴대가능 단말의 MAC 주소 정보는 애플리케이션 서버에 발신된다. 본 개시는 포털 인증을 사용하는 동작을 가능하게 하고, 사용자가 포털 인증을 수행하는 것을 잊지 않게 하며, 포털 인증 메커니즘에 친숙하지 않은 이들에게 편리함을 가져온다.

Description

포털 인증{PORTAL AUTHENTICATION}

관련 특허 출원에 대한 상호참조

이 출원은 "Application Client Terminal, Server, and Corresponding Portal Verification Method"라는 표제로 2014년 4월 14일에 출원된 중국 특허 출원 제201410148906.8호에 대한 외국 우선권을 주장하고, 상기 중국 특허 출원의 모든 내용은 참고로 본 출원에 포함된다.

기술 분야

본 개시는 인터넷 기술 분야에 관련되고, 더욱 구체적으로, 애플리케이션 클라이언트 단말(application client terminal) 및 애플리케이션 서버(application server)에 관련된다.

모바일 인터넷의 업스트림(upstream) 및 다운스트림(downstream) 산업의 개발과 함께, 현 시점에서 모바일 액세스(mobile access)는 점차 인터넷으로의 액세스를 얻기 위한 주류가 되었다. 사용자는 온라인 쇼핑 애플리케이션과 소셜(social) 애플리케이션을 포함하는 다양한 모바일 애플리케이션을 활용하기 위해 스마트폰과 패드 같은 휴대가능 단말(portable terminal)을 사용한다. 가정에서조차, 많은 사용자가 네트워크를 액세스하기 위해 휴대가능 단말을 사용하는 것을 여전히 더 선호한다. 공공장소(public place)에서, 사용자는 인터넷을 액세스하기 위해 3G/4G와 같은 모바일 데이터 액세스 기술을 사용할 수 있다. 사용자가 위치한 공공장소에서 무료 무선 네트워크 액세스 서비스가 이용가능한 경우, 사용자는 보통 무선 로컬 영역 네트워크(Wireless Local Area Network: WLAN)를 통하여 인터넷을 액세스하기로 선택한다. 모바일 데이터 액세스와 비교하여, 일반적으로 WLAN 액세스는 더 안정적이고 더 빠른 인터넷 액세스 경험을 제공하고, 사용자에 있어서 인터넷 액세스 비용을 상당히 감소시킨다.

하이디라오(Haidilao™) 식당 또는 스타벅스(Starbucks™)와 같은 공공장소는 일반적으로 사용자를 위해 무선 액세스 서비스를 제공한다. 상업자(merchant)로서, 하이디라오(Haidilao™) 또는 스타벅스(Starbucks™)는 그 자체의 무선 네트워크를 구축하고 관리할 필요가 있는데, 예를 들어 무선 액세스 포인트(Access Point: AP) 및 무선 액세스 제어기(Access Controller: AC)를 포함하는 무선 네트워크를 배치하는 것이다. 이 시나리오에서, 하이디라오(Haidilao™)와 같은 상업자는 무선 네트워크의 소유자일 뿐만 아니라 무선 네트워크의 관리자이기도 하며, 무선 액세스 서비스의 보안 및 서비스 품질을 고려할 필요가 있다.

보안 관점에서, 사용자 신원 인증(user identity authentication)은 의심할 여지 없이 극도로 중요한 보안 메커니즘이다. 와이파이 보호 액세스(Wi-Fi Protected Access: WPA)/WPA2와 같은 무선 인증 모드는 홈 네트워크(home network)와 같은 소규모로 된 네트워크에 널리 적용되고, 네트워크의 관리자는 비교적 안전한 방식으로 비밀 키(secret key)를 각각의 인가된 사용자(authorized user)에게 알린다. 상업자들에 의해 배치된 몇몇 중간 규모로 되거나 대규모로 된 네트워크에서, 사용자에게 키를 하나씩 알리는 것은 명백히 용인할 수 없다. 더욱이, 위에서 기술된 메커니즘은 무선 링크 계층(wireless link layer)에서 구동되고(run), 따라서 열악한 호환가능성을 갖는다. 예컨대, 몇몇 사용자의 휴대가능 단말은 더 이른 모델이고, 그러한 휴대가능 단말 상에서 사용되는 무선 기술은 WPA2와 같은 인증 모드를 지원하지 않을 수 있다.

포털 인증(portal authentication)은 네트워크 계층(network layer) 위의 계층에서 구동되고, 일반적인 적용가능성을 가지며, 사용자의 휴대가능 단말의 하드웨어 및 휴대가능 단말 상에서 사용되는 무선 액세스 기술에 거의 무관하다. 사용자가 무선 네트워크를 액세스하는 이상 사용자는 표준적인 포털 인증 프로세스를 기반으로 네트워크 액세스 허가(network access permission)를 취득한다. 그러나, 포털 인증 기술은 사실 개인용 컴퓨터(Personal Computer: PC) 인터넷의 시대에서 유래하고, 모바일 인터넷의 사용 특성에 적응시키기 위한 기술적 문제를 갖는다.

도 1을 참조하면, 차이나 유니콤(China Unicom™)에 의해 제공되는 WLAN 인터넷 액세스 서비스가 일례로서 사용된다. 사용자의 스마트폰이 차이나 유니콤(China Unicom™)의 AP에 성공적으로 연결된(무선 네트워크를 액세스한) 후, 사용자의 스마트 폰의 스크린의 상부의 메시지 프롬프트 바(message prompt bar) 상에서, 무선 네트워크 연결 아이콘(11)은 스마트 폰이 무선 네트워크에 성공적으로 연결되었음을 나타낸다. 그러나, 이 때에, 사용자는 성공적으로 웨이보(Weibo™)를 리프레시하지(refresh) 않을 수 있다. 이 문제의 근본 원인은, 많은 통상적인 사용자들이, 무선 네트워크에 성공적으로 연결된 후에 그들이 외부 네트워크(일반적으로 인터넷)를 액세스할 수 있음을 당연하게 여기는 것이다. 그러나 사실, 사용자들은 무선 방식으로 유니콤(Unicom™)의 무선 네트워크에 성공적으로 연결될 뿐이다. 몇몇 인증 없는(authentication-free) 사이트(예를 들어 동적 호스트 구성 프로토콜(Dynamic Host Configuration Protocol: DHCP) 서버)를 제외하고, 사용자들은 포털 인증을 통과하기 전에 인터넷을 액세스할 수 없다.

사용자 단말(user terminal)에 관해서, 포털 인증은 브라우저(browser)를 기반으로 구현되고, 많은 통상적인 사용자들은 그들이 포털 인증 프로세스를 개시하기 위해 브라우저를 열 필요가 있음을 알지 못하는데 이 인증 메커니즘은 사용자의 가정 내의 무선 네트워크의 인증 모드와 상이하기 때문이다. 다른 관점에서, 설령 몇몇 사용자가 포털 인증의 작동 원리를 이해하더라도, 포털 인증을 수행하는 것은 여전히 불편하다. 예컨대, 사용자의 휴대가능 단말은 일반적으로 휴대가능 단말이 이전에 연결된 무선 네트워크에 자동으로 연결되는 기능을 가지나, 많은 스마트폰은 무선 네트워크에 스마트폰이 성공적으로 연결되는 경우 3G와 같은 모바일 데이터 연결을 자동으로 끌 것이다. 일단 사용자의 스마트폰이 무선 네트워크에 자동으로 연결되지만 사용자가 이 상황을 알아차리지 못하면, 사용자는 브라우저를 통해 포털 인증을 개시하지 않을 것이다. 그러한 시나리오에서는, 모바일 데이터 연결이 꺼지기 때문에 사용자 단말은 인터넷을 액세스하지 않을 수 있고 언제나 온라인으로 데이터를 교환할 필요가 있는 많은 애플리케이션에서 문제가 생길 것이다.

이 개요는 상세한 설명에서 추가로 후술되는 개념들 중 선택된 것을 단순화된 형태로 소개하기 위해 제공된다. 이 개요는 청구된 대상물(claimed subject matter)의 모든 중요 특징 또는 필수적 특징을 식별하도록 의도되지 않고, 청구된 대상물의 범주를 정하는 데에서 보조로서 단독으로 사용되도록 의도되지도 않는다. 예를 들면, 용어 "기법"은 위의 맥락에 의해 그리고 본 개시 도처에서 허용되는 대로 장치(들), 시스템(들), 방법(들) 및/또는 컴퓨터 판독가능(computer-readable) 명령어를 나타낼 수 있다.

본 개시는 휴대가능 단말 상에서 상주하거나(reside) 적용되는 예시적 애플리케이션 클라이언트 단말을 제공한다. 클라이언트는 푸시 처리 유닛(push processing unit), 포털 에이전트 유닛(portal agent unit) 및 매체 액세스 제어 주소 동기화 유닛(media access control address (MAC) synchronization unit)을 포함한다.

푸시 처리 유닛은, 애플리케이션 서버에 의해 푸시된(pushed) 인증 프롬프트 메시지(authentication prompt message)를 수신하는 경우, 휴대가능 단말의 메시지 프롬프트 바 내에 인증 프롬프트 메시지에 대응하는 인증 프롬프트 옵션(authentication prompt option)을 출력한다.

포털 에이전트 유닛은 인증 프롬프트 옵션이 사용자에 의해 선택됨이 판정된 후 포털 인증을 개시하는데, 포털 인증이 개시된 후 포털 서버에 의해 회신된 본 휴대가능 단말의 MAC 주소 정보를 획득한다. 포털 에이전트는, 포털 인증 동안에, 애플리케이션 클라이언트 단말이 애플리케이션 서버 또는 애플리케이션 서버 단말로 로그인하는 사용자 이름 및 암호를 포털 인증을 위한 사용자 이름 및 암호로서 사용한다.

MAC 동기화는 애플리케이션 서버로 포털 서버에 의해 회신된 본 휴대가능 단말의 MAC 주소 정보를 발신한다.

본 개시는 휴대가능 단말에 적용되는 예시적 포털 인증 방법을 또한 제공한다. 그 방법은 다음 동작들을 포함한다.

단계 A: 애플리케이션 서버에 의해 푸시된 인증 프롬프트 메시지가 수신된 경우, 인증 프롬프트 메시지에 대응하는 인증 프롬프트 옵션이 휴대가능 단말의 메시지 프롬프트 바 내에 출력된다.

단계 B: 인증 프롬프트 옵션이 사용자에 의해 선택됨이 판정된 후 포털 인증이 개시된다. 포털 서버에 의해 회신된 본 휴대가능 단말의 MAC 주소 정보가 포털 인증이 개시된 후 획득된다. 포털 인증 동안에, 애플리케이션 서버에 로그인하는 애플리케이션을 위한 사용자 이름 및 암호가 포털 인증을 위한 사용자 이름 및 암호로서 사용된다.

단계 C: 포털 서버에 의해 회신된 본 휴대가능 단말의 MAC 주소 정보가 애플리케이션 서버로 발신된다.

본 개시는 서버에 적용되거나 서버에 상주하고 애플리케이션 클라이언트 단말 및 무선 서버와 상호작용하는 예시적 애플리케이션 서버 단말을 또한 제공한다. 무선 서버는 적어도 하나의 무선 네트워크 내의 무선 액세스 디바이스를 관리한다. 애플리케이션 서버 단말은 푸시 관리 유닛(push management unit) 및 MAC 유지 유닛(MAC maintenance unit)을 포함한다.

무선 서버에 의해 발신된 단말 연결 메시지(terminal connection message)가 수신된 경우, 푸시 관리 유닛은 메시지 내에 실린(carried) 휴대가능 단말의 MAC 주소 정보를 획득하고, 로컬 사용자 MAC 테이블(local user MAC table) 내에서 MAC 주소에 대응하는 사용자를 찾아 검색하며, 만약 대응하는 사용자가 발견되는 경우 사용자의 애플리케이션 클라이언트 단말로 인증 프롬프트 메시지를 푸시한다.

포털 인증 요청이 수신된 경우, 포털 인증 유닛은 요청 내의 사용자 이름 및 암호가 본 애플리케이션의 등록된(registered) 사용자에 속하는지를 판정하고, 만약 그렇다면, 사용자의 포털 인증이 성공함을 판정한다.

사용자의 애플리케이션 클라이언트 단말에 의해 발신된 MAC 주소 정보가 수신된 경우, MAC 유지 유닛은 MAC 주소 정보 및 사용자 간의 대응 관계로써 사용자 MAC 테이블을 업데이트한다.

본 개시는 휴대가능 단말 및 무선 서버와 상호작용하기 위해 애플리케이션 서버에 적용되는 예시적 포털 인증 서비스 방법을 또한 제공한다. 무선 서버는 적어도 하나의 무선 네트워크 내의 무선 액세스 디바이스를 관리한다. 그 방법은 다음 동작들을 포함할 수 있다.

단계 a: 무선 서버에 의해 발신된 단말 연결 메시지가 수신된 경우, 메시지 내에 실린 휴대가능 단말의 MAC 주소 정보가 획득되고, MAC 주소에 대응하는 사용자가 로컬 사용자 MAC 테이블 내에서 검색되며, 만약 대응하는 사용자가 발견되는 경우 인증 프롬프트 메시지가 사용자에게 푸시된다.

단계 b: 포털 인증 요청이 수신된 경우, 요청 내의 사용자 이름 및 암호가 본 애플리케이션의 등록된 사용자에 속하는지가 판정되고, 만약 그렇다면, 사용자의 포털 인증이 성공함이 판정된다.

단계 c: 사용자에 의해 발신된 MAC 주소 정보가 수신된 경우, 사용자 MAC 테이블이 MAC 주소 정보 및 사용자 간의 대응 관계로써 업데이트된다.

종래의 기법과 비교하여, 본 개시는 포털 인증을 사용하는 사용자의 동작을 상당히 수월하게 하고, 사용자가 포털 인증을 수행하는 것을 잊거나 인터넷을 액세스하기 위한 포털 인증 메커니즘을 알지 못하기에 사용자가 무선 네트워크를 통해 인터넷을 액세스하지 못한다는 문제를 상당 부분 방지한다. 본 개시는 모바일 인터넷 환경에서의 사용자 요구사항에 더 잘 적응된다.

도 1은 사용자가 포털 인증을 수행하는 것을 잊은 경우 웨이보(Weibo™) 리프레시 결과의 개략도이다.
도 2는 전형적인 포털 인증 네트워킹(portal authentication networking)의 개략도이다.
도 3은 본 개시의 예시적 실시예에서의 연동 시스템(linkage system) 내의 각각의 노드(node)의 하드웨어 및 로직(logic) 구조의 도해이다.
도 4는 본 개시의 예시적 실시예에 따른 예시적 포털 인증 처리(portal authentication processing)의 흐름도이다.
도 5는 본 개시의 예시적 실시예에 따른 예시적인 상세화된 포털 인증 처리의 흐름도이다.
도 6은 본 개시의 예시적 실시예에 따른 상업자 및 사용자를 위한 예시적인 편리한 연동 프로세스의 개략도이다.

본 개시의 예시적 실시예들의 소개 전에, 통상의 기술자가 본 개시의 기술적 이점을 더 분명히 이해할 것이도록 우선 포털 인증 메커니즘이 기술된다. 도 2에 도시된 네트워킹 예를 참조하면, 이 네트워킹 환경에서, 스마트폰과 같은 휴대가능 단말(202)이 무선 네트워크에 성공적으로 연결된 후, 사용자는 (인터넷 상의 사이트와 같은) 외부 네트워크를 액세스하여 포털 인증을 트리거한다(trigger). 포털 인증 프로세스는 다음과 같이 간략히 기술될 수 있다:

단계 I: 사용자는 웹사이트, 예컨대 www.weibo.com를 액세스하기 위해 휴대가능 단말(202)에서 브라우저를 사용한다. 그 사이트의 인터넷 프로토콜(Internet Protocol: IP) 주소는 일반적으로 AC(무선 액세스 제어 서버 또는 디바이스)(204)의 예외 리스트(exception list)(인증이 없음) 내에 있지 않고 사용자의 IP 주소는 AC(204)의 사용자 화이트리스트(user whitelist) 내에 있지 않으므로, 프로세스는 단계 II로 넘어간다.

단계 II: 무선 액세스 디바이스는 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol: HTTP) 재지향(redirection)에 의해서 (일반적으로 AC(204)와 통합된) 포털 서버(206)로 사용자의 액세스를 재지향하고, 포털 서버는 포털 인증 페이지를 브라우저에 회신한다.

단계 III: 사용자는 사용자 이름 및 암호를 포털 인증 페이지 내에 입력하고 인증 요청을 제출하며, 포털 서버는 이후 인증 요청을 무선 액세스 디바이스에 제출한다.

단계 IV: AC(204)는 사용자에 의해 입력된 사용자 이름 및 암호가 인가된 사용자와 매칭되는지(matched)를 검증하기 위해 인증 서버(208)로의 포털 인증을 개시한다.

단계 V: 만약 사용자 포털 인증이 통과되는 경우, AC(204)는 사용자의 IP 주소를 사용자 화이트리스트에 추가한다.

단계 VI: 사용자는 다시 임의의 웹사이트를 액세스하며, 사용자의 IP 주소가 이미 사용자 화이트리스트 내에 있으므로, 사용자의 액세스는 허용될 것이다.

단계 I 내지 단계 VI은 전형적인 포털 인증 프로세스를 기술하고, 그러한 프로세스는 PC 상의 포털 인증과 일반적으로 동일하다. 모바일 인터넷의 요구사항에 적응하고 사용자에게 편리함을 가져오기 위하여, 더욱 최적화된 해결책에서, (위에서 기술된 AC(204)와 같은) 무선 액세스 디바이스 및 애플리케이션 서버(208) 간의 연동을 기반으로, 포털 인증 프로세스는 단순화될 수 있다. 단계 II에서, 포털 서버(206)에 의해 회신된 포털 인증 페이지는 애플리케이션 연관 컴포넌트(application associated component)(예를 들어 알리페이(Alipay™) 연관 컴포넌트)를 전한다. 브라우저 내에 로딩된(loaded) 후, 알리페이(Alipay™) 연관 컴포넌트는, 모바일 전화의 전경(foreground)으로 알리페이 월렛(Alipay™ Wallet)을 호출하고, 사용자를 대신하여 포털 인증을 수행할 것을 알리페이 월렛(Alipay™ Wallet)에 청하는 통지를 발신하는 알리페이 월렛(Alipay™ Wallet)의 호출 동작을 수행할 것이다. 그때 사용자가 알리페이 월렛(Alipay™ Wallet)에 이미 로그인하였다고 가정하면, 알리페이 월렛(Alipay™ Wallet)은 통지에 따라 사용자의 알리페이(Alipay™) 사용자 이름 및 암호를 사용함으로써 포털 인증을 수행한다. 단계 IV에서, 알리페이(Alipay™) 사용자 이름 및 암호가 사용되므로, 이 경우에, (알리페이(Alipay™) 서버와 같은) 애플리케이션 서버(208)는 대응하는 인증 서버의 역할을 하며, 이 방식으로, 사용자는 포털 인증을 위해 사용자 이름 및 암호를 기억할 필요가 없고, 대신에 사용자는 알리페이(Alipay™) 사용자 이름 및 암호를 사용할 수 있다. 인증 서버(212) 및 애플리케이션 서버(208)와 함께 무선 서비스를 제공하는 하나 이상의 다른 무선 서버(들)(210)가 있을 수 있다. 휴대가능 단말(202)은 AP(액세스 포인트)(214)를 통해 AC(204)에 연결될 수 있다.

애플리케이션 알리페이 월렛(Alipay™ Wallet)은 로그인된 상태를 정기적으로 유지할 수 있으므로, 사용자는 일반적으로 브라우저를 열 필요가 없고, 포털 인증 프로세스에서 알리페이(Alipay™) 사용자 이름 및 암호를 입력하는 동작은 필요하지 않다. 더 중요하게는, 알리페이(Alipay™)가 많은 상업자들과 파트너십(partnership)을 구축하였기에, 사용자는 그 상업자들을 방문하는 경우 포털 인증을 구현하기 위해 동일한 사용자 이름 및 암호를 사용할 수 있다. 물론, 만약 사용자가 알리페이(Alipay™) 사용자가 아닌 경우, 사용자는 여전히 종래의 포털 인증 모드로 포털 인증을 수행할 수 있지만, 이 사용자는 미리 등록하여 포털 사용자 이름 및 암호를 획득하거나, 임시적인 포털 사용자 이름 및 암호를 텍스트 메시지를 통해 또는 다른 방식으로 획득할 필요가 있을 수 있다. 그러한 사용자의 포털 사용자 이름 및 암호의 인증은 여전히 인증 서버에서 행해질 것이다. 이 해결책은 알리페이(Alipay™) 사용자 또는 유사한 애플리케이션의 등록된 사용자의 포털 인증을 가능하게 한다. 그러나, 그러한 구현은 여전히 배후에서 제기되는 기술적 문제를 철저히 해결하지는 못한다.

계속해서 도 2를 참조하면, 본 개시는 위에서 기술된 포털 인증을 기반으로 추가로 최적화한다. 예시적 실시예에서, 본 개시는 네트워크 시스템 및 애플리케이션 시스템 간의 집약적인 연동에 기반한다. 네트워크 시스템은 상업자의 무선 네트워크 내의 무선 액세스 디바이스 및 무선 액세스 디바이스 각각을 관리하는 무선 서버를 물리적으로 포함하고, 애플리케이션 시스템은 휴대가능 단말 및 애플리케이션 서버를 물리적으로 포함한다. 무선 액세스 디바이스는 휴대가능 단말을 위해 무선 네트워크 액세스 서비스를 제공한다. 무선 액세스 디바이스는 운영자(operator) 또는 식품 벤더(food vendor)와 같은 다양한 상업자가 소유할 수 있는데, 이는 일반적으로 상업자가 비즈니스 서비스를 제공하는 물리적 영역 내에 배치된다.

도 3을 참조하면, 본 개시를 묘사하는 데에 도움이 되도록, 서버 및 휴대가능 단말과 같은 호스트의 하드웨어 아키텍처가 단순화되고 추상화된다. 하드웨어 계층에서, 각각의 호스트는 하나 이상의 프로세서, 메모리, 추가적인 비휘발성 저장 디바이스 및 네트워크 인터페이스를 포함한다. 서비스 계층의 관점에서, 도 3 내의 애플리케이션 클라이언트 단말 및 애플리케이션 서버 단말 양자 모두는 이하의 방식으로 형성된 로직 장치(logic apparatus)(또한 "가상 장치"(virtual apparatus)로 지칭됨)로서 해석될 수 있다: 대응하는 호스트 상의 프로세서가 컴퓨터 프로그램 또는 컴퓨터 실행가능 명령어를 실행을 위해 메모리 내로 판독함. 물론, 본 개시는 소프트웨어 구현 외에 프로그램가능 로직 디바이스(programmable logic device)와 같은 다른 구현을 배제하지 않는다. 다시 말해, 다음의 설명에서 각각의 처리 단계를 실행하는 개체는 하드웨어, 로직 디바이스 또는 유사한 것을 사용하여 구현될 수 있다.

도 3에 도시된 바와 같은 예시적 실시예에서, 클라이언트 또는 휴대가능 단말(302)은 하나 이상의 네트워크 인터페이스(304), 하나 이상의 프로세서 또는 데이터 처리 유닛(들)(306) 및 메모리(308)를 포함한다. 메모리(308)는 컴퓨터 판독가능 매체의 일례이다. 메모리(308)는 푸시 처리 유닛(push processing unit)(310), MAC 동기화 유닛(MAC synchronization unit)(312) 및 포털 에이전트 유닛(portal agent unit)(314)을 포함하는 복수의 모듈 또는 유닛을 그 내부에 저장할 수 있다. 휴대가능 단말(302)은 추가적인 비휘발성 저장 디바이스(316)을 더 포함할 수 있다. 휴대가능 단말(302)은 무선 액세스 디바이스(318)를 통하여 네트워크에 연결된다.

애플리케이션 서버 단말(320)은 하나 이상의 네트워크 인터페이스(322), 하나 이상의 프로세서(들) 또는 데이터 처리 유닛(들)(324) 및 메모리(326)를 포함한다. 메모리(326)는 컴퓨터 판독가능 매체의 일례이다. 메모리(326)는 MAC 유지 유닛(MAC maintenance unit)(328), 포털 인증 유닛(portal authentication unit)(330) 및 푸시 관리 유닛(push management unit)(332)을 포함하는 복수의 모듈 또는 유닛을 그 내부에 저장할 수 있다. 애플리케이션 서버 단말(320)은 추가적인 비휘발성 저장 디바이스(334)를 더 포함할 수 있다.

도 4를 참조하면, 클라이언트 단말, 무선 액세스 디바이스, 무선 서버 및 애플리케이션 서버 단말은 이하의 동작들을 수행하기 위해 동작 동안에 서로 협력한다(coordinate).

402에서, 무선 액세스 디바이스는 휴대가능 단말이 무선 액세스 디바이스의 무선 네트워크에 연결됨이 판정되는 경우 무선 서버에 단말 연결 메시지를 보고한다. 그 메시지는 무선 액세스 디바이스의 식별자 및 무선 네트워크에 연결된 휴대가능 단말의 MAC 주소 정보를 전한다.

404에서, 단말 연결 메시지가 수신된 후, 무선 서버는 애플리케이션 서버 단말에 연결 프롬프트 메시지(connection prompt message)를 발신한다. 연결 프롬프트 메시지는 휴대가능 단말의 MAC 주소 정보를 전한다.

406에서, 무선 서버에 의해 발신된 단말 연결 메시지가 수신되는 경우, 애플리케이션 서버 단말의 푸시 관리 유닛은 메시지 내에 실린 휴대가능 단말의 MAC 주소 정보를 획득하고, 로컬 사용자 MAC 테이블과 같은 사용자 MAC 테이블 내에서 MAC 주소에 대응하는 사용자를 찾아 검색한다. 만약 대응하는 사용자가 발견되는 경우, 408에서의 동작이 수행된다. 그렇지 않으면, 현재의 프로세스 흐름은 종료된다.

408에서, 애플리케이션 서버 단말의 푸시 관리 유닛은 발견된 사용자의 애플리케이션 클라이언트 단말에 인증 프롬프트 메시지를 푸시한다.

410에서, 애플리케이션 서버 단말에 의해 푸시된 인증 프롬프트 메시지가 수신되는 경우, 애플리케이션 클라이언트 단말의 푸시 처리 유닛은 휴대가능 단말의 메시지 프롬프트 바 내에 인증 프롬프트 메시지에 대응하는 인증 프롬프트 옵션을 출력한다.

412에서, 인증 프롬프트 옵션이 사용자에 의해 선택됨이 판정된 후 또는 브라우저의 연관 컴포넌트(associated component)로부터의 통지가 수신된 후, 애플리케이션 클라이언트 단말의 포털 에이전트 유닛은 포털 인증을 개시하고, 포털 인증이 개시된 후 포털 서버에 의해 회신된 휴대가능 단말의 MAC 주소 정보를 획득하며, 포털 인증 동안에, 애플리케이션 클라이언트 단말이 애플리케이션 서버 단말에 로그인하기 위해 사용하는 사용자 이름 및 암호를 포털 인증을 위한 사용자 이름 및 암호로서 사용한다.

414에서, 포털 인증 요청이 수신되는 경우, 애플리케이션 서버 단말의 포털 인증 유닛은 요청 내의 사용자 이름 및 암호가 애플리케이션의 등록된 사용자에게 속하는지를 판정하고, 만약 그렇다면, 사용자의 포털 인증이 성공함을 판정한다.

416에서, 애플리케이션 클라이언트 단말의 MAC 동기화 유닛은 애플리케이션 서버 단말에 포털 서버에 의해 회신된 휴대가능 단말의 MAC 주소 정보를 발신한다.

418에서, 애플리케이션 클라이언트 단말에 의해 발신된 MAC 주소 정보가 수신된 후, 애플리케이션 서버 단말의 MAC 유지 유닛은 MAC 주소 정보 및 사용자 간의 대응 관계로써 사용자 MAC 테이블을 업데이트한다.

본 개시에서, 휴대가능 단말은 사용자가 휴대하기 쉬운 단말 디바이스, 예컨대, 스마트폰(smart phone), PDA 또는 태블릿 컴퓨터(tablet computer)일 수 있다. 스마트폰은 아래의 설명을 위한 일례로서 사용된다. 본 개시의 애플리케이션 클라이언트 단말은, 임의의 클라이언트 단말(이로부터 사용자가 애플리케이션에 로그인하기 위해 사용자 이름 및 암호를 입력함), 예를 들어 알리페이 월렛(Alipay™ Wallet), 타오바오(Taobao™), 시나 웨이보(Sina™ Weibo™) 또는 라이왕(Laiwang)을 포함하는 모바일 전화 애플리케이션 클라이언트 단말일 수 있는, 휴대가능 단말 상에서 구동되는 애플리케이션 소프트웨어일 수 있다. 애플리케이션 클라이언트 단말 알리페이 월렛(Alipay™ Wallet)은 아래의 설명을 위한 일례로서 사용된다. 애플리케이션 서버 단말은 애플리케이션 서버 상에서 구동되는 서비스 소프트웨어이고 애플리케이션 클라이언트 단말을 위해 대응하는 애플리케이션 서비스를 제공한다. 알리페이(Alipay™) 서버 단말은 아래의 애플리케이션 서버의 일례로서 사용된다. 무선 액세스 디바이스는 팻 AP(fat AP), AC와 씬 AP(thin AP)의 아키텍처 내의 AC, 또는 무선 액세스 기능을 갖는 다른 유사한 네트워크 디바이스일 수 있다. AC는 아래의 설명을 위한 일례로서 사용된다.

대부분의 경우에, 하나의 스마트폰은 일반적으로 고유한 MAC 주소를 가지며, 따라서, 하나의 MAC 주소는 일반적으로 알리페이 월렛(Alipay™ Wallet)을 사용하는 하나의 사용자와의 상대적으로 안정적인 대응 관계를 갖는다. 스마트폰이 어떤 AC에 의해 관리되는 무선 네트워크에 연결되는 경우, 대응하는 사용자는 따라서 무선 네트워크를 통해 인터넷을 액세스하려고 시도한다고 판정된다. 이 경우에, 404에서 연동 메커니즘에 의해, 알리페이(Alipay™) 서버 단말은 무선 서버에 의해 발신된 단말 연결 메시지에 따라 이 이벤트(event)를 통지받는다. 대응하여, 알리페이(Alipay™) 서버 단말은 메시지 내에 실린 MAC 주소 정보에 따라 대응하는 알리페이(Alipay™) 사용자를 발견하고, 이 경우에, 알리페이(Alipay™) 사용자는 AC에 연결된 앞서 언급된 스마트폰을 사용하고 있다고 가정된다. 이 가정에 기반하여, 알리페이(Alipay™) 서버 단말은 사용자의 알리페이(Alipay™) 클라이언트 단말에 인증 프롬프트 메시지를 푸시한다. 알리페이 월렛(Alipay™ Wallet)은 인증 프롬프트 메시지에 따라 인증 프롬프트 옵션을 생성하는데, 사용자가 인증 프롬프트 옵션을 선택하는 한, 알리페이 월렛(Alipay™ Wallet)은 사용자를 대신하여 포털 인증을 자동으로 수행한다. 전체 프로세스 동안, 사용자는 클릭하기(clicking) 또는 유사한 간단한 동작에 의해 인증 프롬프트 옵션을 선택할 필요가 있을 뿐이고, 포털 인증은 신속히 완료된다. 더욱이, 본 기법은 사용자가 포털 인증을 형성하는 것을 잊어버린다는 문제를 상당한 정도로 방지한다. 이하는 특정 구현을 사용함으로써 상세히 본 개시의 이점을 소개한다.

본 개시에서, 무선 네트워크로의 스마트폰의 첫 액세스(first-time access)를 위한 인증 프로세스는 무선 네트워크로의 처음이 아닌 액세스(non-first-time access)를 위한 인증 프로세스와는 어느 정도 상이하다. 그러나, 첫 액세스이든 처음이 아닌 액세스이든 상관없이, 412부터 418까지의 동작이 수행된다. 사실, 첫 액세스 및 처음이 아닌 액세스를 위한 포털 인증 프로세스들 간의 차이는 그저 인증 트리거링(authentication triggering) 방식이다.

1) 사용자가 처음으로 알리페이(Alipay™)의 협조 상업자(cooperative merchant)의 무선 네트워크에 연결되는 경우 프로세스 흐름:

사용자(토니(Tony))가 처음으로 알리페이(Alipay™)의 협조 상업자(상업자 A라고 가정함)를 방문한다고 가정된다. 사용자는 상업자 A의 무선 네트워크를 발견하기 위해 그의 스마트폰(이의 MAC 주소는 MAC3임)을 사용하고, 무선 네트워크로의 연결을 완료한다. 상업자 A의 무선 네트워크에 연결되는 사용자의 동작은 402부터 406까지의 동작을 트리거할 것이다. 406에서, 알리페이(Alipay™) 서버 단말은 표 1에 도시된 바와 같이, MAC3에 따라 로컬 사용자 MAC 테이블 내에서 검색한다. 사용자가 포털 인증을 수행하기 위해 알리페이(Alipay™) 서버 단말을 사용하는 것이 처음이므로, MAC3는 표 1 내에 존재하지 않는데, 그때, 애플리케이션 서버 단말의 프로세스 흐름은 여기서 종료된다. 애플리케이션 서버 단말은 어느 사용자가 상업자 A의 무선 네트워크에 연결되는 데에 스마트폰을 사용하는지 알지 못하고, 따라서 인증 프롬프트 메시지를 푸시할 수 없다. 다시 말해, 사용자가 처음으로 알리페이(Alipay™)의 협조 상업자의 무선 네트워크에 연결되는 경우, 408에서의 동작은 수행되지 않을 것이고, 사용자의 모바일 전화는 인증 프롬프트 메시지를 수신하지 않을 것이다. 이 경우에, 사용자는 수동으로 포털 인증 프로세스를 트리거해야 한다.

사용자에 의해 포털 인증을 수동으로 트리거하는 프로세스는, 예컨대, 예외 사이트 리스트(exception site list) 내에 있지 않은 임의의 웹사이트로 액세스하는 것에 의함으로써, 선행 기술에서와 동일하거나, 간단히 말하면, 포털 인증은 사용자가 브라우저를 사용함으로써 인터넷에 액세스하는 한 트리거된다. 위에서 기술된 바와 같이, 이 프로세스에서, 애플리케이션 클라이언트 단말 알리페이 월렛(Alipay™ Wallet)은 브라우저 상에서 구동되는 알리페이(Alipay™) 연관 컴포넌트에 의해 호출될 것이다. 대응하여, 알리페이 월렛(Alipay™ Wallet)의 포털 에이전트 유닛은 연관 컴포넌트의 인증 통지를 수신할 것이다.

예컨대, 포털 인증이 개시되기 전에, 포털 에이전트 유닛은 사용자가 애플리케이션 로그인된 상태(application logged-in status) 내에 있는지를 체크할 수 있고, 만약 사용자 Tony가 애플리케이션 로그인된 상태 내에 있지 않은 경우, 알리페이 월렛(Alipay™ Wallet) 로그인 인터페이스가 전경으로 호출되어 사용자가 알리페이(Alipay™) 사용자 이름 및 암호를 인터페이스 내에 입력할 수 있다. 사용자가 사용자 이름 및 암호를 제출한 후, 알리페이(Alipay™) 서버 단말은 애플리케이션 로그인을 완료하기 위해 신원 인증(identity authentication)을 수행한다. 물론, 그러한 프로세스는 의무적이지 않은데, 왜냐하면 애플리케이션 알리페이(Alipay™)가 그 자체의 로그인 타임아웃 메커니즘(login timeout mechanism)을 갖도록 포털 에이전트 유닛은 애플리케이션 알리페이(Alipay™)의 보안 메커니즘을 전혀 감안하지 않을 수 있기 때문이지만, 이것은 포털 인증에서 대안으로서의 알리페이(Alipay™) 신원 정보(알리페이(Alipay™) 사용자 이름 및 암호)의 사용에 영향을 미치지 않는다. 사용자의 사용자 이름 및 암호가 알리페이(Alipay™) 클라이언트 단말 내에 저장되는 한 포털 인증은 개시될 수 있다. 포털 인증이 개시된 후, 포털 인증 요청은 마침내 알리페이(Alipay™) 서버 단말에 도달할 것이고, 알리페이(Alipay™) 서버 단말의 포털 인증 유닛은 포털 인증 요청 내의 사용자 이름 및 암호가 알리페이(Alipay™)의 등록된 사용자에게 속하는지를 체크하며, 만약 그렇다면, 무선 액세스 디바이스에 인증 성공 통지를 회신할 수 있다. 그러면 무선 액세스 디바이스는 성공적인 인증을 스마트폰에 통지한다. 여기서 알리페이(Alipay™) 서버 단말이 애플리케이션 서비스를 제공하기 위해 사용하는 IP 주소는 일반적으로 상업자 A의 AC의 예외 사이트 리스트 내에 구성됨에 유의할 수 있는데, 다시 말해, 각각의 사용자는, 사용자가 인증을 통과하거나 그렇지 않든 상관없이, 어떤 제한도 없이 애플리케이션 서비스를 획득하기 위해 AC를 통해 그 IP 주소를 액세스할 수 있다.

단계(406)에서, 포털 인증을 개시하기 위한 두 종류의 트리거 조건이 있는데: 하나는 인증 프롬프트 옵션이 사용자에 의해 선택되는 것이고, 다른 것은 브라우저의 연관 컴포넌트로부터의 통지가 수신되는 것이다. 사용자가 처음으로 알리페이(Alipay™)의 협조 상업자의 무선 네트워크에 연결되는 경우, 트리거 조건은 브라우저의 연관 컴포넌트의 통지이다. 다시 말해, 사용자가 처음으로 무선 네트워크에 연결되는 경우, 402부터 418까지의 동작은 단지 부분적으로 수행되는데, 408 및 410에서의 동작은 수행되지 않고 408 및 410에서의 동작의 목적은 사용자의 수동 동작에 의해 달성된다. 412에서의 포털 인증의 개시에 더하여, 본 개시 내의 알리페이 월렛(Alipay™ Wallet)은 선행 기술과는 상이한 416 및 418에서의 동작을 또한 수행한다.

416에서, 알리페이 월렛(Alipay™ Wallet)이 MAC 주소를 획득하는 방법은 선행 기술에서와는 상당히 상이하다. 종래의 설계 아이디어에 따르면, 애플리케이션 개발자는 운영 체제로부터 직접적으로 MAC 주소를 판독하는 것과, MAC 주소가 모바일 전화 하드웨어의 속성이므로 이후 서버 단말에 MAC 주소를 발신하는 것을 보통 고려한다. 종래의 PC 인터넷 환경에서, 윈도우즈(Windows™) 운영 제체를 일례로서 사용함으로써, 모든 통상적인 사용자는 "ipconfig /all"과 같은 커맨드(command)를 사용함으로써 호스트의 MAC 주소를 획득할 수 있다. 그러나, 모바일 인터넷 환경에서, 그러한 종래의 구현 아이디어는 미세한 기술적 결함을 갖는다.

우선, 사용자의 정보 보안과 같은 다양한 요인에 대한 우려로 인해, 모바일 운영 체제는 모바일 전화의 MAC 주소를 판독하는 것에 대해 많은 난관을 설정한다. 예컨대, 구글(Google™)에 의해 제공되는 안드로이드(Android™) 운영 체제에서, 애플리케이션은 스마트폰의 MAC 주소를 판독할 수 있게 되어 있기는 하지만, 추가적인 조건이 충족될 필요가 있고, 이들 추가적인 조건을 만족시키기 위해서는, 더 복잡한 개발 작업이 행해질 필요가 있다. 애플(Apple™)에 의해 제공되는 아이오에스(IOS™) 운영 체제에서, 현재 그 운영 체제는 모바일 전화 애플리케이션으로 하여금 직접적으로 스마트폰의 MAC 주소를 판독할 수 있게 하지 않는다. MAC 주소를 판독하기 위해서는, 그러한 제한이 우회될(bypassed) 필요가 있는데, 이는 더 복잡한 개발 작업이 있음을 의미하며, 간접적으로 MAC 주소를 판독하기 위해 시스템 제한이 우회되더라도, 모바일 전화 애플리케이션의 보안이 아이오에스 앱 스토어(IOS™ App store)에서 의심받을 수 있으니, 이는 구현하기 어렵다. 즉, 종래의 기법에 따라 스마트폰으로부터 MAC 주소를 판독하는 것이 기술적으로 실현가능하기는 하나, 구현 효과는 하찮다.

본 기법은 사용자의 정보 보안을 보장하면서 더 편리한 방법으로 사용자의 MAC 주소를 획득한다. 스마트폰이 AC에 연결된 후, AC는 스마트폰에 패킷을 전송할 필요가 있기에 AC는 당연히 스마트폰의 MAC 주소를 저장한다. 따라서, AC는 포털 인증 동안에 포털 서버에 스마트폰의 MAC 주소를 전달할 수 있고, 포털 서버는 알리페이 월렛(Alipay™ Wallet)에 MAC 주소를 회신한다. 많은 인기 있는 해결책에서, 포털 서버는 흔히 AC 내에 통합되고, 따라서, MAC 주소를 전달하는 것이 비교적 쉽다. 예시적 구현에서, 본 개시는, 알리페이 월렛(Alipay™ Wallet)에, 모바일 전화의 MAC 주소를 재지향된(redirected) URL(Uniform Resource Location)에 의해 전달되는 파라미터(재지향된 URL의 전달 파라미터)로서 회신한다. 포털 서버에 의해 발신된 재지향된 URL의 일례가 다음과 같이 보여진다:

www.portalabc.com/default.asp?id=50-E5-49-BB-3F-BE

www.portalabc.com/default.asp는 포털 인증 페이지의 URL을 나타내고, www.portalabc.com/default.asp에는 가변적인 전달 파라미터가 뒤따른다. 파라미터가 MAC 주소인 경우, 파라미터는 포털 인증 프로세스에 대해 어떤 실질적인 의미도 갖지 않는다. 그러나 이 프로세스를 사용함으로써, 본 개시는 사용자 Tony의 스마트폰의 MAC 주소를 URL의 전달 파라미터로서 사용하여, 이로써 MAC 주소를 알리페이 월렛(Alipay™ Wallet)에 회신한다. 이 경우에, 알리페이 월렛(Alipay™ Wallet)은 MAC 주소 50-E5-49-BB-3F-BE(MAC3)를 획득하기 위해 URL을 파싱하고(parse), 이후 알리페이(Alipay™) 서버 단말에 MAC3를 통지한다. 예시적 실시예에서, 알리페이(Alipay™) 서버 단말은 포털 인증이 성공한 후 통지받을 수 있다. MAC3가 수신된 후, 알리페이(Alipay™) 서버 단말은 이에 따라 사용자에 의해 사용되는 스마트폰의 MAC 주소 및 사용자 간의 대응관계를 저장한다. 표 1은 대응하여 표 2이도록 업데이트된다.

몇몇 무선 액세스 디바이스는 사용자의 정보 보안에 대한 우려에서 MAC 주소를 암호화된 문자열(encrypted character string)로 암호화하고, 암호화된 문자열을 스마트폰으로 MAC 주소 정보로서 회신할 수 있음을 고려하면, 이 경우에, 알리페이 월렛(Alipay™ Wallet)은 특별한 처리를 수행할 필요는 없고 그 위의 MAC 동기화 유닛이 암호화된 데이터를 애플리케이션 서버 단말에 발신할 필요가 있을 뿐이다. 그러나, 애플리케이션 서버 단말은 특별한 처리를 수행할 필요가 있다. 418에서, MAC 유지 유닛은 MAC 주소 정보가 저장되기 전에 MAC 주소 정보가 암호화된 데이터인지를 판정한다. 만약 MAC 주소 정보가 암호화된 데이터가 아닌 경우, MAC 유지 유닛은 MAC 주소 정보 및 사용자 간의 대응 관계를 저장할 필요가 있을 뿐이다. 만약 MAC 주소 정보가 암호화된 데이터인 경우, MAC 유지 유닛은, 전달 파라미터 내에 추가적으로 실린 벤더 식별(vendor identification)에 따라, 대응하는 복호화 알고리즘(decryption algorithm)을 기동하여(invoke), 암호화된 데이터를 복호화하고, 평문(plaintext) MAC 주소 정보를 획득하며, 이후 MAC 주소 정보 및 사용자 간의 대응 관계를 저장할 필요가 있다. 일반적으로, 무선 액세스 디바이스의 제공자는 알리페이(Alipay™)와의 파트너십을 가지며, 따라서 그 디바이스의 벤더 식별 및 그 식별에 대응하는 암호화/복호화는(만약 필요하다면) 알리페이(Alipay™) 서버 단말 상에 저장된다. 양측 모두에서 동일한 암호화/복호화 알고리즘을 공유함으로써, MAC 주소 정보의 연동이 실현되고, 더욱이, 사용자 정보의 보안이 개선된다.

2) 알리페이(Alipay™)의 협조 상업자의 무선 네트워크로의 사용자의 처음이 아닌 액세스를 위한 프로세스 흐름:

도 5를 참조하면, 사용자 Tony가 알리페이(Alipay™)의 협조 상업자 A에서 첫 번째 포털 인증을 완료한 후, 알리페이(Alipay™) 서버 단말은 사용자 및 사용자의 모바일 전화의 MAC 주소 간의 대응 관계를 저장한다.

도 5 내에서, 502에서, 애플리케이션, 가령 알리페이(Alipay™)를 설치한 스마트폰과 같은 휴대가능 단말(애플리케이션 클라이언트 단말)(504)은 (포털 서버와 통합된) 무선 액세스 디바이스(506)를 통하여 무선 액세스 네트워크에 액세스한다. 508에서, 무선 액세스 디바이스(506)는 무선 서버(510)에 단말 연결 메시지를 발신한다. 512에서, 무선 서버(510)는 알리페이(Alipay™) 서버 단말을 구비한 알리페이(Alipay™) 서버와 같은 애플리케이션 서버(514)에 연결 프롬프트 메시지를 발신한다. 516에서, 애플리케이션 서버(514)는 연결 프롬프트 메시지 내에 포함된 MAC 주소 정보에 따라 사용자를 발견한다. 518에서, 애플리케이션 서버(514)는 휴대가능 단말(504)에 인증 프롬프트 메시지를 푸시한다. 520에서, 휴대가능 단말(504)은 인증 프롬프트 옵션을 생성하고 그것을 사용자에게 디스플레이한다. 522에서, 포털 단말(504)은 인증 프롬프트 옵션이 사용자에 의해 선택됨이 판정되는 경우 무선 액세스 디바이스(506)와 함께 포털 인증을 개시한다. 524에서 무선 액세스 디바이스(506)는 재지향된 URL의 전달 파라미터로서 포털 서버로부터 회신된 휴대가능 단말(504)의 MAC 주소를 휴대가능 단말(502)에 발신한다. 526에서, 휴대가능 단말(504)은 재지향된 URL로부터 MAC 주소 정보를 획득한다. 528에서, 휴대가능 단말(504)은 알리페이(Alipay™)와 같은 애플리케이션의 사용자 이름 및 암호를 무선 액세스 디바이스(506)에 제출한다. 530에서, 무선 액세스 디바이스는 애플리케이션 서버(514)에 포털 인증 요청(530)을 발신한다. 532에서, 애플리케이션 서버(514)는 신원 인증(532)을 수행한다. 534에서, 만약 신원 인증이 성공하는 경우, 애플리케이션 서버(514)는 무선 액세스 디바이스에 알린다. 536에서, 무선 액세스 디바이스(506)는 인증이 성공함을 휴대가능 단말(504)에 알린다. 538에서, 휴대가능 단말(504)은 그것의 MAC 주소 정보를 애플리케이션 서버(514)에 발신한다. 540에서, 애플리케이션 서버(514)는 MAC 주소 정보 및 사용자를 사용자 MAC 테이블로 세이브한다(save).

대응 관계 및 402부터 418까지의 동작으로써, 사용자 Tony가 알리페이(Alipay™)의 임의의 협조 상업자 내에서 무선 네트워크를 차후 사용하는 것이 꽤 편리하다. 사용자 Toney가 며칠 후 다시 상업자 B를 방문한다고 가정하면, 사용자 Tony는 상업자 B의 무선 네트워크를 찾기 위해 그의 스마트폰을 사용하고, 무선 네트워크로의 연결을 완료한다. 위에서 기술된 바와 같이, 상업자 B의 무선 네트워크로 연결되는 사용자의 동작은 402부터 406까지의 동작을 트리거한다. 알리페이(Alipay™) 서버 단말은 로컬 사용자 MAC 테이블(이는 이 경우에 표 2임) 내에서 검색하는 경우 MAC3를 사용하는 사용자가 Tony임을 발견하고 이후 애플리케이션 서버 단말은 사용자에게 인증 프롬프트 메시지를 푸시하기 위해 408로 넘어간다.

위에서 기술된 바와 같이, 알리페이(Alipay™) 서버 단말은 AC의 예외 사이트 리스트 내에 있는데, 따라서 알리페이 월렛(Alipay™ Wallet) 및 알리페이(Alipay™) 서버 단말 간의 상호 액세스는 비제한적이되, 애플리케이션 알리페이 월렛(Alipay™ Wallet)은 일반적으로 배후(background)에서 알리페이(Alipay™) 서버 단말과의 연결을 유지하여 중요한 데이터를 서로 적시에 송신한다. 따라서, 인증 프롬프트 메시지는 원활하게 사용자 Tony의 알리페이 월렛(Alipay™ Wallet)에 푸시될 수 있다. 그 메시지가 수신된 후, 알리페이 월렛(Alipay™ Wallet)은 (예컨대, 모바일 전화의 스크린의 최상부에 있는) 메시지 프롬프트 바 내에 인증 프롬프트 옵션을 출력하기 위해 대응하여 410에서 동작을 수행한다. 웨이보(Weibo™)와 같은 소셜 애플리케이션의 메시지 프롬프트 옵션의 설계 또는 다른 유사한 설계(이는 구체적으로 기술되지 않을 것임)가 옵션을 출력하는 데에 사용될 수 있는데, 이는 본 문서 내에 상술되지 않는다.

더 나은 프롬프트 효과를 달성하기 위해서, 알리페이 월렛(Alipay™ Wallet)은 또한 소리 또는 진동 프롬프트를 출력하여 대응하여 사용자를 상기시킬 수 있다. 사용자가 모바일 전화의 메시지 프롬프트 바 내에서 인증 프롬프트 옵션을 발견한 후, 사용자는 풀다운(pull-down) 및 클릭 동작을 수행함으로써 인증 프롬프트 옵션을 선택할 수 있다. 일단 인증 프롬프트 옵션이 선택되면, 알리페이 월렛(Alipay™ Wallet)은 사용자를 대신하여 포털 인증을 완료하기 위해 412에서 동작을 수행한다. 인증이 성공한 후, 사용자의 IP 주소는 AC의 화이트리스트에 추가될 것인데, 이 방식으로, 사용자는 포털 인증을, 거의 그것을 인지하지 않고서 통과하고, 인터넷을 액세스할 수 있다.

도시된 바와 같이, 임의의 알리페이(Alipay™) 사용자를 위해, 알리페이(Alipay™)의 협조 상업자의 무선 네트워크로의 첫 연결 동안에, 사용자는 포털 인증 프로세스를 트리거하기 위해 수동으로 브라우저를 열고 웹사이트에 들어갈 필요가 있다. 이후에, 사용자가 알리페이(Alipay™)의 임의의 협조 상업자에게 가고 성공적으로 무선 네트워크에 연결되는 경우, 사용자는 매우 짧은 시간 내에 인증 프롬프트를 수신할 것이고, 쉽게 포털 인증을 완료하기 위해 풀다운 및 클릭하기와 같은 동작을 수행함으로써 인증 프롬프트 옵션을 선택할 필요가 있을 뿐이다. 한편으로, 사용자는 웹사이트에 들어가기 위해 브라우저를 여는 것과 같은 비교적 복잡한 동작을 수행할 필요가 없다. 다른 한편으로, 사용자는 인증 프롬프트를 획득하므로, 그것은 사용자가 포털 인증을 수행하는 것을 잊지 않도록 하는데, 이는 포털 인증 기술에 친숙하지 않은 이들에게 더 의미가 있다.

전술한 구현에서, 설명은 사용자가 특정한 스마트폰을 사용하는 경우에 집중하는데, 이는 일반적으로 대다수의 사용자의 사용 수요를 충족시킬 수 있다. 본 개시는 사용자가 여러 휴대가능 단말을 사용하는 경우에 또한 적용가능하다. 사용자 Tony가 두 개의 스마트폰을 사용한다고 가정되는데, 여기서 모바일 전화 1의 MAC 주소는 MAC3이고 모바일 전화 2의 MAC 주소는 MAC256이다. 만약 전술한 사용 프로세스를 반복하기 위해 사용자 Tony가 모바일 전화 2를 사용하는 경우, 서버 단말은 한 사용자를 위해 하나의 고유한 테이블 엔트리(table entry)를 저장할 필요가 있을 뿐인데, 즉 Tony의 테이블 엔트리는 업데이트되고, Tony의 MAC 주소는 MAC256이도록 업데이트된다. 만약 Tony가 다시 모바일 전화 1을 사용하는 경우, Tony의 테이블 엔트리는 다시 리프레시된다(refreshed). 추가로, 만약 Tony가 알리페이 월렛(Alipay™ Wallet)을 더 이상 사용하지 않는 경우, 그것은 MAC3가 위치된 테이블 엔트리가 한참 동안 업데이트되지 않았음을 의미한다. 따라서, 이 테이블 엔트리는 사전설정된 에이징 메커니즘(aging mechanism)에 따라 삭제될 수 있다. 다시 말해, 만약 표 3 내의 세 번째 테이블 엔트리가 418에서 결코 업데이트되지 않거나 항목의 사전설정된 임계를 넘어서 업데이트되지 않는 경우, 사용자는 MAC 주소를 더 이상 사용하지 않는다고 추론될 수 있고, 따라서 이 테이블 엔트리는 삭제될 수 있다. 만약 Tony가 다시 이 MAC 주소를 사용하는(예컨대, 원래의 모바일 전화를 사용하는) 경우, 본 개시는 여전히 위에서 기술된 절차에 따라 정상적인 처리를 수행할 수 있다.

전술한 구현을 기반으로, 본 개시의 연동 메커니즘은 사용자 및 상업자 간의 연동을 가능하게 할 수 있다. 도 6을 참조하면, 도 6 내의 AC(602)(이의 디바이스 식별자는 AC100임)는 상업자(그의 상업자 식별자는 HDL임)와의 대응 관계를 갖는다. AC(602)는 상업자 HDL에 의해 구매되거나 임차된 디바이스일 수 있다. 즉, AC 및 상업자는 무선 서버 측 상에서 대응 관계를 가지고, 이 대응은 흔히 무선 서버(604)의 데이터베이스 내에, 표 4에 도시된 바와 같이, 저장된다.

606에서, AC(602)는 무선 서버(604)에 AC 식별(AC identification)을 포함하는 단말 연결 메시지를 발신한다. 608에서, 무선 서버(604)는 AC 식별에 따라 상업자 식별(merchant identification)을 검색한다. 610에서, 무선 서버(604)는 상업자 식별을 포함하는 연결 프롬프트 메시지를 알리페이(Alipay™) 서버 단말과 같은 애플리케이션 서버(612)에 발신한다. 614에서, 애플리케이션 서버(612)는 알리페이(Alipay™) 클라이언트 단말을 설치한 스마트폰과 같은 휴대가능 단말(616)에 상업자에 대응하는 제3자 애플리케이션 및/또는 상업자 식별에 대응하는 상업자의 서비스 정보를 포함하는 인증 프롬프트 메시지를 발신한다. 618에서, 휴대가능 단말(616)은 포털 인증이 성공한 후 대응하는 제3자 애플리케이션을 호출하고/하거나 서버 정보를 디스플레이한다. 618에서, 휴대가능 단말(616)은 포털 인증이 성공한 후 대응하는 제3자 애플리케이션을 호출하고/하거나 서비스 정보를 디스플레이한다. 휴대가능 단말(616)은 AP(618)를 통하여 AC(602)와 연결된다.

무선 서버는 단말 연결 메시지 내에 실린 AC 식별자, 즉 AC100에 따라 대응하는 상업자 식별자 HDL을 발견하고, 상업자 식별자 HDL을 연결 프롬프트 메시지에 추가하며, 그것을 알리페이(Alipay™) 서버 단말에 발신한다. 알리페이(Alipay™) 서버 단말은 서비스 정보 및/또는 제3자 애플리케이션 식별자(상업자 HDL에 대응함)를 저장한다. 구현의 측면에서, 알리페이(Alipay™) 서버 단말은 상업자 인터페이스 유닛을 더 포함할 수 있다. 상업자 인터페이스 유닛은 웹 서비스 윈도우일 수 있다. 상업자가 대응하는 기업 계정을 사용함으로써 로그인한 후, 상업자에 의해 구성된 서비스 정보 및 제3자 애플리케이션 식별자는 상업자 인터페이스 유닛에 발신되고, 상업자 인터페이스 유닛은 서비스 정보 및 제3자 애플리케이션 식별자를 상업자 정보 테이블 내에 저장한다. 상업자 HDL은 규칙적으로 또는 불규칙적으로 애플리케이션 서버 단말 상의 상업자 정보 테이블 내의 서비스 정보, 예를 들어 상품 판촉(commodity promotion) 정보 및 신착(new arrival) 정보를 업데이트하기 위해 상업자 인터페이스 유닛을 사용할 수 있다. 제3자 애플리케이션 식별자는 HDL 자체에 의해 개발된 주문 클라이언트(ordering client)와 같은, 상업자 HDL에 대응하는 애플리케이션 클라이언트 단말, 또는 HDL의 협력자에 의해 개발되고 HDL에 적용가능한, 타오바오(Taobao™) 앱과 같은 애플리케이션 클라이언트 단말의 식별자일 수 있다.

알리페이(Alipay™) 서버 단말의 푸시 관리 유닛은 대응하는 서비스 정보 및/또는 제3자 애플리케이션 식별자를 판정하기 위해 연결 프롬프트 메시지 내의 상업자 식별자 HDL에 따라 상업자 정보 테이블(도 5 내의 예를 참조함)을 검색한다. 푸시 관리 유닛은 발견된 서비스 정보 및/또는 제3자 애플리케이션 식별자를 인증 프롬프트 메시지에 추가하고, 인증 프롬프트 메시지를 알리페이 월렛(Alipay™ Wallet)에 푸시한다. 알리페이 월렛(Alipay™ Wallet)이 인증 프롬프트 메시지를 수신한 후, 알리페이 월렛(Alipay™ Wallet)의 푸시 처리 유닛은 서비스 정보를 인증 프롬프트 메시지로부터 획득하고 서비스 정보를 디스플레이한다. 예시적 실시예에서, 서비스 정보가 링크를 포함할 수 있고 사용자는 대응하는 사이트를 액세스하기 위해 링크를 클릭할 필요가 있으므로 포털 인증이 통과된 후에 푸시 처리 유닛은 서비스 정보를 디스플레이할 수 있다. 포털 인증이 통과되기 전에, 사용자는 그 사이트들을 그것들이 예외 사이트의 화이트리스트 내에 있지 않는 한 액세스할 수 없다.

만약 인증 프롬프트 메시지가 제3자 애플리케이션 식별자를 또한 전하는 경우, 푸시 처리 유닛은 스마트폰이 대응하는 제3자 애플리케이션을 로컬로(locally) 갖는지를 또한 체크할 수 있다. 만약 스마트폰이 로컬로 그 대응하는 제3자 애플리케이션을 갖는 경우, 푸시 처리 유닛은 그 제3자 애플리케이션을 시작한다. 만약 스마트폰이 로컬로 그 대응하는 제3자 애플리케이션을 갖지 않는 경우, 푸시 처리 유닛은 포기하거나, 사용자가 그 제3자 애플리케이션을 다운로드하는 것을 제안한다. 아래의 표 5를 참조하면, 사용자가 상업자 HDL의 무선 네트워크에 연결되는 프로세스 동안에, 사용자가 지체 없이 인증을 완료하는 것을 돕는 것 외에, 본 기법은 사용자가 늦지 않게 최신 상업자 서비스 정보를 편리하게 업데이트하였을 수 있도록 또한 상업자 HDL의 최신 서비스 정보를 사용자에게 디스플레이한다. 추가로, HDL이 식품 벤더이고 인증이 성공한 후 애플리케이션 클라이언트 단말을 기동하는 것에 의한 주문 클라이언트 단말 "HDL 주문"(HDL ordering)을 전개한다고 가정하면, 푸시 관리 유닛은 HDL에서 식사를 하려고 계획하고 있는 사용자의 셀프서비스 주문을 가능하게 한다. 그러한 서비스 정보의 디스플레이 및 제3자 애플리케이션의 호출이 상업자 HDL에서의 사용자의 소비 활동을 더욱 쉽게 만들고 소비자와 상업자 간의 소통의 비용을 감소시킨다는 데에는 의심의 여지가 없다.

표준적인 구성에서, 컴퓨팅 디바이스, 예를 들어 본 개시 내에 기술된 바와 같은 임의의 서버 또는 디바이스는 하나 이상의 중앙 처리 유닛(Central Processing Unit: CPU), 하나 이상의 입력/출력 인터페이스, 하나 이상의 네트워크 인터페이스, 그리고 메모리를 포함할 수 있다.

메모리는 컴퓨터 판독 매체 내의 비지속성 메모리(non-permanent memory), 랜덤 액세스 메모리(Random Access Memory: RAM) 및/또는 비휘발성 메모리(non-volatile memory), 예를 들어 판독 전용 메모리(Read Only Memory: ROM) 및 플래시 랜덤 액세스 메모리(플래시 RAM)과 같은 형태를 포함할 수 있다. 메모리는 컴퓨터 판독가능 매체의 일례이다.

컴퓨터 판독가능 매체들은 정보 저장을 구현하기 위해 임의의 방법 또는 기법을 사용할 수 있는 지속성 및 비지속성, 이동가능(movable) 및 비이동가능(non-movable) 매체들을 포함한다. 정보는 컴퓨터 판독가능 명령어, 데이터 구조, 소프트웨어 모듈 또는 임의의 데이터일 수 있다. 컴퓨터 저장 매체의 예는 위상 변화 메모리(Phase-Change Memory: PCM), 정적 랜덤 액세스 메모리(Static Random Access Memory: SRAM), 동적 랜덤 액세스 메모리(Dynamic Random Access Memory: DRAM), 다른 유형 RAM, ROM, 전기적 소거가능 프로그램가능 판독 전용 메모리(Electrically Erasable Programmable Read Only Memory: EEPROM), 플래시 메모리(flash memory), 내부 메모리(internal memory), CD-ROM, DVD, 광학 메모리(optical memory), 자기 테이프(magnetic tape), 자기 디스크(magentic disk), 임의의 다른 자기 저장 디바이스(magnetic storage device), 또는 컴퓨팅 디바이스에 의해 액세스가능한 정보를 저장할 수 있는 임의의 다른 비통신(non-communication) 매체를 포함할 수 있으나, 이에 한정되지 않는다. 본 문서 내에 정의된 바와 같이, 컴퓨터 판독가능 매체는 변조된 데이터 신호(modulated data signal) 및 반송파(carrier wave)와 같은 일시적(transitory) 매체를 포함하지 않는다.

용어 "포함하는"(including), "포함하는"(comprising) 또는 이의 임의의 변형은 복수의 구성요소를 포함하는 프로세스, 방법, 제품 또는 디바이스가 그 복수의 구성요소뿐만 아니라 명시적으로 열거되지 않은 임의의 다른 구성요소, 또는 그러한 프로세스, 방법, 제품 또는 디바이스를 위해 필수적이거나 내재적인 임의의 구성요소도 포함하도록 비배타적 포함(non-exclusive inclusion)을 나타낸다는 점에 유의하여야 한다. 더 이상의 제한 없이, 문구 "...을 포함하는"(including a ...)에 의해 정의된 구성요소들은 프로세스, 방법, 제품 또는 디바이스가 그 구성요소들 외에 다른 동일한 구성요소를 포함함을 배제하지 않는다.

통상의 기술자는 예시적 실시예들이 방법, 시스템 또는 컴퓨터 소프트웨어 제품의 형태로 제시될 수 있음을 이해할 것이다. 그러므로, 본 기법은 하드웨어, 컴퓨터 소프트웨어 또는 이들의 조합에 의해 구현될 수 있다. 추가로, 본 기법은 컴퓨터 실행가능 또는 컴퓨터 판독가능 명령어를 포함하는 (디스크, CD-ROM 또는 광학 저장 디바이스를 포함하나 이에 한정되지 않는) 하나 이상의 컴퓨터 저장 매체의 형태로 된 컴퓨터 소프트웨어 제품으로서 구현될 수 있다.

위의 설명은 본 개시의 예시적 실시예들을 기술하는데, 이는 본 개시를 한정하는 데에 사용되어서는 안 된다. 통상의 기술자는 본 기법에 대해 임의의 개정 또는 변형을 행할 수 있다. 본 기법의 사상 및 범주로부터 벗어나지 않고서 임의의 변경, 균등한 대체, 또는 개선이 본 개시의 청구항의 범주 하에 여전히 속할 것이다.

Claims

모바일 운영 체제 환경에서 동작하는 모바일 단말 디바이스로서,
프로세서와
애플리케이션이 저장된 메모리를 포함하고, 상기 애플리케이션은 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작을 수행하도록 하며, 상기 동작은
상기 모바일 단말 디바이스의 매체 액세스 제어(Media Access Control: MAC) 주소 정보를, 서버로부터 상기 MAC 주소 정보를 수신함으로써, 취득하는 것 - 상기 MAC 주소 정보는 상기 애플리케이션과 상기 서버 사이의 접속 전에는 상기 애플리케이션에 의해서 직접적으로 액세스 가능하지 않음 - 과,
상기 MAC 주소 정보를 애플리케이션 서버의 계정과 연관시키는 것과,
상기 애플리케이션이 상기 애플리케이션 서버에 로그인하는 사용자 이름 및 암호를 포털 인증(portal authentication)을 위한 사용자 이름 및 암호로서 사용하는 것을 포함하는
모바일 단말 디바이스.
제1항에 있어서,
상기 동작은 상기 서버에 의해 회신된 재지향된 URL(Uniform Resource Locator)로부터 상기 MAC 주소 정보를 획득함으로써 상기 MAC 주소 정보를 취득하는 것을 더 포함하되, 상기 MAC 주소 정보는 상기 재지향된 URL에 의해 전달되는 파라미터인
모바일 단말 디바이스.
제1항에 있어서,
상기 포털 인증을 위한 사용자 이름 및 암호는 브라우저(browser)의 애플리케이션 연관 컴포넌트(application associated component)에 의해 발신되는
모바일 단말 디바이스.
제1항에 있어서,
상기 동작은,
상기 포털 인증을 시작하기 전에 사용자에 의해 상기 애플리케이션이 로그인되는지를 체크하는 것과,
상기 애플리케이션이 로그인됨을 판정하는 것에 응답하여 상기 포털 인증을 개시하는 것과,
상기 애플리케이션이 로그인되지 않음을 판정하는 것에 응답하여 상기 애플리케이션에 로그인할 것을 상기 사용자에게 요청하는 로그인 인터페이스를 제시하는 것을 더 포함하는
모바일 단말 디바이스.
제1항에 있어서,
상기 동작은
상기 모바일 단말 디바이스의 메시지 프롬프트 바(message prompt bar) 내에 인증 프롬프트 메시지(authentication prompt message)에 대응하는 인증 프롬프트 옵션(authentication prompt option)을 출력하는 것을 더 포함하는
모바일 단말 디바이스.
제5항에 있어서,
상기 인증 프롬프트 메시지는 제3자 애플리케이션 식별자를 포함하고,
상기 동작은 상기 포털 인증이 성공한 후 상기 제3자 애플리케이션 식별자에 따라 대응하는 제3자 애플리케이션을 시작하는 것을 더 포함하는
모바일 단말 디바이스.
제6항에 있어서,
상기 제3자 애플리케이션은 상기 애플리케이션이 연결된 무선 네트워크와 연관된 상업자(merchant)에 대응하는
모바일 단말 디바이스.
제5항에 있어서,
상기 인증 프롬프트 메시지는 상업자에 대응하는 서비스 정보를 포함하고,
상기 동작은 상기 포털 인증이 성공한 후 상기 서비스 정보를 디스플레이하는 것을 더 포함하는
모바일 단말 디바이스.
제5항에 있어서,
상기 동작은 상기 인증 프롬프트 옵션이 사용자에 의해 선택됨을 판정한 후 상기 포털 인증을 개시하는 것을 더 포함하는
모바일 단말 디바이스.
제1항에 있어서,
상기 동작은 상기 MAC 주소 정보를 상기 애플리케이션 서버에 발신하는 것을 더 포함하는
모바일 단말 디바이스.
포털 인증 방법으로서,
프로세서와 애플리케이션이 저장된 메모리를 포함하고 모바일 운영 체제 환경에서 동작하는 모바일 단말 디바이스의 매체 액세스 제어(Media Access Control: MAC) 주소 정보를, 서버로부터 상기 MAC 주소 정보를 수신함으로써, 취득하는 단계 - 상기 MAC 주소 정보는 상기 애플리케이션과 상기 서버 사이의 접속 전에는 상기 애플리케이션에 의해서 직접적으로 액세스 가능하지 않음 - 와,
상기 MAC 주소 정보를 애플리케이션 서버의 계정과 연관시키는 단계와,
상기 애플리케이션이 상기 애플리케이션 서버에 로그인하는 사용자 이름 및 암호를 포털 인증을 위한 사용자 이름 및 암호로서 사용하는 단계를 포함하는
포털 인증 방법.
제11항에 있어서,
상기 MAC 주소 정보를 취득하는 단계는 상기 서버에 의해 회신된 재지향된 URL(Uniform Resource Locator)로부터 상기 MAC 주소 정보를 획득하는 단계를 포함하되, 상기 MAC 주소 정보는 상기 재지향된 URL에 의해 전달되는 파라미터인
포털 인증 방법.
제11항에 있어서,
상기 포털 인증을 위한 사용자 이름 및 암호는 브라우저의 애플리케이션 연관 컴포넌트에 의해 발신되는
포털 인증 방법.
제11항에 있어서,
상기 포털 인증을 시작하기 전에 사용자에 의해 상기 애플리케이션이 로그인되는지를 체크하는 단계와,
상기 애플리케이션이 로그인됨을 판정하는 것에 응답하여 상기 포털 인증을 개시하는 단계와,
상기 애플리케이션이 로그인되지 않음을 판정하는 것에 응답하여 상기 애플리케이션에 로그인할 것을 상기 사용자에게 요청하는 로그인 인터페이스를 제시하는 단계를 더 포함하는
포털 인증 방법.
제14항에 있어서,
상기 애플리케이션 서버에 의해 푸시된 인증 프롬프트 메시지를 수신하는 경우에 상기 모바일 단말 디바이스의 메시지 프롬프트 바 내에 상기 인증 프롬프트 메시지에 대응하는 인증 프롬프트 옵션을 출력하는 단계 ― 상기 인증 프롬프트 메시지는 제3자 애플리케이션 식별자를 포함하고, 제3자 애플리케이션은 상기 애플리케이션이 연결된 무선 네트워크와 연관된 상업자에 대응함 ― 와,
상기 포털 인증이 성공한 후 상기 제3자 애플리케이션 식별자에 따라 대응하는 제3자 애플리케이션을 시작하는 단계를 더 포함하는
포털 인증 방법.
제11항에 있어서,
상업자에 대응하는 서비스 정보를 포함하는 인증 프롬프트 메시지를 수신하는 단계와,
상기 포털 인증이 성공한 후 상기 서비스 정보를 디스플레이하는 단계를 더 포함하는
포털 인증 방법.
애플리케이션 서버에 의해 수행되는, 포털 인증 서비스 방법으로서,
단말 연결 메시지(terminal connection message) 내에 실린 모바일 운영 체제 환경에서 동작하는 모바일 단말 디바이스의 MAC 주소 정보를 획득하는 단계와,
상기 MAC 주소 정보를 재지향된 URL(Uniform Resource Locator)로서 상기 모바일 단말 디바이스에 회신하는 단계를 포함하는
포털 인증 서비스 방법.
제17항에 있어서,
사용자 MAC 테이블 내에서 상기 MAC 주소 정보에 대응하는 사용자를 검색하는 단계와,
상기 사용자가 발견된 후 상기 모바일 단말 디바이스에 인증 프롬프트 메시지를 푸시하는 단계와,
포털 인증 요청 내에 포함된 애플리케이션에 로그인하기 위한 상기 사용자의 사용자 이름 및 암호가 등록된 사용자에게 속하는지를 판정하는 단계와,
상기 포털 인증 요청에 로그인하기 위한 상기 사용자의 상기 사용자 이름 및 암호가 상기 등록된 사용자에게 속함을 판정하는 것에 응답하여 포털 인증이 성공함을 판정하는 단계와,
상기 MAC 주소 정보와 상기 등록된 사용자 간의 대응 관계로써 상기 사용자 MAC 테이블을 업데이트하는 단계를 더 포함하는
포털 인증 서비스 방법.
제18항에 있어서,
상기 단말 연결 메시지는 상기 모바일 단말 디바이스가 연결된 무선 액세스 디바이스에 대응하는 상업자 식별자(merchant identifier)를 포함하는
포털 인증 서비스 방법.
제19항에 있어서,
상기 상업자 식별자에 따라 로컬 상업자 정보 테이블(local merchant information table) 내에서 대응하는 서비스 정보를 검색하는 단계와,
사용자에게 상기 인증 프롬프트 메시지 내에 상기 서비스 정보를 발신하는 단계를 더 포함하는
포털 인증 서비스 방법.