顯示具有 open source 標籤的文章。 顯示所有文章
顯示具有 open source 標籤的文章。 顯示所有文章

2026年6月26日 星期五

上傳保密文件給AI的可能後果 - UK v. Secretary of State for the Home Department (UTIAC)

筆記

前篇討論「使用商用AI將放棄律師-當事人特權 - United States v. Heppner (S.D.N.Y. Oct. 28, 2025)」,其中涉及的議題是當事人尋求AI提供法律意見,但行為因為不符合Attorney-Client Privilege條件而失去特權保護,使得相關文件需要被揭露。

另有案例 - Glencore International AG v Commissioner of Taxation [2019] HCA 26,關於律師與當事人之間的權利義務關係,律師原本的工作就是維護當事人利益,當中需要雙方花時間充分的溝通、協助法律進程,以及在法庭上爭取權益,而現在的當事人已經沒有時間與律師慢慢磨了,動不動就找AI的幫助,超過律師可以控制的狀況。此案例主要問題是,當事人尋求AI協助法律問題,如果是將需要保密的部分提供給一般可公眾使用的生成式AI,這些保密內容有可能會提供給其他人,而使用者其實並不曉得AI到底會怎麼處理這些內容,甚至不曉得儲存在哪裡。(updated)

本篇參考的文章就提到幾件法院案例,其一為前篇報導的 - United States v. Heppner (S.D.N.Y. Oct. 28, 2025);本篇特別補充英國有案例 - UK v. Secretary of State for the Home Department (UTIAC),判決結果是上傳機密文件到開源的AI工具 - 如ChatGPT,將使相關資訊在網路上被公開,也就違法律師與客戶之間保密協定,並放棄了相關法律特權,主要是指律師-當事人特權(Attorney-Client Privilege)。(updated on June 28, 這裡我提出個疑點:此判決通篇說“open-source AI,如ChatGPT”,我覺得應該是指可讓公眾使用的AI(accessible to the general public),或說open AI,且經查不少資料,ChatGPT應不算open source AI。如果"open-source AI"用在地端,應該也不會有洩密的問題。)


UK v. Secretary of State for the Home Department (UTIAC)(UTIAC: Upper Tribunal Immigration and Asylum Chamber:上級法庭移民與庇護庭),摘錄如下:

上傳保密文件到開源AI工具,也就將資訊放在公眾領域,也就違反律師-客戶保密與拋棄法律特權。

這裡提到Microsoft Copilot沒有上述風險(?)。

這段說明AI訓練過程會產生illusion,在法律上的意見並不可靠。

my two cents:
一旦保密資訊成為公眾可存取的資料,法院也就沒有保密義務了。


Ron

2023年4月10日 星期一

非文字的軟體元件的著作權適用性(copyrightability)- SAS Inst. v. World Programming Ltd. (Fed. Cir. 2023).

案件資訊:
原告/上訴人:SAS INSTITUTE, INC.
被告/被上訴人:WORLD PROGRAMMING LIMITED
系爭軟體:SAS System v. WPS System
判決時間:April 06, 2023

本案緣起SAS於美國東德州地方法院對World提出著作權侵權訴訟,雙方於審判期間提出侵權與著作權適用性(copyrightability,編按,TIPO翻"可著作性",我覺得是"著作權適用性")等議題的簡易判決,經過審理,地院作出幾點判決:

1. SAS證實其擁有的軟體著作權登記。
2. World提出的證據證明其中軟體元件(software element)並未落入著作權法的保護範疇。
3. 根據World提出的證據,法院要求SAS證明相關軟體元件有受到著作權保護。
4. 運用抽象概念過濾比對(abstraction-filtration-comparison)測試原則(這是在著作權議題討論之前要指出其中受到著作權保護與未保護部分再進行比對的過程),地院判決SAS並未建立其宣稱的軟體具有"著作權適用性(copyrightability)",因此駁回SAS提出的專家報告,並撤銷訴訟。

於是SAS上訴CAFC。

----------- 系爭軟體 -------------
SAS販售自己開發的資料存取、管理、分析與表示軟體 - "SAS System",並開發出自己的程式語言-SAS Language,可讓使用者以GUI輸入程式碼,以進行分析,並且也登記著作權。特別的是,SAS System早先的版本曾進入公眾領域(public domain),意思是放棄著作權而讓大眾可以取得程式碼(open source),在不用授權的情況下能開發自己的產品。

World Programming公司也提出自己的軟體 - "WPS System",使用的語言正是SAS Language,提供與SAS System相同的功能。

SAS對World提出著作權侵權訴訟,認為World侵害SAS System與使用者手冊等著作權。但如上述,地方法院撤銷訴訟。
--------------------------------------

上訴議題包括:
1. 地院對於SAS軟體的"copyrightability"的意見有錯?其中討論copyrightability,特別包括"the filtration step of the abstraction-filtration-comparison test"議題。
2. 地院錯誤使用特別聽證("special hearing")進行判決?
3. 地院錯誤否決SAS專家報告?

(特別地,其中並未包括侵權議題!)

COPYRIGHTABILITY

軟體程式屬於文字上的工作,具有如文學作品的著作權,這裡特別定義"copyrightability"議題,就是討論著作中的特別元件(specific elements)是否落於著作權法的保護範疇內。


這裡所稱"特別元件/軟體元件",為非文字的元件(nonliteral elements),應是指經過編碼的功能性的元件,並不是可讀的文字。顯然,這部分的著作權適用性是傳統認知"文字表示的著作權"無法解決的問題,為了陪審團裁決,地方法院因此召開"Copyrightability Hearing"解決這個議題。

很特別的是,SAS並未對WPL中複製SAS System的程式碼主張著作權(編按,這部分應該是落入public domain),反而是主張WPL仿冒/侵害了SAS System的功能,但這就是導致敗訴的主張之一。

相關軟體元件如"Input Formats", "Output Designs"等,這些並非是文字表示的軟體元件,因此落入"copyrightability"的討論議題。

abstraction-filtration-comparison test

針對軟體元件的「copyrightability(著作權適用性)」,就是討論軟體元件是否受到著作權保護。果然,World採用了public domain的SAS早期版本,並證明WPS System中採用的"Input Formats"與"Output Designs"與現行SAS System中使用在public domain的功能一樣,SAS Language也屬於public domain,證明爭議中的軟體元件並未受到著作權保護。

在“filtration”測試下,World釐清了不受到著作權保護的相關軟體元件。


CAFC階段:

SAS並未明確指出自己擁有的系統中那些部分是受到著作權保護,反而World利用大量的證據證明WPS System採用了public domain的軟體功能,以及各種並非SAS原創的程式。

因此,回答了為何進入CAFC反而沒有侵權議題的問題,因為SAS在Copyrightability Hearing中並未提出證據證明SAS System中的軟體元件(功能性的元件)是受到著作權保護的部分,使得陪審團無法進行審理。

針對SAS主張World侵害其"Input Formats"與"Output Designs"等軟體元件的議題,SAS採用比較概念式的定義,不同於一般以文字理解著作權的方式,其專家證詞也無法釐清相關可受到著作權保護的部分,僅一昧地說明這是原創的軟體並不足以證明其著作權適用性。

基於以上種種,顯然是SAS準備不周,無法證明相關軟體功能是著作權保護的觀念與表示(Idea/Expression),也無法讓陪審團理解哪一部分是受到著作權保護,CAFC同意地院判決。





Ron

2023年2月17日 星期五

OpenAI要取得商標,簡單,但有阻礙

繼續蹭ChatGPT話題,順便學習商標識別性(distinctiveness)。

早上問候一下ChatGPT,問了OpenAI商標的問題,答案很"標準":

根據USPTO商標搜尋的結果,目前OpenAI公司提出的商標申請案有兩件狀態是"Live",並且都在審查過程中:

兩件目前的狀態都是「under examination/non-final office action」,顯示OpenAI的商標申請案目前尚在答辯中,遇到的問題是識別性的問題,最新核駁意見是「CLAIM OF ACQUIRED DISTINCTIVENESS NOT ACCEPTABLE」(摘錄no.97238902):

USPTO因為商標申請案不具識別性為由駁回申請案,OA中要求申請人提出更多證據來佐證商標申請案具備「acquired distinctiveness(取得識別性)」,或說是要申請人證明申請案具有第二含意(secondary meaning)。

這裡提到「acquired distinctiveness」,是一種「取得識別性」,也就是一般理解的第二含意「(secondary meaning)」,根據TIPO提出的研究報告(連結如下):「對於不具有固有識別性的標章,仍然可以經由證明已取得第二意義,而獲得商標之保護。在藍亨法(the Lanham Act)中並未使用「第二意義」一詞,而是稱為「取得的識別性」  (acquired  distinctiveness),此二詞意義相同。

可參考TIPO「美國商標法上識別性之研究」:https://www.tipo.gov.tw/tw/dl-4339-874368882fdc4847a5eab643387bc65b.html

文中註腳提到:「最高法院的意見表示:於兩種情況下,標章具有識別性而能夠受到保護:(1)具有固有識別性(inherently distinctive);(2)經由第二意義而取得識別性(acquired distinctiveness)。」

根據OpenAI商標申請案審查意見,審查委員引用案例「SeeConverse,  Inc. v. ITC (Fed. Cir. 2018) (“the Converse factors”)」建立的“the Converse factors”,也就是OpenAI要證明的幾個要件:

(1) 由消費者來看,商標與特定來源的連結;
(2) 使用的長度、程度和排他性;
(3) 廣告的數量和方式;
(4) 銷售額和客戶數;
(5) 故意仿冒;
(6) 非申請人要求的媒體報導(媒體自動報導)。

"When  determining  whether  the  evidence  shows  the  mark  has  acquired  distinctiveness,  the  trademark  examining attorney will consider the following six factors: (1) association of the mark with a particular source by actual purchasers (typically measured by customer surveys linking the name to the source); (2)  length,  degree,  and  exclusivity  of  use;  (3)  amount  and  manner  of  advertising;  (4)  amount  of  sales  and  number  of  customers;  (5)  intentional  copying;  and  (6)  unsolicited  media  coverage."

相關報導可參考:商品獨特性建立第二含意的標準 - 外觀商標與時間的關係 - Converse v. ITC and Sketchers, New Balance, et al. (Fed. Cir. 2018)(https://enpan.blogspot.com/2018/11/converse-v-itc-and-sketchers-new.html

my two cents:
按照OpenAI提出的ChatGPT的全球熱門程度,下次OA大概就是核准通知了!!!

OpenAI另有提出「CHATGPT」的商標申請案,尚在pending中。

Ron


2023年2月15日 星期三

ChatGPT告訴我OpenAI的美國專利?全錯!

註冊並使用了最近超夯OpenAI旗下的AI聊天機器人「ChatGPT」,想必以後這裡有些文章會運用ChatGPT自動生成???(可能需要升級到Plus)




可以向ChatGPT問出它的相關智慧財產是由OpenAI擁有,也列舉幾件專利,不過...請往下看。


這裡提到了以下幾件專利,但經查有些失誤,怪怪的!
  1. US Patent No. 10,765,951: "Generating Answers to Questions Using a Generative Model"
  2. US Patent No. 10,847,575: "Machine Learning with Gradient-Based Hyperparameter Optimization"
  3. US Patent No. 10,940,159: "Training Recurrent Neural Networks Using Skip-Connections and Mixed-Precision Computing"
  4. US Patent No. 10,965,162: "Learning Latent Representations Using Contrastive Multiview Coding"
  5. US Patent No. 11,009,076: "Unsupervised Representation Learning Using Contrastive Multiview Coding with Online Negative Sampling"
錯誤一:其中第一件提到US Patent No. 10,765,951,但經查,與AI無關,專利名稱也與ChatGPT講的不同,這裡就有錯誤,想要告訴ChatGPT,交談已經停止了。

再以名稱「"Generating Answers to Questions Using a Generative Model"」來查,也沒看到專利。

錯誤二:第二件US Patent No. 10,847,575是TSMC的專利,名稱也找不到OpenAI的專利。

錯誤三:第三件US Patent No. 10,940,159是一種醫藥類專利,明顯不是AI的技術。

錯誤四:第四件US Patent No. 10,965,162是蘋果的專利。

錯誤五:第五件US Patent No. 11,009,076是結構專利。

再問一次,這次用英文問:


以下是第二次得到的結果,驚訝的是,與以上結果不同!!!
  1. US Patent 10,719,227 - "Neural network-based dialogue agent" (granted on July 14, 2020)
  2. US Patent 10,879,309 - "Using computer vision to generate natural language descriptions" (granted on December 29, 2020)
  3. US Patent 10,900,714 - "Methods and systems for training and utilizing large-scale generative models" (granted on January 26, 2021)
  4. US Patent 10,990,100 - "Using neural networks for audio enhancement" (granted on April 27, 2021)
  5. US Patent 11,027,638 - "Integrating multimodal data for natural language processing" (granted on June 8, 2021)
錯誤六:US Patent 10,719,227是KONICA MINOLTA專利。

錯誤七:US Patent 10,879,309是TSMC專利。

錯誤八:US Patent 10,900,714是一種製程中的烘乾技術。

錯誤九:US Patent 10,990,100是無人車專利。

錯誤十:US Patent 11,027,638是Volvo專利。

 
my two cents:
結論是,有關專利的知識回答還蠻好的,但問出的OpenAI自己的專利都是錯的(它自己留有但書),不過還沒有測試專利相關的其他方面,所以只能說現階段還不能用ChatGPT進行專利檢索。

ChatGPT理論上會愈來愈強,但是目前還沒有可以到"完全信賴"的階段,應該每個領域不同,顯然要形成有用的法律意見,還是需要一些驗證。

不久之後~~~
繼續往下聊(基本上我是用問的,沒有聊...下次再來看看能否聊出一篇文章/專利?!!),可能太多人使用,問了幾句就...當了,或是應該要購買Plus(每個月20美元):



Ron

2021年7月8日 星期四

我國電腦相關發明審查基準修正筆記之三

撰寫電腦相關發明專利說明書時,也是會碰到其他技術領域的專利中不明確的問題,因此規則應該都是可以互相套用,只是電腦相關發明還是有些獨有的特性,特別是很喜歡自己發明技術用語。我個人的判斷是,只要理工背景的人應該有電腦程式撰寫能力(誰在大學中沒有碰過程式撰寫呢?),應該有能力理解電腦相關領域發明專利,甚至切入此領域撰寫工作(資訊背景的人較佳,但據了解這類硬背景的人比較少人從事專利撰寫工作),認真一點會去follow新技術領域就可以了,如大數據、區塊鏈、AI、IOT等,再積極從發明人學習新事物。本篇筆記新修正電腦相關方法審查基準「請求項的記載原則」中「2.2.3請求項不明確之情形」,本次修正的特色是"很務實"地呈現實地撰寫專利說明書的工作面對的問題。


以下筆記有加上我個人的意見與實務經驗。

2.2.3.1執行步驟或功能的主體不明確

電腦相關發明的專利範圍通常以步驟流程表示,且會用「動詞」作為技術特徵,但是有些動詞的動作可能"主體"不曉得是誰?是人?電腦?軟體還是硬體?因此有時需要"交代"是誰執行某個步驟。

因此「角色扮演」可能是撰寫這類專利範圍的人需要考量的,用保護主體作為主詞,審查基準列舉的範例表達出主體不明確的情況之一。

〔請求項〕一種接收商品訂單之方法,包含下列步驟:
利用電腦自客戶接收商品訂單;
查詢該商品之庫存情形;
當該商品有庫存時,通知該客戶可寄送商品;
當該商品無庫存時,通知該客戶無法寄送商品。

誰"查詢"?誰"通知"?解決方式就是在前言提出所述方法「由電腦載入程式」所執行,主體就出來了!

2.2.3.2界定發明之技術特徵不明確

電腦相關發明常常會引述特定技術、演算法、規則、邏輯、虛擬機器等,發明人都可能不容易了解全貌,因此會造成撰寫專利說明書的困擾,因此建議即便不清楚其中狀況,但總可以歸納出方法論(methodology),用流程表達其中步驟與判斷邏輯。我舉的範例是,面對AI演算法,很多很多開源的演算法,可能需要揭露"演算法名稱"、利用特定演算法的methodology等。

審查基準列舉範例〔請求項〕一種解題電腦,使用"右腦推論規則"來解答難題。這裡"右腦推論規則"就需要把其中運作方法描述出來。

2.2.3.3表現方式所致之不明確

電腦相關發明常常會涉及「功效的增進、達到的優點」,比如利用一個方法"加速"運算效能、降低硬體成本、節省時間等功效,需要揭露具體辦法。

審查基準範例:
〔請求項〕一種編譯機器,包含:一"高速語彙分析裝置";及一語法分析裝置;其中該二裝置能夠"平行"處理。

此範例請求項內容的一些用語需要更明確的說法,或是不說,避免不明確,如「高速」需要有比較基準。

2.2.3.4範疇不明確

這部分討論是軟硬不分的問題,如果請求項中使用「架構」、「機制」、「平台」、「雲端」等用語,在資訊領域的人可能可以理解,但嚴肅的法律文件中需要明確的定義,就在說明書好好地描述實施例,並明確以圖文表達其中技術內容。

剛好想到一個例子,會在英文專利說明書中看到"heuristic"與"logic"用語,好像可以理解,又覺得好像不容易理解。範例US10,957,358

1. A system, comprising:
  • one or more computer processors;
  • and memory storing program instructions that are executed by the one or more computer processors to implement a heuristic-based analyzer configured to:
  • evaluate captured video to detect one or more faces in at least a first frame and a second frame of the video;
  • and in response to detection of one or more faces in the video, analyze at least a portion of the first frame of the video including the detected one or more faces with one or more face-scenario-specific heuristics to produce a first image quality metric;
  • analyze at least a portion of the second frame of the video including the detected one or more faces with the one or more face-scenario-specific heuristics to produce a second image quality metric;
  • and output a video quality metric based at least in part on the first image quality metric and the second image quality metric.
US10,554,786

1. A method comprising:
  • initializing, by a sampling daemon executing on a mobile device, a heuristic process;
  • registering the heuristic process with the sampling daemon to cause the heuristic process to receive event data of the mobile device;
  • obtaining, by the heuristic process, the event data from the sampling daemon;
  • determining, by the heuristic process, a peer forecast for an attribute specified by the event data;
  • determining, by the heuristic process, component settings for the mobile device based on the event data and the peer forecast;
  • and transmitting, by the heuristic process, the component settings to a control multiplexer of the mobile device to adjust settings of one or more components of the mobile device.
US9,335,924

1. A computing device, comprising:
  • a touch screen display;
  • one or more processors operative coupled with the touch screen display;
  • memory;
  • and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs when executed by the one or more processors cause the device to perform:
while a first application user interface is displayed on the touch screen display:
  • detecting one or more first finger contacts on the first application user interface;
  • applying a first set of heuristics to the one or more first finger contacts to determine a first command in the first application, wherein the first set of heuristics comprises:
  • a vertical screen scrolling heuristic for determining that the one or more first finger contacts correspond to a one-dimensional vertical screen scrolling command rather than a two-dimensional screen translation command based on an angle of movement of a finger contact with respect to the touch screen display;
  • and a two-dimension screen translation heuristic for determining that the one or more first finger contacts correspond to a two-dimensional screen translation command rather than the one-dimensional vertical screen scrolling command based on the angle of the movement of the first finger contact with respect to the touch screen display;
  • and processing the first command;
  • and while a second application user interface is displayed on the touch screen display:
  • detecting one or more second finger contacts on the second application user interface;
  • applying a second set of heuristics to the one or more second finger contacts to determine a second command in the second application, wherein:
  • the second set of heuristics is different from the first set of heuristics, and the second set of heuristics comprises a next-item heuristic for determining that the one or more second finger contacts correspond to a command to transition from displaying a first element in a collection of elements to displaying a next element in the collection;
  • and processing the second command.
"heuristic"很難理解呀?!?

2.2.3.5手段(步驟)功能用語的不明確

撰寫電腦相關專利範圍時,難以避免地需要"以各種面貌的形式"使用「功能/步驟手段用語」,因此需要在說明書中提供裝置、結構或動作的支持內容,避免不明確。

審查基準指出「請求項中之手段(步驟)功能用語於解釋時,應包含說明書中所敘述對應於該功能之結構、材料或動作及其均等範圍」,「無法由說明書中判斷對應於該功能之結構、材料、動作或達成該功能之電腦軟體演算法或硬體構件,通常會導致請求項不明確」,還有「當申請人採用手段功能用語或步驟功能用語解釋請求項時,請求項之特徵將包含說明書中所敘述對應於達成該功能之必要結構、材料或動作及其均等範圍,惟並非直接限縮於說明書中所載之實施例,其中該均等範圍應以申請時該發明所屬技術領域中具有通常知識者不會產生疑義之範圍為限」。

2.2.3.6欠缺必要技術特徵

這個不明確理由會發生在所有技術領域的專利範圍中,就看看審查基準提出的範例。

〔請求項〕一種微處理器排程方法,包含下列步驟:
在記憶體所構成之多層佇列內將資料從一佇列轉送至另一佇列;
每一佇列設定一權重值,其中該權重值係依據資料處理所使用之CPU時間而設定;及
一微處理器參照各權重值控制資料輸出,使資料輸出之負載變成均等方式,以提高資料處理之效率。

因為專利範圍明顯的重點是「每一佇列設定一權重值」,效果是「使資料輸出之負載變成均等方式」,因此怎麼設定權重值確實是個重要的必要特徵,講不清楚就會不明確。

另可參考前面兩篇:
我國電腦相關發明審查基準修正筆記之一(https://enpan.blogspot.com/2021/07/blog-post.html
我國電腦相關發明審查基準修正筆記之二(https://enpan.blogspot.com/2021/07/blog-post_4.html

Ron

2021年7月1日 星期四

我國電腦相關發明審查基準修正筆記之一

TIPO公布新版「電腦軟體相關發明審查基準」,修正「專利審查基準」第二篇第十二章電腦軟體相關發明,並自中華民國110年7月1日生效(https://topic.tipo.gov.tw/patents-tw/cp-750-891201-9f474-101.html


從這張簡化的表來看(原則上不脫一般的理解,標準仍是很寬鬆),可知被認定符合發明定義的電腦軟體發明條件主要是「使用電腦軟體與硬體資源所實現的發明」,如:(1)有具體執行對機器的控制或處理者;(2)具體執行有技術性質的資訊處理者。不符發明定義的為:(1)人為安排、數學公式、商業方法;(2)單純資訊揭示。

基準中的流程圖:

進步性:
審查進步性時,可舉出有動機結合多件引證案證明發明不具進步性,參考修正後4.2.2.1節規定:
4.2.2.1否定進步性之因素
4.2.2.1.1有動機能結合複數引證判斷該發明所屬技術領域中具有通常知識者是否有動機能結合複數引證之技術內容時,原則上得綜合考量「技術領域之關連性」、「所欲解決問題之共通性」、「功能或作用之共通性」及「教示或建議」等事項。由於電腦軟體技術通常可應用於各技術領域,不應僅以複數引證之技術領域無關連性即直接認定無動機結合該等引證。(編按,這是很棒的答辯/申復前言)

其中列舉6種「簡單變更」態樣(4.2.2.1.2節):
1) 技術領域之轉用。
2) 將人類所進行之作業方法予以系統化。
3) 將先前硬體技術所執行之功能軟體化。
4) 在電腦虛擬空間重現申請時之通常知識。
5) 申請時通常知識之應用或變更。
6) 無助於技術性效果的特徵。


據以實現要件:
針對經常面對的人工智能(AI)方面的發明,常常面對的是「2.1.1 可據以實現要件」,也就是揭露發明內容的程度,如此節提到,電腦軟體發明常以功能界定,為使該發明所屬技術領域中具有通常知識者能據以實現,說明書應明確且充分描述實現該功能的相關技術內容(例如演算法),當希望發明人可以適當地揭示其演算法時,常常面臨的問題是『講不出來』,不是不懂,而是不曉得怎麼表達。

本篇審查基準很務實地講出要如何描述這類發明:得於圖式中輔以「1.流程圖」或「2.功能方塊圖」加以說明,必要時,亦得輔以3.資料流程圖、4.虛擬碼、5.時序圖、6.程式碼片段等揭露其技術特徵。(看來這裡建議有6種表達方式)

圖式中若以流程圖表現,說明書應配合該流程圖的操作順序描述方法的各步驟。若以功能方塊圖表現, 說明書應描述該功能方塊圖中,軟體各模組與硬體各構件之相互關連或硬體各構件之間的連結關係,對於特別設計之硬體,則須更明確界定構 件之邏輯電路結構,使該發明所屬技術領域中具有通常知識者,依說明書能了解解決問題之技術手段並可據以實現。

更進一步地,基準很務實地提到:如係藉助特定的軟、硬體工具或架構據以實現其功能,例如特定的程式語言、函式庫、整合開發環境(IDE)、工具套件、資料庫、 (類)神經網路模型等,不論其屬商用或開源(open source),應於說明書中予以揭露。例如申請專利之發明係以某商用晶片及相關開發軟體套件加以實現,應於說明書中揭露足以特定出該商用晶片、開發軟體套件之相關內容,如晶片名稱與型號、開發軟體套件名稱與版本,以及其他足使該發明所屬技術領域中具有通常知識者能依說明書內容據以實現 之技術內容。

編按,面對發明人採用特定AI演算法時,表示是採用已經發佈的演算法(屬於已知技術),一般希望發明人適當地揭示使用此演算法達成的軟體流程,概念上亦可,主要還是要描述到「使該發明所屬技術領域中具有通常知識者能了解該發明之內容並可據以實現」的程度。

電腦軟體相關發明審查基準修正懶人包(https://topic.tipo.gov.tw/patents-tw/cp-673-893182-61f5d-101.html

我國現行專利審查基準第二篇第十二章電腦軟體相關發明(https://topic.tipo.gov.tw/patents-tw/dl-279430-1805a40a70894a7fbf6eebe20eed2a30.html


Ron

2021年4月6日 星期二

Google合理使用JAVA API程式 - Google LLC v. Oracle America, Inc. (Supreme Court 2021)

美國最高法院於2021年4月5日判決出爐:Google合理使用JAVA API程式 - Google LLC v. Oracle America, Inc. (Supreme Court 2021),推翻2018年CAFC判決Google侵害著作權成立的決定。

編按,根據過去一路追蹤的理解,其實各方說法都有道理,只是,就API本質與使用目的而言,就像是標準,如USB、WiFi、Bluetooth,但其涉及的是「程式碼」,不像是一般的著作,合理使用成為重要的議題。這樣想,合理使用是很合理的!但著作權人取得合理利益應該也是合理的(或者需要通過專利授權!)。

一提的是,考量市場因素,陪審團與法官都認為Oracle很難進入手機市場,人家(指Google)拿去用僅是因為這個市場的程式開發人員熟悉Java語言而已,沒有傷害公共利益!

GOOGLE LLC v. ORACLE AMERICA, INC.案件資訊:
(from Syllabus of April 5, 2021 Supreme court decision

最高法院判決:

本次討論的議題涉及延續10年的爭議,故事源自Oracle(甲骨文)公司於2009年4月(距今12年)把系統大廠Sun Microsystems(昇陽電腦)(編按,當年開發Java後在網路伺服器市場呼風喚雨)買下,即擁有Java原始碼版權與相關專利權。之後,從專利侵權開始,例如Sun於1998年獲得US5,966,702,2010年轉讓給Oracle,次年即向Google提出侵權告訴。

2010年訴狀的一些資訊:


歷經10年,案件進入最高法院,主要議題就是Google是否合理使用Oracle自Sun Microsystems取得的Java的37個API?

2021年最高法院意見:

Oracle通過交易取得Java SE版權,Google從2005年就開始開發Android並採用Java中的11500行程式碼,即API,讓Android平台的程式開發者在此基礎上開發Android應用軟體,"時機成熟",Oracle開始"回收"自己的投資,向Google提出侵權告訴,法院考量的是,是否Oracle可以主張API的著作權?如果可以,Google是否合理使用(fair use)這些程式碼?

議題落於,Java SE API是否可主張著作權(copyrightability)?是否Google可以合理使用(fair use)這些程式碼?

(編按,SE指的是"standard edition",既然是"標準版本",其原始意圖應該是要公開成為標準!API指的是application programming interface,既然是"介面",其中隱含的意思應該也是公開使用的介面。)

Google認為合理使用的理由:
"Google envisioned an Android platform that was free and open, such that software developers could use the tools found there free of charge."

基於開放原始碼的精神,法院參考了相關領域的意見:
"As Android’s founder explained, “the whole idea about open source [platform] is to have very, very few restrictions on what people can do with it,” and Sun’s interoperability policy would have undermined that free and open business model."

定義:著作權(copyright)授予原始作者取得一段時間內的排他權,但因為這可能有負面的後果,因此著作權保護範圍仍有限制,使得著作權人的壟斷權不會傷害公共利益!

法律:法律提供的著作權保護並未延伸到"任何想法、程序、流程、系統、運作方法、概念、原理或發現",著作權人不能防止其他人可以"合理使用"其著作。

相關法條:
17 U.S.C. § 102 Subject matter of copyright:  In general
(b)  In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

17 U.S. Code § 107 - Limitations on exclusive rights: Fair use
Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright. In determining whether the use made of a work in any particular case is a fair use the factors to be considered shall include— 
(1)the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes; 
(2)the nature of the copyrighted work; 
(3)the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and 
(4)the effect of the use upon the potential market for or value of the copyrighted work. 
The fact that a work is unpublished shall not itself bar a finding of fair use if such finding is made upon consideration of all the above factors.

最高法院的判決基礎是,設定相關Java SE API程式碼具有著作權,可被著作權法保護,審理Google是否合理使用這些程式碼?

法院認為,電腦程式碼的著作權與一般著作權不同,因為電腦程式碼是有功能目的的,因此,電腦程式碼的合理使用成為其主要的討論議題。最高法院判定在地院陪審團的判斷中,由於合理使用是個法律議題,而非事實的判斷,因此最高法院先釐清陪審團審判權(right of trial by jury)並不包括有權可以解決合理使用辯護的議題

同樣地,著作權合理使用的判斷也是依循著著作權法提出的4個考量因素:
(1)考量使用的目的與性質;
(2)考量著作的本質;
(3)考量使用的部份與著作整體的數量與實質性;以及
(4)考量使用著作對市場與版權的價值的影響。

這幾個考量因素的重要性會因個案不同。

最高法院意見:
1. 本案著作權的本質是提供"使用者(針對程式開發者)介面"(API),因此又與一般電腦程式的著作權保護有所不同。
2. Google有限度使用相關程式碼是用於「transformative use(轉換的使用)」,Google僅複製要讓程式開發者開發可以在不同電腦環境運作而無須拋棄熟悉的部份的程式碼
3. Google所複製上萬行的程式碼僅佔所有API程式的0.4%,並且其動機是要讓程式開發者可以讓其技能運用在新的移動裝置平台上。
4. Google的移動裝置平台的市場與Java SE市場不同,並非取代,且事實顯示Oracle使用Java SE的利益是在不同的市場,因此並不會造成公共利益的損害。
5. 法院認為電腦程式著作主要是其功能,很難適用一般著作權,且Google僅因其目的而使用一小部份程式碼。

最高法院判決:Google複製Java SE API程式碼的需求是因應程式開發新的與可轉換程式的需要,法律上為合理使用!

Held: Google’s copying of the Java SE API, which included only those lines of code that were needed to allow programmers to put their accrued talents to work in a new and transformative program, was a fair use of that material as a matter of law.

最高法院駁回(發回重審)CAFC判決。Android程式的開發者可以喘一口氣了!

---------------------------------------------
重點摘錄:

A. “The Nature of the Copyrighted Work”

"The Sun Java API is a “user interface.” It provides a way through which users (here the  programmers) can “manipulate and control” task-performing computer programs “via a series of menu commands.”"

"... unlike many other programs, its use is inherently bound together with uncopyrightable ideas (general task division and organization) and new creative expression (Android’s implementing code)."

B. “The Purpose and Character of the Use”

"Google copied portions of the Sun Java API precisely, and it did so in part for the same reason that Sun created those portions, namely, to enable programmers to call up implementing programs that would accomplish particular tasks."

"It copied the API (which Sun created for use in desktop and laptop computers) only insofar as needed to include tasks that would be useful in smartphone programs."

C. “The Amount and Substantiality of the Portion Used”


"Google copied those lines not because of their creativity, their beauty, or even (in a sense) because of their purpose. It copied them because programmers had already learned to work with the Sun Java API’s system, and it would have been difficult, perhaps prohibitively so, to attract programmers to build its Android smartphone system without them.
"

(編按,著作權侵權或合理使用的其中之一考量是,複製的目的是因為其創造性、美感或是其目的,就可能非合理使用,這也常見於網路文章抄抄抄的內容,如果連"表達方式"都抄入,就明顯有侵權問題,電腦程式比較沒有為了美感而寫的程式碼(其實,可能有程式開發者會反對這個說法!)。Google可以說服人的是,其複製的目的是因為程式開發者已經熟悉Java API)

D. Market Effects

"In any event, the jury’s fair use determination means that neither Sun’s effort to obtain a license nor Oracle’s conflicting evidence can overcome evidence indicating that, at a minimum, it would have been difficult for Sun to enter the smartphone market, even had Google not used portions of the Sun Java API."

"Google’s copying helped Google make a vast amount of money from its Android platform. And enforcement of the Sun Java API copyright might give Oracle a significant share of these funds."

"The uncertain nature of Sun’s ability to compete in Android’s market place, the sources of its lost revenue, and the risk of creativity-related harms to the public, when taken together, convince that this fourth factor—market effects—also weighs in favor of fair use."

(編按,陪審團認為Oracle或Sun很難進入手機市場,即便Google沒有使用Java API也難)

API示意圖:
"For each method, the declaring code is associated with particular lines of implementing code (the dotted arrow). It is that implementing code (which Google wrote for its Android API) that actually instructs the computer in the programmer’s application."

---------------------------------------------
過去報導:(編按,本部落格從2010年追蹤Oracle以專利侵權為由開始與Google周旋,到2021年以著作權定論)

- 美國最高法院將要對Google v. Oracle著作權爭議提出意見(https://enpan.blogspot.com/2020/10/google-v-oracle.html
- 合理使用著作權標的的四個判斷因素 - Oracle America, Inc. v. Google LLC (Fed. Cir. 2018)(https://enpan.blogspot.com/2018/03/oracle-america-inc-v-google-llc-fed-cir.html) 

"CAFC使用四個合理使用因素,法官判定:

(factor one)Google確實為商業使用,雖沒有用Android授權取得利益,但是最終販賣的手機仍是商業行為;即便Google有重新撰寫了部分的功能,但是與原本程式差異不大,為一樣的功能與目的,確不構成「transformative」(轉變);雖Google還不至於構成惡意(bad faith),因為以上兩個理由,仍不符合理使用的第一個因素。

(factor two)這個因素是考量是否著作權本身有開創性,法官認為37個API具有開創性,使得Google不得不用,而不容易重新撰寫程式,因此這點符合合理使用。

(factor three)即便Google有加上自己的程式,卻不影響使用了原本程式的比例,這點是看Google使用了多少比例的原始碼。Google為了要顧及社群程式開發,並加上不容易開發相同的功能,因此就沿用多數程式碼,因此這部分是否合理使用,法院持平看待。

(factor four)最高法院曾表示第四個因素是合理使用最重要的判斷因素。對市場而言,「傷害(harm)」是指主張著作權程式碼對於真實或預期市場的傷害,以及對於潛在衍生使用的傷害。Google主張,Oracle並非製造裝置,也沒有開發自己的手機平台,因此認為自己是合理使用。

不過,法官認為(編按,其實很有道理),有關潛在市場,不僅是直接製造商,也關於授權他人使用,因此Google主張無效。由於Oracle有意授權行動電話使用,著作權也保護著作權人進入潛在市場的權利,將來可能成為競爭者,因此判斷Google不符合理使用。

最終,經平衡上述四點,並考量著作權的目的,判決Google不符合理使用Oracle Java APIs的條件"

- Android中使用Java API為合理使用? - Oracle v. Google(https://enpan.blogspot.com/2016/06/androidjavaapi-oracle-v-google.html) 

地院於2016年(第二次)判決Google為合理使用:

"判決表示,根據前例,電腦程式的結構、程序與組織(the structure, sequence and organization of a computer program)是根據每案的特定事實來判定是否為可保護的標的,且判斷時總是會排除不受保護的部分。判決表示此Oracle v. Google案就是落於不保護的部分

針對這回Java API的爭議,爭議的為166個API(packages)中的37個API。Android作業系統中有97%為Google新開發的程式,剩餘3%為可自由代換(也就是被主張侵權的部分),顯然陪審團用"使用比例"來作判斷。判決認為,如果同意Oracle的主張,將會允許每個人針對實現一個系統的一版本程式主張著作權,如此,將可能禁止他人撰寫不同的版本去實現相同的功能。"

- Oracle與Google針對JAVA程式著作權的爭議(Google合理使用?)(https://enpan.blogspot.com/2013/02/oraclegooglejavagoogle.html) 
- Oracle與Google的著作權爭議現階段CAFC態度(https://enpan.blogspot.com/2014/06/oraclegooglecafc.html) 
- Google與Oracle因為Java開打(https://enpan.blogspot.com/2012/04/googleoraclejava.html) 
- Oracle告Google - 看專利學專利(About Claims XXXIII)(https://enpan.blogspot.com/2010/08/oraclegoogle.html

查詢相關專利轉讓資料:Patent Assignment Search(https://assignment.uspto.gov/patent/index.html#/patent/search

Ron

2020年10月14日 星期三

美國最高法院將要對Google v. Oracle著作權爭議提出意見

關於Google與Oracle的著作權爭議十分時代性,關於傳統觀念的著作權與現今科技開源碼的權利歸屬,從過去兩邊爭議的歷程可以獲得許多重要的資訊,例如判斷著作權合理使用的條件?但是如果是「開發軟體的使用者介面」是否也是合理使用的範疇,這就是掌握平台的重要目的,如果連使用平台提供的介面都產生著作權議題,就會有點影響深遠。


對於Google以及廣大使用Android使用者而言,由於"沒有別的選擇"(沒有取代物),"侵權"是一個必然過程,而"合理使用"是一個救贖,掌握java原始碼著作權的Oracle是否有因為"被使用"而產生傷害是主要判斷是否侵權或是合理使用的關鍵。然而,對於全球最大公司之一的Google而言,若判斷為「合理使用」卻又不是很"合理"!因此最高法院意見成為全球關注的議題。


根據IDC(https://www.idc.com/promo/smartphone-market-share/os)報導,雖然iPhone/iOS超級厲害,也是大家關注焦點,Android的手機相對新聞量較少(這是我在自己環境的感覺),Android在全球市占率仍逐年升高,使得Google"轉身不易",侵權判下去真的是"意義重大"。


2018佔有率統計:Android:85.1%;iOS:14.9%(編按,避免著作權問題,還是去原頁面看好了,雖然我也可以主張合理使用!!!)

Google搜尋IDC的畫面:


最高法院議題:


根據patently-o部落格的資訊,可知美國最高法院在10/07/2020設定好言詞辯論的議題(前兩個是最高法院文件呈現的問題,後兩個應該是附加議題):

(1)著作權保護是否及於「軟體程式碼」以及「程式語言的組織架構」?

(2)是否使用用於建立新的程式碼的「軟體介面」為合理使用(fair use)?

(3)(法院的請求)陪審團決定「合理使用」的角色為何?

(4)專利在軟體程式碼保護的角色為何?(Crouch律師提出)


本次最高法院議題主要是根據2018年CAFC判決(合理使用著作權標的的四個判斷因素 - Oracle America, Inc. v. Google LLC (Fed. Cir. 2018)(https://enpan.blogspot.com/2018/03/oracle-america-inc-v-google-llc-fed-cir.html)。

CAFC判決以及引用的四個判斷因素:

(factor one)Google確實為商業使用,雖沒有用Android授權取得利益,但是最終販賣的手機仍是商業行為;即便Google有重新撰寫了部分的功能,但是與原本程式差異不大,為一樣的功能與目的,確不構成「transformative」(轉變);雖Google還不至於構成惡意(bad faith),因為以上兩個理由,仍不符合理使用的第一個因素

(factor two)這個因素是考量是否著作權本身有創造性,法官認為37個API具有開創性,使得Google不得不用,而不容易重新撰寫程式,因此這點符合合理使用

(factor three)即便Google有加上自己的程式,卻不影響使用了原本程式的比例,這點是看Google使用了多少比例的原始碼。Google為了要顧及社群程式開發,並加上不容易開發相同的功能,因此就沿用多數程式碼,因此這部分是否合理使用,法院持平看待

(factor four)最高法院曾表示第四個因素是合理使用最重要的判斷因素。對市場而言,「傷害(harm)」是指主張著作權程式碼對於真實或預期市場的傷害,以及對於潛在衍生使用的傷害。Google主張,Oracle並非製造裝置,也沒有開發自己的手機平台,因此認為自己是合理使用


------------------------------

Oracle v. Google的爭議歷程(以下為本部落格報導,事實上,應該是有漏掉一些過程,有興趣者還是要多方參考相關資料):

- 合理使用著作權標的的四個判斷因素 - Oracle America, Inc. v. Google LLC (Fed. Cir. 2018)(https://enpan.blogspot.com/2018/03/oracle-america-inc-v-google-llc-fed-cir.html

- Android中使用Java API為合理使用? - Oracle v. Google(https://enpan.blogspot.com/2016/06/androidjavaapi-oracle-v-google.html

- Oracle與Google針對JAVA程式著作權的爭議(Google合理使用?)(https://enpan.blogspot.com/2013/02/oraclegooglejavagoogle.html

- Oracle與Google的著作權爭議現階段CAFC態度(https://enpan.blogspot.com/2014/06/oraclegooglecafc.html

- Google與Oracle因為Java開打(https://enpan.blogspot.com/2012/04/googleoraclejava.html

- Oracle告Google - 看專利學專利(About Claims XXXIII)(https://enpan.blogspot.com/2010/08/oraclegoogle.html


資訊來源:

https://patentlyo.com/patent/2020/10/this-supreme-court.html

https://www.ipwatchdog.com/2020/10/09/barks-bites-friday-october-9-scotus-discusses-industry-effects-oracle-v-google-uspto-issues-ai-report-crispr-inventors-win-nobel-prize-chemistry/id=126127/

https://www.ipwatchdog.com/2020/10/07/justices-look-reassurance-sky-wont-fall-google-v-oracle/id=126052/


Ron

2018年10月12日 星期五

微軟帶槍投靠OIN的遠景

我從網路上片片段段的新聞中找到一些信息如下。

微軟帶槍投靠,微軟帶著60000專利加入OIN(https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/),此舉讓加入OIN(https://www.openinventionnetwork.com/)的人在使用Linux或開源技術時可以免於這些專利組合的專利干擾(royalty-free)。

"The OIN patent license and member cross-licenses are available royalty-free to anyone who joins the OIN community."

"Microsoft now finds itself as one of the largest contributors to open source."

過去報導:微軟加入OIN(https://enpan.blogspot.com/2018/10/open-invention-network-open-invention.html

微軟此舉似乎"放棄"對Android的授權金,過去至少因為專利授權自使用Android系統的公司取得60億美元的收益,例如,三星在2013年曾經付出10億美元的授權金給微軟,平均賣一台裝置就要付出3塊多美元的授權金。(富比士新聞:https://www.forbes.com/sites/ewanspence/2015/11/01/microsoft-android-patent-income/#32f45e8f5c6c

這是有跡可循,包括Microsoft日前(June 4, 2018,75億美元)宣佈買下世界最大的軟體開發平台GitHub,當時業界戰戰兢兢,擔心微軟"來者不善",...加上加入OIN的善意,包括對OIN中開源碼社群的大老會員IBM, Novell, Red Hat...等的善意,這些應該是要透過開放原始碼強大的社群來壯大微軟建造的雲端平台 - Azure,假想敵應該是Amazon的AWS Amazon Cloud‎

Microsoft貢獻的專利組合,這裡說,是除了微軟作業系統與桌面應用以外的全部專利。

"The donation encompasses almost all of Microsoft's patent portfolio, with the exception of a number of patents relating to Windows and desktop applications."

微軟的企圖應該是要吸引Linux等開源碼社群的開發者加入這個雲端平台來開發軟體。

"At Microsoft, we take it as a given that developers do not want a binary choice between Windows versus Linux, or .NET versus Java - they want cloud platforms to support all technologies."

一點點微軟的專利分析(僅美國專利)。
有關microsoft的專利權人:


以專利權人"MICROSOFT TECHNOLOGY LICENSING, LLC"為例的專利分布:


微軟在所佈局的幾個類別中都名列前茅:


(工具:Patent Buddy)

新聞:
https://www.computing.co.uk/ctg/news/3064361/microsoft-donates-60-000-patents-to-open-source-as-it-joins-open-invention-network
https://www.zdnet.com/article/what-microsoft-buying-github-means-to-open-source-software-development/
https://www.forbes.com/sites/jasonevangelho/2018/10/11/microsoft-just-open-sourced-60000-patents-proving-it-really-does-love-linux/#454830b93807

微軟最新的狀態:
https://www.microsoft.com/en-us/legal/intellectualproperty/iplicensing/default.aspx
全球核准專利標註為60000+)


my two cents:
擁有專利權,可行使權利,但又放棄權利,就受到尊敬,這也是專利的遊戲規則之一。

Ron