TW202205834A - 電腦實施系統及方法 - Google Patents

Abstract

在一第一態樣中，本揭露內容提出用於實施用於與一區塊鏈相關聯之訊息或交易之一通道服務的電腦實施方法、裝置及系統，該通道服務經提供用於一或多個用戶端。該方法包含向一給定用戶端提供對一或多個功能之存取，該等一或多個功能能夠進行該給定用戶端與另一實體之間的直接通訊，該等一或多個功能包括(i)與用於傳輸資料之一或多個通道有關之通道功能或程序，及/或(ii)與使用該等一或多個通道被傳輸之該資料有關之訊息功能或程序。在一第二態樣中，本揭露內容提出用於實施對一通道服務之定址之電腦實施方法、裝置及系統，該通道服務諸如為該第一態樣中之該通道服務。使用與該通道服務相關聯之一通道的通訊係基於與通訊實體有關之定址密鑰而起始的。

Description

電腦實施系統及方法

發明領域

本揭露內容大體上係關於用於使用在實體之間進行通訊之一或多個通道來實施通道服務的方法及系統。特定言之，本揭露內容係關於但不限於經由或使用實體之通道來提供對一或多個功能或應用程式之存取，該等通道能夠進行或促進或允許用於交易或訊息之該等實體之間的同級間或直接通訊。

發明背景

在此文件中，吾人使用術語「區塊鏈」來包括所有形式之基於電腦之電子分散式分類帳。此等包括基於共識之區塊鏈及交易鏈技術、許可及未許可分類帳、共用分類帳、公用及私用區塊鏈及其變型。儘管已提議並開發了其他區塊鏈實施方案，但區塊鏈技術之最廣泛已知之應用係比特幣分類帳。儘管可在本文中出於便利性及說明之目的提及比特幣，但應注意，本揭露內容不限於關於比特幣區塊鏈之使用，且與任何種類之數位資產或數位資產之表示相關聯的替代性區塊鏈實施方案及協定屬於本揭露內容之範疇內。術語「用戶端」、「實體」、「節點」、「使用者」、「發送者」、「接收者」、「付款人」、「受款人」在本文中可指計算或基於處理器之資源。術語「比特幣」在本文中用以包括源自或基於比特幣協定之任何版本或變型。術語「數位資產」可指任何可轉移資產，諸如密碼貨幣、表示財產之至少一部分之符記、智慧型合約、許可證(亦即軟體許可證)，或用於媒體內容之DRM合約等。應理解，術語「數位資產」在整個此文件中用於表示可與值相關聯之商品，其可在自一個實體至另一實體之交易中轉移或作為付款提供。

區塊鏈係同級間電子分類帳，其經實施為由區塊構成之基於電腦之非集中式分散式系統，該等區塊又由交易構成。每一交易係資料結構且包括至少一個輸入及至少一個輸出，該資料結構對區塊鏈系統中之參與者之間的數位資產之控制的轉移進行編碼。每一區塊含有先前區塊之散列，使得區塊變為鏈接在一起以產生自一開始便已寫入至區塊鏈之所有交易的永久性不可變更之記錄。交易含有嵌入至其輸入及輸出中之被稱為指令碼的小型程式，其指定可如何及由誰存取交易之輸出。在比特幣平台上，此等指令碼係使用基於堆疊之指令碼處理語言來撰寫。

為了將交易寫入至區塊鏈，交易必須經「驗證」。網路節點(採擷器)執行工作以確保每一交易有效，其中由網路拒絕無效交易。安裝於節點上之軟體用戶端藉由執行其鎖定及解鎖指令碼而對未用交易(UTXO)執行此驗證工作。若對鎖定及解鎖指令碼之執行評估為真，則交易係有效的且接著交易經寫入至區塊鏈。因此，為了將交易寫入至區塊鏈，該交易必須i)藉由接收該交易之第一節點而驗證--若該交易經驗證，則節點將其中繼至網路中之其他節點；ii)經添加至由採擷器建構之新區塊；且iii)經採擷，亦即，經添加至過去交易之公用分類帳。

應瞭解，由採擷器執行之工作的本質將取決於用以維持區塊鏈之共識機制的類型。雖然工作量證明(PoW)與原始比特幣協定相關聯，但應瞭解，可使用其他共識機制，諸如權益證明(PoS)、權益委託證明(DPoS)、能力證明(PoC)、經過時間證明(PoET)、授權證明(PoA)等。不同共識機制改變在節點之間分佈採擷之方式，其中成功地採擷區塊之幾率取決於例如採擷器之散列動力(PoW)、由採擷器持有之密碼貨幣金額(PoS)、委託給委託採擷器之密碼貨幣金額(DPoS)、採擷器儲存密碼難題之預定解決方案的能力(PoC)、隨機指派至採擷器之等待時間(PoET)等。通常，採擷器具備用於採擷區塊之激勵或獎勵。比特幣區塊鏈例如用新發佈之密碼貨幣(比特幣)及與區塊中之交易相關聯的費用(交易費用)來獎勵採擷器。對於比特幣區塊鏈，經發佈之密碼貨幣金額隨時間而減少，其中激勵最終僅由交易費用組成。因此，應瞭解，交易費用之處置係用於將資料提交至諸如比特幣區塊鏈之公用區塊鏈的基礎機制之部分。

如先前所提及，給定區塊中之每個交易對區塊鏈系統中之參與者之間的數位資產之控制的轉移進行編碼。數位資產無需一定對應於密碼貨幣。例如，數位資產可與文件、影像、實體物件等之數位表示有關。向採擷器支付密碼貨幣及/或交易費用可簡單地充當用以藉由執行必要工作而維持區塊鏈之有效性的激勵。與區塊鏈相關聯之密碼貨幣有可能充當採擷器之安全性，其中區塊鏈自身係主要與除密碼貨幣以外之數位資產相關的交易之分類帳。在一些情況下，參與者之間的密碼貨幣之轉移有可能係由實體處置，該實體不同於及/或獨立於使用區塊鏈來維持交易之分類帳的實體。

一旦作為UTXO儲存在區塊鏈中，使用者可將相關聯資源之控制轉移至與另一交易中之輸入相關聯的另一位址。此轉移通常而非基本上使用數位電子錢包進行。此數位電子錢包可為裝置；實體媒體；程式；諸如桌上型電腦、膝上型電腦或行動終端之計算裝置上之應用程式(app)；或與諸如網際網路之網路上之區域相關聯的遠端代管服務。數位電子錢包儲存公用及私用密鑰且可用以追蹤與使用者相關聯之資源、符記及資產等之所有權；接收或使用數位資產；轉移可與數位資產，諸如密碼貨幣、許可證、財產或其他類型之資源相關的符記。

儘管區塊鏈技術因密碼貨幣實施方案之使用而最廣泛已知，但數位企業家正在探索比特幣所基於之密碼安全系統及可儲存於區塊鏈上以實施新系統之資料二者的使用。區塊鏈技術在區塊鏈可用於不限於密碼貨幣範圍之自動任務及程序時將非常有利。該等解決方案能夠利用區塊鏈之益處(例如，事件之永久性防篡改記錄、分散式處理等)，同時在其應用中變得更通用。

當前研究之一個領域係使用區塊鏈實施「智慧型合約」。此等智慧型合約係經設計以使機器可讀合約或協議之條款之執行自動化的電腦程式。不同於將以自然語言撰寫之傳統合約，智慧型合約係包含可處理輸入以產生結果之規則的機器可執行程式，該等規則接著可取決於彼等結果而使得動作得以執行。區塊鏈相關關注之另一領域係使用「符記」(或「彩色幣」)以經由區塊鏈來表示及轉移真實世界實體。可能敏感或秘密之物件可由符記表示，符記不具有可辨別之含義或值。符記因此充當允許自區塊鏈引用真實世界物件之識別符。

上文所提及之實例、應用程式及/或情形儘管利用區塊鏈之優勢以提供事件之永久性防篡改記錄；但是要求用戶端、用戶端實體、計算裝置或與用戶端相關聯之終端包括或實施軟體及/或硬體，或處理器/模組，諸如數位電子錢包，其用於實施用於管理數位資產、管理用於橢圓曲線數位簽名演算法(ECDSA)之密碼密鑰之功能性，該等密碼密鑰例如由比特幣中本聰願景(Bitcoin Satoshi's Vision；BSV)區塊鏈使用。另外，亦要求用戶端裝置能夠實施區塊鏈交易建構且下載BSV程式庫，以便能夠將資產或資產之控制轉移至另一實體或同級者。因此，用戶端不僅需要包括處理以實施該功能性，而且需要確保針對該等程序實施適當安全措施。

存在簡化之付款驗證(SPV)機制，其中應用程式需要來自區塊鏈之資訊，但不具有至其之直接鏈接，此係因為該等應用程式不運行完整之採擷器節點。該等SPV應用程式允許輕型用戶端檢驗交易是否確實包括於區塊鏈中，而無需下載整個區塊鏈。儘管此為有利的，但此仍呈現對於用戶端運行與關於區塊鏈之交易相關聯的區塊鏈之部分的要求，此係因為需要同級者當中之發送者或接收者來將交易最終提交至區塊鏈，且識別該交易是否已被採擷。

因此，希望實施安全、低複雜度、對使用者友好、有效且穩健之技術，無論計算上是否複雜，其皆將允許任何用戶端能夠直接(以同級間方式)以簡單、有序、快速、準確、可靠及安全之方式立即存取另一方且與另一方(亦即，與該用戶端相關聯之交易的交易對方或發送者/接收者)交互，該方式對用戶端而言在計算上及功能上均不太繁雜。更特定言之，希望以以下方式來利用分散式分類帳(區塊鏈)技術及記錄之增強的安全性、透明度及可靠性之優勢：使得任何用戶端計算裝置能夠確保與用戶端相關聯之任何資料、事件或數位資產可立即且安全地經採擷或易於寫入至區塊鏈中--藉此提供其可視需要產生、撰寫、更新、讀取或檢視的持續、防篡改且可審計之記錄；同時無需下載或運行區塊鏈之任何部分。

現已設計出該種經改良解決方案。本揭露內容藉由提出一或多種技術而解決以上技術問題，該等技術能夠藉由向通道或傳訊服務提供介面或功能之方法、裝置及系統進行用戶端之直接或同級間通訊，而該等用戶端無需實施區塊鏈之任何處理或功能性，同時仍能夠利用與其相關聯之所有優勢。資料或與用戶端相關聯之資訊可簡單地、安全地且立即經寫入至區塊鏈中或自區塊鏈獲得，同時使用戶端與區塊鏈解除關聯。

發明概要

在一第一態樣中，本揭露內容提出用於實施用於實體之間的訊息或交易之一通道服務的電腦實施方法、裝置及系統，該通道服務經提供用於一或多個用戶端。該方法包含向一給定用戶端提供對一或多個功能之存取，該等一或多個功能能夠進行該給定用戶端與另一實體之間的直接通訊，該等一或多個功能包括(i)與用於傳輸資料之一或多個通道有關之通道功能或程序，及/或(ii)與使用該等一或多個通道被傳輸之該資料有關之訊息功能或程序。

在一第二態樣中，本揭露內容提出用於實施對一通道服務之定址之電腦實施方法、裝置及系統，該通道服務經提供用於實體之間的訊息及交易，該通道服務經提供用於一或多個用戶端。該方法包含自一個實體提供至少一個服務/用戶端/採擷器端點，以及一相關聯之定址密鑰。獲得與用於通訊之另一實體相關聯之一定址密鑰。存取經提供至能夠使用用於傳輸資料或訊息之一通道進行該等實體之間的直接通訊之一或多個功能，其中使用該通道之通訊係基於該等定址密鑰而起始的。

貫穿本說明書，詞「包含(comprise)」或者諸如「包括(includes)」或「包含(comprises或comprising)」之變型應理解為暗示包括所陳述之要素、整數、步驟，或要素、整數或步驟之群組，但不排除任何其他要素、整數、步驟，或要素、整數或步驟之群組。

較佳實施例之詳細說明

藉由按比例調整使用分散式分類帳(區塊鏈)技術用於需要與應用程式相關聯之事件或交易之安全、可靠、可稽核、防篡改及可靠記錄的數個應用程式，用於參與實體之解決方案傳統上依賴於實時同步區塊鏈之完全複本，從而直接自區塊鏈識別與其應用程式相關之交易及嵌入式資料二者。然而，隨著應用程式之範疇、能力及安全演進且隨著區塊鏈按比例調整，變得清楚的是，需要允許當事方直接通訊之技術解決方案，且需要該等應用程式直接交換訊息，以便按比例調整且完全實現及利用與區塊鏈相關聯之優勢的全部潛力，且使得該種解決方案可用於任何類型之用戶端(不管計算上是否複雜)。

在一第一態樣中，本揭露內容提供用於實施用於實體之間的訊息或交易之通道服務或功能性的電腦實施方法，該通道服務經提供用於一或多個用戶端。在第一態樣之第一實施方案中，該方法藉由通道處理器實施。在一些實施例中，通道服務係指此後將在本文中描述之一或多個功能或程序或應用程式設計介面(API)。在一些實施例中，通道處理器可為一或多個計算裝置或伺服器或基於雲端之軟體解決方案，其可在單一遠端或分散式計算節點或實體上運行，該等計算節點或實體可藉由一或多個用戶端經由有線或無線通訊網路進行存取。在一些實施例中，用戶端可為實體、使用者終端/裝置或具有一或多個處理器之計算裝置或系統。在一些實施例中，用戶端可與數位電子錢包相關聯，該數位電子錢包允許用戶端管理諸如密碼貨幣及符記等之一或多個數位資產。在一些實施例中，可經由數位電子錢包將通道服務提供至一或多個用戶端當中之給定用戶端。然而，應理解，不具有數位電子錢包或數位資產之單獨應用程式的用戶端實體亦在本揭露內容之範疇內。在一些實施例中，尤其對於計算上複雜之用戶端，實施通道服務之通道處理器可與用戶端實體整合或為用戶端實體之部分。在此狀況下，通道處理器可經實施為用戶端內之針對該用戶端能夠進行通道服務功能性的模組。在一些實施例中，其他用戶端或實體亦可由該通道處理器伺服。

根據第一態樣之方法包括接收來自一或多個用戶端當中之給定用戶端的請求，該請求與通道服務有關。在一些實施例中，此請求可經由諸如網際網路之網路發送。在一些實施例中，用戶端可因此經由已知網際網路通訊協定與通道服務通訊。在一些實施例中，此請求係關於對給定用戶端向通道服務提供者或處理器登記之請求。該方法接著包括為給定用戶端建立帳戶，該帳戶具有特定於該給定用戶端之帳戶識別符及特定於該帳戶識別符之存取密鑰。經識別之此帳戶可由通道服務或由用戶端提供。總之，此等構成用於給定用戶端之帳戶之憑證，類似於用戶端ID及PIN或密碼對。在其他實施例中，此等憑證亦可基於非對稱密碼密鑰對，該非對稱密碼密鑰對包括與給定用戶端相關聯之私用及公用密鑰。

在登記後，該方法包括向給定用戶端提供對一或多個功能之存取，該等一或多個功能能夠進行該給定用戶端與另一實體之間的直接通訊，其中該等一或多個功能包括：與用於傳輸資料之一或多個通道有關之通道功能或程序；及/或與使用該等一或多個通道被傳輸之該資料有關之訊息功能或程序。在一些實施例中，一或多個通道能夠進行實體之間的直接或同級間通訊路徑或會話以用於訊息或資料之傳送。在大多數實施例中，每個通道僅存在二個實體。然而，亦可存在一些有限情況，其中第三實體亦可具備對相同通道之存取。

在此第一實施方案中，由於一或多個功能係呈針對用戶端提供之介面或存取點之形式，因此通道之一個實體將為用戶端，另一實體為希望與用戶端直接通訊之另一裝置或實體或使用者終端。在大多數實施例中，通道能夠進行全雙工，亦即，用戶端與另一實體之間的雙向通訊。在一些實施例中，可僅在一個方向上允許通訊，亦即，用戶端可能僅想要將訊息發送至另一實體或自另一實體接收訊息。

有利地，在第一態樣之情況下，BSV、比特幣、區塊鏈知識、ECDSA或特定於區塊鏈之其他密碼密鑰管理程式庫或交易建構軟體等皆不需要由用戶端實施以用於同級間交易。使用一或多個處理資源或使用者終端之用戶端簡單地登記以經由已知鑑認技術來使用通道服務，該等技術諸如用於出於帳戶登記之目的而驗證用戶端身分之密碼保護授權或標準公用密鑰基礎結構(PKI)。一旦已接收到來自通道服務之一或多個功能，用戶端便將僅能夠使用標準通訊/傳輸協定(亦即，網際網路協定，諸如超文字傳輸協定(HTTP)/傳輸控制協定(TCP)或類似者)與另一實體進行通訊。對於與企業相關聯或可表示組織(諸如諸如商家)之用戶端實體，該等用戶端可具有與之關於數個商品進行交易的大量其他實體(客戶)。因此，對於該等情形，極其有益的是，使用用於與一或多個客戶進行通訊之通道同時與實施同維持所有該等交易之記錄的區塊鏈相關之任何功能性解除關聯或解耦。在提供通道功能以及訊息功能之情況下，該等用戶端能夠將特定通道用於關於特定交易之特定客戶(諸如特定發票或對某些商品之查詢等)。

在一些實施例中，給定通道與特定通道識別符相關聯。同一用戶端可具有數個單獨通道，每一單獨通道具有其自身之唯一識別符。在一些實施例中，給定通道係關於與特定類型或主題相關聯之資料而與另一實體進行通訊，其中與通道中之每一主題相關聯之資料係在或包括於一或多個訊息或交易中。有利地，使特定通道用於特定主題會確保用戶端更清晰、更可靠及更靈活，尤其在用戶端類似於商家實體之狀況下，用戶端可具有需要單獨地追蹤或處理之若干主題(諸如交易數目或發票)。

亦有利地，通道之使用允許異步處理給定通道中之每一請求或訊息。此允許通道中之訊息之順暢及準確的不連續或延遲處理流，此係因為始終存在次序以及訊息之清晰度，因為通道特定於給定主題。此可特別適用於以下實施方案或情況：來自另一實體(或用戶端)之回應需要進一步繼續進行交易，但用戶端或其他實體可能不可操作或在線或能夠即刻提供該回應。因此，上述技術使得請求仍能被可靠地遞送並準確地處理且按次序使用通道來進行該遞送及處理，即使當至通道之當事方離線或無回應時亦如此，此係因為訊息在其下次在線或連接至網路時仍將存在於通道中，因此其可存取通道中之訊息。此外，不管通道中可能已提供多少其他訊息，該等訊息將可按遞送次序由另一實體存取。因此，儘管處理請求存在延遲或中斷，但通道中之訊息的該處理仍準確地並且順暢地完成，如同完全不存在延遲。在一些實施例中，可存在與同當事人離線或在線時之特定主題相關聯的特定通道相關聯之一或多個規則，例如(i)訊息將按到達次序而經回應，因此確保傳輸中無間隙或(ii)通道不能經完成，除非所有訊息亦經回應等以保持資料完整性。

在一些實施例中，用戶端為一或多個通道之擁有者，此等通道係基於藉由通道服務提供之一或多個功能的通道。在一些實施例中，一或多個功能係向給定用戶端發出或經提供至給定用戶端之應用程式設計介面(API)，該等API包括用於一或多個通道之通道API；及用於資料之訊息API，亦即，與同每一或給定通道相關聯之主題相關之訊息。API可理解為允許建立或管理實體(諸如，在此狀況下之用戶端)之應用程式或其他服務的存取應用程式之特徵或資料之端點、介面，或功能與程序之集合。在此狀況下，其將實施通道功能以及訊息功能。

在一些實施例中，該方法進一步包含以下步驟：針對用戶端向一或多個通道當中之給定通道發出一或多個存取符記，該等符記經組配以用於與另一實體安全通訊。該等一或多個存取符記與該給定通道或甚至該給定通道中之一或多個訊息有關。在一些實施例中，存取符記係特定於給定通道或給定訊息之API符記。存取符記，且特定言之API符記在一些實施例中可充當請求對服務或通道進行存取之實體或應用程式的唯一識別符。在一些實施例中，存取符記可被視為指派給個別用戶端帳戶之唯一鑑認憑證，且甚至可為針對個別通道或每個通道中之個別訊息而細化的。在一些實施例中，存取符記可使得用戶端可針對其通道中之每一者將此等符記提供至另一實體以用於鑑認。在本實施例中，存取符記可由用戶端或用於一或多個其他實體之通道服務產生或提供，該等一或多個其他實體各自具有不同通道。

在一些實施例中，通道處理器與HTTP API端點相關聯，且其中來自給定用戶端之請求係基於HTTP傳輸協定格式(例如HTTP、安全HTTP (HTTPS)等)而經接收。在第一態樣之一些實施例中，來自用戶端之經接收請求係HTTP GET或HTTP POST或HTTP PUT或HTTP PATCH請求，該請求包括特定於給定用戶端之用戶端識別符以及用戶端之特定通道的通道識別符(若針對用戶端存在的話)，或與該用戶端識別符及該通道識別符相關聯。

有利地，通道處理器API允許基於網路之互動介面，亦即，在一些實施例中，其可經實施為用於一或多個用戶端之網路服務，使得可使用基於網路之服務的標準網際網路通訊協定經由網際網路進行通訊。舉例而言，在一些實施例中，同級者之間或用戶端與通道服務之間的層之間的應用程式層級中之HTTP訊息或請求可基於任何基於標準網際網路之傳輸層協定來傳輸及接收。對HTTP傳輸協定或HTTP API之參考在本文中亦囊封所有標準網際網路通訊協定，諸如TCP/IP、UDP、HTTPS等。在一些實施例中，通道處理器經實施為表示狀態傳送(REST)端點。

在實施例中，其中可存在用於為一或多個用戶端提供通道服務之多於一個通道處理器，亦即，可存在與相同通道服務相關聯之分散式通道處理器或網路伺服器，該第一態樣之該方法進一步包含以下步驟：提供應用程式設計介面(API)轉換器，其用於執行以下步驟：以HTTP傳輸協定格式自用戶端接收請求；將經接收請求轉換成遠端程序呼叫(RPC)格式；以及將RPC請求發送至多個處理器當中之給定處理器，該給定處理器經組配以實施經接收請求。在回流路徑中，此實施例包括以RPC格式自給定通道處理器接收相關聯之回應，以及使用HTTP或類似傳輸協定轉換待發送至用戶端之各別回應。

此係有利的，因為其允許用戶端使用基於網路之平台API經由基於簡單HTTP之協定傳達與區塊鏈相關聯之請求，且順暢地提供與實施上文所描述服務但不使用用於網路服務之網際網路協定通訊標準進行通訊的節點或伺服器中之任一者的互操作性。實施於此實施例中之API轉換器不限於HTTPS至RPC，且反之亦然轉換。在回流路徑中，第一態樣之方法亦包括以RPC格式自各別處理器接收回應，且因此使用HTTP轉換各別回應以用於發送至用戶端上。因此，有利地藉由通道處理器實施經提議介面會使得用戶端及通道處理器能夠使用不同無線資料通訊協定及機制進行順暢通訊。

在一些實施例中，經指派或經提供用於用戶端之帳戶識別符係經提供用於給定用戶端之別名。有利地，為了使用戶端識別以及定址變得更簡單，已存在其中使用可儲存且更友好之別名而非一或多個用戶端實體之複雜的公用位址之機制。該種解決方案在美國專利申請第16/384696號中以nChain Holdings有限公司名義經提議。此等文件闡明基於別名之付款服務及相關聯協定(被稱作bsvalias付款服務)，其中別名用於目的地定址而非用戶端實體之公用位址。該種系統中之別名通常與發送/接收用戶端實體之域名相關聯，且可為URI或電子郵件地址。因此，只要發送者或實體知道或具備別名，則此對於bsvalias付款系統或基於另一別名之定址機制係足夠的。可例如使用諸如JavaScript物件表示法(JSON)文件之機器可讀資源中提供之指令將訊息發送至用戶端之別名，該等指令保存在用於bsvalias或其他付款服務之熟知URI或位置中。在本揭露內容之一些實施例中，多個用戶端中之一或多者可具有諸如上述之別名以識別針對每交易之同級者的各別其他實體，無論其是否與至區塊鏈之鏈接相關聯。

在第一態樣之一些實施例中，一旦用戶端已藉由通道服務登記且已藉由帳戶憑證及與通道服務相關聯之一或多個功能或API而經提供，通道處理器亦可提供特定於通道之一或多個功能或API。在此狀況下，該方法包括自給定用戶端接收請求，該請求與用於用戶端帳戶之通道相關聯。請求可包括例如與以下各者中之一或多者相關聯之存取或功能性： -          對列出與該給定用戶端之該帳戶有關的該等一或多個通道之一請求； -          對為該帳戶建立一通道之一請求； -          對刪除一經識別通道之一請求； -          對修正與一經識別通道相關聯之性質及/或權限之一請求； -          對產生用於一經識別通道之一通道存取符記之一請求； -          對撤銷用於一經識別通道之一通道存取符記之一請求。

在以上實施例中，第一態樣之方法包含基於用戶端帳戶識別符來驗證用戶端，該用戶端帳戶識別符可基於與在帳戶登記期間保存或指派之用戶端帳戶識別符及存取密鑰對應的記錄。該種記錄可與通道處理器相關聯。接著，基於用戶端之成功驗證，該方法包括另外或任擇地基於通道識別符判定自用戶端接收之請求是否係有效的步驟。此例如用以檢查彼通道是否基於經提供用於用戶端之通道API或基於包括於各別記錄中之一或多個設定或權限而在作用中。在一些實施例中，屬性或設定可指示給定用戶端是否允許存取用於通道之經請求服務之全部或部分。舉例而言，與用戶端識別符相關聯之一或多個權限層級可經提供於屬性或設定中。舉例而言，可允許給定用戶端請求服務以建立通道、在通道上發送/接收訊息，但可能不允許其修改、刪除或終止通道中之訊息；而另一用戶端可具有關於用於通道之一或多個服務之所有以上動作的權限。在另一實例中，可能拒絕建立用於已存在之主題之另一通道的請求，諸如現有發票數目，此可有利地防止詐騙訊息或通道係藉由冒充者或惡意當事方產生。

在一些實施例中，亦可存在進一步檢查以諸如基於核對和或散列值而檢查通道中之資料或訊息的完整性，該等核對和或散列值可進一步儲存至在通道中正發送或接收之訊息的每一者或設定數目個訊息。此確保惡意當事方不獲得對訊息或通道中之資料的存取及篡改。

在一些實施例中，驗證給定用戶端之身分的步驟可基於與用戶端相關聯之數位簽名。包括與每一用戶端相關聯之私用密鑰及公用密鑰(或公用位址)的密碼密鑰對可用於驗證對服務進行之請求實際上確實來源於給定用戶端，亦即，其中由私用密鑰簽名之資料僅可使用對應公用密鑰恢復或驗證。若驗證係基於數位簽名，則可使用並實施標準公用密鑰基礎結構(PKI)技術。

接著，基於與給定用戶端有關之帳戶識別符及存取密鑰係有效之一判定；且基於請求係有效之一判定，該方法包括處理對通道之請求；且包括將回應發送至給定用戶端，該回應包括存取與該請求相關之一或多個通道功能。

類似於與用於用戶端帳戶之通道相關之上述通道功能，在藉由用戶端接收與給定通道中之一或訊息相關聯之請求後，亦可使用類似程序將一或多個訊息功能或訊息API提供至用戶端。此等可包括向與訊息相關聯之以下請求提供一或多個API： -      對在該給定通道中測試新訊息之一請求； -      對擷取該給定通道中之一訊息之一請求； -      對標記或識別該給定通道中之已讀或未讀訊息之一請求； -      對在該給定通道中寫入一訊息之一請求。

在經提供回應中之訊息API的狀況下，此經提供至用戶端以用於控制或管理特定訊息或通道中之每一訊息的傳送、規則、權限。在一些實施例中，該等API可經提供以使得用戶端可與通道之交易對方(亦即，另一實體)共享此API。

在一些實施例中，回應中經提供之通道或訊息功能包括該帳戶之JavaScript物件表示法(JSON)經由超文字傳輸協定(HTTP) API，以能夠藉由用戶端或其它實體存取、建立及/或管理一或多個訊息。

有利地，對諸如特定於用戶端之給定通道的API或符記之功能的存取或對給定通道內一或多個訊息的存取之提供會確保對通道及訊息之控制以及管理在進行與另一實體之直接或同級間通訊時取決於用戶端。在一些實施例中，一旦API或功能經提供用於通道，則該控制可能無需經請求用於另一訊息，但可能需要經請求用於不同通道。此外，此確保可管理對特定通道或訊息之限制。舉例而言，若呈訊息或提醒形式之多個付款提醒經發送但由另一實體忽略，則可拒絕與用於該另一實體之其他通道相關聯之請求或拒絕對刪除或標記該等訊息為未讀之請求。

在一些實施例中，包括一或多個模組之通道服務程式庫可由用戶端之通道處理器提供，該等一或多個模組用於促進自通道處理器接收的用於與該給定用戶端相關聯之該帳戶的該(等)通道功能及/或該(等)訊息功能。

在本揭露內容之第一態樣之第二實施方案中，提供一種用於存取用於訊息或交易之通道服務的電腦實施方法，該方法藉由一或多個用戶端當中之給定用戶端之一或多個處理器實施。第二實施方案類似於第一實施方案，且與類似優勢相關聯。應注意，在一些實施例中，用於通道服務之用戶端亦可為一或多個採擷器節點，或與區塊鏈相關聯或運行全節點之實體。儘管本方法對於希望與另一實體直接通訊以免具有與區塊鏈相關聯之任何鏈路的用戶端而言特別有利，但此並不排除與其他完全或部分(SPV)電子錢包實施方案相關聯之採擷器節點或用戶端，以亦利用該種通道服務用於同級間通訊。舉例而言，重要且有用之應用程式可用於該等採擷器模式以使用通道來將採擷證明或內含證明直接發送至另一方，另一方可為通道處理器或與區塊鏈交易相關聯之另一實體。在此實施例中，當交易經提交(此可由用戶端或通道服務進行)以待由採擷器進行採擷時，採擷器可基於自通道處理器或用戶端接收之通道功能而使用通道提交返回交易之提交器的內含證明。有利地，藉此用戶端及通道處理器(或任何提交方)均不需要檢查執行區塊鏈之任何部分以驗證交易提交，此係由於該種證明現經由通道直接經遞送至提交器。此係有利的，此係因為其輔助待寫入至區塊鏈中之同級間應用程式的資源之可縮放性及最佳化，此係由於不再需要任何實體來檢查區塊鏈以存取其交易。

該方法包含以下步驟：發送與通道服務有關之請求，該通道服務藉由通道處理器實施，及回覆獲得針對給定用戶端建立之帳戶的帳戶憑證，該等帳戶憑證包括帳戶識別符及特定於該帳戶識別符之存取密鑰。接著，用戶端實施方法包括獲得對能夠進行給定用戶端與另一實體之間的直接通訊之一或多個功能的存取。如同第一實施方案，該等一或多個功能包括：與用於傳輸資料之一或多個通道有關之通道功能或程序；及/或與使用一或多個通道被傳輸之資料有關之訊息功能或程序。

在一些實施例中，如由用戶端實施之方法亦包括發送與用於給定用戶端之帳戶的通道或訊息有關之請求，使得特定API可經遞送至用戶端，如上文所論述。藉由用戶端在通道處理器之回應中接收之通道API用於有利地建立及/或管理一或多個通道。在一些實施例中，經接收回應包括存取符記，諸如用於如上所述之每一通道功能之通道API符記。在訊息功能之情況下，由通道處理器發出之用於用戶端帳戶的訊息API有利地使得給定用戶端及一或多個其他實體能夠交換訊息及/或自給定通道讀取資料及/或將資料寫入至給定通道。在一些實施例中，經接收回應包括存取符記，諸如用於每一訊息功能之訊息API符記。

在第一態樣之一些實施例中，為了用戶端使用通道服務及一或多個通道與交易對方或另一實體以及自通道處理器獲得之訊息功能或API進行互動，該方法包括識別進行通訊交換之另一實體的步驟。此可藉由使用對於另一實體已知或藉由另一實體提供之存取點或別名。

接著，使用自通道處理器接收之一或多個通道功能，建立用於通訊之通道及將與通道相關聯的一或多個存取符記發送至另一實體。此有利地使得能夠與另一實體安全、可靠且準確地設置通道，該另一實體可為商家用戶端之客戶。該方法接著包括使用自通道處理器接收之通道的一或多個訊息功能將關於交易之至少一個訊息寫入至通道，及將與該等一或多個訊息相關聯之一或多個存取符記發送至另一實體。此有利地確保任何回應之鑑認可經由存取符記發生。該方法包括接收與該通道中之該交易有關之至少一個回覆訊息。

回應於完成通訊交換(其可在接收到數位資產付款之確認後經指示)，亦即，類似於由另一實體進行之匯款註釋或對用戶端接收資金之確認，接著準備與通道相關聯之該經完成交易用於提交至區塊鏈。在一些實施例中，此經發送至通道處理器，該通道處理器可接著代表用戶端提交交易。藉此，有利地，同級間交易(用戶端或其他實體)中之當事方均不負責將經完成交易提交至區塊鏈。此可藉由通道處理器進行，且接著由與區塊鏈相關聯之一或多個採擷器節點採擷。因此，用戶端不需要運行與區塊鏈相關聯之任何功能性，甚至不需要SPV電子錢包或任何其他形式之數位電子錢包。在一些實施例中，若用戶端或實際上另一實體具有能夠提交交易之功能，則該提交可由該用戶端或另一實體進行。

在第一態樣之第三實施方案中，本揭露內容提供一種用於處理與區塊鏈相關聯之交易的電腦實施方法，該方法藉由與多個採擷器當中之一採擷器相關聯的一或多個處理器實施，該等多個採擷器以通訊方式耦接至為至少一個用戶端實施通道服務之至少一個通道處理器。如上文所提及，採擷器節點亦可存取用於促進與一或多個其他實體之同級間通訊之通道服務。此可為其是否為通道服務之用戶端之狀況，只要其接收通道或訊息API及/或自需要與採擷器直接通訊之另一實體評估與通道相關聯之符記。此對於數個區塊鏈相關聯之應用程式可為特別有利的，此係因為採擷器可接著使用通道以將用於經提交至區塊鏈之交易的默克爾樹內含證明直接發送至另一實體。此為有用的，此係因為其意謂不再存在對用戶端(諸如，商家或另一實體(諸如，客戶))或實際上通道服務之任何需求以必須搜尋區塊鏈來尋找該種交易。此係因為有利地，一旦經採擷，內含證明便可使用通道經直接發送至通道處理器或實際上用戶端或其他實體，亦即，無論哪個實體提交用於採擷之區塊鏈交易。

當然，採擷亦可在給定交易之採擷器並非為向通道服務登記之用戶端的情況下使用通道服務進行。在此狀況下，通道處理器或實際上提交交易之通道處理器可簡單地基於已提供至其之通道及訊息功能而使用通道服務建立用於待接收之採擷器內含證明的通道。採擷器接著變成該通道中之另一實體(接著，用戶端或通道API為第一實體)，且可簡單地接收訊息API及經由通道所需之存取符記。

本揭露內容之第二態樣係關於向用於同級間通訊之通道提供安全定址及加密。與第二態樣相關聯之態樣及實施例可針對實施於實體之間的一或多個同級間通道而單獨地實施。亦可結合上文所論述之實施例及實施方案(亦即，針對第一態樣之通道服務)來使用。第二態樣之以下實施例係關於如第一態樣中所提及之通道服務而論述，但應理解為不限於此。

在第二態樣之第一實施方案中，本揭露內容提出用於實施對通道服務定址之方法，該通道服務經提供用於訊息或交易，該通道服務經提供用於一或多個用戶端。該方法藉由通道處理器實施且包含以下步驟：自多個用戶端當中之給定用戶端接收請求，該請求與通道服務有關。接著，檢查對與給定用戶端有關之帳戶識別符及存取密鑰之有效性的判定。如上文關於第一態樣所論述，此檢查可基於儲存之憑證或實際上基於PKI技術而執行。該方法包括向用戶端提供服務端點。在一些實施例中，此可為用於通道服務之服務API或HTTP端點。該方法包括：提供與通道服務相關聯之至少一個服務定址密鑰；及獲得與用戶端相關聯之至少一個用戶端定址密鑰。定址密鑰可為靜態密鑰或短暫密鑰或二者，且可用於驗證各別端點之身分。接著，基於所接收請求，該方法包括向給定用戶端提供對一或多個功能之存取，該等一或多個功能能夠進行給定用戶端與用於資料或訊息之傳輸之另一通道(亦即，設定通訊路徑或會話或資料隧道)之間的直接通訊，其中使用通道之通訊可基於服務及/或用戶端定址密鑰來起始。

如關於第一態樣所論述，採擷器節點亦可將通道服務用作用戶端，且在此狀況下，在第二態樣中，以上方法以相同方式應用於亦為用戶端之採擷器。為了易於參考，與採擷器相關聯之端點及密鑰將被稱作採擷器定址密鑰及採擷器端點，此係因為第二態樣可就採擷經完成交易而論請求用戶端及採擷器二者(若用戶端不具有與區塊鏈之任何鏈路)。

有利地，本揭露內容之第二態樣之方法藉由實施通道服務及提供端點(諸如API端點)以及定址密鑰(諸如靜態密鑰及/或動態密鑰/短暫密鑰)而允許與用戶端相關聯之一或多個處理器跟網路服務一樣註冊及存取通道服務，而無將資料寫入或存取至區塊鏈中之任何要求。該等密鑰進一步使得鑑認或交握程序能夠在經由通道對訊息進行任何傳送之前起始，藉此藉由驗證建立通道所用於之當事方的身分而增加安全性，從而確保經由通道之所有通訊僅在二個經驗證實體之間發生。

在一些實施例中，交握程序包括獲得交握結果或型樣。基於交握結果或型樣，獲得共用秘密密鑰使得使用通道之直接通訊係基於共用秘密密鑰而經加密。此為進一步有利的，此係因為共用秘密密鑰係基於身分，亦即，通道經起始所針對之二個當事方或實體之定址密鑰。因此，僅各別有效及經鑑認當事方將能夠解碼經加密密文，藉此增加可靠性以及隱私，且對惡意當事方之冒充嘗試進行抵制。在此狀況下，當事方將為通道服務及另一方(亦即，用戶端)，針對另一方之用戶端與通道處理器之間的通訊係經由通道的。

第二態樣之第二實施方案係關於一種用於使用用於訊息或交易之通道服務實施對通道之定址的方法，該通道服務經提供用於一或多個用戶端，其中該方法藉由該等一或多個用戶端當中之給定用戶端之一或多個處理器實施。如上文所提及，採擷器節點亦可為用戶端，其用於利用用於促進與其他節點之同級間通訊的通道服務。該方法包括發送與通道服務有關之請求、藉由通道處理器實施之通道服務及獲得與通道服務相關聯之服務端點。該方法包括獲得與通道服務相關聯之至少一個服務定址密鑰及提供與給定用戶端相關聯之至少一個用戶端定址密鑰。在採擷器之狀況下，此可為採擷器定址密鑰。該方法接著包括獲得對一或多個功能之存取，該等一或多個功能能夠使用用於傳輸資料或訊息之通道進行給定用戶端與另一實體之間的直接通訊，其中使用該通道之通訊係基於服務及/或用戶端/採擷器定址密鑰而起始的。有利地，此使得用戶端以及服務端點能夠安全地驗證彼此之身分。針對第一實施方案論述之優勢同樣適用。

當通道待使用由通道處理器提供之功能與另一實體建立時，該第二態樣在由用戶端實施時包括識別用以進行通訊交換之另一實體的方法步驟。此可基於用戶端識別符或別名或任何其他已知方式，接著，使用自通道處理器接收之一或多個功能，該方法包括建立用於通訊交換之通道。該方法接著進一步包含使用所建立之通道執行以下步驟： 提供一用戶端端點； 獲得與該另一實體相關聯之至少一個第三方定址密鑰； 提供與該給定用戶端相關聯之至少一個用戶端定址密鑰； 基於該等用戶端及第三方定址密鑰使用該通道交換一或多個交握訊息； 基於一交握結果或型樣，獲得一共用秘密密鑰； 其中使用該通道之與該另一實體之該直接通訊係基於該共用秘密密鑰而經加密。

此有利地確保所有通訊現經鑑認且基於與用戶端以及另一實體相關聯之密鑰而受到保護。此外，此定址及鑑認態樣以及端對端加密之提供亦與已知雜訊協定架構相容。

在一些實施例中，服務、用戶端及/或採擷器之端點係HTTP API端點，且其中該端點使用安全HTTP (HTTPS)經遞送至用戶端。此有利地確保端點可經由返回至已知且受信任證書授權機構(CA)之一系列證書驗證。在一些實施例中，端點可為通用資源位置(URL)，其包括於對與通道服務相關聯之一或多個功能的請求之回應中。藉由以上操作，有利地，另一方之身分可藉由至少一方針對通道使用PKI或其他機制來已知並經驗證。

在一些實施例中，端點可為與通道之各別實體相關聯之別名，其中該別名特定於通道處理器且係由基於別名之定址服務提供，該定址服務具有可自經界定或熟知位置存取之機器可讀資源，該機器可讀資源包括與通道處理器有關之一或多個能力。該別名可為已知的或經提供至一或多個用戶端/採擷器，該別名與用於鑑認之非對稱密碼密鑰對相關聯。

藉由以上操作，有利地，二個當事方之身分可為已知的且藉由二個當事方使用PKI或其他機制來驗證。

本揭露內容之各態樣亦包括一種計算裝置，其包含處理器及記憶體，該記憶體包括可執行指令，由於由該處理器執行，該等可執行指令使得該裝置執行如上文所論述之電腦實施方法，其中該計算裝置與通道有關。

本揭露內容之各態樣亦包括一種計算裝置，其包含處理器及記憶體，該記憶體包括可執行指令，由於由該處理器執行，該等可執行指令使得該裝置執行如上文所論述之電腦實施方法，其中該計算裝置與用戶端有關。

本揭露內容之各態樣亦包括一種計算裝置，其包含處理器及記憶體，該記憶體包括可執行指令，由於由該處理器執行，該等可執行指令使得該裝置執行如上文所論述之電腦實施方法，其中該計算裝置與採擷器有關。

本揭露內容之各態樣亦包括系統，其包含至少一個通道處理器，該至少一個通道處理器經由通訊網路以通訊方式耦接至至少一個用戶端及至少一個採擷器，該至少一個通道處理器實施用於一或多個用戶端之通道服務，如上文所論述。

本揭露內容之各態樣亦包括一種電腦可讀儲存媒體，其上儲存有可執行指令，由於由電腦之處理器執行，該等可執行指令使得該電腦執行如上文所闡明之態樣及實施例中之任一者的方法。

現藉助於參考附圖進行圖示來描述一些特定實施例，在該等附圖中，相同附圖標號指代相同特徵。

與本揭露內容相關之上述態樣及實施例藉由以可擴展、安全且準確之方式實施用於該等應用及使用案例之通道服務來提供該種解決方案及安全、鏈外、當事方間(同級間/直接)應用程式傳訊機制，該方式使實體易於參與該直接通訊以進行實施及管理。該等態樣及實施例提供一種機制，當事方可經由該機制以安全方式進行通訊，甚至在當事方中之一者暫時離線的情況下亦如此。

存在用於實體之間的訊息遞送之熟知系統及機制。在下文簡要地論述此等：

電子器件郵件(電子郵件)： 作為在現代網際網路上運行之最老且最流行的傳訊應用程式中之一者，電子郵件提供許多積極解決方案，包括： •  定址、用戶端 •  連接性(用於推送之IMAP、或交換/ActiveSync) •  同步(IMAP或交換/ActiveSync) •  帳戶管理--基於操作者要求而非用戶端要求 •  儲存 •  安全性--用於鑑認(不關於應用中)

一些缺點意味著電子郵件不安全，無法擴展到足以與區塊鏈相關聯之應用程式一起使用： •  \替代性且更靈活且安全之定址不存在(僅電子郵件位址)，基於用於交易對方之主題的更可靠且獨立之構造不存在 •  如許多應用程式之不靈活或有限之技術範圍，尤其可與區塊鏈互操作之彼等應用程式使用機器可讀，亦即JSON經由HTTP，而電子郵件係自訂協定，其中許多安全私人以及公用之區塊鏈網路不允許發送電子郵件。 即時信使：

隨處可見、安全、可擴展、現代即時信使解決方案(諸如WhatsApp、電報及信號)適用於一些同級間應用。但所有此等解決方案皆由中央授權機構操作，所述中央授權機構出於任何原因而在任何時間對任何人皆有拒絕服務之權力。此與所有公用區塊鏈之真正本質不相容。

訊息代理人： 訊息代理人係支援各種傳訊範例之硬體器具或軟體中間軟體。有時被稱作企業服務匯流排(ESB)或整合匯流排，此等產品向企業提供發行者-訂戶遞送訊息。其通常提供一或多種適用機制，如： •  定址 •  連接性 •  帳戶管理 •  儲存、配額 •  安全性

然而，該等解決方案係專屬的且需要由常常在單一組織內之單一實體進行部署。因此，此等者亦不適合於分散式分類帳技術，尤其不適用於公用區塊鏈。

如上文所論述，本揭露內容之第一及第二態樣及實施例提議提供通道服務以經由使用針對許多應用程式之同級間通訊所提供之單獨可識別通道(亦即，通訊路徑或會話)來實施傳訊功能性。此可在數個應用程式及使用案例中實施，該等案例需要實體交換訊息，同時使參與實體不再具有任何鏈路或下載區塊鏈之任何部分。此等使用案例中之一些的實例在此文件中標題為「使用案例」之章節中解釋。

如上文所論述，個別通道有擁有者，該等擁有者係已向通道服務登記之用戶端，且該等用戶端獲得呈API形式之通道功能性以組配通道讀取/寫入權限。此等權限可例如為不允許未經鑑認之連接；且藉由可撤銷評估符記(亦即API密鑰或符記)之問題向通道及個別訊息提供相異讀取/寫入權限。如所論述，通道使用已知傳輸協定操作應用程式層級端對端加密協定，其保護其中傳輸之訊息。 第一態樣--通道服務之實施方案

用於提供如上文針對第一態樣所描述之通道服務的通道處理器可為平台即服務(PaaS)以及軟體即服務(SaaS)，其有利地提供用於一或多個用戶端之端對端(同級間)通訊或傳訊服務。

如上文所提及，請求可經由或使用網際網路通訊協定自用戶端經由用於通道處理器之存取點或API而經接收，此係因為API可經實施為網路服務，但是該方法不限於此。舉例而言，亦可使用與通道處理器相關聯之別名，亦即基於上文提及之bsvalias定址協定。圖1係關於本揭露內容之第一態樣，且描繪用於提供用於促進一或多個用戶端之同級間通訊之通道服務的電腦實施方法。圖1之方法藉由通道處理器實施，該通道處理器可包括一或多個通道處理器。

步驟102係關於來自用戶端之對通道服務之登記請求。步驟102描繪自多個用戶端當中之給定用戶端接收請求。如上文所提及，用戶端可為無任何用於與區塊鏈互動之功能性的用戶端，或具有諸如SPV電子錢包之有限功能性的用戶端，或甚至可為運行區塊鏈之完整複本的採擷器節點。因為通道處理器與由URI或別名識別之API端點相關聯，因此在此實例中，來自給定用戶端之請求可基於諸如超文字傳輸協定(HTTP)傳輸協定格式之標準網際網路協定。在一些實施例中，請求可包括用戶端之識別符以及所請求服務之識別符。

步驟104描繪為用戶端建立帳戶，該帳戶與帳戶憑證相關聯，諸如唯一用戶端或帳戶識別符及用於通道服務之存取密鑰，該密鑰可為密碼或PIN或甚至可為與用戶端相關聯之一或多個密碼密鑰。在一些狀況下，在登記時，記錄可基於帳戶憑證針對給定用戶端而建立。

與帳戶登記相關聯之實例方案可為：Openapi: 3.0.0 … components: securitySchemes: basicAuth:  # name for scheme type: http scheme: basic security --basicAuth: []

步驟106描繪提供對通道以及訊息功能之存取以使得用戶端能夠使用通道實施與任何其他實體之同級間直接通訊。通道可使用通道功能產生，且通道內之資料流可基於所提供之訊息功能。如上文所論述，此等可為通道API或訊息API。藉由帳戶憑證而受到保護之通道API允許帳戶持有者建立及管理通道。傳訊API允許帳戶持有者及交易對方(亦即，產生通道之其他實體或第三方)，或甚至諸如管理員(若用戶端為組織)之其他實體自通道讀取或寫入至通道。

因此，通道服務經由來自步驟104之帳戶憑證及/或用於每一帳戶之通道識別為客戶/使用者，該等帳戶各自具有唯一識別符。訊息串流(無論是一次性還是長期串流)經邏輯地配置成通道，該等通道又由單一帳戶(用戶端帳戶)擁有。一旦設定，用戶端便可經由帳戶憑證識別其自身至通道服務。

在一些實施例中，通道及訊息功能亦可包括用於帳戶持有者(用戶端)產生API符記之功能性，若通道擁有者需要用於其API之鑑認，則該等API符記可傳遞至第三方(訊息交換交易對方，用戶端希望與該訊息交換交易對方直接通訊)。因此，通道API可任擇地由API符記保護。

圖1a係根據第一態樣之通道服務之實施方案的示意性圖示。圖1a展示藉由多個n提供之通道服務，其中n＞1，通道處理器之數目對多個n個用戶端實施通道服務，每一用戶端分別與一或n個交易對方進行通訊。如所展示，每一用戶端可具有數個不同通道，每一通道用於n個主題中之特定主題。

圖2係關於本揭露內容之第一態樣，且描繪一種用於提供與關於特定通道或與給定用戶端帳戶相關聯之訊息的請求相關聯之API或功能的電腦實施方法。

步驟202描繪自給定用戶端接收與通道相關聯之請求。此請求可關於通道，亦即，藉由唯一通道ID識別或關於用於用戶端帳戶之新通道的通道。在一些實施例中，此請求可與特定訊息有關，亦即與特定通道中之主題1或2或n相關，如圖1a中所見。該請求包括用戶端之帳戶識別符，且可在提交圖1之步驟104中的帳戶憑證之後做出該請求。

在步驟204中，檢查用戶端之身分以查看用戶端是否為經登記以使用通道服務及由其提供之功能性的有效用戶端。在一些實施例中，此在登記期間可基於已知鑑認方法，諸如密碼保護之登入鑑認或其類似者。驗證可基於經接收之與記錄中之密碼匹配的密碼。在其他實施例中，基於密碼或定址私用/公用密鑰對之標準PKI技術亦可用以驗證可存在於步驟202中自用戶端接收之請求中的數位簽名。在此情況下，可藉由檢查是否可使用公用密鑰成功地恢復或驗證由私用密鑰簽名之請求來驗證用戶端之身分。

若用戶端身分無法經驗證或驗證失敗，則在步驟206中，並不進一步處理請求。

若用戶端經成功驗證，則在步驟204中，接著檢查步驟208中之服務之請求的有效性。此步驟用以確保給定用戶端實際上經授權以利用所請求服務。對此之權限或屬性可存在於用戶端之記錄中，以指示可提供至各別用戶端的一或多種類型之存取層級或服務。舉例而言，用戶端可具有建立通道及訊息但不修改訊息或刪除訊息之權限。此外，在一些實例中，在請求中識別之通道可能不正確或可能不與給定用戶端相關聯且因此無效。

若發現不允許該請求對用戶端進行請求或發現該請求在請求用戶端時係無效的，則在步驟210中，並不進一步處理請求。可在作出未經授權請求之情況下傳回的錯誤訊息之一些實例在下文給出： 錯誤碼401  帳戶憑證/數位簽名並非有效的。 錯誤碼402  帳戶憑證/數位簽名係有效的，但該請求未被授權。此係因為帳戶經停用，或帳戶持有者並非指定通道之擁有者。 錯誤碼403  未發現通道、API符記或其他資源。

應理解，上文所闡明之驗證用戶端及/或請求之實施例對於實施第一態樣之通道服務的操作而言並非必需的，但係有用的。在一些狀況下，僅可執行步驟202或步驟206中之驗證。在一些狀況下，無驗證經由通道處理器執行，此係因為此驗證可藉由其他方式進行(參看如上文所提及且自圖6向前詳細地進行之第二態樣)。

若在步驟208中發現請求有效，則接著在步驟212中，在作為請求或權限之部分而經請求或需要的情況下，將所請求通道功能及/或訊息功能以及其存取或API符記提供至用戶端。

下文展示與用於通道及/或訊息功能/API之請求相關聯的特定方案及/或格式之一些實例，連同用於由通道處理器提供之回應的實例方案。 1.   通道API：

通道API可為JSON經由HTTP API用戶端帳戶，其由用以服務之通道服務提供以建立及/或管理用於同級間通訊之通道。

在一些實施例中，所有API端點可能需要鑑認。特定鑑認方案可為實施方案判定的。常見形式包括諸如OAuth、基本鑑認及承載符記方法之方案。如上所述，通道API可任擇地藉由用戶端所提供或產生之API符記保護。

1. 如步驟204至208中所見，藉由帳戶憑證而保護之通道API允許帳戶持有者建立及管理通道。可提供以下API： 1.1     清單通道：傳回所有通道之清單

請求格式： GET /api/account/＜account-id＞/channel/list Authorization: …

回應格式： 201 OK Content-type: application/json Content-length: ... { "Channel": [ { "id": "...", "href": "https://example.org/channel/＜id＞", "public_read": true | false, "public_write": true | false, "locked": true | false, "sequenced": true | false, "head": ＜sequence＞, "retention": { "min_age_days": null | ＜number＞, "max_age_days": null | ＜number＞, "auto_prune": true | false }, "access_tokens": [ { "id": "...", "description": "...", "can_read": true | false, "can_write": true | false } ] } ] } 1.2 建立通道：建立由帳戶持有者擁有之新通道。

請求格式： POST /api/account/＜account-id＞/channel Authorization: ... Content-type: application/json Content-length: ... { "public_read": true | false, "public_write": true | false, "sequenced": true | false, "retention": { "min_age_days": null | ＜number＞, "max_age_days": null | ＜number＞, "auto_prune": true | false } }

回應格式： 成功建立之回應含有初始存取符記。在步驟204中之帳戶憑證及按照圖1之設置可用以存取通道API，但符記可用以存取傳訊API。出於其讀取及寫入至通道之目的，對此之此初始存取符記屬於帳戶持有者。 201 OK Content-type: application/json Content-length: ... { "id": "...", "href": "https://example.org/channel/＜id＞", "public_read": true | false, "public_write": true | false, "sequenced": true | false, "head": ＜sequence＞, "retention": { "min_age_days": null | ＜number＞, "max_age_days": null | ＜number＞, "auto_prune": true | false }, "access_tokens": [ { "id": "...", "token": "...", "description": "Owner", "can_read": true, "can_write": true } ] } 1.3 刪除通道

請求格式： DELETE /api/account/＜account-id＞/channel/＜channel-id＞ Authorization: ...

回應格式： 204 No Content

1.4  修正通道：更新通道後設資料及權限。 請求 POST /api/account/＜account-id＞/channel/＜channel-id＞ Authorization: ... Content-type: application/json Content-length: ... 回應

此請求類似於HTTP PATCH而起作用，且因此若不需要改變，則可省略來自訊息本體之欄位。 { "public_read": true | false, "public_write": true | false, "locked": true | false } 1.5 產生通道API符記

請求格式： POST /api/account/＜account-id＞/channel/＜channel-id＞/api-token Authorization: ... Content-type: application/json Content-length: ... { "description": "...", "can_read": true | false, "can_write": true | false }

回應格式： 此為將傳回符記值之唯一API調用。若符記丟失，則符記應被刪除且由新符記替換。 201 Created Content-type: application/json Content-length: ... { "id": "...", "token": "...", "description": "...", "can_read": true | false, "can_write": true | false }

1.6 撤銷通道API符記：建立新API符記以供第三方在存取此通道時使用。

請求格式： DELETE /api/account/＜account-id＞/channel/＜channel-id＞/api-token/＜token-id＞ Authorization: ...

回應格式： 204 No Content

傳訊API允許帳戶持有者及相關交易對方(用於通道之另一實體自給定通道讀取或寫入用於給定通道之訊息。

2. 以下訊息API可經提供為JSON經由HTTP API以用於帳戶持有者及其交易對方以交換訊息。

2.1 用於新訊息之測試通道 請求格式： HEAD /api/channel/＜id＞ Authorization: ＜api-token＞

回應格式： 201 OK ETag: ＜max-sequence＞

2.2  將訊息寫入至通道 請求格式： POST /api/channel/＜id＞ Authorization: ＜api-token ＞ Content-type: ... Content-length: ...

回應格式： a)   可接受 該訊息經寫入至通道。 201 已建立 b)   定序故障

通道經定序產生，且與請求相關聯之API符記尚未標記為讀取通道中之最新訊息。若其仍係適當的，則用戶端可需要重試寫入嘗試。 409 衝突 c)   訊息過大

在其中端對端加密例如基於雜訊協定保護所有訊息之實施例中，任何單一訊息之最大大小經設定為65536位元組。由於不應存在大於此之訊息，因此在一些實施例中，限制寫入至通道之任何訊息的最大大小可為有用的t。通道可拒絕大於此之訊息。 413 酬載過大 d)   超過儲存配額

已超出可在一些實施例中由服務業者設定之配額。用戶端請求可為有效的，但儲存服務此時不能滿足該請求。 507 不充足之儲存 2.3 取得通道中之訊息

傳回來自通道之所有訊息，任擇地將其過濾為未讀。 請求格式： GET /api/channel/＜id＞[?unread=true] Authorization: ＜api-token＞

未讀之查詢字串參數係任擇的。 回應格式： 201 OK Content-type: application/json Content-length: ... ETag: ＜max-sequence＞ { "messages": [ { "sequence": ＜number＞, "received": ＜unix-timestamp＞, "content_type": "...", "payload": "hex/base64" } ] }

2.4  將訊息標記為已讀或未讀：將訊息標誌為已讀或未讀。

請求格式： POST /api/channel/＜id＞/＜sequence＞[?older=true] Authorization: ＜api-token＞ Content-type: application/json Content-length: ... {"read": true | false }

任擇的早期參數允許用戶端在單個呼叫中將具有低於或等於經供應＜序列＞路徑自變數之序列的所有訊息標記為已讀。 回應格式： 201 OK

在步驟214中，在圖2之實施例中，可接著將經完成交易提供至通道處理器。此可藉由用戶端或藉由另一實體針對通道進行發送。在此實施例中，希望通道處理器將交易提交至待採擷之區塊鏈。然而，如先前所提及，本揭露內容不限於此。用戶端或另一實體替代地提交交易係可能的。

在本實施例中，通道處理器(或在其他實例中，提交器)可接著準備用於提交之交易，且接著繼續建立通道，在該通道上，內含證明(默克爾樹證明)最終將自採擷器經接收。此通道特定於通道處理器及採擷器。通道處理器(或提交器)接著將交易提交至採擷器，用於包括於區塊鏈網路(諸如，公用BSV區塊鏈)中。在一些實施例中，通道處理器(或提交器)亦可自採擷器接收提交回應。

在步驟216中，通道處理器經由在步驟214中建立之通道自採擷器接收包括於區塊鏈中之證明。因此，不需要通道處理器、用戶端或其他實體必須搜索用於該交易之區塊鏈，此係由於內含證明已由使用通道服務之採擷器提供。

與第一態樣相關之圖3的方法係由與用戶端相關聯之一或多個處理器實施。

在步驟302中，用戶端準備對通道服務之請求且將其發送至通道服務(通道處理器)，且在步驟304中，接收與用戶端帳戶之帳戶識別符及存取密鑰相關聯之所需帳戶憑證。在一些實施例中，用戶端識別符包括請求中之用戶端別名或識別符及/或服務識別符。此程序類似於圖1之步驟102及104。所準備之請求可由使用超文字傳輸協定(HTTP)或類似傳輸協定格式之用戶端發送。在一些實施例中，其經發送至實施為HTTP或REST API之通道處理器，且回應亦可以HTTP傳輸協定格式經提供至用戶端。

在步驟306中，關於特定通道或訊息之請求藉由用戶端發送，類似於圖2中之步驟202(在由通道處理器接收時)。在步驟308中，針對請求將具有通道或訊息API以及存取符記之回應(若需要)提供至用戶端。經發送之請求的實例以及對通道及/或訊息API所接收之回應在圖2中之步驟212中可見。

在步驟310中，接著使用來自步驟308中之通道處理器的所接收API來產生具有另一實體之通道。舉例而言，用戶端可為商家，且另一方可為客戶或交易對方，諸如數位資產之付款的資料或資產結轉必須針對特定發票或目的或商品進行。任何已知傳輸協定可經由通道用於此情形，該通道為用戶端及藉由API及存取符記保護之其他實體提供直接及端對端路徑。

所接收之API用以接著及/或讀取或寫入訊息或執行與通道相關聯之任何其他功能，及/或基於與通道相關聯之一或多個存取符記將訊息發送至另一實體。如上文所提及，存取符記可用以鑑認另一實體。在一些實施例中，訊息API亦經發送至另一實體以供經由通道進行通訊。

在步驟312中，經由通道接收來自另一實體或交易對方之回應。由於另一方已接收所有所需訊息API以及在先前步驟中接收存取符記，故此係可能的。

在步驟314中，回應於通訊交換之完成，在圖3之實施例中，用戶端將經完成交易發送至通道處理器以供提交至區塊鏈。如關於步驟214所論述，若用戶端或另一方與用於提交交易之功能性相關聯，則此亦係可能的。然而，不需要用戶端或其他當事方具有用於使用通道服務以供使用通道進行同級間通訊之任何該種功能性。

與第一態樣相關之圖4的方法係由與採擷器相關聯之一或多個處理器實施。

如上文所提及，採擷器有可能作為通道服務之用戶端，且在此狀況下，闡明於圖1至圖3中之程序適用於採擷器節點以及用戶端。然而，對於採擷器節點並非必需的係仍能使用由通道服務提供之通道的用戶端。舉例而言，若發送通道，則其可使用該通道，其中該通道為通道之另一實體。此情形在圖4中描繪。

在步驟402中，當藉由提交方將經完成交易提供至採擷器以用於採擷時(提交方可為通道處理器，或通道服務之用戶端)，提交器可使用通道服務建立通道以用於與採擷器直接通訊。在此狀況下，亦如圖3之步驟310中所論述，採擷器自提交器及任何相關聯訊息API及存取符記接收對通道之存取。

在步驟404中，採擷器繼續使用用於採擷之已知技術來採擷與區塊鏈相關聯之區塊中的交易，其中一些在本申請案之背景中加以論述。

在步驟406中，採擷器接著使用步驟402中之通道將區塊鏈中之交易的內含證明之證明直接發送至提交器，使得不存在對於提交器必須運行區塊鏈之複本或搜索區塊鏈以尋找該交易之要求。

在一些實施例中，該證明可為默克爾樹證明。此係經組織為樹之已知經鑑認資料結構。每一資料區塊之散列經儲存於基層上或葉之節點中，且樹或分支之每一內部節點含有根據其二個子代節點之散列而計算的密碼散列。樹之頂部節點(默克爾根)唯一地識別建構樹所依據之資料集。因此，默克爾樹允許有效內含證明，其中採擷器或證明器節點藉由使用審計路徑向其發送證明而向提交器或驗證器巢展示特定資料區塊為經鑑認資料集之部分。審計路徑含有重新計算默克爾根必要之節點散列，而不需要提交器揭露整個資料集。在比特幣SV中，區塊中所含之交易儲存於默克爾樹中。 第二態樣：安全性：定址及加密

本揭露內容之第二態樣係關於向用於同級間通訊之通道提供安全定址及安全性功能。與第二態樣相關聯之態樣及實施例可針對實施於實體之間的一或多個每同級通道而單獨地實施。亦可結合如上文所論述之實施例使用如根據第一態樣實施之通道服務。此為在下文關於圖5至圖7論述之實施例，但應理解，第二態樣之本揭露內容不僅限於如第一態樣中所描述且實施之通道服務。第二態樣係關於確保實體之同級間通訊路徑的安全性。一旦實例及第二態樣之相關使用案例係其與第一態樣之通道服務一起使用。

與第二態樣有關的圖5之方法係藉由與實施通道服務之通道處理器相關聯的一或多個處理器實施。

步驟502描繪自用戶端藉由通道處理器接收對於與通道服務相關聯之服務的請求之步驟。此亦可係如上文所提及之採擷器。此實施例中之請求允許請求實體存取用於藉由第三方或另一實體促進建立或管理一或多個通道或訊息之服務，如關於第一態樣所論述。

在步驟504中，如在圖2中之步驟204中闡明，與所請求用戶端相關聯之帳戶憑證經驗證。此係在推測請求用戶端向如圖1中闡明之通道服務登記的情況下。若用戶端鑑認無效，則步驟502中作出之請求在步驟506中被通道處理器拒絕。

在步驟508中，通道處理器發送用於通道服務之服務端點及與通道服務相關聯之至少一個服務定址密鑰。

服務端點可為超文字傳輸協定(HTTP)應用程式設計介面(API)端點，其中該端點使用安全HTTP (HTTPS)傳遞且可經由返回至已知且受信任CA之證書鏈而經驗證。此係有利的，此係因為其提供對通道服務之身分的鑑認，使得服務端點可實際上被信任為屬於通道服務，而非惡意當事方。

在一些實施例中，端點可為包括於來自先前例如在用戶端之帳戶設定或通道API或訊息API遞送期間發送之通道服務的訊息中之通用資源位置(URL)。此亦有利地確保端點可被信任，此係因為其提供於僅可與所請求之通道服務相關聯的訊息中。任擇地，亦可包括HTTP授權標頭值。當異步回覆將由用戶端(或通道中之另一方)產生時，可使用簡單HTTP POST呼叫。

可藉由以下實例性質來擴展物件方案：{ "noise_e": "＜hex encoded ephemeral public key＞", "callbackUrl": "https://example.com/api/channel/＜id＞", "authorization": "＜type＞ ＜credentials＞" }

在其他實施例中，服務端點可為與通道服務相關聯之別名，諸如如上文所提及之bsvalias服務，其中別名可基於與bsvalias或另一定址服務相關聯的機器可讀JSON資源來驗證。

在步驟510中，自用戶端獲得用戶端定址密鑰。服務定址密鑰及/或用戶端定址密鑰可為一或多個靜態「s」密鑰及/或短暫「e」密鑰。此為有利的，因為該等定址密鑰藉由用於端對端加密(諸如雜訊協定架構)之一或多個已知且安全密鑰交換協定相容。

在步驟512中，使用定址密鑰，在雙方之間(在此狀況下為通道處理器及用戶端)遵循交握程序。在一些實施例中，交握係基於設定在雜訊協定架構中之機制。雜訊為基於Diffie-Hellman (DH)密鑰協議之密碼協定的架構。雜訊協定提供解決除初始靜態密鑰分佈以外的所有要求之受重視、經審查、經採用之一系列密碼協定。雜訊協定架構用以藉由選擇在交握階段期間涉及靜態密鑰之構築體來建構方案，該方案解決鑑認、機密性及資料完整性。

雜訊相容性交握之概述如下文所闡明，如http://www.noiseprotocol.org/noise.html中所闡明： 雜訊協定以二個當事方交換交握訊息開始。在此交握階段期間，當事方交換DH公用密鑰且進行一連串DH操作，將DH結果散列至共用秘密密鑰。在交握階段之後，每一方可使用此共用密鑰來發送經加密輸送訊息。

雜訊架構支援交握，其中每一方具有長期靜態密鑰對及/或短暫密鑰對。雜訊交握由簡單語言描述。此語言由配置成訊息型樣之符記組成。訊息型樣經配置成交握型樣。

訊息型樣為指定包含交握訊息之DH公用密鑰及在發送或接收彼訊息時進行之DH操作的一連串符記。交握型樣指定包含交握之訊息之依序交換。

交握型樣可藉由DH函數、密碼函數及散列函數具現化以給出具體雜訊協定。

雜訊之核心為在交握期間由每一方維持之變數集合，及用於藉由依序處理來自訊息型樣之符記而發送及接收交握訊息的規則。

每一方維持以下變數： •s、e：本端方之靜態密鑰對及短暫密鑰對(其可為空的)。 •rs、re：遠端方之靜態密鑰及短暫公用密鑰(其可為空的)。 •h：交握散列值，其散列已經發送及接收之所有交握資料。 •ck：散列所有先前DH輸出之鏈接密鑰。一旦交握完成，鏈接密鑰便將用以導出用於輸送訊息之加密密鑰。 •k、n：加密密鑰k (其可為空的)及基於計數器之臨時標誌n。每當新DH輸出使得新ck被計算時，亦計算新k。密鑰k及臨時標誌n用以加密靜態公用密鑰及交握酬載。對k加密使用一些經鑑認加密及相關聯資料(AEAD)編密模式且將當前h值用作由AEAD鑑認覆蓋之相關聯資料。靜態公用密鑰與酬載之加密在交握階段期間提供一定機密性及密鑰確認。

交握訊息由繼之以酬載之一些DH公用密鑰組成。酬載可含有藉由應用程式選擇之憑證或其他資料。為了發送交握訊息，發送者指定酬載且依序處理來自訊息型樣之每一符記。可能之符記為： •「e」：發送者產生新的短暫密鑰對且將其儲存於e變數中，將短暫公用密鑰作為明文寫入至訊息緩衝器中，且散列公用密鑰連同舊h以導出新h。 •「s」：發送者將其靜態公用密鑰自s變數寫入至訊息緩衝器中，在k為非空之情況下加密該訊息緩衝器，且散列輸出連同舊h以導出新h。 •「ee」、「se」、「es」、「ss」：在發起者之密鑰對(由第一個字母判定是靜態的還是短暫的)與回應者之密鑰對(由第二個字母判定是靜態的還是短暫的)之間執行DH。將結果與舊ck一起散列以導出新ck及k，且n經設定為零。

在處理交握訊息中之最終符記之後，發送者接著將酬載寫入至訊息緩衝器中，在k為非空之情況下加密該訊息緩衝器，且散列輸出連同舊h以導出新h。

作為簡單實例，藉由交握型樣描述未經鑑認之DH交握： -＞ e ＜- e, ee

發起者發送第一訊息，該訊息僅為短暫公用密鑰。回應者發回其自身短暫公用密鑰。接著執行DH，且將輸出散列至共用秘密密鑰中。

應注意，在明文短暫公用密鑰之後，在第一訊息中發送明文酬載，且在明文短暫公用密鑰之後，在回應訊息中發送經加密酬載。本申請案可以發送其想要之任何酬載。

回應者可發送其靜態公用密鑰(在加密之情況下)且經由稍微不同型樣鑑認其自身： -＞ e ＜- e, ee, s, es

在此狀況下，最終ck及k值為二個DH結果之散列。由於es符記指示發起者之短暫密鑰與回應者之靜態密鑰之間的DH，因此藉由第二訊息之酬載的發起者之成功解密用以向發起者鑑認回應者。

應注意，因為加密係以AEAD模式進行，所以第二訊息之酬載可含有零長度密文，但酬載密文仍將含有鑑認資料(諸如鑑認標籤或「合成IV」)。第二訊息之酬載亦可用以遞送憑證以供用於回應者之靜態公用密鑰。

發起者可發送其靜態公用密鑰(在加密之情況下)，且使用交握型樣藉由一個額外訊息鑑認自身： -＞ e ＜- e, ee, s, es -＞ s, se

以下章節充實細節，且添加一些併發情況。然而，雜訊之核心係變數、符記及處理規則之此簡單系統，此允許一系列協定之簡明表達。

在步驟514中，基於上文闡明之交握，獲得共用秘密密鑰，該共用秘密密鑰接著又為用於通道之端對端加密的密鑰。在一些實施例中，不直接使用共用密鑰，且可另外存在亦可與在步驟512中之交握之後獲得的任何該種密鑰組合使用之其他程序及另外的密鑰導出、二級DH交換、雙棘輪等。

與第二態樣相關之圖6的方法係由與用戶端相關聯之一或多個處理器實施。

在步驟602中，藉由用戶端發送與通道服務相關聯之請求，且在步驟604中，在成功驗證之後，獲得與通道服務相關聯之一或多個功能，亦即，通道及訊息API等。此等步驟與圖3中之步驟306及308類似，且亦與圖5之步驟502及504相關。

在步驟606中，用戶端建立用於與交易對方或第三方(其他實體)進行通訊之通道。此類似於圖3之步驟310。

在步驟608中，經由所建立之通道將用戶端定址密鑰以及用戶端端點發送至另一實體。在步驟610中，自另一實體接收第三方定址密鑰。此等步驟類似於步驟508及510，不同之處在於並非通道處理器，而是用戶端經由通道將端點及定址密鑰提供至另一方。在一些實施例中，另一方可為採擷器、通道處理器或經由通道直接通訊所意欲且用戶端端點所提供至之某一其他第三方實體。

用於執行用於識別用於端對端加密之供使用的共用秘密密鑰之交握的步驟612及614類似於步驟512及514，不同之處在於交握係在用戶端與另一實體之間。

與第二態樣相關之圖7的方法係由與採擷器相關聯之一或多個處理器實施。

步驟702描繪自用於採擷經完成交易之提交器接收請求的採擷器。此請求可來自與藉由通道處理器實施之通道服務相關聯之通道處理器或用戶端。在一些實施例中，採擷器亦可為通道服務之用戶端。儘管在圖7之實施例中，通道處理器係提交器，但本揭露內容不限於此。

步驟704類似於步驟608，其中接收服務(提交器)定址密鑰及服務(提交器)端點。步驟706類似於步驟610，不同之處在於在此狀況下提供採擷器定址密鑰。

用於執行用於識別用於端對端加密之供使用的共用秘密密鑰之交握的步驟708及710類似於步驟512及514，不同之處在於交握係在採擷器與提交器之間。

圖8表示基於上文已解釋之關於本揭露內容之第一態樣以及第二態樣所論述之方法而使用通道(例如通道服務之用戶端與另一實體(交易對方)之間的同級間通訊/交易/交換)的訊息之實例流程。使用案例

此章節描述使用當事人間應用程式傳訊系統之數個現有現實世界情形，其中本揭露內容之態樣及實施例可經實施/使用/應用以實現上文關於第一及第二態樣所解釋之所有優勢。 A)  同級間交易：

為擴展密碼採用，密碼付款必須更接近於付款工作之頒佈，且特定言之，更接近於傳統上吾人如何在結帳櫃台處支付項目。客戶需要能夠花費BSV而無需在線，從而將商家之負擔置於廣播交易。為進行此操作，低頻寬SPV系統係適合之解決方案。客戶將具有可在大部分時間離線之電子錢包，其中僅能夠向具有所含之區塊標頭UTXO、輸入Tx及默克爾路徑之交易進行支付。另一方面，商家將具有可藉由中心集線器遍及位置分支、接收彼等付款及將其廣播至區塊鏈之系統。

該種同級間流程之示意性圖示可見於圖9中。發票 - 交易- 提交- 驗證 之此流程允許當事方在不必維持及檢驗比特幣SV區塊鏈之完整複本的情況下進行交易。

發送者及接收者系統可為複雜之解決方案，其中在伺服器側及始終接通連接性上進行進階密鑰管理，在此狀況下，發送者及接收者系統可回應於使用者請求而直接進行通訊。然而，發送者及/或接收者可為具有部分連接性之終端使用者裝置。在此配置中，發送者及接收者可不經連接且為同時可達。另外，在發送者及接收者二者為經部分連接之裝置的狀況下，其可皆在網路位址轉譯(NAT)組配之後，此將防止其能夠直接通訊，即使二者皆同時在線亦如此。

如藉由適合於交易之同級間交換的本揭露內容之通道服務所提供的解決方案有利地允許同級者在交易對方離線時交換訊息，且以其中在二個當事方之間不存在直接路由之部署。

B)   開發票： 開發票允許交易方自接收者向發送者直接發出付款之請求。邏輯地，發票由以下構成： •發佈者細節 •發票編號或付款請求標號 •付款目的地指令碼 •應付金額 •返迴路徑

針對開發票使用案例實施本揭露內容之通道服務有利地滿足以下要求： •定址：發票發佈者必須能夠定址發票以遞送至發票接收者，且發送者必須能夠隨後將付款交易遞送至發佈者 •機密性：發票可為私人的及/或商業上敏感的，且不必為在交易方之外的任何第三方可視 •鑑認：當事方必須能夠在任何訊息交換中鑑認交易對方，以便發送者驗證發票源(接收者)之合法性，且以便發票源藉由與另一方共用細節而不會違反發送者之隱私。 •資料完整性：訊息必須為顯竊啟的，使得發送方可知曉經接收之發票自藉由接收者發佈時起尚未經修改，例如修改付款目的地、應付金額或所要求之發佈者細節

C)   付款通道： 付款通道為用於將交易對方風險降低至幾乎零之鏈外付款協商之技術。付款通道之典型用途係其中需要低值、高頻率計量之帳單的情形。該等付款情形之一些實例包括： •公用Wi-Fi存取 •串流媒體(影片、體育事件) •停車 •預付家用設施(電、氣、水)

付款通道之一個建構在本質上類似於信用卡預授權，其中供應商或商家可確保在客戶仍受保護以免商品或服務無法送達時保留資金。

在此建構中，建構將資金完全支付至供應商之初始融資交易。在提交此交易以用於包括至比特幣SV區塊鏈之前，建構退款交易，其將所有資金返回至客戶。此退款交易進一步受限時鎖約束，限時鎖經設定得足夠久遠以允許提供商品或服務來結束交易。

若當事方皆不採取任何另外動作，則客戶可確定一旦限時鎖到期，「預授權」資金將返回至其。

一旦服務供應開始，便建構新交易，其將預授權資金付回至客戶及供應商二者，其中客戶:供應商付出之比率

係經過之時間單位與每單位價格之函數(例如，每秒1000 satoshis)。此付出交易係由客戶不斷地更新且傳輸至供應商，作為客戶接收下一單位商品或服務之交換。

此不斷更新之交易亦受限時鎖約束，該限時鎖經設定於服務供應之預期結束與完整客戶退款交易激活之間的某處。

若任一方中途停止交易，則對任一方之最大損失為帳單之一個時間單位之值，在此實例中，該損失對客戶為1000 satoshis的損失，或對商家為價值1000 satoshis之商品或服務的損失。此分單付出交易之最新版本可由任一方提交以用於包括於比特幣SV區塊鏈中而不管交易對方之回應。

若付款通道結束，則商家或服務提供者將已充分供應商品或服務，且客戶將已支付正確金額。服務提供者可提交分單交易之最終版本以確定付款通道。

此使用案例表示幾乎完全鏈外之解決方案，其中僅「預授權」交易及任一結算交易經最適合地廣播至比特幣SV網路。

針對付款通道使用案例實施本揭露內容之通道服務有利地滿足以下要求： •定址：客戶及服務提供者必須能夠基於某一穩定目的地交換訊息 •鑑認：儘管此構造將交易對方風險降低至幾乎為零，但當事方必須能夠鑑認彼此，此係因為懲罰條項可導致一方採取動作與另一方作對；當事方必須確保其與哪方針對付款通道之生命週期進行通訊 •資料完整性：訊息必須可經驗證，此係因為其經發送以防第三方「陷害」交易方中之一者違犯合約或其他懲罰 •實時：付款通道可以高頻率在低值增量上操作(儘管並非全部將會如此)；對於其中時間單位短之情形，有必要更新待(偽)即時自客戶路由至供應商之分單交易，以便防止中斷服務感知未付款

D)   多重簽名電子錢包： 多重簽名電子錢包保護具有指令碼之資金，該等指令碼需要來自經界定群組內之多個當事方的呈簽名形式之授權。無論傳統的(有時稱為「裸」 ) OP_CHECKMULTISIG是否基於較新累加器多重簽名 構造，電子錢包可經組配以需要群組之子集提供授權，其中彼子集之大小在1至每一方範圍內。此有時被稱作N 之 M 多重簽名 。

直至M 個簽名應用於多重簽名保護之基金的花費為止，花費其之交易在比特幣規則下並非有效。此意謂未經簽名或經部分簽名之交易無法經由比特幣SV網路在授權方之間經傳遞。另外，即使此情形係可能的，這將與當前按比例調整方案(包括同級間交易及SPV模型)相反。

群組中之當事方因此需要能夠在彼此之間傳遞交易以及內容(為何花費此資金，以及向誰支付？)，直至已給出足夠授權且花費交易變得有效為止。其可接著經傳遞至資金接收者或經提交用於採擷。圖10中可見此情形之實例示意性流程。

針對多重簽名使用案例實施本揭露內容之通道服務有利地滿足以下要求： •定址：當事方必須能夠藉由某處置將交易(及內容)投送至彼此 •鑑認：當事方必須能夠鑑認其從何接收了授權請求，以便徹底地拒絕詐欺花費請求 •資料完整性：內容及交易必須如由起始方呈現給群組

另外，群組中之當事方可使用部分連接與完全連接之本端用戶端軟體之任何混合，且本端用戶端軟體可歸因於NAT部署而不可使用。任何傳訊解決方案必須能夠克服此等障礙。

E)   安全多方計算： 安全多方計算(亦稱為安全計算、多方計算(MPC)或隱私保護計算)係密碼子域，其目的係建立用於當事方以經由其輸入聯合地計算函數同時保持彼等輸入私密性的方法。不同於其中密碼保證通訊或儲存之安全性及完整性且對手(發送者及接收者上之竊聽者)在參與者之系統外部的傳統密碼任務，此模型中之密碼保護參與者彼此之隱私。

解決方案開始呈現藉由計算私用密鑰作為多方計算之部分來增強基於私用密鑰之系統的安全性。完成此協定(有時被稱作無交易商秘密分佈 )產生持有私用密鑰之份額 的多個當事方、裝置或系統。第二協定，臨限簽名 ，進一步允許持有密鑰份額以進行合作之彼等當事方以經由訊息產生有效ECDSA簽名。

自起始至簽名完成，私用密鑰從不在單一地點經金屬化。此不僅向多重簽名方案提供類似層級之安全性，而且藉由自區塊鏈隱藏當事方之數目(及相對於一些多重簽名方案之彼等當事方的公用密鑰)而提供增強之隱私。

針對安全多方計算使用案例實施本揭露內容之通道服務有利地滿足以下要求： •機密性：若任何當事方對之間的任何訊息，甚至相同群組內之彼等訊息由任何其他當事方觀測到，則MPC之安全性中斷 •鑑認：當事方必須能夠在任何訊息交換中鑑認交易對方，以防止經由中間者攻擊或類似者而破壞機密性 •資料完整性：訊息必須係顯竊啟的，使得當事方可知曉經接收之訊息在自會話交易對方進行傳輸期間尚未經更改

視特定應用程式而定，包括私用密鑰份額及其他中間狀態之秘密材料可駐存於具有部分連接性之終端使用者裝置上。不論發送者及接收者之連接狀態如何，當事方對之間的訊息必須經遞送。

F) 裝置同步： 考慮其中界定以下實體之系統模型： •帳戶，其在邏輯上保存秘密及/或資金 •使用者，其表示具有代表帳戶起作用之權限的個人，其中帳戶具有一或多個使用者 •裝置，其為使用者所擁有，該使用者可具有多個裝置

在該種系統中，許多鑑認及授權方案係可能的。在一個模型中，所有帳戶秘密，諸如私用密鑰或對稱密鑰係系統管理的。

使用者使用一或多個充分理解之方案(諸如，密碼、TOTP/鑑認器應用程式、智慧卡，及/或硬體密鑰)針對該種系統進行鑑認。一旦經驗證，使用者便可在其控制下登記一或多個裝置，諸如桌上型或膝上型電腦、平板電腦或智慧型電話。愈來愈通常，終端使用者裝置特徵係安全工作區域 ，其保護免受具有防篡改硬體之秘密(諸如私用密鑰)之損失。安全工作區域操作可進一步受諸如生物識別之額外因素保護。

一旦經登記，裝置通常經由詰問-回應協定及數位簽名將其自身識別至系統，其中本端裝置密鑰產生於本端裝置安全工作區域中且從不自其輸出。就此而言，此等密鑰以類似於諸如TLS之SSL的方案中之用戶端證書的方式起作用。

使用者可藉由對其裝置進行本端鑑認及將動作發佈至系統來授權系統內待採取之動作，其中系統將裝置辨識為已登記的。系統接著可使用系統管理之秘密、私用密鑰(或其份額)及針對系統管理之資金來執行動作。

在另一模型中，諸如私用密鑰之秘密並不由系統管理，但替代地由使用者之裝置管理。

對於部署端對端加密之服務或應用程式，通常存在交握階段，其常常涉及跟隨有對稱密鑰導出程序之密鑰交換協定。可使用來自僅一個裝置(尤其短暫密鑰)之密鑰來施加密鑰交換協定，且其他彼等密鑰可全部在安全工作區域內經管理。在交握協定結束時，僅使用者之裝置中之一者瞭解對稱密鑰。

可以二種方式中之一者解決使帳戶之明文或經由端對端加密通道所接收之使用者層級訊息同步的問題。在二種情況下，裝置一定已經歷類似交握協定以成對地在其之間建立端對端加密通道，從而形成裝置對裝置通道之網格。

一旦建立了裝置網格，則已成功地完成原始第三方交握之裝置與使用者之其他裝置共用所得對稱密鑰，或裝置解密通道訊息，接著在將該等訊息轉遞至其他裝置上之前將其重新加密。現今在產品及服務中發現二個模型。

針對裝置同步使用案例實施本揭露內容之通道服務有利地滿足以下要求： •定址：裝置對必須能夠定位彼此 •鑑認：裝置對必須確定任何訊息交換中之交易對方係預期通道交易對方 •機密性：在裝置對外部之當事方皆不可學習裝置之間所交換之秘密或私用訊息 •資料完整性：干擾裝置之間訊息分佈之任何嘗試不准導致裝置同步錯誤材料 •同步：裝置不准嘗試同時回覆外部交握程序，否則(良好建構之)交握會在偵測到衝突協定訊息後發生故障

現轉而參看圖11，提供計算裝置2600之例示性簡化方塊圖，該計算裝置可用於實踐本揭露內容之至少一個實施例。在各種實施例中，計算裝置2600可用以實施上文所繪示及描述之系統中之任一者。舉例而言，計算裝置2600可經組配以用作圖式之DBMS之一或多個組件，或計算裝置2600可經組配為與給定使用者相關聯之用戶端實體，該用戶端實體產生對於由圖11之DBMS管理之資料庫的資料庫請求。因此，計算裝置2600可為便攜式計算裝置、個人電腦，或任何電子計算裝置。如圖11中所展示，計算裝置2600可包括具有快取記憶體之一或多個層級的一或多個處理器以及可經組配以與包括主記憶體2608及持久儲存器2610之儲存子系統2606進行通訊的記憶體控制器(共同地標記為2602)。主記憶體2608可包括如所展示之動態隨機存取記憶體(DRAM) 2618及唯讀記憶體(ROM) 2620。儲存子系統2606及快取記憶體2602且可用於儲存資訊，諸如與如本揭露內容中所描述之交易及區塊相關聯的細節。處理器2602可用以提供如本揭露內容中所描述之任何實施例的步驟或功能性。

處理器2602亦可與一或多個使用者介面輸入裝置2612、一或多個使用者介面輸出裝置2614及網路介面子系統2616進行通訊。

匯流排子系統2604可提供用於使得計算裝置2600之各種組件及子系統能夠按預期彼此進行通訊之機制。儘管匯流排子系統2604經示意性地展示為單一匯流排，但匯流排子系統之替代性實施例可利用多個匯流排。

網路介面子系統2616可將介面提供至其他計算裝置及網路。網路介面子系統2616可充當用於自其他系統接收資料及將資料自計算裝置2600傳輸至其他系統之介面。例如，網路介面子系統2616可使資料技術員能夠將裝置連接至網路，使得資料技術員可能夠在處於諸如資料中心之遠端位置時將資料傳輸至裝置及自裝置接收資料。

使用者介面輸入裝置2612可包括：一或多個使用者輸入裝置，諸如鍵盤；指標裝置，諸如整合式滑鼠、軌跡球、觸控板或圖形平板電腦；掃描器；條形碼掃描器；觸控式螢幕，其併入至顯示器中；音訊輸入裝置，諸如語音辨識系統、麥克風；及其他類型之輸入裝置。一般而言，使用術語「輸入裝置」意欲包括用於將資訊輸入至計算裝置2600之所有可能類型的裝置及機構。

一或多個使用者介面輸出裝置2614可包括顯示子系統、印表機或諸如音訊輸出裝置之非視覺顯示器等。顯示子系統可係陰極射線管(CRT)、諸如液晶顯示器(LCD)之平板裝置、發光二極體(LED)顯示器，或投影裝置或其他顯示裝置。大體而言，使用術語「輸出裝置」意欲包括用於輸出來自計算裝置2600之資訊之所有可能類型的裝置及機制。舉例而言，一或多個使用者介面輸出裝置2614可用以呈現使用者介面以在使用者與應用程式之互動可係適當的時促進此互動，該等應用程式執行所描述之處理程序及其中之變化。

儲存子系統2606可提供電腦可讀儲存媒體，該電腦可讀儲存媒體用於儲存可提供本揭露內容之至少一個實施例之功能性的基本程式設計及資料構建。應用程式(程式、程式碼模組、指令)在由一或多個處理器執行時可提供本揭露內容之一或多個實施例的功能性，且可儲存於儲存子系統2606中。此等應用程式模組或指令可由一或多個處理器2602執行。儲存子系統2606可另外提供用於儲存根據本揭露內容所使用之資料的儲存庫。舉例而言，主記憶體2608及快取記憶體2602可提供用於程式及資料之揮發性儲存器。持久儲存器2610可提供用於程式及資料之持久性(非揮發性)儲存器且可包括快閃記憶體、一或多個固態驅動機、一或多個磁性硬碟驅動機、具有相關聯可移式媒體之一或多個軟碟驅動機、一或多個光學驅動機(例如CD-ROM或DVD或藍光光碟)、具有相關聯可移式媒體之驅動機及其他類似儲存媒體。該程式及資料可包括用於實行如本揭露內容中所描述之一或多個實施例之步驟的程式以及與如本揭露內容中所描述之交易及區塊相關聯的資料。

計算裝置2600可為各種類型，包括攜帶型電腦裝置、平板電腦、工作站或下文所描述之任何其他裝置。另外，計算裝置2600可包括可藉由一或多個埠(例如，USB、頭戴式耳機插口、雷電型連接器等)連接至計算裝置2600的另一裝置。可連接至計算裝置2600之裝置可包括經組配以接受光纖連接器之多個埠。因此，此裝置可經組配以將光學信號轉換成可藉由將裝置連接至計算裝置2600之埠傳輸的電信號以供處理。由於電腦及網路不斷改變之本質，出於說明裝置之較佳實施例之目的，圖11中所描繪之計算裝置2600之描述僅意欲作為特定實例。具有比圖11中描繪之系統多或少之組件的許多其他組配係可能的。經列舉之實例實施例

本揭露內容特此基於與上述態樣相關之以下條項來論述，該等條項在本文中經提供作為例示性實施例以用於較佳地解釋、描述及理解所主張之態樣及實施例。

1. 一種用於實施用於訊息或交易之一通道服務之電腦實施方法，該通道服務經提供用於一或多個用戶端，該方法藉由一通道處理器實施且包含以下步驟： 自該等一或多個用戶端當中之一給定用戶端接收一請求，該請求與該通道服務有關； 為該給定用戶端建立一帳戶，該帳戶具有特定於該給定用戶端之一帳戶識別符及特定於該帳戶識別符之一存取密鑰； 向該給定用戶端提供對一或多個功能之存取，該等一或多個功能能夠進行該給定用戶端與另一實體之間的直接通訊； 其中該等一或多個功能包括： 與用於傳輸資料之一或多個通道有關之通道功能或程序；及/或 與使用該等一或多個通道被傳輸之該資料有關之訊息功能或程序。

2. 如條項1中所闡明之方法，其中一給定通道與一通道識別符相關聯，該給定通道經組配以用於關於與一特定類型或主題相關聯之資料而與另一實體通訊。

3. 如條項2中所闡明之方法，其中與該給定通道相關聯之資料係在或包括於一或多個訊息或交易中。

4. 如前述條項中任一項所闡明之方法，其中該給定用戶端係該等一或多個通道之擁有者，該方法進一步包含以下步驟：向該等一或多個通道當中之一給定通道發出一或多個存取符記，該等一或多個存取符記經組配以用於與另一實體安全通訊，該等一或多個存取符記與該給定通道或該給定通道中之一給定訊息有關。

5. 如前述條項中任一項所闡明之方法，其中該等一或多個功能係向該給定用戶端發出或經提供至該給定用戶端之應用程式設計介面(API)，該等API包括用於該等一或多個通道之通道API；以及用於與每一或一給定通道相關聯之資料的訊息API；且其中該等存取符記係特定於一給定通道或一給定訊息之API符記。

6. 如前述條項中任一項所闡明之方法，其包含以下步驟： 自該給定用戶端接收一請求，該請求與一通道相關聯； 基於與該給定用戶端有關之該帳戶識別符及該存取密鑰係有效之一判定；允許該給定用戶端存取該帳戶； 基於該請求係有效之一判定，處理對該通道之該請求；以及 將一回應發送至該給定用戶端，該回應包括對與該請求相關之一或多個通道功能之存取； 其中經接收之該請求包括以下各者中之一或多者： -      對列出與該給定用戶端之該帳戶有關的該等一或多個通道之一請求； -      對為該帳戶建立一通道之一請求； -      對刪除一經識別通道之一請求； -      對修正與一經識別通道相關聯之性質及/或權限之一請求； -      對產生用於一經識別通道之一通道存取符記之一請求； -      對撤銷用於一經識別通道之一通道存取符記之一請求。

7. 如條項6中所闡明之方法，其中該回應中之該(等)通道功能包括該帳戶之一JavaScript物件表示法(JSON)經由超文字傳輸協定(HTTP) API，以能夠建立及/或管理一或多個通道。

8. 如前述條項中任一項所闡明之方法，其包含以下步驟： 自該給定用戶端接收一請求，該請求與一訊息相關聯，該訊息係關於與該給定用戶端之一給定通道相關聯之資料； 基於與該給定用戶端有關之該帳戶識別符及該存取密鑰係有效之一判定；允許該給定用戶端存取該帳戶； 基於該請求係有效之一判定，處理對該訊息之該請求；以及 將一回應發送至該給定用戶端，該回應包括對與該請求相關之一或多個訊息功能之存取； 其中經接收之該請求包括以下各者中之一或多者： -          對在該給定通道中測試新訊息之一請求； -          對擷取該給定通道中之一訊息之一請求； -          對標記或識別該給定通道中之已讀或未讀訊息之一請求； -          對在該給定通道中寫入一訊息之一請求。

9. 如條項8中所闡明之方法，其中該回應中之該(等)訊息功能包括該帳戶之一JSON經由HTTP API，以使得該給定用戶端及一或多個其他實體能夠交換訊息，及/或自該給定通道讀取資料及/或將資料寫入至該給定通道。

10.  如前述條項中任一項所闡明之方法，其中通道處理器與一HTTP API端點相關聯，且其中來自該給定用戶端之該請求係基於一HTTP傳輸協定格式而經接收。

11.  如條項10中所闡明之方法，其中該通道處理器與一API轉換器相關聯，該API轉換器經組配以用於執行以下步驟： 以一HTTP傳輸協定格式自該給定用戶端接收該請求； 將一經接收請求轉換為一遠端程序呼叫(RPC)格式，且將該RPC請求發送至該通道處理器以實施該經接收請求； 以一RPC格式自該通道處理器接收一回應；以及 使用一HTTP傳輸協定轉換待發送至該給定用戶端之各別回應。

12.  如前述條項中任一項所闡明之方法，其中該經接收請求係包括該給定用戶端之一帳戶識別符或與該帳戶識別符相關聯之一HTTP GET或POST或PUT或PATCH請求。

13.  如前述條項中任一項所闡明之方法，其中該帳戶識別符係經提供用於一給定用戶端之一別名，該別名特定於該給定用戶端且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該給定用戶端有關之一或多個能力。

14.  如條項13中所闡明之方法，其中該別名與該給定用戶端之一域名相關聯。

15.  如前述條項中任一項所闡明之方法，其包含向該給定用戶端提供一通道服務程式庫之步驟，該通道服務程式庫包括用於促進與該給定用戶端相關聯之該帳戶的該(等)通道功能及/或該(等)訊息功能之一或多個模組。

16.  如前述條項中任一項所闡明之方法，其中，回應於自該給定用戶端接收與一給定通道相關聯之一經完成訊息或交易以用於提交至區塊鏈，接著方法包含以下步驟： 將該等交易提交至一給定採擷器； 建立用於與該給定採擷器進行通訊之一通道； 向該給定採擷器提供對一或多個功能之存取，該等一或多個功能能夠進行與該通道處理器之直接通訊；以及 使用該通道自該給定採擷器接收在一區塊中包括該經完成交易之一證明。

17.  一種用於存取用於訊息或交易之一通道服務之電腦實施方法，該通道服務經提供用於一或多個用戶端，該方法藉由該等一或多個用戶端當中之一給定用戶端之一或多個處理器實施，該方法包含以下步驟： 發送與該通道服務有關之一請求，該通道服務藉由一通道處理器實施； 獲得針對該給定用戶端建立之一帳戶之帳戶憑證，該等帳戶憑證包括一帳戶識別符及特定於該帳戶識別符之一存取密鑰； 獲得對一或多個功能之存取，該等一或多個功能能夠進行該給定用戶端與另一實體之間的直接通訊，該等一或多個功能包括： 與用於傳輸資料之一或多個通道有關之通道功能或程序；及/或 與使用該等一或多個通道被傳輸之該資料有關之訊息功能或程序。

18.  如條項17中所闡明之方法，其包含以下步驟： 發送與該給定用戶端之帳戶的一通道有關之一請求； 自該通道處理器獲得一回應，該回應包括對與該請求相關之一或多個通道功能之存取； 其中該請求包括以下各者中之一或多者： -          對列出與該給定用戶端之該帳戶有關的該等一或多個通道之一請求； -          對為該帳戶建立一通道之一請求； -          對刪除一經識別通道之一請求； -          對修正與一經識別通道相關聯之性質及/或權限之一請求； -          對產生用於一經識別通道之一通道存取符記之一請求； -          對撤銷用於一經識別通道之一通道存取符記之一請求。

19.  如條項18中所闡明之方法，其中在該回應中獲得之該(等)通道功能包括該帳戶之一通道API，該通道API能夠建立及/或管理一或多個通道。

20.  如條項19中所闡明之方法，其中該回應包括存取符記，諸如用於每一通道功能之API符記。

21.  如條項17中所闡明之方法，其包含以下步驟： 發送與一訊息相關聯之一請求，該訊息係關於與該給定用戶端之帳戶的一給定通道相關聯之資料； 自該通道處理器獲得一回應，該回應包括對與該請求相關之一或多個訊息功能之存取； 其中該請求包括以下各者中之一或多者： -      對在該給定通道中測試新訊息之一請求； -      對擷取該給定通道中之一訊息之一請求； -      對標記或識別該給定通道中之已讀或未讀訊息之一請求； -      對在該給定通道中寫入一訊息之一請求。

22.  如條項21中所闡明之方法，其中該回應中之該(等)訊息功能包括該帳戶之一訊息API，以使得該給定用戶端及一或多個其他實體能夠交換訊息，及/或自該給定通道讀取資料及/或將資料寫入至該給定通道。

23.  如條項22中所闡明之方法，其中該回應包括存取符記，諸如用於每一訊息功能之訊息API符記。

24.  如條項17至23中任一項所闡明之方法，其進一步包含： 識別用以進行一通訊交換之另一實體； 使用自該通道處理器接收之一或多個通道功能，建立用於通訊之一通道； 將與該通道相關聯之一或多個存取符記發送至該另一實體； 使用自該通道處理器接收之該通道的一或多個訊息功能，將與一交易有關之至少一個訊息寫入至該通道； 將與該等一或多個訊息相關聯之一或多個存取符記發送至該另一實體； 接收與該通道中之該交易有關之至少一個回覆訊息； 回應於該通訊交換之完成；提供一經完成交易以供提交。

25.  如條項17至24中任一項所闡明之方法，其包含接收及/或儲存一通道服務程式庫之步驟，該通道服務程式庫包括用於促進針對與該給定用戶端相關聯之該帳戶自該通道處理器接收之該(等)通道功能及/或該(等)訊息功能之一或多個模組。

26.  一種用於處理與一區塊鏈相關聯之交易之電腦實施方法，該方法藉由與多個採擷器當中之一給定採擷器相關聯的一或多個處理器實施，該等多個採擷器以通訊方式耦接至為至少一個用戶端實施一通道服務之至少一個通道處理器，該方法包含以下步驟： 接收對藉由另一實體將一經完成交易提交至該區塊鏈之一請求；自該另一實體接收對一通道之存取，該通道能夠進行與該另一實體之直接通訊； 進一步在一區塊中採擷該經完成交易，使用該通道發送包括該經完成交易之一證明。

27.  一種用於實施對一通道服務之定址之電腦實施方法，該通道服務經提供用於訊息或交易，該通道服務經提供用於一或多個用戶端，該方法藉由一通道處理器實施且包含以下步驟： 自該等多個用戶端當中之一給定用戶端接收一請求，該請求與該通道服務有關； 基於與該給定用戶端有關之一帳戶識別符及一存取密鑰係有效之一判定；向該用戶端提供一服務端點； 提供與該通道服務相關聯之至少一個服務定址密鑰； 獲得與該用戶端相關聯之至少一個用戶端定址密鑰； 基於該經接收請求，向該給定用戶端提供對一或多個功能之存取，該等一或多個功能能夠使用用於資料或訊息之傳輸的一通道進行該給定用戶端與另一實體之間的直接通訊。

28.  如條項27中所闡明之方法，其包含以下步驟： 接收與一給定用戶端相關聯之一經完成訊息或交易以供提交至區塊鏈； 提供用於一採擷器之一服務端點； 提供與該通道服務相關聯之至少一個服務定址密鑰； 獲得與該採擷器相關聯之至少一個採擷器定址密鑰； 向該採擷器提供對一或多個功能之存取，該等一或多個功能能夠使用一通道進行與該通道服務之直接通訊。

29.  如條項27或28中任一項所闡明之方法，其中該(等)服務定址密鑰、該(等)用戶端定址密鑰及/或該(等)採擷器定址密鑰係一或多個靜態密鑰及/或短暫密鑰。

30.  如條項27至29中任一項所闡明之方法，其包含以下步驟： 基於該等服務及用戶端/採擷器定址密鑰而與一用戶端/採擷器交換一或多個交握訊息； 獲得一交握結果或型樣； 基於該交握結果或型樣，獲得一共用秘密密鑰； 其中使用該通道之該直接通訊係基於該共用秘密密鑰而經加密。

31.  如條項27至30中任一項所闡明之方法，其中該服務端點係一超文字傳輸協定(HTTP)應用程式設計介面(API)端點，且其中該端點使用一安全HTTP (HTTPS)經傳遞至該用戶端。

32.  如條項27至30中任一項所闡明之方法，其中該服務端點係一通用資源位置(URL)，其包括於對來自該給定用戶端之對與該通道服務相關聯之該等一或多個功能的一請求之一回應中。

33.  如條項27至32中任一項所闡明之方法，其中該服務端點係與該通道服務相關聯之一別名，該別名特定於該通道處理器且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該通道處理器有關之一或多個能力。

34.  如條項33中所闡明之方法，其中該別名係已知的或經提供至一或多個用戶端/採擷器，該別名與用於鑑認之一非對稱密碼密鑰對相關聯。

35.  如條項27至34中任一項所闡明之方法，其中該通道服務係使用如條項1至16中任一項所闡明之方法來實施。

36.  一種用於使用用於訊息或交易之一通道服務實施對一通道之定址之電腦實施方法，該通道服務經提供用於一或多個用戶端，該方法藉由該等一或多個用戶端當中之一給定用戶端之一或多個處理器實施，該方法包含以下步驟： 發送與該通道服務有關之一請求，該通道服務藉由一通道處理器實施； 獲得與該通道服務相關聯之一服務端點； 獲得與該通道服務相關聯之至少一個服務定址密鑰； 提供與該給定用戶端相關聯之至少一個用戶端定址密鑰； 獲得對一或多個功能之存取，該等一或多個功能能夠使用用於資料或訊息之傳輸的一通道進行該給定用戶端與另一實體之間的直接通訊。

37.  如條項36中所闡明之方法，其包含以下步驟： 識別用以進行一通訊交換之另一實體； 使用自該通道處理器接收之該等一或多個功能，建立用於該通訊交換之一通道；該方法進一步包含使用該經建立通道進行以下操作： 提供一用戶端端點； 獲得與該另一實體相關聯之至少一個第三方定址密鑰； 提供與該給定用戶端相關聯之至少一個用戶端定址密鑰； 基於該等用戶端及第三方定址密鑰使用該通道交換一或多個交握訊息； 基於一交握結果或型樣，獲得一共用秘密密鑰； 其中使用該通道之與該另一實體之該直接通訊係基於該共用秘密密鑰而經加密。

38.  如條項36或37中所闡明之方法，其中該(等)服務定址密鑰及/或該(等)用戶端定址密鑰及/或該等第三方定址密鑰係一或多個靜態密鑰及/或短暫密鑰。

39.  如條項36至38中任一項所闡明之方法，其中該用戶端端點係一超文字傳輸協定(HTTP)應用程式設計介面(API)端點，且其中該用戶端端點使用一安全HTTP (HTTPS)經傳遞。

40.  如條項36至38中任一項所闡明之方法，其中該用戶端端點係一通用資源位置(URL)，其包括於使用該經建立通道發送之來自該給定用戶端之一訊息中。

41.  如條項36至40中任一項所闡明之方法，其中該用戶端端點係與該用戶端相關聯之一別名，該別名特定於該用戶端且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該用戶端有關之一或多個能力，且其中該別名與用於鑑認之一非對稱密碼密鑰對相關聯。

42.  如條項36至41中任一項所闡明之方法，其中該另一實體與相關聯之一別名相關聯，該別名特定於該另一實體且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該另一實體有關之一或多個能力，且其中該別名與用於鑑認之一非對稱密碼密鑰對相關聯。

43.  如條項36至42中任一項所闡明之方法，其進一步包含如條項17至26中任一項所闡明之方法。

44.  一種用於處理與一區塊鏈相關聯之交易之電腦實施方法，該方法藉由與多個採擷器當中之一採擷器相關聯的一或多個處理器實施，該等多個採擷器以通訊方式耦接至為至少一個用戶端實施一通道服務之至少一個通道處理器，該方法包含以下步驟： 自一提交器接收對採擷一經完成交易之一請求，該提交器係該通道處理器或與該通道服務相關聯之一用戶端； 獲得與該提交器相關聯之一服務或用戶端端點； 獲得與提交器相關聯之至少一個服務或用戶端定址密鑰； 提供與該採擷器相關聯之至少一個採擷器定址密鑰； 獲得對一或多個功能之存取，該等一或多個功能能夠使用一通道進行與該通道服務之直接通訊。

45.  如條項44中所闡明之方法，其中該(等)服務/用戶端定址密鑰及/或該(等)採擷器定址密鑰係一或多個靜態密鑰及/或短暫密鑰。

46.  如條項44或45中任一項所闡明之方法，其包含以下步驟： 基於該等服務/用戶端及採擷器定址密鑰而與通道處理器交換一或多個交握訊息； 基於一交握結果或型樣，獲得一共用秘密密鑰； 其中使用該通道之該直接通訊係基於該共用秘密密鑰而經加密。

47.  如條項44至46中任一項所闡明之方法，其中該採擷器端點係一超文字傳輸協定(HTTP)應用程式設計介面(API)端點，且其中該端點使用安全HTTP (HTTPS)經提供。

48.  如條項44至46中任一項所闡明之方法，其中該採擷器端點係通用資源位置(URL)，其包括於使用與該通道服務相關聯之該等一或多個功能發送之來自該採擷器之一訊息中。

49.  如條項44至48中任一項所闡明之方法，其中該採擷器端點係與該採擷器相關聯之一別名，該別名特定於該採擷器且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該採擷器有關之一或多個能力，且其中該別名與用於鑑認之一非對稱密碼密鑰對相關聯。

50.  如條項44至49中任一項所闡明之方法，其進一步包含如條項26中所闡明之方法。

51.  一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，由於由該處理器執行，該等可執行指令使得該裝置執行如條項1至16及27至34中任一項所闡明之電腦實施方法，該計算裝置與一通道處理器有關。

52.  一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，由於由該處理器執行，該等可執行指令使得該裝置執行如條項17至25及36至43中任一項所闡明之電腦實施方法，其中該計算裝置與一用戶端有關。

53.  一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，由於由該處理器執行，該等可執行指令使得該裝置執行如條項26及44至50中任一項所闡明之電腦實施方法，其中該計算裝置與一採擷器有關。

54.  一種電腦系統，其包含： 至少一個通道處理器，其經由一通訊網路以通訊方式耦接至至少一個用戶端及至少一個採擷器，該至少一個通道處理器實施用於一或多個用戶端之一通道服務，其中該至少一個通道處理器係根據如條項51中所闡明之計算裝置來實施；該至少一個用戶端係根據如條項52中所闡明之計算裝置來實施；且該至少一個採擷器係根據如條項53中所闡明之計算裝置來實施。

55.  一種電腦可讀儲存媒體，其上儲存有可執行指令，由於由一電腦之一處理器執行，該等可執行指令使得該電腦執行如條項1至50中任一項之方法。

應注意，上文所提及之態樣及實施例繪示而非限制本揭露內容，且熟習此項技術者將能夠設計許多替代性實施例而不偏離本揭露內容之如由所附申請專利範圍界定的範疇。在申請專利範圍中，置放於圓括號中之任何參考符號不應被認為限制申請專利範圍。詞「包含(comprising及comprises)」及其類似者並不排除除任何申請專利範圍或說明書中整體列出之彼等元件或步驟外的元件或步驟之存在。在本說明書中，「包含(comprises及comprising)」意謂「包括或由……組成(includes or consists of及including or consisting of)」。元件之單數參考並不排除該等元件之複數參考，且反之亦然。本揭露內容可藉助於包含若干相異元件之硬體且藉助於經合適程式化之電腦而實施。在列舉若干構件之裝置申請專利範圍中，此等構件中之若干者可由硬體之同一物件體現。在相互不同之附屬申請專利範圍中敍述某些措施之純粹實情並不指示不能有利地使用此等措施之組合。

102,104,106,202,204,206,208,210,212,214,216,302,304,306,308,310,312,314,402,404,406,502,504,506,508,510,512,514,602,604,606,608,610,612,614,702,704,706,708,710:步驟 2600:計算裝置 2602:快取記憶體/處理器 2604:匯流排子系統 2606:儲存子系統 2608:主記憶體 2610:持久儲存器 2612:使用者介面輸入裝置 2614:使用者介面輸出裝置 2616:網路介面子系統 2618:動態隨機存取記憶體 2620:唯讀記憶體

現將僅作為實例且參考附圖描述本揭露內容之態樣及實施例，在附圖中：

圖1係描繪用於根據第一態樣向一或多個用戶端提供通道服務之方法的流程圖，如藉由與通道服務相關聯之一或多個通道處理器所實施。 圖1a係繪示根據第一態樣之與經提供用於多個用戶端之區塊鏈相關聯的通道服務之實例概述的示意圖。 圖2係描繪根據第一態樣之用於實施用於給定用戶端之通道服務之方法的流程圖，如藉由通道處理器所實施。 圖3係描繪根據第一態樣之用於存取通道服務之方法的流程圖，如藉由與用戶端相關聯之一或多個處理器所實施。 圖4係描繪根據第一態樣之用於使用通道服務來處理區塊鏈交易之方法的流程圖，如藉由與採擷器相關聯之一或多個處理器所實施。 圖5係描繪根據第二態樣之用於實施對通道服務之定址之方法的流程圖，如藉由通道處理器所實施。 圖6係描繪根據第二態樣之用於使用通道服務來實施對通道之定址之方法的流程圖，如藉由與用戶端相關聯之一或多個處理器所實施。 圖7係描繪根據第二態樣之用於使用通道服務來處理區塊鏈交易之方法的流程圖，如藉由與採擷器相關聯之一或多個處理器所實施。 圖8係繪示根據第二態樣之提供定址及端對端加密以供經由通道進行通訊的實例之示意性流程圖。 圖9係繪示與同級間異步通訊相關之以上態樣的實例使用案例之示意性流程圖，該等通訊與區塊鏈相關聯。 圖10係繪示與區塊鏈交易之多重簽名(多個或臨限數目個簽名)授權相關之以上態樣的實例使用案例之示意性流程圖。 圖11係繪示其中可實施本揭露內容之各種態樣及實施例的計算環境之示意圖。

Claims (55)

1. 一種用於實施用於訊息或交易之一通道服務之電腦實施方法，該通道服務經提供用於一或多個用戶端，該方法藉由一通道處理器實施且包含以下步驟： 自該等一或多個用戶端當中之一給定用戶端接收一請求，該請求與該通道服務有關； 為該給定用戶端建立一帳戶，該帳戶具有特定於該給定用戶端之一帳戶識別符及特定於該帳戶識別符之一存取密鑰； 向該給定用戶端提供對一或多個功能之存取，該等一或多個功能能夠進行該給定用戶端與另一實體之間的直接通訊； 其中該等一或多個功能包括： 與用於傳輸資料之一或多個通道有關之通道功能或程序；及/或 與使用該等一或多個通道被傳輸之該資料有關之訊息功能或程序。
2. 如請求項1之方法，其中一給定通道與一通道識別符相關聯，該給定通道經組配以用於與關於與一特定類型或主題相關聯之資料的另一實體通訊。
3. 如請求項2之方法，其中與該給定通道相關聯之資料係在或包括於一或多個訊息或交易中。
4. 如前述請求項中任一項之方法，其中該給定用戶端係該等一或多個通道之擁有者，該方法進一步包含以下步驟：為該等一或多個通道當中之一給定通道發出一或多個存取符記，該等一或多個存取符記經組配以用於與另一實體安全通訊，該等一或多個存取符記與該給定通道或該給定通道中之一給定訊息有關。
5. 如前述請求項中任一項之方法，其中該等一或多個功能係為該給定用戶端發出或提供至該給定用戶端之應用程式設計介面(API)，該等API包括用於該等一或多個通道之通道API；以及用於與每一或一給定通道相關聯之資料的訊息API；且其中該等存取符記係特定於一給定通道或一給定訊息之API符記。
6. 如前述請求項中任一項之方法，其包含以下步驟： 自該給定用戶端接收一請求，該請求與一通道相關聯； 基於與該給定用戶端有關之該帳戶識別符及該存取密鑰係有效之一判定；允許該給定用戶端存取該帳戶； 基於該請求係有效之一判定，處理對該通道之該請求；以及 將一回應發送至該給定用戶端，該回應包括對與該請求相關之一或多個通道功能之存取； 其中經接收之該請求包括以下各者中之一或多者： 對列出與該給定用戶端之該帳戶有關的該等一或多個通道之一請求； 對為該帳戶建立一通道之一請求； 對刪除一經識別通道之一請求； 對修正與一經識別通道相關聯之性質及/或權限之一請求； 對產生用於一經識別通道之一通道存取符記之一請求； 對撤銷用於一經識別通道之一通道存取符記之一請求。
7. 如請求項6之方法，其中該回應中之該(等)通道功能包括該帳戶之一JavaScript物件表示法(JSON)經由超文字傳輸協定(HTTP) API，以能夠建立及/或管理一或多個通道。
8. 如前述請求項中任一項之方法，其包含以下步驟： 自該給定用戶端接收一請求，該請求與一訊息相關聯，該訊息係關於與該給定用戶端之一給定通道相關聯之資料； 基於與該給定用戶端有關之該帳戶識別符及該存取密鑰係有效之一判定；允許該給定用戶端存取該帳戶； 基於該請求係有效之一判定，處理對該訊息之該請求；以及 將一回應發送至該給定用戶端，該回應包括對與該請求相關之一或多個訊息功能之存取； 其中經接收之該請求包括以下各者中之一或多者： 對在該給定通道中測試新訊息之一請求； 對擷取該給定通道中之一訊息之一請求； 對標記或識別該給定通道中之已讀或未讀訊息之一請求； 對在該給定通道中寫入一訊息之一請求。
9. 如請求項8之方法，其中該回應中之該(等)訊息功能包括該帳戶之一JSON經由HTTP API，以使得該給定用戶端及一或多個其他實體能夠交換訊息，及/或自該給定通道讀取資料及/或將資料寫入至該給定通道。
10. 如前述請求項中任一項之方法，其中通道處理器與一HTTP API端點相關聯，且其中來自該給定用戶端之該請求係基於一HTTP傳輸協定格式而接收。
11. 如請求項10之方法，其中該通道處理器與一API轉換器相關聯，該API轉換器經組配以用於執行以下步驟： 以一HTTP傳輸協定格式自該給定用戶端接收該請求； 將一經接收請求轉換為一遠端程序呼叫(RPC)格式，且將該RPC請求發送至該通道處理器以實施該經接收請求； 以一RPC格式自該通道處理器接收一回應；以及 使用一HTTP傳輸協定轉換待發送至該給定用戶端之各別回應。
12. 如前述請求項中任一項之方法，其中該經接收請求係包括該給定用戶端之一帳戶識別符或與該帳戶識別符相關聯之一HTTP GET或POST或PUT或PATCH請求。
13. 如前述請求項中任一項之方法，其中該帳戶識別符係經提供用於一給定用戶端之一別名，該別名特定於該給定用戶端且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該給定用戶端有關之一或多個能力。
14. 如請求項13之方法，其中該別名與該給定用戶端之一域名相關聯。
15. 如前述請求項中任一項之方法，其包含向該給定用戶端提供一通道服務程式庫之步驟，該通道服務程式庫包括用於促進與該給定用戶端相關聯之該帳戶的該(等)通道功能及/或該(等)訊息功能之一或多個模組。
16. 如前述請求項中任一項之方法，其中，回應於自該給定用戶端接收與一給定通道相關聯之一經完成訊息或交易以用於提交至區塊鏈，接著方法包含以下步驟： 將該等交易提交至一給定採擷器； 建立用於與該給定採擷器進行通訊之一通道； 向該給定採擷器提供對一或多個功能之存取，該等一或多個功能能夠進行與該通道處理器之直接通訊；以及 使用該通道自該給定採擷器接收在一區塊中包括該經完成交易之一證明。
17. 一種用於存取用於訊息或交易之一通道服務之電腦實施方法，該通道服務經提供用於一或多個用戶端，該方法藉由該等一或多個用戶端當中之一給定用戶端之一或多個處理器實施，該方法包含以下步驟： 發送與該通道服務有關之一請求，該通道服務藉由一通道處理器實施； 獲得針對該給定用戶端建立之一帳戶之帳戶憑證，該等帳戶憑證包括一帳戶識別符及特定於該帳戶識別符之一存取密鑰； 獲得對一或多個功能之存取，該等一或多個功能能夠進行該給定用戶端與另一實體之間的直接通訊，該等一或多個功能包括： 與用於傳輸資料之一或多個通道有關之通道功能或程序；及/或 與使用該等一或多個通道被傳輸之該資料有關之訊息功能或程序。
18. 如請求項17之方法，其包含以下步驟： 發送與該給定用戶端之帳戶的一通道有關之一請求； 自該通道處理器獲得一回應，該回應包括對與該請求相關之一或多個通道功能之存取； 其中該請求包括以下各者中之一或多者： 對列出與該給定用戶端之該帳戶有關的該等一或多個通道之一請求； 對為該帳戶建立一通道之一請求； 對刪除一經識別通道之一請求； 對修正與一經識別通道相關聯之性質及/或權限之一請求； 對產生用於一經識別通道之一通道存取符記之一請求； 對撤銷用於一經識別通道之一通道存取符記之一請求。
19. 如請求項18之方法，其中在該回應中獲得之該(等)通道功能包括該帳戶之一通道API，該通道API能夠建立及/或管理一或多個通道。
20. 如請求項19之方法，其中該回應包括存取符記，諸如用於每一通道功能之API符記。
21. 如請求項17之方法，其包含以下步驟： 發送與一訊息相關聯之一請求，該訊息係關於與該給定用戶端之帳戶的一給定通道相關聯之資料； 自該通道處理器獲得一回應，該回應包括對與該請求相關之一或多個訊息功能之存取； 其中該請求包括以下各者中之一或多者： 對在該給定通道中測試新訊息之一請求； 對擷取該給定通道中之一訊息之一請求； 對標記或識別該給定通道中之已讀或未讀訊息之一請求； 對在該給定通道中寫入一訊息之一請求。
22. 如請求項21之方法，其中該回應中之該(等)訊息功能包括該帳戶之一訊息API，以使得該給定用戶端及一或多個其他實體能夠交換訊息，及/或自該給定通道讀取資料及/或將資料寫入至該給定通道。
23. 如請求項22之方法，其中該回應包括存取符記，諸如用於每一訊息功能之訊息API符記。
24. 如請求項17至23中任一項之方法，其進一步包含： 識別與之進行一通訊交換之另一實體； 使用自該通道處理器接收之一或多個通道功能，建立用於通訊之一通道； 將與該通道相關聯之一或多個存取符記發送至該另一實體； 使用自該通道處理器接收的該通道之一或多個訊息功能，將與一交易有關之至少一個訊息寫入至該通道； 將與該等一或多個訊息相關聯之一或多個存取符記發送至該另一實體； 接收與該通道中之該交易有關之至少一個回覆訊息； 回應於該通訊交換之完成；提供一經完成交易以供提交。
25. 如請求項17至24中任一項之方法，其包含接收及/或儲存一通道服務程式庫之步驟，該通道服務程式庫包括用於促進針對與該給定用戶端相關聯之該帳戶自該通道處理器接收之該(等)通道功能及/或該(等)訊息功能之一或多個模組。
26. 一種用於處理與一區塊鏈相關聯之交易之電腦實施方法，該方法藉由與多個採擷器當中之一給定採擷器相關聯的一或多個處理器實施，該等多個採擷器以通訊方式耦接至為至少一個用戶端實施一通道服務之至少一個通道處理器，該方法包含以下步驟： 接收對藉由另一實體將一經完成交易提交至該區塊鏈之一請求；自該另一實體接收對一通道之存取，該通道能夠進行與該另一實體之直接通訊； 進一步在一區塊中採擷該經完成交易，使用該通道發送包括該經完成交易之一證明。
27. 一種用於實施對一通道服務之定址之電腦實施方法，該通道服務經提供用於訊息或交易，該通道服務經提供用於一或多個用戶端，該方法藉由一通道處理器實施且包含以下步驟： 自該等多個用戶端當中之一給定用戶端接收一請求，該請求與該通道服務有關； 基於與該給定用戶端有關之一帳戶識別符及一存取密鑰係有效之一判定；為該用戶端提供一服務端點； 提供與該通道服務相關聯之至少一個服務定址密鑰； 獲得與該用戶端相關聯之至少一個用戶端定址密鑰； 基於該經接收請求，向該給定用戶端提供對一或多個功能之存取，該等一或多個功能能夠使用用於資料或訊息之傳輸的一通道進行該給定用戶端與另一實體之間的直接通訊。
28. 如請求項27之方法，其包含以下步驟： 接收與一給定用戶端相關聯之一經完成訊息或交易以供提交至區塊鏈； 提供用於一採擷器之一服務端點； 提供與該通道服務相關聯之至少一個服務定址密鑰； 獲得與該採擷器相關聯之至少一個採擷器定址密鑰； 向該採擷器提供對一或多個功能之存取，該等一或多個功能能夠使用一通道進行與該通道服務之直接通訊。
29. 如請求項27或28中任一項之方法，其中該(等)服務定址密鑰、該(等)用戶端定址密鑰及/或該(等)採擷器定址密鑰係一或多個靜態密鑰及/或短暫密鑰。
30. 如請求項27至29中任一項之方法，其包含以下步驟： 基於該等服務及用戶端/採擷器定址密鑰而與一用戶端/採擷器交換一或多個交握訊息； 獲得一交握結果或型樣； 基於該交握結果或型樣，獲得一共用秘密密鑰； 其中使用該通道之該直接通訊係基於該共用秘密密鑰而加密。
31. 如請求項27至30中任一項之方法，其中該服務端點係一超文字傳輸協定(HTTP)應用程式設計介面(API)端點，且其中該端點係使用一安全HTTP (HTTPS)傳遞至該用戶端。
32. 如請求項27至30中任一項之方法，其中該服務端點係一通用資源位置(URL)，其包括於對來自該給定用戶端之對與該通道服務相關聯之該等一或多個功能的一請求之一回應中。
33. 如請求項27至32中任一項之方法，其中該服務端點係與該通道服務相關聯之一別名，該別名特定於該通道處理器且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該通道處理器有關之一或多個能力。
34. 如請求項33之方法，其中該別名係已知的或經提供至一或多個用戶端/採擷器，該別名與用於鑑認之一非對稱密碼密鑰對相關聯。
35. 如請求項27至34中任一項之方法，其中該通道服務係使用如請求項1至16中任一項之方法來實施。
36. 一種使用用於訊息或交易之一通道服務實施對一通道之定址之電腦實施方法，該通道服務經提供用於一或多個用戶端，該方法藉由該等一或多個用戶端當中之一給定用戶端之一或多個處理器實施，該方法包含以下步驟： 發送與該通道服務有關之一請求，該通道服務藉由一通道處理器實施； 獲得與該通道服務相關聯之一服務端點； 獲得與該通道服務相關聯之至少一個服務定址密鑰； 提供與該給定用戶端相關聯之至少一個用戶端定址密鑰； 獲得對一或多個功能之存取，該等一或多個功能能夠使用用於資料或訊息之傳輸的一通道進行該給定用戶端與另一實體之間的直接通訊。
37. 如請求項36之方法，其包含以下步驟： 識別與之進行一通訊交換之另一實體； 使用自該通道處理器接收之該等一或多個功能，建立用於該通訊交換之一通道；該方法進一步包含使用該經建立通道進行以下操作： 提供一用戶端端點； 獲得與該另一實體相關聯之至少一個第三方定址密鑰； 提供與該給定用戶端相關聯之至少一個用戶端定址密鑰； 基於該等用戶端及第三方定址密鑰使用該通道交換一或多個交握訊息； 基於一交握結果或型樣，獲得一共用秘密密鑰； 其中使用該通道之與該另一實體之該直接通訊係基於該共用秘密密鑰而加密。
38. 如請求項36或37之方法，其中該(等)服務定址密鑰及/或該(等)用戶端定址密鑰及/或該等第三方定址密鑰係一或多個靜態密鑰及/或短暫密鑰。
39. 如請求項36至38中任一項之方法，其中該用戶端端點係一超文字傳輸協定(HTTP)應用程式設計介面(API)端點，且其中該用戶端端點係使用一安全HTTP (HTTPS)傳遞。
40. 如請求項36至38中任一項之方法，其中該用戶端端點係一通用資源位置(URL)，其包括於使用該經建立通道發送之來自該給定用戶端之一訊息中。
41. 如請求項36至40中任一項之方法，其中該用戶端端點係與該用戶端相關聯之一別名，該別名特定於該用戶端且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該用戶端有關之一或多個能力，且其中該別名與用於鑑認之一非對稱密碼密鑰對相關聯。
42. 如請求項36至41中任一項之方法，其中該另一實體與相關聯之一別名相關聯，該別名特定於該另一實體且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該另一實體有關之一或多個能力，且其中該別名與用於鑑認之一非對稱密碼密鑰對相關聯。
43. 如請求項36至42中任一項之方法，其進一步包含如請求項17至26中任一項之方法。
44. 一種用於處理與一區塊鏈相關聯之交易之電腦實施方法，該方法藉由與多個採擷器當中之一採擷器相關聯的一或多個處理器實施，該等多個採擷器以通訊方式耦接至為至少一個用戶端實施一通道服務之至少一個通道處理器，該方法包含以下步驟： 自一提交器接收對採擷一經完成交易之一請求，該提交器係該通道處理器或與該通道服務相關聯之一用戶端； 獲得與該提交器相關聯之一服務或用戶端端點； 獲得與提交器相關聯之至少一個服務或用戶端定址密鑰； 提供與該採擷器相關聯之至少一個採擷器定址密鑰； 獲得對一或多個功能之存取，該等一或多個功能能夠使用一通道進行與該通道服務之直接通訊。
45. 如請求項44之方法，其中該(等)服務/用戶端定址密鑰及/或該(等)採擷器定址密鑰係一或多個靜態密鑰及/或短暫密鑰。
46. 如請求項44或45中任一項之方法，其包含以下步驟： 基於該等服務/用戶端及採擷器定址密鑰而與通道處理器交換一或多個交握訊息； 基於一交握結果或型樣，獲得一共用秘密密鑰； 其中使用該通道之該直接通訊係基於該共用秘密密鑰而加密。
47. 如請求項44至46中任一項之方法，其中該採擷器端點係一超文字傳輸協定(HTTP)應用程式設計介面(API)端點，且其中該端點係使用安全HTTP (HTTPS)提供。
48. 如請求項44至46中任一項之方法，其中該採擷器端點係通用資源位置(URL)，其包括於使用與該通道服務相關聯之該等一或多個功能發送之來自該採擷器之一訊息中。
49. 如請求項44至48中任一項之方法，其中該採擷器端點係與該採擷器相關聯之一別名，該別名特定於該採擷器且係由一基於別名之定址服務提供，該定址服務具有可自一經界定或熟知位置存取之一機器可讀資源，該機器可讀資源包括與該採擷器有關之一或多個能力，且其中該別名與用於鑑認之一非對稱密碼密鑰對相關聯。
50. 如請求項44至49中任一項之方法，其進一步包含如請求項26之方法。
51. 一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，做為由該處理器執行之一結果，該等可執行指令使得該裝置執行如請求項1至16及27至34中任一項之電腦實施方法，該計算裝置與一通道處理器有關。
52. 一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，做為由該處理器執行之一結果，該等可執行指令使得該裝置執行如請求項17至25及36至43中任一項之電腦實施方法，其中該計算裝置與一用戶端有關。
53. 一種計算裝置，其包含一處理器及記憶體，該記憶體包括可執行指令，做為由該處理器執行之一結果，該等可執行指令使得該裝置執行如請求項26及44至50中任一項之電腦實施方法，其中該計算裝置與一採擷器有關。
54. 一種電腦系統，其包含： 至少一個通道處理器，其經由一通訊網路以通訊方式耦接至至少一個用戶端及至少一個採擷器，該至少一個通道處理器實施用於一或多個用戶端之一通道服務，其中該至少一個通道處理器係根據如請求項51之計算裝置來實施；該至少一個用戶端係根據如請求項52之計算裝置來實施；且該至少一個採擷器係根據如請求項53之計算裝置來實施。
55. 一種電腦可讀儲存媒體，其上儲存有可執行指令，做為由一電腦之一處理器執行之一結果，該等可執行指令使得該電腦執行如請求項1至50中任一項之方法。

Images