歐盟普通法院(EU General Court)於2024年6月5日宣告McDonald’s(後稱麥當勞)在與競爭對手愛爾蘭速食品牌Supermac's的訴訟中,失去其「Big Mac」(又稱「大麥克」)之部分商標權,即無法將「Big Mac」商標用於雞肉三明治等家禽類商品與餐廳內用及得來速外帶等餐飲服務上。
此案件起因於Supermac's公司拓展事業版圖進入歐盟市場,將公司品牌名稱「Supermac's」申請註冊歐盟商標,而麥當勞則主張消費者可能與其於1996年取得之「Big Mac」歐盟商標產生混淆誤認。然而,Supermac's於2017年向歐盟智慧財產局(European Union Intellectual Property Office,後稱EUIPO)以「麥當勞未真實使用(genuine use)『Big Mac』商標逾五年」為由,申請廢止麥當勞之「Big Mac」註冊商標。EUIPO於2019年廢止「Big Mac」商標於部分類別的註冊,惟EUIPO仍允許麥當勞仍可將「Big Mac」商標用於雞肉三明治、其他家禽產品及餐廳服務上。
爾後,Supermac's向歐盟普通法院提出上訴,而歐盟普通法院於2024年6月認為,麥當勞未能證明其於連續五年間有將「Big Mac」商標「真實使用」於雞肉三明治、家禽商品或餐廳服務的使用程度(例如:銷售量、商標使用期間長短及使用頻率等),故認定麥當勞不得再將「Big Mac」商標用於雞肉三明治、家禽商品或餐廳、得來速或外帶等服務上,惟本案尚未確定,而可再就法律問題上訴,故仍可持續關注本案的後續發展。
企業可從本案了解到當品牌標識成功註冊為商標後,務必留意各國所規範之連續使用年限(例如若連續五年未使用歐盟商標,則可能有被商標廢止之風險),以及明確留存足以佐證「真實使用」於註冊所指定之類別與品項之使用證明,以維護品牌商標之保護。
雖然歐盟未曾批准基因改造動物所衍生的食品與飼料之市場應用。然生物科技發展迅速,許多歐盟境外的國家已發展許多關於基因改造動物科技之應用。是故,歐盟基於此類基因改造動物所衍生的食品與飼料可能對歐洲整體食品安全及環境帶來影響評估,而由歐盟執委會(European Commission, EC)要求歐洲食品管理局(European Food Safety Authority, EFSA)在歐盟第1829/2003 號規章(Regulation EC No 1829/2003)之架構下,發展關於「基因改造動物所衍生的食品及飼料與相關動物的健康與福利,以及對環境影響之安全評估」的綜合性的指導文件(Guidance),預計發布兩份指導性文件,第一份即為此份指導文件,其係針對「基因改造動物所衍生的食品及飼料」以及「基因改造動物的衛生與福利方面」兩方面的風險評估,在歷經2011所進行的公眾諮詢(Public Consultation)後,EFSA於2012年1月26日正式公布。該份指導文件內容並未包含「基因改造動物衍生之食品與飼料」對於環境所產生的影響之評估,EFSA另行制定第二份指導文件做為評估之依循,目前初稿已制定完成,並進行公眾諮詢,而可能於近期發佈。 因畜牧而豢養的動物之健康狀態,向來作為衡量此類農畜食品與飼料的安全之重要指標,本指導文件即以此指標作為整體基本假設。故該指導性文件之發展策略即以傳統飼養的動物健康狀態及其所衍生的食品與飼料作為安全衡量的基底標準(Baseline);並同時發展合適於「基改動物」與「衍生的食品與飼料」,各自的不同比較尺度的評估方法。其評估重點如下: 1.分子特性之評估,係提供針對動物插入一個穩定基因特徵(Trait)的結構描述之資訊之評估; 2.毒性物質之評估,針對基改動物以及衍生之食品與飼料所可能導致生物上改變之影響; 3.新蛋白質的誘發性過敏評估,係針對所有基改動物所衍生的食品所可能導致過敏之評估; 4.營養性評估,係針對所有的基改動物所衍生的食品與飼料對於人類或傳統飼養動的營養評估。 5.針對基改動物衍生的食品與飼料上市後的監測調查(Post-Market Monitoring, PPM),辨識此類基改食品與飼料在上市後可能的潛在之影響 此指導文件另一重點,即對於基因改造動物的健康與福利之評估,這項評估指標之重要性在於: 1.基於動物倫理,即對於動物本身之健康與福利之衡量; 2.動物本身的健康與福利之情形,亦被視為動物衍生產品之安全之重要指標。 綜上,此份指導文件建構出關於申請此類「基因改造動衍生食品與飼料」上市前的安全評估所必須提供的特定資料之內容架構,並結合即將發布的第二份關於環境影響評估的指導文件,做為上市前的綜合安全評估之依循。
英國提出因應GDPR自動化決策與資料剖析規定之細部指導文件2018年5月,英國資訊專員辦公室(Information Commissioner’s Office, ICO)針對歐盟GDPR有關資料自動化決策與資料剖析之規定,公布了細部指導文件(detailed guidance on automated decision-making and profiling),供企業、組織參考。 在人工智慧與大數據分析潮流下,越來越多企業、組織透過完全自動化方式,廣泛蒐集個人資料並進行剖析,預測個人偏好或做出決策,使個人難以察覺或期待。為確保個人權利和自由,GDPR第22條規定資料當事人應有權免受會產生法律或相類重大效果的單純自動化處理決策(a decision based solely on automated processing)之影響,包括對個人的資料剖析(profiling),僅得於三種例外情況下進行單純自動化決策: 為簽訂或履行契約所必要; 歐盟或會員國法律所授權; 基於個人明示同意。 英國2018年新通過之資料保護法(Data Protection Act 2018)亦配合GDPR第22條規定,制定相應國內規範,改變1998年資料保護法原則上容許資料自動化決策而僅於重大影響時通知當事人之規定。 根據指導文件,企業、組織為因應GDPR而需特別留意或做出改變的事項有: 記錄資料處理活動,以幫助確認資料處理是否符合GDPR第22(1)條單純自動化決策之定義。 倘資料處理涉及資料剖析或重大自動化決策,應進行資料保護影響評估(Data Protection Impact Assessment, DPIA),判斷是否有GDPR第22條之適用,並及早了解相關風險以便因應處理。 提供給資料當事人的隱私權資訊(privacy information),必須包含自動化決策之資訊。 應確保組織有相關程序能接受資料當事人的申訴或異議,並有獨立審查機制。 指導文件並解釋所謂「單純自動化決策」、「資料剖析」、「有法律效果或相類重大影響」之意義,另就可進行單純自動化決策的三種例外情況簡單舉例。此外,縱使符合例外情況得進行單純自動化決策,資料控制者(data controller)仍必須提供重要資訊(meaningful information)給資料當事人,包括使用個人資料與自動化決策邏輯上的關聯性、對資料當事人可能產生的結果。指導文件亦針對如何向資料當事人解釋自動化決策處理及提供資訊較佳的方式舉例說明。
開放原始碼撤出蘋果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 逐漸產生分歧,後來情況則越來越嚴重。
歐洲議會全體會議投票通過《資安韌性法》草案,以提高數位產品安全性歐洲議會於2024年3月12日全體會議投票通過《資安韌性法》(Cyber Resilience Act)草案,後續待歐盟理事會正式同意後,於官方公報發布之日起20天後生效。該草案旨於確保具有數位元件之產品(products with digital elements, PDEs)(下簡稱為「數位產品」)具備對抗資安威脅的韌性,並提高產品安全性之透明度。草案重點摘要如下: 一、數位產品進入歐盟市場之條件 課予數位產品之製造商及其授權代理商、進口商與經銷商法遵義務,規定產品設計、開發與生產須符合資安要求(cybersecurity requirements),且製造商須遵循漏洞處理要求,產品始得進入歐盟市場。 二、數位產品合規評估程序(conformity assessment procedures) 為證明數位產品已符合資安及漏洞處理要求,依數位產品類別,製造商須對產品執行(或委託他人執行)合規評估程序:重要(無論I類或II類)數位產品及關鍵數位產品應透過第三方進行驗證,一般數位產品得由製造商自行評估。通過合規評估程序後,製造商須提供「歐盟符合性聲明」(EU declaration of conformity),並附標CE標誌以示產品合規。 三、製造商數位產品漏洞處理義務 製造商應識別與記錄數位產品的漏洞,並提供「安全更新」(security updates)等方式修補漏洞。安全更新後,應公開已修復漏洞之資訊,惟當製造商認為發布相關資訊之資安風險大於安全利益時,則可推遲揭露。 四、新增開源軟體管理者(open-source software steward)之義務 開源軟體管理者應透過可驗證的方式制定書面資安政策,並依市場監管機關要求與其合作。當開源軟體管理者發現其所參與開發的數位產品有漏洞,或遭受嚴重事故時,應及時透過單一通報平臺(single reporting platform)進行通報,並通知受影響之使用者。