App Store是否得申請作為商標---Apple與Microsoft開啟戰火
2011年1月Microsoft針對Apple欲將App Store申請作為商標一案，向美國專利商標局(USPTO)提出即決判決(summary judgment)之申請，請求USPTO拒絕允許App Store註冊為商標。Microsoft主張「App Store」一詞係由「形容產品的普通名詞」加上「形容店面的普通名詞」而組成的詞彙，屬於普通性字眼(generic terms)，如同「Computer Store」一詞之前也被認定為屬於普通性詞彙，不得註冊為商標。此外，Microsoft還主張App Store這個詞語已經被許多同業、新聞媒體、消費者甚至Apple本身，作為普通性詞彙加以廣泛使用，例如黑苺公司使用App World、三星公司使用Samsung App、惠普公司使用App Catalog來形容自家的應用程式專賣店。因此，App Store不應被註冊為商標，否則將造成他人無法正常使用此普通性詞彙。
另一方面，Apple於2011年3月向美國專利商標局提出說明，反駁Microsoft的指控，Apple並舉The Paper Store、The Container Store等商標法先例，說明這些名詞最後皆被認定為具有爭議性之「描述性詞彙(descriptive terms) 」，而得以註冊登記為商標。Apple進一步認為Microsoft聘請的專家所提出可證明「App Store」一詞為普通性詞彙的相關證據，其取樣係有問題。因其是以app store小寫字樣為關鍵字，並輸入在Westlaw資料庫中進行查詢，而這樣的採樣方式，當然會導向app store一詞的使用情境偏向於普通性詞彙使用(generic use)。另外，Apple也以Microsoft十多年來大眾對其WINDOWS商標屬於普通性詞彙之爭議及指控為例，認為在衡量系爭詞彙是否屬於普通性名詞而無法作為商標使用的判斷上，須就系爭詞彙整體觀之，透過蒐集大量事實以評估系爭詞彙對相關大眾（relevant public）之主要意義(primary significance)為何。例如相關大眾就app store此詞彙的主要認知是聯想到「Apple」所經營的線上應用程式專賣商店，抑或相關大眾看到app store一詞直接想到其意指一般應用程式商店。
在雙方激烈唇槍舌戰中，究竟這場App Store商標申請准駁戰，會由Apple還是Microsoft取得勝利？容我們拭目以待。
施品安
副主任 編譯整理
MUSIC WEEK，2011年03月02日，http://www.musicweek.com/story.asp?sectioncode=1&storycode=1044390&c=1，最後瀏覽日：2011年03月03日
PCMAG.COM，2011年01月12日，http://www.pcmag.com/article2/0,2817,2375622,00.asp，最後瀏覽日：2011年03月03日
考量各行各業的從業習慣及民眾對企業蒐集、使用、揭露永久居留證(National Registration Identification Card, NRIC)號碼之看法，新加坡個人資料保護委員會(Personal Data Protection Commission, PDPC)於2017年11月提議修改個人資料保護法的諮詢指引(Advisory Guidelines on the Personal Data Protection Act )，明確界定企業蒐集、使用、揭露NRIC及其號碼之範圍。 依據舊的諮詢指引，新加坡個人資料保護法允許企業在基於合理特定目的並依法獲得當事人有效同意之情況下，蒐集、使用或揭露NRIC號碼。因此，不少企業活動習慣蒐集利用民眾的NRIC號碼，包括零售商店所舉辦的抽獎活動。然而，在PDPC提出新的諮詢指引後，企業可蒐集利用NRIC號碼的情況受到大幅限縮。 由於NRIC號碼與個人資訊息息相關且具不可取代性，無差別地蒐集利用將增加資料被用以從事非法活動之風險，故新的諮詢指引闡明，原則上企業不應蒐集、使用或揭露個人NRIC號碼或複印NRIC，除非有下列兩種例外情況之一：(一)法律要求；(二)為確實證明當事人身分所必要。第一種例外情況，雖因法律要求無須取得當事人同意，但企業仍應踐行告知義務，使當事人知悉NRIC號碼被蒐集、使用或揭露之目的，並確保企業內已採行適當安全措施，防止NRIC號碼被意外洩漏。第二種例外情況則仍須就NRIC號碼的蒐集、使用或揭露取得當事人同意，除非符合個人資料保護法規定下毋庸取得當事人同意之例外(如急救等緊急狀況)。 此外，PDPC針對得蒐集、使用或揭露NRIC號碼或複印NRIC的情況，以情境案例方式於諮詢指引中說明供企業參考，另給予12個月的審視期間，使企業得修正組織內部政策並尋找可行替代方案。
美國參眾兩院提出嚴禁專利藥廠簽訂授權學名藥協議系列法案美國過去透過Hatch-Waxman Act之立法，建立起「簡易新藥申請」（Abbreviated New Drug Application，ANDA）制度，促使學名藥廠開發學名藥後，能較迅速地通過藥品查驗登記，且首家獲得ANDA上市許可的學名藥廠還可享有180日的市場專屬保障；但是，專利藥廠近年卻設計出授權學名藥（Authorized Generic Drug）、原廠學名藥（Rebranded Generic Drug）和專利與學名藥訴訟和解協議（Brand-Generic Litigation Settlement）等智慧財產權管理策略，用以瓜分專利到期後的學名藥市場。 為了矯正此種實務發展，今（2007）年初美國參眾兩院先後提出內容一致的「公平處方藥競爭法案」（Fair Prescription Drug Competition Act, S.438）和「修正聯邦食品藥品化妝品法禁止授權學名藥上市法案」（To amend the Federal Food, Drug, and Cosmetic Act to prohibit the marketing of authorized generic drugs, H.R.806），禁止專利藥廠自行或間接製造銷售原廠學名藥，或是授權第三人製造銷售授權學名藥，企圖透過立法方式，確保首家提出ANDA的學名藥廠，在其所獲180日市場專屬期間內，不會因專利藥廠利用推出原廠或授權學名藥之策略而稀釋掉該學名藥的市佔率。但本法案未禁止專利藥廠與獲得市場專屬保護的學名藥廠簽訂類似協議；假使該學名藥廠經商業判斷後寧願與專利藥廠簽訂協議，僅需依現行規範將該協議通報FTC和司法部即可。 美國參議院亦提出「保護可負擔學名藥取得法案」（Preserve Access to Affordable Generics Act, S.316），禁止專利藥廠直、間接簽訂給予ANDA申請者任何對價（不限金錢）且要求其不得研發、製造、銷售或販賣該學名藥之專利侵權訴訟和解協議；例如專屬給付和解協議（Exclusion Payment Settlement）、逆向給付和解協議（Reverse Payment Settlement）等。
何謂德國電信媒體法中的「妨害人責任」(Störerhaftung)?原德國電信媒體法第八條條文中所指的「網路服務提供者」為擁有獨自或其他電信媒體及提供接取網路服務的自然人或法人，與我國著作權法中所提及「網路服務提供者」(Internet Service Provider)之適用對象範圍略有不同，而德國民法中有個特殊連坐法－「妨害人責任」（Störerhaftung），所有人對於妨害所有權之人，有排除及不作為請求權，因此，在原德國電信媒體法未規定之特定情形下，「網路服務提供者」應對他人透過其網路所從事的任何侵權違法行為負責。 這項法律使得德國許多咖啡館、公共空間、飯店大廳不願提供免費無線網絡，同時又讓大型咖啡連鎖店如星巴克，以提供免費網絡服務吸引顧客，因為他們就算被捲入網絡侵權責任的訴訟，也不怕支付高額律師費用，小型咖啡館就無法承擔這個風險，只能無奈面對客人轉向大型咖啡連鎖店消費的困境。根據原德國電信媒體法規定，咖啡館業主和其他網路熱點設立者所提供網路服務的方式將可能收到律師的警告函，告知他們不得再為非法下載者提供網路接取服務。 德國聯邦議院(Deutscher Bundestag)於2016年6月初經過激烈的辯論後，通過電信媒體法(Telemediengesetz; TMG)修正草案，將在最新的電信媒體法中免除「網路服務提供者」之「妨害人責任」(Störerhaftung)，使德國的免費無線網絡連接點可以增加並走向開放。
歐盟資通安全局公布《提升歐盟軟體安全性》研究報告歐盟資通安全局（European Union Agency for Cybersecurity, ENISA）於2020年4月25日以歐盟網路安全驗證框架（EU cybersecurity certification framework）檢視現行安全軟體開發及維護之方式與標準，並公布《提升歐盟軟體安全性》（Advancing Software Security in the EU）研究報告。歐盟資通安全局後續將以該研究報告協助產品、服務及軟體開發之驗證，並期望能夠成為執行歐盟網路安全驗證框架相關利害關係人之非強制性參考文件之一。 本報告指出由於安全軟體已普遍應用於日常商品與服務當中，但目前針對軟體安全事故並無相對應之安全守則及技術，故為提高軟體安全層級並緩解目前已知之軟體安全威脅，應針對安全軟體開發及維護進行規範並驗證。 報告中除了針對軟體安全提出其應具備之要素、概述現行安全軟體開發方式及標準之缺點外，亦提出若以歐盟網路安全驗證框架針對軟體開發方式進行驗證時可考量之一些實際做法，包括： 已驗證之資訊與通訊科技（Information and Communication Technology, ICT）產品、服務或流程供應商或製造商，針對資料庫之部署及維護，除探討防止資料洩漏之方式外，尚應考量產品、服務或流程驗證過程中，進行資料共享會面臨之安全威脅以及緩解之方式。 應與歐洲標準組織（European Standards Organizations, ESOs）及標準制定組織（Standards Developing Organization, SDOs）合作。 建立一些針對軟體開發、維護及操作準則以補充現有歐盟網路安全驗證方案（EU cybersecurity certification schemes）。 針對現行不一致之軟體開發及維護規範，應考量建立較寬鬆之合規性評估（conformity assessment）標準。 借鏡現有經驗和專業知識，促進歐盟網絡安全驗證框架之適用。