從知名社群網路服務平台Twitter商標的更名看「品牌商標管理」

2023年7月知名社群網路服務平台Twitter基於品牌多角化經營考量(意圖進軍線上金融服務領域),Twitter執行長伊隆·馬斯克(Elon Musk)突然宣布全面變更品牌商標,經典「藍色小鳥」的商標標識改為黑白配色的「X」圖案(以下將該案例稱為「Twitter案」)。

實務上,企業可能於多種情況進行品牌商標之變更,例如:諾基亞(Nokia)因為希望向消費者表明其從手機公司轉型為商業科技公司的決心,故更換新商標,可見Twitter案的更名在科技業並不少見。重點在於品牌商標更名後,可能在商標法方面產生的風險。商標為指示品牌商品與服務來源的重要識別標識,在Twitter案中使用單一英文字母「X」作為新商標,在商標法上,一般被認為識別性較低,較難取得商標權,且其保護範圍可能也因此限縮於設計過的「黑白X標識」;其次,X作為一個常用的英文單字,較易產生與他人商標近似之風險,例如:微軟(Microsoft)公司2003年註冊與其遊戲系統Xbox通訊有關的X商標,或Meta公司自2019年起擁有藍白色彩的X字母商標,且註冊商標指定範圍也是社群媒體、軟體等。

為降低前述品牌商標爭議問題,建議企業由品牌標識設計、品牌全球拓展、品牌行銷宣傳三大階段,分別留意以下事項:

一、品牌標識設計階段:設計全新品牌標識或優化既有品牌標識前,事先評估品牌標識在商標法上是否具有識別性、是否與他人商標近似造成消費者混淆誤認等法定無法取得商標等風險,再決定是否維持原設計理念投入設計。如:Twitter案新商標X,除了透過品牌標識設計增加法律上的識別性,同時降低可能的侵權風險。
二、品牌全球拓展階段:如果預見可能侵權風險,則應加強爭議處理機制的建置,以利爭議發生時,及時採取因應措施。
三、品牌行銷宣傳階段:運用行銷手段加強品牌商標的「後天識別性」,如:透過投放廣告加強在消費者心中「黑白X標識」與品牌的連結等。

有關Twitter Inc.(現已併入X Corp.)的X品牌商標保護與布局策略,將會是後續值得關注的議題。

本文同步刊登於TIPS網站(https://www.tips.org.tw

相關連結
你可能會想參加
※ 從知名社群網路服務平台Twitter商標的更名看「品牌商標管理」, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?d=9033&no=64&tp=1 (最後瀏覽日:2026/06/10)
引註此篇文章
你可能還會想看
我國去識別化實務發展-「個人資料去識別化過程驗證要求及控制措施」

我國關於個人資料去識別化實務發展 財團法人資訊工業策進會科技法律研究所 2019年6月4日 壹、我國關於個人資料去識別化實務發展歷程   我國關於個資去識別化實務發展,依據我國個資法第1條立法目的在個資之隱私保護與加值利用之間尋求平衡,實務上爭議在於達到合理利用目的之個資處理,參酌法務部103年11月17日法律字第10303513040號函說明「個人資料,運用各種技術予以去識別化,而依其呈現方式已無從直接或間接識別該特定個人者,即非屬個人資料,自非個資法之適用範圍」,在保護個人隱私之前提下,資料於必要時應進行去識別化操作,確保特定個人無論直接或間接皆無從被識別;還得參酌關於衛生福利部健保署資料庫案,健保署將其所保有之個人就醫健保資料,加密後提供予國衛院建立健保研究資料庫,引發當事人重大利益爭議,終審判決(最高行政法院106年判字第54號判決)被告(即今衛福部)勝訴,法院認為去識別化係以「完全切斷資料內容與特定主體間之連結線索」程度為判準,該案之資料收受者(本案中即為衛福部)掌握還原資料與主體間連結之能力,與健保署去識別化標準不符。但法院同時強調去識別化之功能與作用,在於確保社會大眾無法從資料內容輕易推知該資料所屬主體,並有提到關於再識別之風險評估,然而應採行何種標準,並未於法院判決明確說明。   我國政府為因應巨量資料應用潮流,推動個資合理利用,行政院以推動開放資料為目標,104年7月重大政策推動會議決議,請經濟部標檢局研析相關規範(如CNS 29191),邀請相關政府機關及驗證機構開會討論,確定「個人資料去識別化」驗證標準規範,並由財政部財政資訊中心率先進行去識別化驗證;並以我國與國際標準(ISO)調和之國家標準CNS 29100及CNS 29191,同時採用作為個資去識別化驗證標準。財政部財政資訊中心於104年11月完成導航案例,第二波示範案例則由內政部及衛生福利部(105年12月通過)接續辦理。   經濟部標準檢驗局目前不僅將ISO/IEC 29100:2011「資訊技術-安全技術-隱私權框架」(Information technology – Security techniques – Privacy framework)、ISO/IEC 29191:2012「資訊技術-安全技術-部分匿名及部分去連結鑑別之要求事項」(Information technology – Security techniques – Requirements for partially anonymous, partially unlinkable authentication),轉換為國家標準CNS 29100及CNS 29191,並據此制訂「個人資料去識別化過程驗證要求及控制措施」,提供個資去識別化之隱私框架,使組織、技術及程序等各層面得整體應用隱私權保護,並於標準公報(107年第24期)徵求新標準之意見至今年2月,草案編號為1071013「資訊技術-安全技術-個人可識別資訊去識別化過程管理系統-要求事項」(Management systems of personal identifiable information deidentification processes – Requirements),主要規定個資去識別化過程管理系統(personal information deidentification process management system, PIDIPMS)之要求事項,提供維護並改進個人資訊去識別化過程及良好實務作法之框架,並適用於所有擬管理其所建立之個資去識別化過程的組織。 貳、個人資料去識別化過程驗證要求及控制措施重點說明   由於前述說明之草案編號1071013去識別化國家標準仍在審議階段,因此以下以現行「個人資料去識別化過程驗證要求及控制措施」(以下簡稱控制措施)[1]說明。   去識別化係以個資整體生命週期為保護基礎,評估資料利用之風險,包括隱私權政策、隱私風險管理、隱私保護原則、去識別化過程、重新識別評鑑等程序,分別對應控制措施之五個章節[2]。控制措施旨在使組織能建立個資去識別化過程管理系統,以管理對其所控制之個人可識別資訊(personal identifiable information, PII)進行去識別化之過程。再就控制措施對應個人資料保護法(下稱個資法)說明如下:首先,組織應先確定去識別化需求為何,究係對「個資之蒐集或處理」或「為特定目的外之利用」(對應個資法第19條第1項第4、5款)接著,對應重點在於「適當安全維護措施」,依據個資法施行細則第12條第1項規定,公務機關或非公務機關為防止個資被竊取、竄改、毀損、滅失或洩漏,採取技術上及組織上之措施;而依據個資法施行細則第12條第2項規定,適當安全維護措施得包括11款事項,並以與所欲達成之個資保護目的間,具有適當比例為原則。以下簡要說明控制措施五大章節對應個資法: 一、隱私權政策   涉及PII處理之組織的高階管理階層,應依營運要求及相關法律與法規,建立隱私權政策,提供隱私權保護之管理指導方針及支持。對應個資法施行細則第12條第2項第5款適當安全維護措施事項「個人資料蒐集、處理及利用之內部管理程序」,即為涉及個資生命週期為保護基礎之管理程序,從蒐集、處理到利用為原則性規範,以建構個資去識別化過程管理系統。 二、PII隱私風險管理過程   組織應定期執行廣泛之PII風險管理活動並發展與其隱私保護有關的風險剖繪。直接對應規範即為個資法施行細則第12條第2項第3款「個人資料之風險評估及管理機制」。 三、PII之隱私權原則   組織蒐集、處理、利用PII應符合之11項原則,包含「同意及選擇原則」、「目的適法性及規定原則」、「蒐集限制原則」、「資料極小化原則」、「利用、保留及揭露限制」、「準確性及品質原則」、「公開、透通性及告知原則」、「個人參與及存取原則」、「可歸責性原則」、「資訊安全原則」,以及「隱私遵循原則」。以上原則涵蓋個資法施行細則第12條第2項之11款事項。 四、PII去識別化過程   組織應建立有效且周延之PII去識別化過程的治理結構、標準作業程序、非預期揭露備妥災難復原計畫,且組織之高階管理階層應監督及審查PII去識別化過程之治理的安排。個資法施行細則第17條所謂「無從識別特定當事人」定義,係指個資以代碼、匿名、隱藏部分資料或其他方式,無從辨識該特定個人者,組織於進行去識別化處理時,應依需求、風險評估等確認注意去識別化程度。 五、重新識別PII之要求   此章節為選驗項目,需具體依據組織去識別化需求,是否需要重新識別而決定是否適用;若選擇適用,則保留重新識別可能性,應回歸個資法規定保護個資。 參、小結   國際上目前無個資去識別化驗證標準及驗證作法可資遵循,因此現階段控制措施,係以個資整體生命週期為保護基礎,評估資料利用之風險,使組織能建立個資去識別化過程管理系統,以管理對其所控制之個人可識別資訊進行去識別化之過程,透過與個資法對照個資法施行細則第12條規定之安全維護措施之11款事項,內化為我國業者因應資料保護與資料去識別化管理制度。   控制措施預計於今年下半年發展為國家標準,遵循個資法與施行細則,以及CNS 29100、CNS 29191之國家標準,參照國際上相關指引與實務作法,於技術上建立驗證標準規範供產業遵循。由於國家標準無強制性,業者視需要評估導入,仍建議進行巨量資料應用等資料經濟創新業務,應重視處理個資之適法性,建立當事人得以信賴機制,將有助於產業資料應用之創新,並透過檢視資料利用目的之合理性與必要性,作為資料合理利用之判斷,是為去識別化治理之關鍵環節。 [1] 參酌財團法人電子檢驗中心,個人資料去識別化過程驗證,https://www.etc.org.tw/%E9%A9%97%E8%AD%89%E6%9C%8D%E5%8B%99/%E5%80%8B%E4%BA%BA%E8%B3%87%E6%96%99%E5%8E%BB%E8%AD%98%E5%88%A5%E5%8C%96%E9%81%8E%E7%A8%8B%E9%A9%97%E8%AD%89.aspx(最後瀏覽日:2019/6/4) 財團法人電子檢驗中心網站所公告之「個人資料去識別化過程自評表_v1」包含控制措施原則、要求事項與控制措施具體內容,該網站並未公告「個人資料去識別化過程驗證要求及控制措施」,故以下整理係以自評表為準。 [2] 分別為「隱私權政策」、「PII隱私風險管理過程」、「PII之隱私權原則」、「PII去識別化過程」、「重新識別PII之要求」。

世界經濟論壇發布《贏得數位信任:可信賴的技術決策》

  世界經濟論壇(World Economic Forum, WEF)於2022年11月15日發布《贏得數位信任:可信賴的技術決策》(Earning Digital Trust: Decision-Making for Trustworthy Technologies),期望透過建立數位信任框架(digital trust framework)以解決技術開發及使用之間對數位信任之挑戰。   由於人工智慧及物聯網之發展,無論個人資料使用安全性還是演算法預測,都可能削弱人民對科技發展之信賴。本報告提出數位信任路線圖(Digital trust roadmap),說明建立數位信任框架所需的步驟,以鼓勵組織超越合規性,指導領導者尋求符合個人與社會期望之全面措施行動,以實現數位信任。路線圖共分為四步驟:   1.承諾及領導(commit and lead):數位信任需要最高領導階層之承諾才能成功,故需將數位信任與組織戰略或核心價值結合,並從關鍵業務領域中(例如產品開發、行銷、風險管理及隱私與網路安全)即納入數位信任概念。   2.規劃及設計(plan and design):透過數位信任差距評估(digital trust gap assessment)以瞭解組織目前之狀態或差距,評估報告應包括目前狀態說明;期望達成目標建議;治理、風險管理與合規性(governance, risk management and compliance, GRC)調查結果;將帶來之益處及可減輕之風險;計畫時程表;團隊人員及可用工具;對組織之影響等。   3.建立及整合(build and integrate):實現數位信任需關注人員、流程及技術等三大面向。首先需確保人員能力、達成該能力所需之資源,以及人員溝通與管理;第二,定義組織數位信任流程,包括制定計劃所需時程、預算及優先實施領域,調整目前現有管理流程,並識別現有資料資產;最後,針對技術使用,可考慮使用AI監控、雲端管理系統以及區塊鏈等,以監測資料之使用正確性及近用權限管理。   4.監控及滾動調整(monitor and sustain):建立數位信任框架後,需持續建構相關績效及風險評估程序,以確保框架之穩定,並根據不斷變化的數位信任期望持續改善,以及定期向董事會報告。

昇陽進入開放原始碼 Solaris 時代

  昇陽公司本月十四日把 500 多萬行 Solaris 核心 (kernel) 的原始碼張貼在 OpenSolaris 網站上。不過,一些原始碼元件,像是安裝程式與管理工具,因為仍在逐行檢視以免專利侵權問題,稍後才會推出。   Solaris 是使用率相當廣的一種 Unix 衍生版本,在一九九○年代末期網路泡沫時期大行其道,但後來隨開原碼作業系統 Linux 竄起而式微。同時,微軟的 Windows 作業系統,也蠶食著昇陽的市占率。為了讓 Solaris 成為開放原始碼軟體,昇陽積極拉攏軟體開發人員,軟體開發人數增多,可能引來更多的使用者、更多的合作夥伴,以及更多的軟體開發者。然而,要與氣勢正旺的 Linux 競爭,並非易事。 Solaris 開發工程僅傾昇陽一家公司之力,但 Linux 幕後卻有廣大的開發人員社群支持。   Quandt Analytics 分析師 Stacey Quandt 說,與外部程式設計師分享權力,是昇陽必須通過的考驗。對昇陽來說,真正的挑戰是,昇陽是否真能容納局外人貢獻的修補程式,而且不叫昇陽經驗老到的工程師加以改寫。   OpenSolaris 是昇陽自行研發的專屬計畫,但不表示一定會失敗。 IBM 即曾經以 Eclipse 程式設計工具為中心,建立起活力十足的開原碼社群,就是成功的例子。昇陽雖來不及按原訂計畫在二○○四年推出 OpenSolaris ,但已推動一些配套措施,包括在今年一月發布稱為 DTrace 的元件,提供詳細的效能分析;吸引一百五十位外部程式設計人員參與 OpenSolaris 測試計畫;並成立由五人組成的社群顧問委員會,其中兩席是昇陽的代表。

國際海事組織公布自駕船規則制定期程表

  國際海事組織(International Maritime Organization, IMO)於2018年6月5日第99次海上安全委員會(MSC 99)上,根據日本等國提案,開始進行監理範圍之界定與檢討等相關工作(Regulatory Scoping Exercise, RSE)。於MSC 99之會議上,IMO已暫定自駕船之定義與自動化等級,並於2018年12月3日至12月7日於英國倫敦召開之MSC 100會議上進一步確定RSE框架,公布自駕船規則之制定期程表,具體措施將分為兩階段實行。第一階段預計在2019年9月前釐清可能妨礙自駕船航行,或者有修正和確認必要之IMO規定。第二階段則規劃在2020年5月召開之MSC 102前,檢討為實現自駕船所需修正及制定之IMO規則。此外,MSC 100亦批准2018年5月IMO人為因素、訓練和值班小組委員會(Sub-Committee on Human element, Training and Watchkeeping, HTW)提出之船員「疲勞指引」(Guidelines on Fatigue)修正案,並預計在2019年6月召開之MSC101上,進一步針對燃料油品質所引發之安全問題進行討論。

TOP