微軟與阿爾卡特的專利官司勝負難分
2007年2月份美國加州聖地牙哥法院甫宣判，微軟公司必須支付約15億美元（折合新台幣近500億元）給阿爾卡特（Alcatel-Lucent）公司，以解決微軟公司產品使用MP3技術所引發的糾紛。不過在3月初，另一位聯邦法官Rudi Brewster做出一項裁定，駁回阿爾卡特公司所有的主張，因為阿爾卡特公司主張微軟公司侵害一項其所有之有關語音編碼的技術專利。
微軟與阿爾卡特的專利官司可追溯至2003年，當時未合併前的朗訊（Lucent，二公司於2006下半年合併）公司控告PC製造商Dell與Gateway使用其所擁有的MP3技術專利。微軟公司後來被捲入這場專利糾紛，與阿爾卡特（Alcatel-Lucent）公司專利官司的糾紛日益擴大。二家公司爭訟的結果，在2月份的判決，根據2003年5月以來微軟公司所賣出的每台Windows PC數目，來計算出可能造成的損失，所以微軟公司才必須付出約15億美元的天價。
但是3月的這項裁定，卻阻止阿爾卡特公司趁勝追擊。在知識經濟的時代中，專利訴訟的結果甚至可能影響一家公司的興亡，相信沒有多少家公司可以輕易付出15億美元的賠償，如何確保不侵犯他人的智慧財產是很重要的課題。此外，爭訟的雙方都是業界的重量級廠商，不論結果如何，後續的發展都值得大家關注。
本文為「經濟部產業技術司科技專案成果」
BRCA1與BRCA2乃兩個已經被確認的基因，係用來檢測婦女是否容易罹患乳癌或卵巢癌的重要基因。在澳洲這個檢測產品是由基因技術有限公司（Genetic Technologies Limited, 以下簡稱GTL）所擁有。因檢測費用高達3,700元美金且無法有其他的檢測選擇，形成獨占。 今（2010）年3月，美國紐約聯邦地方法院（United States District Court Southern District of New York）認為BRCA1與BRCA2等人類基因乃如同血液、空氣或水的結構，屬於自然的產物，不具有可專利性，系爭專利阻礙了乳癌與卵巢癌相關研究與創新，並限制檢測的選擇性，因而作出BRCA1與BRCA2基因不具可專利性之判決。 受到美國判決之影響，今（2010）年6月澳洲的癌症之聲消費者團體（Cancer Voices），及一名患有乳癌的婦女同向雪梨聯邦法院（Australian Federal Court in Sydney）提起訴訟，希望免除GTL對於檢測乳癌與卵巢癌產品的獨占權利。主要理由包括，對人類的一部分（基因）給予專利，不但阻礙了後續研究，也會阻礙乳癌與卵巢癌治療方法的研發，更提高許多病患接受此檢測的障礙。固然專利權人得維持高檢測費用，但有別於傳統工程或技術上的專利，生物技術專利也含有高度追求人類健康之公共利益，因此握有生物技術專利者，實不應利用獨占地位阻礙的人類健康的維持與追求，阻礙醫療或治療方式的研究。 過去澳洲專利局認為自自然產物分離的基因或物質是具有可專利性的，此案若勝訴，澳洲專利局將調整原先承認自自然產物分離的基因或物質，具可專利性之見解，所以該案的後續發展值得我們關注。
歐盟理事會修正《第428/2009號歐盟理事會規章》，提升歐洲軍民兩用出口管制力度歐盟理事會與歐洲議會於2020年12月14日，針對歐洲軍民兩用出口管制法規《第428/2009號歐盟理事會規章》（COUNCIL REGULATION (EC) No 428/2009）達成修正協議，並獲得歐盟理事會下設常駐代表委員會（Committee of Permanent Representatives, COREPER）認可後正式通過。《規章428/2009》用以規範歐盟軍民兩用出口管制，監管歐盟涉及「軍民兩用」敏感貨品、服務、軟體和技術的對外出口、內部轉口及過境貿易。因兩用貨品包含軍事用途及商用用途，故此次歐盟調整軍民兩用出口管制的相關規則，主要考量面向包括：英國脫歐對歐洲出口管制的影響；如何確保歐盟出口管制條例與國際反武器擴散制度相一致；以及解決網路監管和新興技術帶來的安全威脅等。本次歐洲軍民兩用出口管制修正重點如下： 提升出口管制力度，防止濫用網路監管等新興技術：管制項目具備監視、取得、蒐集或分析資通訊系統資料功能者，因涉及國家內部鎮壓或嚴重違反國際人權和國際人道法（International Humanitarian Law），即使未明列在歐盟軍民兩用法規的附件中，也應加強管制。 新增兩項歐盟一般出口許可證（EU General Export Authorisations, EU GEAs）：包括集團內部技術轉讓（EU007）及加密（EU008），允許軍民兩用貨品出口至特定目的地。 統一歐盟軍民兩用貨品規則：例如技術協助屬於特定軍事用途且與軍民兩用相關者須經授權，歐盟成員國得配合擴張軍民兩用貨品清單。 強化企業調查和報告義務，遵守並適用出口管制規則：實施出口及授權作業的出口商，應落實內部合規計劃，確保企業遵守出口管制的政策和程序。 歐盟成員國間加強合作機制：促進資訊交流、政策調整和執法行動。
美國OMB發布M-26-04備忘錄，確立聯邦採購之「無偏見原則」與透明度義務美國白宮管理與預算辦公室（Office of Management and Budget，以下簡稱OMB）在2025年12月11日發布M-26-04備忘錄（以下簡稱本指引），目標是落實第14319號行政命令「防止聯邦政府中的覺醒AI」（Preventing Woke AI in the Federal Government）。本指引闡述「追求真相」（Truth-seeking）、「意識型態中立」（Ideological Neutrality）兩大「無偏見AI原則」（Unbiased AI Principles），並強制要求聯邦機構在採購大型語言模型（LLM）時，必須將此二原則納入合約條款。 為確保符合規定，本指引要求聯邦機構在進行採購時，應避免強制供應商揭露過於敏感的技術資料（如模型權重），而是採取以下兩層級的資訊揭露架構： 1. 基本透明度要求（Minimum Threshold for LLM Transparency） 各機構於招標階段，應要求供應商提供以下資訊： (1) 可接受的使用政策：界定產品適當與不適當用途的文件。 (2) 模型、系統和/或資料的摘要卡（Model, System, and/or Data Cards）：包含訓練摘要、風險緩解措施及基準測試評分。 (3) 終端用戶資源與意見回饋機制：包含用戶教程及針對違反無偏見原則產出的回報管道。 2. 強化透明度門檻（Threshold for Enhanced LLM Transparency） 若機構擬將模型整合至其他軟體或服務中，則需獲取更深入的開發與運作資訊，例如： 1. 預訓練和後訓練（Pre-Training and Post-Training）：如影響產出事實性（factuality）的活動、系統提示詞（System Prompts）、以及內容審查過濾器的具體運作。 2. 模型評估：針對政治議題的偏見測試結果與方法論。 3. 模型中嵌入的企業控制（Enterprise-Level Controls）: 如可客製化的系統指令或來源引用功能。 4. 第三方對模型的修改：非原廠開發者所施加的額外控制層。 本指引對聯邦行政機構具有行政拘束力。機構必須於2026年3月11日前更新採購政策，並將上述要求納入新舊合約中。值得注意的是，本指引引入了「實質性要求」（Materiality Requirement），即若供應商拒絕針對違反無偏見原則的產出採取糾正措施，將構成合約違約之重要事由，機構得據此終止合約。 觀察美國OMB此次發布的內容，係透過將「意識形態中立」轉化為具體的採購合規要件，OMB利用聯邦政府龐大的購買力，在採購合約中確立供應商的「透明度義務」，OMB指引不僅建立了明確的法遵標竿，更可能發揮示範效應，將政府端的無偏見規範逐步推廣至私營部門，轉化為產業的最佳實踐標準。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（World Health Organization, WHO）於2023年10月19日發布「人工智慧於健康領域之監管考量因素」（Regulatory considerations on artificial intelligence for health）文件，旨在協助各國有效監管健康領域之人工智慧，發揮其潛力同時最大限度地降低風險。本文件以下列六個領域概述健康人工智慧之監管考量因素： （1）文件化與透明度（Documentation and transparency） 開發者應預先規範（pre-specifying）以及明確記錄人工智慧系統（以下簡稱AI系統）之預期醫療目的與開發過程，如AI系統所欲解決之問題，以及資料集之選擇與利用、參考標準、參數、指標、於各開發階段與原始計畫之偏離及更新等事項，並建議以基於風險之方法（Risk-based approach），根據重要性之比例決定文件化之程度、以及AI系統之開發與確效紀錄之保持。 （2）風險管理與AI系統開發生命週期方法（Risk management and AI systems development lifecycle approaches） 開發者應在AI系統生命之所有階段，考慮整體產品生命週期方法（total product lifecycle approach），包括上市前開發管理、上市後監督與變更管理。此外，須考慮採用風險管理方法（risk management approach）來解決與AI系統相關之風險，如網路安全威脅與漏洞（vulnerabilities）、擬合不足（underfitting）、演算法偏差等。 （3）預期用途、分析及臨床確效（Intended use, and analytical and clinical validation） 開發者應考慮提供AI系統預期用途之透明化紀錄，將用於建構AI系統之訓練資料集組成（training dataset composition）之詳細資訊（包括大小、設定與族群、輸入與輸出資料及人口組成等）提供給使用者。此外，可考慮透過一獨立資料集（independent dataset）之外部分析確效（external analytical validation），展示訓練與測試資料以外之效能，並考慮將風險作為臨床確效之分級要求。最後，於AI系統之上市後監督與市場監督階段，可考慮進行一段期間密集之部署後監督（post-deployment monitoring）。 （4）資料品質（Data quality） 開發者應確認可用資料（available data）之品質，是否已足以支援AI系統之開發，且開發者應對AI系統進行嚴格之預發布評估（pre-release evaluations），以確保其不會放大訓練資料、演算法或系統設計其他元素中之偏差與錯誤等問題，且利害關係人還應考慮減輕與健康照護資料有關之品質問題與風險，並繼續努力創建資料生態系統，以促進優質資料來源之共享。 （5）隱私與資料保護（Privacy and data protection） 開發者於AI系統之設計與部署過程中，應考慮隱私與資料保護問題，並留意不同法規之適用範圍及差異，且於開發過程之早期，開發者即應充分瞭解適用之資料保護法規與隱私法規，並應確保開發過程符合或超過相關法規要求。 （6）參與及協作（Engagement and collaboration） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。