Apple獲得針對可攜式電子裝置之防竊系統的專利
Apple Inc.成功取得一個防竊安全系統的專利權，該系統能簡單地藉由偵測外界環境而防止筆記型電腦、電話以及其他可攜式電子裝置遭竊。
於原始申請案中，申請人提到了許多竊案皆提供了某些非偶然的移動線索，例如快速且持續的移動。因此，藉由分析該裝置於一段期間內的移動，該防竊系統應可辨別出竊盜或合法使用者。因此，當使用者暫時離開時，他們能放心地將可攜式電子裝置留下，而不需要加裝纜線鎖或其它物理性安全裝置。
根據該專利，此防竊系統包含加速規(accelerometer)以及相對應的軟體。加速規可在某些位置或震動情況下自動傳送一訊號至該裝置核心的硬體，致使其觸發聲音或影像警報。此外，該裝置也能完全被鎖住，並且需要一組密碼使其回復到正常使用狀態。
雖然Apple很小心地避免在說明前述機制時指明特定的應用硬體，但藉由該專利說明書的描述，可以很清楚的了解Apple的構想是將該防竊系統安裝在iPod上。當然，手機以及筆記型電腦也是安裝該防竊系統的顯著標的。
- http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7,218,226.PN.&OS=PN/7,218,226&RS=PN/7,218,226
- http://www.myiphone.com/apple-awarded-patent-for-mobile-security-system-16698.php
- http://www.appleinsider.com/articles/07/05/16/apple_patent_clears_road_for_theft_proof_iphones_macs.html
鄒宗萱
副所長 編譯整理
http://www.appleinsider.com/articles/07/05/16/apple_patent_clears_road_for_theft_proof
_iphones_macs.html，最後瀏覽日：2007年05月16日
http://www.myiphone.com/apple-awarded-patent-for-mobile-security-system-16698.php，最後瀏覽日：2007年05月16日
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7,218,226.PN.&OS=PN/7,218,226&RS=PN/7,218,226，最後瀏覽日：2007年05月15日
企業或機構對於所屬研發人員所為的 職務發明 ， 應該給予多少的報償才算「合理」，近年來成為日本專利制度的爭議話題之一，其中 Olympus Optical Co., Ltd. v. Shumpei Tanaka 、 Yonezawa v. Hitachi Co. Ltd. 、 Nakamura v. Nichia Chemical Co Ltd 幾件訴訟案件更受到高度矚目，引發各界對於日本特許法（即專利法）中第 35 條第 3 、 4 項相關規定之檢討與議論，進而促使日本國會於 2004 年 5 月 28 日 通過特許法修正案，並自 2005 年 4 月 1 日 正式生效。 修正後之日本特許法有關受雇人發明制度部分，修正了第 35 條第 3 項及第 4 項並新增第 5 項。第 35 條第 3 項規定，受雇人依據契約、工作規則或其他約定，同意授予雇用人關於受雇人所為發明之專利申請權、專利權或設定專用實施權時，受雇人對於雇用人有收取合理報酬之權。第 35 條第 4 項規定，依據前項所定之契約、工作規則與其他約定，訂有報酬之約定時，在該報酬之決定標準係經由受雇人與雇用人協議為之，該報酬標準係經公開，且受雇人對於計算報酬金額所表達之意見，亦被充分聽取的情形下，依據該約定所為之報酬金給付應被認為是合理的。又同條第 5 項之規定，若企業內部之契約、工作規則與其他約定，並未規定報酬金額，或雖有規定，但該規定之報酬金額被認為是不合理的，則第 3 項所規定之合理報酬金額，應權衡雇用人基於該發明所獲得之利益、所承受之負擔及對該發明所做之貢獻，與受雇人在相關發明中所獲得之利益及其他相關因素加以認定之。 上述修正規定最大的特色在於 ：（一）尊重自主協議 ； （二）報酬計算要件更加具體化 ； （三）鼓勵裁判外紛爭解決手段 。新修正之受雇人制度會帶來什麼樣的影響，目前各界仍在觀察；不過可確定的是，相較於舊法，新法至少在計算合理報酬上，要求雇用人須踐行更多的程序及其他要件，而這程序或要件規定將可減少法官在舊法時計算合理報酬金額的沈重負擔，與高度不確定所帶來的風險，並且亦可減少受雇人發明訴訟的總數量。 以日本電子大廠 Toshiba 新近在 7 月底與其離職員工 Fujio Masuoka 就閃光記憶晶片技術（ flash memory chip technology ）所達成之職務發明報酬和解協議為例， Toshiba 在 7 月 27 日 發布的新聞稿中，即特別感謝東京地方法院對公司有關員工職務發明之報酬政策及看法的尊重。
美國眾議院一致通過電子郵件保護法案美國眾議院於2016年4月27日一致同意通過支持電子郵件保護及雲端隱私法案（Email Privacy Act, EPA），本法案之後將會要求執法部門於搜查電子郵件或儲存於雲端設備的資料時，必須向法院取得搜查令，才能取得超過180天以上的資料。 本法案係針對1986年推出的《電子通信隱私法（Electronic Communication Privacy Act, ECPA》進行補強，因為目前科技的進步，早已遠超過ECPA是在網路興起前所得規制的範圍，在當初ECPA法案訂定之初，人民仍有定期刪除E-mail以保持硬碟空間的習慣，但相較於現在多數人都已使用雲端信箱的習慣下，如仍能讓警方等恣意調查任何人的信箱，往往可取得巨量的消息，因此本次的修正可預期將更能使相關規範符合時宜需求。 本次修正重點如下： 1.過往之ECPA規定要求聯邦機構在調查超過180天的電子郵件時只需要取得傳票即可，現在則是需要取得搜查令。 2.要求政府機構必須先取得法院的搜查令，才可以要求供應者揭露其保有之資訊。 3.要求執法部門應於取得資料的10天內向資料被揭露者提供相關證明，如涉及政府單位者則縮短至3天。 雖然EPA在眾議院內獲得美國兩黨的一致通過，但仍須經參議院下一波的投票表決，才能決定本案是否得順利通過。
歐盟法院判決二手軟體銷售合法歐盟法院在UsedSoft GmbH v. Oracle International Corp.（Case C-128/11）一案中，認定軟體開發商之散佈權在第一次銷售後即耗盡，不得限制其後二手軟體之再銷售。此一判決發展將影響軟體開發商之市場銷售策略。 本案軟體開發商Oracle以授權合約中的禁止移轉條款為據，起訴欲終止UsedSoft的二手軟體銷售模式。在此商業模式中，原始被授權人書面說明其被授權使用某軟體，同時聲明後續不再使用，相關文件經公證後，UsedSoft即以此文件及合約進行二手軟體的銷售，新的使用者可直接由UsedSoft取得軟體。 本案的關鍵點在於著作權是否隨著軟體第一次銷售而權利耗盡，如權利耗盡則合約中的禁止移轉條款將無任何效力。在傳統軟體光碟銷售的情形，被授權人可以將軟體再轉賣給任何人，權利耗盡是被確認的，但網站下載的軟體販售模式，權利是否隨之耗盡，則不無疑問。 歐盟法院在本案判決中表示，不管是負載於光碟或網站下載的軟體銷售，一旦開發商售出軟體，其權利即隨之耗盡；但同時也指出，如果原授權使用數量較多，權利耗盡並不得作為後續二手軟體切割販售授權的依據，開發商也不因此判決而必須提供軟體支援給二手被授權人。 此一判決可能刺激二手市場的成長，但同時也可能對軟體開發商帶來負面影響，開發商無法再掌握確實的被授權人，也無有效的方法確認原始授權人是否仍使用軟體。建議軟體開發商應檢視其授權作業，並嘗試從授權合約中處理，例如增加授權轉讓時應通知開發商的條款等。
經濟合作與發展組織發布《促進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風險管理流程進行外在監督，並能夠更廣泛地在不同類型的組織中建立相應機制。