TW201725543A - 跨應用程式之交易方法 - Google Patents

Abstract

一種跨應用程式之交易方法，其係首先利用一使用者點擊其行動裝置中之第一應用程式以進行交易，之後，由此第一應用程式喚醒一同時安裝於此行動裝置之第二應用程式，以將一付款通知傳送予第二應用程式。之後，第二應用程式係傳送一驗證訊息至與其連線之一伺服器，並由伺服器驗證第一應用程式是否具有合法呼叫第二應用程式之權限。若是，則伺服器係將驗證結果回傳至第二應用程式，使得使用者可經由第二應用程式接收付款通知，以完成交易。至於，若第一應用程式不具有合法呼叫第二應用程式之權限時，則伺服器係回應驗證失敗，並中止傳送付款通知，以結束交易。藉此，本發明有效解決習見行動支付常有安全性薄弱且整體建置成本過高之問題。

Description

跨應用程式之交易方法

本發明係有關於一種行動支付方法，特別是一種利用行動裝置內之應用程式相互呼叫以進行交易之支付方法。

按，近年來，隨著商業模式與商品交易之模式越來越成熟，故自動化交易以及C2C（Consumer to Consumer）的交易模式也越來越容易使消費者接受。一般而言，現行所常見的商業交易付款方法，主要係包括有：現金支付、支票支付、信用卡（Credit card）支付、RFID小額付款（例如悠遊卡）、實體金融卡轉帳、或是借記卡（Debit card）支付等等。其中，隨著現代人日漸講求簡便與快速之需求，現金交易已逐漸成為小眾，而大多數民眾皆喜好採取使用簡易卡片進行交易的方式。不過，值得注意的是，由於卡片數量太多容易有管理不易且遺失的問題，並且，使用卡片的風險亦太高，容易有被偽造及盜用之問題，緣此，習知現有的交易方法顯然已經無法滿足上述簡便、快速與安全性之需求，而亟具有值得改進之空間。

更進一步而言，若以現代人最常使用的小額付款而言，當消費者使用手機付款時，目前市面上的技術多是將非接觸式晶片（RFID）嵌入手機之背板，但缺點在於，此種RFID非接觸式的感應極容易受到無線訊號的干擾，並且，店家與消費者均必須持有特殊規格的裝置，方可進行訊號的發送及讀取，於此，將造成整體建置的成本過高，將不利於整體使用。至於，若直接在手機的SIM卡中產生一加密及動態的密碼，再將此密碼作為交易的憑證，則缺點則在於需要由工程師修改手機內部的晶片與讀卡裝置，不僅在成本及推行上都有一定的阻礙。又抑或，現有技術亦提出一種可利用網路進行SSL加密認證的付款方法，然而此種方法亦存在有其缺失，也就是若被有心人士擷取其內容，並且破解密碼時，則交易即存在著極大的風險。除此之外，認證能力薄弱，無法確認消費者之唯一性，亦為現有技術迄今無法克服的重大課題之一。

緣是，為了解決上述習知技術存有的眾多缺失，本發明人係有感該些諸多缺點之可改善，且依據多年來從事此方面之相關經驗，悉心觀察且研究之，並配合學理之運用，而提出一種設計新穎且有效改善上述缺失之本發明，其係揭露一種可透過消費者本身手機內之應用程式相互呼叫，以進行交易並提升行動支付安全性之方法，其係能輕易取代現有付款方法的交易模式，有關本發明具體之架構及實施方式將詳述於下。

為解決習知技術存在的問題，本發明之一目的係在於提供一種跨應用程式之交易方法，其係針對現行常見的行動支付行為作一改良，此改良之處可大幅地助長於本發明有效提升行動支付安全性之較佳功效。根據本發明之實施例，利用本發明所揭露之此種交易方法，係主要利用消費者手持之行動裝置，藉由其內部至少二應用程式之間的溝通與呼叫，以完成卡片支付資訊的取得，藉此解決習見行動支付安全性薄弱且整體建置成本過高之問題。

承上所述，本發明係揭露一種跨應用程式之交易方法，其係包括以下步驟：首先，一行動裝置中係安裝有一第一應用程式與一第二應用程式；一使用者點擊此行動裝置中之第一應用程式以進行交易；由第一應用程式喚醒第二應用程式，並傳送一付款通知予第二應用程式；之後，第二應用程式係傳送一驗證訊息至與其連線之一伺服器，並由此伺服器驗證第一應用程式是否具有合法呼叫第二應用程式之權限。當第一應用程式具有合法呼叫第二應用程式之權限時，則伺服器係將驗證結果回傳至第二應用程式，使得使用者可經由第二應用程式接收付款通知，以完成交易。至於，若第一應用程式不具有合法呼叫第二應用程式之權限時，則伺服器係回應驗證失敗，並中止傳送付款通知，以結束交易。

其中，根據本發明之實施例，在使用者接收付款通知進行交易後，更包括步驟：使用者透過第二應用程式選擇支付方式及卡片；由第二應用程式產生支付之相關資訊回傳至第一應用程式；以及，第一應用程式將支付之相關資訊與交易資訊轉為一授權交易，並將授權交易傳送至一收單代理機構，使得收單代理機構組成授權訊息予使用者的發卡行，以由發卡行進行授權作業。

更進一步而言，在發卡行進行授權作業之步驟後，發卡行係可回應一授權結果至收單代理機構，之後，再由收單代理機構轉送至第一應用程式與第二應用程式，以供使用者瞭解交易結果。再者，使用者亦可利用第二應用程式執行轉帳交易、餘額查詢交易、繳費稅、行動提款等交易之行為，並透過第二應用程式進行狀態查詢，以確保交易成功完成。

其中，根據本發明之實施例，行動裝置中所安裝之第一應用程式係可為一服務供應程式（SP），而第二應用程式係可為一電子錢包，在此情況之下，與第二應用程式連線並提供驗證結果的伺服器則係為一數位皮夾管理者（Wallet Server），以針對電子錢包進行連線及訊息的傳遞。

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

以上有關於本發明的內容說明，與以下的實施方式係用以示範與解釋本發明的精神與原理，並且提供本發明的專利申請範圍更進一步的解釋。有關本發明的特徵、實作與功效，茲配合圖式作較佳實施例詳細說明如下。

有鑑於習知行動支付方式不僅繁瑣、建置成本過高，且容易有消費者資料外洩或安全性不夠之問題，本發明人乃憑藉著多年的實務經驗，在經過多次實驗及研究後，終於設計出本發明之一種利用行動裝置中至少兩個應用程式相互呼叫，以完成溝通與驗證之支付方法，期能藉此解決習知行動支付方法的諸多問題與不便。以下，為詳細解釋本發明所實施之系統架構及步驟流程，請參閱第1圖及第2圖所示。

首先，第1圖係揭露本發明實施例交易方法之系統架構示意圖，根據本發明之實施例，此種交易方法係為一種應用於相同之行動裝置內，以透過跨應用程式來進行交易的操作流程，如第1圖所示，本發明之系統架構中係包括有：使用者100、行動裝置200、收單代理機構300、發卡行400、授權轉接中心500、伺服器600、第一應用程式202以及第二應用程式204。其中，各個角色皆有其相對應之作業，本發明係先針對各個角色之作業分工說明如下。

使用者100泛指一般行動裝置200的持有者，在本發明所揭露的行動支付環境下，行動裝置200例如可為一攜帶型電腦（Notebook）、個人數位助理（Personal Digital Assistant，PDA）或智慧型手機（Smart phone），且行動裝置200內係安裝有第一應用程式202以及第二應用程式204。在本發明之實施例中，此第一應用程式202係可為一服務供應程式（SP），大抵而言，第一應用程式202係為一種由行動裝置200之服務供應商所提供之應用程式，例如：自來水繳費應用程式、台灣電力公司線上繳費應用程式、中華電信線上繳費應用程式、104年所得稅繳費應用程式、或國泰世華網路銀行服務應用程式等等。另一方面而言，行動裝置200內安裝之第二應用程式204則係可為一電子錢包，例如：數位皮夾APP，此電子錢包係連線至伺服器600。在此情況下，則伺服器600即可視為一數位皮夾管理者，以透過此角色進行與電子錢包之連線與訊息傳遞。

另一方面而言，根據本發明之實施例，收單代理機構300則係指與上述之第一應用程式202之服務供應商存在有合作關係之金融機構，其係集中收送第一應用程式202之服務供應商的授權交易，以透過此角色進行交易的繞送。發卡行400則係為使用者100所持有卡片之發行者，例如各家銀行業者，其主要係針對交易後端進行相關的檢核作業，並且依據使用者100之交易行為進行後續的授權作業審核。其中，值得一提的是，當收單代理機構300與使用者100之發卡行400若屬不同銀行時，則交易行為必須經由一授權轉接中心500來負責交易的繞送。相對地，若收單代理機構300與使用者100之發卡行400係隸屬於同一銀行時，則無須授權轉接中心500作為媒合的中介角色。

在解釋完本發明實施之系統架構中的各個角色後，本發明係接續針對使用者操作界面與交易流程之間的搭配進行更詳盡的說明，其中，有關本發明所揭露之跨應用程式之交易方法，其實施之流程步驟示意圖，請一併參閱第2圖所示。

請參考步驟S202所示，首先，行動裝置200中係同時安裝有如前所述之第一應用程式202與第二應用程式204。之後，如步驟S204所示，使用者100係操作行動裝置200，並且點擊其中之第一應用程式202以進行交易，如前所舉例，此交易內容例如可包括：繳納水費、電費、所得稅、或者進行線上轉帳、餘額查詢或行動提款等等。根據本發明之實施例，由於第一應用程式202與第二應用程式204間係設計為可相互溝通連結的，因此，如步驟S206所示，第一應用程式202係開始喚醒第二應用程式204，並且將對應使用者100所建立之付款通知傳送至第二應用程式204。

之後，如步驟S208所示，當第二應用程式204被喚醒之後，其係先傳送一待驗證訊息至與之連線之伺服器600，並且如步驟S210所示，再由伺服器600驗證第一應用程式202是否具有合法呼叫第二應用程式204之權限。因此，根據本發明之實施例，如步驟S212所示，其中若伺服器600驗證第一應用程式202的確具有合法呼叫第二應用程式204之權限，則伺服器600係將驗證結果回傳至第二應用程式204，使得使用者100可直接經由操作第二應用程式204接收付款通知，以完成交易。舉例來說，若伺服器600驗證第一應用程式202與第二應用程式204二者皆係為合法的應用程式，又同為iOS環境時，則此時伺服器600將回傳相對應的網頁位址（Uniform Resource Locator，URL）。至於，若伺服器600驗證第一應用程式202與第二應用程式204係為Android環境時，則回傳驗證成功與否。另一方面而言，如本發明步驟S214所示，至於當伺服器600驗證第一應用程式202並不具有合法呼叫第二應用程式204之權限時，則伺服器600係回應驗證失敗，並中止傳送該付款通知，以直接結束交易，藉此達到本發明維護消費者單一性與其資訊之機密的優勢。

接著，請參閱第3A圖與第3B圖所示，其係揭露本發明不同實施例之付款通知之示意圖，其中當第一應用程式202係為一繳費稅應用程式時，則在此情況下，付款通知係如第3A圖所示，包括有一付款交易中心之名稱（例如：台灣電力公司）、交易金額（1800元）、交易明細（例如：電費繳納）、以及交易日期與時間（2015/05/01 09：00：00）等訊息。因此，當使用者100利用第二應用程式204成功接收到付款通知時，即可自行決定是否進行付款、何時進行付款、以及選擇自行想要進行付款的方式。在本發明之另一實施例中，當第一應用程式202係為一網路銀行或網路ATM應用程式時，則在此情況下，付款通知係如第3B圖所示，包括有：付款交易中心之名稱（例如：國泰世華網路銀行）、交易金額（1800元）、交易明細（例如：轉帳交易）、以及交易日期與時間（2015/05/01 09：00：00）等訊息。同樣地，故當使用者100利用第二應用程式204成功接收到付款通知時，則亦可自行決定是否進行付款、何時進行付款、以及選擇自行想要進行付款的方式。

更進一步而言，請參閱第4圖所示，在使用者決定欲執行付款後，如步驟S402所示，使用者100首先可透過行動裝置200之第二應用程式204選擇欲支付方式及卡片，其詳細之示意圖可參閱第5圖，使用者100可自行選擇欲使用VISA卡1、MASTER卡2、JCB卡3 、AE卡4、行動金融卡5、銀行帳戶6，並在點擊「使用」後成功選取該張卡片進行交易。之後，如步驟S404所示，再由第二應用程式204產生支付之相關資訊回傳至第一應用程式202。其中，根據本發明之實施例，第二應用程式204係可依據使用者100所選定的卡片，產生並組成一跨應用程式（Cross APP）付款通知訊息，並將此訊息回傳給第一應用程式（服務供應商APP）202。最後，如步驟S406所示，第一應用程式202再將支付之相關資訊與交易資訊轉為一符合授權交易之規格，並將其傳送至收單代理機構300，以供收單代理機構300組成授權訊息予使用者100的發卡行400，續由發卡行400進行授權作業。值得說明的是，當收單代理機構300與使用者100之發卡行400隸屬於不同銀行時，則交易行為必須經由授權轉接中心500來負責交易的繞送。相對地，若收單代理機構300與使用者100之發卡行400係隸屬於同一銀行時，則授權訊息可直接傳送至使用者100之發卡行400，而無須授權轉接中心500作為媒合的中介角色。

之後，當發卡行400成功完成授權作業後，則使用者100即可利用其行動裝置200上所安裝之第二應用程式204而執行轉帳、餘額查詢、繳費稅、行動提款等交易，而無須鍵入任何個人金融資訊於網路上之任何機構或中心，藉此達到本發明保護消費者機密與維持安全性之目的。最後，發卡行400亦可回應一成功授權的結果至收單代理機構300，再由收單代理機構300轉送至行動裝置200之第一應用程式202與第二應用程式204上，如第6圖所示，則利用本發明所揭露之交易方法，不僅可確保交易被成功完成，留待使用者100瞭解交易結果，除此之外，使用者100亦可透過行動裝置200上之第二應用程式204進行後續的狀態查詢，以針對交易行為及後續處理進行有效追蹤。

是以，綜上所述，本發明所提出之跨應用程式之交易方法，主要係透過使用者操作單一行動裝置，以由行動裝置中之其一應用程式先提供服務界面操作，之後，利用此應用程式喚醒另一應用程式接收付款資訊，並使得消費者之卡片管理與相關安全元件可進行溝通，待取得卡片支付相關資訊時，則透過相關平台（例如iOS或Android）所提供的技術，來進行二者之間應用程式的呼叫與溝通。緣此，利用本發明所揭露之跨應用程式之交易方法，消費者之金融資訊（包括信用卡卡號、帳號、密碼等）皆無須曝露在公開的操作裝置或網際網路上，故不至於有遭受網路駭客盜取之風險，不僅兼具保護消費者之敏感性資訊之優勢，更可有效率地提高行動支付之安全層級。是以，相較於習知技術，本發明所揭露之技術思想，顯然具有較佳之使用效率、產業發展性與廣於發展之潛力，應具備足夠之新穎性與進步性。

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

100‧‧‧使用者
200‧‧‧行動裝置
202‧‧‧第一應用程式
204‧‧‧第二應用程式
300‧‧‧收單代理機構
400‧‧‧發卡行
500‧‧‧授權轉接中心
600‧‧‧伺服器
1‧‧‧VISA卡
2‧‧‧MASTER卡
3‧‧‧JCB卡
4‧‧‧AE卡
5‧‧‧行動金融卡
6‧‧‧銀行帳戶

第1圖係為根據本發明實施例之系統架構示意圖。 第2圖係為根據本發明實施例跨應用程式之交易方法之步驟流程圖。 第3A圖及第3B圖係為根據本發明實施例之付款通知之示意圖。 第4圖係為根據本發明實施例使用者執行付款之步驟流程圖。 第5圖係為根據本發明實施例選擇支付方式及卡片之示意圖。 第6圖係為根據本發明實施例成功授權結果之示意圖。

Claims (11)

1. 一種跨應用程式之交易方法，包括以下步驟： 提供一行動裝置，其中該行動裝置中安裝有一第一應用程式與一第二應用程式； 一使用者點擊該行動裝置之該第一應用程式以進行交易； 由該第一應用程式喚醒該第二應用程式，並傳送一付款通知予該第二應用程式；以及 該第二應用程式係傳送一驗證訊息至與其連線之一伺服器，並由該伺服器驗證該第一應用程式是否具有合法呼叫該第二應用程式之權限： 若是，則該伺服器係將驗證結果回傳至該第二應用程式，使該使用者可經由該第二應用程式接收該付款通知，以完成交易；以及 若否，則該伺服器係回應驗證失敗，並中止傳送該付款通知，以結束交易。
2. 如請求項1所述之跨應用程式之交易方法，其中在該使用者接收該付款通知後，更包括步驟： 該使用者透過該第二應用程式選擇支付方式及卡片； 由該第二應用程式產生支付之相關資訊回傳至該第一應用程式；以及 該第一應用程式係將支付之相關資訊與交易資訊轉為一授權交易，並將該授權交易傳送至一收單代理機構，使得該收單代理機構組成授權訊息予該使用者的發卡行，由該發卡行進行授權作業。
3. 如請求項2所述之跨應用程式之交易方法，其中該授權訊息係直接傳送或間接透過一授權轉接中心而傳送至該使用者之發卡行。
4. 如請求項2所述之跨應用程式之交易方法，其中在該發卡行進行授權作業之步驟後，該發卡行係回應一授權結果至該收單代理機構，再由該收單代理機構轉送至該第一應用程式與該第二應用程式，以供該使用者瞭解交易結果。
5. 如請求項1所述之跨應用程式之交易方法，其中該付款通知包括提供一付款交易中心之名稱、交易金額、交易明細、以及交易時間之訊息。
6. 如請求項5所述之跨應用程式之交易方法，其中在該發卡行完成授權作業之步驟後，該使用者係可利用該第二應用程式執行轉帳交易、餘額查詢交易、繳費稅、行動提款等交易之行為。
7. 如請求項1所述之跨應用程式之交易方法，其中該行動裝置係可為一攜帶型電腦、個人數位助理或智慧型手機。
8. 如請求項6所述之跨應用程式之交易方法，其中該使用者更可透過該第二應用程式進行狀態查詢，以確保交易成功完成。
9. 如請求項1所述之跨應用程式之交易方法，其中該行動裝置之該第一應用程式係為一服務供應程式。
10. 如請求項1所述之跨應用程式之交易方法，其中該行動裝置之該第二應用程式係為一電子錢包。
11. 如請求項10所述之跨應用程式之交易方法，其中該伺服器係為一數位皮夾管理者，其係進行與該電子錢包之連線及訊息傳遞。