日本國土交通省公布最後一哩路自駕車系統指引
為促進自駕車研發和推廣，日本國土交通省召集產官學研各界成立先進安全汽車（Advanced Safety Vehicle, ASV）推進檢討會，檢討設計自駕車時之注意事項，並於2020年7月17日公布「最後一哩路自駕車系統基本設計書」（ラストマイル自動運転車両システム基本設計書），希望能藉此達成確保地方交通運輸能量及加速自駕車落地之目標。
「最後一哩路自駕車系統基本設計書」將操作適用範圍（Operational Design Domain, ODD）定義為限定區域或駕駛環境條件，並提出所有自駕車應具備之共通ODD，包括（1）道路/地理條件︰目標道路、行駛道路；（2）環境條件︰時間、天氣；（3）行駛條件︰行駛速度；（4）行駛空間︰可支援自駕車行駛之基礎設施，以及可提醒用路人注意正在進行自駕車實驗之設施。此外，由於不同應用情境會影響ODD之設定，故本書以限定路線下往返之自駕車為代表，說明在個案中該如何進一步檢討ODD。以行駛速度為例，在共通ODD中，最後一哩路自駕車時速應為30公里，但在提供限定路線內往返之載客服務時，自駕車的時速應設定在12公里以下。最後，「最後一哩路自駕車系統基本設計書」內整理最後一哩路自駕車共通及特有之技術要件，以及設計時應留意和確認的問題。
本文為「經濟部產業技術司科技專案成果」
周晨蕙
副主任 編譯整理
2.柯亦儒，〈英國BSI發布自駕車發展與評估控制系統指引〉，2020/07，https://stli.iii.org.tw/article-detail.aspx?tp=5&i=180&d=8492&no=67（最後瀏覽日期︰2020/10/05）。
美國的數位服務推動小組18F（Digital service delivery，18F），因辦公室位於華盛頓特區F街18號而得名。2014年3月由總務署（General Service Administration，GSA）成立，透過業界與政府合作模式，幫助政府機關改善流程及增進效率，其所輔導的專案計畫將實際轉變政府機關提供數位服務及科技產品之運作模式，以達跨部會、機關之整合，並使對公眾的數位服務更便於使用。 18F為幫助美國各機關建造、購買及分享現代數位服務以提升政府的使用者經驗，提供了五項服務：（一）就已存的數位規格（digital component）打造訂製化產品（custom products）；（二）以創新方式購買科技，使各政府能夠獲得更快、更好及產生更好結果的IT服務。詳細服務內容有代寫委外服務建議書（Request For Proposal，RFP）、開發市場利用現代技術購買IT服務、購買開放源代碼（open source code）以提升專案計畫；（三）替政府建造一安全、可擴展的工具與平台，其能更加符合需求並能夠持續為改善以達需求；（四）協助成為數位化組織，不只是增加組織內部數位化能力，更要形成數位習慣並最終促使組織文化改變；（五）透過討論會、設計工作室、指南及文件工作平台，提供及分享18F實際運用的相關現代數位化服務技術，使政府機關能自行複製及使用。 近期知名成果案例發生於加州。在加州，每一年的孩童福利服務案件管理系統超過2萬名社工利用為追蹤管理超過50萬件虐待及忽視兒童案件，若使用過時系統產生風險將無法估計，故加州政府、美國衛生與人群服務部（Department of Health and Human Services，DHHS）即利用了前述相關服務，與18F共同重新設計該系統的採購流程。從2015年11月至2016年10月，合作建立新系統不到1年的時間，導入了契約文件之簡化、模組化（modular）契約之合併、敏捷性開發（agile development）、使用者中心之設計及開放源（open source）之實踐。 首先，代寫委外服務建議書，18F於其中展示如何將專案計畫為模組化，亦即別於過往採購的傳統模式，非尋找單一開發商去建置整個已預設需求的系統，透過分離的方式，找尋不同開發商以更符合實際需求，亦能避免時間金錢的浪費，降低遲約或違約之風險。再者，聚集可能符合資格的供應商，邀請眾供應商建造以開放源代碼（open source code）方式的原型（prototype）。透過此一過程的激盪，18F從中協助評估所提出的原型、技術等，以了解供應商如何提出及是否符合使用者中心的設計。同時也能減少政府與供應商雙方的招標時間及行政成本。最後，為使加州政府機關能自行複製及使用相關現代數位化服務技術，18F示範敏捷軟體開發（agile software development）專案計畫。從中加州政府不僅瞭解如何為風險評估，且思考相關技術部門於專案計畫中的角色定位。 面臨現代化數位服務，在美國，聯邦與州政府都面臨極大挑戰。18F介入發展新模式，更能達實際需求，亦為內化之協助，利於政府自行發展其他數位服務。18F與加州政府合作之案例，或許能為國家發展數位服務運作之借鏡。
韓國「2021年經濟政策」韓國財政經濟部（Ministry of Economy and Finance）於2020年12月17日發布「2021年經濟政策」（2021 Economic Policies）。2021年經濟政策中包含兩大重點，分別為因應新型冠狀病毒影響下的不確定性，盡快恢復經濟成長動能，以及推動產業創新與結構轉型，以培植未來的經濟成長動力。政策文件中指出，儘管2020年經濟成長率因疫情影響而表現低迷，但仍期許2021年經濟能夠盡快好轉，改善投資、出口與國內就業。 針對如何盡快恢復經濟成長動能議題，政策文件指出首先應處理因疫情帶來的不確定性，除了維持擴張性財政政策，以增加政府支出刺激總體需求外，在經濟成長與疫情防治間應取得平衡並加強風險管理；其次為透過租稅減免促進消費、擴大投資額度與提供出口融資，以及提供資金以扶植中小企業、提供優惠貸款協助大型企業度過疫情難關、鬆綁法規以發展地方經濟等一連串措施，來達到恢復經濟成長動能的目標。 而在推動產業創新與結構轉型上，將持續投資於5G應用與6G技術的發展上，推動數位經濟與數位政府系統建構，具體措施包含減免投資5G應用貸款稅率2%、籌集投資數位新政基金、完善智慧醫療應用等。此外在扶植新創政策上，則包含建立新興科技實驗場域（K-test bed），以政府採購扶植新興科技、提供商機以及協助銜接海外市場，修正創投法規開放附認股權憑證之低利貸款以引進矽谷創投資金，以及排除可轉換可贖回之債務認定以降低政府研發補助申請門檻等，以有效扶植創新能量成為未來的經濟成長動力。
關於軟體產品的智慧財產權保護建議近期軟體產品(特別是演算法)的智慧財產權保護受到各界廣泛注意，2022年12月美國實務界律師特別撰文對此提出相關智財權保護建議。軟體產品通常涉及演算法，指由人工智慧(AI)和分析組成，用於解決特定問題的一組規則。專利通常被企業預設為保護技術產品的最佳形式。 然而在2014年，美國最高法院在Alice Corp. v. CLS Bank International一案中可以發現將軟體申請專利保護可能存在風險，如：（一）軟體可能被認為是抽象概念(abstract ideas)，非專利適格標的，而無法受專利法保護；（二）通常不易主張專利權，或可能在訴訟過程中因舉證責任造成機密資訊揭露等風險。因此該文作者認為難以受專利法保護之演算法、用於基於機器學習或訓練模型的資訊和資料集等軟體資料，亦可考慮透過營業秘密來保護，並提出以下營業秘密管理的建議： 1.員工教育訓練：建議企業可在僱傭的各階段(僱傭時、每年、終止時)採行相關措施、訓練，以減少營業秘密的竊用，及防止未來員工抗辯不知道該資訊是營業秘密。 2.機密標示：建議企業透過此階段審視組織對於機密文件之界定，再透過機密標示配合存取權限設定，協助企業控管與防止機密外流。 3.執行：瞭解需要受管理的營業秘密是什麼以及其為何重要。 4.監控和衡量員工參與度：建議企業採取相關監測機制檢視員工活動，及早發現離職動向與管控營業秘密資訊。 5.避免資訊揭露：建議企業應確保在向消費者或客戶行銷的過程中不洩露營業秘密，或至少採取相關保護措施，如簽訂保密契約。 6.確保資料安全：建議企業可建置網路安全策略、設置密碼、存取限制、外部設備使用下載或儲存限制等管控措施。 綜上所述，對於從事軟體開發的企業，除以專利保護產出成果外，還可從技術本質、後續是否容易主張、是否適合公開等面向，評估搭配營業秘密保護成果。並在選擇以營業秘密保護成果時，採行相關的管理措施避免營業秘密外洩而造成企業損失，包括：劃定需管理的營業秘密、制定員工教育訓練與相關管制措施，如機密標示、權限控管，並可搭配預警機制以便能夠即早發現異常。 本文同步刊登於TIPS網站（https://www.tips.org.tw）
歐盟資通安全局公布《提升歐盟軟體安全性》研究報告歐盟資通安全局（European Union Agency for Cybersecurity, ENISA）於2020年4月25日以歐盟網路安全驗證框架（EU cybersecurity certification framework）檢視現行安全軟體開發及維護之方式與標準，並公布《提升歐盟軟體安全性》（Advancing Software Security in the EU）研究報告。歐盟資通安全局後續將以該研究報告協助產品、服務及軟體開發之驗證，並期望能夠成為執行歐盟網路安全驗證框架相關利害關係人之非強制性參考文件之一。 本報告指出由於安全軟體已普遍應用於日常商品與服務當中，但目前針對軟體安全事故並無相對應之安全守則及技術，故為提高軟體安全層級並緩解目前已知之軟體安全威脅，應針對安全軟體開發及維護進行規範並驗證。 報告中除了針對軟體安全提出其應具備之要素、概述現行安全軟體開發方式及標準之缺點外，亦提出若以歐盟網路安全驗證框架針對軟體開發方式進行驗證時可考量之一些實際做法，包括： 已驗證之資訊與通訊科技（Information and Communication Technology, ICT）產品、服務或流程供應商或製造商，針對資料庫之部署及維護，除探討防止資料洩漏之方式外，尚應考量產品、服務或流程驗證過程中，進行資料共享會面臨之安全威脅以及緩解之方式。 應與歐洲標準組織（European Standards Organizations, ESOs）及標準制定組織（Standards Developing Organization, SDOs）合作。 建立一些針對軟體開發、維護及操作準則以補充現有歐盟網路安全驗證方案（EU cybersecurity certification schemes）。 針對現行不一致之軟體開發及維護規範，應考量建立較寬鬆之合規性評估（conformity assessment）標準。 借鏡現有經驗和專業知識，促進歐盟網絡安全驗證框架之適用。