TW201814606A

TW201814606A - 使用現代圖碼技術於行動商務平台上應用，透過行動裝置作為身分識別及行動商務支付活動的方法

Info

Publication number: TW201814606A
Application number: TW105133161A
Authority: TW
Inventors: 何駿逸
Original assignee: 何駿逸
Priority date: 2016-10-14
Filing date: 2016-10-14
Publication date: 2018-04-16

Abstract

透過打造一個行動商務平台，藉由現代圖碼(Picture Code)，即利用目前所常見使用的條碼，如：堆疊式二維條碼以及矩陣式二維條碼，結合現行還在開發之新技術，組合出更新，圖形更複雜且資料儲存量更大之圖碼當作介質，透過網路之連結，以現代資訊商務發展活動的應用模式為基礎，套用本發明之應用模型，作為對於個人使用者的身分驗證，以及個人消費者於現代資訊商務發展活動之「電子錢包」及「電子商務」、「第三方支付」乃至「C2C」在使用信用卡的應用上，透過使用智慧型手機或行動裝置，作為現代另一新的「行動支付」方法。

Description

使用現代圖碼技術於行動商務平台上應用，透過行動裝置作為身分識別及行動商務支付活動的方法

本發明係透過打造

1. 一個行動商務平台，

2. 藉由現代圖碼(Picture Code)，即利用目前所常見使用的條碼，如：堆疊式二維條碼以及矩陣式二維條碼，結合現行還在開發之新技術，組合出更新，圖形更複雜且資料儲存量更大之圖碼當作介質，

3. 透過網路之連結，

4. 經由使用智慧型手機或行動裝置，作為現代對於個人使用者的身分驗證，以及另一新的「行動支付」方法式。

5. 以現代資訊商務發展活動的應用模式為基礎，套用本發明之應用模型，作為對於現代資訊商務發展活動之「電子錢包」及「電子商務」、「第三方支付」乃至「C2C」在使用信用卡的應用上之方法。

1. 行動商務平台。

2. 現代圖碼(Picture Code)。

即利用目前所常見使用的條碼，如：堆疊式二維條碼以及矩陣式二維條碼，結合現行還在開發之新技術，組合出更新，圖形更複雜且資料儲存量更大之圖碼當作介質。

3. 網路之連結。

4. 智慧型手機或行動裝置。

5. 以現代資訊商務發展活動的應用模式為基礎，套用本發明之應用模型，作為對於現代資訊商務發展活動之應用方法。

本發明乃依據現代資訊商務發展活動模式並根據其資料流程，發展出一套利用「智慧型行動輸入裝置」及「圖碼掃描讀取接受裝置」，並透過依照本發明專利說明書的發明內容中之「行動商務平台」，發展出一套對資訊傳輸身分認證與利用實體卡片的商務支付交易活動之「應用模型」。

應用模型說明如下：

1. 外在環境：

網路暢通並且輸出、接受設備皆可與行動商務平台及後台主機系統及時連線。

2. 以現代圖碼為介質之行動商務平台：

(1)輸入裝置：智慧型手機、PAD..等。

(2)接受裝置：

圖碼掃描讀取器、智慧型手機+POS機、收銀機、PC..等。

(3)行動商務平台

A. 登入安全機制模

登入時，使用者或接受者除了使用基本之號及密碼外，期望未來能夠發展出人臉及指紋辨識，以提高安全性。

當使用者或接受者登入後，行動商平台上出現選擇「使用者要求」或「接受者驗證」選項。點選「使用者要求」或「接受者驗證」選樣後，即進入「使用者要求」系統或是「接受者驗證」系統。

B. 使用者要求系統

(A)選擇使用卡片單位模組

登入使用者要求系統後，行動商務平台畫面即提供依使用者當時所設定之使用卡片或使用單位(類似電子卡片皮夾)，如：健保卡、商店會員卡、銀行金融卡、悠遊卡、信用卡..等之畫面。

使用者依自己本身需求點選使用之卡片後，即與發卡使用單位自動連線，同時也進入發卡使用單位網頁之個人帳戶。

(B)輸入畫面模組

進入欲要求之發卡使用單位之輸入畫面後，(輸入畫面實則是在發卡使用單位的後台主機系統上所提供，透過本行動商務平台輸入畫面模組將發卡使用單位之輸入畫面完全呈現，此時輸入畫面模組同時記錄相關之時間資訊，做為圖碼驗證模組之安全控管及驗證依據)，並依發卡使用單位畫面所提供之選項輸入使用者欲要求或輸入之資訊與數據。

(C)圖碼產生器模組

發卡使用單位的後台主機系統接收使用者欲要求或輸入之資訊與數據後，將所需之資訊及認證相關資訊傳輸至行動商務平台之圖碼產生器轉換模組。圖碼產生器依要求或輸入之資訊與數據轉換成圖碼，並利用其加密之模組將其加密，(如對卡號之第4，6，12碼以其他代碼表示並轉換為圖碼)，其圖碼內容將包括：

a. 圖碼產生之序號

b. 發卡使用單位代號

c. 使用者基本資訊(如：卡號..)

d. 要求或輸入之資訊與數據

e. 要求輸入資訊之日期，時間

f. 發卡使用單位之驗證號碼

g. 輸入畫面時間點

h. 經由使用者或系統自動設定之圖碼有效時間..等。

當產生圖碼後，再回傳至發卡使用單位的後台主機系統。

(D)輸出畫面模組

發卡使用單位的後台主機系統收到由行動商務平台之圖碼產生器所產生之圖碼後，透過行動商平台之輸出畫面模組呈現於使用者之行動裝置(輸出畫面依舊是在發卡使用單位的後台主機系統上所提供，只是透過本行動商務平台輸出畫面模組將發卡使用單位之輸出畫面完全呈現)。

(E)圖碼驗證模組

此時發卡使用單位的後台主機系統，同時傳輸訊息給行動商務平台之圖碼驗證模組，告知其圖碼等待驗證。

C. 接受者驗證系統

(A)固定連結接受使用單位/非固定連結接受使用單位模組

接受者通過登入安全機制認證登入後，點選行動商平台上「接受者驗證」系統之選項即進入「接受者驗證」系統。此時，行動商務平台畫面即出現提供「固定連結接受使用單位」或「非固定連結接受使用單位」選項，選擇：

a. 「固定連結接受使用單位」：

接受者當時所設定之接受者使用單位，長時間並固定連接並只接受來自接受者設定接受的發卡使用單位所產生的圖碼(通常為使用者與接受者為同一發卡使用單位)。

b. 「非固定連結接受使用單位」：

選擇此選項乃因接受者使用單位將可接受來自多發卡使用單位所產生的圖碼。

(B)輸入畫面模組

接受者經由「固定連結接受使用單位」或「非固定連結接受使用單位」選擇後，進入依接受者當時所設定之接受使用單位之輸入畫面，(輸入畫面則是在接受者設定使用單位的後台主機系統上所提供，只是透過此商務平台輸入畫面模組呈現)等待圖碼掃描。

(C)圖碼分析模組

圖碼經由輸入畫面掃描輸入後，將進入圖碼分析器模組並依其選項分析判斷：

a. 「固定連結接受使用單位」：

判斷圖碼是否來自接受者設定接受之發卡使用單位。

若是來自接受者設定接受發卡使用單位，則將圖碼及相關資訊(如經由輸入畫面模組所記載之時間點、發卡單位號碼..等)繼續後傳至接受者所設定接受者使用單位後台主機系統。

若不是來自接受者設定接受之發卡使用單位，則不接受，並發出錯誤訊息，同時傳輸至接受者所設定之接受者使用單位後台主機系統並經行動商平台輸出畫面模組呈現於輸出裝置。

b. 「非固定連結接受使用單位」：

分析圖碼是來自於何處發卡使用單位所產出的。

若是來自與接受者設定之接受使用單位相同，則將圖碼及相關資訊(如經由輸入畫面模組所記載之時間點、發卡單位號碼..等)繼續後傳至接受者所設定接受者使用單位後台主機系統。

若是來自與接受者設定之接受使用單位不相同，則將其將圖碼、發卡單位之代碼與相關資訊(如經由輸入畫面模組所記載之時間點、發卡單位號碼..等)回傳至接受者所設定之接受者使用單位後台主機系統。

接受者設定之接受使用單位後台主機系統在接受由圖碼分析模組所傳回之圖碼與相關資訊後，將依圖碼模組所分析之發卡單位號碼，將其圖碼及相關資訊及要求傳輸至原發卡使用單位。

(D)圖碼驗證模組

原發卡使用單位(在選擇「固定連結接受使用單位」狀況下，原發卡使用單位與接受者所設定接受者使用單位二者相同)接收到來自接受者所設定接受者使用單位後台主機系統傳來之圖碼與相關資訊後，將圖碼傳輸至行動商務平台之圖碼驗證模組對其加以驗證。

圖碼驗證模組收到圖碼後，將依其當時原發卡使用單位對圖碼產生器要求所產生之圖碼予以解碼，並根據當時所產生之相關資訊：

a. 圖碼產生之序號

b. 發卡使用單位代號

c. 使用者基本資訊(如：卡號..)

d. 要求或輸入之資訊與數據

e. 要求輸入資訊之日期，時間

f. 發卡使用單位之驗證號碼

g. 輸入畫面時間點

h. 經由使用者或系統自動設定之圖碼有效時間..等，加以驗證。

經由驗證確認無誤後，圖碼驗證模組傳輸確認訊息至原發卡使用產生圖碼單位。原發卡使用產生圖碼單位再將完全接受訊息、相關訊息及回復傳輸至接受者所設定接受者使用單位。

當原發卡使用產生圖碼單位將需要之資訊與資料成功傳輸至接受者所設定接受者使用單位後，原發卡使用產生圖碼單位同時傳輸訊息給行動商務平台之圖碼驗證模組，告知其圖碼已完成有效驗證，圖碼驗證模組將對相同之圖碼的第二次驗證視為無效。

(E)輸出畫面模組

接受者所設定接受者使用單位的後台主機系統收到由原發卡使用單位所產生的圖碼完全接受的資訊後，則產生接受需要之資訊與資料，透過行動商平台輸出畫面模組(輸出畫面依舊是在接受者所設定接受者使用單位的後台主機系統上所提供，只是透過本行動商務平台輸出畫面模組將發卡使用單位之輸出畫面完全呈現)傳送並呈現於接受者之接受裝置。

D. 輸出入畫面模組時間記錄分析比對模組

記錄行動商務平台上：

a. 「使用者要求」系統

(a)輸入畫面模組之最終時間

(b)輸出畫面模組之最終時間

b. 「接受者驗證」系統

輸入畫面模組之最終時間

當圖碼經過驗證模組驗證完成後，確定無誤，判定為可接受後，會再進入輸出入畫面模組時間記錄分析比對模組，對於上述之「使用者要求」與「接受者驗證」二系統中之輸出入畫面最終時間加以分析比對，對於不合理之時間點則不予以接受，以防止類似像照相後轉寄之情況發生。本模組包含於圖碼驗證模組中。

行動商務平台系統架構圖。如第1圖所示。

在今日網路普及，網路傳輸速率(4G)快速，幾乎人手一支智慧型手機的時代，相信只要能善加利用此應用模型，必能為我們現代之行動生活與行動商務活動帶來更多的便利！

茲將本發明所發展出之應用模型，相應於當今較為被普遍廣泛使用的卡片，對其套用本發明之應用模型並根據資料傳輸與操作流程為實例分述如下，作為未來之發展應用。

第1圖係根據本發明之行動商務平台系統架構圖。

第2圖係本發明之使用者要求系統資料傳輸與操作流程圖。

第3圖係本發明之接受者驗證系統資料傳輸與操作流程圖。

第4圖係本發明之接受者驗證系統資料傳輸與操作流程圖。

第5圖係本發明之信用卡收單行驗證系統資料傳輸與操作流程圖。

第6圖係本發明之金融卡B銀行提款機驗證系統資料傳輸與操作流程圖。

第7圖係本發明之利用電子商務平台購買台灣高鐵車票並透過第三方支付平台交易流程。

第8圖係本發明之購買台灣高鐵車票交易流程。

第9圖係本發明之收到為非國內銀行所發信用卡時則會直接傳送至國際信用卡組織中心之資料傳輸與操作流程圖。

第10圖：Square行動支付工具。

第11圖：中國大陸的拉卡拉行動支付工具。

1 身分認證與註記-健保卡應用

在假設使用行動裝置或智慧型手機的電磁波不會影響醫療設備，同時醫療院所也同意將行動裝置調為靜音模式就可進入診間，並且具備如本應用模型的接受裝置的前提之下，將平常我們較常使用到的健保卡，透過本發明之應用模型，以當我們於排隊候診時，即將進入診間為例，發展應用如下：

●使用者要求系統面-使用者使用健保卡進入診間

資料傳輸與操作流程：如第2圖所示。

1. 使用者使用行動裝置進入行動商務平台之登入安全機制模組。

2. 通過登入安全機制認證後，點選「使用者要求入系統」。

3. 進入「使用者要求入系統」後，點選健保卡。

4. 輸入畫面出現中央健保局之個人帳戶之畫面，(此時已進入中央健保局後台主機系統，輸入畫面透過行動商務平台之輸入畫面模組呈現)並依中央健保局個人帳戶網頁上所提供之選項輸入自己要求所需之資訊或數據並點選產生圖碼確認。(健保卡使用應無需輸入自己要求所需之資訊或數據，故直接點選產生圖碼確認即可)。

5. 發卡使用單位後台主機系統接收使用者欲要求或輸入之資訊與數據後，將所需之資訊及認證相關資訊傳輸至行動商務平台之圖碼產生器模組進行資訊轉換進而產生圖碼。

6. 圖碼產生器模組將產生出之圖碼回傳至發卡使用單位後台主機系統。

7. 發卡使用單位後台主機系統將圖碼透過行動商務平台輸出畫面模組將圖碼輸出，同時呈現於使用者的行動裝置上。

8. 發卡使用單位後台主機系統，同時傳輸訊息給行動商務平台之圖碼驗證模組，告知其圖碼將等待驗證。

9. 發卡使用單位後台主機系統在收到由行動商務平台之圖碼產生模組所產出之圖碼後，將會記錄且保留於使用者個人帳戶之記錄欄中，直至失效為止。所以當使用者不小心登出或跳離畫面時，使用者仍可繼續透過登入行動商務平台進入發卡使用單位之個人帳戶之記錄裡，重新點擊叫出並繼續使用。

●接受者驗證系統面-診間健保卡之驗證

資料傳輸與操作流程：如第3圖所示。

1. 接受者使用接受裝置進入行動商務平台之登入安全機制模組。

2. 通過登入安全機制認證後，點選「接受者驗證系統」。

3. 進入「接受者驗證系統」後，點選固定連接接受使用單位-中央健保局。

在本例中使用健保卡，1到3步驟之前就設定為固定值，所以當醫護人員一開機(接受裝置)，通過登入安全機制認證後，就會直接固定連結至中央健保局之相關網站，進而直接進入到下一步驟，等待接受圖碼。

4. 輸入畫面出現接受使用單位之等待輸入之畫面，(此時已進入中央健保局後台主機系統，輸入畫面透過行動商務平台之輸入畫面模組呈現)，等待接受圖碼。

接者，使用者手持行動裝置將圖碼經過接受裝置之掃描，將圖碼傳輸至接受使用單位後台主機系統。

5. 接受使用單位後台主機系統接圖碼後，會先將圖碼傳輸置行動商務平台之圖碼分析模組，透過此模組之分析，先行判斷該圖碼使來自何處，是否為來自可接受之發卡使用單位所產生(透過中央健保局所產生之圖碼)，若不可接受則發出錯誤訊息，回傳至接受使用單位主機，透過商務平台之輸出畫面模組，呈現於接受裝置。

在本例子中，因當時已設定為固定連接使用單位，所以只接受固定之發卡單位所產生之圖碼。

6. 圖碼經行動商務平台之圖碼分析模組確認無誤且為可接受後，將回傳可接受之訊息至接受使用單位後台主機系統。

7. 接受使用單位主機系統在接受到圖碼為接受之訊息後，將圖碼傳輸至行動商務平台之圖碼驗證模組。

8. 經行動商務平台圖碼驗證模組驗證無誤後，圖碼驗證模組回傳確認訊息至使用發卡使用單位主機系統。

9. 接受使用單位主機系統在收到圖碼驗證模組回傳確認訊息後，將所需之相關資訊經由行動商務平台之輸出畫面模組呈現於接受者之接受設備。如此醫護人員就可透過身旁PC得到來自中央健保局之相關資訊，同時也表示該使用者成功就診。

10. 接受使用單位後台主機系統，同時傳輸訊息給行動商務平台之圖碼驗證模組，告知其圖碼已驗證完畢，行動商務平台之圖碼驗證模組將對其圖碼註記為失效並且無法再行使用。

原發卡使用單位主機系統在收到經由接受者所設定之接受使用單位之圖碼，在透過行動商務平台的圖碼驗證模組驗證後所傳回驗證並接受的訊息後，將會記錄且註記使用者個人帳戶之記錄欄中，並於不久後將圖碼刪除，以防止重複使用。故當使用者再次登入個人帳戶網頁查詢時，只會看到過去紀錄且無法看到過去所使用之圖碼。

對於學校學生的學生證及公司企業的員工證，利用本應用模式，在學校及公司企業的門禁管理或其他應用(如：借閱書籍..等)，相信定能夠發揮良好的應用，為大家帶來更多的便利！

2 電子錢包-悠遊卡應用

在此所指之電子錢包乃是指儲藏在智慧卡片上的「價值單位」，是現金的電子等同物。例如現在被大眾使用率頗高的悠遊卡，icash卡，即屬於此類。

而電子錢包支付方式，是必須先在智慧卡片上儲值金錢，透過接受裝置以感應的方式經由店家輸入金額或是由接受裝置以自動方式扣款。悠遊卡是目前被使用率最高的電子錢包，大多數被應用搭乘大眾交通工具與便利商店購物時之小額付款，本節將以使用悠遊卡為例，利用本發明之應用模型，作為其發展應用的方向。

2.1 搭乘捷運之運用

在假設各捷運站之進出閘口皆有與本應用模型的類似之接受裝置，能夠對圖碼進行快速掃描讀取(目前僅高鐵之進出閘口有此裝置)，同時各捷運站之進出閘口掃描裝置皆與捷運公司的後台主機系統保持即時連線狀態連線前提下，我們以使用悠遊卡搭乘台北捷運為例：

■使用者使用悠遊卡通過捷運站入站閘口

●使用者要求系統面-通過捷運站入口閘口

資料傳輸與操作流程圖如同第2圖，其操作步驟與流程說明同1節使用者要求系統面1~8步驟，並將於第3步驟中，點選悠遊卡，則發卡使用單位為悠遊卡公司。

使用者登入行動商務平台並點選悠遊卡，連結至悠遊卡公司之網站的個人帳戶網頁時，當儲值金額小於0時，則無法產生圖碼，同時悠遊卡公司後台主機系統將產生錯誤訊息，經行動商務平台輸出畫面模組呈現於使用者行動裝置，要求使用者儲值。

因悠遊卡為電子錢包之使用，如前述乃透過接受裝置以感應的方式經由店家輸入金額或是由接受裝置以自動方式扣款，因此，以現代圖碼為介質透過行動商務平台在本應用模式中，在步驟4裡，同5.1節使用者要求系統面之步驟4，悠遊卡使用應無需輸入自己要求所需之資訊或數據，故直接點選產生圖碼確認即可。

●接受者驗證系統面-捷運站入站閘口之悠遊卡驗證

資料傳輸與操作流程：如第4圖所示。

其資料流程與操作步驟說明同1節接受者驗證系統面1~6步驟，但於第3步驟中，點選非固定連結接受使用單位，表示雖然接受者設定之使用單位為捷運局，但仍然可接受其他類似悠遊卡之卡片，例如一卡通卡片。

在本例中，1到3步驟之前就設定為固定值，所以當捷運站一開機(接受裝置)，通過登入安全機制認證後，就會直接固定連結至捷運站之相關網站，進而直接進入到下一步驟，等待接受圖碼。

步驟6後之資料流程與操作說明如下：

7. 接受者設定之接受使用單位(捷運局)後台主機系統在接受到經圖碼分析模組分析後，得知圖碼為來自與接受者設定之接受使用單位不相同單位時，依據圖碼分析模組分析所得之卡號，接受者設定之接受使用單位(捷運局)後台主機系統將記錄該卡號進站時間與地點，接者，將圖碼與該卡號進站時間與地點訊息一併傳輸至發卡使用單位(悠遊卡公司)主機系統，等待相關資訊回覆。

8. 原發卡使用單位(悠遊卡公司)後台主機系統在收到來自接受者設定之接受使用單位(捷運局)後台主機系統所傳送之圖碼與該卡號進站時間與地點後，將圖碼傳輸至行動商務平台之圖碼驗證模組，進行驗證。

9. 經行動商務平台之圖碼驗證模組驗證確認圖碼無誤後，將圖碼確認與相關訊息回傳至原發卡使用單位(悠遊卡公司)後台主機系統。

10. 原發卡使用單位(悠遊卡公司)主機系統將圖碼確認無誤及回覆相關訊息傳送至接受者設定之接受使用單位(捷運局)後台主機系統，同時原發卡使用單位(悠遊卡公司)後台主機系統也記錄該卡號進站時間與地點。

11. 接受使用單位(捷運局)後台主機系統在收到原發卡使用單位(悠遊卡公司)主機系統回傳確認訊息後，把相關記錄皆記錄於主機系統中，接者將所需之相關資訊經由行動商務平台之輸出畫面模組呈現於接受者之接受設備。而此時捷運站之入口閘門就會打開讓使用者順利通過入站。

12. 發卡使用單位(悠遊卡公司)後台主機系統，同時傳輸訊息給行動商務平台之圖碼驗證模組，告知其圖碼第一次驗證以驗證完畢即將等待第二次驗證。

■使用者使用悠遊卡通過捷運站出站閘口

●使用者要求系統面-通過捷運站出站閘口

使用者完全不須再點選產生圖碼，只需再經由行動裝置透過行動商務平台進入使用者要求系統連結至使用者發卡使用單位(悠遊卡公司)之個人帳戶網頁，依其上之記錄，重新點擊打開上一次進入捷運站閘口時所產生之圖碼，透過行動商務平台之輸出畫面模組呈現於使用者之行動裝置。接者，只需將其圖碼置於捷運站出口閘口上之接受裝置接受掃描讀取，通過驗證及扣款後即可通過捷運站出站閘口。

●接受者驗證系統面-捷運站出站閘口之悠遊卡驗證

資料傳輸與操作流程同捷運站入閘口之悠遊卡驗證資料傳輸與操作流程。參照第3圖所示。

1~6步驟完全與捷運站入閘口之悠遊卡驗證資料傳輸與操作流程為相同，從第7步驟開始，說明如下：

7. 接受者設定之接受使用單位(捷運局)後台主機系統在接受到經圖碼分析模組分析後，得知圖碼為來自與接受者設定之接受使用單位不相同單位時，依據圖碼分析模組分析所得之卡號，接受者設定之接受使用單位(捷運局)後台主機系統記錄該卡號出站時間與地點，並依系統記錄該卡號之進站時間與地點，計算出費用。最後，將圖碼與要求扣款訊息一併傳輸至發卡使用單位(悠遊卡公司)主機系統，並等待回覆。

8. 原發卡使用單位(悠遊卡公司)後台主機系統在收到來自接受者設定之接受使用單位(捷運局)後台主機系統所傳送之圖碼與該卡號出站時間與地點，要求扣款費用訊息後，將圖碼傳輸至行動商務平台之圖碼驗證模組，進行驗證。

9. 經行動商務平台之圖碼驗證模組驗證並且也確認為第二次圖碼驗證後，回傳確認訊息至原發卡使用單位(悠遊卡公司)後台主機系統。

10. 原發卡使用單位(悠遊卡公司)主機系統收到經圖碼驗證模組驗證並且也確認為第二次圖碼驗證訊息後，主機系統將對卡號出站時間與地點與入站時間與地點做一比對，確認且核實後，將記錄於主機系統中，並依據該卡之上一次記錄，計算出是否給予折扣優惠，完成扣款動作。再將圖碼確認無誤與同意並完成扣款訊息傳(包括折扣優惠)送至接受者設定之接受使用單位(捷運局)後台主機系統。

11. 接受使用單位(捷運局)後台主機系統在收到原發卡使用單位(悠遊卡公司)主機系統回傳確認訊息後，系統接收扣款之款項並把相關記錄皆記錄於主機系統中，接受者將所需之相關資訊經由行動商務平台之輸出畫面模組呈現於接受者之接受設備。而此時捷運站之出口閘門就會打開讓使用者順利通過出站。

12. 發卡使用單位(悠遊卡公司)後台主機系統同時傳輸訊息給行動商務平台之圖碼驗證模組，告知其圖碼已待驗證完畢，並稍後發卡使用單位(悠遊卡公司)後台主機系統會將其帳號上之圖碼刪除。

使用者再次登入並透過行動商務平台，連結悠遊卡之個人帳戶網頁查詢剩餘金額，即可發現其悠遊卡之金額經搭乘捷運扣款後已正確地減少。

2.2 搭乘捷運後並轉乘公車之運用

一般民眾在使用悠遊卡搭乘大眾交通工具時，常會利用轉乘方式，如在搭完捷運之後再搭乘公車，同時又享受因用搭乘大眾交通工具並轉乘的二段式搭乘所得到之優惠。

使用悠遊卡在搭乘捷運後又在悠遊卡限定之時效內再搭乘公車而享用之優惠的實際狀況，依舊可以利用於本行動商務平台及本發明所發展之應用模式做為將來發展用模式。

目前台北市各主要路線之公車皆陸續安裝了行動網路閘道(Mobile Gateway)設備，各客運管理站透過了行動網路(WIFI或4G)經由公車之Mobile Gateway隨時掌控各公車動態同時還可與駕駛文字訊息方式絡溝通並對各公車候車站牌上的電子看板資訊同步更新。雖然，現在於公車上的悠遊卡之讀卡機器在扣款時並未與公車客運公司後台主機系統即時連線，但相信不久的將來，讓公車上的悠遊卡之讀卡機器在扣款時透過公車上之Mobile Gateway與客運公司後台主機系統保持即時連線，不難實現。在假設各公車上的悠遊卡之讀卡機器在扣款時透過公車上之Mobile Gateway與客運公司後台主機系統保持即時連線並有與本應用模型的類似之接受裝置，能夠對圖碼進行快速掃描讀取具備前提下，我們以使用悠遊卡搭乘台北捷運後並於享受優惠時效內又轉搭台北市公車為例：

●使用者要求系統面-通過公車悠遊卡接受裝置

資料傳輸與操作流程圖如同第2圖，其操作步驟與流程說明同上述2.1搭乘捷運之運用-使用者使用悠遊卡通過捷運站入站閘口的「使用者要求系統面-通過捷運站入站口閘口」步驟完全相同。

●接受者驗證系統面-公車悠遊卡接受裝置驗證

資料傳輸與操作流程圖如同第4圖，其操作步驟與流程說明同上述2.1搭乘捷運之運用，使用者使用悠遊卡通過捷運站出站閘口的「接受者驗證系統面-捷運站出站閘口之悠遊卡驗證」步驟1~12相似。接受者使用設定的接受者使用單位為各公車客運公司，後台主機系統則為各公車客運公司後台主機系統。

同樣的，於第7步驟中，公車客運公司後台主機系統記錄該卡號上車或下車時間，並依該卡之類別計算出固定費用號之應扣款額(如成人固定額為15元或優惠老人學生為8元)。最後，再將圖碼與要求扣款訊息一併傳輸至發卡使用單位(悠遊卡公司)主機系統，並等待回覆。

於第10步驟中，原發卡使用單位(悠遊卡公司)主機系統收到經圖碼驗證模組驗證並且確認訊息後，主機系統將對卡號上車或下車時與上一次搭乘捷運記錄做一比對，確認需要予以折扣優惠後，將記錄於主機系統中，再將圖碼確認無誤與同意並需要予以優惠之扣款訊息傳送至接受者設定之接受使用單位(公車客運公司)後台主機系統，同時完成扣款動作。

第11步驟中，接受使用單位(公車客運公司)後台主機系統在收到原發卡使用單位(悠遊卡公司)主機系統回傳確認訊息及因優惠而必須將扣款金額調整之款項訊息後，系統完成接收優惠扣款動作並把相關記錄皆記錄於主機系統中，接受者再將所需之相關資訊經由行動商務平台之輸出畫面模組呈現於接受者之接受設備。此時，使用者順利上車或下車。

2.3 搭乘大眾交通工具後使用Ubike之運用

與2.2同樣的情境，在假設各Ubike之借還處上的讀卡機器為本應用模型的類似之接受裝置，能夠對圖碼進行快速掃描讀取同時並且還與悠遊卡公司後台主機系統保持即時連線前提下，我們以使用悠遊卡在搭乘大眾交通工具後情境為例：

借車：

●使用者要求系統面-通過Ubike借車處接受裝置

資料傳輸與操作流程圖如同第2圖，其操作步驟與流程說明同上述2.1搭乘捷運之運用，使用者使用悠遊卡通過捷運站入站閘口的「使用者要求系統面-通過捷運站入站口閘口」步驟完全相同。

●接受者驗證系統面-Ubike借車處接受裝置驗證

資料傳輸與操作流程圖如同第2圖，其操作步驟與流程說明同上述2.1搭乘捷運之運用，使用悠遊卡通過捷運站入站閘口的「接受者驗證系統面-捷運站入站閘口之悠遊卡驗證」，同步驟1~12。

接受者使用設定的接受者使用單位為台北市公共自行車處，後台主機系統為台北市公共自行車處後台主機系統。發卡使用單位為悠遊卡公司。

還車：

●使用者要求系統面-通過Ubike還車處接受裝置

其操作步驟與流程說明同上述2.1搭乘捷運之運用，使用者使用悠遊卡通過捷運站出站閘口的「使用者要求系統面-通過捷運站出站閘口」步驟完全相同。

●接受者驗證系統面-Ubike還車處接受裝置驗證

資料傳輸與操作流程圖如同第4圖，其操作步驟與流程說明同上述2.1搭乘捷運之運用，使用者使用悠遊卡通過捷運站出閘口的「接受者驗證系統面-捷運站出站閘口之悠遊卡驗證」之步驟1~12。加上綜合上述2.2搭乘捷運後並轉乘公車之運用的公車悠遊卡接受裝置驗證步驟中之優惠判斷步驟，計算出扣款金額。

2.4 便利商店購物時之小額支付

資料流程與操作模式在本應用模式上皆與前述2.1，2.2，2.3幾種應用模式相同，而其中之差異在於扣款金額是在於接受者接受裝置上直接輸入扣款金額數目，而不是經由悠遊卡公司後台主機系統依據接受使用單位，依照捷運入、出站，公車上、下車，Ubike借、還車，再加上各種組合狀況與時間條件下之折扣計算出扣款金額。接受者接受裝置在接收圖碼同時，會將扣款金額數目訊息一併傳輸至使用者之使用發卡單位(悠遊卡公司)。

●使用者要求系統面-使用悠遊卡刷卡消費購物

資料傳輸與操作流程圖如同第2圖，其操作步驟與流程說明同上述2.1搭乘捷運之運用，使用悠遊卡通過捷運站入站閘口的「使用者要求系統面-通過捷運站入站口閘口」步驟完全相同。

●接受者驗證系統面-便利商店之接受裝置

資料傳輸與操作流程圖如同第4圖，其操作步驟與流程說明同上述2.1搭乘捷運之運用，使用悠遊卡通過捷運站出閘口的「接受者驗證系統面-捷運站出閘口之悠遊卡驗證」，同步驟1~12。

第10步驟中，在對於扣款金額部分，當使用者之使用者的原發卡單位(悠遊卡公司)，收到圖碼與扣款金額要求訊息後，在圖碼確認無誤後，便直接依據扣款金額要求訊息上的金額數直接扣款，完成扣款動作，在回傳回圖碼確認無誤與同意扣款之訊息。否則，若是扣款金額大於悠遊卡中之餘額，使用者的原發卡單位(悠遊卡公司)主機後台系統則發出錯誤訊息，顯示餘額不足，回傳至便利商店後台主機系統。

在第11步驟中，接受使用單位(便利商店)後台主機系統在收到原發卡使用單位(悠遊卡公司)主機系統回傳確認及接收受扣款項目訊息後，把相關記錄皆記錄於主機系統中，接受者再將所需之相關資訊經由行動商務平台之輸出畫面模組呈現於接受者之接受設備，使用者順利完成交易。

3 行動支付-信用卡之應用與金融卡於提款機應用 3.1 行動支付-信用卡之應用

●根據發卡銀行統計，雖然這幾年整體大環境經濟呈現不景氣，但全球使用信用卡的人口仍持續成長中，有效卡片使用經統計也呈正成長。而一般民眾每人平均持有信用卡張數至少為2張以上，並也已習慣於日常生活中利用信用卡消費，因此，使用信用卡消費早已在消費模式中佔了非常大與重要之比率。

因此，信用卡在使用率如此之高下，若是以本發明發展之行動商務平台的應用模型做為未來行動之付交易模式，相信將來必是一個很好之發展應用。

在假設各特約商店之電子刷卡機(POS機)皆有與本應用模型的類似之接受裝置，能夠對圖碼進行快速掃描讀取前提下，我們以持卡人持有國內A銀行所發之信用卡，至國內特約商店刷卡消費，特約商店有3台POS機，收單銀行各為國內之銀行B、銀行C、銀行D為例：在使用者持卡人進入行動商務平台點選信用卡選項，如同電子錢包悠遊卡之應用般，例如該卡已非正常有效卡，信用額度不足或是被報失等問題，發卡行則直接產生錯誤訊息，不會產生圖碼。

資料流程與操作模式在本應用模式上皆與前述2.4應用模式相同，而其中之刷卡金額是在於接受者接受裝置上直接輸入刷卡金額數目，接受者接受裝置在接收圖碼後，會將扣款金額數目訊息一併傳輸至使用者之使用發卡單位(A銀行)。

●使用者要求系統面-使用信用卡的發卡銀行產生圖碼

資料傳輸與操作流程圖如同第2圖，其操作步驟與流程說明同上述2.4使用悠遊卡於便利商店購物時之小額支付應用的「使用者要求系統面-使用悠遊卡刷卡消費購物」步驟完全相同。並於第3步驟中，點選A銀行所發之信用卡，則發卡使用單位即為信用卡發卡銀行A銀行。

●接受者驗證系統面-特約商店之POS機圖碼掃描

資料傳輸與操作流程圖如同第5圖。

在本例中，1到3步驟之前就設定為非固定值，所以當特約商店POS系統一開機(接受裝置)，通過登入安全機制認證後，就會自動選取連結至收單行B銀行，收單行C銀行或是收單行D銀行，表示特約商店與收單行所簽約的不只有一家銀行，特約商店可於系統中設定於對自己做有利之優先順序或是依據網路連線狀態由系統自動連結，因此，如圖5.7所示，接受者設定單位收單行則有B銀行，C銀行及D銀行，而在本例中，接受者使用單位自動跳轉至B銀行。進入收單行B銀行之相關網站，進而直接進入到下一步驟，等待接受圖碼。

其操作步驟與流程說明同上述2.4使用悠遊卡於便利商店購物時之小額支付應用的「接受者驗證系統面-便利商店之接受裝置」，同步驟1~6。

步驟6後之資料流程與操作說明如下：

7. 接受者使用單位收單行B銀行接收經行動商務平台之圖碼分析模組分析圖碼資訊後，得知其發卡行為來自國內發卡行A銀行，則將圖碼、發卡單位代碼及要求刷卡金額相關訊息一併傳輸至國內信用卡清算中心。

8. 國內信用卡清算中心，經確認為有效卡號後，依據收單行所提供之信用卡發卡行代碼，將所有相關訊息一併傳入至發卡行A銀行。

9. 原發卡使用單位(A銀行)後台主機系統在收到來自國內信用卡清算中心後台主機系統所傳送之圖碼與該卡號刷卡金額與時間與後，將圖碼傳輸至行動商務平台之圖碼驗證模組，進行驗證。

10. 經行動商務平台之圖碼驗證模組驗證確認圖碼無誤後，將圖碼確認與相關訊息回傳至原發卡使用單位(A銀行)後台主機系統。

11. 原發卡使用單位(A銀行)主機系統將圖碼確認無誤及回覆同意刷卡金額相關訊息傳送至國內信用卡清算中心後台主機系統。

12. 國內信用卡清算中心後台主機系統在收到原發卡使用單位(A銀行)主機系統回傳確認訊息後，把圖碼確認無誤及回覆同意刷卡金額相關訊息回傳至收單銀行B銀行。

13. 接受使用單位收單行(B銀行)後台主機系統在收到國內信用卡清算中心主機系統回傳確認訊息後，系統接收刷卡之款項並把相關記錄皆記錄於主機系統中，接受者將所需之相關資訊經由行動商務平台之輸出畫面模組呈現於接受者之接受設備。而此時特約商店接受信用卡之刷卡。

14. 使用者單位發卡行(A銀行)後台主機系統，同時傳輸訊息給行動商務平台之圖碼驗證模組，告知其圖碼已待驗證完畢，該圖碼將無法進行第二次驗證。

信用卡之金流與電子錢包不相同，電子錢包金流是於當下資料傳輸時即產生並予以扣款，而信用卡在傳輸資料時並無金流產生，而是事後透過清算中心，由收單行向發卡行請款，當下指示對其信用消費做一放行與否的決定。

經由上述應用之例，利用本發明以圖碼為介質之行動商務平台應用模型，相信在以行動裝置作為信用卡行動支付發展上，定可與TSM平台相結合並應用發展，它不需要經過手機改換SIM卡的繁瑣過程，也不需要再經由TSM平台做確認，在安全考量上，以本發明之應用模型，更無如像前些時間新聞所報導的新聞，有心人士利用特殊工具與設備，透過利用近距離傳輸(如NFC，藍芽Bluetooth..)讀取裝置，完全地接收並竊取手機上SIM卡及晶片卡上之資料的疑慮，因為所有資料皆存在於各使用單位上，此種應用模式，相信更為廣大消費者所接受。

3.2 金融卡於提款機之應用

一般我們最常用的金融提款卡在提款機上提款或做其他操作時，透過本發明之行動商務平台產生的圖碼作為身分的認證，成為另一發展應用模式。

在假設各提款機皆有與本應用模型的類似之接受裝置，能夠對圖碼進行快速掃描讀取前提下，我們以持卡人持有國內A銀行所發之金融卡，至國內銀行B提款機提款或做其他操作為例：在使用者持卡人進入行動商務平台點選金融卡選項，如同1節身分認證與註記健保卡應用般。資料流程與操作模式在本應用模式上皆與前述1應用模式相同。

●使用者要求系統面-使用金融卡的發卡銀行產生圖碼

資料傳輸與操作流程圖如同第2圖，其操作步驟與流程說明同參照上述1節使用者要求系統面-使用者使用健保卡進入診間步驟完全相同。並於第3步驟中，點選A銀行所發之金融卡，則發卡使用單位即為金融卡發卡銀行A銀行。

●接受者驗證系統面-B銀行提款機之圖碼掃描

資料傳輸與操作流程圖如同第5圖，在本例中，1到3步驟之前就設定為固定值，所以當提款機一開機(接受裝置)，通過登入安全機制認證後，就會自動選取連結至B銀行，直接進入B銀行之相關網站，進而直接進入到下一步驟，等待接受圖碼。

其操作步驟與流程說明同上述3.1行動支付-信用卡之應用的「接受者驗證系統面-特約商店之POS機圖碼掃描」，同步驟1~14。如同第6圖所示。

在步驟7中接受者使用單位B銀行接收經行動商務平台之圖碼分析模組分析圖碼資訊後，得知其發卡行為來自國內發卡行A銀行，並非自行B銀行，則將圖碼、發卡單位代碼相關訊息一併傳輸至國內金融卡清算中心(財金公司)。而步驟中並無任何與金額相關之扣款或其他訊息，純粹是身分之認證。

待身分認證確認無誤完畢後，接者對於提款機操作，不管是提款或是轉帳或是繳交費用皆與現行應用模式完全相。

經由上述應用之例，利用本發明以圖碼為介質之行動商務平台應用模型，相信在以行動裝置作為金融卡於提款機操作應用上，民眾就不需隨身攜帶多張金融卡，同時也為一般大眾帶來解決不時之需之便利。

4 電子商務+第三方支付+行動支付-信用卡之應用 4.1 電子商務

電子商務市場的發展，主要歸功於電商平台為用戶提供了更便宜的價格、簡單和多樣的送貨方式，並透過行銷策略很好地觸及到用戶。

隨著行動網路與行動裝置的普及，各領域也都積極搶入此市場，更冀望借由O2O模式綁住更多消費者，例如亞馬遜不只在網路賣東西，也推出Home Services(家政、售後服務O2O)，涵蓋了房屋修繕、汽車修理、草坪打理、電器維修等實體服務；團購網GOMAJI藉由販售優惠券將餐飲、旅行、美容、娛樂等各行各業納入了O2O的一環；以銷售電器起家的燦坤也利用iBeacon技術推出手機app，使消費者於店面購物時能擁有即時的促銷資訊。

這些O2O模式帶來的是更豐富的購物體驗，未來的O2O不再是線上發動，更多的是由線下出擊，其界線將趨向模糊，萬物互聯時代下O2O浪潮全面啟動。

在大陸11月11日所發展出來的俗稱光棍購物節日上，於O2O行銷模式裡，不難看出對整體消費經濟的影響力。消費者利用信用卡於電商平台消費也儼然成為一個重要消費模式。而利用電商平台購物在使用行動支付為付款模式，更是日常生活上，常遇到的消費模式。

4.2 電子商務+第三方支付應用

對於透過第三方支付平台交易，目前國內應用正處於立法通過，各第三方支付平台正積極在開發市場階段，反觀大陸應用較為成熟。

利用電子商務平台透過第三方支付平台購買商品：目前台灣高鐵站的入、出閘口都有對圖碼掃描讀取之裝置，國內也有些信用卡發卡銀行與高鐵合作，使用這些發卡行之信用卡購買台灣高鐵車票，將可利用手機在通過入、出閘口時，可使用QR Code圖碼通過(目前仍處於測試階段，且限定使用某指定之銀行之信用卡刷卡購買才可使用)。

我們以持卡人來自大陸之商務旅客以中國A銀行所發之信用卡，因行程臨時需要，經由業務包含兩岸旅行社之電商平台(因透過該店商平可享有紅利積分或其他優惠，故不經由台灣高鐵網站購買)，並以透過大陸第三方支付(如支付寶..等)付款方式，購買明日之台灣高鐵車票。

利用電子商務平台購買台灣高鐵車票並透過第三方支付平台交易流程如第7圖。

1. 消費者登入旅行社電商平台。

2. 透過旅行社電商平台向台灣高鐵購票。

3. 消費者透過第三方支付平台支付寶付費。

4. 第三方支付平台支付寶依消費者者設定之信用卡銀行向A銀行進行刷卡消費。

5. A銀行刷卡交易成功後，告知第三方支付平台支付寶消費者以成功刷卡，交易成功。

6. 第三方支付平台支付寶通知旅行社電商平台消費者已付款。

7. 電商平台之旅行社通知台灣高鐵準備出票。

8. 台灣高鐵系統列印實體購買車票憑證，並通知電商平台之旅行社。

9. 電商平台之旅行社派遣快遞至台灣高鐵索取實體購買車票憑證並送至消費者大陸之商務旅客之手中。

消費者大陸商務旅客在準備搭乘高鐵之前須至服務櫃台前持列印實體購買車票憑證辦理換取登車實體票證，才可進入進站之入閘口。

第三方支付平台支付寶在消費者成功購買產品後3至7日後，將會與消費者確認此筆交易是否有效與否，確認有效無誤後，將購票之費用付給電商平台之旅行社。

4.3 電子商務+第三方支付應用+行動支付

使用本發明之行動商務平台與電子商務平台購買商品：同上述例：利用本發明之行動商務平台並透過電子商務平台購買台灣高鐵車票交易流程，如第8圖。

1. 消費者登入旅行社電商平台。

2. 透過旅行社電商平台向台灣高鐵購票。並於高鐵購票網頁，選擇需使用行動電子票證通過入出閘口選項。

3. 台灣高鐵購票主機系統將購票之相關訊息(電商平台上之會員資訊、搭乘日期班次及所需之總金額)回傳至電商平台(旅行社)，並將其會員狀態記錄為「預訂出票」。

4. 消費者於電商平台上點選「選擇信用卡付款」。進入選擇信用卡付款後，點選大陸A銀行信用卡並勾選「選擇使用行動裝置支付」選項。因電商平台上已選擇使用大陸A銀行信用卡並勾選「選擇使用行動裝置支付」的選項，故電商平台將會員資訊、搭乘日期班次及所需之總金額在會員連結進入大陸A銀行之網站前端伺服器時，一併傳輸至大陸A銀行之網站前端伺服器。

5. 進入大陸A銀行之網站前端伺服器之網頁，選擇「使用圖碼進行信用卡刷卡付費」選項及「需與消費確認後才真正付款」選項。進入本發明之行動商務平台經由登入安全機制進入A銀行之個人帳戶網頁，由使用者要求系統面進入進行圖碼產生流程(第8圖藍色號碼標記)，並將圖碼置於A銀行之個人帳戶網頁中。

6. 在經由登入安全機制登入後，原本從電商平台傳送之會員資訊、搭乘日期、班次及所需之總金額等資訊，將透過大陸A銀行之網站前端伺服器也一併傳送至大陸A銀行後台主機系統，經由藍色號碼標記第5步驟，傳送至行動商務平台之圖碼產生器模組去建立圖碼。

7. 當圖碼建立完畢並置於使用者之大陸A銀行之個人網頁紀錄中後，大陸A銀行後台主機系統傳送已建立圖碼完畢訊息給網站前端伺服器系統。

8. 大陸A銀行網站前端伺服器系統接收到後台主機系統傳送已建立圖碼完畢訊息後，傳送訊息給電商平台告知已完成「預刷卡」之動作。

9. 電商平台(旅行社)收到訊息後，通知台灣高鐵售票系統，已收到會員之預刷卡，台灣高鐵購票主機系統將其會員狀態記錄為「正式已出票」。

消費者持行動裝置欲通過高鐵站入、出站閘口時，其流程與2.1節搭乘捷運入、出站，使用者要求系統面-準備通過捷運站入、出站閘口相同。

在台灣高鐵入、出站閘口驗證系統上，其流程與2.1節搭乘捷運入、出站相似，接受者驗證系統面-捷運站入、出站閘口之悠遊卡驗證。參考第4圖，將各入、出閘口當作是固定之信用卡之收單行，接受者使用單位為台灣高鐵公司。不同處為在於第6步驟中，當本行動商務平台經由圖碼判斷模組收到為非國內銀行所發信用卡時，在第7步驟裡，則會直接傳送至國際信用卡組織中心如VISA、MASTER、JCB、銀聯等，經由國際信用卡組織中心轉傳至發卡行(大陸A銀行)，再經由發卡行傳送至本行動商務平台之圖碼驗證模組做驗證。如第9圖。

當進入大陸A銀行之網站前端伺服器之網頁，選擇「使用圖碼進行信用卡刷卡付費」選項及「需與消費確認後才真正付款」選項。故當消費者完成消費後之3至7日，大陸A銀行會因台灣高鐵(收單行)系統當時使用圖碼通行確認記錄及相關購買資訊向大陸A銀行(發卡行)收取該筆交易費用時，將與消費者確認該筆交易是否確認付費。在與消費者確認無誤後(或是消費者在7日內無提出異議要求退貨)，大陸A銀行將付費給台灣高鐵公司該消費者(大陸之商務旅客)該筆消費金額。

透過上述應用模型，以消費者透過電商平台購物，並採用貨到付款或親自取貨之方式，將常用之電子商務與行動支付做一結合應用。消費者以當時在電商平台上同時勾選「使用圖碼進行信用卡刷卡付費」及「需與消費確認後才真正付款」選項，透過當初產生之圖碼作為行動支付預付之憑據；而電商平台或店家以系統當時使用圖碼通行確認記錄及相關購買資訊作為請款之依據；消費者與店家雙方皆認同以本發明之行動商務平台上之圖碼產生輸出、入及驗證輸出、入記錄作為交易證明；如此，降低了消費者購物的風險(因真正付費是在消費者在7日內無提出異議要求退貨後)，同時也保障了與電商與店商之權益(當時使用圖碼通行確認記錄及相關購買資訊)，更為消費者與商家帶來了便利！

目前較常見並可廣泛應用之例：某美式速食餐廳經電子商務平台(目前盛行之團購網站)接受消費者預約訂購餐點，並採用上述之應用模型，消費者預先於電商平台上完成餐點訂購，到了美式速食餐廳店實體店鋪，只要手持行動裝置，點擊當時使用者選擇發卡單位之個人帳戶，將當時訂購後所產生出的圖碼透過美式速食餐廳店之圖碼掃描讀取器讀取掃描後，店員隨即將消費者當時預購之餐點送上(可外帶或內用，完全依消費者當時之選擇)，同時也完成結帳之動作。

5 C2C模式mPOS應用

本小章節所研究之C2C(customer to customer)應用，並非指的是一般透過電子商務平台上，消費者與消費者之間互動交易行為，而指的是當利用透過Square，或是像大陸的拉卡拉行動支付工具作為個人對個人商業交易活動。如第10,11圖所示。

在假設銀行允許個人就能成為獨立信用卡之收單行(如同特約商店之POS機)的情況下，某日消費者與消費者的朋友在一下午茶聚會中，消費者看上消費者朋友手上價值不斐的金錶，而消費者朋友基於同是愛錶之雅士，於彼此都認同之價錢下，當下同意讓賢。但此時消費者並未攜帶足夠現金，彼此也都不想因此而錯失良機，雙方二人在利用各自行動裝置，透過本發明之行動商務平台作為行動支付與收款工具下，順利完成了交易。

■消費者使用行動裝置透過本發明之行動商務平台刷卡：

資料流程與操作模式在本應用模式上皆與前述5.3節應用模式相同，而其中之刷卡金額可選擇於信用卡發卡銀行之個人帳戶網頁上輸入(或是在於接受者接受裝置上直接輸入刷卡金額數目，接受者接受裝置在接收圖碼後，會將扣款金額數目訊息一併傳輸至使用者之使用發卡單位銀行)。

●使用者要求系統面-使用信用卡的發卡銀行產生圖碼

資料傳輸與操作流程圖如同第2圖，其操作步驟與流程說明同上述3節，使用信用卡於作為行動支付應用。於第3步驟中，點選銀行所發之信用卡，則發卡使用單位即為信用卡發卡銀行。

■消費者的朋友使用行動裝置透過本發明之行動商務平台接受刷卡驗證：

●接受者驗證系統面-使用行動裝置作為POS機

利用行動裝置上之照相或是圖碼掃描讀取APP程式對圖碼進行掃描讀取，接受者使用單位將在消費者朋友選擇固定接受使用單位，連結至收單銀行。進入收單銀行之相關網站，進而直接進入到下一步驟，等待接受圖碼的驗證。資料傳輸與操作流程圖如同第5圖。

6 與O2O模式結合應用

從過去的公元2000年所強調網路Dot Com時代來臨，資訊商務發展一路從電子錢包、電子商務、B2B、B2C、第三方支付、C2C、O2O..到近期的「行動支付」發展的角度上來看，因為網路的發達，無線網路覆蓋面積的增大，網路速度也不斷的提升，智慧型手機及行動裝置使用廣泛，讓整體消費市場由過去所重視的企業消費市場已大幅轉向重視個人的消費市場。而個人消費者的使用與消費習慣改變，同時也造就了消費市場巨幅的改變，企業更為爭取個人消費者的市場，作為企業競爭力之指標。從企業為爭取從個人消費者的市場之發展趨勢，O2O(Online to Offline,Offline to Online)更成為現代重要的營銷模式。

近年來，為了兼顧實體通路與虛擬通路，開始出現整合的需求，顧客可以透過線上的購買動作，「促進」線下的到店取貨或接受服務。以台灣的店家為例，如EzTable線上訂位，消費者在網路上搜尋餐廳資訊並訂位，再到實體的餐廳接受服務，即是典型的O2O消費模式；另外，如摩斯漢堡(MOS Burger)，消費者可以利用線上的APP進行訂購，再到最近的店面進行取貨和付款，也能因此而節省等候時間。另外，國外的Uber手機叫車服務、Groupon酷碰團購，也是利用網路上的事先預訂與購買，在實體享用計程車與旅館等服務。

在本發明之各項應用中，不管是悠遊卡(或是各種會員卡)、金融提款卡、信用卡的應用，從資料交易流程來看，在接受者驗證系統面，當圖碼被驗證完畢後，表示其交易已完成，使用者點選單位(發卡行)將依照之前傳輸近來之資訊，判斷其接受者驗證單位(圖碼掃描讀取機，收單行)為來自何處，透過大數據分析，或是於系統資料庫中，依據消費者過去消費紀錄與喜好，將相關優惠或是任何促銷活動資訊即時傳送至使用者或是消費者的個人帳戶中，將相關優惠或是任何促銷活動資訊直接產生圖碼並傳送至使用者或是消費者的個人帳戶內。當使用者接收到相關優惠或是任何促銷活動資訊並再次消費時，O2O2O(從online到offline；再從offline到online)的營銷模式與應用儼然形成與充分發揮，為消費者帶來折扣利益，也為商家帶來更多利潤與商機；利用此一模式運作，也正是本發明期待在當今O2O的營銷模式與應用上，為消費者與商家帶來更直接與時效性之利益與商機！

Claims

使用者使用行動裝置當做為現行的卡片，在網路暢通並可連線環境下，透過行動裝置登入行動商務平台，利用行動商務平台所產生的圖碼，將其傳輸並顯示於使用者的行動裝置上(行動商務平台之輸出畫面模組對其圖碼控制使其無法轉發與轉寄)透過以此圖碼做為一種新的介質取代卡片上的磁條或是晶片，並將卡片上及磁條上或是晶片上的相關資訊建立並隱藏於圖碼中，經由接受裝置讀取，(圖碼掃描讀取器、智慧型手機+POS機、收銀機、PC..等)。作為身分識別及行動商務支付各種活動的方法。
根據申請專利範圍第1項之應用方式，所有現今應用模式上利用卡片作為身分識別及行動商務支付活動，僅需將接受者之接受裝置改成具有圖碼掃描讀取功能之機器。在應用系統上，發卡單位開發APP應用程式介面，新增或修改調整會員之個人網頁，以便使用者於行動裝置上使用與查詢。接受者使用單位新增或修改調整因應接受者使用單位藉由行動商務平台登入連結至使用單位後台主機之相關程式並新增其相關功能。對於現今所有交易資料流程僅多了同意建立圖碼及圖碼確認的步驟，特別是對於資料現金流部分，也完全符合現今金融法規之規定，完全不受影響，而不需要像目前流行之第三方支付方式，金融相關管理單位還須因應此種支付方式，對於相關法規做放寬與修改。
根據申請專利範圍第1項之應用方式，在行動支付活動上，利用圖碼被動接收至接受裝置掃描讀取。而今現行行動支付活動上，乃是以與電信公司與發卡單位達成協議並針對使用者的使用裝置重新客製USIM卡，並採取NFC或是Bluetooth主動發送模式至接受裝置，因此採用本發明做為行動支付活動上，不會有擔心被資料側錄之風險，也省去更換USIM卡之麻煩，相對連同TSM平台之驗證過程也不需要。同時也提供了僅有WIFI無USIM卡及NFC、Bluetooth功能之行動裝置可以使用行動支付之功能。
根據申請專利範圍第1項之應用方式，行動商務平台所產生之圖碼受到行動商務平台上模組控制與管理，僅具一次使用及時效性，一旦遭受到照相複製並轉發使用，僅會損失該單筆交易之認證或金額，避免像一旦卡片遺失並遭到冒用，冒用者將持卡片一直盜刷使用，直至卡片原始真正持有者發現，通報發卡單位將其停卡，造成鉅額損失之風險。
根據申請專利範圍第1項之應用方式，使用者係根據自己當時所註冊時之帳號與密碼透過行動裝置登入行動商務平台，所有相關帳務數據或資料皆還是儲存於原發卡單位，而行動商務平台僅負責圖碼產生、認證與控制管理，所以當使用者遺失行動裝置時，並無像使用者遺失卡片並遭到連續盜刷之風險。
根據申請專利範圍第1項之應用方式，在銀行允許個人就能成為獨立信用卡之收單行(如同特約商店之POS機)的情況下，新增個人電子銀行帳戶之收單行功能，買賣雙方因買方資金不足，希望使用信用卡完成買賣交易。即可透過本發明之行動商務平台作為行動支付與收款工具下，順利完成了交易。(如本發明之實施方式中的C2C模式mPOS應用。)
根據申請專利範圍第1項之應用方式，在本發明之各項應用中，不管是悠遊卡(或是各種會員卡)、金融提款卡、信用卡的應用，從資料交易流程來看，在接受者驗證系統面，當圖碼被驗證完畢後，表示其交易已完成，透過大數據分析，或是於系統資料庫中，依據消費者過去消費紀錄與喜好，將相關優惠或是任何促銷活動資訊即時傳送至使用者或是消費者的個人帳戶中，將相關優惠或是任何促銷活動資訊直接產生圖碼並傳送至使用者或是消費者的個人帳戶內。當使用者接收到相關優惠或是任何促銷活動資訊並再次消費時，O2O2O(從online到offline；再從offline到online)的營銷模式與應用儼然形成與充分發揮，為消費者帶來折扣利益，也為商家帶來更多利潤與商機；利用此一模式運作，也正是本發明期待在當今O2O的營銷模式與應用上，為消費者與商家帶來更直接與時效性之利益與商機！