美國德克薩斯州聯邦北區地方法院駁回德國汽車零組件供應商大陸集團對Avanci授權SEP模式違反反托拉斯法訴訟
美國德克薩斯州北區聯邦地方法院於2020年9月10日，駁回德國汽車零組件供應商大陸集團（Continental Automotive Systems）針對高通、諾基亞、夏普及其他電信公司透過Avanci授權標準必要專利（Standard Essential Patents, SEP）模式違反反托拉斯法的訴訟。法院指出，Avanci是由SEP專利技術擁有者組成的專利授權平台，而Avanci繞過零組件供應商，直接與汽車製造商就授權協議進行談判，並未違反反托拉斯法。
按大陸集團係依據《休曼法》（Sherman Antitrust Act）第2條提出反壟斷訴訟，指Avanic及其成員濫用標準制定的壟斷力量，排除其他技術擁有者並提高專利授權費用。對此，法院列舉聯邦第九巡迴法院在FTC v. Qualcomm案的相同看法指出，該行為是屬於Avanic及成員的契約問題，即SEP持有人可以選擇依照公平、合理、無歧視（Fair, Reasonable, Non-discriminatory, FRAND）的契約方式限制SEP授權，但違反此契約義務並不違反反托拉斯法。大陸集團主張SEP持有人違反FRAND授權承諾，欺騙標準制定組織，從而將專利納入產業標準；但即使這種欺騙會將被告的競爭者排除在標準之外，乃是針對競爭者本身而不是對競爭過程的損害，SEP權利人藉由價格歧視（Price Discrimination）合法地將專利價值最大化並不違反反托拉斯法。
另外，原告控訴依據還包括《休曼法》第1條，禁止事業以契約等方式限制競爭。但法院認為Avanci授權模式是與組成公司間協議訂定，該協議並不會阻止成員向非製造端客戶單獨授權。在SEP授權人拒絕與原告進行談判，或僅同意以向汽車製造商授權的相同價格與零組件供應商進行交易，頂多屬於SEP權利人間的個別行動，並未違反反托拉斯法，因而駁回訴訟。
本文為「經濟部產業技術司科技專案成果」
許祐寧
專案經理 編譯整理
新加坡聖淘沙發展局(Sentosa Development Corporation, SDC)（以下簡稱聖淘沙發展局）於今（2018）年1月30日向新加坡高等法院(High court)起訴，主張一家名為Vela的醫療器材企業（包含Vela Operations Singapore, Vela Diagnostics等子公司，以下合稱Vela公司），在其一系列檢測HIV及茲卡病毒的醫材產品中使用″Sentosa″（下稱系爭商標）之行為，侵害了聖淘沙發展局的商標權，要求其停止使用。 聖淘沙發展局隸屬於新加坡貿易與工業部，為專責推動聖淘沙觀光活動的法人機構，系爭商標早在2005年於新加坡申請註冊，其保護範圍以服裝、飾品、書籍、玩具與飲品等涉及觀光之類別為主。截至2015年止，聖淘沙發展局更將保護範圍擴及馬來西亞、印尼及中國大陸。該局表示，系爭商標在過去長達45年的經營下，已成為新加坡著名商標。Vela公司將之作為其醫材品牌的行為，不僅會淡化，甚至減損系爭商標的識別性，造成消費者混淆誤認，將該檢測醫材與聖淘沙發展局產生不當連結，為蓄意藉機炒作。 事實上，Vela公司曾欲將″Sentosa″申請註冊商標，卻於2012年11月被駁回。這次Vela公司則提起商標無效之反訴回應聖淘沙發展局的訴訟，其認為系爭商標係指稱新加坡當地觀光渡假勝地的地理名詞，縱非地理名詞，在馬來語中亦屬稱頌和平寧靜之用語，無法代表特定之服務或產品，根本欠缺商標識別性要件，系爭商標應屬無效。 本案涉及新加坡司法實務有關地理名詞是否具備商標識別性之判斷標準，故其後續發展，值得追蹤觀察。 「本文同步刊登於TIPS網站（https://www.tips.org.tw）」
BEREC推出網路中立性原則指南2016年8月底，歐洲電子通傳監管機構（Body of European Regulators for Electronic Communications, BEREC）根據歐洲議會（European Parliament）與歐盟理事會（Council of the European Union）通過的第2015/2120號規章（下稱2120號規章）第5條第3項的規定，推出規範歐盟各會員國國家監管機構（national regulatory authorities, NRAs）落實網路中立性原則的指南，為歐洲近年積極鼓吹數位人權運動寫下勝利的一頁。 該指南主要針對2120號規章以下幾條進行細部說明： 1. 第一條：規範主體與範圍； 2. 第二條：定義； 3. 第三條：網路中立權利的保障； 4. 第四條：確保網路中立的資訊透明措施； 5. 第五條：監管機制； 6. 第六條：罰則； 7. 第十條：規章實施與過渡條款。 指南補充說明了原先規章中，各條條文的相關細部規範。BEREC不只對各條規範中較為模糊的敘述提供明析的論述，同時也強化NRAs規範網路服務供應商（internet service provider, ISP）應提供網路中立服務的拘束力。 該指南的立場旨在希望歐洲網路終端用戶近用網路的權利受到更為完善的保障，且為了達成這樣的目標而為ISPs所提供的服務設下了更為嚴苛的門檻。不過BEREC也表示，ISPs可以在不影響其他終端用戶的權利及傳輸速率下，為特定服務提供特別的服務方案，例如：即時醫療服務（real-time health services）。當然，針對這些特定服務，各國NRAs必須加以監管以確保其他網路終端用戶的權利。 雖然該指南對歐盟各會員國的NRAs有行政指導上的指標意義，不過有趣的是，英國通訊傳播管理局（Office of Communications, Ofcom）身為BEREC的會員，但英國已非歐盟會員，Ofcom是否會提出適用英國自己的網路中立性規範，以及歐盟各會員國對於該指南的適用狀況值得繼續追蹤。
政府將Linux認證納入採購需求一直以來負責政府部門資訊軟體採購的中信局，均要求廠商出示所謂 " 原廠証明 "，但是自由軟體並無法取得 " 原廠証明 "，以致難以打入公部門。今年中信局第一季發佈的政府採購需求中，首度在個人電腦部份列出具備 Linux 相容測試以及中文化認證的產品。未來要做政府生意的非 Windows-based 桌面電腦軟硬體廠商，都必須取得 Linux 相容測試認證。這是政府為了擴大 Linux 軟硬體使用而推動 Linux 相容測試，第一次明文要求， Linux-based PC 必須要具備 Linux 相容性認證。Linux 相容認證列入 IT 產品採購規格中，將因政府需求的驅動而有助於刺激國內廠商參與測試、取得認證的意願，使推動 Linux 的力量更為聚焦。 眾多 Linux 版本 OS、應用彼此相容、以及中文化不足，是國內企業使用與佈署特別是 Linux 桌面軟體造成障礙。三年前工業局推動成立 Linux 相容測試中心，希望能降低 Linux 版本相容性問題，並在今年開始推動中文化認證。 過去 Linux 相容測試免費提供廠商產品測試服務，並沒有於政府需求銜接，導致在促進 Linux 產品取得認證過於發散，此次中信局僅在個人電腦部份列出需求，也有助於收斂投測產品種類。 Linux 相容測試中心，也將在本月頒發第一批「 Linux 軟硬體相容性基本驗證規範」及「基本中文化實用性驗證」的產品。 Linux 相容測試中心交由台北市電腦公會（TCA）負責的 Linux 促進會執行
世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（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） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。