2021年7月14日歐盟普通法院裁定時尚品牌GUERLAIN法國嬌蘭(簡稱嬌蘭)口紅外盒形狀可註冊為商標。
嬌蘭於2018年針對其口紅外盒設計向歐盟智慧財產局(簡稱EUIPO)提出商標申請,EUIPO審查認為申請的商標缺乏識別性特徵並駁回申請;嬌蘭進而向EUIPO提出上訴,其上訴委員會維持該決定,理由為口紅立體形狀外盒設計與時尚產業領域的其他產品沒有“顯著差異”。
在上訴中,歐盟普通法院裁定EUIPO上訴委員會的決定無效。法院將嬌蘭的口紅設計與最常見的圓柱口紅形狀、平行六面體形狀進行比較,並指出嬌蘭申請的口紅外盒設計與市面上其他品牌之口紅外觀設計有明顯不同,認為該口紅外盒設計具有顯著特徵。
最終,歐盟普通法院說明判斷商標是否具有顯著性,不應該以商標在相關商品和服務所屬領域具有獨創性或未使用為依據;此外,僅僅立體形狀的新穎性和美觀特徵為主觀看法,不足以得出具有獨特性的結論,因為決定性的標準是該立體形狀可顯現出商品或服務來源的能力。同時,歐盟普通法院重申相關判定標準是嬌蘭口紅外盒立體設計方式以類似於船、搖籃或倒置金條的獨特形狀組成,明顯與時尚產業固有的口紅外盒的圓柱、平行六面體形狀設計規範和習慣大相徑庭,並且相關形狀特徵設計足以讓相關消費者藉以區辨服務來源。
在時尚品牌產業,商標本身通常不能成為區分品牌產品的唯一方式,尤其是當一個品牌提供多樣化的產品時更是難以認定具有獨特性。本案普通法院對立體形狀商標顯著特徵的認可無疑將為希望可保護其產品顯著設計元素的時尚品牌帶來曙光。
「本文同步刊登於TIPS網站(https://www.tips.org.tw)」
一直以來負責政府部門資訊軟體採購的中信局,均要求廠商出示所謂 " 原廠証明 ",但是自由軟體並無法取得 " 原廠証明 ",以致難以打入公部門。今年中信局第一季發佈的政府採購需求中,首度在個人電腦部份列出具備 Linux 相容測試以及中文化認證的產品。未來要做政府生意的非 Windows-based 桌面電腦軟硬體廠商,都必須取得 Linux 相容測試認證。這是政府為了擴大 Linux 軟硬體使用而推動 Linux 相容測試,第一次明文要求, Linux-based PC 必須要具備 Linux 相容性認證。Linux 相容認證列入 IT 產品採購規格中,將因政府需求的驅動而有助於刺激國內廠商參與測試、取得認證的意願,使推動 Linux 的力量更為聚焦。 眾多 Linux 版本 OS、應用彼此相容、以及中文化不足,是國內企業使用與佈署特別是 Linux 桌面軟體造成障礙。三年前工業局推動成立 Linux 相容測試中心,希望能降低 Linux 版本相容性問題,並在今年開始推動中文化認證。 過去 Linux 相容測試免費提供廠商產品測試服務,並沒有於政府需求銜接,導致在促進 Linux 產品取得認證過於發散,此次中信局僅在個人電腦部份列出需求,也有助於收斂投測產品種類。 Linux 相容測試中心,也將在本月頒發第一批「 Linux 軟硬體相容性基本驗證規範」及「基本中文化實用性驗證」的產品。 Linux 相容測試中心交由台北市電腦公會(TCA)負責的 Linux 促進會執行
美國聯邦地方法院加州北區法院禁止REALNETWORKS公司販賣Real DVD美國聯邦地方法院加州北區法院於2009年8月11日判決禁止REALNetworks公司致力或便利於製造、進口、供公眾使用、為販賣之要約或販賣以存取、複製及再散佈等他法規避CSS之保護或受著作權保護之DVD內容之軟體產品,這些產品如已知的RealDVD,或Vegas、Facet或其他名稱之產品,或有近似功能的軟體或其他產品、服務或裝置、設備或其零件。理由在於RealDVD軟體違反了數位千禧年著作權法案(Digital Millennium Copyright Act of 1998,DMCA)禁止規避電腦加密技術之規定。DVD若被CSS(Content Scramble System)鎖碼,則DVD播放者必須取得授權方能播放此光碟片,這些防止技術就是為了避免被複製而設計的。因為RealDVD是一種從含有著作權的DVD製造了一個永久的複製品的軟體技術,而這無法置外於數位千禧年著作權法案所賦予的義務,即使從個人合理使用的條文詮釋,亦無法認為是合法的。 這件案子是美國迪士尼、Sony、派拉蒙、二十世紀福斯、NBC、華納兄弟、哥倫比亞等好萊塢主要電影公司以及DVD複製控制協會(DVD copy control Association,DVD CCA) 於2008年對於REALNetworks公司銷售RealDVD軟體之行為提起訴訟,指控其行為違法法令。 而兩日後(2009年8月13日),於DVD複製控制協會(DVD CCA)訴KALEIDESCAPE公司上訴案中,加州聯邦上訴法院又判決KALEIDESCAPE公司販售DVD複製軟體(Kaleidescape system)違反數位千禧年著作權法案。 此兩個判決對於好萊塢電影工業無疑是一大勝利,但對於DVD複製軟體的科技發展卻是一項打擊。另外在判決中法官也強調這樣的判決決定,仍然保留了個人合理使用的合法空間。
美國國家標準與技術研究院公布人工智慧風險管理框架(AI RMF 1.0)美國國家標準與技術研究院(National Institute of Standards and Technology, NIST)於2023年1月26日公布「人工智慧風險管理框架1.0」(Artificial Intelligence Risk Management Framework, AI RMF 1.0),該自願性框架提供相關資源,以協助組織與個人管理人工智慧風險,並促進可信賴的人工智慧(Trustworthy AI)之設計、開發與使用。NIST曾於2021年7月29日提出「人工智慧風險管理框架」草案進行公眾徵詢,獲得業界之建議包含框架應有明確之衡量方法以及數值指標、人工智慧系統設計時應先思考整體系統之假設於真實世界中運作時,是否會產生公平性或誤差的問題等。本框架將隨著各界使用後的意見回饋持續更新,期待各產業發展出適合自己的使用方式。 本框架首先說明人工智慧技術的風險與其他科技的差異,定義人工智慧與可信賴的人工智慧,並指出設計該自願性框架的目的。再來,其分析人工智慧風險管理的困難,並用人工智慧的生命週期定義出風險管理相關人員(AI actors)。本框架提供七種評估人工智慧系統之信賴度的特徵,包含有效且可靠(valid and reliable):有客觀證據證明人工智慧系統的有效性與系統穩定度;安全性(safe):包含生命、健康、財產、環境安全,且應依照安全風險種類決定管理上的優先次序;資安與韌性(secure and resilient);可歸責與資訊透明度(accountable and transparent);可解釋性與可詮譯性(explainable and interpretable);隱私保護(privacy-enhanced);公平性—有害偏見管理(fair – with harmful bias managed)。 本框架亦提出人工智慧風險管理框架核心(AI RMF Core)概念,包含四項主要功能:治理、映射(mapping)、量測與管理。其中,治理功能為一切的基礎,負責孕育風險管理文化。各項功能皆有具體項目與子項目,並對應特定行動和結果產出。NIST同時公布「人工智慧風險管理框架教戰手冊」(AI RMF Playbook),提供實際做法之建議,並鼓勵業界分享其具體成果供他人參考。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件,期能協助各國有效監管健康領域之人工智慧世界衛生組織(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) 開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。