作者：徐莉 律師、專利代理師

隨著互聯(lián)網(wǎng)和通信技術的高速發(fā)展，軟件方法類的專利申請不斷增多。軟件方法的技術方案通常由多個執(zhí)行主體共同實施，如在消息收發(fā)的通信場景中，執(zhí)行主體至少包括發(fā)送端（如移動設備）和接收端（如基站）；在程序應用的交互場景中，執(zhí)行主體至少包括用戶端（如終端設備）和服務端（如服務器）。

當技術方案涉及多個執(zhí)行主體時，權利要求布局應遵循單側撰寫原則，一套權利要求以單一執(zhí)行主體為對象進行撰寫，以利于后續(xù)維權過程中認定侵權。簡單來說，侵權認定遵循全面覆蓋原則，如果一項權利要求涵蓋多個執(zhí)行主體，則在主張侵權時要證明每個執(zhí)行主體實施了權利要求所描述的步驟，不僅舉證義務加重，而且很容易因侵權方未覆蓋某一執(zhí)行主體/某一步驟，導致侵權認定失敗。

因此，單側撰寫已成為代理師在處理涉及多端的軟件專利申請時的一項基本原則。筆者在軟件專利申請的撰寫實務中發(fā)現(xiàn)，單側撰寫原則確應遵循，但不能生搬硬套，還需結合專利申請的必要技術特征、創(chuàng)造性、單一性等其他要求，具體問題具體分析，處理好涉及多端的軟件專利的申請工作。

下面主要從單側撰寫和創(chuàng)造性兩方面考慮，結合撰寫實務簡單分析涉及多端的軟件專利申請的撰寫思路，并討論具體案例中當單側撰寫與創(chuàng)造性沖突時如何權衡。

撰寫思路

第一步，理清技術方案。由多個執(zhí)行主體共同實施的軟件方法，通常包括較多的交互步驟，理清技術方案、明確各個執(zhí)行主體之間如何交互以解決技術問題，是撰寫的前提。在實踐中，可以借助直觀描述各個執(zhí)行主體之間交互過程的交互圖，進行技術方案的整理和分析。

第二步，基于單側撰寫進行每個執(zhí)行主體的方案拆分。從技術方案保護的角度出發(fā)，按照單側撰寫原則提取每個執(zhí)行主體的執(zhí)行步驟，形成每個執(zhí)行主體的技術方案。本步驟中，從技術方案保護的角度出發(fā)是指對適宜作為軟件專利的保護對象的執(zhí)行主體進行方案提取，排除用戶等不適宜作為軟件專利的保護對象的執(zhí)行主體。

第三步，基于發(fā)明點進行每個執(zhí)行主體的方案提煉和創(chuàng)造性判斷。以發(fā)明點為核心，對每個執(zhí)行主體的技術方案進行提煉，總結必要技術特征和發(fā)明點相關特征，使區(qū)別于現(xiàn)有技術的發(fā)明構思體現(xiàn)在拆分出的每個執(zhí)行主體上，形成每個執(zhí)行主體的分層次保護的技術方案。當然，創(chuàng)造性判斷的前提是新穎性，因新穎性的判斷較為基礎，本文不做詳細討論。

按照上述的撰寫思路，在判斷方案創(chuàng)造性時，會遇到部分執(zhí)行主體的方案明顯不具備創(chuàng)造性的情況。雖然創(chuàng)造性的判定需經(jīng)過審查和答復，但代理師在撰寫申請文件時，應當對方案創(chuàng)造性有一個初步判斷。在部分執(zhí)行主體的方案明顯不具備創(chuàng)造性時，則要考慮放棄這一端的權利要求布局，或者通過多端結合的方式進行撰寫。

具 體 案 例：

一、拆分出的每個執(zhí)行主體的技術方案經(jīng)初步判斷都可爭取創(chuàng)造性。

例如，一個通過為消息載體配置傳輸功能，解決消息傳輸可靠性問題的技術方案。方案的執(zhí)行主體涉及發(fā)送端和接收端，方案內容大致包括：由接收端確定待配置傳輸功能的消息載體，向發(fā)送端發(fā)送對該消息載體配置傳輸功能的配置指令；發(fā)送端接收到配置指令后對該消息載體配置傳輸功能，并通過配置了傳輸功能的消息載體將待發(fā)送消息傳輸至接收端，以此實現(xiàn)不同類型消息的可靠傳輸。

基于單側撰寫原則對上述方案拆分后，可以形成分別從發(fā)送端一側和接收端一側圍繞發(fā)明點展開的技術方案：

發(fā)送端一側：響應于配置指令，對指定的消息載體執(zhí)行傳輸功能的配置，并通過配置了傳輸功能的消息載體執(zhí)行待發(fā)送消息的傳輸。

接收端一側：確定待配置傳輸功能的消息載體，并發(fā)出為指定的消息載體配置傳輸功能的配置指令。

另外，撰寫時還可以加入發(fā)送端對應的裝置和設備、接收端對應的裝置和設備、以及包括發(fā)送端設備和接收端設備的消息傳輸系統(tǒng)等權利要求。

二、拆分出的某些執(zhí)行主體的方案過于常規(guī)，明顯不符合創(chuàng)造性要求。

例如，一個通過分流查詢數(shù)據(jù)至搜索服務器，解決數(shù)據(jù)查詢耗時問題的技術方案。方案的執(zhí)行主體涉及用戶端和服務端，方案內容大致包括：服務端從基礎數(shù)據(jù)中分流出一部分查詢數(shù)據(jù)，以查詢維度和索引標識存儲將這些查詢數(shù)據(jù)存儲至搜索服務器中；當服務端接收到用戶端發(fā)送的查詢請求時，對預存于搜索服務器中的查詢維度，基于索引標識從基礎數(shù)據(jù)中快速獲取對應的詳細數(shù)據(jù)；沒有預存的查詢維度則通過遍歷基礎數(shù)據(jù)的方式獲取對應的詳細數(shù)據(jù)，以此實現(xiàn)對查詢請求的快速響應。

基于單側撰寫原則對上述方案拆分后，發(fā)現(xiàn)發(fā)明點相關步驟均由服務端完成，用戶端只執(zhí)行常規(guī)的發(fā)送請求和展示結果，并不包含區(qū)別于現(xiàn)有技術的手段，創(chuàng)造性高度明顯不夠。因此，本案例可以將重心放在服務端，形成服務端一側的技術方案如下：

根據(jù)數(shù)據(jù)查詢請求，獲取查詢維度；對于已預存的查詢維度，根據(jù)對應的索引標識索引詳細的基礎數(shù)據(jù)；對于未預存的查詢維度，遍歷獲取詳細的基礎數(shù)據(jù)；及在響應查詢請求的過程中，實時地將滿足分流條件的查詢數(shù)據(jù)按照查詢維度和索引標識添加至搜索服務器中。

當然，撰寫時會與發(fā)明人討論，確認用戶端沒有可挖掘的發(fā)明點。若能挖掘出用戶端的發(fā)明點，則需對用戶端進行權利要求布局，并使用戶端的發(fā)明構思與服務端的發(fā)明構思產(chǎn)生技術關聯(lián)，避免出現(xiàn)單一性問題。若不滿足單一性則需考慮分案申請，本文不做詳細討論。

三、部分案例中，當基于單側撰寫原則進行方案拆分，不僅創(chuàng)造性要求無法滿足，還會出現(xiàn)方案無法實施的情況。

例如一個通過終端管理設備進行智能家居綁定的技術方案，依賴于終端管理設備、智能家居以及云平臺等設備之間的交互通信，以任一執(zhí)行主體單側撰寫都會導致方案缺少必要技術特征而無法解決技術問題。對于這類案件，在權利要求布局時就不宜生搬硬套單側撰寫原則，而應結合實際方案，從滿足必要技術特征角度，結合創(chuàng)造性要求，撰寫通過終端管理設備經(jīng)云平臺執(zhí)行智能家居綁定的方案。

以上對權利要求的布局和撰寫進行了簡單分析。說明書的撰寫則要詳細而全面，且需描述各個執(zhí)行主體之間交互的實施例，以充分支持權利要求中單側撰寫的方案，使整個技術方案完整可讀。

綜上，在涉及多端的軟件專利申請的撰寫實務中，應結合單側撰寫原則和包括創(chuàng)造性在內的多項專利申請要求，撰寫出一份保護方案的布局合理、范圍合適的申請文件。