本發(fā)明涉及通信技術(shù)領(lǐng)域，特別涉及一種支付方法及支付系統(tǒng)。

背景技術(shù)：

隨著移動互聯(lián)網(wǎng)技術(shù)的發(fā)展，移動終端的普及率越來越高，在電子交易平臺的交易過程中，用戶使用移動終端的頻率也越來越高，并且在電子交易平臺的交易環(huán)節(jié)中，越來越多的人通過移動終端進行支付。

在電子交易過程中，用戶主要考慮的是支付操作的安全性，那么，如何提高在電子交易中支付操作的安全性，就成為一個亟待解決的技術(shù)問題。

技術(shù)實現(xiàn)要素：

本發(fā)明的主要目的是提供一種支付方法及支付系統(tǒng)，旨在有效提升支付操作的安全性。

為實現(xiàn)上述目的，本發(fā)明提出的支付方法，包括如下步驟：

客戶端接收用戶輸入的下單請求，并將所述下單請求發(fā)送至收款方服務(wù)器；

所述收款方服務(wù)器將所述下單請求按照預(yù)設(shè)的簽名規(guī)則進行簽名以生成訂單信息，并將所述訂單信息發(fā)送至所述客戶端；

所述客戶端將所述訂單信息按照預(yù)設(shè)的格式生成請求數(shù)據(jù)，并將所述請求數(shù)據(jù)發(fā)送至支付平臺；

所述支付平臺解密所述請求數(shù)據(jù)，獲取所述訂單信息；驗證所述訂單信息的簽名，并在驗證成功后生成支付憑證；將所述支付憑證按照預(yù)設(shè)的加密方式進行加密，并將加密后的支付憑證發(fā)送至所述客戶端；

所述客戶端解密所述支付憑證，并根據(jù)所述支付憑證中的支付信息調(diào)用支付工具進行支付操作。

可選的，所述客戶端將所述訂單信息按照預(yù)設(shè)的格式生成請求數(shù)據(jù)的步驟包括：

在所述訂單信息中添加二進制協(xié)議頭。

可選的，所述將所述支付憑證預(yù)設(shè)的加密方式進行加密的步驟包括：

在所述支付憑證中添加二進制協(xié)議頭。

可選的，所述支付方法還包括：

支付成功后，所述支付平臺向所述收款方服務(wù)器反饋支付成功信息。

可選的，所述向所述收款方服務(wù)器反饋支付成功信息的步驟包括：

所述支付平臺接收所述支付工具反饋的支付成功信息，并將所述支付成功信息發(fā)送至所述收款方服務(wù)器；

判斷所述支付成功信息是否發(fā)送成功；

如果否，則記錄發(fā)送失敗的原因，并在到達預(yù)設(shè)時間時，再次向發(fā)送所述支付成功信息；

當發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器發(fā)送預(yù)警郵件。

為實現(xiàn)上述目的，本發(fā)明提出一種支付系統(tǒng)，包括客戶端、收款方服務(wù)器、支付平臺及支付工具；其中，

所述客戶端，用于接收用戶輸入的下單請求，并將所述下單請求發(fā)送至所述收款方服務(wù)器；

所述收款方服務(wù)器，用于將所述下單請求按照預(yù)設(shè)的簽名規(guī)則進行簽名以生成訂單信息，并將所述訂單信息發(fā)送至所述客戶端；

所述客戶端，用于將所述訂單信息按照預(yù)設(shè)的格式生成請求數(shù)據(jù)，并將所述請求數(shù)據(jù)發(fā)送至支付平臺；

所述支付平臺，用于解密所述請求數(shù)據(jù)，獲取所述訂單信息；驗證所述訂單信息的簽名，并在驗證成功后生成支付憑證；將所述支付憑證按照預(yù)設(shè)的加密方式進行加密，并將加密后的支付憑證發(fā)送至所述客戶端；

所述客戶端，用于解密所述支付憑證，并根據(jù)所述支付憑證中的支付信息調(diào)用支付工具；

所述支付工具，用于執(zhí)行支付操作。

可選的，所述客戶端用于在所述請求數(shù)據(jù)中添加二進制協(xié)議頭。

可選的，所述支付平臺用于在所述支付憑證中添加二進制協(xié)議頭。

可選的，所述支付平臺，還用于在支付成功后，向所述收款方服務(wù)器反饋支付成功信息。

可選的，所述支付平臺包括：執(zhí)行模塊與判斷模塊；其中，

所述執(zhí)行模塊，用于接收所述支付工具反饋的支付成功信息，并將所述支付成功信息發(fā)送至所述收款方服務(wù)器；

所述判斷模塊，用于判斷所述支付成功信息是否發(fā)送成功；

所述執(zhí)行模塊，還用于在所述支付成功信息發(fā)送失敗后，記錄發(fā)送失敗的原因，并在到達預(yù)設(shè)時間時，再次向發(fā)送所述支付成功信息；

所述執(zhí)行模塊，還用于在發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器發(fā)送預(yù)警郵件。

本發(fā)明的技術(shù)方案，通過對客戶端、收款方服務(wù)器及支付平臺之間的交互數(shù)據(jù)按照不同的方式進行加密，有效保證了交互數(shù)據(jù)的安全性，進而保證了提升了支付操作的安全性。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖示出的結(jié)構(gòu)獲得其他的附圖。

圖1為本發(fā)明支付方法一實施例的流程圖；

圖2為本發(fā)明支付方法另一實施例的流程圖；

圖3為圖2中向所述收款方服務(wù)器反饋支付成功信息的步驟的流程圖；

圖4為本發(fā)明支付系統(tǒng)一實施例的模塊示意圖；

圖5為實現(xiàn)本發(fā)明支付系統(tǒng)一實施例的流程示意圖；

圖6為圖4中支付平臺一實施例的模塊示意圖。

本發(fā)明目的的實現(xiàn)、功能特點及優(yōu)點將結(jié)合實施例，參照附圖做進一步說明。

具體實施方式

應(yīng)當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

現(xiàn)在將參考附圖描述實現(xiàn)本發(fā)明各個實施例的移動終端。在后續(xù)的描述中，使用用于表示元件的諸如“模塊”、“部件”或“單元”的后綴僅為了有利于本發(fā)明的說明，其本身并沒有特定的意義。因此，“模塊”與“部件”可以混合地使用。

本發(fā)明提出一種支付方法。本發(fā)明的支付方法應(yīng)用于移動終端，但不限于移動終端。下面以移動終端為例進行說明：

如圖1所示，圖1為本發(fā)明支付方法一實施例的流程圖。

本實施的支付方法，包括如下步驟：

步驟S100、客戶端接收用戶輸入的下單請求，并將所述下單請求發(fā)送至收款方服務(wù)器。

具體的，所述客戶端安裝于移動終端內(nèi)。所述客戶端為對應(yīng)所述收款方服務(wù)器的應(yīng)用程序(比如，游戲客戶端等)。用戶在移動終端上下載與游戲商提供的服務(wù)器對應(yīng)的客戶端。

當用戶需要對客戶端進行充值等支付動作時，用戶可以通過客戶端上的充值模塊觸發(fā)充值界面，并選擇或自行輸入充值類型、充值數(shù)額等，并確定?？蛻舳烁鶕?jù)用戶輸入的充值類型與充值數(shù)額生成下單請求，并將所述下單請求發(fā)送至收款方服務(wù)器。

步驟S200、所述收款方服務(wù)器將所述下單請求按照預(yù)設(shè)的簽名規(guī)則進行簽名，以生成訂單信息，并將所述訂單信息發(fā)送至所述客戶端。

具體的，所述收款方服務(wù)器需要向第三方支付平臺進行注冊，以獲取相關(guān)信息：appId、appKey、appSecurity等，其中，appId用于表示不同的應(yīng)用，而appSecurity用于對訂單請求進行簽名。

當所述收款方服務(wù)器接收到所述下單請求后，根據(jù)以下簽名規(guī)則對訂單請求進行簽名，進而生成訂單信息。

簽名規(guī)則：

1，參數(shù)排序，將所有參數(shù)名按字母順序進行排序，若遇到相同首字母，則看第二個字母，沒有值的參數(shù)(如null和””情況)不要參與簽名；

2，參與簽名的數(shù)據(jù)不要做URL Encoding，一律以UTF-8編碼參與簽名；

3，參與簽名的數(shù)據(jù)中，必須有字段data_timestamp；

4，參數(shù)拼接，將所有參數(shù)按k1＝v1&k2＝v2&k3＝v3…格式進行拼接；

5，將第4步所得字符串后面加上“:”、appId、appSecurity，得到一個新的字符串，用md5對新字符串進行摘要計算，得簽名字符串(也即，具有簽名的訂單信息)。

步驟S300、所述客戶端將所述訂單信息按照預(yù)設(shè)的格式生成請求數(shù)據(jù)，并將所述請求數(shù)據(jù)發(fā)送至支付平臺(也即上述的第三方支付平臺)。

具體的，當所述客戶端接收到所述收款方服務(wù)器發(fā)送的訂單信息后，在所述訂單信息中添加二進制協(xié)議頭，以生成加密的請求數(shù)據(jù)，并將所述請求數(shù)據(jù)發(fā)送至所述第三方支付平臺。

在本步驟中，所述二進制協(xié)議頭包含有64個字節(jié)，其中，0-3字節(jié)表示appId；4-5字節(jié)表示接口編號；6-7字節(jié)表示版本號；8-39字節(jié)表示一個會話；40字節(jié)表示加密方式；41-42用于校驗；其他字節(jié)數(shù)保留。也即，所述請求數(shù)據(jù)包括二進制協(xié)議頭與具有簽名的訂單信息。

步驟S400、所述支付平臺解密所述請求數(shù)據(jù)，獲取所述訂單信息；驗證所述訂單信息的簽名，并在驗證成功后生成支付憑證；將所述支付憑證按照預(yù)設(shè)的加密方式進行加密，并將加密后的支付憑證發(fā)送至所述客戶端。

具體的，當所述支付平臺接收到所述請求數(shù)據(jù)后，先對所述請求數(shù)據(jù)進行解密分析，以獲得包含在所述請求數(shù)據(jù)中的具有簽名的訂單信息。然后對簽名進行驗證，當驗證驗證通過后，保存所述訂單信息，并根據(jù)所述訂單信息生成支付憑證。接著，在所述支付憑證中添加二進制協(xié)議頭，以加密所述支付憑證。最后，將加密后的支付憑證發(fā)送至所述客戶端。

在本步驟中，所述二進制協(xié)議頭包含有32字節(jié)，其中，0-1字節(jié)表示接口編號；2字節(jié)表示加密方式；3-4字節(jié)用戶校驗；8-11字節(jié)表示錯誤碼；其他字節(jié)保留。也即，鎖住支付憑證包括二進制協(xié)議頭與支付憑證的真實信息。

步驟S500、所述客戶端解密所述支付憑證，并根據(jù)所述支付憑證中的支付信息調(diào)用支付工具進行支付操作。

具體的，當所述客戶端接收到所述支付憑證后，解密所述支付憑證，以獲取支付憑證中包含的真實信息，并根據(jù)該真實信息調(diào)用支付工具(安裝于移動終端內(nèi)的應(yīng)用程序，比如，微信、支付寶、手機銀行等)進行支付操作。

本實施例的支付方法，通過對客戶端、收款方服務(wù)器及支付平臺之間的交互數(shù)據(jù)按照不同的方式進行加密，有效保證了交互數(shù)據(jù)的安全性，進而保證了提升了支付操作的安全性。

進一步的，如圖2及圖3所示，圖2為本發(fā)明支付方法另一實施例的流程圖；圖3為圖2中向所述收款方服務(wù)器反饋支付成功信息的步驟的流程圖。

基于上述實施例，在本實施例中，所述支付方法還包括：

步驟S600、支付成功后，所述支付平臺向所述收款方服務(wù)器反饋支付成功信息。

在本實施例中，所述向所述收款方服務(wù)器反饋支付成功信息的步驟包括：

步驟S610、所述支付平臺接收所述支付工具反饋的支付成功信息，并將所述支付成功信息發(fā)送至所述收款方服務(wù)器。

具體的，當支付成功后，所述支付工具向所述支付平臺反饋支付成功信息，以通知所述支付平臺對訂單狀態(tài)進行變更。所述支付平臺將訂單狀態(tài)變更為已付款后，向所述收款方服務(wù)器發(fā)送支付成功信息，以通知所述收款方服務(wù)器對訂單狀態(tài)進行變更。

步驟S620、判斷所述支付成功信息是否發(fā)送成功；

如果是，則流程結(jié)束。

如果否，則執(zhí)行步驟S630。

步驟S630、記錄發(fā)送失敗的原因，并在到達預(yù)設(shè)時間時，再次向發(fā)送所述支付成功信息。

具體的，當所述支付平臺向所述收款方服務(wù)器發(fā)送了支付成功信息后，判斷是否接收到相應(yīng)的反饋，如果否，則認定該次發(fā)送失敗。當判定為發(fā)送失敗后，記錄該次發(fā)送失敗的原因，并在預(yù)設(shè)的時間到達后，再次向所述收款方服務(wù)器發(fā)送該支付成功信息。如此循環(huán)，至發(fā)送成功，或發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)(比如8次)后停止發(fā)送。

步驟S640、當發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器發(fā)送預(yù)警郵件。

具體的，當發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器發(fā)送預(yù)警郵件

值得一提的是，在預(yù)警郵件中設(shè)置有回調(diào)機制，運營人員收到發(fā)送的預(yù)警郵件后，并更改了出錯的問題，可以在郵件中點擊“手動回調(diào)”按鈕，再次執(zhí)行上述通知收款方服務(wù)器支付成功信息的步驟。

本實施例的技術(shù)方案，通過多次送達及郵件預(yù)警機制，極大地提升了支付成功的幾率，保證了用戶的體驗度。

本發(fā)明還提出一種支付系統(tǒng)。本發(fā)明的支付系統(tǒng)應(yīng)用于移動終端，但不限于移動終端。下面以移動終端為例進行說明：

如圖4所示，圖4為本發(fā)明支付系統(tǒng)一實施例的模塊示意圖。

本實施例的支付系統(tǒng)包括客戶端110、收款方服務(wù)器120、支付平臺130及支付工具140；其中，所述客戶端110，用于接收用戶輸入的下單請求，并將所述下單請求發(fā)送至所述收款方服務(wù)器120；所述收款方服務(wù)器120，用于將所述下單請求按照預(yù)設(shè)的簽名規(guī)則進行簽名以生成訂單信息，并將所述訂單信息發(fā)送至所述客戶端110；所述客戶端110，用于將所述訂單信息按照預(yù)設(shè)的格式生成請求數(shù)據(jù)，并將所述請求數(shù)據(jù)發(fā)送至支付平臺130；所述支付平臺130，用于解密所述請求數(shù)據(jù)，獲取所述訂單信息；驗證所述訂單信息的簽名，并在驗證成功后生成支付憑證；將所述支付憑證按照預(yù)設(shè)的加密方式進行加密，并將加密后的支付憑證發(fā)送至所述客戶端110；所述客戶端110，用于解密所述支付憑證，并根據(jù)所述支付憑證中的支付信息調(diào)用支付工具140；所述支付工具140，用于執(zhí)行支付操作。

具體的，所述客戶端110安裝于移動終端內(nèi)。所述客戶端110為對應(yīng)所述收款方服務(wù)器120的應(yīng)用程序(比如，游戲客戶端110等)。用戶在移動終端上下載與游戲商提供的服務(wù)器對應(yīng)的客戶端110。當用戶需要對客戶端110進行充值等支付動作時，用戶可以通過客戶端110上的充值模塊觸發(fā)充值界面，并選擇或自行輸入充值類型、充值數(shù)額等，并確定?？蛻舳?10根據(jù)用戶輸入的充值類型與充值數(shù)額生成下單請求，并將所述下單請求發(fā)送至收款方服務(wù)器120。

所述收款方服務(wù)器120需要向第三方支付平臺130進行注冊，以獲取相關(guān)信息：appId、appKey、appSecurity等，其中，appId用于表示不同的應(yīng)用，而appSecurity用于對訂單請求進行簽名。當所述收款方服務(wù)器120接收到所述下單請求后，根據(jù)以下簽名規(guī)則對訂單請求進行簽名，進而生成訂單信息。

簽名規(guī)則：

1，參數(shù)排序，將所有參數(shù)名按字母順序進行排序，若遇到相同首字母，則看第二個字母，沒有值的參數(shù)(如null和””情況)不要參與簽名；

2，參與簽名的數(shù)據(jù)不要做URL Encoding，一律以UTF-8編碼參與簽名；

3，參與簽名的數(shù)據(jù)中，必須有字段data_timestamp；

4，參數(shù)拼接，將所有參數(shù)按k1＝v1&k2＝v2&k3＝v3…格式進行拼接；

5，將第4步所得字符串后面加上“:”、appId、appSecurity，得到一個新的字符串，用md5對新字符串進行摘要計算，得簽名字符串(也即，具有簽名的訂單信息)。

當所述客戶端110接收到所述收款方服務(wù)器120發(fā)送的訂單信息后，在所述訂單信息中添加二進制協(xié)議頭，以生成加密的請求數(shù)據(jù)，并將所述請求數(shù)據(jù)發(fā)送至所述第三方支付平臺130。所述二進制協(xié)議頭包含有64個字節(jié)，其中，0-3字節(jié)表示appId；4-5字節(jié)表示接口編號；6-7字節(jié)表示版本號；8-39字節(jié)表示一個會話；40字節(jié)表示加密方式；41-42用于校驗；其他字節(jié)數(shù)保留。也即，所述請求數(shù)據(jù)包括二進制協(xié)議頭與具有簽名的訂單信息。

當所述支付平臺130接收到所述請求數(shù)據(jù)后，先對所述請求數(shù)據(jù)進行解密分析，以獲得包含在所述請求數(shù)據(jù)中的具有簽名的訂單信息。然后對簽名進行驗證，當驗證通過后，保存所述訂單信息，并根據(jù)所述訂單信息生成支付憑證。接著，在所述支付憑證中添加二進制協(xié)議頭，以加密所述支付憑證。最后，將加密后的支付憑證發(fā)送至所述客戶端110。所述二進制協(xié)議頭包含有32字節(jié)，其中，0-1字節(jié)表示接口編號；2字節(jié)表示加密方式；3-4字節(jié)用戶校驗；8-11字節(jié)表示錯誤碼；其他字節(jié)保留。也即，鎖住支付憑證包括二進制協(xié)議頭與支付憑證的真實信息。

當所述客戶端110接收到所述支付憑證后，解密所述支付憑證，以獲取支付憑證中包含的真實信息，并根據(jù)該真實信息調(diào)用支付工具140(安裝于移動終端內(nèi)的應(yīng)用程序，比如，微信、支付寶、手機銀行等)進行支付操作。

本實施例的支付系統(tǒng)，通過對客戶端110、收款方服務(wù)器120及支付平臺130之間的交互數(shù)據(jù)按照不同的方式進行加密，有效保證了交互數(shù)據(jù)的安全性，進而保證了提升了支付操作的安全性。

進一步的，如圖圖5及6所示，圖5為實現(xiàn)本發(fā)明支付系統(tǒng)一實施例的流程示意圖；圖6為圖4中支付平臺一實施例的模塊示意圖。

基于上述實施例，在本實施例中，所述支付平臺130，還用于在支付成功后，向所述收款方服務(wù)器120反饋支付成功信息。

所述支付平臺130包括：執(zhí)行模塊132與判斷模塊134；其中，所述執(zhí)行模塊132，用于接收所述支付工具140反饋的支付成功信息，并將所述支付成功信息發(fā)送至所述收款方服務(wù)器120；所述判斷模塊134，用于判斷所述支付成功信息是否發(fā)送成功；所述執(zhí)行模塊132，還用于在所述支付成功信息發(fā)送失敗后，記錄發(fā)送失敗的原因，并在到達預(yù)設(shè)時間時，再次向發(fā)送所述支付成功信息；所述執(zhí)行模塊132，還用于在發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器120發(fā)送預(yù)警郵件。

具體的，當支付成功后，所述支付工具140向所述支付平臺130反饋支付成功信息，以通知所述支付平臺130對訂單狀態(tài)進行變更。所述支付平臺130將訂單狀態(tài)變更為已付款后，向所述收款方服務(wù)器120發(fā)送支付成功信息，以通知所述收款方服務(wù)器120對訂單狀態(tài)進行變更。

當所述支付平臺130向所述收款方服務(wù)器120發(fā)送了支付成功信息后，判斷是否接收到相應(yīng)的反饋，如果是，則結(jié)束，如果否，則認定該次發(fā)送失敗。當判定為發(fā)送失敗后，記錄該次發(fā)送失敗的原因，并在預(yù)設(shè)的時間到達后，再次向所述收款方服務(wù)器120發(fā)送該支付成功信息。如此循環(huán)，至發(fā)送成功，或發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)(比如8次)后停止發(fā)送。

當發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器120發(fā)送預(yù)警郵件

值得一提的是，在預(yù)警郵件中設(shè)置有回調(diào)機制，運營人員收到發(fā)送的預(yù)警郵件后，并更改了出錯的問題，可以在郵件中點擊“手動回調(diào)”按鈕，再次執(zhí)行上述通知收款方服務(wù)器120支付成功信息的步驟。

本實施例的技術(shù)方案，通過多次送達及郵件預(yù)警機制，極大地提升了支付成功的幾率，保證了用戶的體驗度。

需要說明的是，在本文中，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。

上述本發(fā)明實施例序號僅僅為了描述，不代表實施例的優(yōu)劣。

通過以上的實施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到上述實施例方法可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬件，但很多情況下前者是更佳的實施方式?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)(如ROM/RAM、磁碟、光盤)中，包括若干指令用以使得一臺終端設(shè)備(可以是移動終端，計算機，服務(wù)器，空調(diào)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述的方法。

以上僅為本發(fā)明的優(yōu)選實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運用在其他相關(guān)的技術(shù)領(lǐng)域，均同理包括在本發(fā)明的專利保護范圍內(nèi)。