澳洲證券投資委員會與美國商品期貨交易委員會簽訂雙邊合作協議
2018年10月4日，澳洲證券投資委員會（Australian Securities and Investments Commission，簡稱：ASIC）與美國商品期貨交易委員會（US Commodity Futures Trading Commission，簡稱：CFTC）簽訂「金融技術創新合作雙邊協議」（Cooperation Arrangement on Financial Technology Innovation’ bilateral agreement，簡稱：協議），該協議內容主要針對未來金融科技（fintech）以及監理科技（regtech）之合作以及相關資訊作交換。
協議內容主要為加強雙方瞭解、識別市場發展趨勢，進而促進金融科技創新，對於運用監理科技之金融產業採取鼓勵的態度。
具體協議內容及相關合作計畫為以下條款：
1. 建立正式合作途徑，其中包含資訊分享，ASIC創新中心與LabCFTC之間的溝通；
2. 協助轉介有興趣於另一管轄權，設立企業之金融科技公司；
3. 促進監管機構定期舉行相關監管會議，討論目前時下發展趨勢，藉以相互學習；
4. 針對非公開資訊及機密資訊，給予監管機構以共享方式流通資訊。
儘管，澳洲與美國已簽訂此協議，惟須注意的地方在於，此協議本質上不具備法律約束力，對監管機構也未加註責任，並強加特定義務，以及未取代任何國內法的法律義務。
雖然，此協議不具任何法律約束力，但美國以及澳洲之金融科技創新產業間已形成一定之默契，以及交叉合作。此種互利合作，使兩國金融創新企業在雙方管轄權下，並且降低跨境成本及加深跨境無障礙性，為兩國監管機構提供最佳執行方式，以及進一步資料之蒐集。
盧怡寧
法律研究員 編譯整理
ASIC Enters into Bilateral Cross-Border Cooperation Agreement with US Regulator - https://www.natlawreview.com/article/asic-enters-bilateral-cross-border-cooperation-agreement-us-regulator (last visited Oct. 18, 2018)
COOPERATION ARRANGEMENT - https://download.asic.gov.au/media/4894449/cftc-asic-fintech-arrangement-4-october.pdf (last visited Oct. 18, 2018)
日本數位市場競爭本部（デジタル市場競争本部）於2020年6月發布了「數位市場競爭中期展望報告」（デジタル市場競争に係る中期展望レポート案），該報告認為大型數位平台業者透過龐大的用戶資料，不斷地（1）擴大並連結用戶、（2）垂直整合上下游產業並（3）從虛擬鎖定實體的銷售，對市場形成動態競爭（ダイナミック競争）結果。此一結果將導致數位市場極易形成掠奪性定價或併購的風險、資料集中的風險、資料可靠性的風險，甚至是個人價值判斷的風險。 為促進數位市場的治理與信任，該報告提出了以下短期與中長期的政策方向： 鼓勵企業數位轉型以增加數位市場的多樣性：推廣數位轉型指標、擴大沙盒制度適用、加速數位政府戰略。 建立數位市場競爭制度：運用經濟分析強化競爭管制、推動《數位平臺交易透明法》（デジタルプラットフォーム取引透明化法）法制化、建立大型數位平台調查機制。 建構去中心化的資料治理技術：透過資料持有、交換的「去人工干預」，形成一個可信任的網路世界。 該報告已於2020年8月7日完成公眾意見募集，預計於2020年年底前提出最終報告。目前日本新經濟聯盟認為，高頻率的競爭策略以及智慧化交易模式下的反壟斷政策，除了不正競爭的禁止外，政府更應著重在透明化檢視機制的建立。此外報告目前並未處理到平台資料治理的課題，聯盟對此認為政府應更積極地從資料壟斷的概念，調整數位市場准入的障礙。
因應美國華盛頓州《我的健康我的資料法》施行，受監管對象隱私權政策應更新美國華盛頓州《我的健康我的資料法》（My Health, My Data，以下簡稱該法）於2024年3月31日生效，該法係於2023年4月27日通過。目標在於保護華盛頓州消費者的健康資料，特別是生殖健康相關資料（data related to reproductive healthcare）。所拘束對象並不在HIPAA之監管範圍內，包括穿戴式裝置（wearables）、特定零售購物和非HIPAA 所規範之遠距醫療服務（telehealth services）所蒐集之資料。 該法最繁瑣合規要求之一為，受監管對象必須在其主頁上公佈消費者健康資料相關隱私權政策（下統稱隱私權政策）連結，連結必須為獨立、特定且不得包含該法所未要求之額外資訊。另針對小型企業，則設有三個月之緩衝時間，即應於 2024 年 6 月 30 日前遵循該要求。 隱私權政策必須清楚且醒目地揭露以下內容： 1. 所蒐集之健康資料類別和蒐集目的，包括將如何使用這些資料； 2. 所蒐集健康資料來源及類別； 3. 共享之健康資料類別； 4. 共享消費者健康資料的第三方或相關企業之類別；以及 5. 消費者如何行使該法所賦予之權利，包括撤銷同意和要求刪除之權利。 最重要的是，除特殊情形外（即1.已揭露其他特定目的2.取得消費者對其他特定目的所為蒐集、使用、揭露之明確同意），受監管對象不得基於隱私權政策中未明確揭露之任何其他目的，蒐集、使用或共享消費者健康資料。 若違反該法相關規定，即被視為違反《華盛頓州消費者保護法》（the Washington Consumer Protection Act），可由華盛頓州總檢察長提出強制執行。另該法為美國第一部保護大量健康資料之法律，顯現對消費者資料保護監管逐漸嚴格之趨勢。
印度為促進新創公司發展 將不予受理軟體專利申請案印度「專利設計與商標管理局」（Controller General of Patents, Designs and Trademarks）於2016年2月19日發佈最新的「審查電腦相關之發明專利準則」（Guidelines for Examination of Computer Related Inventions, CRIs），決定在專利申請之審查程序中落實印度於1970年所制定的專利法(Patents Act, 1970)之意旨，未來當局將不再受理與電腦相關的軟體專利申請案。印度《專利法》第3條第k項排除本質上為數學演算法、商業方法與電腦程式運算法則等申請案之可專利性（Patentable）。該規定在印度《專利法》於2002年、2004年與2005年修法過程中，雖面臨各方利益團體試圖影響國會立法放寬法定可專利性範圍的壓力，但仍然為印度國會（Bhārat kī Sansad）所保留。 然而，印度「專利設計與商標管理局」卻於2015年8月21日發佈違反《專利法》意旨的CRIs，導致軟體專利的可專利性被實質上放寬。一般認為開放申請軟體專利的政策將會阻礙新創公司的發展，並有利於所謂「專利主張實體」（Patent Assertion Entity, PAE）藉大量軟體專利向一般公司提起訴訟或請求授權金，導致印度當局遭受國內新創軟體公司與相關非政府組織的激烈抗議。 「自由軟體法律中心」（Software Freedom Law Center, SFLC）與「印度軟體產品圓桌會議」（Indian Software Product Industry Round Table, iSPIRT）等機構即代表眾多新創公司與學術界人士上書印度「總理辦公室」（Prime Minister’s Office），請求政府對2015年8月發佈的CRIs進行檢討。SFLC等組織的積極作為，成功說服印度當局作出暫緩該高度爭議的CRIs生效之決定。代表SFLC等組織的專家表示，印度的軟體已受到《著作權法》與《營業秘密法》的足夠保障，進一步開放發明人申請軟體專利只會對該國軟體產業並無助益。 印度當局與相關團體在數個月間密集的進行研議，終於在2016年2月決定修正原先發佈的CRIs，使其回歸印度《專利法》不開放軟體專利申請的立法意旨。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。