美國聯邦最高法院(Supreme Court of the United States)於2020年6月30日以8票對1票之決定,肯認網域名稱「booking.com」可取得聯邦商標註冊。
本案之爭點在於,「通用名稱.com(generic.com)」是否亦會被認定為通用名稱而無法取得商標註冊。過去美國專利商標局(United States Patent and Trademark Office, USPTO)認為,當通用名稱與通用頂級域名(如「.com」)組合時,所得到之組合仍會被認定具有通用性(generic),因為僅在通用名稱中加入「.com」,如同加入「公司」一詞,無法藉此傳達任何可識別來源之意義。就「booking.com」而言,由於 「Booking」一詞意指旅行預訂,「.com」一詞表示其為一個商業網站,故消費者觀諸「booking.com」此一用語,會認為其是提供旅遊住宿之線上預訂服務。且即便認為「booking.com」屬於描述性商標,其亦缺乏第二意義而無法註冊。
惟聯邦最高法院認為,因為同一時間僅有一個實體可占用一特定網域名稱,因此「generic.com」一詞可向消費者傳達與特定網站之關聯。且對於通用性之認定原則主要有三:首先,通用性係指商品或服務之類別,而非該類別之特定示例;其次,對於複合用語而言,其識別性之認定應以整體觀之,非個別隔離觀察;最後,應視用語之相關意涵對於消費者之意義而定。基於該等原則,「booking.com」是否具有通用性,取決於該用語是否整體上向消費者表示為線上旅館預定服務之類別,例如:消費者是否會認為另一家提供相似服務之Travelocity也是一種「booking.com」;但消費者並非以此種方式來認知「booking.com」用語,因此,由於「booking.com」對於消費者而言並非通用名稱,其未具通用性。
USPTO另認為基於政策考量,其反對如「booking.com」之「generic.com」之商標註冊,因此種商標保護將使商標權人對於其他應保持自由使用之相似文字擁有過度控制權,例如可能會妨礙競爭者使用「booking」用語或「ebooking.com」、「hotel-booking.com」等域名。聯邦最高法院指出,USPTO顧慮之情形其實也會出現於任何描述性商標。事實上,除非可能造成消費者混淆,競爭者之使用並不會侵害商標權。「booking.com」是識別性較弱的商標,較難導致消費者混淆,且booking.com公司亦自承「booking.com」之註冊不會阻止競爭者使用「booking」之用語來描述其之服務。因此,聯邦最高法院最終認定「booking.com」之註冊不會使商標權人壟斷「booking」此一用語。
本文為「經濟部產業技術司科技專案成果」
開放原始碼協會(Open Source Initiative,簡稱OSI)的新任總裁Russ Nelson在3月2日提出了一項新的提案,希望解決一項重大的問題:開放原始碼授權的擴增問題。亦即,只要符合該組織的10點開放原始碼定義,OSI可提供正式開放原始碼授權(licenses,或稱「許可」)身份。 在寄給開放原始碼社群的一份聲明裡,Nelson表示,新的條款規定:授權不可與既有的授權重覆;必需以清楚、簡單,而容易了解的方式撰寫;以及把個人、專案或組織的名稱通通移至隨附的附件中,以便讓授權書可重複使用。 Nelson在接受專訪時表示,新條款要由OSI董事會通過才可生效。董事會成員已經過過該提案,但還未安排好投票的議程。OSI並不打算取消已經通過的授權認證,Nelson表示。他認為,推出「OSI Gold」升級認證應該可達到同樣的效果。他進一步表示,新的條款是否能夠有效減少授權數量,還要看執行是否有力。
新加坡推《網路安全法案》:強化網路保護、賦權受害者、要求平台揭露加害者身分面對網路騷擾、私密影像濫用及假訊息快速擴散等現象持續上升,新加坡政府於10月15日正式提出《網路安全(救濟與問責)法案》(Online Safety (Relief and Accountability) Bill,簡稱 OSRA),旨在提供受害者更迅速、更具效力的救濟手段,並強化平台與加害者的法律責任。該法案在16日完成國會一讀,預計於2026年上半年正式設立「網路安全委員會」(Online Safety Commission, OSC)。 政府指出,隨著民眾日常高度依賴網路,各類線上侵害行為不斷增加。根據政府的數位化調查,有84%的受訪者曾接觸有害內容,另有三分之一在過去一年曾遭遇實質的網路不法行為。其類型包括性與暴力內容、網路霸凌、種族與宗教衝突言論等。非營利組織SG Her Empowerment的研究更指出,多數受害者因平台處理無效、加害者匿名、外界輕忽其傷害而感到無助,甚至減少自身在網路上的公共參與。 OSRA的核心是建立網路安全委員會(Online Safety Commission, OSC),作為受害者的專責申訴與救濟窗口。受害者在多數案件中須先向平台申訴;若平台未能妥善處理,即可向OSC報告。但針對私密影像濫用、兒童影像濫用與人肉搜索(doxxing)等急迫性高的侵害,可直接向OSC求助。OSC在確認侵害後,將可發布多類命令,包括要求加害者停止傳播內容、限制其帳號,或命令平台移除貼文、封鎖群組、降低特定內容觸及率等。若平台拒不配合,OSC 還可指示ISP阻擋特定網站,或要求App Store下架相關應用程式。 依據法案與附件內容,新加坡將線上侵害行為分為13類,並分階段實施,包含: 1. 網路騷擾(含性騷擾) 2. 人肉搜索 3. 網路跟蹤 4. 私密影像濫用 5. 兒少影像濫用 6. 網路冒名 7. 不實或合成素材濫用 8. 煽動傷害 9. 煽動暴力 最嚴重且高發生率的前5類,包括預計2026年上半年優先落地,前9類行為將隨後實施,構成法定侵權行為(statutory torts),受害者可據此向法院請求損害賠償或禁制令。 因應匿名性造成追查困難,法案也賦予OSC要求平台提供加害者身分資訊的權限,即OSC得要求平台提供其所持有之、涉嫌造成線上危害之終端使用者身分資訊。受害者在OSC認定遭受侵害後,也可申請揭露資訊以利提起侵權訴訟,但揭露資料若被濫用將構成刑事犯罪。政府表示,OSRA的制定歷經多場閉門會議與公開諮詢並獲得廣泛支持,將補強現行刑事與行政法規,為受害者提供更完整的救濟體系。法案預計在下次國會會期進行二讀審議。
經濟合作與發展組織發布《促進AI可歸責性:在生命週期中治理與管理風險以實現可信賴的AI》經濟合作與發展組織(Organisation for Economic Co-operation and Development, OECD)於2023年2月23日發布《促進AI可歸責性:在生命週期中治理與管理風險以實現可信賴的AI》(Advancing accountability in AI: Governing and managing risks throughout the lifecycle for trustworthy AI)。本報告整合ISO 31000:2018風險管理框架(risk-management framework)、美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST)人工智慧風險管理框架(Artificial Intelligence Risk Management Framework, AI RMF)與OECD負責任商業行為之盡職調查指南(OECD Due Diligence Guidance for Responsible Business Conduct)等文件,將AI風險管理分為「界定、評估、處理、治理」四個階段: 1.界定:範圍、背景、參與者和風險準則(Define: Scope, context, actors and criteria)。AI風險會因不同使用情境及環境而有差異,第一步應先界定AI系統生命週期中每個階段涉及之範圍、參與者與利害關係人,並就各角色適用適當的風險評估準則。 2.評估:識別並量測AI風險(Assess: Identify and measure AI risks)。透過識別與分析個人、整體及社會層面的問題,評估潛在風險與發生程度,並根據各項基本價值原則及評估標準進行風險量測。 3.處理:預防、減輕或停止AI風險(Treat: Prevent, mitigate, or cease AI risks)。風險處理考慮每個潛在風險的影響,並大致分為與流程相關(Process-related)及技術(Technical)之兩大處理策略。前者要求AI參與者建立系統設計開發之相關管理程序,後者則與系統技術規格相關,處理此類風險可能需重新訓練或重新評估AI模型。 4.治理:監控、紀錄、溝通、諮詢與融入(Govern: Monitor, document, communicate, consult and embed)。透過在組織中導入培養風險管理的文化,並持續監控、審查管理流程、溝通與諮詢,以及保存相關紀錄,以進行治理。治理之重要性在於能為AI風險管理流程進行外在監督,並能夠更廣泛地在不同類型的組織中建立相應機制。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局(National Security Agency, NSA)於2022年11月10日發布「軟體記憶體安全須知」(“Software Memory Safety” Cybersecurity Information Sheet),說明目前近70%之漏洞係因記憶體安全問題所致,為協助開發者預防記憶體安全問題與提升安全性,NSA提出具體建議如下: 1.使用可保障記憶體安全之程式語言(Memory safe languages):建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言,以取代C與C++等無法保障記憶體安全之程式語言。 2.進行安全測試強化應用程式安全:建議使用靜態(Static Application Security Testing, SAST)與動態(Dynamic Application Security Testing, DAST)安全測試等多種工具,增加發現記憶體使用與記憶體流失等問題的機會。 3.強化弱點攻擊防護措施(Anti-exploitation features):重視編譯(Compilation)與執行(Execution)之環境,以及利用控制流程防護(Control Flow Guard, CFG)、位址空間組態隨機載入(Address space layout randomization, ASLR)與資料執行防護(Data Execution Prevention, DEP)等措施均有助於降低漏洞被利用的機率。 搭配多種積極措施增加安全性:縱使使用可保障記憶體安全之程式語言,亦無法完全避免風險,因此建議再搭配編譯器選項(Compiler option)、工具分析及作業系統配置等措施增加安全性。