美國專利標示不實之罰金計算
美國聯邦巡迴上訴法院在2009年底於The Forest Group Inc. v. Bon Tool Co. 一案中將美國專利法35 U.S.C. § 292中關於不實專利標示(false patent marking)的懲罰金計算方式認定為罰金之計算是以每一個標示錯誤專利資訊的產品為基礎。美國專利法35 U.S.C. § 292中要求法院對專利資訊標示不實或錯誤之產品或包裝處以最高美金$500的罰金。在此案之前，許多地方法院將35 U.S.C. § 292解釋為罰金之計算是以每一次被告”決定”將產品標示不實專利資訊為基礎 (single penalty for each “decision” to falsely mark products)，不論此決定是包含一個或一整批產品。在本案中，聯邦巡迴上訴法院同意地方法院的看法認定被告Forest Group意圖藉不實專利標示企圖欺騙大眾但撤銷地方法院將罰金定為$500之判定，而將目前專利法35 U.S.C. § 292 解釋為罰金是以”每一個”標示錯誤專利資訊的產品為基礎 (penalty for false marking on a per article basis)。
為了防範日後因此案罰金計算方式而造成所謂”標示流氓”(marking trolls) 之興起，聯邦法院於其判決中特別說明其解釋並非要求法院必須將每一標示錯誤專利資訊的產品處以$500美元的罰金。因法條中之罰金是以美金$500為上限，法院有權利權衡各案例背景決定罰款金額。例如，針對大量製造但價錢低廉的產品， 法院可對每一個產品處以極少的罰金。
The Forest Group 一案是美國聯邦巡迴上訴法院第一次針對不實專利標示之罰金提出解釋，直得關注其後續引發反應。廠商也應重新檢視其產品專利標示是否有不實或錯誤之狀況以避免被控標示不實專利資訊而被處以罰款。
瑞典斯德哥爾摩地方法院於2015/11/27針對網路服務提供者（ISP）責任作出判決，有別於過往相關著作侵權訴訟，對象係針對個人或是散布侵權檔案之網站經營者，此次為針對網路服務提供者責任作成的第一筆判決，其結果具有指標性意義。 此次訴訟是由華納、新力、聯合音樂、北歐電影與瑞典電影中心聯合提起，請求法院命一瑞典ISP業者阻斷二個涉及著作權侵害之網站連結。原告等聲稱被告提供網路連接到侵權網站之行為，已構成侵害行為的參與（medverkar），據此請求法院禁止被告繼續此參與侵害行為。然法院未予採納，認為：（一）依歐盟指令（Infosoc-directivet）之要求，若網路中介者之服務受到第三人利用，作為侵害著作權及其鄰接權之用途，各會員國須提供著作權人司法救濟途徑，以對抗中介人。由於瑞典著作權法已提供禁制令（föreläggande）之申請予著作權人，藉此對抗參與侵害行為的幫助犯。可見瑞典著作權法已符合指令之要求。（二）其次，法院認定本案被告係單純提供其顧客網路聯結到侵權網站，不構成瑞典著作權法上之參與侵權行為。因所謂參與必須是客觀上對侵權行為人有幫助行為（如給與建議及諮詢），但本案被告並未與侵權網站有任何契約或特定關係，不能因為少部分之非法使用者利用其網站連結便認定其構成參與侵權行為。故法院認定本案不具備核發禁制令條件，駁回原告等請求。對此，原告擬提出上訴，後續發展有待觀察。
美國提出「個人資料隱私暨安全法案草案」，規範聯網環境商業應用及隱私權利面對層出不窮資料違背或身份竊盜事件，2014年初， FTC於美國國會的例行會議上，就數位時代關於隱私權之保護課題進行作證，會議中，FTC乃呼籲美國國會應立即通過制定一個更強的聯邦資料安全與違背提醒的法律，其也進而提出「個人資料隱私暨安全法案（草案）」 (Personal Data Privacy and Security Act of 2014, S.1897)。該草案主要分成兩大部分: 第一部份，將強化身份竊盜和其他違反資料隱私與安全之懲罰；第二部份，係關於可茲辨識個人資料(PII)之隱私和資訊安全。 法案第202條係關於「個人資料隱私與安全機制」（personal data privacy and security program），目的在強化敏感性可茲辨識個人資料的保護，從行政(administrative)、技術(technical)和實體(physical)三個構面的防衛機制，進行相關標準之制訂與落實。有關適用之範疇，乃就涉及州際貿易之商業實體，而該州際貿易包含蒐集、近取、傳輸、使用、儲存或在電子或數位格式處理可茲辨識個人之敏感性資料，而這些資料總計多達1萬筆以上，然而，將不適用於金融機構(financial institutions)、醫療保險轉移和責任法(HIPPA)所管制者、服務提供者(service provider)和公共紀錄(public records)。 而在機制設計上，也係從「設計」(DESIGN)、「風險驗證」 (RISK ASSESSEMENT)和「風險管理」(RISK MANAGEMENT)三個角度進行切入，也必須確實提供員工教育訓練(TRAINING)、弱點測試(VULNERABILITY TESTING)、定期驗證和個人資料隱私與安全之更新，另外，在與外部與服務提供者(例如ISP)之關係上，公司必須盡到適當勤勉的義務(due diligence)，也必須透過契約(contract)方式，約定前述所建置起之資料隱私安全機制，並在安全性遭受到侵害時，以合理方式通知締約他方。 本案目前在聯邦參議院已經二讀通過，已交付參議院司法委員會進行下一階段的審議，該立法草案未來是否會直接或間接影響物聯網環境生態系統之商業運作，有待未來持續關注之。
日本簽署SBOM國際共通指引，強化軟體弱點管理，全面提升國家網路安全由美國網路安全暨基礎設施安全局（Cybersecurity and Infrastructure Security Agency, 簡稱CISA）自2024年以來，持續主導並規劃《SBOM網路安全之共同願景》（A Shared Vision of Software Bill of Materials(SBOM) for Cybersecurity）之指引訂定，作為保障網路安全之國際共通指引。於2025年9月3日，由日本內閣官房網路安全統括室為首，偕同經濟產業省共同代表日本簽署了該份指引，包含日本在內，尚有美國、德國、法國、義大利、荷蘭、加拿大、澳洲、紐西蘭、印度、新加坡、韓國、波蘭、捷克、斯洛伐克等共計15個國家的網路安全部門，皆同步完成簽署。以下為指引之重點內容： 1. 軟體物料清單的定位（Software Bill of Materials, 簡稱SBOM） SBOM於軟體建構上，包含元件內容資訊與供應鏈關係等相關資訊的正式紀錄。 2. 導入SBOM的優點 (1) 提升管理軟體弱點之效率。 (2) 協助供應鏈風險管理（提供選用安全的軟體，提升供應商與使用者之間溝通效率）。 (3) 協助改善軟體開發之進程。 (4) 提升管理授權軟體之效率。 3. SBOM對於利害關係人之影響 (1) 使軟體開發人員可選擇最符合需求的軟體元件，並針對弱點做出適當處置。 (2) 軟體資訊的透明化，可供採購人員依風險評估決定是否採購。 (3) 若發現軟體有新的弱點，使軟體營運商更易於特定軟體與掌握弱點、漏洞。 (4) 使政府部門於採購流程中，發現與因應影響國家安全的潛在風險。 4. SBOM適用原則與相關告知義務 確保軟體開發商、製造商供應鏈的資訊透明，適用符合安全性設計（Security by Design）之資安要求，以及須承擔SBOM相關告知義務。 近年來軟體物料清單（SBOM），已逐漸成為軟體開發人員與使用者，於管理軟體弱點上的最佳解決方案。然而，針對SBOM的作法與要求程度，各先進國家大不相同，因此透過國際共通指引的簽署，各國對於SBOM的要求與效益終於有了新的共識。指引內容不僅建議軟體開發商、製造商宜於設計階段採用安全設計，以確保所有類型的資通訊產品（特別是軟體）之使用安全，也鼓勵製造商為每項軟體產品建立SBOM並進行管理，包含軟體版本控制與資料更新，指引更強調SBOM必須整合組織現有的開發與管理工具（例如漏洞管理工具、資產管理工具等）以發揮價值。此份指引可作為我國未來之參考借鏡，訂定相關的軟體物料清單之適用標準，提升政府部門以及產業供應鏈之網路安全。
經濟合作與發展組織發布《促進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風險管理流程進行外在監督，並能夠更廣泛地在不同類型的組織中建立相應機制。