「文件特徵自動擷取」專利迴避分析

2005 年五月 26 日 (星期四) 3:48 pm
分類：智財, 電腦
標籤：自然語言處理

中華民國發明專利第 153789 號「數位文件關鍵特徵之自動擷取方法」，2000-01-15 申請，2002-04-11 公告。

乍看之下，野心頗大，需逐步拆解分析。首先針對申請專利範圍，分析此方法所欲施行的客體：

1. 一種數位文件關鍵特徵之自動擷取方法，該數位文件中包括有複數個元素，任一該元素則包括至少一位元組 (byte)，……
14. 如申請專利範圍第 1 項所述之自動擷取方法，其中該數位文件，係為可表達成字串與有序集合之資料二者擇一的一資訊。
- 什麼叫做「二者擇一」資訊？是指 0 與 1 嗎？
- 敘述似過於冗餘，constituent 切分也有嚴重的 ambiguity；其實第 1 項的 byte 一詞就足夠涵蓋第 14 項的一堆「字串」、「有序集合」、「二者擇一」等敘述。

15. 如申請專利範圍第 14 項所述之自動擷取方法，其中該資訊包括：文字，音樂，語音，音訊，影像序列，時間序列以及 DNA 序列。
- 不同的資訊類型，自有其特殊性質，能否如此般囊括通吃？不無疑問。尤其是缺乏實施例，恐通不過逆均等理論的檢驗。

12. 如申請專利範圍第 1 項所述之自動擷取方法，其中該元素係包括東方文字字元 (character)、東方文字詞彙 (word)、西方語文字元 (alphabet letter)、西方語文單字 (word) 或音樂音符 (note)。
- 這就比第 15 項持平多了，也有實施例佐證。

接下來，以 information retrieval 領域慣用術語，分析申請專利範圍所用的陌生詞彙：

1. ……該自動擷取方法包括：
(A) 將該數位文件轉換為一條列資料結構，該條列資料結構包括至少一條列元素；
6. 如申請專利範圍第 1 項所述之自動擷取方法，其中任一該條列元素係包括任一該元素以及相對應的該出現次數。
- 這只是很基本的 term frequency 統計；習知技術。

4. 如申請專利範圍第 1 項所述之自動擷取方法，其中任一該條列元素係包括任一該元素的一位置組合。
5. 如申請專利範圍第 4 項所述之自動擷取方法，其中該位置組合係由代表該元素於該數位文件中所出現之位置的數字組合而成。
- 說穿了，這只是 inverted index 罷了；習知技術。

綜合整理，此專利所謂的「條列元素」，乃是 (term, frequency, locations) 的 tuple。

現在，我們可以針對申請專利範圍，分析足以構成 substantial differences 的迴避手段：

1. ……該自動擷取方法包括：……
(C) 依序取出該條列資料結構中的該條列元素，……
- 「依序」兩字表示：對於各 term，只會單向 scan 過去，不會 backtrack。

1. ……該自動擷取方法包括：……
(C) 依序取出該條列資料結構中的該條列元素，……若取出之該條列元素的該出現次數大於該臨界值，且臨接於該條列元素之後的一後續元素的該出現次數也大於該臨界值，則進行一組合程序，……
- 以演算法的 bootstrap 階段而言，它的 bigram，只有可能是緊鄰 (adjacent) 的 collocation。
- 然而，在 NLP 或語言學領域的 collocation 研究中，早就考慮到「非緊鄰」的 long distance 情況，像 Whitney Houston 的歌 Take Good Care of My Heart，其中 take 和 care 就非緊鄰在一起，但仍屬語言學學理上的 collocation。
- 此外，collocation 也可能會有移位現象，term 也會有 morphological 變化，像是 “care has been taken of”。
- 單只是在語言學層次，就有上述的問題；換成音樂、影像、DNA 等資料，又怎會只有「緊鄰」這麼簡單？
- NLP 領域很早就有人提出 “collocational window” 方法來解決上述問題，像 FSNLP §5.2 解釋得很詳細。我不知道這概念源自何處，至少早在 1993 年的 Xtract 就出現過，比此專利申請年份早了 7 年，可算是習知技術。
- 【迴避】只要在此步驟，針對申請專利範圍之「臨接」、「後續元素」突圍（譬如說：collocational window），即屬手段、結果之顯著差異。

最後，針對申請專利範圍，分析可能有的敘述瑕疵：

圖式簡單說明：
第 1 圖繪示的是習知技藝一種關鍵詞擷取方法的虛擬碼；
- 呃，有哪一個實際系統會用你所舉的 top-down 方式去找 pattern？

參考文獻

Chris Manning and Hinrich Schütze, Foundations of Statistical Natural Language Processing, MIT Press. Cambridge, MA: May 1999.
Frank Smadja, “Retrieving Collocations from Text: Xtract,” Computational Linguistics, Vol. 19 , No. 1, 1993, pp.143-177.

（註：本文不負責、不擔保商業場域之適用性及適法性，請徵詢專利律師意見。）

◤建議您一併閱讀以下文章：

著作授權方式：Creative Commons 條款。

追蹤留言回應：以 RSS 2.0 方式。
文章永久網址：
» http://william.cswiz.org/blog/archives/2005-05-26/patent-153789/
引用通告 (trackback)：
» http://william.cswiz.org/blog/archives/2005-05-26/patent-153789/trackback/

本站歡迎您以合乎創用CC 的方式，將文章選錄至網路書籤或社群網站，也別忘了將您寶貴的意見（尤其是延伸的評論、補充、彙整、反駁等）留言在本站。謝謝！

6 項留言回應給 “「文件特徵自動擷取」專利迴避分析”

1 曾元顯留言：
2005 年五月 26日於 4:50 pm
1. 一種數位文件關鍵特徵之自動擷取方法，該數位文件中包括有複數個元素，任一該元素則包括至少一位元組 (byte)，……\r
14. 如申請專利範圍第 1 項所述之自動擷取方法，其中該數位文件，係為可表達成字串與有序集合之資料二者擇一的一資訊。
• 什麼叫做「二者擇一」資訊？是指 0 與 1 嗎？
• 敘述似過於冗餘，constituent 切分也有嚴重的 ambiguity；其實第 1 項的 byte 一詞就足夠涵蓋第 14 項的一堆「字串」、「有序集合」、「二者擇一」等敘述。

作者回應：這部分是專利工程師寫的，我本人不清楚其在法律或專利上的效用。

15. 如申請專利範圍第 14 項所述之自動擷取方法，其中該資訊包括：文字，音樂，語音，音訊，影像序列，時間序列以及 DNA 序列。
• 不同的資訊類型，自有其特殊性質，能否如此般囊括通吃？不無疑問。尤其是缺乏實施例，恐通不過逆均等理論的檢驗。

作者回應：文字、音樂都有測試過，按照本發明之精神，音訊、影像序列、時間序列、DNA 序列只要具備重複性，重要片段或特徵片段亦可被擷取出來。我不清楚是否要每一種都要驗證、寫出來，才叫不缺乏實施例。

此發明假設重複片段為重要片段或特徵片段。由於此假設簡單，因此適用範圍相對較大。

由於「重要」片段乃是一種主觀之意見，若不做客觀之假設，電腦將無法處理主觀之物件，因而難以做到自動擷取。當然，各種資料類型有其特殊之應用需求，後續還要根據其應用需求來過濾這些重複片段，而獲得真正想要的特徵片段。在音樂旋律方面，此種過濾作法很簡單，亦即把屬於某些個重複片段的子重複字串刪除即可 (delete those repeated patterns that are substrings of the other repeated patterns)，若不想刪除，也可以，只是留下較多之重複片段旋律而已。這一點在發明說明中，已有提到。

1. ……該自動擷取方法包括：
(A) 將該數位文件轉換為一條列資料結構，該條列資料結構包括至少一條列元素；
6. 如申請專利範圍第 1 項所述之自動擷取方法，其中任一該條列元素係包括任一該元素以及相對應的該出現次數。
• 這只是很基本的 term frequency 統計；習知技術。

作者回應：是 term frequency 沒錯，重點在於如何運用。只要出現次數超過一次的 maximally repeated pattern 就可以被擷取出來，IR 裡面可是很少看到喔。

4. 如申請專利範圍第 1 項所述之自動擷取方法，其中任一該條列元素係包括任一該元素的一位置組合。
5. 如申請專利範圍第 4 項所述之自動擷取方法，其中該位置組合係由代表該元素於該數位文件中所出現之位置的數字組合而成。
• 說穿了，這只是 inverted index 罷了；習知技術。

作者回應：請參考專利中的實施例，未必得做成 inverted index 不可。建構一個 inverted index 會牽涉到 global 範圍的計算，實施例中說明如何盡量避免，而只做 local 的計算，以提高計算效率。

1. ……該自動擷取方法包括：……\r
(C) 依序取出該條列資料結構中的該條列元素，……
• 「依序」兩字表示：對於各 term，只會單向 scan 過去，不會 backtrack。

作者回應：不做 backtrack 是為了提升計算效率。有人要故意設計一個效率較差的方法來規避專利嗎？我不知道答案。

1. ……該自動擷取方法包括：……\r
(C) 依序取出該條列資料結構中的該條列元素，……若取出之該條列元素的該出現次數大於該臨界值，且臨接於該條列元素之後的一後續元素的該出現次數也大於該臨界值，則進行一組合程序，……
• 以演算法的 bootstrap 階段而言，它的 bigram，只有可能是緊鄰 (adjacent) 的 collocation。
• 然而，在 NLP 或語言學領域的 collocation 研究中，早就考慮到「非緊鄰」的 long distance 情況，像 Whitney Houston 的歌 Take Good Care of My Heart，其中 take 和 care 就非緊鄰在一起，但仍屬語言學學理上的 collocation。
• 此外，collocation 也可能會有移位現象，term 也會有 morphological 變化，像是 “care has been taken of ” 。
• 單只是在語言學層次，就有上述的問題；換成音樂、影像、DNA 等資料，又怎會只有「緊鄰」這麼簡單？
• NLP 領域很早就有人提出 “collocational window” 方法來解決上述問題，像 FSNLP §5.2 解釋得很詳細。我不知道這概念源自何處，至少早在 1993 年的 Xtract 就出現過，比此專利申請年份早了 7 年，可算是習知技術。
• 【迴避】只要在此步驟，針對申請專利範圍之「臨接」、「後續元素」突圍（譬如說：collocational window），即屬手段、結果之顯著差異。

作者回應：這一段評論基本上沒錯。「take care」、「takes care」、「took care」可以利用詞性分析與詞幹處理而將這三種表達方式看成同一種，而被擷取出來。但這個方法沒有去照顧到「take good care」、「care has been taken」等重複「概念」的片段，而只單純擷取「take care」這種片語（如果該片語在文件中有重複的話），原因很簡單，就是為了要保持此專利方法的單純性，以及效率。另外 IR 大師 Salton 在 1983 年的著作裡，其 term formation 的方法就有處理你說的情況，因此我就不必在此專利方法中多做討論了。

圖式簡單說明：
第 1 圖繪示的是習知技藝一種關鍵詞擷取方法的虛擬碼；
• 呃，有哪一個實際系統會用你所舉的 top-down 方式去找 pattern？

作者回應：有！而且比起我這個方法有名氣。當初我有將詳細的相關著作寫下來，但專利工程師都將其拿掉，我很不習慣，心想，假如我是專利審查員，怎麼會比發明人更清楚 prior art 呢？把相關書目像寫學術論文一樣詳細列下來不是很好嗎？可惜我們的專利審查委員沒有要求，對專利申請不清楚的我，也只能尊重專利工程師的改寫了。

PS: I was impressed by this blog. Keep it alive!
2 william 留言：
2005 年五月 26日於 6:08 pm
曾老師（稱您為「老師」，比「教授」親切）：

我也很驚訝您這麼快就看到這篇文章。 : -o

我所提的分析，有些本來就是法律判例上爭議較多之處，自然不是紙上或網上討論／辯論就能算數；有些純粹是以「迴避設計」角度去看申請專利範圍，不必然意味我對該技術方法的優劣評論。

像 Claim #15，如果是被控侵權的辯方律師，一定會搬出「逆均等理論」來爭取；至於是否成立，這得看法官。

請參考專利中的實施例，未必得做成 inverted index 不可。建構一個 inverted index 會牽涉到 global 範圍的計算，實施例中說明如何盡量避免，而只做 local 的計算，以提高計算效率。

可能是我用詞不嚴謹，或是對專利內容認知有誤。我以為，若將第 3、4 圖合併來看，本質上就是 inverted index（或者說，是個 in-memory 的、以一數位文件為單位的 inverted index）。

至於第 3 圖所說的「透過雜湊紀錄」，在申請專利範圍的本體中並未著墨。

我說：「依序」兩字表示：對於各 term，只會單向 scan 過去，不會 backtrack。

您回覆說：不做 backtrack 是為了提升計算效率。

可能又是我用詞不當。

就拿 “take care of” 和 “care has been taken” 這兩句話為例。在這裡，我的 “backtrack” 是指：針對 “take” 一詞，在一開始 (bootstrap) 的 data preparation 階段，既允許 forward collecting bigram “take care”，也允許 backward collecting bigram “taken care”。也就是說：允許 collocational window 為 ±n。

附言：雖然我不喜歡專利，比較喜歡學術圈的風格；但仍頗能體會您所隱約表達的發明人 vs. 專利工程師的問題。兩者的 gap，很麻煩。
3 老貓留言：
2005 年五月 26日於 7:30 pm
嗯，看起來你們這些搞資工的大腦果然跟我們平常人不太一樣。本來看正文以為是火星文，沒想到居然有人可以回應，而且還可以對話……
4 william 留言：
2005 年五月 26日於 11:25 pm
呃，「看正文以為是火星文」，原因可能有三。

第一、法律的文件，genre 本來就和一般人的習慣相去甚遠；更何況是「專利」這種既有法律面，又有工程技術面的混合物。所以 in-house 或 in-firm 的專利工程師、專利律師才如此搶手呀！

第二、我無意完整收錄專利全文，也無意逐條解釋。這類文章，主要是給自己札記之用，以及給某些對該專利有興趣，或有潛在利害關係者交流之用。

第三、在找題材、讀論文、做研究之餘，也做些專利地圖的檢索，以免哪一天踩到專利陷阱而不自知，也對產業競爭力概況有個底。還可順便磨練一下專利的工具技巧，免得把五年前課堂學過的東西都還給老師，呵。
5 晴悠君留言：
2005 年六月 26日於 11:36 pm
我也曾有專利工程師來幫自己的 idea 申請專利的經驗，
我是原創人，那個申請文件寫出來，卻連我自己都看不太懂。
所以，這種寫成中文的妖魔鬼怪，其實是連資工人都看不懂，或者說，根本不想看，太痛苦了…
一些常用的英文術語，通通給你寫中文，超拗口的。
6 今日連結 (2005-05-26) [JeffHung.Blog] 引用：
2006 年十二月 19日於 11:15 am
「文件特徵自動擷取」專利迴避分析 - William 在這篇文章裡，示範了一場專利攻防戰，然後專利擁有者曾元顯老師也跳進來討論。在公司有需要生產專利的人，可以一看。 [...]

William’s Blog readings, ideas, feelings, photos, etc. by William Yeh

「文件特徵自動擷取」專利迴避分析

參考文獻

◤建議您一併閱讀以下文章：

6 項留言回應 給 “「文件特徵自動擷取」專利迴避分析”

留言回應

6 項留言回應給 “「文件特徵自動擷取」專利迴避分析”