英國智慧財產局(UK Intellectual Property Office)於2021年9月28日發布「2020-21創新與成長報告」(Innovation and growth report 2020-21)。本報告為英國智慧財產局對其2020至2021年間施政工作的總結報告,以創新為帶動國家與企業成長的核心,並期許能透過串接創新者與市場來帶動價值創造,從而建設英國成為全世界最具創新力與創造力的國家。
本報告指出,英國在全球創新指標當中均名列前茅,關鍵在於以系統化、組織化的方式推動創新,從而使創新成為帶動國家發展的動力,並得以對抗冠狀病毒的侵襲與實現淨零(Net Zero)排放的目標。呼應英國在2020年發表研發路徑圖(R&D Roadmap)以及2021年7月發布的創新戰略(Innovation Strategy),英國目標在2035年成為全球創新中心。
面對2020年英國脫離歐盟的巨大轉變,英國智慧財產局同步推動「單一智慧財產局轉型計畫」(One IPO Transformation Programme),以組織重塑、流程再造及數位轉型等方式,完成包含透過政府數位服務系統(Government Digital Service, GDS)推動智慧財產權管理數位化、開發基於人工智慧的商標搜索工具以協助商標申請人降低檢索成本,以及優化包含會計系統在內等工作流程以支持電腦設備更新並提升作業效率等措施。
為了打造世界一流的智慧財產權環境,英國透過一系列政策與法規來鼓勵創新活動,除了面對脫歐過渡期確保對英國商標跟設計等智慧財產權能在脫歐後繼續受歐盟法規的保護,還有藉由與歐洲經濟區以及其他國家的雙邊或多邊貿易協定,納入智慧財產權條款(包含智財保護與執法)、對創新活動的支持、排除與智財相關之市場准入障礙(IP-related market access barrier)、保障消費者選擇,以及獎勵創作人跟補助產業創新等措施,支持英國企業在國內外的創新與成長。
本文為「經濟部產業技術司科技專案成果」
2015年11月3日德國杜塞道夫地方法院(以下稱德國法院)依據歐盟法院之《華為訴中興》案(Huawei v ZTE case, 16 July 2015, Case C- 170/13)的先決裁判發出第一例禁制令(Cases 4a O 144/14) (Nov. 3, 2015)。這個判決係義大利公司SISVEL公司認為青島海爾德國公司(以下稱海爾公司)侵害其有關GPRS及 UMTS無線網路專利組合之標準專利,並已經對海爾公司發出專利侵權通知,並發出授權要約,海爾公司則抗辯認為,SISVEL僅通知其母公司而未通知其分公司,且其授權要約不符合FRAND原則。 德國法院認為,SISVEL只要將足夠的專利侵權資訊及授權要約通知海爾母公司進而據以判斷是否與SISVEL展開授權協商即可,若要求專利權人亦須一一通知其分公司,則將流於形式。 其次,海爾公司雖因認為SISVEL要求之授權金過高,故拒絕SISVEL的授權要約並提出反向要約,但卻未在提出反向要約後之合理期間內依據歐盟法院在《華為訴中興》案先決裁判中之見解,對SISVEL提供保證金以擔保其授權協議尚未達成前對SISVEL專利之使用費用。故德國法院進一步對前述合理期間給予確切期間,即拒絕專利權人要約時起一個月內。 至於海爾公司主張SISVEL授權要約不符合FRAND原則之抗辯,德國法院認為因海爾公司未履行前述程序,故尚無須判斷SISVEL授權要約是否FRAND原則。故何種情形屬於符合FRAND原則,仍留由後續之實務見解加以補充。
美國聯邦航空總署對外公布「無人機運行執法方針」近年來隨著科技進步,市面上無人飛行載具(Unmanned Aerial Vehicles, UAS,簡稱無人機)產品與相關應用蓬勃興起,為規範相關運行秩序,美國聯邦航空總署(the Federal Aviation Administration, FAA)於2015年1月8日公布了「無人機運行執法方針」(Law Enforcement Guidance for suspected unauthorized UAS Operations),並呼應美國眾議院所曾表達關切,建議應儘速公布美國無人機立法監管架構,以避免許多相關研發技術公司出走海外的不利發展。 FAA該執法方針,先指出實務上,目前以FAA為實際執法單位所面臨的困難,並徵募各州地方警力協助,以進行實際執法行動。由於FAA經常無法立即趕到並處理無人機事件發生地點,然而透過各州地方警力,對於攔阻未經授權或不安全的無人機活動,具有較佳的嚇阻、偵測、立即調查,以及採取適當執法行動的優勢。 因此,FAA執法方針指示州地方警力,應於未經授權的無人機活動事件發生處,採取以下措施:1. 認明並面詢目擊者;2. 鑑別操作可疑無人機活動者;3. 錄下其活動影像並繪製無人機使用之位置與情況;4. 辨識該區域限制航空範圍;5. 立即通知FAA;6. 蒐集證據。 目前美國有關無人機相關規範,僅有現代化及改革法(Modernization and Reform Act)第333條下,批准無人機具有豁免權之14項適用領域,如閉集錄影(closed-set filming)、空中調查工作、監控建築物地點、調查有關離岸鑽油平台、具農業目的等作業項目,並涵蓋相關具體應遵循之規範;所以美國後續亟待制訂更多相關遵守規範,以利產業界遵循,FAA預計於2015年底公布55磅以下無人機的規章制度,並受國會要求將於9月將無人機監管規章整合至美國領空管理系統(National Airspace System),相關規範內容待持續追蹤觀察。
美國國家標準暨技術研究院規劃建立「人工智慧風險管理框架」,並徵詢公眾對於該框架之意見美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST)為管理人工智慧對於個人、組織以及社會所帶來之風險,於2021年7月29日提出將建立「人工智慧風險管理框架」(Artificial Intelligence Risk Management Framework, AI RMF)之規畫並徵詢公眾意見,截止日為9月15日,並預計於10月發布正式報告。 依照NIST說明,公眾所建議之人工智慧風險管理框架,可促進人工智慧之可信賴性,其中包含如何應對並解決人工智慧於設計、發展及使用過程中所遭遇之「精確度」(accuracy)、「可解釋性」(explainability)、「偏見」(bias)等議題。此外,上開管理框架預計為非強制性、供企業自願性使用於人工智慧設計、發展、使用、衡量及評估之人工智慧標準。 依現有公眾意見徵詢結果,其中DeepMind公司建議於人工智慧設計初期,必須預先構思整體系統之假設是否符合真正社會因果關係。舉例言之,當設計一套可預測民眾健保需求程度之系統時,如輸入參數僅考量民眾於醫療上的花費,將使僅有可負擔較高醫療費用之民眾被歸類為健保需求程度較高者,從而導致健保制度排擠經濟負擔程度較差之公民,故在設計系統時,應從預先設定之假設事實反面(counter-factual)思考並驗證是否會產生誤差或公平性之問題(例如預先思考並驗證「醫療費用支出較低之民眾是否即可被正確歸類為健保需求度低之民眾」)。惟進行上述驗證需要大量社會資料,因此DeepMind也建議NIST應建立相關機制,使這些社會資料可以被蒐集、使用。 此外,亦有民眾建議管理框架應有明確之衡量方法以及數值指標,以供工程界遵循。同時鑒於人工智慧發展極為快速,未來可能有不同於以往之人工智慧類型出現,故亦建議NIST應思考如何在「建構一套完整且詳細之人工智慧治理框架」與「保持人工智慧治理框架之彈性與靈活性」之間取得平衡。 最後,目前也有許多徵詢意見指出,許多人工智慧治理之目標會相互衝突。舉例言之,當NIST要求人工智慧系統應符合可解釋性,則人工智慧公司勢必需要經常抽取人工智慧系統中之「數據軌跡」(audit logs),惟數據軌跡可能被認為是使用者之個人資料,因此如何平衡或完善不同治理框架下之目標,為未來應持續關注之議題。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局(National Security Agency, NSA)於2022年11月10日發布「軟體記憶體安全須知」(“Software Memory Safety” Cybersecurity Information Sheet),說明目前近70%之漏洞係因記憶體安全問題所致,為協助開發者預防記憶體安全問題與提升安全性,NSA提出具體建議如下: 1.使用可保障記憶體安全之程式語言(Memory safe languages):建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言,以取代C與C++等無法保障記憶體安全之程式語言。 2.進行安全測試強化應用程式安全:建議使用靜態(Static Application Security Testing, SAST)與動態(Dynamic Application Security Testing, DAST)安全測試等多種工具,增加發現記憶體使用與記憶體流失等問題的機會。 3.強化弱點攻擊防護措施(Anti-exploitation features):重視編譯(Compilation)與執行(Execution)之環境,以及利用控制流程防護(Control Flow Guard, CFG)、位址空間組態隨機載入(Address space layout randomization, ASLR)與資料執行防護(Data Execution Prevention, DEP)等措施均有助於降低漏洞被利用的機率。 搭配多種積極措施增加安全性:縱使使用可保障記憶體安全之程式語言,亦無法完全避免風險,因此建議再搭配編譯器選項(Compiler option)、工具分析及作業系統配置等措施增加安全性。