熱門論文
最新論文
集成Webmail的知識產 權信息管理系統的設計與實現
發布時間：2023-07-07 16:29
目錄
摘要 I
ABSTRACT II
目錄 III
圖錄 VI
表錄 VIII
第一章 緒論 1
1.1研究背景和意義 1
1.2國內外研究現狀 2
1.3研究內容和創新點 3
1.3.1研究內容 3
1.3.2創新點 4
1.4論文結構 5
第二章 相關技術研究 6
2.1Vue.js 框架 6
2.2Express.js 框架 6
2.3MongoDB 數據庫 6
2.4Webmail 7
2.5微信公眾號開發 7
2.6本章小結 7
第三章 系統需求分析 8
3.1功能性需求分析 8
3.1.1檔案管理 9
3.1.2客戶管理 11
3.1.3消息通知 12
3.1.4郵件管理 13
3.1.5郵件關聯檔案 15
3.1.6系統安全管理 15
3.1.7微信應用端功能需求 16
3.1.8郵件應用端功能需求 17
3.2非功能性需求分析 18
3.3本章小結 19
第四章 系統設計 20
4.1系統總體設計 20
4.1.1系統架構設計 20
4.1.2系統網絡拓撲 21
4.2系統功能模塊設計 22
4.2.1檔案管理功能 23
4.2.2客戶管理功能 25
4.2.3消息通知功能 27
4.2.4郵件管理功能 28
4.2.5郵件關聯檔案功能 29
4.2.6系統安全管理功能 31
4.2.7系統微信應用端功能 32
4.2.8系統郵件應用端功能 35
4.3系統數據庫設計 36
4.3.1數據庫 E-R 圖設計 37
4.3.2數據庫表結構設計 37
4.4系統安全設計 41
4.4.1Web 前端安全設計 41
4.4.2Web 服務端安全設計 42
4.4.3數據庫安全設計 42
4.4.4程序安全設計 42
4.5 本章小結 43
第五章 系統實現 44
5.1系統開發環境 44
5.2系統管理端實現 44
5.2.1檔案管理 44
5.2.2客戶管理 46
5.2.3消息通知 47
5.2.4郵件管理 48
5.2.5郵件關聯檔案 50
5.2.6系統安全管理 51
5.3系統微信應用端實現 52
5.3.1信息注冊和修改 53
5.3.2查詢檔案信息 54
5.3.3接收通知 54
5.4系統郵件應用端實現 55
5.4.1查詢檔案信息 55
5.4.2接收通知 56
5.5系統安全實現 57
5.5.1Web前端安全實現 57
5.5.2Web服務端安全實現 58
5.5.3數據庫安全實現 59
5.5.4程序安全實現 60
5.6本章小結 6 1
第六章 系統測試 62
6.1測試說明 62
6.2功能測試 62
6.3非功能性測試 6 6
6.3.1性能測試 66
6.3.2安全性測試 68
6.3.3穩定性測試 69
6.3.4易用性測試 70
6.4本章小結 70
第七章 總結與展望 71
7.1總結 7 1
7.2展望 7 1
參考文獻 73
攻讀碩士期間的學術成果 76
致謝 77
圖錄
圖 2-1 機構客戶與公眾號的交互過程 7
圖 3-1 系統劃分用例圖 9
圖 3-2 檔案管理功能用例圖 10
圖 3-3 客戶管理功能用例圖 11
圖 3-4 消息通知功能用例圖 12
圖 3-5 郵件管理功能用例圖 14
圖 3-6 郵件關聯檔案功能用例圖 15
圖 3-7 系統安全管理功能用例圖 15
圖 3-8 微信應用端功能用例圖 16
圖 3-9 郵件應用端功能用例圖 18
圖 4-1 系統總體架構圖 21
圖 4-2 系統網絡拓撲圖 22
圖 4-3 系統功能模塊設計圖 23
圖 4-4 檔案管理功能框圖 24
圖 4-5 添加專利檔案流程圖 24
圖 4-6 專利檔案添加功能時序圖 25
圖 4-7 客戶管理功能框圖 25
圖 4-8 添加機構類客戶流程圖 26
圖 4-9 機構類客戶信息添加功能時序圖 26
圖 4-10 消息通知功能框圖 27
圖 4-11 消息預約發送功能時序圖 27
圖 4-12 郵件管理功能框圖 28
圖 4-13 移動郵件功能時序圖 29
圖 4-14 郵件關聯檔案功能框圖 30
圖 4-15 關聯專利檔案流程圖 30
圖 4-16 關聯專利檔案功能時序圖 31
圖 4-17 系統安全管理功能框圖 31
圖 4-18 登錄校驗功能流程圖 32
圖 4-19 登錄校驗功能時序圖 32
圖 4-20 微信應用端功能框圖 33
圖 4-21 信息注冊功能流程圖 33
圖 4-22 信息注冊功能時序圖 34
圖 4-23 查詢檔案信息功能時序圖 35
圖 4-24 郵件應用端功能框圖 35
圖 4-25 查詢檔案信息功能時序圖 36
圖 4-26 知識產權信息管理系統 E-R 圖 37
圖 5-1 著作權檔案管理頁面 45
圖 5-2著作權檔案添加頁面 45
圖 5-3 個人客戶管理頁面 46
圖 5-4 個人信息添加頁面 46
圖 5-5 著作權消息通知頁面 47
圖 5-6 著作權郵件列表頁面 48
圖 5-7 著作權預約郵件編輯頁面 48
圖 5-8 收件箱郵件列表頁面 49
圖 5-9 郵件詳情頁面 49
圖 5-10 寫郵件頁面 5 0
圖 5-11 查看往來郵件功能頁面 50
圖 5-12系統用戶管理頁面 5 1
圖 5-13 登錄校驗代碼圖 5 1
圖 5-14 連接副本集代碼圖 52
圖 5-15網頁授權獲取用戶信息功能實現代碼圖 52
圖 5-16 信息注冊頁面 53
圖 5-1 7查詢著作權檔案信息頁面（微信應用端） 54
圖 5-1 8接收通知頁面（微信應用端） 55
圖 5-19 查詢檔案信息頁面（郵件應用端） 56
圖 5-20 接收通知頁面（郵件應用端） 56
圖 5-21 XSS 防御代碼圖 57
圖5-22 axios請求攔截器代碼圖 58
圖 5-23 Token 校驗中間件函數代碼圖 5 8
圖5-24 nginx配置圖 59
圖 5-25 隨機數改寫文件名效果圖 59
圖 5-26 MongoDB 配置圖 59
圖 5-27 密碼加密存儲代碼圖 60
圖5-28傳輸郵件TLS加密代碼圖 60
圖 6-1 JMeter 測試計劃圖 67
圖 6-2 聚合報告（3 分鐘） 67
圖 6-3聚合報告（5分鐘） 67
圖 6-4 響應時間圖（3 分鐘） 68
圖 6-5 響應時間圖（5 分鐘） 68
圖 6-6 服務端運行情況圖 70
圖 6-7 代碼指標圖 70
表錄
表 4-1 檔案信息表 37
表 4-2 通知書信息表 38
表 4-3 個人客戶信息表 39
表 4-4 系統用戶信息表 39
表 4-5 郵件信息表 40
表 4-6 收件箱郵件信息表 40
表 4-7 預約通知信息表 41
表 5-1 服務器配置信息表 44
表 6-1 登錄校驗功能測試表 62
表 6-2 檔案管理功能測試表 63
表 6-3 客戶管理功能測試表 64
表 6-4 消息通知功能測試表 64
表 6-5 郵件管理功能測試表 65
表 6-6 查詢檔案信息功能測試表 66
表 6-7 MongoDB 連接測試表 69
第一章 緒論
1.1研究背景和意義
全球經濟一體化的背景下，隨著信息技術的高速發展，知識經濟已成為國際 大潮［1］［2］。市場競爭從資本競爭逐漸演變為資本資源、科學技術、經營管理的多 元化競爭。“科教興國”戰略強調了科技創新的重要性，知識產權作為科技創新 成果的載體以及法律保護手段提高了企業的市場競爭力，成為重要的戰略資源。 近年來我國愈發重視知識產權的發展規劃，“十八大”提出實施知識產權戰略、 “十九大”要求強化知識產權保護與運用、“十三五”指導我國由知識產權大國 邁向強國、“十四五”強調提高科技創新成果轉化率等，這些頂層設計文件旨在 建立健全知識產權體系，確立中國特色知識產權戰略［3］。
在國家政策的促進作用下，知識產權申請數量如雨后春筍般快速增長，由于 缺少相關法律知識與經驗，部分企業與高校選擇將知識產權申請工作委托給代理 機構［4］，這對代理機構的知識產權檔案信息管理能力提出了更高的挑戰和要求。 目前大部分代理機構使用以電子表格為中心的管理方式［5］，使用郵件作為與機構 客戶的主要溝通手段。這種管理方式與溝通手段的缺點如下：
（1）表格信息冗長，管理信息過多（知識產權檔案名稱、申請號、申請日、 申請人、發明人、公開日等）導致信息不直觀。
（2）檔案更新不及時，被動式更新會帶來更新滯后或者遺漏等問題。
（3）郵件通知方式的消息到達率與查看率不穩定。
（4）郵件與檔案無關聯，工作人員需要在郵件與檔案管理應用間頻繁切換。
面對大量知識產權檔案信息，這種自動化程度低的管理方式效率低下并伴隨 著失誤的隱患。因此需要引入一套系統對知識產權檔案進行信息化管理，提高工 作效率與溝通效率。
目前市面上已有一些知識產權信息管理軟件，調研后發現這些軟件普遍存在 著功能單一的缺陷，一個軟件只解決了一個問題［6］，單單針對知識產權管理的軟 件，不包含消息通知功能，仍然需要代理機構知識產權信息管理人員手動推送消 息。還有部分軟件集成0A系統，學習使用成本較高，購買費用高昂，對于中小 型知識產權代理機構不友好，泛用性有待提高。
集成 Webmail 的知識產權信息管理系統的提出與設計實現正是基于上述現 狀，本系統利用微信龐大的用戶群體和微信公眾平臺的模板消息功能。受制于微 信模板消息內容格式標準，郵件這種內容不受限制并且可以留檔的通信方式可以 彌補微信通知的不足，因此選用 Webmail 這種基于 B/S 架構而非客戶端/服務器 (Client/Server, C/S)架構的郵件技術⑺同。郵件與檔案建立關聯使得工作人員 既能在查看郵件時知曉相關檔案信息，又能在查看檔案時了解此檔案的往來郵件 信息。代理機構的知識產權信息管理人員可以通過本系統對知識產權檔案進行從 受理到授權再到維護的全生命周期管理，提高工作效率；機構客戶可以通過發送 郵件或者微信公眾號查詢的方式來獲取檔案最新進展，本系統會自動回復特定格 式的查詢郵件，使溝通更加便捷及時，實現了機構與客戶高效的信息交互。
1.2國內外研究現狀
由于發達國家較早擁有完善的知識產權管理制度，這些國家對知識產權管理 系統的研究和開發應用都早于國內［9］［10］。美國早期的 CPI 專利管理系統就已經支 持復合條件檢索、自動推算期限、歸類統計等功能；DocketExpress專利管理系統 具有可定制繳費提醒、雙向追蹤、報告生成等功能；TEAS商標信息管理系統提 供多手段查詢、線上/線下申請、自動回復注冊請求等服務； C0RDS 電子注冊記 錄系統涵蓋版權登記、注冊、檢索等功能［11］，此外還有 PatentWizard、 Epoline 等 知識產權管理系統。這些系統實現了知識產權的申請起草、歸檔、檢索、分析的 一站化管理［12］［13］。
近幾年來，隨著我國經濟的高速發展以及知識產權保護政策的大力實施推進， 知識產權管理系統的研究已經取得長足的進展，但整體上與發達國家還是有差距。 就專利而言，大部分知識產權代理機構依然使用EXCEL電子表格結合CPC (專 利電子申請客戶端)的方式來管理專利信息，這種管理方式存在自動化程度不高、 低效率高失誤等問題。因此市面上出現了一些知識產權信息管理軟件，相關代表 有：
(1)EPC專利電子申請客戶端，可與CPC進行關聯。EPC實現了客戶管 理、案卷管理、文件管理、通知書管理、費用管理等功能。 EPC 功能繁多并且使 用免費。缺點是集成度較低，功能模塊離散不利于協同辦公，繁多的功能帶來便 利同時增加了軟件學習使用難度，此外EPC還存在著版本功能升級慢、兼容性 差、技術支持弱等問題。
(2)IPLINE知識產權信息管理系統，實現了對知識產權的全生命周期管理, 具有期限報警、安全管理、統計分析等功能，并且該軟件有C/S架構和B/S架構 兩種版本，兼容性好。缺點是費用高昂、缺乏客戶交互能力。
此外還有彼速之星、啟服云、智慧芽、紅堅果等軟件。經調查分析，這些管 理軟件產品存在同質化現象，功能大同小異，基本都能對知識產權進行全生命周 期管理，但是考慮到中小型為主的代理機構群體，這些管理軟件存在解決問題單 一、費用高昂等問題［14］。
1.3研究內容和創新點
1.3.1研究內容
本文在對比國內外常見知識產權信息管理系統的基礎上，結合現有知識產權 代理機構的知識產權信息管理需求，設計并實現了一套基于B/S架構的集成 Webmail 的知識產權信息管理系統。本系統主要面向知識產權代理機構的信息管 理人員以及機構客戶。系統分為管理端、微信應用端、郵件應用端以及服務端。 管理端主要面向代理機構信息管理人員；微信應用端與郵件應用端主要面向機構 客戶；服務端搭建于Linux環境，功能是與MongoDB數據庫連接并進行相關操 作，并且負責與管理端、微信服務器、郵件服務器通信。本文研究內容為實現界 面友好、功能完備、安全穩定、集成度高的系統。下面對系統特點進行詳細說明：
(1)界面友好：頁面布局合理，便于操作。信息錄入方式多樣化；表單校 驗提示信息醒目；使用語義性強的圖標；操作體驗符合行業使用習慣；危險操作 需二次確認。
(2)功能完備：機構的信息管理人員可以在管理端對知識產權檔案、客戶、 郵件等信息進行管理，使用消息通知功能向機構客戶推送微信模板消息以及郵件， 相應的，機構客戶使用微信應用以及郵件應用接收來自管理端的消息通知或查詢 名下檔案信息，此外，機構客戶還可以通過微信應用注冊/修改自己的信息。
(3)安全穩定：系統內存儲大量檔案以及用戶信息，信息的泄露或遺失會 給機構以及客戶帶來重大影響，因此需要從 Web 前端、 Web 服務端、數據庫等 方面保證系統安全。
(4)集成度高：為了優化業務流程、節省管理成本，將管理端功能模塊集 成整合在一個 Web 前端頁面上并實現模塊間的數據共享。在檔案管理模塊可以 看到此檔案相關的消息通知以及來往郵件；在消息通知模塊上可以看到相關檔案 詳細信息；在郵件管理模塊可以看到此郵件關聯的檔案信息等。
在集成 Webmail 的知識產權信息管理系統的開發過程中，本人主要完成以 下工作：
(1)系統需求分析：與某中小型知識產權代理機構溝通了解行業現狀與實 際業務需求，結合分析市面上成熟的知識產權信息管理系統優點，確定系統需求。
(2)系統設計與實現：根據需求分析的結果，將系統劃分成各個功能模塊 進行設計并使用相關技術實現，涉及Vue.js、Express.js、微信公眾號開發等技術； 設計并搭建數據庫；設計并實現系統安全。
(3)系統測試：對實現的系統進行測試，以保證系統可以提供安全可靠的 服務。
1.3.2創新點
本系統創新性體現如下：
(1)系統集成B/S架構的Webmail，可以直接關聯知識產權檔案信息，不 需要切換應用即可查詢檔案信息或者郵件，簡化了代理機構的檔案郵件管理與郵 件通知等業務流程，提高了工作效率。
(2)利用微信龐大的用戶群體與微信公眾號開發跨平臺的特性，提高了開 發效率。微信通知相比郵件通知方式，具有更高的通知消息的到達率以及查看率， 微信應用端提供給機構客戶自助查詢檔案信息的入口，使機構與客戶之間的信息 交互更智能便捷。
1.4論文結構
本文分為七個章節，每章內容概括如下：
第一章，緒論。本章分析了集成 Webmail 的知識產權信息管理系統的研究背 景意義，結合國內外知識產權信息管理系統發展現狀，對研究內容以及創新點進 行說明，并在該章末尾介紹了論文的組織結構。
第二章，相關技術研究。本系統使用的技術有 Vue.js、 Express.js、 MongoDB、 微信公眾號開發、 Webmail 等，本章對這些技術與理論知識進行簡單分析和闡述。
第三章，知識產權信息管理系統需求分析。本章基于代理機構知識產權信息 管理人員的實際需求，將系統需求劃分為管理端需求、微信應用端需求以及郵件 應用端需求，確定了系統各個模塊的功能性需求，并對系統整體的非功能性需求 進行分析和闡述。
第四章，知識產權信息管理系統設計。本章從系統架構和網絡拓撲出發，將 系統功能模塊劃分為管理端功能模塊、微信應用端功能模塊以及郵件應用端功能 模塊，并對各個功能模塊進行詳細分析設計，最后對數據庫以及系統安全進行設 計。
第五章，知識產權信息管理系統實現。本章對系統管理端、微信應用端以及 郵件應用端的各個功能的實現進行描述，同時對系統安全的實現進行說明。
第六章，知識產權信息管理系統測試。本章首先對系統各個功能模塊進行功 能性測試，然后測試系統的性能以及安全穩定性等指標，測試結果表明本系統可 以提供穩定可靠的服務。
第七章，總結與展望。本章總結本文完成的工作，并指出系統需要改進之處。
第二章 相關技術研究
2.1Vue.js 框架
Vue.js （以下簡稱Vue）是一種前端框架。Vue基于MVVM （Model-View - ViewModel）架構［15］，實現了視圖（View）和模型（Model）的分離，使用觀察 者這一設計模式，視圖的變化通過 ViewModel 使模型同步發生變化，并且模型 的變化也會通過ViewModel來觸發視圖的更新，Vue對每個DOM操作進行了封 裝，并提供給開發者相應的指令，以上特點大量減少了開發者的直接DOM操作， 使開發者更關注于數據邏輯，減少了系統代碼量，降低了系統開發維護成本［16］［17］。
2.2Express.js 框架
Express.js［18］（以下簡稱 Express）是基于 Node.js （以下簡稱 Node）的 Web 服務端應用框架。Node在服務端中的高并發、I/O密集場景里表現較好，具有部 署輕量、開發輕量的特點［19］。
Express 的社區生態較好，下載量在所有基于 Node 的 Web 服務端應用框架 里居第一位。使用 Express 可快速搭建一個服務端應用， Express 內部集成了服務 器模塊、路由模塊、處理請求模塊、靜態資源訪問模塊等，這些模塊都屬于中間 件， Express 特有的線性中間件模型實現了不同需求使用不同中間件處理，方便 解耦，使開發更加靈活高效，同時提高了系統的可擴展性。
2.3MongoDB 數據庫
MongoDB［20囑于非關系型數據庫（Not Only SQL，NoSQL），由C++語言編 寫，基于分布式文件存儲，是NoSQL［21 ］里文檔數據庫的代表之一，具有數據結 構無需預定義、數據可嵌套、擴展性高、表達豐富等特點［22］。文檔是 MongoDB 的基本單元模型。并且MongoDB支持主從復制以及創建副本集操作，有利于數 據災備、恢復。Mongoose為Node中的一個模塊，封裝了 Node原生的MongoDB 模塊的API，使之符合JavaScript的開發習慣，開發者可以使用Mongoose在Node
環境下對 MongoDB 進行更便捷的操作。
2.4Webmail
Webmail［23］提供了一種基于B/S架構的電子郵件服務，主要使用Web瀏覽器 來閱讀和發送電子郵件，又區別于基于 C/S 架構的有電子郵件客戶端的服務， Webmail不需要下載和配置對應的郵件客戶端，只需要Web瀏覽器即可，解決了 不同的設備以及操作系統帶來兼容性的問題。閱讀和發送電子郵件的過程涉及 imap［24］、smtp［25］協議。
2.5微信公眾號開發
微信公眾號為微信公眾平臺簡稱，按運營主體可劃分為訂閱號和服務號。訂 閱號主要提供消息傳播服務，運營主體為個人；服務號的主要提供業務交互能力， 運營主體為企業［26］。訂閱號無法使用高級接口，服務號需要經過認證后才可使用 高級接口［27］。本系統需要使用到的接口有：網頁授權獲取用戶基本信息（以下簡 稱網頁授權）、模板消息等。由于模板消息和網頁授權接口屬于高級接口，本系 統選擇使用認證后的服務號。機構客戶與公眾號交互過程如圖 2-1 所示。
圖 2-1 機構客戶與公眾號的交互過程
2.6 本章小結
本章介紹了知識產權信息管理系統的實現過程中使用的相關技術，從系統前 端框架Vue開始,介紹了服務端Node環境以及Express框架，然后介紹MongoDB 和Webmai 1，最后介紹微信公眾號開發技術以及公眾號交互過程。
第三章 系統需求分析
3.1功能性需求分析
經過調研機構信息管理人員的業務需求，結合市面上知識產權信息管理系統 的實際操作體驗，我們確定了本系統的業務需求如下：
(1)機構信息管理人員可以對知識產權檔案基本信息進行增刪改查操作， 可以修改知識產權檔案生命周期以及查看檔案關聯的郵件。
(2)機構信息管理人員可以對機構客戶信息進行增刪改查等操作。
(3)機構信息管理人員可以預約、撤回、修改需要推送的微信模板消息以 及郵件。
(4)機構信息管理人員可以接收、回復、移動、刪除、編輯并發送郵件， 可以查看郵件所關聯的檔案信息并跳轉。
(5)機構客戶可以通過微信公眾號來注冊修改用戶信息、查詢名下知識產 權檔案信息、接收來自機構信息管理人員預約發送的微信模板消息。
(6)機構客戶可以通過郵件應用來查詢名下知識產權檔案信息、接收來自 機構信息管理人員預約發送的郵件。
(7)檔案信息和客戶信息是對外保密的，因此Web安全、數據庫安全是需 要保證的，其次需要考慮邊界情況和每個功能模塊的互相影響來確保系統完備性， 同時在界面展示、系統操作上做到人性化以兼顧用戶體驗。
本系統主要為機構信息管理人員以及機構客戶提供服務。系統角色按職能分 為三類：系統管理員、機構信息管理人員、機構客戶。下面介紹各個角色作用：
a)系統管理員：負責管理賬號權限、維護系統安全、處理系統故障。
b)機構信息管理人員：負責機構知識產權檔案信息、客戶信息、郵件信息 的管理，以及向機構客戶預約發送通知消息。
c)機構客戶：可以通過微信公眾號注冊或者修改個人信息，查詢檔案信息 以及最新進展，也可以通過郵件應用查詢檔案信息及最新進展。
結合以上業務需求分析和業務角色分析結果，我們確定了系統組成：管理端、
微信應用端、郵件應用端、服務端。管理端供系統管理員和機構信息管理人員使 用，微信應用端和郵件應用端供機構信息管理人員和機構客戶使用，服務端負責 管理端、微信應用端、郵件應用端之間的交互。系統劃分用例圖如圖 3-1 所示。
圖 3-1 系統劃分用例圖
3.1.1檔案管理
結合調研代理機構信息管理人員實際業務需求的結果，我們將機構需要納入 系統進行管理的知識產權檔案分為三類：專利檔案、著作權檔案、商標檔案。檔 案管理功能用例圖如圖3-2所示。
檔案管理
^檔案添加^
'包含J〔二H案信息修改 包含＞＞•__
專利檔案管二一《包含一…c檔案查詢
、'«包含汽二建案生命周期修改 (查看檔案相關郵件 檔案添加^
«包含 ＞＞-二貞案信息修改) 二三:;包含二＜3案刪除＞ 著作權檔案管叮二?包含一…©檔案查詢二
、'«包含》、二遭案生命周期修改 (查看檔案相關郵件 檔案添加) 檔案信息修改＞
圖 3-2 檔案管理功能用例圖
下面以專利檔案為例分析檔案管理業務的功能：
( 1)專利檔案添加 代理機構接收到專利申請時，審核通過后可添加專利檔案的詳細信息到數據 庫。
(2)專利檔案信息修改 當添加至數據庫中的專利檔案信息部分有誤時，需要修改錯誤信息并更新。
( 3)專利檔案刪除 當出現誤添加操作或者無效檔案時，需要刪除該檔案信息來保證數據庫沒有 冗余檔案。為防止誤刪除操作需要二次確認。
（4） 專利檔案查詢 系統內專利檔案數量較多，機構信息管理人員可以通過專利名稱、檔案編號、
申請人、申請日等信息進行復合檢索。
（5） 專利檔案生命周期修改 來自國家知識產權局的新的通知書到達意味著專利檔案的生命周期需要更
新，機構信息管理人員以添加通知書的方式修改專利檔案的生命周期。
（6） 查看專利檔案相關郵件 專利檔案與郵件關聯之后，機構信息管理人員可以快速查看專利檔案下相關
的往來郵件。
3.1.2客戶管理
根據代理機構信息管理人員的實際需求，我們將客戶分為兩類：機構類客戶、 個人客戶。委托人為高校或者企業的客戶為機構類客戶，個人客戶則是非高校或 者企業的個體委托方。客戶管理功能用例圖如圖 3-3 所示。
圖 3-3 客戶管理功能用例圖
下面以機構類客戶為例分析客戶管理業務的功能：
（1）機構類客戶添加
代理機構接收到來自機構類客戶的知識產權申請時，審核通過后可添加客戶 的詳細信息到數據庫。
（2）機構類客戶修改 當添加至數據庫中的機構類客戶信息部分有誤時，需要修改錯誤信息并更新。
（3）機構類客戶刪除 當出現誤添加操作或無效客戶信息時，需要刪除機構類客戶信息來保證數據 庫沒有冗余客戶信息。為防止誤操作需要二次確認。
（4）機構類客戶查詢 系統內機構類客戶數量較多時，機構信息管理人員可以通過機構類客戶名稱 等信息進行查詢。
3.1.3消息通知
機構信息管理人員利用消息通知功能以微信模板消息和郵件的方式對機構
下面分析消息通知業務的功能：
（1）預約發送微信模板消息和郵件 機構信息管理人員從檔案通知書記錄表里選擇通知書后，系統會合并同類型 通知書同聯系人的消息，然后生成對應的微信模板消息和郵件，在預約的時間發 送給機構客戶。
（2）撤回微信模板消息和郵件
預約的微信模板消息和郵件未發送時可以撤回此次消息通知，此功能一般用 于預約誤操作。
（3）編輯微信模板消息和郵件 預約的微信模板消息和郵件未發送時可以編輯微信模板消息的內容、郵件正 文、郵件附件等信息。
（4）預約發送消息時需要填寫的信息有：消息內容、委托人、預約日期， 需要上傳通知書文件作為郵件附件。
3.1.4郵件管理
系統需要引入 Webmail 進行郵件管理，使郵件與檔案相關聯，方便代理機構 信息管理人員在查看郵件或者檔案信息時獲取另一側的內容。郵件管理功能用例 圖如圖 3-5 所示。郵件管理功能可分為：寫郵件、收件箱管理、草稿箱管理、發 件箱管理、自定義文件夾管理這些子模塊。
下面分析郵件管理業務的功能：
（1）移動郵件 把某封郵件從一個文件夾移動到另一個文件夾。收件箱和發件箱之間不允許 互相移動。
（2）標記/取消標記郵件 標記某封郵件為星標郵件或者取消星標郵件的標記，標記不觸發移動操作， 在星標郵件列表可集中訪問。
（3）刪除郵件 把某封郵件移入“已刪除”文件夾。為防誤操作需要二次確認。
（4）存入草稿
把正在編輯的郵件存入草稿箱中。
（5）編輯郵件
在寫郵件模塊編寫郵件或在草稿箱繼續編輯郵件，需要填寫的信息有：收件
人郵箱、抄送人郵箱、郵件主題、正文、附件，使用到此功能的模塊需要提供客 戶列表供點選以快速填寫收件人/抄送人郵箱信息。
（6）發送郵件
將編輯好的郵件發送出去。
（7）查看關聯檔案
郵件和檔案關聯后，機構信息管理人員查看郵件時，界面顯示相關檔案的內 容并提供跳轉至檔案的按鈕。
郵件管理
係記/取消標記郵件
收件箱管理
3.1.5郵件關聯檔案
郵件關聯檔案功能是本系統創新點之一。知識產權信息管理系統收取郵件時，
如果郵件標題或者正文包含檔案編號信息，系統將該郵件與檔案相關聯并存入數
據庫，機構信息管理人員在郵件管理頁面可以查看關聯檔案信息，也可以在檔案
圖 3-6 郵件關聯檔案功能用例圖
3.1.6系統安全管理
知識產權信息管理系統內存儲大量知識產權檔案，需要對系統安全進行管理
來防止知識產權信息的泄露與丟失。系統安全管理功能用例圖如圖3-7所示。
圖 3-7 系統安全管理功能用例圖
下面分析系統安全管理業務的功能：
（1） 權限管理 每個登錄系統的賬號都有各自的權限集，只允許系統管理員進行權限集的分
配。
（2） 用戶管理 系統管理員對每個登錄系統的賬號進行管理，添加、刪除、修改密碼等操作。
（3）登錄校驗 登錄系統時系統對賬號密碼進行校驗，校驗通過后才可以使用管理端。為了 方便機構信息管理人員的使用，登錄成功后服務端頒發具有有效期的Token，在 有效期內訪問管理端無需重新輸入賬號密碼。
（4）數據維護 數據庫是系統的基礎與核心，存儲著知識產權信息數據，數據庫出現問題會 給機構帶來重大損失。賬號密碼不能以明文形式存儲在數據庫中，同時還需要做 好數據的備份和恢復。
3.1.7微信應用端功能需求
微信應用端的使用者為機構客戶、機構信息管理人員。主要負責機構與機構
客戶之間的信息交互（通過微信公眾號）。微信應用端功能用例圖如圖 3-8 所示。
圖 3-8 微信應用端功能用例圖
下面分析微信應用端的功能：
（1）信息注冊 機構客戶通過微信公眾號向機構注冊自己的身份信息。如果是機構類客戶， 需要填寫機構名稱、組織代碼、委托人郵寄地址、委托人聯系電話、委托人聯系 郵箱。如果是個人客戶，需要填寫個人郵寄地址、個人聯系電話、個人聯系郵箱， 微信 OpenID 由微信公眾號的網頁授權接口自動獲取，以上信息與管理端里客戶 管理的信息一致。
（2）信息修改
客戶除微信 OpenID 以外的信息發生變更時，可在微信公眾號內修改信息。
（3） 檔案信息查詢 客戶可以通過微信公眾號來查詢名下的知識產權檔案信息。
（4） 接收通知 客戶通過微信公眾號接收來自管理端預約發送的微信模板消息通知。
3.1.8郵件應用端功能需求
郵件應用端的使用者為機構客戶、機構信息管理人員。主要負責機構與機構 客戶之間的信息交互（郵件方式）。郵件應用端功能用例圖如圖 3-9 所示。
下面分析郵件應用端的功能：
（1） 檔案信息查詢 機構客戶可以通過發送郵件的方式來查詢名下的知識產權檔案信息。
（2） 接收通知 機構客戶通過注冊信息里的聯系郵箱接收來自管理端預約發送的郵件通知。
圖 3-9 郵件應用端功能用例圖
3.2非功能性需求分析
（1）性能
知識產權信息系統主要使用者為機構信息管理人員與機構客戶。為了保證二 者的用戶體驗，訪問人數在50人以下時響應時間不應超過3s,訪問人數超過50 人時響應時間應控制在 5s 以內。結合機構實際業務需求，約定系統最多可支持 70 人并發使用。
（2）安全性
知識產權信息管理系統內存儲大量檔案信息與客戶信息，這些信息一旦泄露 或遺失，可能會給使用機構帶來不良影響。因此需要保證系統的安全性，涉及到 安全方面有：防XSS攻擊、防CSRF攻擊、防MongoDB注入攻擊等。
（3） 穩定性
機構信息管理人員是知識產權信息管理系統的高頻使用者，機構信息管理人 員的使用體驗也取決于系統穩定性，因此在一定時間內，系統需要保證無故障運 行。
（4） 易用性
知識產權信息管理系統需要達到易于操作使用的目標，界面簡潔美觀，按鈕 圖標除了需要做到功能一目了然，還要加上 Title 屬性。除了使用操作方便，系 統還需要考慮到不同終端的用戶群體，微信公眾號內置頁面需要適配移動端各種 機型，系統所有界面在各操作系統以及瀏覽器的表現要求一致。
3.3本章小結
本章完成了知識產權信息管理系統的需求分析，將系統劃分為管理端、微信
應用端、郵件應用端和服務端，通過UML[28]用例圖分析了角色和功能之間的關
系，并確定了非功能性需求。
第四章 系統設計
4.1系統總體設計
本系統結合市面上知識產權信息管理軟件調研結果以及知識產權代理機構 的實際業務需求進行開發，依賴于移動互聯網。本節對系統架構設計以及系統網 絡拓撲進行闡述。
4.1.1系統架構設計
架構設計的目標是實現一個可重用、可擴展、高內聚低耦合的系統［29］。知識 產權信息管理系統可分為：表現層、業務邏輯層、數據訪問層，各層之間通過接 口來進行數據交互，分層有利于系統的維護和擴展。在橫向上按照功能將系統劃 分為子模塊。下面對每層進行詳細分析：
（1）表現層
表現層是距離用戶最近的一層，一般指與用戶交互的界面，負責數據的輸入 與顯示等。表現層決定了用戶體驗深度，在設計上需要達到界面友好、操作便捷 的目標。表現層主要包括微信應用端的微信公眾號頁面、管理端頁面、郵件應用 端頁面（由對應的郵件服務商實現），微信公眾號頁面依賴于微信內置瀏覽器， 管理端頁面依賴于 Web 瀏覽器。微信公眾號頁面與業務邏輯層的交互需要通過 微信服務器作為中轉。郵件應用端頁面與業務邏輯層的交互需要通過郵件服務器 作為中轉，與微信公眾號頁面不同的是，與郵件服務器的通信方式不是HTTP協 議而是IMAP和SMTP協議。管理端頁面與業務邏輯層的交互，除了郵件管理功 能需要郵件服務器作中轉，其余都是以HTTP的方式直接進行通信。
（2） 業務邏輯層 知識產權信息管理系統的所有業務功能都在業務邏輯層實現，包括檔案管理、
客戶管理、消息通知、郵件管理、郵件關聯檔案、系統安全管理等。該層負責表 現層和數據訪問層的信息交互，是系統的核心。
（3） 數據訪問層
數據訪問層的作用是對知識產權信息管理系統的數據進行處理，本系統選用 MongoDB 作為數據庫，實現檔案數據、客戶數據、郵件數據等數據的存儲。在 Node 環境下使用 Mongoose 模塊來對 MongoDB 里的數據進行增刪查改，簡化了 操作。
系統的總體架構如圖 4-1 所示。
數據訪問層
數據層「MongoDB
系統軟硬件資源
圖 4-1 系統總體架構圖
4.1.2系統網絡拓撲
系統整體基于移動互聯網，機構客戶主要通過微信 APP 或者微信 Web 版（瀏 覽器訪問）使用本系統微信應用端的功能，通過電子郵件客戶端或者 Webmail 使 用本系統郵件應用端的功能，使用終端為智能手機或者pc。機構信息管理人員 需要使用PC來訪問本系統管理端Web頁面。
系統網絡拓撲圖如圖 4-2 所示。
4.2系統功能模塊設計
知識產權信息管理系統劃分為管理端、微信應用端、郵件應用端以及共同的 服務端。管理端包含檔案管理模塊、客戶管理模塊、郵件管理模塊等功能模塊。 微信應用端包含信息注冊模塊、信息修改模塊、接收通知模塊等功能模塊。郵件 應用端包含接收通知模塊、查詢檔案信息模塊。
系統功能模塊設計圖如圖4-3所示。
管理端的使用對象為機構信息管理人員和系統管理員。機構信息管理人員主 要使用檔案管理、客戶管理、消息通知、郵件管理、郵件關聯檔案等功能，系統 管理員主要使用系統安全管理功能。下面逐一分析每個功能設計：
4.2.1檔案管理功能
機構信息管理人員可以使用管理端的檔案管理功能進行添加檔案信息、查詢 檔案信息、修改檔案信息、修改檔案生命周期、刪除檔案信息、查看檔案關聯郵 件等操作。根據機構實際業務需求，知識產權檔案分為專利、著作權、商標三類。 檔案管理功能框圖如圖 4-4 所示。
圖 4-5 添加專利檔案流程圖
以專利檔案添加為例，圖4-5展示了實現該功能的業務流程。首先知識產權
信息管理人員登錄管理端頁面，進入檔案管理頁的專利檔案模塊，執行檔案添加
操作，填入知識產權檔案的各個基礎字段信息后系統對所填字段進行校驗，校驗
通過后將檔案信息存入數據庫，校驗未通過時需要修改字段直到校驗通過。專利
檔案添加功能時序圖如圖 4-6 所示。
圖 4-6 專利檔案添加功能時序圖
4.2.2客戶管理功能
機構信息管理人員可以使用管理端的客戶管理功能對客戶信息進行增刪改 查等操作。客戶根據委托人類別劃分為機構類客戶和個人客戶。客戶管理功能框 圖如圖 4-7 所示。
圖 4-9 機構類客戶信息添加功能時序圖
以機構類客戶信息添加為例，圖 4-8 展示了實現該功能的業務流程。首先知 識產權信息管理人員登錄管理端頁面，進入客戶管理頁的機構客戶管理模塊，然 后點擊“新建機構”按鈕，填入機構類客戶的各種信息后系統對所填字段進行校 驗，主要校驗郵箱電話是否合法，校驗通過后將客戶信息存入數據庫，校驗未通 過時需要修改客戶信息直到校驗通過。機構類客戶信息添加功能時序圖如圖 4-9
所示。
4.2.3消息通知功能
機構信息管理人員可以使用管理端的消息通知功能向機構客戶預約推送微
信模板消息和郵件，預約消息發送后保存發送記錄。若預約過程中出現了誤操作，
可以使用消息通知模塊的撤回或編輯消息功能。消息通知功能框圖如圖 4-10 所 示。
消息通知
圖 4-10 消息通知功能框圖
以預約發送消息為例，預約發送消息功能時序圖如圖 4-11 所示。知識產權 信息管理人員登錄管理端頁面，進入消息通知頁的消息通知模塊，在檔案的通知 書記錄列表中選中一個或多個通知書，填寫消息內容和委托人以及預約發送日期， 并上傳通知書，點擊“預約發送”按鈕后，消息通知模塊使用MongoDB的聚合 管道功能將同類通知書同委托人同時間的預約消息先合并再分組最后生成的微 信模板消息和郵件存到預約消息表里，預約消息表里的微信模板消息和郵件可修 改或撤回，到預約的時間，查詢當天要發送的預約消息并發送。
4.2.4郵件管理功能
機構信息管理人員可以使用管理端的郵件管理功能進行寫信、移動郵件等操 作。郵件管理功能框圖如圖 4-12 所示。
郵件管理
圖 4-12 郵件管理功能框圖
圖 4-13 移動郵件功能時序圖
以收件箱管理功能中的移動郵件為例，收件箱移動郵件功能時序圖如圖 4 13 所示。知識產權信息管理人員登錄管理端頁面，進入郵件管理頁的收件箱管 理模塊，收件箱管理模塊使用 IMAP 協議從郵件服務器拉取郵件，點擊移動至某 個文件夾，收件箱管理模塊判斷目的文件夾是否合法(收件箱和發件箱的郵件之 間不能互相移動)，若合法，收件箱管理模塊使用 IMAP 協議向郵件服務器請求 移動郵件，隨后重新拉取郵件并更新數據庫的郵件表信息；若不合法，則取消此 次移動操作。
4.2.5郵件關聯檔案功能
管理端的郵件關聯檔案功能會根據知識產權檔案編號將郵件與知識產權檔 案綁定。二者建立關聯后，機構信息管理人員在查看郵件時可以看到對應知識產 權檔案信息，同理在查看知識產權檔案信息時可以知曉該案件往來郵件情況。根 據知識產權檔案類型，郵件關聯檔案功能模塊劃分為關聯專利檔案、關聯著作權 檔案、關聯商標檔案三個子功能模塊。郵件關聯檔案功能框圖如圖 4-14 所示。
郵件關聯檔案
圖 4-14 郵件關聯檔案功能框圖
以關聯專利檔案為例，圖 4-15 展示了該功能的業務流程。知識產權信息管 理人員登錄管理端頁面，進入郵件管理頁面，郵件管理模塊拉取郵件信息后，關 聯專利檔案模塊根據郵件標題或正文里提及的專利檔案編號去數據庫查詢對應 相應檔案，若查詢沒有結果，關聯結束；若有結果則將郵件與檔案進行綁定并更 新數據庫的專利檔案信息與郵件信息。關聯專利檔案功能時序圖如圖4-16所示。
圖 4-16 關聯專利檔案功能時序圖
4.2.6系統安全管理功能
系統管理員可以使用系統安全管理功能來實現權限管理、用戶管理、登錄校 驗、數據維護。其中登錄校驗功能也面向機構信息管理人員，系統安全管理功能 框圖如圖 4-17 所示。
系統安全管理
圖 4-17 系統安全管理功能框圖
以登錄校驗為例，圖 4-18 展示了該功能的業務流程。機構信息管理人員在 管理端登錄頁進行登錄操作后，登錄校驗模塊依次執行用戶查詢以及密碼校驗操 作。登錄校驗時序圖如圖 4-19 所示。
圖 4-18 登錄校驗功能流程圖
機構信息管理人員 ■ 系統登錄頁面 系統管理主頁面 1 登錄校驗模塊 數據庫
圖 4-19 登錄校驗功能時序圖
4.2.7系統微信應用端功能
微信應用端的表現層為微信公眾號頁面，主要使用者為機構客戶，機構客戶
可以使用微信應用端進行信息注冊、信息修改、查詢檔案信息、接收通知等操作。 微信應用端功能框圖如圖 4-20 所示。
微信應用端
圖 4-20 微信應用端功能框圖
一）信息注冊功能
圖 4-21 信息注冊功能流程圖
圖 4-21 展示了信息注冊的業務流程。使用預約發送消息功能的前提是數據
庫中存有用戶微信和郵件的聯系方式，微信OpenlD和電子郵件地址是不可缺少 的。微信OpenlD的獲取的主要方式為機構客戶在微信應用端進行信息注冊，本 系統利用微信服務號高級接口中的網頁授權接口獲取客戶的微信OpenlD，電子 郵件地址由機構客戶在微信公眾號里的注冊頁面填寫。信息注冊功能模塊對必填 信息以及郵件地址進行校驗，校驗通過后將客戶信息存入數據庫。信息注冊功能
時序圖如圖 4-22 所示。
圖 4-22 信息注冊功能時序圖
（二） 信息修改功能 信息修改功能與信息注冊功能相似，此處不再贅述。
（三） 查詢檔案信息功能 機構客戶可以利用微信應用端的檔案信息查詢功能隨時隨地查詢自己名下
的檔案信息與最新通知書消息。機構客戶進入查詢檔案信息頁面，同信息注冊與 修改，調用接口獲取用戶OpenID后根據OpenID去數據庫查詢相關檔案信息， 最后將結果展示在微信公眾號的查詢檔案信息頁面上。圖 4-23 為查詢檔案信息 功能的時序圖。
圖 4-23 查詢檔案信息功能時序圖
（四）接收通知功能 機構客戶使用接收通知功能可以第一時間獲取來自管理端預約發送的微信 模板消息。此功能為微信公眾號提供，故不再贅述設計過程。
4.2.8系統郵件應用端功能
郵件應用端
圖 4-24 郵件應用端功能框圖
郵件應用端的表現層為郵件應用頁面，主要使用者為機構客戶，機構客戶可 以使用郵件應用端進行查詢檔案信息、接收通知等操作。郵件應用端功能框圖如 圖 4-24 所示。
（一）查詢檔案信息 機構客戶可以通過發送郵件的方式自助查詢自己名下的檔案信息。機構客戶 發送按約定規則編寫的查詢郵件后，查詢檔案信息模塊監聽到新郵件到達且經特
定規則判斷為查詢郵件后，使用發件人郵件地址以及要查詢的檔案編號（郵件標 題提取）查詢數據庫，獲取結果后回復郵件。查詢檔案信息功能時序圖如圖 4-25
所示。
圖 4-25 查詢檔案信息功能時序圖
（二）接收通知 機構客戶通過接收通知功能可以第一時間獲取來自管理端預約發送的郵件。
此功能為郵件服務商提供，故不再贅述設計過程。
4.3系統數據庫設計
數據庫設計是系統開發中的必不可少的環節。從知識產權代理機構的實際業 務以及數據需求出發，我們將系統中涉及的數據以及數據之間的關系先抽象再規 范化、結構化。好的數據庫設計有利于系統后續的維護擴展，提高系統效率和性 能，降低系統開發成本。 MongoDB 的弱一致性提升了數據訪問與寫入速度， MongoDB 的文檔結構自由，支持數據的嵌套，避開了扁平化表結構數據帶來的 查詢、讀取、寫入上的困難，并且知識產權信息管理系統對事務的要求不嚴格， 最終選擇 MongoDB 作為本系統的數據庫。
經過實際數據需求分析，我們需要對專利檔案信息、著作權檔案信息、機構 類客戶信息、個人客戶信息、收件箱信息、草稿箱信息、發件箱信息、自定義文 件夾信息、預約通知信息、系統用戶信息等數據表進行設計。
4.3.1數據庫 E-R 圖設計
在分析各個信息的數據庫表之間的關聯關系后，各個數據庫表之間的實體關 系如圖 4-26 所示。
4.3.2數據庫表結構設計
使用e-r[30]圖對數據實體關系分析后，我們接下來對每個數據信息表進行表 結構設計。由于我們使用MongoDB作為數據庫，每個表會有一個自動生成且具 有唯一性的“」d”字段作為主鍵。“」d”的數據類型為Objectld。
（1）檔案信息表
檔案信息分為專利檔案、著作權檔案、商標檔案三種，這三種表除了個別字 段有區別，大部分字段是一樣的。考慮到檔案信息表是讀寫頻率最高的表，表結 構設計要謹慎：將讀寫頻率高的字段放在表外層，將讀寫頻率低的內嵌字段以內 嵌對象或內嵌數組的形式置于表中，對于與其他表共用的數據采取引用的方式。 檔案信息表如表4-1所示。
表4-1檔案信息表
名稱 中文含義 數據類型 補充說明
_id ObjectId 主鍵，自動生成
PID 檔案編號 String 代理機構分配
名稱 中文含義 數據類型 補充說明
fileTitle 檔案名稱 String
subType 檔案子類型 String 枚舉值，專利、商標、
著作權擁有各自的子類
型
applicantID 檔案申請號 String 國家知識產權局分配
applicant 檔案申請人 String
IPinventor 知識產權發明人 String
consignerName 委托人姓名 ObjectId 弓1用客戶信息表的」d
consignerEmail 委托人郵箱 ObjectId 弓1用客戶信息表的」d
consignerWID 委托人微信
OpenID ObjectId 弓1用客戶信息表的」d
applicantDate 檔案申請日 Date
noticeRecord 通知書記錄 Array 對象數組，對象類型是 通知書
relateMail 往來郵件記錄 Array 數組元素為郵件id
notes 備注 String
通知書記錄為對象數組形式，表 4-2 對通知書信息表進行介紹。
表 4-2 通知書信息表
名稱 中文含義 數據類型 補充說明
_id ObjectId 主鍵，自動生成
noticeType 通知書類型 String 枚舉值，專利、商標、
著作權擁有各自的通知
書類型
postDate 通知書發文日 Date 國家知識產權局發文日
deadlineDate 通知書截止日 Date 國家知識產權局規定回
復截止日
notes 備注 String
2）客戶信息表
客戶信息表分為機構類客戶信息表和個人客戶信息表。信息錄入方式有兩種， 一種為機構信息管理人員在管理端頁面錄入，委托人微信OpenlD需要機構客戶 提供，客戶可以通過微信公眾號自動回復功能來獲取自己的微信OpenlD；另一
種方式為客戶在微信公眾號的信息注冊頁錄入，微信OpenlD獲取方式為調用網 頁授權接口。個人客戶信息表如表 4-3 所示。
表 4-3 個人客戶信息表
名稱 中文含義 數據類型 補充說明
_id ObjectId 主鍵，自動生成
consignerName 個人姓名 String
consignerEmail 個人郵箱 String
consignerWID 個人微信 String 客戶在微信應用端獲取
OpenID
consignerPhone 個人電話 String
company 所在單位 String
addr 個人地址 String
（3）系統用戶信息表
系統用戶分為系統管理員以及機構信息管理人員兩種，二者區別體現在權限 上。系統用戶信息表如表 4-4 所示。
表 4-4 系統用戶信息表
名稱 中文含義 數據類型 補充說明
_id ObjectId 主鍵，自動生成
userName 系統用戶名 String
userPWD 密碼 String select 屬性設置為 false
使密碼無法查看
rightList 權限集 Array 數組元素為各模塊權 限，枚舉值
lastLoginDate 上次登錄時間 Date
4）郵件信息表
郵件信息表除了存儲收件箱、草稿箱、發件箱、自定義文件夾信息外，還存 儲郵箱地址、郵箱密碼、郵件簽名模板等信息，具體信息如表4-5所示。自定義 文件夾可以無限級嵌套，因此用對象數組存儲自定義文件夾扁平化后的子文件夾 郵件信息。
表 4-5 郵件信息表
名稱 中文含義 數據類型 補充說明
_id ObjectId 主鍵，自動生成
email 郵箱 String
emailPWD 郵箱密碼 String 加密后存儲， select 屬 性設置為 false 使密碼 無法查看
mailSignTpl 郵件簽名模板 String 用于寫郵件時自動補充
簽名
inboxMail 收件箱 Array 對象數組，對象類型為
收件箱郵件
draftMail 草稿箱 Array 對象數組，對象類型為 草稿箱郵件
sentMail 發件箱 Array 對象數組，對象類型為
發件箱郵件
customizeMail 自定義文件夾 Array 對象數組，對象類型為
子文件夾
表 4-6 以收件箱郵件為例，介紹單封郵件信息。
表 4-6 收件箱郵件信息表
名稱 中文含義 數據類型 補充說明
_id ObjectId 主鍵，自動生成
mailID 郵件 ID String 使用 IMAP 模塊獲取郵件
時的郵件uid
from 發件人郵箱列表 Array 數組元素為發件人郵箱
to 收件人郵箱列表 Array 數組元素為收件人郵箱
cc 抄送人郵箱列表 Array 數組元素為抄送人郵箱
date 郵件發送日期 Date
subject 郵件主題 String
isStar 是否標記 Boolean
attachments 附件列表 Array 數組元素為附件存儲地址
relateFileList 關聯檔案列表 Array 數組元素為檔案」d
（5）預約通知信息表
預約通知信息表的設計如表4-7所示。機構信息管理人員預約發送微信模板 消息與郵件后，預約信息會存入該表，在預約時間到達前，可以修改微信模板消 息內容和郵件內容等信息。
表 4-7 預約通知信息表
名稱 中文含義 數據類型 補充說明
_id ObjectId 主鍵，自動生成
consignerName 聯系人姓名 String
consignerWID 聯系人微信
OpenID String
noticeType 通知書類型 String 枚舉值
to 收件人郵箱列表 Array 數組元素為收件人郵箱
cc 抄送人郵箱列表 Array 數組元素為抄送人郵箱
subject 郵件主題 String
attachments 附件列表 Array 數組元素為附件地址
contentWXTPL 微信模板消息內容 String
appointmentDate 預約發送日期 Date
msgTag 預約發送狀態 Number 枚舉值， 0 已撤回
1 未發送， 2 已發送
4.4系統安全設計
知識產權信息管理系統存儲大量知識產權檔案、客戶、與郵件等重要信息。 在信息時代，信息這種虛擬財產幾乎與人民幣等價，因此信息安全具有舉足輕重 的地位。下面分別從Web前端安全、Web服務端安全、數據庫安全、程序安全 這四個方面進行系統安全設計。
4.4.1Web 前端安全設計
Web前端攻擊方式主要有XSS （跨站腳本攻擊）、CSRF （跨站點請求偽造） 等。下面一一分析各種攻擊以及相應的防御：
（一） XSS
XSS［31 ］本質上是HTML的注入，用于顯示或提交的數據被當作HTML代碼 來執行，影響了 HTML原本的語義［32］。本系統前端使用Vue框架，屬于MVVM 架構，相對于MVC架構，Vue減少了編碼操作，降低了 XSS攻擊風險，然而還 有部分指令例如“v-html”以及富文本編輯器的安全需要重視，本系統使用Node 的 xss 模塊進行防御。
（二） CSRF
csrf［33］主要利用用戶登錄態在黑客網站發起危險請求，因此需要保證 cookie安全，本系統的身份驗證基于Token而非cookie，系統前端的大部分請求 使用攜帶Token令牌的方式防御CSRFo
4.4.2Web 服務端安全設計
本系統使用nginx作為Web服務器，對nginx進行相關安全配置：隱藏nginx 版本號防止針對某個版本的漏洞攻擊、添加訪問IP黑白名單、限制請求方法拒 絕DELETE等可能改變服務器資源的請求方法等。
本系統會使用到文件上傳的功能來上傳郵件附件，針對文件上傳漏洞需要做 出對應的防御：使用隨機數更改文件名混淆可執行文件。
4.4.3數據庫安全設計
數據庫安全是核心，一旦數據庫里的數據泄露或遺失，特別是商業私密內容 的泄露，會給使用者帶來不可逆轉的損失。MongoDB設置只允許服務端訪問， 禁止外網直連，并設置管理員賬號密碼，此外MongoDB使用副本集［34］使數據在 多個MongoDB服務器之間同步，提高了數據安全性和容災能力。
4.4.4程序安全設計
系統管理員添加系統用戶時檢測密碼強度，不允許低強度密碼；請求會修改 數據的接口時進行Token校驗；系統用戶密碼以及郵箱密碼先加密后存儲；使用 IMAP、SMTP協議與郵件服務器通信時開啟TLS［35］保證郵件信息安全。
4.5本章小結
本章從系統架構和系統網絡拓撲出發確定系統整體設計，然后使用框圖等對 系統功能模塊進行分析設計，最后對系統數據庫以及系統安全設計進行闡述。
第五章 系統實現
5.1系統開發環境
知識產權信息管理系統需要對服務器進行環境配置。服務器詳細配置信息如
表 5-1 所示。
表 5-1 服務器配置信息表
項目 詳細配置
CPU 八核 Intel(R) Xeon(R) E5-2650(@2.00GHz)
內存 16G
硬盤 1T HDD
操作系統 CentOS Linux
Linux 64 位 Linux 3.10.0
Web 服務器 Nginx 1.16.1
數據庫 MongoDB 4.0.12
5.2系統管理端實現
系統管理端功能主要有：檔案管理、客戶管理、消息通知、郵件管理、郵件 關聯檔案、系統安全管理。上一章對以上功能進行分析設計，下面介紹各功能的 具體實現。
5.2.1檔案管理
檔案管理為本系統的核心功能之一，主要提供了知識產權檔案信息的添加、 修改、刪除、查詢、更改生命周期、查看相關郵件的操作方法。下面以著作權檔 案管理為例對檔案管理的實現進行介紹說明。著作權檔案管理頁面主頁面以表格 形式展示所有著作權檔案信息。可以根據標題搜索著作權檔案，也可以使用復合 檢索多條件進行著作權檔案查詢，表格可以根據檔案編號以及最新通知書時間進 行順序或倒序查看，表格展示檔案編號、作品名稱、登記號、登記人、最新通知 書時間、最新通知書信息。機構信息管理人員可以在操作欄可以進行編輯基礎信
息、刪除、關聯郵件、修改檔案生命周期操作，鼠標懸浮在每個操作按鈕上時會 顯示該操作名稱，方便機構信息管理人員理解。點擊表格左側三角符號展示著作 權檔案詳細信息。下方顯示著作權數量以及當前頁數，可進行頁面跳轉。著作權 檔案管理頁面如圖5-1所示。
圖 5-1 著作權檔案管理頁面
知識產權信息管理系統 檔案 iO 郵件 客服 系統 客戶 wchxu©
新建善蝕 酈 個人
Q
\\
.作品名稱 XXX詩
誼⑥入正編8孵6芻稱 A525
xxx^a
刼號
同S1A內容
謝UMS 入內容
甜獻昭 詁輸入內容
委托人OpenlD 內容
申詩日 < 1
備江
圖 5-2 著作權檔案添加頁面
著作權添加操作如圖5-2所示。著作權添加頁可以進行著作權的錄入操作。
右側為機構類客戶和個人客戶列表展示，支持搜索。檔案編號以及作品名稱為必 填項，點擊保存時系統對所填信息進行校驗。通過點擊右側個人或機構列表可以 快速填寫委托人姓名、郵箱、微信 OpenID 信息。
5.2.2客戶管理
客戶管理功能服務于檔案管理與消息通知，機構信息管理人員可以使用此功
能添加、修改、編輯、查詢客戶信息。個人客戶管理頁面如圖 5-3 所示。
圖 5-3 個人客戶管理頁面
個人客戶管理頁面以表格形式展示所有個人客戶信息。可以根據姓名來查找 相關個人信息。操作欄可以進行編輯以及刪除操作，同檔案管理頁，鼠標懸浮在 每個操作按鈕上時會顯示該操作名稱。個人信息添加頁面如圖 5-4 所示。在個人 信息添加頁面可以進行個人信息錄入操作，點擊保存時系統會對所填信息進行校 驗。
圖 5-4 個人信息添加頁面
5.2.3消息通知
消息通知功能為機構提供了與客戶通信的手段。機構信息管理人員除了可以 預約發送微信模板消息與郵件，還可以撤回或編輯已預約但未發送的微信消息與 郵件。預約消息的功能依賴于 node-schedule 模塊：到達設定的每天預約發送的 時間時，查詢預約通知信息表里的需要當天發送的微信模板消息與郵件并調用相 關接口發送出去。下面以著作權消息為例介紹，著作權消息通知頁面如圖 5-5 所 示。
圖 5-5 著作權消息通知頁面
機構信息管理人員通過點擊左側的通知書記錄來填充消息內容，當有復數個 委托聯系人時可以進行復選操作。通知書記錄信息有內容、發文日期、截止日期 和備注。已預約的消息會進入中間欄的消息記錄列表中，消息記錄列表有內容、 發送日期、接收該消息的委托聯系人、消息發送狀態這些信息。已預約但未發送 的消息可以進行撤回操作。已預約的微信模板消息和郵件會進入左側郵件預約和 微信模板消息列表中，機構信息管理人員可以在發送前對預約消息進行修改。圖 5-6 為著作權預約郵件預約列表頁面。
圖 5-6 著作權郵件列表頁面
機構信息管理人員可以在郵件預約列表頁對已預約郵件進行修改和刪除，刪 除即此次消息通知不發送郵件。圖5-7為預約郵件編輯頁面，在此頁面可以對自
動生成的預約郵件的信息進行編輯和保存。
圖 5-7 著作權預約郵件編輯頁面
5.2.4郵件管理
郵件管理是集成Webmail的結果。知識產權信息管理人員不需切換至郵件
應用就可以對郵件進行發送、接收、移動、刪除、查看關聯檔案等操作。收件箱
郵件列表頁面如圖 5-8 所示。
圖 5-8 收件箱郵件列表頁面
左側側邊欄為用戶各個郵箱文件夾信息，其中以“>”開頭的為自定義文件 夾，“>”符號的個數代表此文件夾所在層數。該頁面展示收件箱內郵件的發件人、 郵件主題、收件日期信息，機構信息管理人員可以對郵件進行查看關聯檔案以及 移動、刪除、標記操作。標記后的郵件可在星標郵件列表里查看，移動操作的目 的文件夾默認值是當前文件夾，可下拉選擇移動至除發件箱外的任意文件夾，點 擊“關聯”可查看此郵件的關聯檔案信息。點擊任意一封郵件可以進入郵件詳情 頁，圖 5-9 為郵件詳情頁。
圖 5-9 郵件詳情頁面
在郵件詳情頁可以進行回復操作，右側為關聯檔案的信息，機構信息管理人 員可以點擊“轉至檔案”按鈕跳轉至檔案詳情。
寫郵件頁如圖 5-10 所示。右側展示機構類客戶與個人客戶信息，點擊可快 速填寫收件人或抄送人郵箱信息，正文部分根據機構信息管理人員事先設置的簽 名模板自動填充。本頁還提供了存草稿箱的按鈕，可將未完成的郵件存入草稿箱， 用戶可以在草稿箱里繼續編輯郵件。
圖 5-10 寫郵件頁面
5.2.5 郵件關聯檔案
圖 5-11 查看往來郵件功能頁面
郵件關聯案件功能在獲取郵件時自動執行，作用是將原本不相干的檔案與郵
件聯系起來，是本系統的核心功能之一。圖 5-9 已展示了郵件側查看關聯檔案功 能，檔案側查看往來郵件功能的實現如圖 5-11 所示。管理人員不需要在郵件應 用與檔案管理應用之間切換以查詢對應信息。郵件關聯檔案功能是檔案管理中查 看檔案相關郵件功能與郵件管理中查看關聯檔案功能的實現前提。點擊查看郵件 詳情即可跳轉至郵件詳情頁，亦可在郵件詳情頁跳轉回來。
5.2.6系統安全管理
系統安全管理功能包括用戶管理、權限管理、登錄校驗與數據維護。可以使 用系統用戶管理功能修改密碼或刪除系統用戶信息。系統用戶管理頁信息如圖 5 12 所示。
圖 5-12 系統用戶管理頁面 此功能只開放給系統管理員，即圖中 root 用戶。系統管理員可以查看系統用 戶上次登錄時間。
登錄校驗過程在上一章已進行設計，圖5-13為具體代碼實現。
router.post('/login', async (req, res) => {
const { username, password } = req.body
//1.根據用戶名找用戶
const user = ah/ait AdminUser.findOne({ username })?select('+password') assert(user, 422,，用戶不存在') // 2 •校驗密碼
const isValid = require('bcryptjs')?compareSync(password, user.password) assert^sValid, 422,'榕碼錯誤迪 // 2•返回tohwn生成token需要秘鑰,防止客戶端篡改
//const iat = moment()?u/7ix0
const token = jwt?sign({ id: user?_id, username: user?username }, privateKey); res?send({ token, rightList: user?rightList });
});
圖 5-13 登錄校驗代碼圖
數據維護部分主要涉及數據的備份與恢復，通過添加副本集的方式實現， 本
系統數據庫一共有三個節點，一旦主節點下線，剩下其中一個從節點會升級為新 的主節點。圖 5-14 為連接 MongoDB 副本集代碼。“//”協議符號后面是訪問數據 庫用戶名以及密碼，“@”符號后面三段url為三個副本集，“authSource”后面的 參數為訪問“msjbakDb”數據表的密碼，“replicaSet”后面的參數為副本集名稱。
const mongoose = require('mongoose'); module?exports = app => {
ct也'mongodb://msjbakUser:if
+ H JF" p=n: 1438,'
+ My.com.cn: 1438*
+ '/msjbakDb?airthSource=、.■ i&replicaSet=f
useNewllrlParser: true, useUnifiedTopology: true, useCreatelndex: true, useFindAndModify: false
圖 5-14 連接副本集代碼圖
5.3系統微信應用端實現
〃查詢用戶名下檔案信息
if (req.query.code && req.query.ex === 'l')—
if (req.quEry.code && rEq.query?cx === *2')
r //拼接網頁授權請剝『I
vm『url = 'https://api.weixin.qq.com/sns/oauth2/access_token?' + 'appid=' + config.appTD + '&secret=' + config.appsecret + '&code=' +
req ?query.codm + '&gra rrt_type=authorization_codE‘
//使用重定向回系統服務器后附帶的code參數為求微信服務器,靜默授權方式
vm『msgdata = await rp({url})
//微信服務器返回用戶包含opENd屬性的對象
\/日『obj = 3S0N?parse(msgdata)
//査詢該op^工d名下所有著作權檔案信息并使用ejs渲染模板渲染數據返回網頁 vm『data = await Copy『ight.firKl({ consignerWTD: obj.openid }) if (data.length != 0)
1 //名下有著作權檔案時顯示檔案信息
res.send(ejs?「ender(tp]_4{ data:dat日}))
else
'//名下無著作權檔案時顯示無檔案信息
res. send (ejs. render (tpl_5))
L a '
if (『^q.qy?code && 「Eq.query?cx === 13')—
圖 5-15 網頁授權獲取用戶信息功能實現代碼圖
微信應用端的功能實現基于微信公眾號開發技術。注冊服務號且完成企業認
證之后可以使用服務號高級接口。系統微信應用端中的信息注冊、信息修改、查 詢檔案信息這三個功能基于網頁授權獲取用戶信息接口；接收通知功能基于微信 模板消息接口。以查詢機構客戶名下著作權檔案信息為例，網頁授權過程代碼實 現如圖5-15所示。網頁授權使用的是OAuth2.0[36]方式，獲取用戶信息步驟如下：
（1） 微信公眾號開發平臺里將系統微信應用端頁面域名設置為授權回調域 名。
（2） 用戶在微信環境下訪問信息注冊、信息修改、查詢檔案信息網頁。用 戶同意授權后可獲取 code。
（3） 系統服務端使用 code 作為參數向微信服務器發起請求換取用戶 OpenID。
5.3.1信息注冊和修改
4：19 :：!! W 重＞
X 信息注冊 —
*姓名
*郵箱
公司
電話
郵寄地址
注冊
圖 5-16 信息注冊頁面
信息注冊頁面如圖 5-16 所示。信息注冊是微信應用端所有功能的基礎，系
統獲取了用戶OpenlD信息之后，機構客戶才可以使用信息修改、查詢檔案信息、
接收提醒等功能。點擊微信公眾號菜單可進入信息注冊頁。其中姓名和郵箱為必
填項。信息修改實現與信息注冊相似，此處不再贅述。
5.3.2查詢檔案信息
2：47 ：!!'令
X 著作權 -
L著作權名稱：測試作品
申請號:1234567
通知內容：受理通知書
下達時間：2020-09-15
截止日期：
通知內容：補正通知書
下達時間:2020-09-16
截止日期：
通知內容：發證通知書
下達時間：2020-09-22
截止日期：
通知內容：軟件著作權證書
下達時間：2020-09-28
截止日期：
通知內容：作品登記證書
下達時間：2020-10-01
截止日期：
通知內容：測試通知書
下達時間：2020-10-12
截止日期：
圖 5-17 查詢著作權檔案信息頁面（微信應用端）
查詢檔案信息功能為機構客戶開放了自助查詢名下知識產權檔案的通道。在 微信公眾號菜單欄里包含查詢專利檔案、查詢著作權檔案、查詢商標檔案三個入 口。以查詢著作權為例，本小節開頭處圖 5-15 已展示部分代碼實現，查詢著作 權檔案信息頁面如圖 5-17 所示。
5.3.3接收通知
機構客戶注冊信息后，即可使用接收通知功能。機構信息管理人員預約發送
微信模板消息后，機構客戶可在微信應用端接收到相應微信模板消息。接收通知 頁面如圖5-18所示。
3：12 :：!• -9* QD-
< 麥其資訊0 A
下午3：12
著作權進度提醒
9月14日
尊敬的趙2、趙3先生/女土：
我司已收到新的1件通知書 受理通知書
案件編號：
ZJ0924-1
著作權名稱：
測試作品
申請人：
趙1
詳細內容請您查看通知系統
@ =微信通知 麥其小店 麥其介紹
圖 5-18 接收通知頁面（微信應用端）
5.4系統郵件應用端實現
系統郵件應用端功能以及管理端郵件管理功能實現基于 Node 的 imap 模塊 與 nodemailer 模塊，前者負責“拉”郵件，后者負責“推”郵件。 imap 模塊使用 IMAP 協議拉取郵件服務器上的郵件到本地進行管理，并且移動郵件、刪除郵件 等操作可以同步到郵件服務器。nodemailer模塊使用SMTP協議與郵件服務器進 行通信以發送郵件。
5.4.1查詢檔案信息
郵件應用端的查詢檔案信息功能為機構客戶提供了另一個查詢檔案信息的 入口。機構客戶按約定編寫固定格式的查詢郵件，郵件應用端會輪詢收件箱信息，
出現新增郵件并且經判斷為查詢郵件時自動回復相關檔案信息。圖 5-19 為查詢
檔案信息在郵件應用端的實現效果。
發件人：吳 1 <1 L,_^£=aggi™ni>
時間：2021-09-16 17:48:30
收件人：test < testa ■* iu__
圖 5-19 查詢檔案信息頁面（郵件應用端）
5.4.2接收通知
eKH(4
圖 5-20 接收通知頁面（郵件應用端）
接收通知郵件效果如圖 5-20 所示。機構客戶在郵件應用端接收通知的方式 為郵件。
5.5系統安全實現
5.5.1Web 前端安全實現
在上一章已對系統安全進行設計，前端安全部分涉及 XSS、CSRF 等。下面 一一介紹相關實現：
（一） XSS
對于“v-html”指令與富文本編輯器的安全都可以使用“XSS模塊+白名單” 的方式實現，以富文本編輯器為例，圖5-21為xss防御代碼實現。
import xss from 'xss'
this.edito「.config?onchange = （html） => 口
const options = {
//設置白名單標簽以及屬性
whiteList: { | img: [wsrc*\ ,,title,\ "target''],
const myxss = new xss ?匸：111：0廠乂55（0卩tions）;
//按照白名單過濾富文本編輯器內容
let filterHtml = myxss.processChtml）;
this.info_ = filterHtml; //綁定當前逐漸地值
//將內容丙步到父組件％
this?$emit（"change"$ this.info_）;
I h; -
圖 5-21 XSS 防御代碼圖
（二） CSRF
本系統使用Token校驗的方式來防御CSRF攻擊，Token生成與校驗使用到 jsonwebtoken[37]模塊，Token于第一次登錄或Token過期時生成，詳見圖5-13內 倒數第三行代碼。Token存于瀏覽器的Local Storage，前端每次發起請求時使用 axios 攔截器將 Token 置于 HTTP 自定義請求頭，服務端編寫相應 Token 校驗中 間件函數對Token進行校驗，相關代碼如圖5-22與圖5-23所示。
// axios請求攔截器
http.intwrceptors?request?use(function(config) {
// Do something before request is sent
if (localstorage?token) {
// Authorization為自定義請求頭
config.headers.Authorization = 'Bearer ' + localstorage?token
return config;
}j function(error) {
// Do something with request error return Promise?reject(error);
}); ■
圖 5-22 axios 請求攔截器代碼圖
module.expoTts = options => 口
const assert = require('http-assert');
const jwt = require(*jsonwebtoken，);
const privateKey = * JF i'；
const AdminUser = require('??/models/adminuser *);
return async (req, res, next) => {
H轉為字符串、分割、提取最后一個元素
const token = String(req?headers.authorization || '，)?split(' ').pop(); 〃滿足token,錯誤碼Q, messagg請先登錄 assert (token, 401,'請先登錄')； //使用私鑰對token進行校驗有無cd屬性
const { id } = jwt.verify(token, privateKey);
assert(id? 401 ? ■請先登錄’)；
“eq.user = await AdminUser.findByld(id);
assert(req.user, 401, ■請先登錄’)； await next();
圖 5-23 Token 校驗中間件函數代碼圖
5.5.2Web 服務端安全實現
有關 nginx 的相關安全配置如圖 5-24 所示。文件上傳漏洞采取隨機數改變
文件名的方式避開，上傳附件后由于改變文件名阻斷訪問，極大地增加了攻擊成 本。文件名改寫效果如圖 5-25 所示。
location / {
root /usr/wsjbak/admin;
.index index.html index.htm: .
| add_header x-Frame-options deny'; |
add header Access-Control-Allow-Origin *;
add_header Access-control-Allow-Methods 'get, post, options'}
add_header Access-Control-Allow-Headers 'DNT,x-Mx-Re<iToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
if ($request_method = * OPTIONS') { return 204;
圖 5-24 nginx 配置圖
▼ Name Size (KB)
0 bYbkYiWlplpDa7a5faqq_oN5.jpg 246
0 CN-NcTbKapv;3_wEeRH-jcLv8.jpg 246
固 dsSAmAAv^MOBtdHO-LMaOD7BV.... 412
回 JrEFVH?L7genXd5Sbkgg8FJl.png 16
回 0ESLMgBD8vfP-CuZS5c5r8v0.pdf 412
上0
@ Zmmymdc8USmkulnc5sAvgshJ.jpg 229
圖 5-25 隨機數改寫文件名效果圖
5.5.3數據庫安全實現
三個用作副本集的服務器的 MongoDB 的配置文件 mongod.conf 如圖 5-26 所
示。端口號不設置為常用的27017的原因是防掃描，bindip設置為服務端邏輯
DNS主機名，只允許服務端訪問，保證數據庫的安全，設置副本集以實現數據的
備份與恢復。
port: 1438
bindip: . ' ■ com.cn
auth： true
■Fork： true
dbPath: /var/lib/mongo
replSetName: foxway
圖 5-26 MongoDB 配置圖
5.5.4程序安全實現
Token 校驗的實現如圖 5-22、圖5-23 所示，此處不再贅述。密碼加密存儲的 代碼實現如圖 5-27 所示。郵件傳輸過程中開啟 TLS 加密以保證郵件傳輸安全， 相關代碼如圖5-28所示。
const mongoose = require('mongoose')
const schema = new mongoose?Schema({ usernam { type: String, unique: true }, userPWD: {
type： String， select: false, //使密碼無法查看 set(val) {
return require('bcryptjs').hashSync(val, 12)
rightList:[],
lastLoginDate: { type: Date
module.exports = mongoose?model('AdminUser', schema)
圖 5-27 密碼加密存儲代碼圖
function createTransporter(user)
const type = use「?email.match(mailReg)[1]; return nodemailer? createTransport({
auth: {
user: user.emai].,
pass: user.emailpw,
function creatlmap user^
const type = user.emai/.match(mailReg)[1]; return new Imap({
user: user.email, password: user host: 'imap?${
port: 992,
tls: true,
})；
圖 5-28 傳輸郵件 TLS 加密代碼圖
5.6本章小結
本章從開發環境配置開始，逐步介紹了系統管理端、微信應用端以及郵件應
用端各個功能的實現。最后從Web前端安全、Web服務端安全、數據庫安全以 及程序安全四個方面實現系統整體安全。
第六章 系統測試
6.1測試說明
測試貫穿整個知識產權信息管理系統開發。在系統投入正式使用前，我們需 要根據實際需求從各個方面對系統進行功能性測試和非功能性測試，以發現并修 正系統中存在的錯誤與不足，使系統更加完善。
6.2功能測試
功能測試從實際需求出發，對系統每個部分功能編寫測試用例來保證系統功 能符合要求。功能測試屬于黑盒測試［38］，即不考慮系統代碼結構與實現，輸入各 種測試用例，對比預期輸出結果與實際輸出結果是否一致。
（1 ）登錄校驗
所有使用本系統的人員首先要經過登錄校驗，不同角色的權限集不一樣。測 試前使用系統管理員賬號添加一個用戶名和密碼分別為adminTest與qwer1234@ 的系統用戶。登錄校驗的測試如表 6-1 所示。
表 6-1 登錄校驗功能測試表
測試功能 登錄校驗
補充說明 校驗通過后正確返回 Token 并存入瀏覽器 Local Storage，
Token過期前登錄無需再輸入賬號密碼
(2)檔案管理功能測試
檔案管理功能測試如表6-2所示。
表 6-2 檔案管理功能測試表
測試功能 檔案管理
測試人員 機構信息管理人員
測試目的 測試各類型知識產權檔案管理功能是否正常
a) 進行檔案添加/修改信息操作
b) 進行檔案修改生命周期操作
測試內容 c) 查看檔案關聯郵件并跳轉至郵件詳情
d) 復合檢索查詢檔案信息
e) 進行檔案刪除操作
a) 填入信息完整且合法時，添加/修改成功；不完整或不 合法時，添加/修改失敗
預期結果 b) 檔案生命周期修改成功
c) 顯示相關郵件信息并正確跳轉
d) 顯示符合檢索條件的檔案信息
e) 彈出二次確認窗口，點擊確認后刪除檔案
實際結果 與預期結果一致
結論 檔案管理功能、郵件關聯檔案功能正常
3)客戶管理功能測試
客戶分為機構類客戶以及個人客戶，每種類型客戶依次進行添加、修改、查 詢、刪除操作，同時在微信應用端模擬機構客戶進行注冊、修改信息操作。客戶 管理功能測試如表 6-3 所示。
表6-3客戶管理功能測試表
測試功能 客戶管理
測試人員 機構信息管理人員
測試目的 測試各類型客戶管理功能是否正常
a)進行客戶添加/修改信息操作
b)進行客戶查詢操作
測試內容
c)進行客戶刪除操作
d)機構客戶在微信應用端進行注冊/修改信息操作
a)填入信息完整且合法時，添加/修改成功；不完整或不 合法時，添加/修改失敗
b)顯示符合查詢條件的客戶信息
預期結果
c)彈出二次確認窗口，點擊確認后刪除客戶信息
d)填入信息完整且合法時，注冊/修改成功；不完整或不 合法時，注冊/修改失敗
實際結果 與預期結果一致
結論 客戶管理功能、微信應用端注冊與修改信息功能正常
(4)消息通知功能測試 模擬機構信息管理人員在管理端執行預約發送微信模板消息與郵件、編輯消 息、撤回消息操作，同時可測試微信應用端與郵件應用端的接收通知功能，消息 通知功能測試如表6-4所示。
表 6-4 消息通知功能測試表
測試功能 消息通知
測試人員 機構信息管理人員、機構用戶
測試目的 測試系統消息通知功能是否完善
a) 預約消息
測試用例 b) 預約消息，在發送前編輯微信模板消息與郵件并保存
c) 預約消息，在發送前撤回消息
測試功能 消息通知
a） 到達預約時間，機構客戶收到微信模板消息與郵件
b） 到達預約時間，機構客戶收到編輯后的模板消息與郵
預期結果 件
c） 預約消息不會發送，機構客戶無法收到消息
實際結果 與預期結果一致
管理端的消息通知功能、微信與郵件應用端接收消息通知
結論 功能均正常
（5）郵件管理功能測試
模擬機構信息管理人員對各類型郵件文件夾執行移動、標記、查看關聯檔案、 刪除操作，并執行寫郵件發郵件操作。郵件管理功能測試如表 6-5 所示。
表 6-5 郵件管理功能測試表
成功
件服務商對此文件夾命名不一樣）
測試功能 郵件管理
e)發送成功，另一側可接收到郵件
實際結果 與預期結果一致
結論 郵件管理功能、郵件關聯檔案功能正常
(6)微信、郵件應用端查詢檔案信息功能測試 模擬機構客戶在微信以及郵件應用端查詢檔案信息。此功能測試如表 6-6 所 示。
表6-6查詢檔案信息功能測試表
測試功能 查詢檔案信息
測試人員 機構客戶
測試目的 測試機構客戶是否可以在微信郵件端查詢到名下檔案信息
a)在微信公眾號查詢檔案信息頁面進行查詢
測試內容
b)向系統綁定郵箱發送標題為“查詢：ABC-01 ”的郵件
a)若名下有知識產權檔案信息則顯示詳細信息；若無檔 案信息則顯示“名下暫無專利/著作權/商標檔案信息”
b)若名下有檔案編號為“ ABC-01 ”的檔案信息，系統自
預期結果
動回復一封內容為此檔案詳細信息的郵件；反之，系 統自動回復一封內容為“查詢不到檔案編號為 ABC- 01”的郵件。
實際結果 與預期結果一致
結論 微信、郵件應用端查詢檔案信息功能正常
6.3非功能性測試
6.3.1性能測試
性能測試的目的是檢測系統在一定壓力下是否可以正常工作，有關性能的兩 個重要指標分別為每秒事務數[39] (Transactions Per Second， TPS)以及事務響應
時間（Transaction Response Time， TRT）。本系統使用基于 Java 的 Apache JMeter[40][4i]這一測試工具進行測試。如圖6-1所示，首先加上Token頭信息來模 擬管理端登錄態，然后模擬出三種訪問系統服務端接口的線程組：機構信息管理 人員的管理端、機構客戶的微信應用端和郵件應用端。管理端主要使用獲取郵件、 檔案、客戶信息三種接口；微信應用端主要訪問信息注冊以及查詢檔案信息接口； 郵件應用端使用頻率最高的接口為查詢檔案信息接口。管理端創建 10 個子進程 來模擬10個機構信息管理人員，微信應用端以及郵件應用端各創建30個子進程 來模擬 60 個機構客戶，此時系統并發數約 70，子進程任務設置為向接口發起 HTTP請求，循環次數設置為無限。圖6-2和圖6-3為3分鐘以及5分鐘的聚合 報告。
A測試計劃
X HTTP請求默認值
X token頭信息
"聚合報吉
4察看結果樹
V建菅理端-機構信息管理人員
/管理端-獲取郵件信息接口
/管理端-獲取檔案信息接口
Z管理端-獲取客戶信息接口
V建｝微信應用端-機構客戶
/微信應用端-用戶信息注冊接口
/微信應用端-查詢檔案信息接口
V <•｝郵件應用端-機構客戶
Z郵件應用端-查詢檔案信息接口 d響應時間圖
圖 6-1 JMeter 測試計劃圖
圖 6-2聚合報告（3分鐘）
Label #樣本 平均值 中位數 90%百分位 95%百分位 99%百分位 最小值 最大值 異常％ 呑吐量
郵件應用端 44483 135 118 151 317 390 34 1760 0.00% 147.4/sec
管理狽-獲取... 7350 136 118 152 317 516 40 1032 0.00% 24.4/sec
敬信應用端 20698 156 120 315 327 733 33 6551 0.00% 68.6/$ec
ffl（信應用端-.一 20693 134 118 150 316 333 1 1357 0.00% 68.6/sec
簣理端-獲取... 7342 136 118 153 317 487 36 950 0.00% 24.3/sec
管理報-獲取... 7340 137 118 158 318 361 33 1542 0.00% 24.3/sec
總體 107906 139 118 161 319 517 1 6551 0.00% 357.6/sec
圖中可以看出總吞吐量每秒 350 個左右， 99%的請求響應時間小于 800 毫 秒，平均響應時間為139毫秒，無異常進程。圖6-4和圖6-5為3分鐘以及5分 鐘時的響應時間圖。由圖可推知TRT在120毫秒與170毫秒之間。5分鐘大約完 成 108000 個事務， TPS 在 360 左右。對比圖 6-4 所示三分鐘與圖 6-5 所示五分 鐘的響應時間圖，響應時間整體平穩。
響應時間田
圖 6-4 響應時間圖（3 分鐘）
圖 6-5 響應時間圖（5 分鐘）
6.3.2安全性測試
（ 1 ）數據庫安全
MongoDB 連接測試如表 6-7 所示。測試可知僅在服務端 IP 攜帶正確的連接
參數的情況下才可以連接上MongoDB服務器。隨后模擬MongoDB副本集群主
節點宕掉的情況，經測試從節點會自動升級為主節點，并檢測到原主節點上線后
將原主節點降級為從節點隨后進行數據恢復。
綜上數據庫安全得到保證。
表 6-7 MongoDB 連接測試表
測試功能 MongDB 連接校驗
測試人員 開發人員
測試目的 檢測 MongoDB 連接安全
a) 服務端IP連接，連接參數為正確的用戶名和密碼
測試內容 b) 服務端IP連接，連接參數為正確的用戶名和錯誤密碼
c) 外網IP連接，連接參數為正確的用戶名和密碼
a) 連接成功
預期結果 b) 連接失敗
c) 連接失敗
實際結果 與預期結果一致
結論 MongDB 連接校驗功能正常
( 2) Web 安全
輸入部分的XSS隱患均由Vue框架進行編碼過濾，主要檢測“v-html”指令 與富文本編輯器，經測試腳本標簽以及可能嵌入 XSS 的屬性均已過濾；由于 CSRF針對cookie，本系統未使用cookie而是Token進行身份驗證避免了 CSRF 隱患；其他 Web 安全相關點均已通過測試驗證。
6.3.3穩定性測試
系統服務端為Node環境，故采用PM2進行進程管理。服務端運行情況以及 代碼指標分別如圖 6-6和圖6-7所示。由圖可知，上線五個月后重啟次數與不穩 定重啟次數均為0，HTTP最慢的95%請求平均延遲約為122ms。穩定性符合需 求。
online indexmsjbak default
1.0.0
0
5M
/usr/msjlaw/index_msjbak? j s
N/A
/root/? pm2/logs/index?msjb8k?error?log /root/? pm2/logs/index-msjbak-out ?log
/root/? pm2/pids/index-msjbak-3? pid node
N/A
3
/usr/msjlaw fork_mode
12.16.1
N/A
X
0
2021-04?12T0O:24:35.676Z
圖 6-6 服務端運行情況圖
圖 6-7 代碼指標圖
6.3.4易用性測試
系統管理端頁面使用ElementUI[42]組件庫，組件界面友好，操作反饋明顯且 及時，圖片以及按鈕均設置Title屬性進行功能說明。對于系統頁面兼容性主要 測試 PC 端 Chrome、Firefox 等主流瀏覽器以及移動端 Chrome、Safari 瀏覽器， 經測試在各平臺表現一致。
6.4本章小結
本章對知識產權信息管理系統進行測試，測試結果表明系統可以提供功能完 善且安全可靠的服務。
第七章 總結與展望
7.1 總結
基于知識產權強國與信息技術飛速發展的背景，代理機構傳統的以報表為中 心的信息管理方式已無法滿足日益增長的知識產權申請需求。經調研，報表模式 的痛點有：自動化程度低、失誤率高，結合機構檔案信息管理以及消息通知等各 方面的實際需求，本文設計并實現了集成 Webmail 的知識產權信息管理系統。機 構信息管理人員可以使用此系統對知識產權檔案、客戶、郵件信息進行管理；機 構客戶在注冊信息后可以接收來自機構的消息通知，并且可以查詢自己名下的檔 案信息，本系統提高了知識產權代理機構工作人員的工作效率以及與客戶的溝通 效率。
本文的主要工作內容與成果如下：
（1） 通過分析知識產權信息管理系統的研究現狀以及結合知識產權代理機 構的實際需求，明確了系統功能性需求以及非功能性需求。
（2） 根據需求將系統劃分為管理端、微信應用端、郵件應用端、服務端。 使用框圖等對各個部分功能模塊進行設計分析。然后對數據庫表以及系統安全進 行設計。
（3） 針對每部分的功能設計進行實現，展示了實現界面并簡述使用方法， 對部分實現進行了代碼說明。然后從Web前端、Web服務端、數據庫、程序四 個方面分析系統安全實現。
（4） 對實現的系統功能逐一進行測試，并測試系統性能、安全性、穩定性 以及易用性。測試結果表明本系統可以為知識產權代理機構提供可靠的服務。
7.2展望
本系統開發測試完成后投入實際使用，運行反饋良好，實現了預期需求。由 于本人開發經驗以及技術限制，系統還存在許多不足之處需要完善：
（1）引入插件自動錄入檔案信息。以專利為例，機構信息管理人員需要操 作 CPC 客戶端接收來自國家知識產權局的消息，然后再將消息錄入系統中。此 部分可以編寫插件來進行檔案信息自動導入和更新，使機構信息管理人員專注于 使用本系統進行高效工作。
（2） 支持以 Excel 電子表格形式錄入/導出的檔案信息。引入本系統進行檔 案管理后，代理機構舊的檔案信息存儲在Excel表中，手動遷移舊檔案的方式繁 瑣而且可能出錯，可以引入檔案導入/導出功能解析電子表格并錄入系統數據庫。 代理機構檔案信息如需留檔，可以導出為電子表格形式。
（3） 界面美化。由于系統開發過程中重心主要在功能實現上，有些界面比 較粗糙，后續可以進行優化以提高用戶體驗。
參考文獻
[1]彭晉榮.演化經濟學視角下不確定性與企業發展研究[D].山西大學,2016.
[2]Uchida Hideaki. The big push to a knowledge - based economy with intellectual property rights protection[J]. Review of Development Economics, 2020, 24(4):1551-1559.
[3]卿陶.知識產權保護、技術差距與企業創新[J].產經評論,2021,12(03):38-55.
[4]李光云，劉朝輝.知識產權代理與托管關系初辨[J].云南科技管理,2018, 31(04):24-26.
[5]趙鶴征.大型企業專利管理系統的設計與實現[D].南開大學,2012.
[6]金人杰.知識產權信息管理系統的設計與實現[D].蘇州大學,2016.
[7]Ching-Yu Huang. Integrated Curriculum of Multi-tier Client/Server Web-Based Database Applications[J]. International Journal of Information and Education Technology, 2019, 9(5):318-323.
⑻ 花旭斌.Webmail研究與開發[D].電子科技大學,2006.
[9]LybovAchba, LybovVorona-Slivinskaya, ElenaVoskresenskaya, et al. Current State of Intellectual Property Management and Innovational Development of the Russia[M]. 2020.
[10]朱林.基于B/S模式的專利信息管理系統的設計與實現[D].東南大學,2018.
[11]王玉剛，王哲，陳曄，劉偉峰.國防知識性產權信息平臺構建研究J].中國設 備工程, 2017(06):148-149.
[12]Patent Selections[J]. Recent Patents on Computer Science, 2018, 11(2):238-243.
[13]李詩樂.商標管理信息系統的設計與實現[D].電子科技大學,2020.
[14]曹偉宸.集團企業知識產權管理系統設計與實現[D].湖南大學,2017.
[15]Liang H. Research on Mobile Web Front-end Display Scheme Based on MVVM Architecture[J]. China Computer & Communication, 2019.
[16]Paul Krill. Vue.js 3.0 brings more speed, more TypeScript[J]. InfoWorld.com, 2020.
[17]Li M, Hu J, Lin X. The Development of Web Application Front-End of Intelligent
Clinic Based on Vue.js[M], 2020.
[18]Simon, McManus. Write maintainable web apps with express[J]. Net, 2014.
[19]Zheng-Ren L I, Zhou K H, Wang Q G, et al. Activity Management Platform Based on Node.js and WeChat Mini Program[J]. Computer Systems & Applications, 2019.
[20]宣超.基于MongoDB的事務機制研究與實現[D].電子科技大學,2018.
[21]Jose B, Abraham S. Performance analysis of NoSQL and relational databases with
MongoDB and MySQL[J]. Materials Today: Proceedings, 2020, 24(7):2036-2043.
[22]葛宇鋒.MongoDB查詢優化技術研究[D].南京郵電大學,2017.
[23]孫昌華.基于網絡協議分析的郵件系統安全性研究與改進[D].華中科技大 學, 2017.
[24]Castillo D P, Regidor F M, Higuera J B, et al. A New Mail System for Secure Data Transmission in Cyber Physical Systems[J]. International Journal of Uncertainty Fuzziness and Knowledge-Based Systems, 2020, 28(2):23-48.
[25]Howser G.Simple Mail Transfer Protocol: Email[M]. 2020.
[26]張彌弭. 基于網絡自媒體平臺的品牌傳播模式研究——以微信公眾平臺為例 [D]. 廈門大學, 2014.
[27]齊艷麗.基于微信公眾平臺的商城系統的設計與實現[D].西安電子科技大 學, 2017.
[28]Douglass B P. UML Class Diagrams[J]. Embedded Systems Programming, 2003, 16(2):39-40.
[29]程春蕊，劉萬軍.高內聚低耦合軟件架構的構建J].計算機系統應用，2009, 18(07):19-22.
[30]Rochfeld A, Negros P. Relationship of relationships and other inter-relationship links in E-R model[J]. Data & Knowledge Engineering, 1992, 9(2):205-221.
[31]Ya-Wei L I, Liu Z X, Ding S J. Technique for Discovering Stored XSS Vulnerability Based on Tracing Risky Data[J]. Computer Science, 2014, 41(S2):241-244.
[32]吳翰清.白帽子講Web安全:紀念版[M].電子工業出版社,2014:99.
[33]Ye C. Design and Implementation of CSRF Defense Module Based on MD5[J]. Journal of Information Security Research, 2019, 5(3):223-229.
[34]劉薇.基于OPC UA的MES數據管理系統的研究[D].北京郵電大學,2019.
[35]Dierks T. The Transport Layer Security (TLS) Protocol Version 1.2[J]. Rfc, 2008.
[36]Wang H X, Chun-Xiang G U, Zheng Y H. Formal Security Analysis of OAuth2.0 Authorization Protocol[J]. Journal of Information Engineering University, 2014, 15(2):141-147.
[37]Jones M, Tarjan P, Goland Y, et al. JSON Web Token (JWT)[J]. 2015.
[38]李寧,李戰懷.基于黑盒測試的軟件測試策略研究與實踐J].計算機應用研究, 2009, 26(003): 923-926.
[39]Gorenflo C, Golab L, Keshav S. XOX Fabric: A hybrid approach to transaction execution[J]. 2019.
[40]余青.利用Apache Jmeter進行Web性能測試的研究J].智能計算機與應用, 2012(02):55-57.
[41]Yifeng L I. Design and implementation of automated testing system based on pytest and JMeter[J]. Intelligent Computer and Applications, 2019, 9(1):277-279.
[42]夏耩. 一種基于 ElementUI 和 UEditor 富文本的組件開發方法, CN108089847A[P]. 2018.
攻讀碩士期間的學術成果
競賽獲獎情況：
[1] 2020 年 8 月，獲第十五屆中國研究生電子設計競賽商業技術書賽初賽三等 獎，團隊隊長。
軟件著作權：
[1]軟件著作權，獲得授權，“知識產權信息管理系統軟件（后端）V1.0”登記 號：2020SR0702778，第一登記人。
獎學金：
[1]2019-2020學年校研究生學業獎學金；
[2]2020-2021 學年校研究生學業獎學金。
下一篇：沒有了
相關標簽:
