魔術方塊立體商標權與競爭法之交會
今年5月26日，歐盟高等法院做出裁決，認為魔術方塊不應擁有立體商標權的保護，結束了長達十年的魔術方塊立體商標權爭議。而本案於11月10日已結束聽證會（full hearing），多數意見仍然支持法院的觀點。
歐盟高等法院認為，魔術方塊的立體造型外觀，已成為他3D多面旋轉功能不可或缺的一部分，如果賦與其商標權保護，由於商標權可無限期展延的特性，等於永久阻止所有相同或類似造型外觀的產品上市，間接妨礙了技術上的突破與創新，形成一種相同或類似技術上的獨占地位（monopoly）。裁決更指出，其應以專利權作為申請標的，以保障發明人智慧財產權，而非以商標權變相延伸專利權的保護範圍。
在類似的案例中，雀巢的四指造型巧克力被歐盟法院（CJEU）駁回，理由之一為產品形狀為達到技術結果的必須條件（該造型提供了掰開巧克力的獨特方式），與本案有異曲同工之妙。
然而，反對見解認為，如不賦與魔術方塊立體商標，等於鼓勵仿冒者用相同或類似外觀作為商標使用，而不論該仿品外觀是否確實賦與相同之技術結果，間接限縮了立體商標權的保護效力。
我國立體商標審查基準中也有類似的規定，排除具有功能性的外觀造型註冊立體商標。然而，應該思考的毋寧是，當產品技術水準無法成功申請專利權保護時，如同時駁回該產品外觀的立體商標註冊，則該如何維護該產品的智慧財產權，又該如何防止他人抄襲與仿冒，是本案遺留下的重要問題。
張君任
法律研究員 編譯整理
Rubik’s cube makers square up in trademark battle, Nov.6,2016 https://www.ft.com/content/1ccb76c8-a113-11e6-86d5-4e36b35c3550 (Last visited Nov.8, 2016)
EU court could scrap Rubik’s Cube trademark, May.26,2016 http://bbj.hu/economy/eu-court-could-scrap-rubiks-cube-trademark_116679 (Last visited Nov.8, 2016)
Court House News Service, May.25,2016 http://www.courthousenews.com/2016/05/25/rubiks-cube-trademark-is-invalid-eu-adviser-says.htm (Last visited Nov.8, 2016)
Court of Justice of the European Union PRESS RELEASE No 52/16, May.25,2016 http://curia.europa.eu/jcms/upload/docs/application/pdf/2016-05/cp160052en.pdf (Last visited Nov.8, 2016)
2025年2月7日，經濟合作暨發展組織（Organization for Economic Cooperation and Development，OECD）正式啟動《開發先進人工智慧系統組織的報告框架》（Reporting Framework for the Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems，簡稱G7AI風險報告框架）。 該框架之目的是具體落實《廣島進程國際行為準則》（Hiroshima Process International Code of Conduct）的11項行動，促進開發先進人工智慧系統（Advanced AI Systems）的組織建立透明度和問責制。該框架為組織提供標準化方法，使其能夠證明自身符合《廣島進程國際行為準則》的行動，並首次讓組織可以提供有關其人工智慧風險管理實踐、風險評估、事件報告等資訊。對於從事先進人工智慧開發的企業與組織而言，該框架將成為未來風險管理、透明度揭露與國際合規的重要依據。 G7 AI風險報告框架設計，對應《廣島進程國際行為準則》的11項行動，提出七個核心關注面向，具體說明組織於AI系統開發、部署與治理過程中應採取之措施： 1. 組織如何進行AI風險識別與評估； 2. 組織如何進行AI風險管理與資訊安全； 3. 組織如何進行先進AI系統的透明度報告； 4. 組織如何將AI風險管理納入治理框架； 5. 組織如何進行內容驗證與來源追溯機制； 6. 組織如何投資、研究AI安全與如何降低AI社會風險； 7. 組織如何促進AI對人類與全球的利益。 為協助G7推動《廣島進程國際行為準則》，OECD建構G7「AI風險報告框架」網路平台，鼓勵開發先進人工智慧的組織與企業於2025年4月15日前提交首份人工智慧風險報告至該平台（https://transparency.oecd.ai/），目前已有包含OpenAI等超過15家國際企業提交報告。OECD亦呼籲企業與組織每年定期更新報告，以提升全球利益相關者之間的透明度與合作。 目前雖屬自願性報告，然考量到國際監理機關對生成式AI及高風險AI 系統透明度、可問責性（Accountability）的日益關注，G7 AI風險報告框架內容可能成為未來立法與監管的參考作法之一。建議企業組織持續觀測國際AI治理政策變化，預做合規準備。
日本政府擬修法全面禁止濫發商業電子郵件為解決日益嚴重的騷擾郵件問題，日本總務省於今（2008）年2月29日向國會提出「特定電子郵件送信適當化法修正案（特定電子メール送信適正化法改正案）」，將全面禁止未經收件人事前同意而擅自寄發宣傳廣告郵件，並將海外寄送之騷擾郵件列入適用範圍。 依據現行法之規定，未取得收件人同意寄送廣告或宣傳之郵件時，必須在主旨上標明「未經同意廣告」，並負有標示寄件人名稱、電話號碼之義務。如收件人發出拒絕收件之通知時，即禁止再傳送相關郵件；違反者將處以一年以下拘役或100萬日圓以下罰金。然而，一旦收件人回覆拒絕收件，將使業者察知該郵件帳號為有效帳號；故收件人對騷擾郵件大多不予理會，但如收件人未回覆拒絕收件之訊息時，該騷擾郵件仍得合法寄送。此外，依據調查，目前騷擾郵件中，有九成的電腦郵件及半數的行動電話簡訊，均是從海外所發出，而迴避了現行法之規範。 因此，本次修正草案明定全面禁止未經同意擅自傳送商業電子郵件至他人電腦或行動電話；即使取得收信同意，如中途拒絕時，其後即禁止再傳送郵件。此外，草案並課以郵件中應明示寄件者姓名、名稱及電子郵件地址，並要求須保存如何取得收件者同意之相關記錄。現行法不適用之海外寄送之騷擾電子郵件，也將與日本國內電子郵件受到相同規範。如偽裝電子郵件地址而傳送郵件時，或經總務省要求改善而未加以改善時，將處以最高3000萬日圓罰金。本修正法案預定於2008年中施行。
澳洲國家交通委員會針對駕駛法規之修正進行公眾諮詢，聚焦自駕系統實體法律義務澳洲國家交通委員會(National Transport Commission, NTC)於2017年10月3日提出「修正駕駛法律以支持自動駕駛車輛(Changing driving laws to support automated vehicles)」討論文件，向相關政府機關與業界徵詢修正駕駛法規之意見。此文件目的在於探討法規改革選項，並釐清目前針對駕駛人與駕駛行為法規對於自駕車之適用，並試圖為自動駕駛系統實體（automated driving system entities, ADSEs）建立法律義務。文件中並指出改革上應注意以下議題： 目前車輛法規皆以人類駕駛為前提； 自動駕駛系統並不具有法律人格，無法為其行為負法律責任； 目前的法律並未提供法律實體之定義或規範（即自動駕駛系統實體ADSEs）來為自動駕駛系統行動負責； 目前有些法律上人類駕駛應負之義務，無法直接於自動駕駛時由ADSEs負擔； 車輛之安全義務於自動駕駛時，可能需由非駕駛之他人執行； 法律中並未定義自動駕駛系統車輛的「控制」與「恰當控制」； 目前沒有規範何時人類應有義務將駕駛控制權力自自動駕駛系統轉移回來，來確保人類駕駛保持足夠之警覺性； 目前的遵循與實施規範可能不足以確保自動駕駛系統的安全運作。 NTC並提出建議應定義自動駕駛系統之法律實體，重新規範人類與自動駕駛系統法律實體間的義務。澳洲國家交通委員會將進一步將諮詢結果與法律改革選項於2018年5月提供給澳洲交通部。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。