作者：夏彬 專利代理人

一、概述

隨著互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，計算機與網(wǎng)絡結(jié)合的軟件類專利申請越來越多。在計算機軟件領(lǐng)域中，一個技術(shù)方案往往涉及到多個實施主體，通過多個實施主體之間的交互實現(xiàn)發(fā)明目的。例如，對于客服方法來說，往往涉及到為用戶提供服務的客服方、為客服方提供數(shù)據(jù)支持的云端存儲器方以及方法指向的用戶方。

在權(quán)利要求的撰寫中，對于方法類權(quán)利要求，如果直接按照交互流程來撰寫方法的步驟，每個步驟的實施主體可能彼此不同，即形成了多邊撰寫。比如，一個客服方法，首先用戶方向客服方發(fā)送服務請求，客服方根據(jù)用戶方的請求至云端存儲器中查詢相關(guān)數(shù)據(jù)，云端存儲器則在查詢到相關(guān)數(shù)據(jù)后返回至客服方。

在這種情況下，最大的問題是，在侵權(quán)訴訟中，責任無法分清，難以確定侵權(quán)者。對于客服方法來說，如果將用戶方、客服方和云端存儲器均作為侵權(quán)者顯然是不合適的，因為客服方法面對的是廣泛的受眾，不可能將使用該方法的用戶作為侵權(quán)者，而云端存儲器則是相對中立的第三方，甚至可能跟侵權(quán)訴訟的原告也存在一些合作，不適合于作為侵權(quán)訴訟的對象。

為此，筆者認為，采用權(quán)利要求的“單邊撰寫原則”可以較好的避免上述問題。所謂單邊撰寫原則，與多邊撰寫相對應，指的就是在撰寫方法權(quán)利要求中，僅以方法交互中的一側(cè)設(shè)備作為實施主體來撰寫方法的各個步驟。具體地，例如對上述客服方法改寫為：首先客服方接受到用戶方發(fā)送的服務請求，客服方根據(jù)用戶方的請求至云端存儲器中查詢相關(guān)數(shù)據(jù)，并接收云端存儲器返回的查詢數(shù)據(jù)。

采用單邊撰寫方法后，在判定侵權(quán)時，只需要將客服方作為侵權(quán)者，并且在采用全面覆蓋原則進行專利侵權(quán)判定時，只需要針對客服方判斷其是否實施了方法權(quán)利要求的所有步驟即可，對于侵權(quán)訴訟的原告來說，也大大降低了取證的難度。

二、撰寫思路

下面以一個具體實例來進一步介紹計算機軟件方法類權(quán)利要求的單邊撰寫思路。

技術(shù)方案簡介：提供了一種規(guī)則引擎，在該規(guī)則引擎中，用戶可以通過用戶終端自由配置新的規(guī)則，規(guī)則引擎根據(jù)預設(shè)的規(guī)則，將用戶終端對規(guī)則的配置數(shù)據(jù)進行編譯，生成可執(zhí)行的class文件，然后將class文件發(fā)布至需要執(zhí)行該規(guī)則的目標對象，目標對象接收到該class文件后通過class加載器加載到內(nèi)存。由此，目標對象可以直接通過讀取內(nèi)存執(zhí)行class文件的方式來執(zhí)行用戶自由配置的規(guī)則。

1.技術(shù)方案分析

首先，需要對上述技術(shù)方案進行簡單分析，得到該方案涉及到的實施主體：規(guī)則引擎、用戶終端和目標對象。

本技術(shù)方案解決的技術(shù)問題是，通過規(guī)則引擎建立起用戶終端和目標對象的橋梁，將用戶終端配置的規(guī)則直接輸出到目標對象，成為目標對象可以執(zhí)行的文件。

2.方法流程梳理

然后，根據(jù)上述技術(shù)方案，將包括三個實施主體的技術(shù)方案梳理如下：

S100：規(guī)則引擎推送規(guī)則配置界面給用戶終端；

S200：用戶通過用戶終端在推送配置界面中配置規(guī)則；

S300：規(guī)則引擎將用戶終端的規(guī)則配置數(shù)據(jù)進行編譯，生成可執(zhí)行的class文件；

S400：規(guī)則引擎將class文件發(fā)布至需要執(zhí)行該規(guī)則的目標對象；

S500：目標對象接收到該class文件后通過class加載器加載到內(nèi)存；

S600：目標對象讀取內(nèi)存執(zhí)行class文件。

3.核心實施主體提取

根據(jù)上述技術(shù)問題的分析，可以知道，該方案的主體是規(guī)則引擎，其起到了用戶和目標對象之間的橋梁作用。通過規(guī)則引擎的溝通，實現(xiàn)了用戶自由配置的規(guī)則可以快速加載到目標對象中。因此，選擇規(guī)則引擎為核心實施主體，也就是本專利需要保護的對象。

在考慮核心實施主體時，也可以從侵權(quán)訴訟的角度來看。在侵權(quán)訴訟中，如果將用戶終端作為侵權(quán)者顯然是不合理的，用戶作為使用方，實際上是解決相應技術(shù)問題的需求者，而不是解決者。而目標對象往往受眾較大，一般指的是需要執(zhí)行具體規(guī)則的服務器，其在接收到class文件后加載到內(nèi)存，然后讀取內(nèi)存執(zhí)行class文件的過程，實際上是本方案要實現(xiàn)的目的。對于專利保護者來說，其面對的目標對象可能與侵權(quán)者的目標對象存在重合，因此，不適合將目標對象也作為權(quán)利要求保護的實施主體。

在考慮核心實施主體時，也可以從專利申請者自身的業(yè)務來看。一般，申請該技術(shù)方案的專利申請者，往往是規(guī)則引擎的開發(fā)商，其與用戶終端以及目標對象存在的都是合作關(guān)系，而非包含關(guān)系，因此為了更好地保護專利申請者的權(quán)益，將規(guī)則引擎作為核心實施主體。

4.提取核心實施主體執(zhí)行的步驟

對于該方案，提取規(guī)則引擎執(zhí)行的步驟如下：

S100：規(guī)則引擎推送規(guī)則配置界面給用戶；

S300：規(guī)則引擎將用戶對規(guī)則的配置進行編譯，生成可執(zhí)行的class文件；

S400：規(guī)則引擎將class文件發(fā)布至需要執(zhí)行該規(guī)則的目標對象。

可以看出，提取后的步驟所形成的流程并不是十分完整，缺失了一些關(guān)鍵步驟，因此需要下一步的步驟填充。

5.轉(zhuǎn)化非核心實施主體執(zhí)行的步驟

轉(zhuǎn)化的方法主要有如下三種：

（1）非核心實施主體與核心實施主體之間的交互步驟，將數(shù)據(jù)發(fā)送方作為主體轉(zhuǎn)化為數(shù)據(jù)接收方作為主體

對于該方案來說，步驟S100后，規(guī)則引擎推送規(guī)則配置界面給用戶后，執(zhí)行的是步驟S200用戶通過用戶終端對規(guī)則引擎推送規(guī)則進行配置，步驟S200可以轉(zhuǎn)化為以規(guī)則引擎執(zhí)行的動作，在該步驟中，用戶終端是發(fā)送配置數(shù)據(jù)方，而規(guī)則引擎是接收配置數(shù)據(jù)方。因此步驟S200轉(zhuǎn)化為：規(guī)則引擎接收用戶終端發(fā)送的規(guī)則配置數(shù)據(jù)；

（2）非核心實施主體自身執(zhí)行的動作，從執(zhí)行步驟轉(zhuǎn)化為非核心實施主體的限定內(nèi)容

步驟S500中，目標對象接收到該class文件后通過class加載器加載到內(nèi)存。由于在該過程中，不再涉及到目標對象和規(guī)則引擎之間的交互，而是目標對象在接收到相應文件后，自身執(zhí)行的動作。此時，無法再將步驟S500轉(zhuǎn)化為核心實施主體執(zhí)行的步驟。

在這種情況下，可以將步驟S500轉(zhuǎn)化為目標對象的限定內(nèi)容，例如在步驟S400規(guī)則引擎將class文件發(fā)布至需要執(zhí)行該規(guī)則的目標對象之后，增加對于目標對象的限定“該目標對象被配置為接收到class文件后將所述可執(zhí)行文件加載到內(nèi)存”。經(jīng)過此種轉(zhuǎn)化后，目標對象是特定的需要滿足一定條件“接收到class文件后可以將class文件加載到內(nèi)存”的，其作為步驟S400的限定，也就是核心實施主體執(zhí)行操作時選擇目標對象的限定，而不再作為目標對象執(zhí)行的步驟而存在。

（3）非必要步驟可以刪除

對于該方案來說，核心技術(shù)方案是“規(guī)則的配置和發(fā)布”，步驟S600目標對象讀取內(nèi)存執(zhí)行class文件中，目標對象執(zhí)行的則是規(guī)則實施的步驟。規(guī)則實施屬于規(guī)則發(fā)布之后必然會執(zhí)行的動作，并且并不屬于本發(fā)明的核心保護內(nèi)容。因此，步驟S600可以刪除。

6.整理轉(zhuǎn)化后的單邊撰寫權(quán)利要求

根據(jù)上述提取和轉(zhuǎn)化，可以整理得到轉(zhuǎn)化后的單邊撰寫權(quán)利要求如下：

S100：規(guī)則引擎推送規(guī)則配置界面給用戶；

S200：規(guī)則引擎接收用戶終端發(fā)送的規(guī)則配置數(shù)據(jù)；

S300：規(guī)則引擎將用戶的規(guī)則配置數(shù)據(jù)進行編譯，生成可執(zhí)行的class文件；

S400：規(guī)則引擎將class文件發(fā)布至需要執(zhí)行該規(guī)則的目標對象，該目標對象被配置為接收到class文件后將所述可執(zhí)行文件加載到內(nèi)存。

可以看出，修改后的權(quán)利要求的技術(shù)方案可以解決上述根據(jù)用戶對規(guī)則的配置編譯生成規(guī)則執(zhí)行文件并發(fā)布至目標對象的技術(shù)問題。同時，權(quán)利要求中各個步驟的執(zhí)行主體均為規(guī)則引擎。在侵權(quán)訴訟中，可以將落入授權(quán)專利的保護范圍之內(nèi)的規(guī)則引擎的提供商作為侵權(quán)者，并且在取證過程中只需要調(diào)取規(guī)則引擎執(zhí)行的方法步驟，也降低了取證難度，避免了上面所說的多邊撰寫存在的問題。