這裡將詳細地對示例性實施例進行說明，其示例表示在圖式中。下面的描述涉及圖式時，除非另有表示，不同圖式中的相同數位表示相同或相似的要素。以下示例性實施例中所描述的實施方式並不代表與本說明書一個或多個實施例相一致的所有實施方式。相反，它們僅是與如申請專利範圍中所詳述的、本說明書一個或多個實施例的一些方面相一致的裝置和方法的例子。
需要說明的是：在其他實施例中並不一定按照本說明書示出和描述的順序來執行相應方法的步驟。在一些其他實施例中，其方法所包括的步驟可以比本說明書所描述的更多或更少。此外，本說明書中所描述的單個步驟，在其他實施例中可能被分解為多個步驟進行描述；而本說明書中所描述的多個步驟，在其他實施例中也可能被合併為單個步驟進行描述。
圖1是一示例性實施例提供的一種基於區塊鏈的音訊協議簽訂方法的流程圖。如圖1所示，該方法應用於區塊鏈節點，可以包括以下步驟：
步驟102，根據接收到的音訊協議簽訂請求，對所述音訊協議簽訂請求指示的協議參與方進行身分認證。
在一實施例中，透過在電子設備上安裝、運行區塊鏈的客戶端，可以將該電子設備配置為區塊鏈網路中的區塊鏈節點，比如該電子設備可以包括伺服器、PC、平板電腦、手機等各種類型；換言之，區塊鏈節點可以承載於任意形式的電子設備上，本說明書並不對此進行限制。
在一實施例中，音訊協議簽訂請求指示的協議參與方可以為單方或多方，可以分別針對每一協議參與方實施身分認證。其中，身分認證的方式可以包括以下任一：指紋識別、聲紋識別、人臉識別、實人認證等，本說明書並不對此進行限制。例如，當身分認證為指紋識別時，獲取的身分資料可以包括該用戶的指紋圖像；再例如，當身分認證為聲紋識別時，獲取的身分資料可以包括該用戶的聲紋特徵；又例如，當身分認證為人臉識別形式時，獲取的身分資料可以包括該用戶的人臉圖像；還例如，當身分認證為實人認證時，獲取的身分資料可以包括人臉圖像、人臉視頻、證件圖像、音訊(比如由用戶讀出一段特定的驗證碼等)等。
在一實施例中，如果存在多個協議參與方，可能存在多種情形：例如，多個協議參與方可以分別使用不同的電子設備，每一協議參與方可以分別透過自己使用的電子設備採集並上傳身分資料；再例如，多個協議參與方可以處於同一地點，這些協議參與方可以共用一台電子設備，比如輪流透過該電子設備採集並上傳身分資料，或者由電子設備同時對這些協議參與方進行身分資料的採集和上傳；當然，還可能存在其他情形，本說明書並不對此進行限制。
步驟104，在身分認證通過後獲取所述協議參與方提供的音訊資料，所述音訊資料中包含用於表徵協議內容的第一音訊資訊和用於表徵所述協議參與方認可所述協議內容的第二音訊資訊。
在一實施例中，第一音訊資訊的內容可以為協議參與方讀出協議內容的音訊片段；或者，第一音訊資訊的內容可以為協議參與方之外的其他用戶讀出協議內容的音訊片段；或者，第一音訊資訊可以透過其他方式表徵協議內容，本說明書並不對此進行限制。
在一實施例中，第二音訊資訊的內容可以為協議參與方說出類似於“我同意”、“我確認”、“我認可”或類似的語句；或者，第二音訊資訊可以透過其他方式表徵“認可”的含義，本說明書並不對此進行限制。
在一實施例中，與身分資料的獲取過程相類似的，可能存在多種情形：例如，多個協議參與方可以分別使用不同的電子設備，每一協議參與方可以分別透過自己使用的電子設備採集並上傳音訊資料；再例如，多個協議參與方可以處於同一地點，這些協議參與方可以共用一台電子設備，比如輪流透過該電子設備採集並上傳音訊資料，或者由電子設備同時對這些協議參與方進行音訊資料的採集和上傳；當然，還可能存在其他情形，本說明書並不對此進行限制。
步驟106，將所述音訊資料和/或所述音訊資料的數位摘要資訊發佈至區塊鏈，以記錄為所述協議參與方簽訂的音訊協議。
在一實施例中，透過將音訊資料發佈至區塊鏈中，可以確保該音訊資料無法被篡改或使得對音訊資料的篡改行為可檢驗，且可以透過查詢區塊鏈帳本而對該音訊資料進行追溯，具有極高的可靠性。而音訊資料的數位摘要資訊可以為音訊資料的雜湊值等，可以唯一匹配於該音訊資料，可以將音訊資料的數位摘要資訊發佈至區塊鏈中，而將音訊資料儲存在本地而不上鏈，那麼基於音訊資料與其數位摘要資訊之間的唯一匹配關係，可以確保音訊資料無法被篡改或使得對音訊資料的篡改行為可檢驗，同時可以避免對音訊資料的內容造成公開、有助於實現隱私保護。
在一實施例中，由於音訊資料中透過第一音訊資訊表徵了協議內容、透過第二音訊資訊表徵了協議參與方對協議內容的認可態度，使得本說明書中的音訊資料實際上已經實現了相關技術中的文字協議所需實現的功能，且協議參與方在本說明書的技術方案中無需具體形成文字內容，多個協議參與方不必須前往同一地點簽訂協議，從而在保證協議有效性的同時，極大地簡化了協議參與方的操作、提升了協議簽訂效率。
在一實施例中，區塊鏈節點可以獲取音訊協議的簽訂屬性，比如該簽訂屬性可以包括以下至少之一：所述協議參與方的身分資訊、所述協議參與方的所處地點、協議簽訂時刻等，本說明書並不對此進行限制。然後，區塊鏈節點可以在將所述音訊資料和/或所述音訊資料的數位摘要資訊發佈至區塊鏈時，還關聯發佈所述簽訂屬性，使得該音訊資料所表徵的協議事件具有更多維度的特徵資訊，有助於提升音訊資料的可信度。
在一實施例中，區塊鏈節點可以調用智慧合約，所述智慧合約被用於驗證所述第一音訊資訊所表徵的協議內容是否合法有效。例如，區塊鏈節點可以分析第一音訊資訊所表徵的協議內容、將該協議內容提取為文字資訊，並將該文字資訊提供至智慧合約，使得智慧合約可以對第一音訊資訊所表徵的協議內容進行分析，比如是否命中敏感詞、是否表達了非法語義、協議內容是否含糊不清或存在歧義等，本說明書並不對此進行限制。當協議內容被驗證為合法有效時，允許區塊鏈節點實施其他操作；當協議內容被驗證為非法或無效時，可以將上述的音訊資料判定為無效協議，還可以對音訊資料添加無效標記或阻止該音訊資料生效。
在一實施例中，區塊鏈節點可以調用智慧合約，所述智慧合約被用於驗證所述第二音訊資訊所表徵的所述協議參與方對所述協議內容的認可情況是否有效。例如，區塊鏈節點可以分析第二音訊資訊所表徵的認可情況，並將該認可情況提供至智慧合約，使得智慧合約可以對第二音訊資訊所表徵的認可情況進行分析，比如是否含糊不清或存在歧義、是否存在脅迫狀況等，本說明書並不對此進行限制。當認可情況被驗證為有效時，允許區塊鏈節點實施其他操作；當認可情況被驗證為非法或無效時，可以將上述的音訊資料判定為無效協議，還可以對音訊資料添加無效標記或阻止該音訊資料生效。
在一實施例中，當存在多個協議參與方時，多個協議參與方對應於同一份音訊資料，該音訊資料包含的第二音訊資訊用於表徵多個協議參與方對所述協議內容的認可情況。在另一實施例中，當存在多個協議參與方時，多個協議參與方分別對應於不同的音訊資料，每一音訊資料包含的第二音訊資訊用於表徵相應的協議參與方對所述協議內容的認可情況。
在一實施例中，區塊鏈節點可以調用智慧合約，所述智慧合約被用於在多個協議參與方分別對應於不同的音訊資料的情況下，驗證各個音訊資料包含的第一音訊資訊所表徵的協議內容是否一致。比如，區塊鏈節點可以分別提取各個音訊資料中的第一音訊資訊所表徵的協議內容，並傳遞至智慧合約中，以由智慧合約對各個音訊資料分別對應的協議內容進行比較；如果協議內容均一致，允許區塊鏈節點實施其他操作，如果協議內容不完全一致，可以將本次產生的音訊資料判定為無效協議，還可以對音訊資料添加無效標記或阻止這些音訊資料生效(避免基於這些音訊資料形成音訊合同)。
在一實施例中，區塊鏈節點可以調用智慧合約，所述智慧合約被用於根據所述音訊資料產生文字協議，並透過所述協議參與方的資料身分進行簽名；然後，在將所述音訊資料和/或所述音訊資料的數位摘要資訊發佈至區塊鏈時，該區塊鏈節點還關聯發佈所述文字協議，從而同時基於音訊資料和文字協議實現。
在一實施例中，本說明書中的協議可以包括單方協議，比如承諾書、遺囑、聲明等，本說明書並不對此進行限制。在一實施例中，本說明書中的協議可以包括多方協議或稱為合同，比如房屋租賃合同、商品買賣合同、勞動合同等，本說明書並不對此進行限制。
為了便於理解，下面以協議簽訂為例，對本說明書一個或多個實施例的技術方案進行說明。圖2是一示例性實施例提供的一種實施實人認證的示意圖。如圖2所示，假定用戶A使用手機21(或其他類型的電子設備，本說明書並不對此進行限制)，該手機21上可以透過運行某一應用X的APP客戶端或加載該應用X對應的網站，以向用戶A提供音訊協議的簽訂功能。在實施音訊協議的簽訂過程中，應用X可以對用戶A進行實人認證，以便於對用戶A的個人真實身分進行有效管理，並準確定義相關音訊協議的協議參與方(即用戶A)。
在一實施例中，手機21可以透過攝影機模組對用戶A進行圖像採集，使得採集到的圖片或視頻中包含用戶A的人臉圖像、用戶A手持有效證件(如身分證)的圖像、用戶A按照指令執行相應動作的圖像等，以作為針對用戶A的身分資料，並由手機21將身分資料上傳至伺服器22，使得伺服器22可以基於人臉檢測、人臉識別、OCR證件識別、活體檢測等多種技術手段，對用戶A實施實人認證。
在實人認證完成後，用戶A可以基於已完成認證的身分資訊，簽訂相應的音訊協議。圖3是一示例性實施例提供的一種簽訂音訊協議的示意圖。如圖3所示，手機21可以透過麥克風對用戶A進行音訊採集，並確保採集得到的音訊資料能夠至少表徵兩方面的內容：一方面，音訊資料需要表徵所需簽訂的協議內容，另一方面，音訊資料需要表徵用戶A認可該協議內容。
在一實施例中，用戶A可以朝向手機21的麥克風說出滿足上述要求的語音內容。比如，當用戶A說出諸如“我承諾向XX組織捐贈100萬人民幣”的語音內容時，表徵的協議內容可以為“用戶A向XX組織捐贈100萬人民幣”，而“我承諾……”的句式表達了用戶A對上述協議內容的認可態度，因而可以認為滿足上述要求。
上述實施例涉及到用戶A簽訂單方的音訊協議，即該音訊協議的協議參與方僅包含用戶A，但該場景下並不意味著只有用戶A能夠參與到音訊資料的採集過程。比如圖4所示，用戶A與用戶B均可以出現在手機21採集的音訊資料中，並且伺服器22可以分別針對用戶A和用戶B進行實人認證；在實人認證通過後，用戶B可以協助用戶A完成音訊採集，比如由用戶B口述協議內容，並由用戶A對用戶B口述的協議內容予以確認，譬如用戶B的口述內容可以為“由用戶A向XX組織捐贈100萬人民幣”，而用戶A可以透過諸如“我同意”等內容予以確認。
在一實施例中，伺服器22可以對手機21上傳的音訊資料進行分析，以確定其包含的音訊內容，比如上述的協議內容、用戶A對該協議內容的認可情況等。然後，伺服器22可以透過調用智慧合約，以基於該智慧合約中定義的檢驗規則對上述的音訊內容進行檢驗；其中，檢驗規則可以包括以下至少之一：協議內容是否包含非法內容(比如可以匹配協議內容是否包含預設的敏感詞)、協議內容是否包含無效內容(比如透過語義分析協議內容是否清楚、準確)、協議參與方是否認可協議內容(比如協議參與方是否發出表達“認可”的語音或做出表達“認可”的動作等)、協議參與方表達“認可”的狀態是否正常(比如協議參與方的語調或表情是否正常、是否存在受人脅迫的情形等)等，本說明書並不對此進行限制。
在一實施例中，當伺服器22確定音訊資料的音訊內容通過檢驗後，可以向區塊鏈中發佈相應的音訊協議。例如，伺服器22可以向區塊鏈中發佈一筆交易，該交易中包含上述的音訊資料，該音訊資料經由用於表徵用戶A的數位身分的密鑰進行簽名，以表明該音訊資料為用戶A參與的音訊協議，而該交易的內容可以被記錄至區塊鏈帳本中，從而實現了對該音訊協議的存證。
在一實施例中，伺服器22可以僅在本地儲存上述的音訊資料，而向區塊鏈中發佈的交易中僅包含該音訊資料的雜湊值，一方面可以避免音訊協議的內容被公開、有助於提升資料私密性，另一方面可以根據區塊鏈帳本中記錄的雜湊值對伺服器22在本地儲存的音訊資料進行驗證，以避免該音訊資料被篡改。
上述實施例中，音訊協議僅存在單個協議參與方，即該音訊協議為單方音訊協議；而在其他實施例中，音訊協議還可以為多方音訊協議，即存在多個協議參與方，下面針對多方音訊協議的場景進行描述。
假定用戶A與用戶B均為協議參與方，即由用戶A與用戶B共同參與簽訂一項音訊協議。如圖4所示，用戶A與用戶B可以位於同一處，並共同使用手機21完成實人認證、音訊資料的採集等操作。在實人認證過程中，手機21可以透過攝影機模組同時採集到包含用戶A和用戶B的圖像，並據此針對用戶A和用戶B實施實人認證，其過程與圖2所示的實施例類似，此處不再贅述。或者，用戶A和用戶B可以對手機21進行分時多工，比如首先由用戶A使用手機21完成實人認證，然後換由用戶B使用手機21完成實人認證，對於每個用戶的實人認證過程分別與圖2所示的實施例類似，此處不再贅述。
然後，可以透過手機21對用戶A、用戶B進行音訊採集，以獲得相應的音訊資料。在一實施例中，手機21可以產生一份音訊資料，該音訊資料中包含：表徵所需簽訂的協議內容的音訊內容、表徵用戶A和用戶B認可該協議內容的音訊內容；比如，用戶A可以朝向手機21的麥克風說出“我承諾將XX小區2號樓302室出租給用戶B，租金為每月3000元”，而用戶B可以朝向手機21的麥克風說出“我承諾從用戶A處租用XX小區2號樓302室，租金為每月3000元”，那麼協議內容為“用戶A向用戶B出租XX小區2號樓302室，租金為每月3000元”，且用戶A、用戶B關於“我承諾……”的句式表達了對上述協議內容的認可態度。當然，音訊內容的表達形式並不受限，只要能夠表徵上述兩方面的含義即可。
在另一實施例中，手機21可以針對用戶A和用戶B分別產生一份音訊資料，對應於用戶A的音訊資料中包含：表徵所需簽訂的協議內容的音訊內容、表徵用戶A認可該協議內容的音訊內容，對應於用戶B的音訊資料中包含：表徵所需簽訂的協議內容的音訊內容、表徵用戶B認可該協議內容的音訊內容。對於每份音訊資料，產生方式與圖3或圖4所示的實施例相類似，此處不再贅述。
除了共用手機21之外，用戶A與用戶B還可以分別使用不同的電子設備，比如圖5所示，用戶A可以使用手機21、用戶B可以使用手機23，尤其是當用戶A與用戶B分別處於不同地理位置時，仍然可以遠程簽訂音訊協議，而無需前往同一地點進行協議簽訂。
在一實施例中，可由任一協議參與方透過手機21向伺服器22請求音訊協議的簽訂功能，比如該任一協議參與方為用戶A時，該用戶A可以指定用戶B為相關聯的協議參與方，使得用戶A使用的手機21(登錄有用戶A的帳號)與用戶B使用的手機23(登錄有用戶B的帳號)之間可以實現協同，從而共同參與到同一音訊協議的簽訂過程中。
手機21可以針對用戶A實施實人認證，並採集用戶A相關的音訊資料，這與圖3-4所示實施例的情況類似，此處不再贅述；手機23可以針對用戶B實施實人認證，並採集用戶B相關的音訊資料，這與手機21的實施過程類似，此處不再贅述。
在一實施例中，由於用戶A與用戶B有可能處於不同的地理位置處，使得兩者可能並不能夠直接獲知對方的音訊採集情況，因而伺服器22在獲得一方的音訊資料後，可以將其傳遞至另一方進行核對，使得用戶A、用戶B既可以確認自身的音訊採集情況，也可以獲知對方的音訊採集情況。尤其是，透過對音訊資料的相互傳遞，使得每一協議參與方可以獲知各個協議參與方的音訊資料，從而對音訊資料所含的音訊內容進行核對，便於發現伺服器22可能不易察覺的文字陷阱、歧義等情形；並且，每一協議參與方均可以具備終止簽訂的權限，使得任一協議參與方對其他協議參與方的音訊資料存在異議、且其他協議參與方拒絕修改時，均可以終止協議簽訂，以保障協議參與方的權益。
需要指出的是：雖然本說明書涉及到音訊協議的簽訂，但並不意味著不能夠實施視頻採集。例如圖5所示，手機21、手機23可以分別透過攝影機模組對用戶A、用戶B進行拍攝，並將自身拍攝到的視頻畫面傳輸至對方進行展示，使得每一協議參與方使用的電子設備上，可以展示出分別對應於各個協議參與方的視頻窗口，以分別用於展示各個協議參與方使用的電子設備拍攝的視頻畫面；譬如，手機21、手機23上可以分別展示出兩個視頻窗口，以分別展示手機21和手機23拍攝的視頻畫面，使得用戶A、用戶B既可以查看到自身的視頻拍攝情況，也可以查看到對方的視頻拍攝情況，一方面可使協議簽訂過程更加具有現場感，另一方面便於各個協議參與方之間實現相互查看、相互制約，有助於及時發現可能存在的問題。
此外，對於圖4-5所示的實施例而言，當手機21或手機23將音訊資料上傳至伺服器22後，與圖3所示實施例相類似的，可由伺服器22對音訊資料進行分析，然後透過調用智慧合約對分析結果進行檢驗，比如可以針對下述方面中至少之一進行檢驗：協議內容是否包含非法內容、協議內容是否包含無效內容、協議參與方是否認可協議內容、協議參與方表達“認可”的狀態是否正常等，此處不再贅述。以及，伺服器22可以向區塊鏈中發佈相應的音訊協議，該音訊協議可以包含音訊資料以及用戶A、用戶B等所有協議參與方的簽名(可透過用於表徵各個協議參與方的數位身分的密鑰而產生)；或者，該音訊協議可以包含音訊資料的雜湊值和所有協議參與方的簽名，而將音訊資料儲存於伺服器22本地、避免上鏈。
在一實施例中，在圖3-5所示的實施例中，伺服器22可以將音訊資料轉換為文字協議，並由所有協議參與方進行簽名後，單獨發佈或者與上述音訊資料(或音訊資料的雜湊值)相關聯地發佈至區塊鏈中進行存證。
需要指出的是：雖然在上述實施例中，涉及到多方協議時以用戶A與用戶B之間的協議簽訂場景進行舉例，但本說明書的技術方案同樣可以應用於更多數量的協議參與方之間，以實現三方或更多方的協議簽訂，本說明書並不對此進行限制。
圖6是一示例性實施例提供的一種設備的示意結構圖。請參考圖6，在硬體層面，該設備包括處理器602、內部匯流排604、網路介面606、內部記憶體608以及非易失性記憶體610，當然還可能包括其他業務所需要的硬體。處理器602從非易失性記憶體610中讀取對應的電腦程式到內部記憶體608中然後運行，在邏輯層面上形成基於區塊鏈的音訊協議簽訂裝置。當然，除了軟體實現方式之外，本說明書一個或多個實施例並不排除其他實現方式，比如邏輯裝置抑或軟硬體結合的方式等等，也就是說以下處理流程的執行主體並不限定於各個邏輯單元，也可以是硬體或邏輯裝置。
請參考圖7，在軟體實施方式中，該基於區塊鏈的音訊協議簽訂裝置應用於區塊鏈節點，可以包括：
認證單元71，根據接收到的音訊協議簽訂請求，對所述音訊協議簽訂請求指示的協議參與方進行身分認證；
第一獲取單元72，在身分認證通過後獲取所述協議參與方提供的音訊資料，所述音訊資料中包含用於表徵協議內容的第一音訊資訊和用於表徵所述協議參與方認可所述協議內容的第二音訊資訊；
發佈單元73，將所述音訊資料和/或所述音訊資料的數位摘要資訊發佈至區塊鏈，以記錄為所述協議參與方簽訂的音訊協議。
可選的，還包括：
第二獲取單元74，獲取音訊協議的簽訂屬性；
所述發佈單元73在將所述音訊資料和/或所述音訊資料的數位摘要資訊發佈至區塊鏈時，還關聯發佈所述簽訂屬性。
可選的，所述簽訂屬性包括以下至少之一：
所述協議參與方的身分資訊、所述協議參與方的所處地點、協議簽訂時刻。
可選的，還包括：
第一調用單元75，調用智慧合約，所述智慧合約被用於驗證所述第一音訊資訊所表徵的協議內容是否合法有效。
可選的，還包括：
第二調用單元76，調用智慧合約，所述智慧合約被用於驗證所述第二音訊資訊所表徵的所述協議參與方對所述協議內容的認可情況是否有效。
可選的，所述音訊協議為單方協議，存在一個協議參與方；或者，所述音訊協議為多方協議，存在多個協議參與方。
可選的，
當存在多個協議參與方時，多個協議參與方對應於同一份音訊資料，該音訊資料包含的第二音訊資訊用於表徵多個協議參與方對所述協議內容的認可情況；
或者，當存在多個協議參與方時，多個協議參與方分別對應於不同的音訊資料，每一音訊資料包含的第二音訊資訊用於表徵相應的協議參與方對所述協議內容的認可情況。
可選的，還包括：
第三調用單元77，調用智慧合約，所述智慧合約被用於在多個協議參與方分別對應於不同的音訊資料的情況下，驗證各個音訊資料包含的第一音訊資訊所表徵的協議內容是否一致。
可選的，還包括：
第四調用單元78，調用智慧合約，所述智慧合約被用於根據所述音訊資料產生文字協議，並透過所述協議參與方的資料身分進行簽名；
所述發佈單元73在將所述音訊資料和/或所述音訊資料的數位摘要資訊發佈至區塊鏈時，還關聯發佈所述文字協議。
上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、膝上型電腦、行動電話、相機電話、智慧電話、個人數位助理、媒體播放器、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
在一個典型的配置中，電腦包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和內部記憶體。
內部記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非易失性內部記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。內部記憶體是電腦可讀媒體的示例。
電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變內部記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可抹除可編程唯讀記憶體(EEPROM)、快閃記憶體或其他內部記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶、磁碟儲存、量子記憶體、基於石墨烯的儲存媒體或其他磁性儲存設備或任何其他非傳輸媒體，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀媒體不包括暫存電腦可讀媒體(transitory media)，如調變的資料信號和載波。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
上述對本說明書特定實施例進行了描述。其它實施例在申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多任務處理和並行處理也是可以的或者可能是有利的。
在本說明書一個或多個實施例使用的術語是僅僅出於描述特定實施例的目的，而非旨在限制本說明書一個或多個實施例。在本說明書一個或多個實施例和所附申請專利範圍中所使用的單數形式的“一種”、“所述”和“該”也旨在包括多數形式，除非上下文清楚地表示其他含義。還應當理解，本文中使用的術語“和/或”是指並包含一個或多個相關聯的列出項目的任何或所有可能組合。
應當理解，儘管在本說明書一個或多個實施例可能採用術語第一、第二、第三等來描述各種資訊，但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如，在不脫離本說明書一個或多個實施例範圍的情況下，第一資訊也可以被稱為第二資訊，類似地，第二資訊也可以被稱為第一資訊。取決於語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“回應於確定”。
以上所述僅為本說明書一個或多個實施例的較佳實施例而已，並不用以限制本說明書一個或多個實施例，凡在本說明書一個或多個實施例的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本說明書一個或多個實施例保護的範圍之內。The exemplary embodiments will be described in detail here, and examples thereof are shown in the drawings. When the following description refers to drawings, unless otherwise indicated, the same digits in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with one or more embodiments of this specification. On the contrary, they are only examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the scope of the patent application.
It should be noted that in other embodiments, the steps of the corresponding method may not be executed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.
Fig. 1 is a flowchart of a method for signing an audio agreement based on a blockchain according to an exemplary embodiment. As shown in Figure 1, the method is applied to blockchain nodes and can include the following steps:
Step 102: Perform identity authentication on the agreement participants indicated by the audio agreement signing request according to the received audio agreement signing request.
In one embodiment, by installing and running a blockchain client on an electronic device, the electronic device can be configured as a blockchain node in the blockchain network. For example, the electronic device can include a server, a PC , Tablet computers, mobile phones and other types; in other words, blockchain nodes can be carried on any form of electronic equipment, and this manual does not limit this.
In an embodiment, the parties to the agreement indicated by the request for signing the audio agreement may be one party or multiple parties, and identity authentication may be implemented for each party to the agreement respectively. Among them, the method of identity authentication may include any of the following: fingerprint recognition, voiceprint recognition, face recognition, real person authentication, etc. This specification does not limit this. For example, when the identity authentication is fingerprint recognition, the acquired identity data may include the fingerprint image of the user; for another example, when the identity authentication is voiceprint recognition, the acquired identity data may include the voiceprint characteristics of the user; for example, When the identity authentication is in the form of face recognition, the acquired identity data can include the face image of the user; for example, when the identity authentication is real person authentication, the acquired identity data can include the face image, face Video, credential image, audio (for example, a specific verification code read by the user, etc.), etc.
In one embodiment, if there are multiple protocol participants, there may be multiple situations: for example, multiple protocol participants can use different electronic devices, and each protocol participant can collect and upload data through its own electronic device. Identity data; for another example, multiple parties to the agreement can be in the same location, and these parties to the agreement can share an electronic device, such as taking turns to collect and upload identity data through the electronic device, or the electronic device simultaneously conducts a report on the parties to the agreement. The collection and upload of identity data; of course, there may be other situations, and this manual does not limit this.
Step 104: Obtain the audio data provided by the agreement participant after the identity authentication is passed, and the audio data includes the first audio information used to characterize the content of the agreement and the information used to characterize the agreement content of the agreement participant. Second audio information.
In an embodiment, the content of the first audio information may be an audio fragment read by the agreement participant; or, the content of the first audio information may be an audio fragment read by another user other than the agreement participant. ; Or, First Audio Information can characterize the content of the agreement in other ways, and this manual does not limit this.
In one embodiment, the content of the second audio information can be a sentence similar to "I agree", "I confirm", "I agree" or the like for the parties to the agreement; or, the second audio information can be in other ways It characterizes the meaning of "recognition", and this specification does not limit it.
In one embodiment, similar to the process of obtaining identity data, there may be multiple situations: for example, multiple parties to the agreement can use different electronic devices, and each party to the agreement can collect data through its own electronic device. And upload audio data; for another example, multiple parties to the agreement can be in the same location, and these agreement parties can share an electronic device, such as taking turns to collect and upload audio data through the electronic device, or the electronic device can participate in these agreements at the same time The party collects and uploads audio data; of course, there may be other situations, and this manual does not limit this.
Step 106: Publish the audio data and/or the digital summary information of the audio data to the blockchain to record the audio agreement signed by the agreement participants.
In one embodiment, by publishing the audio data to the blockchain, it can be ensured that the audio data cannot be tampered with or the tampering behavior of the audio data can be verified, and the audio data can be checked by querying the blockchain ledger. Traceability is extremely reliable. The digital summary information of the audio data can be the hash value of the audio data, etc., which can be uniquely matched to the audio data, and the digital summary information of the audio data can be published to the blockchain, and the audio data can be stored locally instead of on the chain. , Then based on the unique matching relationship between the audio data and its digital summary information, it can ensure that the audio data cannot be tampered with or make the tampering behavior of the audio data verifiable, and at the same time, it can avoid the disclosure of the content of the audio data and help achieve privacy protect.
In one embodiment, since the first audio information is used to characterize the content of the agreement in the audio data, and the second audio information is used to characterize the agreement participants’ attitudes towards the content of the agreement, the audio data in this specification has actually been implemented. The functions required by the textual agreement in the technology, and the agreement participants do not need to form specific text content in the technical solution of this manual. Multiple agreement participants do not have to go to the same place to sign the agreement, so as to ensure the validity of the agreement while ensuring the validity of the agreement. It greatly simplifies the operation of the parties to the agreement and improves the efficiency of signing the agreement.
In an embodiment, the blockchain node can obtain the signing attribute of the audio agreement. For example, the signing attribute can include at least one of the following: the identity information of the agreement participant, the location of the agreement participant, and the signing of the agreement Time, etc., this manual does not limit it. Then, when the blockchain node publishes the audio data and/or the digital summary information of the audio data to the blockchain, it also publishes the signing attribute in association, so that the agreement event represented by the audio data has more Multi-dimensional feature information helps to improve the credibility of audio data.
In an embodiment, the blockchain node may call a smart contract, and the smart contract is used to verify whether the content of the agreement represented by the first audio information is legal and valid. For example, the blockchain node can analyze the agreement content represented by the first audio information, extract the agreement content as text information, and provide the text information to the smart contract, so that the smart contract can compare the agreement represented by the first audio information The content is analyzed, such as whether it hits a sensitive word, whether it expresses illegal semantics, whether the content of the agreement is ambiguous or has ambiguity, etc. This manual does not limit this. When the content of the protocol is verified as legal and valid, the blockchain node is allowed to perform other operations; when the content of the protocol is verified as illegal or invalid, the above audio data can be judged as an invalid protocol, and the audio data can also be marked or added as invalid. Prevent the audio data from taking effect.
In one embodiment, a blockchain node may call a smart contract, and the smart contract is used to verify whether the agreement participant's approval status of the agreement content represented by the second audio information is valid. For example, the blockchain node can analyze the approval status represented by the second audio information and provide the approval status to the smart contract, so that the smart contract can analyze the approval status represented by the second audio information, such as whether it is ambiguous Or there is ambiguity, whether there is a coercion situation, etc., this manual does not limit this. When the approval status is verified as valid, the blockchain node is allowed to perform other operations; when the approval status is verified as illegal or invalid, the above audio data can be judged as invalid protocols, and the audio data can also be marked or blocked. The audio data is valid.
In one embodiment, when there are multiple protocol participants, the multiple protocol participants correspond to the same piece of audio data, and the second audio information contained in the audio data is used to characterize the agreement content of the multiple protocol participants. Recognition situation. In another embodiment, when there are multiple protocol participants, the multiple protocol participants respectively correspond to different audio data, and the second audio information contained in each audio data is used to characterize the response of the corresponding protocol participant to the Recognition of the content of the agreement.
In one embodiment, the blockchain node can call a smart contract, which is used to verify the first audio information contained in each audio data when multiple protocol participants correspond to different audio data. Whether the content of the characterization agreement is consistent. For example, the blockchain node can extract the agreement content represented by the first audio information in each audio data and pass it to the smart contract, so that the smart contract compares the agreement content corresponding to each audio data; if the agreement content All are consistent, allowing blockchain nodes to perform other operations. If the content of the protocol is not completely consistent, the audio data generated this time can be judged as an invalid protocol, and the audio data can also be marked as invalid or prevent the audio data from taking effect (avoid based on these The audio data forms an audio contract).
In one embodiment, a blockchain node can call a smart contract, which is used to generate a text agreement based on the audio data, and sign through the data identities of the parties to the agreement; When the audio data and/or the digital summary information of the audio data is released to the blockchain, the blockchain node also publishes the text protocol in association, so as to be implemented based on the audio data and the text protocol at the same time.
In one embodiment, the agreement in this specification may include a unilateral agreement, such as a letter of commitment, will, statement, etc., which is not limited in this specification. In one embodiment, the agreement in this specification may include a multi-party agreement or called a contract, such as a house lease contract, a commodity sales contract, a labor contract, etc. The specification does not limit this.
For ease of understanding, the following takes the signing of an agreement as an example to describe the technical solutions of one or more embodiments of this specification. Fig. 2 is a schematic diagram of implementing real person authentication provided by an exemplary embodiment. As shown in Figure 2, assuming that user A uses a mobile phone 21 (or other types of electronic equipment, this specification does not limit this), the mobile phone 21 can run an APP client of an application X or load the corresponding application X Website to provide user A with the function of signing an audio agreement. In the process of signing the audio agreement, application X can perform real person authentication on user A, so as to effectively manage the real identity of user A, and accurately define the agreement participants (ie, user A) of the related audio agreement.
In one embodiment, the mobile phone 21 can collect images of user A through the camera module, so that the collected pictures or videos include the face image of user A, and the image of user A holding a valid certificate (such as an ID card). The image, the image of user A performing corresponding actions in accordance with the instruction, etc., is used as the identity data for user A, and the mobile phone 21 uploads the identity data to the server 22, so that the server 22 can be based on face detection, face recognition, Various technical methods such as OCR certificate recognition and living body detection implement real person authentication for user A.
After the real person authentication is completed, user A can sign the corresponding audio agreement based on the identity information that has been authenticated. Fig. 3 is a schematic diagram of signing an audio agreement provided by an exemplary embodiment. As shown in Figure 3, the mobile phone 21 can collect audio from user A through a microphone, and ensure that the collected audio data can represent at least two aspects: on the one hand, the audio data needs to represent the content of the agreement to be signed, on the other hand , The audio data needs to signify that user A approves the content of the agreement.
In an embodiment, the user A can speak the voice content that meets the above requirements toward the microphone of the mobile phone 21. For example, when user A says voice content such as "I promise to donate 1 million yuan to XX organization", the characterizing agreement content can be "User A donates 1 million yuan to XX organization", and "I promise..." The sentence pattern expresses user A's attitude towards the content of the above-mentioned agreement, so it can be considered that the above-mentioned requirements are met.
The foregoing embodiment involves user A signing a unilateral audio agreement, that is, the agreement participants of the audio agreement only include user A, but this scenario does not mean that only user A can participate in the audio data collection process. For example, as shown in Figure 4, both user A and user B can appear in the audio data collected by the mobile phone 21, and the server 22 can perform real person authentication for user A and user B respectively; after the real person authentication is passed, user B can Assist user A to complete audio collection, for example, user B dictates the content of the agreement, and user A confirms the content of the agreement dictated by user B. For example, the dictated content of user B can be "a donation of 1 million yuan from user A to XX organization", And user A can confirm through content such as "I agree".
In an embodiment, the server 22 may analyze the audio data uploaded by the mobile phone 21 to determine the audio content contained therein, such as the above-mentioned agreement content, the user A's approval of the agreement content, and so on. Then, the server 22 can inspect the aforementioned audio content based on the inspection rules defined in the smart contract by invoking the smart contract; the inspection rules may include at least one of the following: whether the agreement content contains illegal content (for example, it can match Whether the content of the agreement contains preset sensitive words), whether the content of the agreement contains invalid content (such as whether the content of the agreement is clear and accurate through semantic analysis), whether the parties to the agreement recognize the content of the agreement (such as whether the parties to the agreement issue a voice that expresses "approval" Or make an action to express “approval”, etc.), whether the state of the agreement participants expressing “approval” is normal (such as whether the tone or expression of the agreement participants is normal, whether there is a situation of being coerced, etc.), etc., this manual is not correct This is limited.
In one embodiment, after the server 22 determines that the audio content of the audio data passes the inspection, it can publish the corresponding audio protocol to the blockchain. For example, the server 22 may publish a transaction to the blockchain, the transaction includes the aforementioned audio data, and the audio data is signed by a key used to characterize the digital identity of user A to indicate that the audio data is user A. Participate in the audio protocol, and the content of the transaction can be recorded in the blockchain ledger, thereby achieving the deposit of the audio protocol.
In one embodiment, the server 22 may only store the above-mentioned audio data locally, and the transaction issued to the blockchain only contains the hash value of the audio data. On the one hand, it can prevent the content of the audio protocol from being disclosed and It helps to improve the privacy of the data. On the other hand, the audio data stored locally by the server 22 can be verified according to the hash value recorded in the blockchain ledger to prevent the audio data from being tampered with.
In the above embodiment, the audio protocol has only a single protocol participant, that is, the audio protocol is a single-party audio protocol; and in other embodiments, the audio protocol can also be a multi-party audio protocol, that is, there are multiple protocol participants. The scenario of the audio protocol is described.
It is assumed that both user A and user B are parties to the agreement, that is, user A and user B jointly sign an audio agreement. As shown in Fig. 4, user A and user B can be located at the same place, and use the mobile phone 21 together to complete operations such as real person authentication and audio data collection. In the real person authentication process, the mobile phone 21 can simultaneously collect images containing user A and user B through the camera module, and implement real person authentication for user A and user B accordingly. The process is the same as the implementation shown in Figure 2. The example is similar, so I won't repeat it here. Alternatively, user A and user B can perform time-sharing multiplexing on the mobile phone 21. For example, first user A uses the mobile phone 21 to complete the real person authentication, and then user B uses the mobile phone 21 to complete the real person authentication. The authentication process is similar to the embodiment shown in FIG. 2, and will not be repeated here.
Then, audio collection can be performed on user A and user B through the mobile phone 21 to obtain corresponding audio data. In one embodiment, the mobile phone 21 may generate a piece of audio data, the audio data includes: audio content that characterizes the content of the agreement to be signed, and audio content that characterizes the agreement content of user A and user B; for example, user A You can say "I promise to rent Room 302, Building 2 of XX Community to User B at a monthly rent of 3000 yuan" toward the microphone of mobile phone 21, and user B can say "I promise from user A to the microphone of mobile phone 21" Rent Room 302, Building 2 of XX Community, the rent is 3000 yuan per month", then the content of the agreement is "User A rents Room 302, Building 2 of XX Community to User B, the rent is 3000 yuan per month", and users A and B The sentence about "I promise..." expresses the attitude of approving the content of the above-mentioned agreement. Of course, the form of expression of audio content is not limited, as long as it can represent the meaning of the above two aspects.
In another embodiment, the mobile phone 21 may generate a piece of audio data for user A and user B respectively, and the audio data corresponding to user A includes: audio content representing the content of the agreement to be signed, and representing that user A approves the agreement The audio content of the content corresponds to user B's audio data including: audio content representing the content of the agreement to be signed, and audio content representing user B's approval of the content of the agreement. For each piece of audio data, the generation method is similar to the embodiment shown in FIG. 3 or FIG. 4, and will not be repeated here.
In addition to sharing the mobile phone 21, user A and user B can also use different electronic devices. For example, as shown in Figure 5, user A can use mobile phone 21 and user B can use mobile phone 23, especially when user A and user B respectively When in different geographical locations, it is still possible to sign an audio agreement remotely, without having to go to the same place to sign the agreement.
In one embodiment, any participant of the agreement may request the signing function of the audio agreement from the server 22 through the mobile phone 21. For example, when the participant of any agreement is user A, the user A may designate user B as the associated agreement. Participants, so that the mobile phone 21 used by user A (logged in with the account of user A) and the mobile phone 23 used by user B (logged in with the account of user B) can be coordinated, thereby jointly participating in the signing of the same audio agreement .
The mobile phone 21 can implement real person authentication for user A, and collect audio data related to user A, which is similar to the case of the embodiment shown in Figure 3-4, and will not be repeated here; mobile phone 23 can implement real person authentication for user B , And collect the audio data related to user B, which is similar to the implementation process of the mobile phone 21, and will not be repeated here.
In one embodiment, since user A and user B may be in different geographic locations, the two may not be able to directly learn the audio collection situation of the other party. Therefore, after the server 22 obtains one party's audio data, it can It is passed to the other party for verification, so that user A and user B can not only confirm their own audio collection status, but also learn the other party's audio collection status. In particular, through the mutual transfer of audio data, each protocol participant can learn the audio data of each protocol participant, so that the audio content contained in the audio data can be checked, and it is convenient to find text traps that the server 22 may not easily detect. , Ambiguity, etc.; and each of the parties to the agreement can have the authority to terminate the signing, so that any party to the agreement has objections to the audio data of the other party to the agreement, and the other party to the agreement refuses to modify the agreement, the agreement can be terminated Signed to protect the rights and interests of the parties involved in the agreement.
It should be pointed out that although this manual involves the signing of an audio agreement, it does not mean that video capture cannot be implemented. For example, as shown in Fig. 5, the mobile phone 21 and the mobile phone 23 can respectively shoot user A and user B through the camera module, and transmit the video images captured by themselves to the other party for display, so that the electronic equipment used by each party to the agreement On the above, the video windows corresponding to each protocol participant can be displayed to display the video images taken by the electronic equipment used by each protocol participant; for example, two video windows can be displayed on the mobile phone 21 and the mobile phone 23 respectively. , To separately display the video images taken by the mobile phone 21 and the mobile phone 23, so that the user A and the user B can view their own video shooting situation, but also the other party's video shooting situation. On the one hand, the agreement signing process can be more on-site. On the other hand, it is convenient for the parties to the various agreements to view and restrict each other, which helps to discover possible problems in time.
In addition, for the embodiment shown in FIGS. 4-5, when the mobile phone 21 or the mobile phone 23 uploads the audio data to the server 22, similar to the embodiment shown in FIG. 3, the server 22 can perform the audio data processing. Analyze, and then check the analysis result by calling the smart contract. For example, you can check for at least one of the following aspects: whether the content of the agreement contains illegal content, whether the content of the agreement contains invalid content, whether the parties to the agreement recognize the content of the agreement, and participate in the agreement Whether the state of the party’s expression of "approval" is normal, etc., will not be repeated here. And, the server 22 can publish a corresponding audio protocol to the blockchain. The audio protocol can include audio data and the signatures of all protocol participants such as user A and user B (which can be used to characterize the digital identity of each protocol participant). Alternatively, the audio protocol can include the hash value of the audio data and the signatures of all protocol participants, and the audio data is stored locally on the server 22 to avoid being chained.
In one embodiment, in the embodiment shown in Figs. 3-5, the server 22 can convert the audio data into a text agreement, and after all the parties to the agreement sign it, they can publish it separately or in conjunction with the aforementioned audio data (or audio data). The hash value of the data) is correlated to the blockchain for storage.
It should be pointed out that although in the above-mentioned embodiment, when a multi-party agreement is involved, the scenario of signing an agreement between user A and user B is used as an example, but the technical solution of this specification can also be applied to a larger number of parties to the agreement. In order to realize the signing of an agreement between three or more parties, this manual does not limit this.
Fig. 6 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to Figure 6, at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, an internal memory 608, and a non-volatile memory 610. Of course, it may also include hardware required for other services. body. The processor 602 reads the corresponding computer program from the non-volatile memory 610 to the internal memory 608 and then runs it to form a block chain-based audio agreement signing device at the logical level. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., which means that the execution body of the following processing flow is not limited to Each logical unit can also be a hardware or a logical device.
Please refer to Figure 7. In the software implementation, the block chain-based audio agreement signing device is applied to a block chain node, which may include:
The authentication unit 71, according to the received audio agreement signing request, performs identity authentication on the agreement participants indicated by the audio agreement signing request;
The first obtaining unit 72 obtains the audio data provided by the agreement participant after the identity authentication is passed, and the audio data includes the first audio information used to characterize the content of the agreement and the first audio information used to characterize the agreement The second audio information of the agreement content;
The publishing unit 73 publishes the audio data and/or the digital summary information of the audio data to the blockchain to record the audio agreement signed by the parties to the agreement.
Optionally, it also includes:
The second obtaining unit 74 obtains the signing attribute of the audio agreement;
When the publishing unit 73 publishes the audio data and/or the digital summary information of the audio data to the blockchain, it also publishes the signing attributes in association.
Optionally, the signing attribute includes at least one of the following:
The identity information of the parties to the agreement, the location of the parties to the agreement, and the time when the agreement is signed.
Optionally, it also includes:
The first calling unit 75 calls a smart contract, and the smart contract is used to verify whether the content of the agreement represented by the first audio information is legal and valid.
Optionally, it also includes:
The second invoking unit 76 invokes a smart contract, and the smart contract is used to verify whether the agreement participant's recognition of the agreement content represented by the second audio information is valid.
Optionally, the audio protocol is a single-party agreement, and there is one protocol participant; or, the audio protocol is a multi-party agreement, and there are multiple protocol participants.
Optional,
When there are multiple parties to the agreement, the multiple parties to the agreement correspond to the same piece of audio data, and the second audio information contained in the audio data is used to characterize the recognition of the content of the agreement by the multiple parties to the agreement;
Or, when there are multiple protocol participants, the multiple protocol participants respectively correspond to different audio data, and the second audio information contained in each audio data is used to characterize the recognition of the agreement content by the corresponding protocol participant .
Optionally, it also includes:
The third calling unit 77 calls a smart contract that is used to verify whether the content of the agreement represented by the first audio information contained in each audio data is in the case that multiple parties to the agreement respectively correspond to different audio data Unanimous.
Optionally, it also includes:
The fourth calling unit 78 calls a smart contract, the smart contract is used to generate a text agreement based on the audio data, and sign through the data identities of the parties to the agreement;
When the publishing unit 73 publishes the audio data and/or the digital summary information of the audio data to the blockchain, it also publishes the text agreement in association.
The systems, devices, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of a computer can be a personal computer, a laptop, a mobile phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game console. , Tablets, wearable devices, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and internal memory.
Internal memory may include non-permanent memory in computer-readable media, random access memory (RAM) and/or non-volatile internal memory, such as read-only memory (ROM) or flash memory Body (flash RAM). Internal memory is an example of computer-readable media.
Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change internal memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM). ), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other internal memory technology, read-only CD-ROM (CD-ROM), digital multi Functional optical disc (DVD) or other optical storage, magnetic cassette tape, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used for storage and can be accessed by computing devices Information. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element.
The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the scope of the appended patent application are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to certainty".
The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principle of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. made should be included in the protection scope of one or more embodiments of this specification.
