歐盟第七期研發綱要計畫定案，有條件支持幹細胞研究
歐盟日前正在加緊腳步為第七期研發綱要計畫（ R&D Framework 2007-2013 ）之規劃定案，與此同時，歐盟研發經費究竟應該如何挹注也成為討論焦點。歐洲議會產業研究暨能源委員會（ Industry, Research and Energy (ITRE) Committee ）最近通過第七期研發綱要計畫的預算，預算額度雖然從原本規劃的 72 億歐元減至約 54.5 億歐元左右，但相較於第七期研發綱要計畫，該經費仍成長許多。
此外 ITRE 也決定，基於倫理考量，以下的科技研究領域將無法獲得歐盟補助：複製人、人類基因體的遺傳性改變（ heritable modifications of the human genome ）、為取得幹細胞進行研究而複製人類胚胎。與此同時， ITRE 也重申，歐盟經費可以用於補助人類幹細胞的研究，只要幹細胞的來源不是經由複製人類胚胎兒取得，但研究者必須切實遵守會員國之相關科技政策及法令規定，研究之進行並應依法予以嚴格審核。
ITRE 前述決定目前已提交歐洲議會討論，預計在六月底前歐洲議會即可就此表決。儘管歐盟希望未來在第七期的研發綱要計畫期間內，對幹細胞研究仍延續其目前所採的政策 -- 資助一部份的幹細胞研究但禁止使用複製的幹細胞進行研究（目前歐盟會員國中，僅英國、瑞典、比利時三會員國允許複製胚胎幹細胞），惟由於幹細胞研究議題甚為敏感，且 2004 年 5 月 1 日 新加入的東歐會員國，其大多數在歐洲議會的代表都是天主教徒，故而有關幹細胞研究的議題，恐怕仍有一場激辯。
- http://news.bbc.co.uk/2/hi/europe/5074840.stm
- http://cordis.europa.eu/search/index.cfm?fuseaction=news.simpledocument&N_RCN=25732
- http://www.euractiv.com/en/science/meps-debate-energy-embryonic-stem-cell-research-fp7/article-156090
- http://www.europarl.europa.eu/news/expert/infopress_page/052-8884-164-06-24-909-20060608IPR08812-13-06-2006-2006-false/default_en.htm
- http://www.euractiv.com/en/science/seventh-framework-programme-adoption-moves-forward/article-156156
英國能源與氣候變遷部 (Department of Energy & Climate Change, DECC) 於2012年十二月十二日，依據歐洲執委會於同年三月針對智慧電表系統推展準備所發表的建議 (2012/148/EU: Commission Recommendation of the 9th March 2012 on preparation for the roll-out of SM systems, Section 1.4)，公佈其就智慧電表實施計畫對隱私影響的評估 (Privacy Impact Assessment)。 該項評估羅列了十一項面向，分別探討其可能因智慧電表實施對隱私帶的衝擊。這些面向包括有智慧電表為防範非法、未經授權資料近取的安全性管理，中央、地方政府機關及執法單位為他途而對資料的使用，第三人對細部能源消費資料的取得，對電表資料過長時間的保留，及非帳戶持有人對能源消費資料之取得等。 該部部長巴洛妮絲‧菲瑪 (Baroness Verma) 表示: 消費者是最重要的，因此能源與氣候變遷部在推動智慧電表實施的同時，亦致力於隱私、安全、消費者保護及通信等議題的處理。 除此之外，DECC並針對應如何]執行歐盟於同年十月二十五日通過的能源效率指令(Energy Efficient Directive 2012/27/EC) 中，第十條第二項B款所定關於消費者對去過去至少二十四個月能源消費資料應有簡易取得方式之要求，展開公開諮詢的程序。 英國智慧電表的全面推行預計從2014年展開至2019年結束前完成。其是否能在確保公眾能源消費資料不受非侵害或不當利用的前提下，發展各項配套措施以完成這項各國皆欲達成浩大工程，令人期待。
DE Technologies起訴戴爾侵犯其商業模式專利一家擁有美國網路上國際貿易相關專利的小公司起訴個人電腦巨頭戴爾公司(Dell Inc., DELL)侵權。這家名為DE Technologies Inc.的公司向一家美國聯邦地區法院提起了上述訴訟。DE Technologies的專利於1996年申請，並於2002年被授予。該公司首席執行長Ed Pool表示，他們的最終目的是將其專利授權給跨國公司並收取這些公司網路上貿易額的一小部分作為特許費。但這些費用全部累積起來可能高達數十億美元。 戴爾是首家遭DE起訴的公司。戴爾對上述訴訟未予置評。截至今年1月30日的財政年度，戴爾414億美元的銷售額中有36%來自美國以外地區，該公司向個人及小型企業的銷售中，大部分是通過網路進行的。 DE Technologies擁有的是一個商業模式專利。此類專利涉及的是流程及方法，而不是構造或化學成份。美國上訴法院於1998年判決擁有此類專利是合法的以後，許多公司開始申請此類專利。但批評人士認為許多商業模式不應被授予專利，專利應被授予那些新穎及非顯而易見的發明。
歐盟執委會通過關於《人工智慧責任指令》之立法提案歐盟執委會（European Commission）於2022年9月28日通過《人工智慧責任指令》（AI Liability Directive）之立法提案，以補充2021年4月通過之《人工智慧法》草案（Artificial Intelligence Act）。鑑於人工智慧產品之不透明性、複雜性且具自主行為等多項特徵，受損害者往往難以舉證並獲得因人工智慧所造成之損害賠償，《人工智慧責任指令》立法提案即為促使因人工智慧而受有損害者，得以更容易獲得賠償，並減輕受損害者請求損害賠償之舉證責任。 《人工智慧責任指令》透過引入兩個主要方式：（一）可推翻之推定（rebuttable presumptions）：人工智慧責任指令透過「因果關係推定（presumption of causality）」來減輕受損害者之舉證責任（burden of proof）。受損害者（不論是個人、企業或組織）若能證明人工智慧系統因過失或不遵守法規要求之義務，致其受有損害（包括基本權利在內之生命、健康、財產或隱私等），並且該損害與人工智慧系統之表現具有因果關係，法院即可推定該過失或不遵守義務之行為造成受損害者之損害。相對的，人工智慧之供應商或開發商等也可提供相關證據證明其過失不可能造成損害，或該損害係由其他原因所致，以推翻該損害之推定。（二）證據揭露機制（disclosure of evidence mechanism）：若受害者之損害涉及高風險人工智慧時，得要求自該供應商或開發商等處獲取證據之權利。受害者透過證據揭露機制能夠較容易地尋求法律賠償，並得以找出究責的對象。 歐盟執委會認為以安全為導向的《人工智慧法》，為人工智慧訂定橫向規則，旨在降低風險和防止損害，但仍需要《人工智慧責任指令》之責任規定，以確保損害風險出現時，相關賠償得以被實現。但歐盟執委會仍選擇了較小的干預手段，《人工智慧責任指令》針對過失之責任制度進行改革，並未採取舉證責任倒置（a reversal of the burden of proof）之作法，而是透過「可推翻之推定」，一方面減輕受損害者之舉證責任，使受損害者得對影響人工智慧系統並產生過失或侵害行為之人提出損害賠償；另一方面賦予人工智慧之供應商或開發商等有機會推翻前揭造成損害之推定，以避免人工智慧系統之供應商或開發商面臨更高的責任風險，可能阻礙人工智慧產品和服務創新。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。