日本國土交通省等統整了無人飛行載具目視外飛行時的要件
為了實現在2018年將無人飛行載具（drone）運用於離島或山區的貨物配送之目標，日本國土交通省及產業經濟省自2017年9月起舉行了6次「關於無人飛行載具的目視外與越過第三人上空之飛行檢討會」，並於2018年3月29日發表了其所統整出無人載具進行無輔助者目視外飛行之相關要件。
依據現行航空法第132條之2、國土交通省頒布的「無人航空機飛行手冊」第3點、以及該發表的內容所示，無人載具的目視外飛行除須就機體、操縱技術與安全對策的面向具備相關要件，尚要求在操縱者之外，應配置輔助者，在飛行時監視飛行與氣象狀況，同時管制飛行路線正下方及其周邊的第三人出入，並綜整判斷上述資訊，適時給予操縱者安全飛行所必要的建議。
基此，該發表指出，考量到以現行的技術而言，地上設備與機上裝置仍難以完全取代輔助者所扮演的角色，故就無輔助者的情形，除在現行飛行基準上，附加：1. 飛行路線須選在第三人存在可能性低、且有人機不會飛行的場所與高度；2. 機體須具備預想中用途的相當飛航實績；3. 事前履勘飛行路線與擬定意外發生時的對策等條件外，又增設新的個別要件如下：
（1）就第三人的出入管理，設置能遠距離監視的攝影機，並在管制區域設置看板或海報等，以警示附近居民；
（2）對機體施以增加辨識度的塗裝，裝設可供遠距離監視有無有人機接近的攝影機、或將飛行計畫事前提供給有人機營運者；
（3）隨時掌握自機狀況，擬定在異常情形發生時降落的適切對策；
（4）在飛行路線或機體裝設氣象計以監測氣象狀態，令其得以在判明天候狀況超出機體所能負荷限度的當下即時降落。
預期該發表內容將會成為日本「面向空中產業革命之行程表」中，關於目視外飛行審查要點修訂項目的重要參考基準。
本文為「經濟部產業技術司科技專案成果」
劉純妤
法律研究員 編譯整理
国土交通省，〈無人航空機（ドローン）の目視外飛行に関する要件をとりまとめました～無人航空機を使った荷物配送の実現に向けて～〉，http://www.mlit.go.jp/report/press/kouku01_hh_000087.html（最後瀏覽日：2018年4月2日）
国土交通省，〈無人航空機の目視外飛行に関する要件 概要〉，http://www.mlit.go.jp/common/001227435.pdf（最後瀏覽日：2018年4月2日）
国土交通省，〈無人航空機の目視外飛行に関する要件 本文〉，http://www.mlit.go.jp/common/001227438.pdf（最後瀏覽日：2018年4月2日）
国土交通省，〈空の産業革命に向けたロードマップ〉，http://www.mlit.go.jp/common/001226611.pdf（最後瀏覽日：2018年4月3日）
国土交通省，〈無人航空機 飛行マニュアル〉，http://www.mlit.go.jp/common/001218179.pdf（最後瀏覽日：2018年4月9日）
英國上議院人工智慧專責委員會（Select Committee on Artificial Intelligence）2018年4月18日公開「AI在英國：準備、意願與可能性？（AI in the UK: ready, willing and able?）」報告，針對AI可能產生的影響與議題提出政策建議。 委員會建議為避免AI的系統與應用上出現偏頗，應注重大量資訊蒐集之方式；無論是企業或學術界，皆應於人民隱私獲得保障之情況下方有合理近用數據資訊的權利。因此為建立保護框架與相關機制，其呼籲政府應主動檢視潛在英國中大型科技公司壟斷數據之可能性；為使AI的發展具有可理解性和避免產生偏見，政府應提供誘因發展審查AI領域中資訊應用之方法，並鼓勵增加AI人才訓練與招募的多元性。 再者，為促進AI應用之意識與了解，委員會建議產業應建立機制，知會消費者其應用AI做出敏感決策的時機。為因應AI對就業市場之衝擊，建議利用如國家再訓練方案發展再訓練之計畫，並於早期教育中即加入AI教育；並促進公部門AI之發展與布建，特別於健康照顧應用層面。另外，針對AI失靈可能性，應釐清目前法律領域是否足以因應其失靈所造成之損害，並應提供資金進行更進一步之研究，特別於網路安全風險之面向。 本報告並期待建立AI共通之倫理原則，為未來AI相關管制奠定初步基礎與框架。
英國商業、能源及產業策略部提出新版「後2020智慧電表布建計畫」，以助於住家型智慧電表全面布建英國商業、能源及產業策略部（Department of Business, Energy and Industrial Strategy，以下簡稱BEIS）於2020年6月18日提出新版「後2020智慧電表布建計畫」（Smart meter policy framework post 2020，以下簡稱旨揭智慧電表計畫），擬於未來4年內全面布建住家型智慧電表，以助於住家型用電戶管理用電並進一步減低碳排放量。 依BEIS預估，布建後有可能助於節省住家型用電戶平均250英鎊之電費，並減少全國4千5百萬噸碳排放量。依旨揭智慧電表計畫，電表布建費用將由售電業負擔，售電業應盡其最大努力布建智慧電表，如售電業並未盡到此一義務，則恐將面臨高額罰鍰。同時，智慧電表之布建可以鼓勵消費者改變用電習慣，如鼓勵消費者於用電離峰時間對於電動載具進行充電，或者是設置（再生能源）發電設備用於用電高峰期間發電、饋電至電網。 從而BEIS旨揭智慧電表計畫，也是為BEIS於2019年1月提出智慧饋電保證（Smart Export Guarantee，以下簡稱SEG）鋪路。於SEG新政策下，BEIS將擬定一套不同於躉購制度之政策框架，使小型生產消費者（prosumer，此處係指可以自行生產電力之用電戶）所生產之綠色電力，可於此一政策框架之保障下，與售電業者議約，並將電力售予售電業者，以減輕英國政府預計於今年3月廢除躉購制度所帶來之衝擊。又依SEG新政策，小型生產性用電戶須設置有智慧電表，始受前開SEG新政策之保證，從而得以優惠之價格或條件將再生能源設備所產生之電力出售予電力供應事業主體。職是故，BEIS旨揭智慧電表計畫，實際上可謂與BEIS於2019年所提出SEG新政策相互搭配，以迎接後躉購制度時代之來臨。 對於智慧電表之硬體規格，依旨揭智慧電表計畫，第二代智慧電表（SMETS2）為其建置之核心。第二代智慧電表與第一代智慧電表不同之處在於，第一代智慧電表係以3G為通訊基礎，且不同電力供應事業主體所使用之系統相互間無法交流、並存，第二代智慧電表則以4G以上規格為通訊基礎，且不同電力供應事業係使用同一套系統。同時，智慧電表應盡量配置有「住家顯示系統」（In-Home Displays），使住戶可以透過視覺化之及時反饋方式，知悉現在住家內之能源使用情形以及相關電價狀況，從而進行改變用電習慣。同時，智慧電表之用電或饋電至電網之資訊，也應可以透過智慧電表傳輸至電力供應事業主體或交易市場，從而使電力供應事業主體可及時知悉用電戶之用電或饋電情形，從而及時做出反應。 對於智慧電表之建置程序以及資訊傳輸、保存安全性上，旨揭智慧電表計畫則要求應符合「智慧電表建置行為準則」（The Smart Meter Installation Code of Practice, SMICoP），從而用電戶可以在此一準則或框架下，對於自己之用電資料享有一定之掌握權限。
歐盟計畫降低學名藥壁壘 開罰Teva和Cephalon 6050萬歐元歐盟執行委員會（以下簡稱執委會）於2020年11月以延遲平價學名藥進入市場、違反歐盟反托拉斯法為由，裁罰以色列學名藥廠Teva和美國生物製藥公司Cephalon共6050萬歐元。 Cephalon販售的Modafinil是用於治療猝睡症的藥物，為長年佔Cephalon全球營業額40％以上的暢銷產品。儘管其主要專利已於2005年在歐洲到期，但Cephalon仍保有部分Modafinil的延續性專利（secondary patents）。原先欲以Modafinil學名藥進軍市場的Teva也有Modafinil的相關專利，然而Cephalon和Teva達成「延遲給付」（pay-for-delay）協議，Teva同意暫緩進入市場且不去挑戰Cephalon的專利。執委會經調查發現，該協議排除Teva成為Cephalon的市場競爭者，使Cephalon的專利即使到期多年產品仍可維持高價位。 延遲給付協議在專利和解上通常是合法行為，但執委會認為此舉使患者和健保體系無法即早受惠於市場競爭帶來的低價，協議廠商卻享有缺乏競爭所產生的額外利潤。歐盟日前發布的《歐洲藥品戰略》（Pharmaceutical Strategy for Europe）更強調藥品應是全民可負擔、可取得及安全的，而維持自由競爭對達成此目標至關重大。執委會認為延遲給付協議違反《歐盟運作條約》（Treaty on the. Functioning of the European Union, TFEU）第101條，以協議限制或扭曲歐盟內部市場競爭，故裁處高額罰款。2022年歐盟將採取措施降低學名藥進入市場的阻礙，考慮進行審查、要求廠商使其專利藥品在全歐盟境內都可被取得，否則將縮短其智財權的保護期間。 「本文同步刊登於TIPS網站（https://www.tips.org.tw）」
開放原始碼撤出蘋果Safari？兩年前蘋果選擇開放原始碼成像引擎（ rendering engine ） KHTML 做為 Safari 瀏覽器的基礎；兩年後，蘋果則打算以自己的程式碼取代該引擎，藉以解決相容性的問題。 KHTML 成像引擎──也是其瀏覽器的核心，考慮在其架構上放棄 KHTML 的程式庫（ code base ），或者所謂的「樹狀圖」（ tree ），改用蘋果自己的版本，也就是所謂的 WebCore （網頁核心）。 KHTML 原本是為了要在 KDE （ K Desktop Environment ）上執行而撰寫的──這是 Linux 和 Unix 作業系統的介面。 Safari 並不是蘋果唯一以開放原始碼為基礎的軟體，其麥金塔（ Macintosh ）作業系統就是以達爾文（ Darwin ）開放原始碼計畫為基礎。 企業在某些方面受到限制，而開放原始碼社群以不受限制為傲。蘋果自己內部有些問題搞不定，以致銜接不上 KDE 開發 KHTML 的模式，導致 KHTML 與 Safari 逐漸產生分歧，後來情況則越來越嚴重。