歐洲資料保護委員會(European Data Protection Board, EDPB)於2021年1月18日發布《個資侵害通知範例指引》(Guidelines 01/2021 on Examples regarding Data Breach Notification)草案,並進行為期六週之公眾諮詢。該指引針對2017年10月所發布之《個資侵害通知指引》(Guidelines on Personal data breach notification under Regulation 2016/679)透過案例分析進行補充說明,對於資料控制者如何識別侵害類別以及評估風險提出更詳細的實務建議,協助資料控制者處理資料外洩及風險評估考量因素之認定。
個資侵害係指違反安全性規定而導致傳輸、儲存或以其他方式處理之個資,遭意外或非法破壞、遺失、變更、未獲授權之揭露或近用之情形,由於個資事故將對資料主體可能造成重大不利影響,該指引首先要求資料控制者進行侵害類別之辨識,依據2017年指引將個資侵害分為機密性侵害(confidentiality breach)、完整性侵害(integrity breach)以及可用性侵害(availability breach)。而資料控制者最重要的義務在於主動識別系統漏洞,評估侵害對資料主體權利所產生之風險,制定適當計畫及程序採取適當因應措施,確定侵害事件之問題根因及安全漏洞,加強員工認知培訓及制定操作手冊,並確實記錄各項侵害行為,以提升個資事故因應效率及降低時間延誤。
此外,該指引彙整自GDPR實施以來個資侵害通知具體案例,分為勒索軟體攻擊、資料外洩攻擊、內部人為風險、硬體設備或紙本檔案失竊、誤發郵件以及電子郵件內容外洩,共六大主題十八件案例,針對不同程度風險提供最典型的正確及錯誤作法,並提出資料控制者有關預防潛在攻擊及減輕影響之措施建議。
澳洲聯邦法院於2023年11月16日宣告著名速食餐飲公司McD Asia Pacific LLC (後稱McDonald's)指控Hungry Jack's Pty Ltd(Burger King Corporation特許經營者,後稱Hungry Jack's)商標侵權的審判結果,確認Hungry Jack's的「BIG JACK」和「MEGA JACK」商標與McDonald's的「BIG MAC」和「MEGA MAC」商標並無誤導性之近似性,考量商標之間的外觀、發音和含義等具有顯著性差異且能夠避免對消費者造成混淆,而判決Hungry Jack's的商標使用並未侵犯McDonald's的商標權。 美國漢堡巨頭McDonald's自1971年開始在澳洲運營並銷售「BIG MAC」漢堡。這起案件始於McDonald's公司於2020年提出的指控,聲稱Hungry Jack's於該年推出並使用的「BIG JACK」和「MEGA JACK」商標與其註冊的「BIG MAC」和「MEGA MAC」商標極為相似,可能導致消費者混淆,損害其商標權益。然而,Hungry Jack's反駁了這一指控,主張其商標「BIG JACK」和「MEGA JACK」在外觀、聲音和涵義上與McDonald's的「BIG MAC」和「MEGA MAC」存在顯著差異,並提出了獨特的市場定位和行銷策略。 聯邦法院指出,McDonald's公司聲稱Hungry Jack's的「BIG JACK」和「MEGA JACK」商標使用侵犯了其商標權,但卻未能提供足夠的證據來支持這一主張。法院特別關注商標在外觀、聲音和含義上的差異,並考慮了它們在市場上的實際使用情況。雖然兩者可能在某些方面顯示出相似性,例如名稱中都包含了「BIG」與「MEGA」,但綜合考慮後,法院發現Hungry Jack's的「BIG JACK」和「MEGA JACK」商標與McDonald's的「BIG MAC」和「MEGA MAC」商標之間,包括外觀風格、字體設計和商業標識等方面存在顯著差異,並未達到引起混淆或誤導的程度。因此,基於對雙方商標相似性的詳細分析和法律準則的適用,最終判定Hungry Jack's的「BIG JACK」和「MEGA JACK」商標使用未對McDonald's商標構成侵權。 本案突顯商標管理在品牌企業發展中的關鍵性。企業應定期檢視品牌商標使用情形與辨識侵權他人或被他人侵權等潛在風險,並適合維權等管制措施以及時保護自身的商標權益,確保品牌在市場中的競爭力。 本文同步刊登於TIPS網站(https://www.tips.org.tw/)
德國交通部與歐洲道路安全資料工作組簽署多方協議,透過車聯網分享交通狀況資料以提升道路安全德國聯邦交通及數位基礎設施部(Bundesministerium für Verkehr und digitale Infrastruktur, BMVI)於2020年12月2日公布與道路安全資料工作組(Data Task Force for Road Safety)成員簽署多方協議,以促進交通資料於道路維運單位、聯網車、智慧基礎設施間傳輸交換,進而透過最新技術識別道路危險狀況,以提升交通安全。 道路安全資料工作組係由歐盟成員國、車輛製造商、相關應用服務提供商所組成的公私合營夥伴關係,其任務為透過政府與產業相關利益者之合作,促進道路安全性資料可跨品牌和跨國界共享,並於公平可靠的合作夥伴關係下,促進公平競爭。 而在多方協議中,歐盟成員國,道路交通管理單位,汽車製造商和供應商以及地圖服務提供商等成員,承諾進行長期資料交換,並於協議中定義如何在安全相關交通資訊(Safety Related Traffic Information, SRTI)生態系統內,以公平、可靠的方式近用相關資料,並規定合作夥伴於SRTI價值鏈中應扮演的角色與責任,和透過分享安全相關的的資料,進而提供安全性服務。而在簽署本協議前,已成功完成可行性研究,在2019年6月至2020年10月間,不斷地測試SRTI系統並交換共數百萬筆資料,包括危險事故現場、暫時性濕滑路面、視野受限、特殊天候狀況等資訊。而在初步測試報告指出,透過上述資料交換,可發出相關危險交通狀況警告,能迅速有效因應各狀況作出適當的決策。
美國食品藥物管理局發布《上市後研究及臨床試驗:判定未遵守聯邦食品、藥品和化妝品法案第505(o)(3)(E)(ii)節的正當理由》指引草案美國食品藥物管理局(U.S. Food and Drug Administration, US FDA)於2023年7月14日發布《上市後研究及臨床試驗:判定未遵守聯邦食品、藥品和化妝品法案第505(o)(3)(E)(ii)節的正當理由》(Postmarketing Studies and Clinical Trials: Determining Good Cause for Noncompliance with Section 505(o)(3)(E)(ii) of the Federal Food, Drug, and Cosmetic Act)指引草案,說明FDA如何判定處方藥廠商未遵守上市後要求(Postmarketing Requirements, PMRs)的正當理由。 根據聯邦食品、藥品和化妝品法案(Federal Food, Drug, and Cosmetic Act, FD&C Act)第505(o)(3)節,應完成PMR的廠商必須向FDA更新研究或臨床試驗進度的狀態及時間表,例如:提交最終版本計畫書、完成研究/臨床試驗、提交結案報告。廠商若未向FDA更新上述PMR資訊即違反FD&C Act,除非廠商提出正當理由。 未遵守PMR的正當理由應符合下列三項條件: 一、與錯失時程直接相關的情況。 二、超出廠商的控制範圍。 三、當初制定時間表時無法合理預期的情況。 該指引草案舉例說明可能的正當理由及非正當理由,另建議廠商提交年度報告前主動通報PMR進度的狀態,並在預期錯過時程之前儘快提供理由,亦須採取矯正PMR不合規行為的措施,包括立即制定矯正計畫、主動向FDA通報實際或預期的延誤,以及修訂合理的時間表。未遵守PMR的廠商可能會收到FDA的警告信(Warning Letter)或無標題信(Untitled Letter)、不當標示指控(Misbranding Charges)和民事罰款,FDA將根據廠商是否採取矯正措施來確定罰金。 「本文同步刊載於 stli生醫未來式 網站(https://www.biotechlaw.org.tw)」
世界衛生組織發布人工智慧於健康領域之監管考量因素文件,期能協助各國有效監管健康領域之人工智慧世界衛生組織(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) 開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。