TW201804396A - 交易金鑰之管理補充方法 - Google Patents

Abstract

本發明係揭露一種交易金鑰之管理補充方法，其係由交易管理伺服器主動確認行動裝置是否需要補充交易金鑰，並在需要補充交易金鑰時，藉由行動裝置與交易管理伺服器之間彼此雙向認證的要求與回應，使交易管理伺服器得以產生至少一組新交易金鑰傳送給行動裝置進行儲存更新，以作為下次交易使用之交易金鑰。本發明除了可主動偵測客戶端之行動裝置的剩餘交易金鑰數量之外，更在補充更新時採用客戶端與伺服端之雙向認證機制，並搭配訊息推播傳送連線認證訊息，強化了整個交易金鑰補充更新過程之安全性，進而降低交易資訊被偽冒或竄改的風險。

Description

交易金鑰之管理補充方法

本發明係有關一種利用行動裝置進行交易時所使用之安全性交易金鑰，特別是關於一種透過虛擬信用卡進行交易時所使用的交易金鑰之管理補充方法。

近年來隨著無線應用通訊技術的蓬勃發展，伴隨智慧型行動裝置的盛行，使用行動通訊裝置進行網路購物已蔚為一股風潮。而在不需使用現金、支票或信用卡的情況下，消費者可使用行動裝置支付各項服務或數位及實體商品的費用之行動支付亦日益普及。

目前常見的行動支付方式大致可分為四種類型：簡訊為基礎的轉帳支付、行動帳單付款、行動裝置網路支付（WAP）和非接觸型支付（NFC）等。以 NFC 行動支付為例，最早有Visa首 先發展出一套 Visa payWave 的功能，只要信用卡上有弧形圖案就可以透過感應的方式直接付款；接著電信商與銀行業者合作提出了 TSM 平台，來完成用行動電話進行付款的行動支付流程；當然手機作業系統的開發者也不會遺漏這塊，像是 Google 的 Android 利用雲端模擬晶片，發展出虛擬的主機卡模擬技術（Host Card Emulation，HCE），讓所有安裝Android 系統之行動裝置毋需更換 SIM 卡就能可以直接當電子錢包使用；當然蘋果公司（ Apple） 的 iOS 系統，則推出利用 Visa Token 的服務，把信用卡卡號變成虛擬的數字代碼，成為了新的Apple pay 付款並減少資料被盜取的風險。

由於採用HCE技術之行動支付愈來愈普及，國內也有數位皮夾應運而生，數位皮夾為一種安裝於智慧型行動裝置的應用程式，將手機結合金融卡與信用卡，使用者只要攜帶智慧型手機出門就可消費刷卡購物，連金融卡、信用卡等卡片都不需帶出門，且於數位皮夾中使用虛擬的數字代碼來替代原有的信用卡卡號，行動裝置或店家均不儲存卡片資訊，以避免信用卡卡號等資訊外洩風險，提高行動支付安全性。而在使用行動裝置利用數位皮夾中之虛擬卡進行感應刷卡的過程中，會使用支付憑證代碼（Token Pan）搭配使用一組一次性交易金鑰（session key）以送出交易並完成交易。

因此，如何能安全地於客戶端的行動裝置中提供感應刷卡所需之交易金鑰是非常重要的環節，有鑑於此，本發明遂針對此提出一種交易金鑰之管理補充方法，以提供更安全的交易平台。

本發明之主要目的係在提供一種交易金鑰之管理補充方法，其係主動偵測客戶端行動裝置交易金鑰數量，且在補充更新時採用客戶端與伺服端之雙向認證機制，並搭配訊息推播傳送連線認證訊息，以強化交易金鑰補充更新之安全性，降低行動支付上交易的風險，進而保障發卡端、消費者與商家之權益。

本發明之另一目的係在提供一種交易金鑰之管理補充方法，其所提供之金鑰係具有限制性的單次使用、期限及適用場域，且由交易管理伺服器負責管理、驗證、產生以及更新補充等。

為達到上述目的，本發明之交易交鑰管理補充方法係包括下列步驟：行動裝置提出一啟動補充要求傳送至交易管理伺服器，使交易管理伺服器對應啟動補充要求產生一回應要求給行動裝置提供目前裝置資訊；行動裝置再回傳所需之目前裝置資訊給交易管理伺服器，經其驗證無誤後產生至少一組新交易金鑰傳送給行動裝置進行儲存更新；完成更新的行動裝置係傳送一更新完成訊號給交易管理伺服器，以結束整個流程。

其中，在行動裝置提出啟動補充要求之步驟前，更包括由交易管理伺服器先確認行動裝置內之目前交易金鑰數量是否足夠，若目前交易金鑰之數量不足時，交易管理伺服器會主動傳送訊息通知行動裝置進行交易金鑰的補充。

再者，行動裝置在儲存更新新交易金鑰之步驟中，更包括：行動裝置對其內建之本地端函式庫（Native Library）進行更新此新交易金鑰資料之要求，再利用本地端函式庫進行解碼更新後回傳更新成功回應，使行動裝置之應用程式補充有新交易金鑰。因此，交易金鑰由交易管理伺服器派送至客戶端的行動裝置中，使行動裝置接收後可以直接使用。

底下藉由具體實施例配合所附的圖式詳加說明，當更容易瞭解本發明之目的、技術內容及其所達成之功效

由於採用HCE技術之行動支付，數位皮夾，係使用虛擬的數字代碼來替代原有的信用卡卡號，因此在使用行動裝置利用數位皮夾中之虛擬卡進行感應刷卡的過程中，會使用支付憑證代碼（Token Pan）搭配使用一組一次性交易金鑰（payment session key）以送出交易並完成交易，所以每次交易就會消耗一筆交易金鑰，因此交易金鑰的管理與補充更新就顯得相當重要，此部份之作業係由一交易管理伺服器來負責管理驗證等，且交易管理伺服器亦會管理每一組交易金鑰之參數、使用次數、期限以及使用場域。

第1圖係為本發明於進行交易金鑰之管理補充方法的系統架構示意圖以及第2圖為本發明之方法流程圖。請先如第1圖所示，首先，至少一行動裝置20中係已安裝有一數位皮夾之應用程式22，系統架構請參考第1圖上方，行動裝置20中安裝之數位皮夾係為可供執行虛擬卡進行行動支付的應用程式22，且其中所述之虛擬卡可代表不同之信用卡、金融卡、簽帳卡、儲值卡或電子票證智慧卡等實體卡片。一交易管理伺服器10為第三方平台，可以整合多家發卡端的數位卡片進行行動支付，讓使用者可以利用行動裝置進行刷卡結帳，不用再帶現金及卡片出門，更可因應發卡端各自的優惠方案而在應用程式22中選擇對應該家發卡端的虛擬卡進行支付動作。交易管理伺服器10與行動裝置20之間係透過網際網路或電信網路進行訊號連接。

在了解基本系統架構後，接續完整說明本發明於管理補充交易金鑰之各步驟，請同時參閱第1圖及第2圖所示，本發明係在交易管理伺服器10與行動裝置20之間進行訊號傳輸。首先如步驟S10所示，交易管理伺服器10會先確認行動裝置20之應用程式22內儲存尚未使用之目前交易金鑰數量是否足夠，並於目前交易金鑰之數量不足時，例如，目前交易金鑰之數量係低於一臨界數量時，代表目前交易金鑰之數量不足，此時，交易管理伺服器10會主動透過GCM（Google Cloud Messaging）傳送訊息通知行動裝置20要進行交易金鑰的補充更新流程，整段流程採用端到端（end to end）加密來傳送訊號。

接續如步驟S12所示，應用程式22會提出一啟動補充要求傳送至交易管理伺服器10，以請求進行交易金鑰之補充；如步驟S14所示，交易管理伺服器10對應此啟動補充要求產生一回應要求給行動裝置20，以請求應用程式22提供目前裝置資訊；行動裝置20之應用程式22在收到此回應要求後，如步驟S16所示，即對應回傳所需之目前裝置資訊給交易管理伺服器10，經交易管理伺服器10驗證無誤後，交易管理伺服器10即如步驟S18所示般，產生至少一組新交易金鑰傳送給行動裝置20，使行動裝置20可以進行如步驟S20所示之新交易金鑰的儲存更新；在行動裝置20完成更新後，如步驟S22所示，傳送一更新完成訊號給交易管理伺服器10；最後如步驟S24所示，交易管理伺服器10接收到此更新完成訊號後，結束整個流程。

再者，在前述步驟S20中，對新交易金鑰進行儲存更新之步驟係於行動裝置20中進行，可細分為幾個步驟，請同時參閱第2圖及第3圖所示，在行動裝置20中，如步驟S202所示，數位程式22對行動裝置20中內建之本地端函式庫（Native Library）發出更新此新交易金鑰資料之要求；本地端函式庫24接收到此要求後，如步驟S204所示，於本地端函式庫24中進行解碼更新後，如步驟S206，本地端函式庫24回傳更新成功回應給應用程式22，使行動裝置20之應用程式（數位皮夾）22補充更新此新交易金鑰，以供作為下次交易使用。當然，不管是至少一組交易金鑰或是複數組交易金鑰，皆是由交易管理伺服器10決定其數量，且交易金鑰或是新交易金鑰係為單次性使用金鑰（SUK），因此使用過的交易金鑰數量會愈來愈少，所以在行動裝置20之數位程式22內應該存放有幾組交易金鑰，剩多少組時要進行更新，皆是由交易管理伺服器10負責，且交易管理伺服器亦管理每一目前交易金鑰及新交易金鑰之參數、使用次數、期限以及使用場域，且由交易管理伺服器10負責管理、驗證、產生以及更新補充等。由於行動裝置20中所有交易金鑰皆由交易管理伺服器10派送至客戶端的行動裝置20中，使行動裝置20接收後可以直接使用，完全無須透過發卡端。

因此，本發明提出之交易金鑰管理補充方法係可主動偵測客戶端行動裝置之交易金鑰數量，且在其需要補充更新時，採用行動裝置與交易管理伺服端之雙向認證機制，並搭配訊息推播傳送連線認證訊息，以強化交易金鑰補充更新之安全性，並降低交易資訊被偽冒或竄改之風險，進而降低行動支付於交易上的風險，進而保障發卡端、消費者與商家等各家之權益。

以上所述之實施例僅係為說明本發明之技術思想及特點，其目的在使熟悉此項技術者能夠瞭解本發明之內容並據以實施，當不能以之限定本發明之專利範圍，即大凡依本發明所揭示之精神所作之均等變化或修飾，仍應涵蓋在本發明之專利範圍內。

10‧‧‧交易管理伺服器
20‧‧‧行動裝置
22‧‧‧應用程式
24‧‧‧本地端函式庫

第1圖係為本發明於進行交易金鑰之管理補充方法的系統架構示意圖。 第2圖係為本發明之方法流程圖。 第3圖係為本發明於行動裝置內更新交易金鑰的流程圖。

10‧‧‧交易管理伺服器

20‧‧‧行動裝置

22‧‧‧應用程式

24‧‧‧本地端函式庫

Claims (10)

1. 一種交易金鑰之管理補充方法，其係在至少一行動裝置與一交易管理伺服器之間進行訊號傳輸，該交易交鑰之管理補充方法包括下列步驟： 該行動裝置提出一啟動補充要求傳送至該交易管理伺服器，該交易管理伺服器對應該啟動補充要求產生一回應要求給該行動裝置提供目前裝置資訊； 該行動裝置回傳所需之該目前裝置資訊給該交易管理伺服器，經該交易管理伺服器驗證無誤後，即產生至少一組新交易金鑰傳送給該行動裝置儲存更新；以及 該行動裝置傳送一更新完成訊號給該交易管理伺服器，令該交易管理伺服器結束整個流程。
2. 如請求項1所述之交易金鑰之管理補充方法，其中在該行動裝置提出該啟動補充要求之步驟前，更包括：該交易管理伺服器確認該行動裝置內之目前交易金鑰數量是否足夠，於該目前交易金鑰之數量不足時，主動傳送訊息通知該行動裝置進行交易金鑰的補充。
3. 如請求項2所述之交易金鑰之管理補充方法，其中該目前交易金鑰係低於一臨界數量時，表示該目前交易金鑰之數量不足。
4. 如請求項2所述之交易金鑰之管理補充方法，其中傳送該訊息通知之步驟係採用端到端（end to end）加密來傳送訊號。
5. 如請求項1所述之交易金鑰之管理補充方法，其中在該行動裝置之儲存更新該新交易金鑰之步驟中，更包括： 該行動裝置對其內建之本地端函式庫（Native Library）進行更新該新交易金鑰資料之要求，以利用該本地端函式庫進行解碼更新後回傳更新成功回應，使該行動裝置更新該新交易金鑰。
6. 如請求項1所述之交易金鑰之管理補充方法，其中該行動裝置安裝有可供執行虛擬卡進行行動支付的應用程式。
7. 如請求項7述之交易金鑰之管理補充方法，其中虛擬卡係可代表信用卡、金融卡、簽帳卡、儲值卡或電子票證智慧卡。
8. 如請求項1所述之交易金鑰之管理補充方法，其中該至少一組新交易金鑰為複數組新交易金鑰時，由該交易管理伺服器決定其數量。
9. 如請求項2所述之交易金鑰之管理補充方法，其中該目前交易金鑰及該新交易金鑰係為單次性使用金鑰（SUK）。
10. 如請求項2所述之交易金鑰之管理補充方法，其中該交易管理伺服器係管理每一該目前交易金鑰及該新交易金鑰之參數、使用次數、期限以及使用場域。