德國法院判決，網站上“連絡我們（Contact-Formula）”非屬德國電信服務法第5條規定之電子聯繫資訊
德國Essen地方法院判決（Az. 44 O 79/07），網站上之聯絡我們的功能（Contact-Formula），並不符合網路服務者依德國電信服務法第5條（Telemediengesetz, TMG）所應遵守之資訊揭露義務＊。
根據德國電信服務法第5條第1項第2款規定，網路服務提供者之資訊揭露義務範圍，包括應提供一個供網路使用者可以快速且直接聯繫網路服務提供者之電子聯繫方式，例如提供電子郵件。
按德國電信服務法第5條規定目的在提供消費者法定之保護，而違反本條規定者，將可依德國「不正競爭防止法，UWG」第4條第11款及第2條第1項第2款規定，視為違反公平競爭之行為。
該法院認為，網站上「連絡我們功能（Contact-Formula）」性質上僅屬於一個用以製造連結的科技措施，使用者需填寫網站上表格，按下傳送鍵後，始能得知網路服務者之電子郵件，而有些網站甚至無法顯示網路服務者之電子郵件。
我國於「電子商務消費者保護綱領」第5點企業經營者應提供有利於消費者選擇及進行交易之充分資訊包括「企業經營者本身資訊」，例如登記名稱、負責人姓名及公司簡介、公司或商號所在地及營業處所所在地、電子郵件、電話、傳真等聯絡方式及聯絡人等資訊，資訊提供範圍與德國電信服務法第5條第1項第2款大抵相同。
＊德國電信服務法（TMG）第5條網路服務者應揭露之資訊範圍包括其聯繫資料、特許職業執照證號、營利事業登記證號等。
有鑑於許多歐盟國家為日漸高漲的健康照護成本所困，歐盟於Horizon 2020政策下陸續推動會員國合作以更有效益的創新採購方式進行健康照護計畫的推展，以降低健康照護預算的壓力，RELIEF計畫即屬其一。歐盟於2016年2月啟動RELIEF計畫，聯合義大利、西班牙、瑞典三國，目的在發展創新ICT解決方案以協助慢性病患透過自我管理方式舒緩慢性疼痛、能夠持續獨立生活。欲採購的ICT創新服務為目前尚不存在於市場上、仍需經研發之解決方案，實為針對慢性疼痛自我管理解決方案的「研發服務」，該計畫係採「前商業化採購(Pre-Commercial Procurement, PCP)」方式進行跨國公告招標。目前RELIEF計畫正在進行PCP準備階段之公開市場徵詢，除了透過2個月（今年11、12月）的公開線上問卷調查業者意見，另將以workshop形式舉辦三場公開市場徵詢會議。 RELIEF計畫另一重要目標就是透過此計畫以建立完整PCP流程，讓未來參與相關計畫的公部門能夠熟悉並妥善運用PCP流程及工具 。「前商業化採購」為歐盟廣泛創新戰略中所指出能協助公部門採購「研發服務」的特殊採購程序，以滿足尚未存在市場上、仍需經研發的技術性創新需求，此程序不包含對研發成果的商業化採購，亦不受政府採購法之規範，能夠從需求面刺激廠商創新研發，讓研發從一開始即以機關需求為核心。 RELIEF計畫劃分為PCP之準備階段以及執行階段。於準備階段會進行PCP招標文件準備、採購團隊的需求及現有技術分析、公開市場徵詢(Open Market Consultation, OMC)；由於採購機關對其需求尚無具體的規格描述，必須經廣泛的市場意見徵詢與溝通以進一步定義，正在進行中的OMC將聚集採購團隊、潛在投標者（例如對健康照護、數位照護、病患賦權與互動性有鑽研之ICT業者）、終端使用者等，以廣蒐相關利害關係團體意見並進行充分互動溝通，作為執行階段的重要參考基礎。 PCP正式公告後的執行階段即區分為階段A「解決方案設計(Solution design)」（計半年）、階段B「原型開發(Prototype development)」（計半年）、階段C「商業化前開發：場域測試(Pre-commercial development: field test)」（計一年）。各階段將設定參與廠商應達成目標，以篩選出較符合需求者始得進入下一階段，以維持廠商間良性競爭，於階段C最後決標予研發成果最符合計畫需求之廠商（可能1家以上）。 歐盟目前的創新推動策略上PCP屬尚未被充分運用的工具，從該計畫的規劃可見準備階段對後續PCP執行階段的重要性，透過其示範可供政策規劃者為借鏡，運用創新採購驅動產業創新發展以更有效益解決社會與政府需求。
整合搜尋引擎及服務之軟體專利遭美國專利審查暨上訴委員會宣告無效本案系爭專利為Metasearch Systems公司自Harvey Lunenfeld獲得專屬授權之軟體專利（metasearching online system patent，美國專利證號：8,239,451），主要用於整合線上旅遊資訊搜尋引擎及提供旅遊安排服務，於2015年05月遭美國專利審查暨上訴委員會（Patent Trial and Appeal Board，PTAB）經由商業方法專利審查程序宣告無效。PTAB於最終決定書中認定，專利證號8,239,451之美國專利有六項專利範圍（claim）均為無效，主要理由係基於該軟體系統雖然必須與特定硬體結合才能上線運作，但整合諸多線上搜尋引擎提供旅遊資訊搜尋服務，並同時附帶旅遊代訂票券及食宿等功能，並未足以證明其產生優於現有技術之優勢，使該軟體專利本質上仍僅為抽象概念，而不具備專利適格性。是以，軟體研發雖帶來許多便利性，但是若僅為抽象概念運用方式的結合，就只是一種改變消費模式所帶來的便利，並未足以達到具有專利保護必要之重要技術發展。 本案最初源於Metasearch Systems公司於2012年向德拉瓦州聯邦法院對美國運通公司、Expedia Inc.及Preiceline.com Inc.等旅遊網站業者提起專利侵權訴訟，導致被告業者反而就系爭專利之有效性提出質疑。在本案之前美國聯邦最高法院針對軟體專利適格性判斷之議題作成多起重要判決，尤以Alice Corp. v. CLS Bank International對本案爭議最具影響，足見美國專利法制已建立起一個較明確且統一的判斷標準，逐漸在實務個案上產生影響。
歐盟發佈降低建置高速電子通訊網路成本草案數位議程(Digital Agenda for Europe)規劃2020年全歐洲基本寬頻30mbps以上、且超過一半家戶數具有100mbps接取能力設為目標。歐盟為達成此計畫，在今(2013)年3月發佈「降低建置高速電子通訊網路成本草案」(Reduce The cost of Deploying High-speed Electronic Communications Network)。有鑑於過去調查，挖掘道路佔總光纖基礎建設成本80%，且導致電信商投資低密度、偏遠地區具有龐大壓力。是故，本草案制訂後，不僅可減少30%成本(約400~600億歐元)，亦降低既有業者建設壓力與增加新進業者進入市場，使高速網路(30M)能迅速普及於歐洲。 歐盟以發展高速網路為前提，在本部草案中給與基礎供應商(Network Operator)諸多規範，其中又以「共同開挖工程設施」與「開放物理設施」最為重要。共同開挖工程設施是指基礎供應商(Eg:瓦斯、電力、水力、電子通訊業者)有權利可與其他基礎業者協商，共同進行工程建設(例如挖馬路)。基礎供應商應遵守資訊公開與不歧視原則，並在收到通知後的1個月內，須與相對人進行協商。主管機關接到申請後，須於六個月內進行審駁。歐盟認為此舉不僅可減少成本外，亦可減少挖斷管線的情形發生，使現有基礎建設每年可省下五千萬歐元的維修費。 開放物理基礎設施(Physical Infrastructure)方面，是指每個基礎供應商皆有權利與義務開放包含管道、天線桿、人孔蓋(Manholes)，以及任何建築物或可進入建築物等設施。因此，電子通訊網路(electronic communications network)業者可透過基礎供應商提供的物理設施(Eg:管道)之位址、大小，與所有權人姓名，在公開、合理無歧視的價格下，取得使用權。 由於，既有建築為了接取高速網路而進行裝修，其造價不菲，為了降低電子通訊網路鋪設的成本，是故，本部草案要求在核發建築許可前，新建物或重建建築須具備高速網路設備至網路終端(network termination points)。這項規定，不僅可降低業者建置網路的成本外，在網路服務商皆有權利使用基礎設備進行服務，預計消費者將可享有物美價廉的網路。 雖然，這些新的規範亦有但書，諸如當基礎設施開放後會干擾原服務、造成危險，亦或視重建建築比例，評估是否需賦予配置網路設備等，使部分輿論認為短期將難以看到成效。不過，隨著時間的演進，就如同歐盟執委會副主席Neelie Kroes所敘，很難想像購買一棟房子將會缺少水、電，而網路亦是如此。因此，當網路成為民生必須後，可以預期關鍵設施的開放、建設成本的降低與民眾需求提高，將使網路普及更為迅速。
開放原始碼撤出蘋果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 逐漸產生分歧，後來情況則越來越嚴重。