.Akamai 一案改變了邦巡迴法院認定間接侵權的判斷
2014年Akamai Technologies針對最高法院提起上訴，因此發回聯邦巡迴法院重審，而後上訴法院認為Limelight Networks確實侵害Akamai的專利，Akamai並獲得$ 45.5萬美元的損害賠償。 2006年，Akamai Technologies公司（下稱Akamai）在美國馬薩諸塞州地方法院起訴Limelight Networks（下稱Limelight），指控Limelight侵害Akamai美國專利號6108703。原告Akamai的專利是有效傳送網頁內容的方法專利。而被告Limelight是經營伺服器網路的公司，和Akamai該專利的差別在於Limelight指示用戶完成其中一個修改的步驟。
本案從2006年一直持續到2014年向最高法院上訴為止，都是依據美國專利法第271條規定直接和間接侵權的概念。在原審認為「實施該方法專利」的侵權行為，是要求實施方要獨立完成該侵權行為，所以Limelight不能被視為直接侵權。又因為Limelight公司並沒有滿足單一實體規則（single-entity rule），控制或指示（control or direction）其實施方完成其他的專利之方法步驟，所以不用負共同侵權責任。
但上訴聯邦巡迴法院一致贊成Akamai被侵權，並指出如果被告 Limelight知道並使用專利權人Akamai的專利，而且執行大部分的步驟，只保留一項步驟未執行，進而引誘用戶執行該方法專利的最後一個步驟，且用戶真的執行了該最後一步驟， Limelight就構成美國專利法271(b)間接侵權中的引誘侵權。
- 楊智傑, 方法專利之共同侵權與引誘侵權－ 以美國聯邦巡迴上訴法院2012年Akamai案為例, May 6,2014
- Susan Decker,Akamai Wins Appeal in $45.5 Million Limelight Patent Case,Bloomberg Business, August 13, 2015
- Diego F. Freire and Michael Borella, Akamai Technologies,Inc. V . Limelight Networks, Inc.(Fed. Cir. 2015),patentdocs,June 21, 2015
- Chris DiMarco,Court Sides with Akamai Technologies in Infringement Battle,Legaltech News, August 14, 2015
英格蘭與威爾斯法律委員會(The Law Commission of England and Wales)與蘇格蘭法律委員會(The Scottish Law Commission)於2022年1月26日聯合提出¬「自駕車修法建議報告（Automated Vehicles: joint report）」，總結其自2018年來三次公眾意見諮詢之回應分析，提出75項法律修正建議，提交英格蘭及蘇格蘭議會決議是否採納並修法。 修法建議範圍涵蓋廣泛，重要突破性建議包含： （1）整合英國原有之《2018自動與電動車法（Automated and Electric Vehicles Act 2018）》中自駕車之認定標準，訂定一套雙階段自動駕駛認證許可制度，於第一階段審驗「整車」之規格是否符合國際或國內車輛型式安全審驗標準，並於第二階段審驗¬¬¬「個別自駕功能」是否能符合國內交通法規。 （2）提出「主責使用者（User-In-Charge, UIC）」概念，若車輛設計為在某些情形下需要人工接手駕駛，則自動駕駛系統（Automated Driving System, ADS）啟動時，坐在車內駕駛座之自然人即為UIC。 （3）對於不需要UIC車輛（No User-In-Charge, NUIC）營運平台業者，以及合法自駕車業者（Authorized Self-Driving Entities, ASDE），提出資格條件要求，包含必須具備良好名聲、財務穩健，必須向主管機關提交安全案例（safety cases）等。 （4）因《2018自動與電動車法》中已有要求自駕車均須投保保險，因此當自駕車造成車禍及損傷，不需先經確認有無人為故意過失，即可先行以保險進行賠償。事後若保險公司認為自駕車設計製造者有責任，得再依商品責任規範轉向車廠求償。 （5）而為了幫助事故調查、釐清責任，自駕車相關資料之持有者（如ASDE）應將相關資料保存3年又3個月，以配合侵權行為之法律請求權時效。 本分報告綜合各方意見，以務實之態度提出具體修法建議，深具參考價值，值得我國深入研析。
馬爾他政府針對電子商務法之建議修法內容尋求公眾意見馬爾他競爭力暨通訊部 (Ministry for Competitiveness & Communications, MCMP) 部長 Censu Galea 九月二日公布了「電子商務法」建議修法內容之公開諮詢文件。部長特別強調了電子商務的重要性，尤其對地理位置孤立的島國如馬爾他，電子商務更能有效克服其競爭力上的缺憾。 馬爾他「電子商務法」 自 2002 年生效以來，該國的電子商務呈現蓬勃發展之勢，亦達到 為資訊社會鋪路之目的 。 此次修法建議欲建立一輕度但有效的管理機制，此機制不但能確保網路服務提供者切實遵循法律義務，並加強了消費者權益的保護。另外，此修法建議也計劃完整移植歐盟電子商務指令及電子簽章指令之規定。 馬爾他通訊局 (Malta Communications Authority, MCA) 身為修法建議中的主管機關，將獲授權得於法庭外調解網路服務提供者與消費者間之爭議。 該修法建議亦設計相關措施，確保在馬爾他成立的資訊社會服務提供者不受不必要的官僚體系而阻礙發展。在馬爾他設立之資訊社會服務提供者不論其在何國提供服務，都將只受馬爾他法律規範。再者，這些服務也不必經過任何形式的許可。 該修法建議亦要求網路服務提供者必須揭露基本資訊，讓客戶了解其交易對象，並維持網路交易過程一定的透明度。
何謂「三螺旋理論」三螺旋理論，又稱三螺旋創新模型理論（Triple Helix Theory），主要研究大學、產業以及政府以知識經濟為背景之創新系統中之型態關係，由Etzknowitz與Leydesdorff於1995年首次提出。 因應知識經濟時代來臨，三螺旋理論著重於政府、學術界與產業界（即為產、官、學）三者在創新過程中互動關係的強化。該理論探討如何協調產業、政府、學界三方於知識運用和研發成果產出上的合作；當社會動態產生改變，過去單一強大的領域將不足以帶動創新活動，推動創新也非單一方的責任，此時產業、政府、學界的三螺旋互動便隨之發生：大學透過創新育成機構孕育企業創新，而產業則扮演將研發成果商業化之要角，政府則透過研發相關政策、計畫或法規制定，鼓勵企業和大學間研究發展合作。 有別於早期經濟合作暨發展組織（OECD）將「產業」作為主要研發創新主體，三螺旋理論更重視產業、政府、學界三大主體均衡發展，三方主體各自獨立發展，且同時與其他方維持相互協力合作，共同推進經濟與社會之創新發展。 在三螺旋理論下，產、官、學因其強弱不等的互動狀態，形成不同的動態模型（例如國家干預模型、自由放任模型、平衡配置模型等等），這些動態模型被認為是產生創新的主要動力來源，對未來新知識和科技創造與擴散的能力以及績效具有決定性的影響力。
經濟合作與發展組織發布《促進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風險管理流程進行外在監督，並能夠更廣泛地在不同類型的組織中建立相應機制。