本發(fā)明是有關于一種云端服務應用的系統(tǒng)，特別是有關于一種使用物聯網連接架構的產品生產履歷管理系統(tǒng)。

背景技術：

隨著科技之快速發(fā)展與經濟之結構巨變，傳統(tǒng)「企業(yè)對企業(yè)」之競爭形態(tài)已演變?yōu)椤腹湆湣沟母偁幘置?。提升供應鏈信息整合功能，以改善物流效率及降低物流成本，是現今企業(yè)創(chuàng)造競爭力的重要課題。隨著「無線射頻識別」(Radio Frequency Identification，RFID)技術的進步，RFID已逐漸被采用于供應鏈活動與流程改造。

使用物聯網的管理系統(tǒng)，有助于提高產業(yè)競爭力的兩種特性因子分別為效率性與完整性。首先，就效率性而言，不只是在一定時間內把產品送至客戶手中而已，還要加上在同時間內把不同的產品送至不同的客戶手中的整合性配送方式。其次，就完整性而言，不只有提供產品的實體完整性，還要提供產品內容信息，包括產品的生產履歷、產品是否為真品等。廠商為了提升這兩種特性，必須要取得產品本身的實時信息，因此藉由物聯網結合感測組件(例如:RFID、電子卷標)技術配合云端監(jiān)控系統(tǒng)，即可協(xié)助消費者、企業(yè)與其伙伴(經銷商)，能夠在第一時間提供產品的實時信息。

藉由配置在產品上的感測組件與云端監(jiān)控系統(tǒng)所提供的實時信息，可提高顧客對于產品的完整性的滿意度。產品的完整性不單只有實體產品的完整性，其產品內容的信息的提供，也是產品完整性的考慮方面。而且針產品從原物料取得、產品制造過程至產品出廠出之后，一直到顧客的手中，在這個過程中，可以透過物聯網對產品實時信息的掌控，實時提供消費者對所要購買的產品信息，可以對所要購買的產品質量或是真?zhèn)巫鬟M一步的評估。

能夠形成上述這些應用，是因為物聯網(Internet of Things；IOT)連接架構的建立。物聯網是藉由一個高度整合的云端網絡，將每個人與周遭的事物 全部連接在一個網絡內；例如:制造者、消費者、機器、生產原料、產品生產過程、物流管理、產品銷售狀況、消費習慣等，所有從產品制造到產品銷售，進而到根據這些產品銷售狀況的大數據(big data)，推斷或預估出消費者的消費習慣等，都可以通過配置在產品上的感測組件(例如:RFID、電子卷標)與軟件程序連接到物聯網平臺。同樣的，物聯網在效率和安全是最重要的二個關鍵條件，然而，效率和安全卻是兩個互相抵觸的指標。因此，如何兼顧效率和安全是物流管理系統(tǒng)能否成功應用的關鍵。

技術實現要素：

為了將上述的需求實際運用在企業(yè)運營上，本發(fā)明之一主要目的在于提供一種物聯網的產品生產履歷管理系統(tǒng)，包括:客戶端裝置，為具有無線通信功能的裝置，藉由特定用戶標識符確認該客戶端裝置為物聯網中的其中之一的客戶端裝置；云端裝置，具有與客戶端通信之功能，用以確認該客戶端裝置為物聯網中的其中之一的客戶端裝置；第一代理伺服裝置，具有第一網址及第一密碼，并能與云端裝置通信；第二代理伺服裝置，具有第二網址及第二密碼，并能與客戶端裝置通信；其中，于特定用戶標識符確認客戶端裝置為物聯網中的其中之一的客戶端裝置后，客戶端裝置將所要查詢的產品數據只能經由第一網址及第一密碼與第一代理伺服裝置通信，再由第一代理伺服裝置與云端裝置通信，以便在云端裝置將客戶端裝置所要查詢的產品數據與產品生產履歷數據庫進行比對后，云端裝置并將產品生產履歷數據庫中的訊息只能經由第二網址及第二密碼與第二代理伺服裝置通信，以便由第二代理伺服裝置將產品生產履歷數據庫中的訊息傳送至客戶端裝置。

經由本發(fā)明使用代理伺服裝置所建立的物聯網架構，除了可以提高物聯網產品生產履歷的管理系統(tǒng)的速度及降低運營的成本外；特別是在當有黑客在訊息傳遞過程進行竄改、盜用或否認等行為時，都可藉由本發(fā)明的安全認證來防止密碼遭竄改或盜用，故可以確保產品生產履歷的管理系統(tǒng)的安全 性。

本發(fā)明之另一主要目的在于提供一種物聯網的產品生產履歷管理系統(tǒng)，包括:多個客戶端裝置，每一個客戶端裝置均為具有無線或有線通信功能的裝置，且每一個客戶端裝置均具有一個特定的用戶標識符；云端裝置，具有與客戶端裝置通信之功能，藉由特定用戶標識符確認每一個客戶端裝置均為物聯網中的其中之一的客戶端裝置，且云端裝置中已建立至少一個產品生產履歷數據庫；多個第一代理伺服裝置，每一個第一代理伺服裝置具有一個網址及密碼，并能與云端裝置通信；多個第二代理伺服裝置，每一個第二代理伺服裝置具有第二網址及第二密碼，并能與客戶端裝置通信；其中，于每一個特定用戶標識符確認客戶端裝置為物聯網中的其中之一的客戶端裝置后，每一個客戶端裝置將所要查詢的產品數據只能經由每一個第一網址及第一密碼與配對后的每一個第一代理伺服裝置通信，再由每一個第一代理伺服裝置與云端裝置通信，以便在云端裝置將客戶端裝置所要查詢的每一個產品數據與每一產品生產履歷數據庫進行比對后，云端裝置并將每一個產品生產履歷數據庫中的訊息只能經由每一個第二網址及第二密碼與配對后的每一個第二代理伺服裝置通信，以便由每一個第二代理伺服裝置將每一個產品生產履歷數據庫中的訊息傳送至每一個客戶端裝置。

經由本發(fā)明使用代理伺服裝置所建立的物聯網架構，除了可以提高物聯網產品生產履歷的管理系統(tǒng)的速度及降低運營的成本外；特別是在當有黑客在訊息傳遞過程進行竄改、盜用或否認等行為時，都可藉由本發(fā)明的安全認證來防止密碼遭竄改或盜用，故可以確保產品生產履歷的管理系統(tǒng)的安全性。

附圖說明

圖1A是物聯網連接架構示意圖；

圖1B，是物聯網連接架構另一實施例的示意圖；

圖2，是使用物聯網架構建立生產履歷與產品生產履歷管理系統(tǒng)的示意 圖；

圖3A，是本發(fā)明產品生產履歷的文字內容示意圖；

圖3B，是本發(fā)明產品生產履歷的文字與圖案內容示意圖；

圖3C，是本發(fā)明產品生產履歷的產品保固數據內容示意圖；

圖4，是本發(fā)明使用物聯網建立生產履歷及查詢生產履歷的流程圖；以及

圖5，是本發(fā)明使用物聯網建立生產履歷及查詢生產履歷的另一實施例流程圖。

具體實施方式

為使本發(fā)明之目的、技術特征及優(yōu)點，能更為相關技術領域人員所了解并得以實施本發(fā)明，在此配合所附圖式，于后續(xù)之說明書闡明本發(fā)明之技術特征與實施方式，并列舉較佳實施例進一步說明，然以下實施例說明并非用以限定本發(fā)明，且以下文中所對照之圖式，系表達與本發(fā)明特征有關之示意。

首先，請參考圖1A，是本發(fā)明的物聯網連接架構示意圖。如圖1A所示，物聯網連接架構是由客戶端裝置(client device)100、云端裝置(cloud device)500及至少一個代理裝置(broker device)700所組成；其中，客戶端裝置100為一種具有無線通信功能且具有特定用戶標識符的裝置；云端裝置500，具有與客戶端100通信之功能，藉由客戶端100的特定用戶標識符確認客戶端裝置100為該物聯網中的其中之一的客戶端裝置100；以及代理伺服裝置700，具有其網址及密碼，并能與云端裝置500通信。

在本發(fā)明的物聯網連接架構中，客戶端裝置100可以是一種隨時變動的浮動IP地址(Internet Protocol Address),也可以是一種固定IP的無線通信功能的裝置(例如:個人計算機、筆記本計算機、智能型手機、智能型便攜設備、智能型讀取裝置等)，并且每一個客戶端裝置100都具有獨特性的標識符(例如:制造廠商于出廠時所設定的編碼；又例如:MAC Address等硬件數據)，以便用來產生客戶端裝置100的通用唯一標識符(Universally Unique Identifier；縮寫為uuid)，用以辨識或防止黑客侵入。此外，在本發(fā)明的物聯網連接架構中，云端裝置500是一種固定式域名系統(tǒng)(Domain Name System；縮寫為DNS)，其具有服務器(sever)之功能并且具有與每一個客戶端裝置100進行無 線通信之功能，同時云端裝置500至少是由接收/發(fā)射接口模塊、數據處理模塊及內存模塊等裝置所組成；因此，云端裝置500已經記錄著所有屬于本發(fā)明物聯網中的所有客戶端的uuid并已儲存在內存模塊530中，形成數據庫。再者，代理伺服裝置700是一種可隨時變動的浮動IP，其最主要的工作是將確認是為物聯網中的客戶端裝置100所傳送的編碼數據串在接收后，直接傳送出至云端裝置500；特別要說明的是，代理伺服裝置700在收到客戶端裝置所傳送的數據串后，不做任何處理，而是直接將接收到的資料串直接傳送出去，在云端裝置500收到代理伺服裝置700的數據串后，再經過解碼后，才會對客戶端裝置100所傳送的數據串進行處理。很明顯的，在本發(fā)明的物聯網連接架構中，在整個客戶端裝置100將數據串遞給云端裝置500的過程中，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率，可以大幅度的提高物聯網的安全性。

而在本發(fā)明的物聯網連接架構的較佳實施例中，可以將多個客戶端裝置100分為多個群組，每一個群組分別對應或配對至一個代理伺服裝置700，故在本發(fā)明的物聯網連接架構中，可以有多個代理伺服裝置700，如圖1B所示。當云端裝置500判斷其中一個代理伺服裝置700遭受黑客攻擊后，可以選擇將被攻擊的代理伺服裝置700關閉，或再重新建立一個新的代理伺服裝置700的網址及密碼，可以更確保本發(fā)明物聯網的安全性。此外，在本發(fā)明的實施例中，代理伺服裝置700是選擇使用MQTT(Message Queuing Telemetry Transport)的通信標準(protocol)來做數據串的傳送。由于MQTT是為了物聯網而設計的協(xié)議，特別是基于發(fā)布/訂閱模式的輕量級消息傳輸協(xié)議，其為IBM的Andy Stanford-Clark博士及Arcom公司的Arlen Nipper博士于1999年發(fā)明；最初是為大量計算能力有限且工作在低帶寬、不可靠的網絡的遠程傳感器和控制設備之間的通訊而設計的協(xié)議。因此，MQTT具有傳輸資料小且輕巧的優(yōu)點，可以在帶寬及速度上都有極大優(yōu)勢；也由于其所需要的網絡帶寬是很低的，因而使得其所需要的硬件資源也是低的，故可以將物聯網系統(tǒng)或是使用此物聯網架構的各種商業(yè)運營系統(tǒng)(例如物流管理或是產品的生產履歷的建立與查詢或是產品真?zhèn)味鹊谋孀R等)之效率性提升；也因此可以有效地降低商業(yè)運營的成本。

接著，詳細說明本發(fā)明的物聯網實際完成連接的過程及其方法。

請繼續(xù)參考圖1A，首先，由客戶端裝置100向云端裝置500進行登錄(如圖1A中的S1標示的通信方向)，例如:客戶端裝置100通過https向云端裝置500登錄，以便啟動物聯網系統(tǒng)。接著，當云端裝置500收到客戶端裝置100的請求后(如圖1A中的S2標示的通信方向)，云端裝置500會先驗證客戶端裝置100所使用的硬件uuid(如MAC Address)是否已經儲存在云端裝置500的數據庫中；若確認客戶端裝置100所使用的硬件uuid(如MAC Address)Address已經儲存在云端裝置500的數據庫時，則產生一個客戶辯證碼(client uuid)；接著，云端裝置500產生一對專屬客戶使用的密鑰；在本發(fā)明的較佳實施例中，此密鑰是使用RSM非對稱式密鑰(Asymmetric Key)；故可以產生出一對client_pub_key及client_pri_key；其中，RSM非對稱式密鑰具有解碼時間長，所以安全性高。此外，在另一個較佳實施例中，云端裝置500還可以選擇性的產生一個客戶端裝置100專屬的對稱式密鑰(Symmetric Key)client_share_key。故在本發(fā)明的較佳實施例中，可以選擇性的將RSM非對稱式密鑰及對稱式密鑰配合使用；由于，對稱式密鑰具有譯碼時間短，相對地安全性較低，因此需要隨時變動client_share_key，以確保安全性；為此，云端裝置500還會進一步產生/設定一個變動的時間(share_key_expiry date time)，藉由不定時的更改share_key_expiry date time來提升安全性；故當云端裝置500偵測到隨時變動的client_share_key已經超過了share_key_expiry date time設定變動的時間后，即會自動產生新的client_share_key，以確保安全性。當云端裝置500在確認一個客戶端裝置100的硬件uuid(如MAC Address)數據與儲存在數據庫中相同時，則判斷此客戶端裝置100為本物聯網中的客戶端，之后，云端裝置500會將所產生的uuid及密鑰等訊息回傳至客戶端裝置100(如圖1A中的S3標示的標通信方向)，這些回傳至客戶端裝置100的訊息包括:client_uuid、sever_pub_key(此sever_pub_key即是client_pub_key；因為所有客戶端裝置100都會使用同一個pub_key，所以又可稱為sever_pub_key)及client_pri_key。

另外，若當云端裝置500收到客戶端裝置100的請求后，云端裝置500比對出客戶端裝置100所使用的硬件uuid(如MAC Address)并不在云端裝 置500的數據庫中時，及判斷此客戶端裝置100所使用的硬件uuid(如MAC Address)并非本物聯網中的客戶端裝置，則將此硬件uuid(如MAC Address)訊息儲存在另一個數據庫中，以便后續(xù)比對。特別要說明，S3通信方向的回傳機制，一般而言，是不會有錯誤的，但是還是有發(fā)生錯誤的機制；例如，等待Server反映時間過久導致此次聯機失敗，則會再由客戶端裝置100重新執(zhí)行一次，但是此時的云端裝置500會判定此次的硬件uuid(如MAC Address)已經在數據庫中被記錄，因而還是會將此硬件uuid(如MAC Address)對應的uuid回傳，此時，云端裝置500所產生并回傳給客戶端裝置100的一對密鑰會更新。因此，即便有假的裝置使用任何方法仿冒此客戶端裝置100的硬件uuid(如MAC Address)也無法取得相同密鑰。換句話說，只會有一個確定的uuid能存活在系統(tǒng)中。

接著，如圖1A中的S4標示的通信方向，當客戶端裝置100以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)通過https“要求”取得client_share_key、share_key_expiry date time、MQTT_Broker IP及MQTT_Broker賬號及密碼(username/password)；而當云端裝置500收到轉成亂碼的client_uuid后，即會根據sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將client_share_key、share_key_expiry date time、MQTT_Broker IP及MQTT_Broker賬號及密碼等以client_pub_key編碼后回傳至客戶端裝置100(如圖1A中的S5標示的通信方向)。

此外，在本發(fā)明的一個較佳實施例中，MQTT_Broker的IP、賬號及密碼可以選擇分兩次取得；例如，第一次(如圖1A中的S4標示的通信方向)，客戶端裝置100以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)通過https“要求”取得client_share_key、share_key_expiry date time及MQTT_Broker IP；而當云端裝置500收到轉成亂碼的client_uuid后，即會根據sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將client_share_key、share_key_expiry date time及MQTT_Broker IP等以client_pub_key編碼后回傳至客戶端裝置100(如圖1A中的S5標示的通信方向)。第二次(如圖1A中的S6標示的通信 方向)，客戶端裝置100再以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)，通過https“要求”取得MQTT_Broker賬號及密碼；而當云端裝置500收到轉成亂碼的client_uuid后，即會根據sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將MQTT_Broker賬號及密碼等以client_pub_key編碼后回傳至客戶端裝置100(如圖1A中的S7標示的通信方向)。特別要說明的，第一次及第二次所要取得的內容中，只要求將MQTT_Broker的IP、賬號及密碼分兩次取得，其他并不加以限制。

很明顯地，在客戶端裝置100與云端裝置500進行辨識與確認的過程中，所使用的https是屬于混合型密碼防駭、安全通訊協(xié)議(Secure Sockets Layer；SSL)或傳輸層安全協(xié)議(Transport Layer Security；TLS)，其本身屬于公認的安全協(xié)議，且云端裝置500端所需要有的公認憑證，可以由客戶端裝置100端藉由認證中心的數字簽名來確認訊息是否由云端裝置500直接傳出；因此，當有黑客在訊息傳遞過程進行竄改、盜用或否認等行為時，都可藉由這些安全認證來防止密碼遭竄改或盜用。

接著，如圖1A中的S8標示的通信方向，當客戶端裝置100自云端裝置500取得相關數據后，客戶端裝置100隨即會與代理伺服裝置700進行連接；但在進行與連接代理伺服裝置700前，必須確認所收到的訊息必須完整，此完整的訊息包括:1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/password；5.client_Share_key；6.Share_key_expiry date time。當客戶端裝置100在確認收到完整的訊息后，會使用client_share_key將client_uuid及客戶端裝置100所要傳給云端的數據內容(data involved)進行編碼后，再上傳至代理伺服裝置700(即MQTT Broker)。

在本發(fā)明的較佳實施例中，客戶端裝置100會進一步檢查Share_key_expiry date time的時效是否已經到期(例如:到期日為2015/0501)；如果已經過了Share_key_expiry date time的時效時(例如:檢查期日的結果為2015/0502)，則客戶端裝置100會重新以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)，通過https要求取得新的share_key_expiry date time訊息；而當云端裝置500收到轉成亂碼的client_uuid后，即會根據 sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將新的share_key_expiry date time以client_pub_key編碼后回傳至客戶端裝置100。此外，為增加安全性，share_key-_expiry date time所設定的時間可以是周期性的，也可以是隨機變量的，可以由云端裝置500決定。

當客戶端裝置100在確認已收到完整的訊息后，此時客戶端裝置100已經知道代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼，故客戶端裝置100可以將編碼的client_uuid及數據串(例如:產品的生產履歷等)上傳至代理伺服裝置700(如圖1A中的S8標示的通信方向)；接著，代理伺服裝置700在收到客戶端裝置100所上傳的編碼client_uuid及數據串(例如:產品的生產履歷等)后，隨即將客戶端裝置100所上傳的訊息直接(也就是說，不做任何處理)傳送給云端裝置500端；很明顯地，整個物聯網在客戶端裝置100將其訊息串遞給云端裝置500的過程中，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率。由于代理伺服裝置700只是將客戶端裝置100上傳的數據直接傳送給云端裝置500，故可以降低代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。

接著，如圖1A中的S9標示的通信方向，云端裝置500在接收到代理伺服裝置700所直接傳送的數據(即經過編碼后的client_uuid及數據串)后，隨即使用client_share_key進行譯碼(Decode)，并且會驗證所收到的client_uuid及數據串(例如:產品的生產履歷等)是否完整及正確；如果正確時，則再儲存至內存模塊530中，等待用戶將這些收到的數據串(例如:產品的生產履歷等)進行特定的應用；例如:建立至少一個產品的生產履歷數據庫；若驗證所收到的client_uuid及數據串不完整或不正確時，則進行記錄。要說明的是，要驗證出不正確的訊息的目的，是可以由物聯網系統(tǒng)借著人工智能作深度學習或人為增加、更改或修正的驗證機制，來防止或降低被駭成功的機率。在本實施例中，不正確的訊息包括，例如:(1)由網絡爬蟲抓取新聞發(fā)現當下某些商品的偽品猖獗；又亦或是(2)程序一開始便設定的同一個client_uuid，竟然在同一時間出現在兩個完全不同的地方，此時物聯網系統(tǒng)會通知公司稽查人員 或提出警告，而稽查人員可做出的處置方式至少有觀察或忽略等動作，達到事先預警及防駭的功效；又亦或是(3)裝置500本身持續(xù)受到某特定代理伺服裝置700傳送可疑信息時，例如:不明的client_uuid信息時；當不正確的訊息持續(xù)出現時，則判斷代理伺服裝置700可能被黑客攻擊，則云端裝置500可以選擇關閉此代理伺服裝置700(如圖1A中的S10標示的通信方向)。

在本發(fā)明的實施例中，client_share_key編碼方式可以配合哈希函數來防止竄改，其中哈希函數可以選擇MD5、SHA-1或SHA-256等。同時，client_share_key也可以配合不同的譯碼(decode)方式，例如:區(qū)塊密碼、串流密碼、ECB模式或是前述的混合方法等，除了可以更有效的提高破解難度外，還可以不損失解碼時間。

請參考圖1B，是本發(fā)明的物聯網連接架構另一實施例的示意圖。如圖1B所示，物聯網連接架構是由復數個客戶端裝置100所組成、云端裝置500及至少一個代理裝置700所組成；其中，每一個客戶端裝置100均為具有無線通信功能且具有特定用戶標識符的裝置；云端裝置500，具有與每一個客戶端100通信之功能，藉由每一個客戶端100各自獨有的特定用戶標識符來確認客戶端裝置100為物聯網中的其中之一的客戶端裝置100；代理伺服裝置700，具有其網址及密碼，并能與云端裝置500通信。由于圖1B的實施例與圖1A的實施例在基本連接的架構是相同的，而兩者之間的差異僅在于云端裝置500提供每一個代理伺服裝置的網址、賬號及密碼予至少一個物聯網中的客戶端裝置100并形成配對后，這些被配對后的客戶端裝置100只能與配對的代理伺服裝置700通信，并再由代理伺服裝置700與云端裝置500通信，以便將每一個客戶端裝置100上的數據串傳至云端裝置500中。故圖1B的物聯網實際完成連接的過程簡要說明如下。

請繼續(xù)參考圖1B，首先，每一個客戶端裝置100各自過https向云端裝置500進行登錄。接著，當云端裝置500分別收到每一個客戶端裝置100的請求后，云端裝置500會先驗證每一個客戶端裝置100所使用的硬件uuid(如MAC Address)是否已經儲存在云端裝置500的數據庫中；若確認每一個客戶端裝置100所使用的硬件uuid(如MAC Address)都已經儲存在云端裝置500的數據庫時，則分別產生每一個客戶各自的辯證碼(client uuid)；接著， 云端裝置500根據每一個客戶端裝置100產生一對專屬客戶使用的密鑰；當云端裝置500判斷每一個客戶端裝置100均為本物聯網中的客戶端之后，云端裝置500會將所產生的每一個uuid及密鑰等訊息回傳至相應的每一個客戶端裝置100中，這些回傳至每一個客戶端裝置100的訊息包括:client_uuid、sever_pub_key及client_pri_key。

接著，每一個客戶端裝置100可以將其編碼后的client_uuid通過https“要求”取得client_share_key、share_key_expiry date time、MQTT_Broker IP及MQTT_Broker賬號及密碼(username/password)；而當云端裝置500收到轉成亂碼的client_uuid后，即會根據各自的sever_pri_key進行譯碼，以確認每一個收到的client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將client_share_key、share_key_expiry date time、MQTT_Broker IP及MQTT_Broker賬號及密碼等以client_pub_key編碼后回傳至客戶端裝置100。例如:將代理裝置(Broker-1)的IP、賬號及密碼回傳給Client-1～Client-5；將代理裝置(Broker-2)的IP、賬號及密碼回傳給Client-6～Client-15；將代理裝置(Broker-3)的IP、賬號及密碼回傳給Client-16～Client-50；很明顯的，本物聯網已經將50個各別的客戶端裝置100分別配對由3個代理伺服裝置700來與云端裝置500通信。接著，當每一個客戶端裝置100各自透過云端裝置500取得相關數據后，客戶端裝置100隨即會與其所獲得的配對的代理伺服裝置700進行連接；同時，當每一個客戶端裝置100確認其由云端裝置500所收到的訊息已包括:1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/password；5.Client_Share_key；6.Share_key_expiry date time后，會使用client_share_key將client_uuid及此客戶端裝置100所要傳給云端的數據內容進行編碼后，再上傳至代理伺服裝置700(即MQTT Broker)。

由于，當每一個客戶端裝置100在確認已收到完整的訊息后，此時客戶端裝置100已經知道其所配對的代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼，故客戶端裝置100可以將編碼client_uuid及訊息串(例如:產品的生產履歷等)上傳至配對的代理伺服裝置700；接著，每一個代理伺服裝置700在收到配對的客戶端裝置100所上傳的編碼client_uuid 及訊息串(例如:產品的生產履歷等)后，隨即將客戶端裝置100所上傳的訊息直接(也就是說，不做任何處理)傳送給云端裝置500端；很明顯地，整個物聯網在客戶端裝置100將其訊息串遞給云端裝置500的過程中，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率。由于每一個代理伺服裝置700只是將客戶端裝置100上傳的數據直接傳送給云端裝置500，故可以降低代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。接著，云端裝置500在接收到每一個代理伺服裝置700所直接傳送的數據(即經過編碼后的client_uuid及數據串)后，隨即使用每一個client_share_key進行譯碼，并且會驗證所收到的client_uuid及數據串(例如:產品的生產履歷等)是否完整及正確；如果正確時，則再儲存至內存模塊530中，等待用戶將這些收到的數據串進行特定的應用；例如:建立至少一個產品的生產履歷數據庫；若驗證所收到的client_uuid及數據串不完整或不正確時，則進行記錄；在本實施例中，不正確訊息的產生可能包括:每一個client發(fā)布信息頻率有一定的規(guī)律性，如若產生某client以不正?；蜻^多頻率來發(fā)布的信息，則視為不正確的訊息；或代理伺服裝置700本身頻率發(fā)布信息非經MQTT方式，而試圖連接云端裝置500等；當不正確的訊息持續(xù)出現時，則判斷代理伺服裝置700可能被黑客攻擊；則云端裝置500可以選擇關閉此代理伺服裝置700。

綜合上述，本發(fā)明之物聯網連接架構的主要技術手段，是在云端裝置500確認每一個客戶端裝置100均為本物聯網的用戶后，云端裝置500會將代理伺服裝置700的MQTT_Broker IP、MQTT_Broker賬號及密碼回傳給每一個客戶端裝置100，之后，每一個客戶端裝置100根據所收到的MQTT_Broker IP、MQTT_Broker賬號及密碼與代理伺服裝置700連接，并且將每一個客戶端裝置100所要傳送的數據串(例如:產品的生產履歷等)編碼后，一起上傳至代理伺服裝置700；接著，代理伺服裝置700在不對客戶端裝置100傳送的數據串(例如:產品的生產履歷等)進行處理的狀況下，直接將客戶端裝置100傳送的數據串傳遞至云端裝置500進行譯碼及處理。很明顯的，本發(fā)明的物聯網連接架構分為兩個階段進行連接，并且在第一階段完成客戶端裝置 100的辨識后，客戶端裝置100在第二階段中，只能與代理伺服裝置700連接；由于第一階段是在客戶端裝置100進行連接之前就已完成，故當客戶端裝置100正是傳遞數據串時，均只能與代理伺服裝置700連接及通信；因此，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率，可以有效的提高物聯網連接架構的安全性。

再接著，進一步說明本發(fā)明使用物聯網架構建立產品生產履歷與產品生產履歷管理系統(tǒng)的實施方式。

請參考圖2，本發(fā)明之使用物聯網架構建立生產履歷與產品生產履歷管理系統(tǒng)的實施例示意圖。如圖2所示，客戶端裝置100可以是制造商端的讀寫裝置，可以將產品的從每一個制造步驟一直到運送到賣場的整個生產及運送歷程，以時間軸作為產品生產履歷內容的要項記錄之后，在完成圖1A或圖1B中的S1-S7的確認后(即已經確認每一個客戶端裝置100均為物聯網中的其中一個客戶端裝置，并且每一個客戶端裝置100已經取得所要連接的代理伺服裝置700的網址及密碼)，客戶端裝置100即可以將生產歷程的內容數據經過編碼后，傳遞至代理伺服裝置700，而代理伺服裝置700在收到這些訊息后，代理伺服裝置700在不對客戶端裝置100傳送的數據串(例如:產品的生產履歷等)進行處理的狀況下，直接將客戶端裝置100傳送的數據串傳遞至云端裝置500進行譯碼及處理，以便在云端裝置500的內存模塊530中建立一個生產履歷數據庫，此生產履歷數據庫可以記載每一個產品從每一個制造步驟一直到運送到賣場的整個生產歷程；由于客戶端裝置100在傳遞生產履歷的數據至云端裝置500時，均只能與配對的代理伺服裝置700連接及通信；因此，在整個生產履歷數據庫建立的過程中，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率，可以有效的提高物聯網建立生產履歷數據庫的安全性。

接著，說明本發(fā)明之物聯網產品生產履歷的管理系統(tǒng)的實施方式。請再參考圖2，當物聯網已在云端裝置500的內存模塊530中建立了生產履歷數據庫后，云端裝置500可以根據用戶的要求(此使用者已經過確認為登錄的使用者，例如:智能型手機)，將其所要查詢產品的生產履歷、生產履歷數據的類型(即選擇文字、圖片、語音或是影片等)或是保固數據，透過S11標示的 通信方向，由另一個代理伺服裝置700’傳遞至用戶的通訊裝置100上顯示。由于云端裝置500可以設定代理伺服裝置700’的IP、賬號及密碼，故當云端裝置500要將產品的生產履歷或是保固數據傳遞給用戶時，同樣的，其均只能經過代理伺服裝置700’的IP、賬號及密碼與代理伺服裝置700’連接及通信；因此，在云端裝置500將用戶所要查詢的產品的生產履歷或是保固數據等訊息傳送到用戶的智能型手機上的整個過程中，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率，可以有效的提高物聯網生產履歷數據庫的安全性。

很明顯的，本發(fā)明的物聯網產品生產履歷的管理系統(tǒng)在特定用戶標識符確認客戶端裝置100為物聯網中的其中之一的客戶端裝置后，客戶端裝置100將所要查詢的產品數據只能經由代理伺服裝置700’的網址及密碼與代理伺服裝置700’通信，再由代理伺服裝置700’直接與云端裝置500通信，以便在云端裝置500將客戶端裝置100所要查詢的產品數據與產品生產履歷數據庫進行比對后，云端裝置500并將產品生產履歷數據庫中的訊息只能經由另一代理伺服裝置700’的網址及密碼與代理伺服裝置700’通信，以便由代理伺服裝置700’將產品生產履歷數據庫中的訊息傳送至客戶端裝置100。

而在本發(fā)明的較佳實施例中，還可以進一步在以時間軸作為產品生產履歷內容的要項記錄中，建立詳細的內容型態(tài)記錄，此詳細的內容型態(tài)可以使用如圖3A所示的文字，或是如圖3B所示的文字與圖片，或是語音或是影像等，建立在云端裝置500的生產履歷數據庫中。此外，也可以建立一個產品保固數據所形成的數據庫，其中，產品保固數據至少包括產品的貨品編號、產品的上架日期、產品出廠日期、產地、產品制造商及制造商地址及產品材質等數據，圖3C所示。

再接著，詳細說明本發(fā)明的物聯網連接架構的生產履歷建立及查詢的連接方法及過程，透過本物聯網連接架構的連接方法及過程，可以更清楚的了解本發(fā)明使用代理伺服裝置700之創(chuàng)新點。

請參考圖4，是本發(fā)明的使用物聯網建立產品生產履歷及產品生產履歷管理方法的流程圖。如圖4所示，本發(fā)明的使用物聯網建立產品生產履歷及產品生產履歷管理方法包括:

步驟1:由客戶端裝置100向云端裝置500進行登錄，例如:客戶端裝置100通過https向云端裝置500登錄，以便啟動物聯網系統(tǒng)。

步驟2:當云端裝置500收到客戶端裝置100的請求后，云端裝置500會先驗證客戶端裝置100所使用的硬件uuid(如MAC Address)是否已經儲存在云端裝置500的數據庫中。

步驟3:當云端裝置500確認客戶端裝置100所使用的硬件uuid(如MAC Address)已經儲存在云端裝置500的數據庫時，則判斷客戶端裝置100數據正確，其為本物聯網中的客戶端裝置100，則云端裝置500會產生一個客戶辯證碼(client uuid)、一對專屬客戶使用的密鑰。在本實施例中，此密鑰是使用安全性高的RSM非對稱式密鑰(Asymmetric Key)；故可以產生出一對client_pub_key及client_pri_key；并且將其所產生的uuid及密鑰等訊息回傳客戶端裝置100，這些回傳客戶端裝置100的訊息包括:client_uuid、sever_pub_key(此sever_pub_key即是client_pub_key。此外，若當云端裝置500收到客戶端裝置100的請求后，云端裝置500比對出客戶端裝置100所使用的硬件uuid(如MAC Address)并不在云端裝置500的數據庫中時，及判斷此客戶端裝置100所使用的硬件uuid(如MAC Address)并非本物聯網中的客戶端裝置，則將此一硬件uuid(如MAC Address)訊息儲存在另一數據庫中，以便后續(xù)比對。

步驟4:客戶端裝置100判斷云端裝置500所產生的uuid及密鑰等訊息是否以正確收到；當客戶端裝置100確認已經正確地收到uuid及密鑰等訊息后，客戶端裝置100隨即會以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)通過https向云端裝置500要求取得client_share_key、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼(username/password)。

步驟5:當云端裝置500收到轉成亂碼的client_uuid后，即會根據sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將client_share_key、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼等以client_pub_key編碼后回傳至客戶端裝置100。

步驟6:當客戶端裝置100自云端裝置500取得相關數據后，客戶端裝置100隨即會使用client_pri_key進行譯碼，并確認所收到的訊息必須完整，此完整的訊息包括:1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/password；5.client_Share_key。當客戶端裝置100在確認收到完整的訊息后，即會與代理伺服裝置700進行連接；若客戶端裝置100判斷所收到的訊息不完整時，會回到步驟4，重新要求向云端裝置500要求取得client_share_key、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼(username/password)。

步驟7:客戶端裝置100使用MQTT_Broker IP及MQTT_Broker賬號及密碼連接代理伺服裝置700；同時，也使用client_share_key將client_uuid及客戶端裝置100所要傳給云端裝置500的數據內容(例如:產品的生產履歷等)進行編碼后，再上傳至代理伺服裝置700。

步驟8:代理伺服裝置700在收到客戶端裝置100所上傳的編碼client_uuid及訊息串(例如:產品的生產履歷等)后，隨即將客戶端裝置100所上傳的訊息直接(也就是說，不做任何處理)傳送給云端裝置500端。

步驟9:云端裝置500在接收到代理伺服裝置700所直接傳送的數據后，隨即使用client_share_key進行譯碼，并且會驗證所收到的client_uuid及數據串(例如:產品的生產履歷等)是否完整及正確。

步驟10:云端裝置500判斷所收到的client_uuid及數據串完整及正確時，則將譯碼后的客戶端數據串(例如:產品的生產履歷等)儲存至內存模塊530中，等待用戶將這些收到的數據串進行特定的應用，例如，在云端裝置500中完成了產品的生產履歷數據庫的建立；若驗證所收到的client_uuid及數據串不完整或不正確時，則進行記錄；在本實施例中，不正確的訊息包括(1)某ip對應到的client_uuid不正確，則可能有盜用問題(2)若某client_uuid有配合上Geo Location的數據上傳，可以藉由驗證GeoLocation的合理性來驗證(是否某個client_uuid這一分鐘在亞洲，下一分鐘在北美)；當不正確的訊息持續(xù)出現時，則判斷代理伺服裝置700可能被黑客攻擊；則云端裝置500可以選擇關閉此代理伺服裝置700。

很明顯地，在整個物聯網架構的連接方法過程中，從步驟1至步驟6都 是在每一個客戶端裝置100出廠前就與云端裝置500完成連接，即每一個客戶端裝置100出廠后，就已經自云端裝置500獲得完整的訊息包括:1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/password；5.client_Share_key。當物聯網系統(tǒng)啟動后，每一個客戶端裝置100所要傳送給云端裝置500處理的數據串，都會根據MQTT_Broker IP傳送至代理伺服裝置700，再由代理伺服裝置700直接將客戶端裝置100數據串傳送給云端裝置500。故自步驟7至步驟10之間的訊息傳遞過程中(即產品生產履歷數據庫的建立過程中)，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率。由于代理伺服裝置700只是將客戶端裝置100上傳的數據直接傳送給云端裝置500，故可以降低代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。

接著，當一位消費者使用智能型手機在網絡上看到某一產品，并且想要購買此產品時，消費者可以透過網絡上所標示的產品編號(貨號)或是QR Code等，查看此產品的生產履歷或是保固數據，其查詢過程說明如下。

首先，消費者可以先建立其所使用的智能型手機與本發(fā)明的物聯網完成身分辨識的程序；例如下載本發(fā)明物聯網的APP軟件，經由圖4的步驟1至步驟6的過程，讓消費者使用智能型手機已在本發(fā)明的物聯網完成身分辨識的程序，即消費者使用智能型手機的硬件uuid(如MAC Address)已經儲存在云端裝置500的數據庫中；接著，當消費者可以透過其所使用的智能型手機，將想要查詢的產品編號(貨號)或是QR Code，以及要查看此產品的生產履歷或是保固數據等數據串，都會經由步驟7，根據MQTT_Broker IP傳送至代理伺服裝置700，再經步驟8，由代理伺服裝置700直接將消費者想要查詢的數據串傳送給云端裝置500。再接著，經由步驟9，云端裝置500判斷所收到的client_uuid及數據串完整及正確時，則會經由步驟11，根據譯碼后的消費者數據串，至產品生產履歷數據庫中比對所要查詢的產品編號(貨號)或是QR Code是否已建立；如果比對到消費者想要查詢的產品編號(貨號)或是QR Code之后，云端裝置500還會進一步查看消費者所要查詢的產品的生產履歷或是保固數據的型態(tài)是否存在；如果有符合消費者所要查詢的產品的 生產履歷或是保固數據的型態(tài)時，云端裝置500即會經由步驟12，與代理伺服裝置700’連接，并將消費者所要查詢的產品的生產履歷或是保固數據的型態(tài)傳送至代理伺服裝置700’，再由代理伺服裝置700’直接將產品的生產履歷或是保固數據的型態(tài)傳送至消費者的智能型手機，使得消費者可以透過智能型手機上的顯示器看到所要購買的產品生產履歷或是保固數據。

由于云端裝置500可以設定代理伺服裝置700’的IP、賬號及密碼，故當云端裝置500要將產品的生產履歷或是保固數據傳遞給用戶時，同樣的，其均只能經過代理伺服裝置700’的IP、賬號及密碼與代理伺服裝置700’連接及通信；因此，在云端裝置500將用戶所要查詢的產品的生產履歷或是保固數據等訊息傳送到用戶的智能型手機上的整個過程中，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率，可以有效的提高云端裝置500及物聯網生產履歷數據庫的安全性。

接著，請參考圖5，是本發(fā)明使用物聯網建立產品生產履歷及產品生產履歷管理方法的另一個實施例的流程圖。如圖5所示，本發(fā)明的使用物聯網建立產品生產履歷及產品生產履歷管理的方法包括:

步驟1:由客戶端裝置100向云端裝置500進行登錄，例如:客戶端裝置100通過https向云端裝置500登錄，以便啟動物聯網系統(tǒng)。

步驟2:當云端裝置500收到客戶端裝置100的請求后，云端裝置500會先驗證客戶端裝置100所使用的硬件uuid(如MAC Address)是否已經儲存在云端裝置500的數據庫中。

步驟3:當云端裝置500確認客戶端裝置100所使用的硬件uuid(如MAC Address)已經儲存在云端裝置500的數據庫時，則判斷客戶端裝置100數據正確，其為本物聯網中的客戶端裝置100，則云端裝置500會產生一個客戶辯證碼(client uuid)、一對專屬客戶使用的密鑰。在本實施例中，此密鑰是使用安全性高的RSM非對稱式密鑰(Asymmetric Key)；故可以產生出一對client_pub_key及client_pri_key；并且將其所產生的uuid及密鑰等訊息回傳客戶端裝置100，這些回傳客戶端裝置100的訊息包括:client_uuid、sever_pub_key(此sever_pub_key即是client_pub_key。此外，若當云端裝置500收到客戶端裝置100的請求后，云端裝置500比對出客戶端裝置100所 使用的硬件uuid(如MAC Address)并不在云端裝置500的數據庫中時，及判斷此客戶端裝置100所使用的硬件uuid(如MAC Address)并非本物聯網中的客戶端裝置，則將此硬件uuid(如MAC Address)訊息儲存在另一個數據庫中，以便后續(xù)比對。

步驟4:客戶端裝置100判斷云端裝置500所產生的uuid及密鑰等訊息是否以正確收到；當客戶端裝置100確認已經正確地收到uuid及密鑰等訊息后，客戶端裝置100隨即會以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)通過https向云端裝置500要求取得client_share_key、share_key_expiry date time、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼(username/password)。

在本發(fā)明的較佳實施例中，此密鑰是使用RSM非對稱式密鑰(Asymmetric Key)；故可以產生出一對client_pub_key及client_pri_key；其中，RSM非對稱式密鑰具有解碼時間長，所以安全性高。此外，在另一個較佳實施例中，云端裝置500還可以選擇性的產生一個客戶端裝置100專屬的對稱式密鑰(Symmetric Key)client_share_key。故在本發(fā)明的較佳實施例中，可以選擇性的將RSM非對稱式密鑰及對稱式密鑰配合使用；由于，對稱式密鑰具有譯碼時間短，相對地安全性較低，因此需要隨時變動client_share_key，以確保安全性；為此，云端裝置500還會進一步產生一個隨時變動的share_key_expiry date time，藉由不定時的更改client_share_key來提升安全性；故當云端裝置500偵測到隨時變動的client_share_key已經超過了設定變動的時間后，即會自動產生新的client_share_key，以確保安全性。

步驟5:當云端裝置500收到轉成亂碼的client_uuid后，即會根據sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將client_share_key、share_key_expiry date time、代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼等以client_pub_key編碼后回傳至客戶端裝置100。

步驟6:當客戶端裝置100自云端裝置500取得相關數據后，客戶端裝置100隨即會使用client_pri_key進行譯碼，并確認所收到的訊息必須完整，此完整的訊息包括:1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP； 4.MQTT_Broker username/password；5.client_Share_key；6.share_key_expiry date time。當客戶端裝置100在確認收到完整的訊息后，即會與代理伺服裝置700進行連接；若客戶端裝置100判斷所收到的訊息不完整時，會回到步驟4，重新要求向云端裝置500要求取得。

步驟7:客戶端裝置100使用MQTT_Broker IP及MQTT_Broker賬號及密碼連接代理伺服裝置700；同時，也使用client_share_key將client_uuid及客戶端裝置100所要傳給云端裝置500的數據內容(例如:產品的生產履歷等)進行編碼后，再上傳至代理伺服裝置700。

步驟8:客戶端裝置100檢查Share_key_expiry date time的時效是否已經到期；若檢查結果尚未到期后，則編碼后的client_uuid及數據串(例如:產品的生產履歷等)內容上傳至代理伺服裝置700；若檢查結果為過期狀態(tài)后，則會回到步驟4，重新要求向云端裝置500要求取得新的Share_key_expiry date time。例如:到期日為2015/0501時；如果檢查結果已經過了Share_key_expiry date time的時效時(例如:檢查期日的結果為2015/0502)，則客戶端裝置100會重新以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)，通過https要求取得新的share_key_expiry date time；而當云端裝置500收到轉成亂碼的client_uuid后，即會根據sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將新的share_key_expiry date time以client_pub_key編碼后回傳至客戶端裝置100。此外，為增加安全性，share_key_expiry date time所設定的時間可以是周期性的，也可以是隨機變量的，可以由云端裝置500決定。

步驟9:代理伺服裝置700在收到客戶端裝置100所上傳的編碼client_uuid及訊息串(例如:產品的生產履歷等)后，隨即將客戶端裝置100所上傳的訊息直接(也就是說，不做任何處理)傳送給云端裝置500端。

步驟10:云端裝置500在接收到代理伺服裝置700所直接傳送的數據后，隨即使用client_share_key進行譯碼，并且會驗證所收到的client_uuid及數據串(例如:產品的生產履歷等)是否完整及正確。

步驟11:云端裝置500判斷所收到的client_uuid及數據串(例如:產品的生產履歷等)完整及正確時，則將譯碼后的客戶端數據串儲存至內存模塊530 中，等待用戶將這些收到的數據串(例如:產品的生產履歷等)進行特定的處理及應用；若驗證所收到的client_uuid及數據串不完整或不正確時，則進行記錄；在本實施例中，不正確的訊息包括(1)某ip對應到的client_uuid不正確，則可能有盜用問題(2)若某client_uuid有配合上Geo Location的數據上傳，可以藉由驗證GeoLocation的合理性來驗證(是否某個client_uuid這一分鐘在亞洲，下一分鐘在北美)。當不正確的訊息持續(xù)出現時，則判斷代理伺服裝置700可能被黑客攻擊；則云端裝置500可以選擇關閉此代理伺服裝置700。

很明顯地，在整個物聯網架構的連接方法過程中，從步驟1至步驟6都是在每一個客戶端裝置100出廠前就與云端裝置500完成連接，即每一個客戶端裝置100出廠后，就已經自云端裝置500獲得完整的訊息包括:1.Sever_pub_key；2.Client_pri_key；3.MQTT_Broker IP；4.MQTT_Broker username/password；5.client_Share_key；6.share_key_expiry date time。當物聯網系統(tǒng)啟動后，每一個客戶端裝置100所要傳送給云端裝置500處理的數據串，都會根據MQTT_Broker IP傳送至代理伺服裝置700，再由代理伺服裝置700直接將客戶端裝置100數據串傳送給云端裝置500。故自步驟7至步驟10之間的訊息傳遞過程中，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率。由于代理伺服裝置700只是將客戶端裝置100上傳的數據直接傳送給云端裝置500，故可以降低代理伺服裝置700的MQTT_Broker IP及MQTT_Broker賬號及密碼被破解的機率，可以更增加物聯網通信過程的安全性。

接著，本發(fā)明還可以在圖5的步驟4中，將客戶端裝置100向云端裝置500取得代理伺服裝置700的MQTT_Broker IP、MQTT_Broker賬號及MQTT_Broker密碼的過程，分為兩次來執(zhí)行；例如:第一次是客戶端裝置100以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)通過https要求取得client_share_key及MQTT_Broker IP；而當云端裝置500收到轉成亂碼的client_uuid后，即會根據sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將client_share_key及MQTT_Broker IP等以client_pub_key編碼后回傳至客 戶端裝置100；第二次是客戶端裝置100再以編碼后的client_uuid(即client_uuid會根據sever_pub_key轉成亂碼)，通過https要求取得MQTT_Broker賬號及密碼；而當云端裝置500收到轉成亂碼的client_uuid后，即會根據sever_pri_key進行譯碼，以確認client_uuid是否正確；待云端裝置500確認client_uuid正確后，云端裝置500將MQTT_Broker賬號及密碼等以client_pub_key編碼后回傳至客戶端裝置100。特別要說明的，第一次及第二次所要取得的內容中，只要求將MQTT_Broker的IP、賬號及密碼分兩次取得，其他并不加以限制。

接著，當多位消費者使用各自的智能型手機在網絡上分別看到某一個產品，并且想要購買此產品時，消費者可以透過網絡上所標示的產品編號(貨號)或是QR Code等，查看此產品的生產履歷或是保固數據，其管理過程說明如下。

首先，每一位消費者可以先建立其所使用的智能型手機與本發(fā)明的物聯網完成身分辨識的程序；例如:每一位消費者都已下載本發(fā)明物聯網的APP軟件，經由圖4的步驟1至步驟6的過程，讓每一位消費者所使用智能型手機已在本發(fā)明的物聯網完成身分辨識的程序，即每一位消費者所使用智能型手機的硬件uuid(如MAC Address)均已經儲存在云端裝置500的數據庫中；接著，當每一位消費者透過其所使用的智能型手機，將想要查詢的產品編號(貨號)或是QR Code，以及要查看此產品的生產履歷或是保固數據等數據串，都會經由步驟7至步驟8，根據每一位消費者所配對好的MQTT_Broker IP傳送至代理伺服裝置700，再經步驟9，由代理伺服裝置700直接將消費者想要查詢的數據串傳送給云端裝置500。再接著，經由步驟10，云端裝置500判斷所收到的client_uuid及數據串完整及正確時，則會經由步驟12，根據解碼后的每一位消費者的數據串，至產品生產履歷數據庫中比對所要查詢的產品編號(貨號)或是QR Code是否已建立；如果比對到每一位消費者想要查詢的產品編號(貨號)或是QR Code之后，云端裝置500還會進一步查看消費者所要查詢的產品的生產履歷或是保固數據的型態(tài)是否存在；如果有符合消費者所要查詢的產品的生產履歷或是保固數據的型態(tài)時，云端裝置500即會經由步驟13，與代理伺服裝置700’連接，并將每一位消費者所要查詢的產品的 生產履歷或是保固數據的型態(tài)傳送至另一個代理伺服裝置700’，再由代理伺服裝置700’直接將產品的生產履歷或是保固數據的型態(tài)傳送至每一位消費者的智能型手機，使得每一位消費者可以透過智能型手機上的顯示器看到所要購買的產品生產履歷或是保固數據。很明顯的，在云端裝置500也可以與多個代理伺服裝置700’通信，且每一個代理伺服裝置700’可以與多個消費者形成配對。

由于云端裝置500可以設定代理伺服裝置700’的IP、賬號及密碼，故當云端裝置500要將產品的生產履歷或是保固數據傳遞給用戶時，同樣的，其均只能經過代理伺服裝置700’的IP、賬號及密碼與代理伺服裝置700’連接及通信；因此，在云端裝置500將用戶所要查詢的產品的生產履歷或是保固數據等訊息傳送到用戶的智能型手機上的整個過程中，云端裝置500并不會直接暴露出自己的地址，故可以降低云端裝置500被黑客攻擊的機率，可以有效的提高云端裝置500及物聯網生產履歷數據庫的安全性。

雖然本發(fā)明以前述之較佳實施例揭露如上，然其并非用以限定本發(fā)明，任何熟習本領域技藝者，在不脫離本發(fā)明之精神和范圍內，當可作些許之更動與潤飾，因此本發(fā)明之專利保護范圍須視本說明書所附之申請專利范圍所界定者為準。