Horizon Europe為歐盟2021-2027年之科技研發架構計畫。科技研發架構計畫(Framework Programmes for Research and Technological Development,依不同期別縮寫為FP1-FP8)為全球最大型的多年期科研架構計畫,今期之Horizon 2020已進入尾聲,2021年起所實施的歐盟科研架構計畫──FP9正式命名為「Horizon Europe」。
為打造歐盟成為創新市場先鋒,延續Horizon 2020計畫成效,Horizon Europe重視投資研發與發展創新,包含強化歐盟的科學與技術基礎、促進歐洲創新能力,以及永續歐洲社會經濟的模式與價值。
Horizon Europe發展方向分為三大主軸,分別為:
此外,Horizon Europe擬把實驗階段中具備高潛力和前瞻性的技術帶入市場,轉以任務導向協助新創產業設立,推動跨事業多方整合。
本文為「經濟部產業技術司科技專案成果」
大多數國家是認為動植物為法定不得授予專利之標的,歐盟以往因為歐洲專利公約實施細則(Implementing Regulations to the Convention on the Grant of European Patents,下簡稱實施細則)跟擴大上訴委員會(the Enlarged Board of Appeal,簡稱EBA)決定不一致而造成爭議,EBA於2020年5月做出的新決定,對於動植物是否為可授予專利之標的做出一致性解釋。 在歐洲專利公約(European Patent Convention,簡稱EPC)第53條第2款規定用以生產動植物的基本生物學方法不可授予專利,並於2017年生效的實施細則第28條第2項將其進一步擴張解釋成,僅運用基本生物學方法所產生的動植物不可授予專利,這與EBA在2015年所做出的決定(G 2/12、G 2/13)並不一致,在2015年的決定中提到,運用基本生物學方法來界定動植物的請求項仍可以被接受,因此實施細則第28條第2項與2015年的決定產生衝突。 於2019年,技術上訴委員會(Technical Board of Appeal)在案例T 1063/18中發現了這個問題,並提到EBA討論,EBA表示,考慮到法條涵義可能因時間產生變化,需要對EPC第53條第2款進行動態解釋(dynamic interpretation),實施細則第28條第2項與EPC第53條第2款並未矛盾,而是進一步擴展為,僅通過基本生物學過程,或是由基本生物學方法界定動植物之情況,皆屬於不可授予專利之情況,而推翻之前的決定。而為維持法律安定性,本決定(G 3/19)對於2017/07/01前生效或申請的案件並不具效力。 「本文同步刊登於TIPS網站(https://www.tips.org.tw )」
美國眾議院提出軟體法案 為醫療APP提供規範方向美國眾議院於2013/10/22提出法案(Sensible Oversight for Technology which Advances Regulatory Efficiency Act of 2013,簡稱Software Act,HR3303),擬限制食品藥物管理局 (Food and Drug Administration,FDA)在與健康醫療有關軟體制訂規範的權限。 根據美國聯邦法典第21編第301條以下(21 U.S.C. § 301)規定,FDA對醫療器材擁有法定職權進行規範。FDA近來亦開始嘗試對醫療軟體APP制訂規範,包括附有生物識別裝置(如血壓監視器和照相機)、讓消費者可以蒐集資料、供醫生可遠距離進行部分檢測行為的行動設備。這項法案的支持者以為,FDA此舉將阻礙醫療創新,故擬透過Software Act界定FDA的規管權限。 這項法案主要增加了3個定義:醫療軟體(medical software)、臨床軟體(clinical software)和健康軟體(health software)。醫療軟體仍在FDA的管轄範圍內,但其他2類則否。惟本法案只確立FDA無權對資料蒐集類軟體進行規範,但對此類軟體得使用的範圍、或是否需另授與執照等議題並沒有著墨。提案者以為,後續應由總統和國會應共同努力,對臨床軟體和健康軟體制訂和頒佈立法,建立以風險為基礎的管制架構,降低管制負擔,促進病患安全與醫療創新。 所謂醫療軟體,指涉及改變身體(changing the body)的軟體。包括意圖透過市場銷售、供消費者使用,直接改變人體結構或功能的軟體;或,意圖透過市場銷售、供消費者使用,以提供臨床醫療行為建議的藥物、器材或治療疾病的程序;或其他不需要健康照護提供者參與的情境,但實施後會直接改變人體結構或功能的藥物、器材或程序。 僅從人體蒐集資料者,被歸類為臨床軟體(由醫療院所、健康照護提供者裝設)或健康軟體(由民眾自為)。兩者的區別,主要在由誰提供並裝設。 所謂臨床軟體,是醫療院所或健康照護提供者在提供服務時使用,提供臨床決策支援目的之軟體,包括抓取、分析、改變或呈現病患或民眾臨床數據相關的硬體和流程,但不會直接改變人體結構或任何功能。 根據Research2Guidance於2013年2月發表的調查報告(Mobile Health Market Report 2013-2017),目前在APPLE的APP Store上已有97,000個行動健康類的APP程式,有3百萬個免費、30萬個付費下載使用者。15%的APP是專門設計給健康照護提供者;與去年相比,已有超過6成的醫生使用平板提供服務。預測消費者使用智慧型手機上的醫療APP的數量,在2015年將達5億。這個法案的出現,外界以為,提供了科技創新者較明確的規範指引,允許醫療的進步和創新。
合成資料(synthetic data)「合成資料」(synthetic data)的出現,是為了保護原始資料所可能帶有的隱私資料或機敏資料,或是因法規或現實之限制而無法取得或利用研究所需資料的情況下,透過統計學方法、深度學習、或自然語言處理等方式,讓電腦以「模擬」方式生成研究所需之「合成資料」並進行後續研究跟利用,透過這個方法,資料科學家可以在無侵犯隱私的疑慮下,使合成資料所訓練出來的分類模型(classifiers)不會比原始資料所訓練出來的分類模型差。 在合成資料的生成技術當中,最熱門的研究為運用「生成對抗網路」(Generative Adversarial Network, GAN)形成合成資料(亦有其他生成合成資料之方法),生成對抗網路透過兩組類神經網路「生成網路」(generator)與辨識網路(discriminator)對於不同真偽目標值之反覆交錯訓練之結果,使其中一組類神經網路可生成與原始資料極度近似但又不完全一樣之資料,也就是具高度複雜性與擬真性而可供研究運用之「合成資料」。 英國國防科技實驗室(Defense Science and Technology Laboratory, DSTL)於2020年8月12日發布「合成資料」技術報告,此技術報告為DSTL委託英國航太系統公司(BAE Systems)的應用智慧實驗室(Applied Intelligence Labs, AI Labs)執行「後勤科技調查」(Logistics Technology Investigations, LTI)計畫下「資料科學與分析」主題的工作項目之一,探討在隱私考量下(privacy-preserving)「合成資料」當今技術發展情形,並提供評估技術之標準與方法。 技術報告中指出,資料的種類多元且面向廣泛,包含數字、分類資訊、文字與地理空間資訊等,針對不同資料種類所適用之生成技術均有所不同,也因此對於以監督式學習、非監督式學習或是統計學方法生成之「合成資料」需要採取不同的質化或量化方式進行技術評估;報告指出,目前尚未有一種可通用不同種類資料的合成資料生成技術或技術評估方法,建議應配合研究資料種類選取合適的生成技術與評估方法。
日本簽署SBOM國際共通指引,強化軟體弱點管理,全面提升國家網路安全由美國網路安全暨基礎設施安全局(Cybersecurity and Infrastructure Security Agency, 簡稱CISA)自2024年以來,持續主導並規劃《SBOM網路安全之共同願景》(A Shared Vision of Software Bill of Materials(SBOM) for Cybersecurity)之指引訂定,作為保障網路安全之國際共通指引。於2025年9月3日,由日本內閣官房網路安全統括室為首,偕同經濟產業省共同代表日本簽署了該份指引,包含日本在內,尚有美國、德國、法國、義大利、荷蘭、加拿大、澳洲、紐西蘭、印度、新加坡、韓國、波蘭、捷克、斯洛伐克等共計15個國家的網路安全部門,皆同步完成簽署。以下為指引之重點內容: 1. 軟體物料清單的定位(Software Bill of Materials, 簡稱SBOM) SBOM於軟體建構上,包含元件內容資訊與供應鏈關係等相關資訊的正式紀錄。 2. 導入SBOM的優點 (1) 提升管理軟體弱點之效率。 (2) 協助供應鏈風險管理(提供選用安全的軟體,提升供應商與使用者之間溝通效率)。 (3) 協助改善軟體開發之進程。 (4) 提升管理授權軟體之效率。 3. SBOM對於利害關係人之影響 (1) 使軟體開發人員可選擇最符合需求的軟體元件,並針對弱點做出適當處置。 (2) 軟體資訊的透明化,可供採購人員依風險評估決定是否採購。 (3) 若發現軟體有新的弱點,使軟體營運商更易於特定軟體與掌握弱點、漏洞。 (4) 使政府部門於採購流程中,發現與因應影響國家安全的潛在風險。 4. SBOM適用原則與相關告知義務 確保軟體開發商、製造商供應鏈的資訊透明,適用符合安全性設計(Security by Design)之資安要求,以及須承擔SBOM相關告知義務。 近年來軟體物料清單(SBOM),已逐漸成為軟體開發人員與使用者,於管理軟體弱點上的最佳解決方案。然而,針對SBOM的作法與要求程度,各先進國家大不相同,因此透過國際共通指引的簽署,各國對於SBOM的要求與效益終於有了新的共識。指引內容不僅建議軟體開發商、製造商宜於設計階段採用安全設計,以確保所有類型的資通訊產品(特別是軟體)之使用安全,也鼓勵製造商為每項軟體產品建立SBOM並進行管理,包含軟體版本控制與資料更新,指引更強調SBOM必須整合組織現有的開發與管理工具(例如漏洞管理工具、資產管理工具等)以發揮價值。此份指引可作為我國未來之參考借鏡,訂定相關的軟體物料清單之適用標準,提升政府部門以及產業供應鏈之網路安全。