英國Tesco於網域名稱爭議中獲得勝利
Tesco對Elogicom公司主張商標權之侵害及搭便車，並請求移轉網域名稱；Elogicom則提起反訴請求給付佣金。該案法官認為Elogicom是利用「tesco」之名稱採取「釣魚」(fishing) 的方式，誘引不喜歡利用搜尋引擎而習慣於網路位址列鍵入猜測域名之網路使用者連結至其所設立之錯誤網站，藉由網站之自動連結功能跳頁至Tesco網站而賺取連結佣金，即使該公司並未使用該網站連結至與Tesco有營業競爭關係之網站，但仍因此利用Tesco之名賺取不正當利益並造成Tesco之商譽受到損害，判決Tesco勝訴並駁回Elogicom公司之反訴。
歐盟執委員會於2018年5月17日公布第三套安全，清潔和聯網式行動議程，該套行動也是最後一套實現歐洲運輸系統現代化的措施。 在2017年9月的國情咨文中，歐盟主席容克提出歐盟產業成為創新，數位化和低碳化均能領先於全球地位的目標。基於此原因，在交通領域執委會2017年5月和11月的提出兩套歐洲行動措施，其目標係讓所有歐洲人都能從享受更安全的交通，更少污染的車輛和更先進的技術解決方案，並同時加強歐盟產業業的競爭力。為此，本次議程聚焦包括未來車輛和基礎設施安全措施綜合政策;重型車輛的二氧化碳標準; 歐洲發展和製造電池的戰略行動計畫以及關於車聯網和自駕車的前瞻性戰略。 而歐洲能源聯盟表示：交通正到跨越一個新的技術前沿，透過能源聯盟的最終提案，將可幫助我們相關產業保持領先地位，並透過大規模研發關鍵技術解決方案，包括潔淨能源之電池技術和建置相關充電基礎設施，以解決碳排放，行車擁堵和降低事故發生。 歐盟氣候行動與能源專員亦表示：所有部門都必須為實現巴黎協議之氣候承諾做出貢獻，這就是為什麼歐盟在有史以來第一次訂定提提高燃油效率標轉和減少碳排放的標準，也為歐洲工業鞏固當前在創新技術領域的領導地位。 歐盟交通運輸專員亦表示：過去一年，執委會在通領域提出許多重大舉措，以提升未來交通安全、乾淨及聯網性。所有措施皆以乾淨且智慧的交通工具目標前進，並尋求各成員國和歐洲議會能支持該雄心壯志。 歐盟內部市場，產業，創業和中小企業專員表示：90％的道路交通事故係出於人為錯誤，目前提出新的強制性安全功能將減少事故的數量，並有利車聯網及自駕車技術發展。 本次議程內容簡介如下 交通安全 從2001年至今道路死亡人數減少已了一半以上，然2017年歐盟境內仍有25,300人交通事故身亡，及13.5 萬人受重傷。因此，歐盟執委會建議新型車輛應配備先進的安全功能，例如用於汽車的先進緊急煞車和車距保持輔助系統或卡車對於周遭行人和用路人之檢測系統。此外，委員會將幫助成員國能在危險路段進行系統性改善建設投資。預計將可挽救多達10,500人的生命，並在2020-2030年期間避免接近6萬人的嚴重受傷，從而為歐盟實現2050年接近零死亡和重傷的長期目標做出貢獻。 交通能源清潔性 歐盟執委會將提出有史以來第一個重型車輛的二氧化碳排放標準來完成低排放交通系統的計畫。此外，2025年，新卡車的二氧化碳平均排放量必須比2019年低15％。2030年，新卡車與2019年相比，必須達到至少30％的減排目標。該目標符合可協助歐盟於巴黎協議所作的承諾，並將使運輸公司（主要是中小企業）透過降低油耗（5年25,000歐元）節省大量成本。為了進一步減少二氧化碳排放，委員將會促進更多的先進低汙染的車輛（例如：改善汽車動力學、輪胎等零件）。此外，委員會將提出一個全面的行動計畫，將有助於在歐洲建立一個具有競爭力和永續性發展的電池生態系統。 車聯網及自駕車 目前越來越多地車輛已配備駕駛員輔助系統，並朝完全自動駕駛車輛目標邁進。因此，該戰略將著眼於道路使用者之間的新協同操作，此將為整個交通系統帶來巨大的利益。運輸將變得更安全，更清潔，更便宜，並使老年人和行動不便的人更方便。此外，執委會建議建立一個全數位化的貨運資訊交換環境，以促進物流運作的數位資訊流。
昇陽進入開放原始碼 Solaris 時代昇陽公司本月十四日把 500 多萬行 Solaris 核心 (kernel) 的原始碼張貼在 OpenSolaris 網站上。不過，一些原始碼元件，像是安裝程式與管理工具，因為仍在逐行檢視以免專利侵權問題，稍後才會推出。 Solaris 是使用率相當廣的一種 Unix 衍生版本，在一九九○年代末期網路泡沫時期大行其道，但後來隨開原碼作業系統 Linux 竄起而式微。同時，微軟的 Windows 作業系統，也蠶食著昇陽的市占率。為了讓 Solaris 成為開放原始碼軟體，昇陽積極拉攏軟體開發人員，軟體開發人數增多，可能引來更多的使用者、更多的合作夥伴，以及更多的軟體開發者。然而，要與氣勢正旺的 Linux 競爭，並非易事。 Solaris 開發工程僅傾昇陽一家公司之力，但 Linux 幕後卻有廣大的開發人員社群支持。 Quandt Analytics 分析師 Stacey Quandt 說，與外部程式設計師分享權力，是昇陽必須通過的考驗。對昇陽來說，真正的挑戰是，昇陽是否真能容納局外人貢獻的修補程式，而且不叫昇陽經驗老到的工程師加以改寫。 OpenSolaris 是昇陽自行研發的專屬計畫，但不表示一定會失敗。 IBM 即曾經以 Eclipse 程式設計工具為中心，建立起活力十足的開原碼社群，就是成功的例子。昇陽雖來不及按原訂計畫在二○○四年推出 OpenSolaris ，但已推動一些配套措施，包括在今年一月發布稱為 DTrace 的元件，提供詳細的效能分析；吸引一百五十位外部程式設計人員參與 OpenSolaris 測試計畫；並成立由五人組成的社群顧問委員會，其中兩席是昇陽的代表。
ECtHR就國會發言揭露個資是否構成隱私權侵害作成判決，強調應尊重國家之裁量歐洲人權法院（European Court of Human Rights，簡稱ECtHR）於2025年4月8日就Green v. The UK案作成判決，針對國會議員發言揭露個資是否構成隱私權侵害之爭議，強調國家就衡平立法權與司法權的界線、言論自由與隱私保護等利益享有裁量權，駁回了申訴人之請求。 一、事實背景 本案起源於英國每日電訊報（Telegraph）試圖就英國零售集團Arcadia的前員工針對其董事長Philip Green的職場性騷擾與霸凌指控進行報導。先前，Arcadia及Green已與涉及相關糾紛的員工達成了和解協議，依據協議所附保密協定，員工除正當揭露（如向警察揭露犯罪）外不得洩露相關資訊。Green於Telegraph於報導前徵求當事人評論時發現資訊遭洩露，隨即向法院申請禁制令與暫時禁制令，英國上訴法院嗣後批准了暫時禁制令，認定Telegraph獲得的資訊很可能來自違反保密協定的揭露，也不認為欲報導的內容當然具備凌駕當事人可能蒙受之損害的公共利益。Telegraph最終尊重了暫時禁制令。惟隔日，一位英國上議院議員援引言論免責權，於議會發表了雖不涉及細節，但具體提及Green身分和關於其性騷擾、霸凌的指控，並提及Telegraph遭禁制報導一事。Green因此向議會申訴，認為議員違反了司法保密規則（sub judice rule）（編按：上議院曾做成決議，認除非具全國重要性，議員不得於動議、辯論或質問中論及繫屬於法院中的個案）及濫用免責權，但上議院標準專員（House of Lords Commissioner for Standards）認為司法保密規則不屬於《上議院行為準則》。Green嗣後在法院中試圖向Telegraph請求賠償，認為Telegraph應要為議員的發言負責，違反了禁制令，並要求提供線人身分。Telegraph抗辯，在議員享有免責權的前提下，法院毋庸受理本案處理其責任問題。Green向ECtHR提出申訴，主張國家對議員使用免責權揭露受禁制令約束的資訊的權力缺乏事前和事後控制，侵犯了其受歐洲人權公約（ECHR）第8條保障的私生活權。 二、法院判斷 法院認為由於受暫時禁制令保護的資訊被揭露，Green的私生活權利確實受到干預。然而，法院不認為國家違反了公約課予國家保護私生活權之積極義務（positive obligation）。核心理由在於：國家對如何履行積極義務有廣泛的裁量權，且於各國就保護方式較無共識，或涉及基本權利間之衡平時，法院尤應尊重裁量空間。 針對本案，法院認為：（1）議會中的言論自由享有較高程度的保護，對其干涉需要非常重大的理由（very weighty reasons）；（2）涉及司法權與立法權的具體界線，以及言論自由與隱私保護的利益衡量；（3）必須考量議會自治原則在多國之間有廣泛共識；（4）英國並非完全沒有針對國會議員發言的事前、事後控制措施。儘管非屬《上議院行為準則》，但上議院所做成的司法保密規則決議，仍屬一定程度的事前控制。事後來看，國會議員若確實構成濫用免責權，法院也可以判處蔑視法庭罪。 法院總結認為，基於原則上各國議會較國際法院，更適合評估限制議會行為之必要性與手段，法院要取代這個判斷須要非常重大的理由，但本案中Green並無法成功論述這個理由存在，因此駁回Green的主張。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（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） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。