一種基於二維碼的文件協同處理方法及系統與流程

2024-03-05 11:42:15 2

本發明涉及文件協同處理領域，特別涉及一種基於二維碼的文件協同處理方法及系統。

背景技術：

文件共享包括了：本地區域網共享、網盤雲共享、U盤文件共享方面。

協同處理，是指發生在兩臺或多臺計算機分擔一個程序或計算任務處理的分布式計算系統中。一般而言，協同處理需要一個複雜的程序能在網絡上處理分配負載、共享數據文件和內存競爭，同時要維持信息的同步安全性和準確性。

此外，在遠程協同處理上述共享文件中的某一個文案時，往往要反覆上傳、下載，甚至還會遇到Word、Office等版本不同，還需要各種更新；特別是當Windows與Mac系統文件相遇時，不僅版本不兼容且無法實現多人協同操作。

目前單據的錄入是軟體使用過程中最常見的場景，較為常見的應用場景是：通常一個單據由一個錄入員在一臺設備上就可以完成，但也存在一些場景比較複雜。

首先，單據需要的資料在多個人手中，比如地產工地現場的一些變更涉及到合同信息、費用、施工設計、變更前後照片等，需要開發商、施工方等多人提供資料。

其次，單據信息在不同設備上，比如在office附件在pc上，但一些現場的施工照片在手機上。

上述複雜的場景通常做法有兩種形式：

1.線下搜集資料，然後交給統一對接人統一錄入；

2.通過流程轉接進行協作，一個人錄入完成後再轉到下個人進行錄入；

這兩種方式都會導致單據錄入很繁瑣，而且周期非常長，用戶體驗差。

技術實現要素：

本發明要解決的技術問題是，如何實現高效率處理和快捷協同處理的基於二維碼的文件協同處理方法。

解決上述技術問題，本發明提供了一種基於二維碼的文件協同處理方法，包括如下步驟：

第一協作者，按照文件處理需求生成第一處理指令，

根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至：

第二協作者，

第三協作者，

……

第N協作者，N為自然數，

所述第二協作者、第三協作者……以及第N協作者通過掃描所述文件二維碼獲取編輯權限，根據所述編輯權限編輯符合上述文件處理需求的內容，並且分別上傳；

所述第一協作者同步獲得上述編輯過後的內容並提交。

更進一步，所述第一協作者、所述第二協作者、第三協作者……以及第N協作者與伺服器通過長連接保持通信。

更進一步，所述文件二維碼分享方法為：微博、連結或者微信中的一種或者多種第三方API接口。

更進一步，所述第一協作者還用以根據同步獲得的編輯內容，生成用以確認提交、重新修訂以及審批通過的第二處理指令。

更進一步，所述第一協作者還用以處理：文件變更、文件作廢、文件處理、文件備案的文件處理需求。

更進一步，根據所述第一處理指令生成文件二維碼的具體方法如下：

基於對應的文件編號ID+當前處理時間+GUID全局唯一標識符，並採用AES對稱加密算法，進行加密後作為所述文件二維碼。

更進一步，當所述第二協作者、第三協作者……以及第N協作者掃描所述文件二維碼時，

通過反解密算法得到文件二維碼的文件編號ID和當前處理時間，再校驗掃描二維碼的所述第二協作者、第三協作者……以及第N協作者是否具有該文件的權限；

若有權限，則根據當前處理時間校驗是否過期，

以及，校驗是否被提交了，若已提交則其他協作者不能再進行編輯。

基於上述本發明提供了一種基於二維碼的文件協同處理系統，包括：多個客戶端以及至少一個伺服器端，

所述客戶端與伺服器端連接，所述客戶端包括：第一客戶端、第二客戶端、第三客戶端……以及第N客戶端；

所述第一客戶端用以，按照文件處理需求生成第一處理指令，根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至：

第二客戶端，

第三客戶端，

……

第N客戶端，N為自然數，

在所述第二客戶端、第三客戶端……以及第N客戶端通過掃描所述文件二維碼獲取編輯權限，根據所述編輯權限編輯符合上述文件處理需求的內容，並且分別上傳；

在所述第一客戶端同步獲得上述編輯過後的內容並提交，

上述第一客戶端、第二客戶端、第三客戶端……第N客戶端分別與所述伺服器端通過長連接保持通信。

此外，本發明還提供了基於二維碼的文件協同處理的客戶端，所述客戶端被配置為：

按照文件處理需求生成第一處理指令，

根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至其它客戶端；

通過掃描所述文件二維碼獲取編輯權限，根據所述編輯權限編輯符合上述文件處理需求的內容，並且分別上傳；

同步獲得上述編輯過後的內容並提交。

此外，本發明還提供了基於二維碼的文件協同處理的伺服器端，所述伺服器端用以，

接收第一協作者按照文件處理需求生成第一處理指令，根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至與其長連接的：

第二協作者，

第三協作者，

……

第N協作者，N為自然數，

若所述第二協作者、第三協作者……以及第N協作者通過掃描所述文件二維碼獲取編輯權限，則接收根據所述編輯權限編輯符合上述文件處理需求的內容分別上傳的文件，

以及，接收從所述第一協作者提交的同步獲得的編輯過後的內容

本發明的有益效果：

1)本發明中的基於二維碼的文件協同處理方法由於第一協作者，按照文件處理需求生成第一處理指令，根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至：第二協作者，第三協作者，……第N協作者，然後，所述第二協作者、第三協作者……以及第N協作者通過掃描所述文件二維碼獲取編輯權限，根據所述編輯權限編輯符合上述文件處理需求的內容，並且分別上傳；最後，所述第一協作者同步獲得上述編輯過後的內容並提交。上述過程基於文件二維碼生成、文件二維碼分享以及協作者與伺服器端的長連接。此外，所有協作者都能夠實時共享其它協作者添加的內容，而第一協作者作為協作的發起者，具有將申請提交並審批的權項，能夠完成文件的審核和提交。上述過程，提高了多人協作編輯的用戶體驗，從而使得數據在多人之間實時傳輸。

2)在本發明中還提供了一種文件的二維碼生成及掃描技術：基於對應的文件編號ID+當前處理時間+GUID全局唯一標識符，並採用AES對稱加密算法，進行加密後作為所述文件二維碼。另外，可以在當所述第二協作者、第三協作者……以及第N協作者掃描所述文件二維碼時，通過反解密算法得到文件二維碼的文件編號ID和當前處理時間，從而實現信息獲取和權項校驗。

3)相較於傳統的方式，線下搜集資料後需要把資料送到同一個地點，需要重複地的花費人力和時間成本。如果通過流程來協作，一個接一個，周期會被拉的很長。而採用本發明中的基於二維碼的文件協同處理方法，可以讓協作者隨時隨地都可以在一起協作，文件錄入的效率提高80％以上。

附圖說明

圖1是本發明一實施例中的方法流程示意圖；

圖2是二維碼生成算法流程示意圖；

圖3與圖2對應的反解密算法流程示意圖；

圖4是本發明中基於客戶端的操作流程示意圖；

圖5是本發明中基於伺服器端的操作流程示意圖；

圖6是本發明的一實施例中的拓撲結構圖；

圖7是本發明一實施例中的交互示意圖；

圖8是本發明另一實施例中的交互示意圖；

圖9是本發明再一實施例中的交互示意圖。

具體實施方式

現在將參考一些示例實施例描述本公開的原理。可以理解，這些實施例僅出於說明並且幫助本領域的技術人員理解和實施例本公開的目的而描述，而非建議對本公開的範圍的任何限制。在此描述的本公開的內容可以以下文描述的方式之外的各種方式實施。

如本文中所述，術語「包括」及其各種變體可以被理解為開放式術語，其意味著「包括但不限於」。術語「基於」可以被理解為「至少部分地基於」。術語「一個實施例」可以被理解為「至少一個實施例」。術語「另一實施例」可以被理解為「至少一個其它實施例」。

圖1是本發明一實施例中的方法流程示意圖，本實施例中的一種基於二維碼的文件協同處理方法，包括如下步驟：

步驟S100第一協作者，按照文件處理需求生成第一處理指令，

步驟S101根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至：

第二協作者，

第三協作者，

……

第N協作者，N為自然數，

步驟S102所述第二協作者、第三協作者……以及第N協作者通過掃描所述文件二維碼獲取編輯權限，根據所述編輯權限編輯符合上述文件處理需求的內容，並且分別上傳；

步驟S103所述第一協作者同步獲得上述編輯過後的內容並提交。

在一些實施例中，在上述步驟S101中所述第一協作者、所述第二協作者、第三協作者……以及第N協作者與伺服器通過長連接保持通信。在本實施例中長連接即是要在客戶端與伺服器之間創建和保持穩定可靠的連接。通常的做法是，在伺服器的程序中加入一個死循環，在循環中監測數據的變動。當發現新數據時，立即將其輸出給瀏覽器並斷開連接，瀏覽器在收到數據後，再次發起請求以進入下一個周期的長輪詢(long-polling)方式。長連接在頁面裡嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設為對一個長連接的請求或是採用xhr請求，伺服器端就能源源不斷地往客戶端輸入數據。

作為本實施例中的優選，所述文件二維碼分享方法為：微博、連結或者微信中的一種或者多種第三方API接口。所述第二協作者、第三協作者……以及第N協作者通過分享的文件二維碼，即可打開對應的需要操作的文件。

在一些實施例中，所述第一協作者還用以根據同步獲得的編輯內容，生成用以確認提交、重新修訂以及審批通過的第二處理指令。

確認提交：將文件確認後提交至接收端。

重新修訂：對文件進行更新或者修改。

審批通過：審批文件中的條款或者款項。

在一些實施例中，所述第一協作者還用以處理：文件變更、文件作廢、文件處理、文件備案的文件處理需求。

文件變更，包括但不限於文件中涉及甲方、乙方或者第三方的文件變更內容。

文件作廢，包括但不限於將文件中的內容部分或者全部作廢。

文件處理，包括但不限於將文件中缺少的內容進行完善、將有誤的內容進行修訂、將多餘的內容進行刪除等。

文件備案，包括但不限於對文件內容進行備份留檔。

在一些實施例中，所述第一協作者作為協作的發起者，所述第二協作者、第三協作者……以及第N協作者作為文件的協作者，所述第一協作者具備查看、修改、審核以及提交等權限，所述所述第二協作者、第三協作者不具備審核以及提交的權限，具備查看更新文件、修改文件的權項。

上述的方法，可以應用至以下的施工場景中：

STEP 1在工地現場需要發起一個變更申請，用戶A(比如，施工方項目經理)打開一個變更的新增界面，填寫變更單。所述變更單除了用戶A要錄入「變更內容」和「變更日期」外還有其他很多信息：

比如，這個施工項目的「合同照片」，在用戶B(比如，施工方的合同管理員)手中；另外還需要上傳「施工前後照片」，在用戶C(比如，施工方工程師)手機上；

STEP 2用戶A在界面上點擊生成二維碼按鈕，生成二維碼，將該二維碼圖片分享給需要協作的用戶B、用戶C、……或者更多需要協作參與的用戶。

STEP 3用戶B、用戶C通過掃描二維碼進入同一個變更單，進行編輯。

STEP 4用戶A、用戶B、用戶C編輯的內容傳遞到伺服器端，再由伺服器端分發給其他用戶，這樣所有人可以同時編輯內容又能實時看到其他人編輯的內容

STEP 5最後由單據的發起人(用戶A)檢查完整後提交單據，只有單據的發起人才能最後提交表單，其他人只能填寫信息和查看別人填寫的信息。

以上完成了文件協同處理，上述過程基於文件二維碼生成、文件二維碼分享以及協作者與伺服器端的長連接。此外，所有協作者都能夠實時共享其它協作者添加的內容，而第一協作者作為協作的發起者，具有將申請提交並審批的權項，能夠完成文件的審核和提交。上述過程，提高了多人協作編輯的用戶體驗，從而使得數據在多人之間實時傳輸。

圖2是二維碼生成算法流程示意圖，根據所述第一處理指令生成文件二維碼的具體方法如下：基於對應的文件編號ID+當前處理時間+GUID全局唯一標識符，並採用AES對稱加密算法，進行加密後作為所述文件二維碼。

作為本實施例中的優選，在上述STEP 1中涉及的所有變更單都是基於合同的，用戶A在點擊「生成二維碼」UI按鈕時，會將該變更單對應的合同ID+當前時間+GUID，用AES對稱加密算法進行加密後作為內容生成二維碼。

所述合同ID包括但不限於：合同編號。

所述當前時間包括但不限於：當前處理髮起時間、當前處理截止時間等。

所述GUID是指，全局唯一標識符(GUID，Globally Unique Identifier)是一種由算法生成的二進位長度為128位的數字標識符。GUID主要用於在擁有多個節點、多臺計算機的網絡或系統中。在理想情況下，任何計算機和計算機集群都不會生成兩個相同的GUID。隨機生成兩個相同GUID的可能性是非常小的，但並不為0。所以，用於生成GUID的算法通常都加入了非隨機的參數(如時間)，以保證這種重複的情況不會發生。本實施例中採用GUID符合多人協作的網絡環境要求即多個節點、多臺計算機的網絡。

作為本實施例中的優選，對稱加密算法還可以是：DES算法、3DES算法，TDEA算法、Blowfish算法、RC5算法、IDEA算法、AES算法。

AES算法是廣泛運用的可以用於保護電子數據的加密算法。在AES算法中採用迭代的、對稱密鑰分組的密碼，它可以使用128、192和256位密鑰，並且用128位(16位元組)分組加密和解密數據。與公共密鑰密碼使用密鑰對不同，對稱密鑰密碼使用相同的密鑰加密和解密數據。通過分組密碼返回的加密數據的位數與輸入數據相同。迭代加密使用一個循環結構，在該循環中重複置換(permutations)和替換(substitutions)輸入數據。採用相同的密鑰加密和解密數據，得到使得所述第二協作者、第三協作者……以及第N協作者通過掃描所述文件二維碼後，能夠解密並獲得文件信息內容。

圖3與圖2對應的反解密算法流程示意圖，包括步驟為：

步驟S300所述第二協作者、第三協作者……以及第N協作者掃描所述文件二維碼，

步驟S301通過反解密算法得到文件二維碼的文件編號ID和當前處理時間，

步驟S302校驗掃描二維碼的所述第二協作者、第三協作者……以及第N協作者是否具有該文件的權限；

步驟S303若有權限，則根據當前處理時間校驗是否過期，

步驟S304校驗是否被提交了，若已提交則其他協作者不能再進行編輯。

上述步驟S302為一級校驗，步驟S303為二級校驗，步驟S304為三極校驗。在所述步驟S302中所述第二協作者、第三協作者……以及第N協作者獲得上述文件的權限，若沒有權限則無法查看或者修改。在所述步驟S303中需要校驗當前處理時間是否過期，比如設定的當前處理時間為2hs，若超過則過期，二維碼失效。在所述步驟S304中，校驗文件是否被協作的發起者提交，若已經提交則無法進行查看或者修改。

若否則進入步驟S305，獲得文件查看或者編輯權限。

在一些實施例中，所述第二協作者、第三協作者……以及第N協作者包括但不限於：PC端、WEB端、IOS/安卓端。

在一些實施例中，所述第二協作者、第三協作者……以及第N協作者可分別選用PC端、WEB端、IOS/安卓端進行協作。

在一些實施例中，所述第二協作者、第三協作者……以及第N協作者可選用相同的PC端、WEB端、IOS/安卓端進行協作。

在PC端上傳完office附件後，在移動端立即掃描二維碼就可以打開單據傳輸圖片。而不需要像原來先把圖片通過數據線傳輸到PC上，在上傳到單據中。

本實施例中的二維碼生成和解密方法，基於對應的文件編號ID+當前處理時間+GUID全局唯一標識符，並採用AES對稱加密算法，進行加密後作為所述文件二維碼。另外，可以在當所述第二協作者、第三協作者……以及第N協作者掃描所述文件二維碼時，通過反解密算法得到文件二維碼的文件編號ID和當前處理時間，從而實現信息獲取和權項校驗。

圖4是本發明中基於客戶端的操作流程示意圖，基於二維碼的文件協同處理的客戶端，所述客戶端被配置為：按照文件處理需求生成第一處理指令，根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至其它客戶端；通過掃描所述文件二維碼獲取編輯權限，根據所述編輯權限編輯符合上述文件處理需求的內容，並且分別上傳；同步獲得上述編輯過後的內容並提交。

作為本實施例中的優選，所述客戶端被封裝為基於WEB端的應用程式軟體。

作為本實施例中的優選，所述客戶端被封裝為PC端的應用程式軟體。

作為本實施例中的優選，所述客戶端被封裝為手機端的應用程式軟體。

所述客戶端按照文件處理需求生成第一處理指令包括但不限於：變更、作廢、審批。

所述客戶端可將所述文件二維碼分享至其它客戶端，或者直接掃一掃所述文件二維碼。

協作者通過所述客戶端掃描所述文件二維碼獲取編輯權限，所述編輯權限按照協作者的用戶分組確定，所述用戶分組為：甲方、乙方或者項目相關的第三方。

圖5是本發明中基於伺服器端的操作流程示意圖，基於二維碼的文件協同處理的伺服器端，所述伺服器端用以，接收第一協作者按照文件處理需求生成第一處理指令，根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至與其長連接的：第二協作者，第三協作者，……第N協作者，N為自然數，若所述第二協作者、第三協作者……以及第N協作者通過掃描所述文件二維碼獲取編輯權限，則接收根據所述編輯權限編輯符合上述文件處理需求的內容分別上傳的文件，以及，接收從所述第一協作者提交的同步獲得的編輯過後的內容。

在一些實施例中，伺服器端為本地伺服器以及資料庫。

在一些實施例中，伺服器端為雲端伺服器以及本地資料庫。

在一些實施例中，伺服器端包括：應用程式伺服器和本地資料庫。

在本實施例中的伺服器端，用以接收第一協作者按照文件處理需求，在接收到文件二維碼後發送至其他通過掃描二維碼獲得文件處理權項的第二協作者，第三協作者，……第N協作者，所述第二協作者，第三協作者，……第N協作者完成後同步至伺服器端，此時伺服器端再將所述第二協作者，第三協作者，……第N協作者分別變更的數據，由第一協作者確認並再次將完整的變更請求發送至伺服器端。

圖6是本發明的一實施例中的拓撲結構圖，STEP 1在工地現場需要發起一個變更申請，用戶A(比如，施工方項目經理)打開一個變更的新增界面，填寫變更單。所述變更單除了用戶A要錄入「變更內容」和「變更日期」外還有其他很多信息：

比如，這個施工項目的「合同照片」，在用戶B(比如，施工方的合同管理員)手中；另外還需要上傳「施工前後照片」，在用戶C(比如，施工方工程師)手機上；

STEP 2用戶A在界面上點擊生成二維碼按鈕，生成二維碼，將該二維碼圖片分享給需要協作的用戶B、用戶C、……或者更多需要協作參與的用戶。在所述STEP 2中，所有變更單都是基於合同的，用戶A在點擊「生成二維碼」按鈕時，會將該變更單對應的合同ID+當前時間+GUID用AES對稱加密算法進行加密後作為內容生成二維碼，

STEP 3用戶B、用戶C通過掃描二維碼進入同一個變更單，進行編輯。在所述STEP 3中當掃描二維碼時，通過反解密就能得到該二維碼的合同和生成時間，再校驗掃描二維碼的人是否具有該合同的權限，如果有權限，再根據二維碼生成時間校驗是否過期。最後還會校驗這個單據是否被用戶A(二維碼發起人)提交了，如果單據已經提交了，其他用戶也不能再編輯了。若上述的條件都滿足時，用戶B、C就可以錄入內容了。

STEP 4用戶A、用戶B、用戶C編輯的內容傳遞到伺服器端，再由伺服器端分發給其他用戶，這樣所有人可以同時編輯內容又能實時看到其他人編輯的內容

STEP 5最後由單據的發起人(用戶A)檢查完整後提交單據，只有單據的發起人才能最後提交表單，其他人只能填寫信息和查看別人填寫的信息。

圖7是本發明一實施例中的交互示意圖，包括：多個客戶端以及至少一個伺服器端，所述客戶端與伺服器端連接，

所述客戶端包括：第一客戶端、第二客戶端、第三客戶端……以及第N客戶端；

S1所述第一客戶端即客戶端A用以執行操作：協作者按照文件處理需求生成第一處理指令，

S2根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至客戶端B，包括但不限於：第二客戶端，第三客戶端，……第N客戶端，N為自然數，

S3其它協作者在所述第二客戶端、第三客戶端……以及第N客戶端通過掃描所述文件二維碼獲取編輯權限，

S4根據所述編輯權限編輯符合上述文件處理需求的內容，並且分別上傳；

S5在所述第一客戶端同步獲得上述編輯過後的內容並提交，

上述第一客戶端、第二客戶端、第三客戶端……第N客戶端分別與所述伺服器端通過長連接保持通信。

圖8是本發明另一實施例中的交互示意圖，包括：

客戶端A,S1按照文件處理需求生成第一處理指令，

客戶端B,S2根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至其它客戶端；

客戶端B,S3通過掃描所述文件二維碼獲取編輯權限，根據所述編輯權限編輯符合上述文件處理需求的內容，

客戶端B，S4並且分別上傳至伺服器端；

客戶端A，S5同步獲得上述編輯過後的內容並提交。

上述的客戶端A，客戶端B與所述伺服器端保持長連接。

採用本實施例中的客戶端，用戶體驗能夠得到大幅度提升，比如在PC端上傳完office附件後，在移動端立即掃描二維碼就可以打開單據傳輸圖片。而不需要像原來先把圖片通過數據線傳輸到PC上，在上傳到單據中。

圖9是本發明再一實施例中的交互示意圖，包括：伺服器端。

客戶端A，S1接收第一協作者通過客戶端A按照文件處理需求生成第一處理指令，根據所述第一處理指令生成文件二維碼，並將所述文件二維碼分享至與其長連接的伺服器端，

客戶端B,S2通過掃描所述文件二維碼獲取編輯權限，同步至伺服器端；

客戶端B,S3接收根據所述編輯權限編輯符合上述文件處理需求的內容分別上傳的文件，同步至伺服器端；

客戶端A,S4接收從所述第一協作者提交的同步獲得的編輯過後的內容,提交至伺服器端。

應當理解，本發明的各部分可以用硬體、軟體、固件或它們的組合來實現。在上述實施方式中，多個步驟或方法可以用存儲在存儲器中且由合適的指令執行系統執行的軟體或固件來實現。例如，如果用硬體來實現，和在另一實施方式中一樣，可用本領域公知的下列技術中的任一項或他們的組合來實現：具有用於對數據信號實現邏輯功能的邏輯門電路的離散邏輯電路，具有合適的組合邏輯門電路的專用集成電路，可編程門陣列(PGA)，現場可編程門陣列(FPGA)等。

在本說明書的描述中，參考術語「一個實施例」、「一些實施例」、「示例」、「具體示例」、或「一些示例」等的描述意指結合該實施例或示例描述的具體特徵、結構、材料或者特點包含於本發明的至少一個實施例或示例中。在本說明書中，對上述術語的示意性表述不一定指的是相同的實施例或示例。而且，描述的具體特徵、結構、材料或者特點可以在任何的一個或多個實施例或示例中以合適的方式結合。

總體而言，本公開的各種實施例可以以硬體或專用電路、軟體、邏輯或其任意組合實施。一些方面可以以硬體實施，而其它一些方面可以以固件或軟體實施，該固件或軟體可以由控制器、微處理器或其它計算設備執行。雖然本公開的各種方面被示出和描述為框圖、流程圖或使用其它一些繪圖表示，但是可以理解本文描述的框、設備、系統、技術或方法可以以非限制性的方式以硬體、軟體、固件、專用電路或邏輯、通用硬體或控制器或其它計算設備或其一些組合實施。

此外，雖然操作以特定順序描述，但是這不應被理解為要求這類操作以所示的順序執行或是以順序序列執行，或是要求所有所示的操作被執行以實現期望結果。在一些情形下，多任務或並行處理可以是有利的。類似地，雖然若干具體實現方式的細節在上面的討論中被包含，但是這些不應被解釋為對本公開的範圍的任何限制，而是特徵的描述僅是針對具體實施例。在分離的一些實施例中描述的某些特徵也可以在單個實施例中組合地執行。相反對，在單個實施例中描述的各種特徵也可以在多個實施例中分離地實施或是以任何合適的子組合的方式實施。