將申請人的發(fā)明方案清楚地進(jìn)行描述并據(jù)此要求相應(yīng)的權(quán)利，是作為一名優(yōu)秀代理人應(yīng)該具備的基本素質(zhì)。這里提到的清楚，不但包括方案本身語言描述的清楚，更包括發(fā)明方案的邏輯清楚。筆者認(rèn)為，為保證發(fā)明方案的描述邏輯清楚，對技術(shù)方案的理解，不能僅停留在文字上，而需要代理人在撰寫中結(jié)合具體應(yīng)用場景思考所描述出來的發(fā)明方案本身的邏輯是否合理。

下面結(jié)合筆者在實(shí)務(wù)中碰到的幾個案例，對其進(jìn)行說明，需要說明的是，筆者對引用案例中原方案做了小改動，以避免其他問題對本文所述問題的干擾。

案例一：

在空管自動化系統(tǒng)間的管制移交互聯(lián)轉(zhuǎn)換方法中，發(fā)明要解決的問題是：在相鄰兩個空管自動化系統(tǒng)間的管制移交過程中，提高移交效率和安全，所提供的解決方案是在相鄰兩個空管自動化系統(tǒng)之外提供第三方設(shè)備，對一個空管自動化系統(tǒng)向另一個相鄰的空管自動化系統(tǒng)發(fā)出的數(shù)據(jù)進(jìn)行實(shí)時監(jiān)控，一旦發(fā)現(xiàn)數(shù)據(jù)傳輸出現(xiàn)問題就向管理員發(fā)出風(fēng)險預(yù)警，提高移交效率和安全性。

然而，發(fā)明人提供的交底書中對方案的具體實(shí)施方式描述得比較籠統(tǒng)，并未給出第三方設(shè)備具體的工作方式。代理人和發(fā)明人溝通后，在權(quán)利要求中提到：

第三方設(shè)備接收作為發(fā)出方的空管自動化系統(tǒng)發(fā)出的報文；

對每個時間周期內(nèi)接收到的所述監(jiān)測數(shù)據(jù)進(jìn)行解析，得出各個數(shù)據(jù)項以及所述各個數(shù)據(jù)項的分析結(jié)果。

從描述的權(quán)利要求方案來看方案是清楚的。然而，當(dāng)結(jié)合具體應(yīng)用場景思考權(quán)利要求所反應(yīng)的技術(shù)方案，我們就會發(fā)現(xiàn)邏輯存在問題：現(xiàn)有技術(shù)中沒有第三方設(shè)備的情況下，一個空管自動化系統(tǒng)對另一個相鄰的空管自動化系統(tǒng)發(fā)出數(shù)據(jù)，而一旦第三方設(shè)備加入后，空管自動化系統(tǒng)為什么能夠不向相鄰的空管自動化系統(tǒng)發(fā)出數(shù)據(jù)，而轉(zhuǎn)而將數(shù)據(jù)發(fā)送給第三方設(shè)備呢？機(jī)器沒有眼睛，它無法知道加入了新的設(shè)備，如果不對現(xiàn)有設(shè)備做相應(yīng)改動或者第三方設(shè)備事先不和現(xiàn)有設(shè)備相互建立聯(lián)系的話，現(xiàn)有設(shè)備即上述案例中提到的空管自動化系統(tǒng)直接將數(shù)據(jù)發(fā)送給新加入的第三方設(shè)備，這顯然是脫離了技術(shù)方案本身，不合乎邏輯。

考慮到這點(diǎn)，代理人繼續(xù)和發(fā)明人進(jìn)行溝通后發(fā)現(xiàn)，第三方設(shè)備的加入并不會影響現(xiàn)有技術(shù)數(shù)據(jù)發(fā)送的流程，也就是說，作為發(fā)送方的空管自動化系統(tǒng)依然會向作為接收方的空管自動化系統(tǒng)發(fā)送數(shù)據(jù)，第三方設(shè)備需要主動從接收方去提取數(shù)據(jù)，而如何實(shí)現(xiàn)主動提取數(shù)據(jù)在此不作詳述。代理人最后根據(jù)溝通的內(nèi)容對申請文件的方案做了修改以使得申請文件的方案合理且邏輯清楚。

案例二：

在涉及通過掃描二維碼獲取用戶賬號和密碼的方法中，發(fā)明人欲提供一個對用戶進(jìn)行身份驗(yàn)證的方案，但交底書中并未給出具體的實(shí)施方式。代理人在和發(fā)明人進(jìn)行初步溝通后，在權(quán)利要求中提到:

用戶終端首先向服務(wù)器發(fā)送獲取賬號和密碼的請求；

服務(wù)器將所請求的賬號和密碼通過二維碼展示；

用戶終端對二維碼進(jìn)行掃描從而獲取賬號和密碼，其中，用戶終端對二維碼進(jìn)行掃描包括：用戶終端在開機(jī)時，對用戶身份信息進(jìn)行驗(yàn)證，驗(yàn)證通過后開始對二維碼進(jìn)行掃描。

結(jié)合應(yīng)用場景來思考上述權(quán)利要求所反應(yīng)的方案，會發(fā)現(xiàn)方案的內(nèi)在邏輯是有問題的。步驟中提到用戶終端首先向服務(wù)器發(fā)送獲取賬號和密碼的請求，從這個步驟，我們可以知道用戶終端已經(jīng)處于開機(jī)狀態(tài)，而在對用戶終端對二維碼進(jìn)行掃描這個步驟做具體限定中指出“在用戶終端開機(jī)時，對用戶身份信息進(jìn)行驗(yàn)證”，問題來了：前一個步驟在已經(jīng)開機(jī)的狀態(tài)下完成，按照步驟執(zhí)行順序的話，后一個步驟應(yīng)該是在前一個步驟基礎(chǔ)之上去執(zhí)行，而在后一個步驟的執(zhí)行過程中卻要在開機(jī)時對用戶的身份進(jìn)行驗(yàn)證，，就算后一個步驟中提到的“開機(jī)驗(yàn)證”的過程理解為是在前一個步驟之前執(zhí)行的話，那么所描述的后一個步驟和前一個步驟之間的邏輯關(guān)系也是不清楚的。

針對此問題，代理人和發(fā)明人進(jìn)行了再次的深入溝通后獲知，用戶終端對二維碼進(jìn)行掃描執(zhí)行過程是：用戶終端在開啟二維碼掃描功能之前，對用戶身份信息進(jìn)行驗(yàn)證，而并非是在用戶終端開機(jī)時對用戶身份進(jìn)行驗(yàn)證。代理人根據(jù)此次溝通的內(nèi)容對申請文件做了對應(yīng)修改。

諸如上述提到的類似情況在實(shí)務(wù)中遇到不少，主要原因是代理人對方案的理解停留在文字上，而忽略了結(jié)合應(yīng)用場景去思考所描述出來的方案的合理性。

發(fā)明人通常都具有豐富的專業(yè)知識，并且在工作中的交流對象往往也是具有相同技術(shù)背景的研發(fā)人員，因此在工作的交流中使用的語言不需要特別準(zhǔn)確，對方也能理解其表達(dá)的意思，也正因如此，發(fā)明人在撰寫交底書時，對某些技術(shù)特征或方案的表達(dá)也會習(xí)慣性地比較籠統(tǒng)或隨意。而專利申請文件是一個嚴(yán)謹(jǐn)?shù)姆晌募枰獫M足清楚、完整等要求，而準(zhǔn)確地反映發(fā)明的內(nèi)在邏輯，更是滿足“清楚”這一要件不可或缺的。因此，代理人在撰寫申請文件時，對方案的理解不能僅停留在文字上，而需要結(jié)合具體的應(yīng)場景考慮方案的合理性，以避免此類問題的發(fā)生。

以上，是筆者的一些經(jīng)驗(yàn)總結(jié)，其中必有不妥之處，還請讀者指正。