本發(fā)明屬于智能交通技術(shù)領(lǐng)域，尤其涉及一種基于動態(tài)碼的租車方法，以及與該方法對應(yīng)的租車系統(tǒng)和服務(wù)器端。

背景技術(shù)：

為了提倡環(huán)保出行，緩解交通壓力并且實現(xiàn)資源共享，市政府推出了公共自行車系統(tǒng)。但公共自行車系統(tǒng)在實際使用過程中存在諸多痛點：

痛點一：采取刷卡用車模式，實體卡片容易丟失；

痛點二：有樁租還，站點覆蓋范圍有限，站點樁位有限，遇到滿樁情況不易還車，從站點到目的地還需不行；

痛點三：還車時需要刷卡扣費，系統(tǒng)網(wǎng)絡(luò)穩(wěn)定性差；

痛點四：只需服務(wù)器發(fā)送指令給自行車進行開鎖，安全性無法管控而且開鎖的方式也較單一化。

痛點五：針對服務(wù)器發(fā)送指令給自行車的開鎖方式，由于服務(wù)器與鎖保持長連接通訊方式，因此其功耗較高。

針對現(xiàn)有技術(shù)中的種種缺陷和不便，提供一種能同時克服以上缺陷的租車方法，以及對應(yīng)的系統(tǒng)和服務(wù)器端是本領(lǐng)域技術(shù)人員急需解決的問題。

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

針對以上技術(shù)不足，本發(fā)明提供了一種基于動態(tài)碼的租車方法及租車系統(tǒng)、服務(wù)器端，可通過匹配動態(tài)碼與物聯(lián)鎖內(nèi)部生成的開鎖密碼來開鎖以實現(xiàn)租還車，更便捷更安全及使開鎖方式的多樣化，同時由于物聯(lián)鎖與服務(wù)器端采用短連接通訊方式還可節(jié)省物聯(lián)鎖的能耗。

本發(fā)明是這樣實現(xiàn)的，一種基于動態(tài)碼的租車方法，其應(yīng)用于服務(wù)器端，包括如下步驟：

a.服務(wù)器端接收客戶端發(fā)出的租車請求，所述租車請求中至少包括用戶的信息、定位信息以及物聯(lián)鎖信息；

b.服務(wù)器端判斷租車請求是否滿足條件，若滿足，則依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼；

c.服務(wù)器端將所述動態(tài)碼發(fā)送至客戶端；

d.當(dāng)接收到物聯(lián)鎖發(fā)出的開鎖信息時，服務(wù)器端開始記錄用戶行程信息；

e.當(dāng)接收到物聯(lián)鎖發(fā)出的關(guān)鎖信息時，服務(wù)器端依據(jù)用戶行程信息生成用戶行程單，并將用戶行程單發(fā)送至客戶端。

優(yōu)選的，所述物聯(lián)鎖信息通過二維碼與物聯(lián)鎖綁定。

優(yōu)選的，所述用戶行程信息至少包括定位信息和開鎖時的時間信息，所述用戶行程單至少包括所述用戶行程信息、關(guān)鎖時的時間信息、用戶的身份標識信息以及使用費用信息。

優(yōu)選的，服務(wù)器端判斷租車請求是否滿足條件，若滿足，則依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼具體包括：

b1：服務(wù)器端從用戶的信息中提取身份標識信息并驗證該身份標識信息是否合法，若是，則進入步驟b2；

b2：檢測該用戶對應(yīng)的押金信息或信用度是否滿足預(yù)先設(shè)定的要求，若是，則進入步驟b3；

b3：服務(wù)器端驗證二維碼是否為有效二維碼；若是，則進入步驟b4；

b4：服務(wù)器端提取二維碼中物聯(lián)鎖信息并判斷所述信息是否合法，若是，則服務(wù)器端依據(jù)當(dāng)前時間與所述租車請求包括的物聯(lián)鎖信息生成動態(tài)碼。

優(yōu)選的，在步驟e之后還包括如下步驟：服務(wù)器端接收客戶端發(fā)送的繳費信息。

本發(fā)明還提供一種基于動態(tài)碼的租車方法，其應(yīng)用于物聯(lián)鎖，所述物聯(lián)鎖鎖于車輪上，包括如下步驟：

a’.當(dāng)物聯(lián)鎖感應(yīng)客戶端掃碼時，依據(jù)物聯(lián)鎖內(nèi)的當(dāng)前時間與物聯(lián)鎖信息生成開鎖密碼，并保存開鎖密碼；

b’.當(dāng)接收到輸入的動態(tài)碼時，將所述輸入的動態(tài)碼與開鎖密碼進行匹配；

c’.當(dāng)所述輸入的動態(tài)碼與開鎖密碼匹配成功時，將物聯(lián)鎖進行開鎖；

d’.當(dāng)物聯(lián)鎖開鎖或關(guān)鎖成功時，將開鎖信息或關(guān)鎖信息發(fā)送至服務(wù)器端。

優(yōu)選的，所述物聯(lián)鎖在預(yù)設(shè)時間段內(nèi)保存開鎖密碼。

優(yōu)選的，當(dāng)接收到輸入的動態(tài)碼時，將所述輸入的動態(tài)碼與開鎖密碼進行匹配具體包括：

b’1.當(dāng)接收到輸入的動態(tài)碼時，所述物聯(lián)鎖獲取預(yù)設(shè)時間段內(nèi)的開鎖密碼；

b’2.將所述動態(tài)碼與所述預(yù)設(shè)時間段內(nèi)的開鎖密碼進行匹配。

優(yōu)選的，在步驟d’之后包括：

物聯(lián)鎖每隔固定時間或預(yù)設(shè)時長內(nèi)未開鎖，則發(fā)送時間較準請求至服務(wù)器端以請求時間較準。

本發(fā)明實施例還提供.一種基于動態(tài)碼的租車系統(tǒng)，其應(yīng)用于服務(wù)器端，包括：

接收模塊，用于接收客戶端發(fā)出的租車請求，所述租車請求中至少包括用戶的信息、定位信息以及物聯(lián)鎖信息；

處理模塊，用于判斷租車請求是否滿足條件，并在滿足條件時，則依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼；

發(fā)送模塊，用于將所述動態(tài)碼發(fā)送至客戶端；

所述處理模塊，還用于當(dāng)所述接收模塊接收到物聯(lián)鎖發(fā)出的開鎖信息時，開始記錄用戶行程信息；

所述處理模塊，還用于當(dāng)接收模塊接收到物聯(lián)鎖發(fā)出的關(guān)鎖信息時，依據(jù)用戶行程信息生成用戶行程單，并通過發(fā)送模塊將用戶行程單發(fā)送至客戶端。

優(yōu)選的，所述用戶行程信息至少包括定位信息和開鎖時的時間信息，所述用戶行程單至少包括所述用戶行程信息、關(guān)鎖時的時間信息、用戶的身份標識信息以及使用費用信息。

優(yōu)選的，所述處理模塊判斷租車請求是否滿足條件，并在滿足條件時，依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼具體包括：

驗證用戶的身份標識信息是否合法，若是，則檢測該用戶對應(yīng)的押金信息或信用度是否滿足預(yù)先設(shè)定的要求，若是，則驗證二維碼是否為有效二維碼；若是，則驗證二維碼中物聯(lián)鎖信息是否合法，若是，則依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼。

優(yōu)選的，所述接收模塊還用于接收所述客戶端發(fā)送的繳費信息。

本發(fā)明實施例還提供一種基于動態(tài)碼的租車系統(tǒng)，其應(yīng)用于物聯(lián)鎖，該物聯(lián)鎖鎖于車輪上，包括：

密碼管理模塊，用于當(dāng)物聯(lián)鎖感應(yīng)客戶端掃碼時，依據(jù)物聯(lián)鎖內(nèi)的當(dāng)前時間與物聯(lián)鎖信息生成開鎖密碼，并保存開鎖密碼；

所述密碼管理模塊，還用于當(dāng)接收到輸入的動態(tài)碼時，將所述輸入的動態(tài)碼與開鎖密碼進行匹配；

開鎖模塊，用于當(dāng)所述輸入的動態(tài)碼與開鎖密碼匹配成功時，將物聯(lián)鎖進行開鎖；

上傳模塊，用于當(dāng)物聯(lián)鎖開鎖或關(guān)鎖成功時，將開鎖信息或關(guān)鎖信息發(fā)送至服務(wù)器端。

優(yōu)選的，所述物聯(lián)鎖在預(yù)設(shè)時間段內(nèi)保存開鎖密碼。

優(yōu)選的，所述密碼管理模塊具體當(dāng)用于：

當(dāng)接收到輸入的動態(tài)碼時，所述物聯(lián)鎖獲取預(yù)設(shè)時間段內(nèi)的開鎖密碼；

將所述動態(tài)碼與所述預(yù)設(shè)時間段內(nèi)的開鎖密碼進行匹配。

優(yōu)選的，還包括時間管理模塊，用于：

物聯(lián)鎖每隔固定時間或預(yù)設(shè)時長內(nèi)未開鎖，則發(fā)送時間較準請求至服務(wù)器端以請求時間較準來最終同步時間等。在本實施例中，所述物聯(lián)鎖與所述服務(wù)器端之間是建立短連接，所述物聯(lián)鎖每隔預(yù)設(shè)時間與服務(wù)器端同步時間、上報位置、獲取配置等。

本發(fā)明還提供一種服務(wù)器端，如上所述的基于動態(tài)碼的租車系統(tǒng)，所述服務(wù)器端與客戶端建立通訊連接，用于接收客戶端發(fā)送的租車請求，還用于向客戶端發(fā)送動態(tài)碼，接收客戶端發(fā)送的開鎖時記錄用戶行程信息，接收客戶端發(fā)送的關(guān)鎖信息時向客戶端發(fā)送用戶行程單，所述租車請求中至少包括用戶的信息、定位信息以及物聯(lián)鎖信息。

與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果如下：本技術(shù)方案采用客戶端、服務(wù)器端以及物聯(lián)鎖與自行車配合，要租車時即可通過移動終端中的客戶端將攜帶有物聯(lián)鎖身份標識的租車請求發(fā)送至服務(wù)器端，服務(wù)器端發(fā)送動態(tài)碼給客戶端，若物聯(lián)鎖針對輸入的動態(tài)碼與自身生成的開鎖密碼匹配成功時，則開鎖，即實現(xiàn)租車；要還車時，手動關(guān)鎖后，物聯(lián)鎖向服務(wù)器端發(fā)送關(guān)鎖消息，服務(wù)器端生成用戶行程單，發(fā)送至客戶端確認。

整個過程中不需要實體卡，只需移動終端即可，避免了卡容易丟失的情況。且該種方式實現(xiàn)無樁租還車，無范圍限制，隨用隨停，用戶騎行至目的地，鎖車后服務(wù)器端自動結(jié)算，線上自動扣款，解決了現(xiàn)有技術(shù)中公共自行車系統(tǒng)的諸多缺陷，大大提高了租還車的便捷性。同時本發(fā)明可通過匹配動態(tài)碼與物聯(lián)鎖內(nèi)部生成的開鎖密碼來開鎖以實現(xiàn)租還車，更安全及使開鎖方式的多樣化，而且大大降低物聯(lián)鎖能耗。

附圖說明

圖1為本發(fā)明實施例提供的一種基于動態(tài)碼的租車方法應(yīng)用于服務(wù)器端的流程圖；

圖2為本發(fā)明實施例提供的一種基于動態(tài)碼的租車方法應(yīng)用于物聯(lián)鎖的流程圖。

圖3為本發(fā)明實施例提供的服務(wù)器端的功能模塊圖。

圖4為本發(fā)明實施例提供的物聯(lián)鎖的功能模塊圖。

具體實施方式

為了使本發(fā)明所要解決的技術(shù)問題、技術(shù)方案及有益效果更加清楚明白，以下結(jié)合附圖及實施例，對本發(fā)明進行進一步詳細說明。應(yīng)當(dāng)理解，此處所描述的具體實施例僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

本發(fā)明實施例提供的基于動態(tài)碼的租車方法，涉及客戶端、服務(wù)器端、物聯(lián)鎖三方，物聯(lián)鎖鎖于自行車輪上，租車者為用戶，租車者的移動終端中耦合有本實施例所述的客戶端，客戶端與服務(wù)器端通訊連接，服務(wù)器端與客戶端及物聯(lián)鎖通訊連接。

本發(fā)明實施例公開的一種基于動態(tài)碼的租車方法，其應(yīng)用于服務(wù)器端，如圖1所示，包括如下步驟：

s100：服務(wù)器端接收客戶端發(fā)出的租車請求，所述租車請求中至少包括用戶的信息、定位信息以及物聯(lián)鎖信息。

用戶通過客戶端登錄服務(wù)器端后，向服務(wù)器端發(fā)送租車請求，所述租車請求中至少包括用戶的信息、定位信息以及物聯(lián)鎖信息，在本發(fā)明實施例中，作為優(yōu)選，物聯(lián)鎖信息包含于二維碼中，二維碼貼于自行車或物聯(lián)鎖上，使得自行車、物聯(lián)鎖、二維碼互相對應(yīng)。采用二維碼的方式，提升了操作的便捷性。在其它實施例中，所述物聯(lián)鎖不限于鎖于自行車上，還可鎖于摩托車等行駛車輛上，當(dāng)然也可以不限于鎖于車輪上。

在本發(fā)明實施例中，客戶端調(diào)用移動終端的掃描設(shè)備掃描二維碼獲取物聯(lián)鎖信息，并獲取移動終端的定位信息后，再添加用戶的信息后生成租車請求，并把該租車請求發(fā)送至服務(wù)器端。

s110：服務(wù)器端判斷租車請求是否滿足條件？若滿足，則進入步驟s120，否則，結(jié)束流程。

本發(fā)明實施例中，服務(wù)器端判斷租車請求是否滿足條件主要判斷三方面因素，包括用戶的信息、二維碼以及物聯(lián)鎖信息。具體步驟如下：

b1：服務(wù)器端從用戶的信息中提取身份標識信息并驗證該身份標識信息是否合法，若是，則進入步驟b2，否則結(jié)束流程或向客戶端發(fā)送身份不合法的提示信息。

服務(wù)器端接收到租車請求后，首先驗證租車請求中的用戶的身份標識信息是否合法，即驗證該用戶是否為本服務(wù)器端上的注冊用戶。

b2：檢測該用戶對應(yīng)的押金信息或信用度是否滿足預(yù)先設(shè)定的要求，若是，則進入步驟b3，否則結(jié)束流程或向客戶端發(fā)送押金或信用度不滿足要求的提示信息。

基于自行車的成本考慮，以及規(guī)范用戶的租車行為，需要用戶在租車前繳納一定的押金或提供信用證明。本發(fā)明實施例中，優(yōu)先檢測用戶的第三方提供的信用基數(shù)，若滿足服務(wù)器端預(yù)先設(shè)定的信用基數(shù)，則進入步驟b3，否則，再檢測用戶在服務(wù)器端上的押金數(shù)額，若滿足預(yù)先設(shè)定的數(shù)額，則進入步驟b3，否則結(jié)束流程或向客戶端發(fā)送押金或信用度不滿足要求的提示信息。

b3：服務(wù)器端驗證二維碼是否為有效二維碼；若是，則進入步驟b4，否則結(jié)束流程或向客戶端發(fā)送二維碼無效的信息。

在用戶的身份信息以及押金或信用度通過驗證后，服務(wù)器端開始驗證二維碼是否為有效二維碼，即驗證收到的二維碼是否為在本服務(wù)器端存儲的二維碼。

b4：服務(wù)器端提取二維碼中物聯(lián)鎖信息并判斷所述信息是否合法，若是，則進入步驟s120。當(dāng)上述驗證通過后，驗證物聯(lián)鎖信息是否與本服務(wù)器端中物聯(lián)鎖信息相同，若是，則服務(wù)器端依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼，若否，則結(jié)束流程或向客戶端發(fā)送物聯(lián)鎖錯誤的提示信息。

s120：服務(wù)器端依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼。

本發(fā)明實施例中，當(dāng)判斷租車請求滿足條件時，所述服務(wù)器端依據(jù)查詢當(dāng)前時間，獲取當(dāng)前時間，并從租車請求中提取出相應(yīng)的物聯(lián)鎖信息，依據(jù)獲取的服務(wù)器端當(dāng)前時間與提取出的相應(yīng)的物聯(lián)鎖信息生成相應(yīng)的動態(tài)碼。

具體的，如獲取的服務(wù)器的當(dāng)前時間為“2017-4-29:20”；所述物聯(lián)鎖信息為“12345678”，對應(yīng)生成的動態(tài)碼為“3648”。所述獲取的時間格式，物聯(lián)鎖信息編號方式，及動態(tài)碼的字符組成都不限于上述舉例。

s130：服務(wù)器端將所述動態(tài)碼發(fā)送至客戶端。

本發(fā)明實施例中，服務(wù)器端與客戶端之間通過tcp長連接方式，并采用標準的808協(xié)議進行通訊。

s140：當(dāng)接收到物聯(lián)鎖發(fā)出的開鎖信息時，服務(wù)器端開始記錄用戶行程信息。

客戶端接收到動態(tài)碼后，用戶將所述動態(tài)碼輸入至所述物聯(lián)鎖，當(dāng)物聯(lián)鎖將所述動態(tài)碼與物聯(lián)鎖內(nèi)部的開鎖密碼匹配成功后控制機械結(jié)構(gòu)開鎖，開鎖成功時，物聯(lián)鎖向服務(wù)器端發(fā)送開鎖信息。在本實施例中，所述服務(wù)器端生成的動態(tài)碼與所述物聯(lián)鎖內(nèi)部的開鎖密碼采用相同加密算法。服務(wù)器端接收到物聯(lián)鎖發(fā)出的開鎖信息，表示租車成功，此時，服務(wù)器端開始記錄用戶的行程信息，至少包括租車成功時的定位信息和開鎖時的時間信息。本發(fā)明實施例中，為了更好地掌握被租車輛的使用情況，用戶的行程信息中還包括自行車使用過程中的gps定位軌跡。

本發(fā)明實施例中，服務(wù)器端與物聯(lián)鎖之間建立短連接進行通訊，所述物聯(lián)鎖每隔預(yù)設(shè)時間與服務(wù)器端同步時間、上報位置、獲取配置等。由于物聯(lián)鎖與服務(wù)器端采用短連接通訊方式，可以大大降低物聯(lián)鎖的功耗。具體而言，服務(wù)器端發(fā)送指令給物聯(lián)鎖開鎖的方式在不充電情況下，物聯(lián)鎖可待機大概35天左右，而動態(tài)密碼鎖的情況下，該物聯(lián)鎖的待機時間大概在3年。

s150：當(dāng)接收到物聯(lián)鎖發(fā)出的關(guān)鎖信息時，服務(wù)器端根據(jù)用戶行程信息生成用戶行程單，并將用戶行程單發(fā)送至客戶端。

當(dāng)用戶停止租車時，手動關(guān)鎖，此時，物聯(lián)鎖向服務(wù)器端發(fā)送關(guān)鎖信息，表明租車結(jié)束，服務(wù)器端根據(jù)用戶行程信息生成用戶行程單，用戶行程單中包括用戶的信息(包括身份標識信息)、開鎖和關(guān)鎖的時間信息、使用費用信息。使用費用的計算規(guī)則可由服務(wù)器端的管理方預(yù)先設(shè)定，本發(fā)明實施例中，租車的計費根據(jù)使用時間來計算，開鎖時間到關(guān)鎖時間之間的時間段即為租車時間，使用時間乘以單位時間的費用即為最后的使用費用。

s150：服務(wù)器端接收客戶端發(fā)送的繳費信息。

服務(wù)器端將用戶行程單發(fā)送至客戶端后，客戶端確認付款并將付款信息發(fā)送至服務(wù)器端，從而完成本次租還車業(yè)務(wù)。

該發(fā)明實施例所公開的基于動態(tài)碼的租車方法，整個過程中不需要實體卡，只需移動終端即可，避免了卡容易丟失的情況。且該種方式實現(xiàn)無樁租還車，無范圍限制，隨用隨停，用戶騎行至目的地，鎖車后服務(wù)器端自動結(jié)算，線上自動扣款，解決了現(xiàn)有技術(shù)中公共自行車系統(tǒng)的諸多缺陷，大大提高了租還車的便捷性。同時由于自行車開鎖過程中會利用動態(tài)碼與物聯(lián)鎖內(nèi)的開鎖密碼進行匹配以提高自行車的安全性，并豐富了開鎖方式。與此同時，此種采用動態(tài)碼的開鎖模式相較傳統(tǒng)的通過服務(wù)器端發(fā)送指令給物聯(lián)鎖開鎖的方式可大大降低能耗，具體而言，服務(wù)器端發(fā)送指令給物聯(lián)鎖開鎖的方式在不充電情況下可待機大概35天左右，而動態(tài)密碼鎖待機時間大概在3年。

基于同一發(fā)明構(gòu)思，本發(fā)明實施例還提供一種基于動態(tài)碼的租車方法，其應(yīng)用于物聯(lián)鎖，所述物聯(lián)鎖鎖于車輪上，例如自行車，摩托車，等車可行駛車輪上，如圖2所示。

s200：當(dāng)物聯(lián)鎖感應(yīng)客戶端掃碼時，依據(jù)物聯(lián)鎖內(nèi)的當(dāng)前時間與物聯(lián)鎖信息生成開鎖密碼，并保存開鎖密碼。

具體的，所述物聯(lián)鎖內(nèi)置感應(yīng)器，當(dāng)有客戶端掃碼時，所述物聯(lián)鎖獲取物聯(lián)鎖內(nèi)部計時器計算的當(dāng)前時間，并獲取物聯(lián)鎖信息，并依據(jù)所述當(dāng)前時間與物聯(lián)鎖信息生成開鎖密碼。所述開鎖密碼也是一組編碼，可以是數(shù)字，字母或其它字符形式。所述物聯(lián)鎖信息指的物聯(lián)鎖的id。

與此同時，所述生成的開鎖密碼會保存在所述物聯(lián)鎖中一段預(yù)設(shè)時長，例如，一分鐘、二分鐘等，其中所述預(yù)設(shè)時長可依據(jù)具體情況進行相應(yīng)設(shè)置。由于后返回給租車用戶。將所述開鎖密碼保存預(yù)設(shè)時長是一種容錯機制，由于服務(wù)器端時間可能和物聯(lián)鎖內(nèi)部時間有幾秒的誤差時間，所以物聯(lián)鎖內(nèi)部會保存當(dāng)前一分鐘的密碼，并且會保存前后兩分鐘對應(yīng)的密碼，用來解決時間誤差問題和用戶操作開鎖時間，保證用戶能正常開鎖。

s220：當(dāng)接收到輸入的動態(tài)碼時，將所述輸入的動態(tài)碼與開鎖密碼進行匹配。

客戶端接收到服務(wù)器端發(fā)送的動態(tài)碼后，用戶可將所述動態(tài)碼通過手動等方式輸入至物聯(lián)鎖，所述物聯(lián)鎖會將所述動態(tài)碼與當(dāng)前物聯(lián)鎖內(nèi)生成的開鎖密碼進行匹配。其具體包括：

b’1.當(dāng)接收到輸入的動態(tài)碼時，所述物聯(lián)鎖獲取預(yù)設(shè)時間段內(nèi)的開鎖密碼；

b’2.將所述動態(tài)碼與所述預(yù)設(shè)時間段內(nèi)的開鎖密碼進行匹配。

s230：當(dāng)所述輸入的動態(tài)碼與開鎖密碼匹配成功時，將物聯(lián)鎖進行開鎖。

客戶端接收到動態(tài)碼后，用戶將所述動態(tài)碼輸入至所述物聯(lián)鎖，當(dāng)物聯(lián)鎖將所述動態(tài)碼與物聯(lián)鎖內(nèi)部的開鎖密碼匹配成功后控制機械結(jié)構(gòu)開鎖。

s240：當(dāng)物聯(lián)鎖開鎖或關(guān)鎖成功時，將開鎖信息或關(guān)鎖信息發(fā)送至服務(wù)器端。

開鎖成功時，物聯(lián)鎖向服務(wù)器端發(fā)送開鎖信息；另一方面，當(dāng)關(guān)鎖成功時，物聯(lián)鎖也會向服務(wù)器端發(fā)送關(guān)鎖信息。

基于同一發(fā)明構(gòu)思，本發(fā)明實施例還提供了服務(wù)器端的模塊示意圖，如圖3所示，包括接收模塊30，用于接收客戶端發(fā)出的租車請求，所述租車請求中至少包括用戶的信息、定位信息以及物聯(lián)鎖信息；

處理模塊32，用于判斷租車請求是否滿足條件，并在滿足條件時，則依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼；

發(fā)送模塊35，用于將所述動態(tài)碼發(fā)送至客戶端；

所述處理模塊32，還用于當(dāng)所述接收模塊30接收到物聯(lián)鎖發(fā)出的開鎖信息時，開始記錄用戶行程信息；

所述處理模塊32，還用于當(dāng)接收模塊30接收到物聯(lián)鎖發(fā)出的關(guān)鎖信息時，依據(jù)用戶行程信息生成用戶行程單，并通過發(fā)送模塊將用戶行程單發(fā)送至客戶端。

所述用戶行程信息至少包括定位信息和開鎖時的時間信息，所述用戶行程單至少包括所述用戶行程信息、關(guān)鎖時的時間信息、用戶的身份標識信息以及使用費用信息。

所述處理模塊判斷租車請求是否滿足條件，并在滿足條件時，依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼具體包括：

驗證用戶的身份標識信息是否合法，若是，則檢測該用戶對應(yīng)的押金信息或信用度是否滿足預(yù)先設(shè)定的要求，若是，則驗證二維碼是否為有效二維碼；若是，則驗證二維碼中物聯(lián)鎖信息是否合法，若是，則依據(jù)當(dāng)前時間與所述物聯(lián)鎖信息生成動態(tài)碼。

所述接收模塊還用于接收所述客戶端發(fā)送的繳費信息。

在本發(fā)明實施例中，所述服務(wù)器端具體為服務(wù)器，所述服務(wù)器包括：

至少一個處理器；以及，與所述至少一個處理器通信連接的存儲器；其中，所述存儲器存儲有可被所述一個處理器執(zhí)行的指令，所述指令被所述至少一個處理器執(zhí)行，以使所述至少一個處理器能夠執(zhí)行本發(fā)明實施例中所述的基于動態(tài)碼的租車方法。

所述服務(wù)器端與客戶端建立通訊連接，用于接收客戶端發(fā)送的租車請求，還用于向客戶端發(fā)送動態(tài)碼，接收客戶端發(fā)送的開鎖時記錄用戶行程信息，接收客戶端發(fā)送的關(guān)鎖信息時向客戶端發(fā)送用戶行程單，所述租車請求中至少包括用戶的信息、定位信息以及物聯(lián)鎖信息。服務(wù)器端在用戶掃碼租車并驗證通過時生成動態(tài)碼，用戶在鎖上輸入所述動態(tài)碼后，物聯(lián)鎖根據(jù)算法進行校驗，認證通過即開鎖。

此種采用動態(tài)碼的開鎖模式相較傳統(tǒng)的通過服務(wù)器端發(fā)送指令給物聯(lián)鎖開鎖的方式可大大降低能耗，具體而言，服務(wù)器端發(fā)送指令給物聯(lián)鎖開鎖的方式在不充電情況下可待機大概35天左右，而動態(tài)密碼鎖待機時間大概在3年。

基于同一發(fā)明構(gòu)思，本發(fā)明實施例還提供了物聯(lián)鎖的模塊示意圖，如圖4所示，其具體包括：

密碼管理模塊40，用于當(dāng)物聯(lián)鎖感應(yīng)客戶端掃碼時，依據(jù)物聯(lián)鎖內(nèi)的當(dāng)前時間與物聯(lián)鎖信息生成開鎖密碼，并保存開鎖密碼；

所述密碼管理模塊40，還用于當(dāng)接收到輸入的動態(tài)碼時，將所述輸入的動態(tài)碼與開鎖密碼進行匹配；

開鎖模塊42，用于當(dāng)所述輸入的動態(tài)碼與開鎖密碼匹配成功時，將物聯(lián)鎖進行開鎖；

上傳模塊45，用于當(dāng)物聯(lián)鎖開鎖或關(guān)鎖成功時，將開鎖信息或關(guān)鎖信息發(fā)送至服務(wù)器端。

所述物聯(lián)鎖在預(yù)設(shè)時間段內(nèi)保存開鎖密碼。

所述密碼管理模塊40具體當(dāng)用于：

當(dāng)接收到輸入的動態(tài)碼時，所述物聯(lián)鎖獲取預(yù)設(shè)時間段內(nèi)的開鎖密碼；

將所述動態(tài)碼與所述預(yù)設(shè)時間段內(nèi)的開鎖密碼進行匹配。

所述物聯(lián)鎖還包括時間管理模塊，用于：

物聯(lián)鎖每隔固定時間或預(yù)設(shè)時長內(nèi)未開鎖，則發(fā)送時間較準請求至服務(wù)器端以請求時間較準。例如，每隔8小時，或當(dāng)檢測到4小時內(nèi)物聯(lián)聯(lián)未被打開時，則時間管理模塊自動發(fā)送較準請求至服務(wù)器端以請求時間較準，以確定物聯(lián)鎖與服務(wù)器端時間一致。在本實施例中，所述物聯(lián)鎖與所述服務(wù)器端之間是建立短連接，所述物聯(lián)鎖每隔預(yù)設(shè)時間與服務(wù)器端同步時間、上報位置、獲取配置等。

本實施例中的用戶形成信息和用戶行程單與上文所述一致，故不再贅述。所述客戶端還用于向服務(wù)器端發(fā)送繳費信息。

在此提供的算法和顯示不與任何特定計算機、虛擬系統(tǒng)或者其它設(shè)備固有相關(guān)。各種通用系統(tǒng)也可以與基于在此的示教一起使用。根據(jù)上面的描述，構(gòu)造這類系統(tǒng)所要求的結(jié)構(gòu)是顯而易見的。此外，本發(fā)明也不針對任何特定編程語言。應(yīng)當(dāng)明白，可以利用各種編程語言實現(xiàn)在此描述的本發(fā)明的內(nèi)容，并且上面對特定語言所做的描述是為了披露本發(fā)明的最佳實施方式。

在此處所提供的說明書中，說明了大量具體細節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細節(jié)的情況下實踐。在一些實例中，并未詳細示出公知的方法、結(jié)構(gòu)和技術(shù)，以便不模糊對本說明書的理解。

類似地，應(yīng)當(dāng)理解，為了精簡本公開并幫助理解各個發(fā)明方面中的一個或多個，在上面對本發(fā)明的示例性實施例的描述中，本發(fā)明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而，并不應(yīng)將該公開的方法解釋成反映如下意圖：即所要求保護的本發(fā)明要求比在每個權(quán)利要求中所明確記載的特征更多的特征。更確切地說，如下面的權(quán)利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個實施例的所有特征。因此，遵循具體實施方式的權(quán)利要求書由此明確地并入該具體實施方式，其中每個權(quán)利要求本身都作為本發(fā)明的單獨實施例。

本領(lǐng)域那些技術(shù)人員可以理解，可以對實施例中的設(shè)備中的模塊進行自適應(yīng)性地改變并且把它們設(shè)置在與該實施例不同的一個或多個設(shè)備中?？梢园褜嵤├械哪K或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設(shè)備的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。

此外，本領(lǐng)域的技術(shù)人員能夠理解，盡管在此所述的一些實施例包括其它實施例中所包括的某些特征而不是其它特征，但是不同實施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實施例。例如，在下面的權(quán)利要求書中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。

本發(fā)明的各個部件實施例可以以硬件實現(xiàn)，或者以在一個或者多個處理器上運行的軟件模塊實現(xiàn)，或者以它們的組合實現(xiàn)。本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，可以在實踐中使用微處理器或者數(shù)字信號處理器(dsp)來實現(xiàn)根據(jù)本發(fā)明實施例的基于動態(tài)碼的租車系統(tǒng)服務(wù)器中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設(shè)備或者裝置程序(例如，計算機程序和計算機程序產(chǎn)品)。這樣的實現(xiàn)本發(fā)明的程序可以存儲在計算機可讀介質(zhì)上，或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網(wǎng)網(wǎng)站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。

應(yīng)該注意的是上述實施例對本發(fā)明進行說明而不是對本發(fā)明進行限制，并且本領(lǐng)域技術(shù)人員在不脫離所附權(quán)利要求的范圍的情況下可設(shè)計出替換實施例。在權(quán)利要求中，不應(yīng)將位于括號之間的任何參考符號構(gòu)造成對權(quán)利要求的限制。單詞“包含”不排除存在未列在權(quán)利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當(dāng)編程的計算機來實現(xiàn)。在列舉了若干裝置的單元權(quán)利要求中，這些裝置中的若干個可以是通過同一個硬件項來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序。可將這些單詞解釋為名稱。

顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。