運作技術成熟度(Technology Readiness Level)進行技術評估
資策會科技法律研究所
法律研究員 羅育如
104年10月22日
壹、前言
為提升我國科技競爭力,於1999年制定科學技術基本法(以下簡稱科技基本法),透過科技基本法的規定,使原本歸屬國有財產之研發成果,得以下放歸屬執行單位所有,使大學對研發成果能有更完善應用之權利。
科技基本法實施之後,各研究單位開始學習國外經驗,積極進行產學合作,將內部之研發成果技術移轉與外部產業。但是,科技基本法實行已15年的今日,各界逐漸發現,政府經費之投入與研發成果產出之經濟效益有相當大的差距。例如科技部102年專題研究計畫補助經費為215億新台幣,但僅創造3.5億新台幣之衍生成果技術移轉權利金[1]。政府經費投入與產出不符預期的議題,牽涉多元層面問題,但是從新設立政府計畫案之目標與KPI,可以發現政府新創設之補助計畫開始以協助技術商業化作為主要目的,例如萌芽計畫、產學計畫等。
技術商業化操作模式會依據技術成熟度不同而有所差異,技術成熟度高的項目,廠商承接後所需要投入的研發成果可能較低,直接協助廠商改善生產流程或是成為產品商品化的機率較高;反之,廠商則需要投入較多的技術研發費用,需要花費較多的人力與資源,技術才有機會商品化。
由此可知,在技術商業化計畫推廣時,技術項目的技術成熟度是一個重要的評估關鍵。本文針對技術成熟度的評估指標詳細說明,以提供執行技術商業化計畫時,評估技術項目之參考。以下會分別說明何謂技術成熟度以及技術成熟度如何運用,最後會有結論與建議。
貳、技術成熟度說明
技術成熟度或稱為技術準備度(Technology Readiness Level;簡稱TRL)是美國太空總署(NASA)使用多年的技術評估方法,後來為美國國防部所用,再廣為國際各政府機構、學研單位、企業機構使用。
TRL是一個系統化的量尺/衡量指標,可以讓不同型態的技術有一致性的衡量標準,描述技術從萌芽狀態到成功應用於某項產品的完整流程[2]。而TRL涵蓋的技術研發流程則包括四個部分:(1)概念發展:新技術或是新概念的基礎研究,涵蓋TRL1~3;(2)原型驗證:特定技術針對一項或是多項潛在應用的技術開發,涵蓋TRL4與5;(3)系統開發:在某一應用尚未成為一整套系統之前的技術開發以及技術驗證,然後進行系統開發,涵蓋TRL6;(4)系統上市並運作[3],涵蓋TRL7~9。以下分別說明TRL每個衡量尺度的定義[4]。
TRL 1 基礎科學研究成果轉譯為應用研究。
TRL 2 為某項特殊技術、某項材料的特性等,找出潛在創新應用;此階段仍然是猜測或推論,並無實驗證據支持。
TRL 3 在適當的應用情境或載具下,實驗分析以驗證該技術或材料相關物理、化學、生物等特性,並證明潛在創新應用的可行性(proof-of-concept)。
TRL 4 接續可行性研究之後,該技術元素應整合成具體元件,並以合適的驗證程序證明能達成原先設定的創新應用目標。
TRL 5 關鍵技術元件與其他支援元件整合為完整的系統/系系統/模組,在模擬或接近真實的場域驗證。需大幅提高技術元件驗證的可信度。
TRL 6 代表性的模型/雛形系統在真實的場域測試。展示可信度的主要階段。
TRL 7 實際系統的雛形品在真實的場域測試。驅使執行TRL7的目的已超越了技術研發,而是為了確認系統工程及研發管理的自信。
TRL 8 實際系統在真實的場域測試,結果符合設定之要求。代表所有技術皆已整合在此實際系統。
TRL 9 實際系統在真實場域達成目標。
參、技術成熟度應用
技術成熟度可以單純拿來衡量技術開發階段、可用來衡量技術開發風險、也可作為研發機構角色以及補助計畫定位的參考,以下說明。
一.技術成熟度用來衡量技術開發階段
這是技術成熟度最單純的應用方法,但因為每種技術領域都可其特殊的技術開發脈絡,所以可以根據NASA原有的技術成熟度,修改成貼近該技術領域需求的技術成熟度指標。目前有看過軟硬體TRL指標、綠能&能源TRL指標、ICT TRL指標、生醫(新藥、生物製劑、醫材)TRL指標等[5]。
二、技術成熟度用來管理技術研發風險
研究開發需投入大量的人力、物力,而研究成果的不確定性又很高,所以需要有良好的技術研發管理。技術成熟度對技術研發管理而言,是風險的概念,一般而言,TRL階段與技術風險是反向關係,也就是說TRL階段越高,技術風險越低[6]。
需要考慮的面向包括[7] ,(1)現在技術成熟度在哪一階段?以及我們投入研發後,希望達到的技術成熟度目標為何?(2)從現在的技術成熟度到專案需要的技術成熟度,要精進這項技術到底有多難?(3)這項特定技術如果開發成功,對於全面技術目標而言的重要性如何?
三、機構角色以及補助計畫定位
TRL指標可用來明確區分研發機構角色定位,例如工研院內部運用TRL指標做為技術判斷量化評估指標,並且工研院需將技術成熟度提升到TRL6或7,以克服技術面的問題,進行小型試量產,才能跨越死亡之谷讓業界接手商業化[8]。
TRL指標也可以用來區分補助計畫的標的範圍,例如美國國防部傾向投資TRL 4階段技術,美國國防部培養TRL4以及4以下的技術到TRL6階段,使得這些技術能更順利的進入技術市場,其原因在於TRL程度越低,成功商品化的不確定性以及風險就越高,而TRL4階段技術項目,是美國國防部可以承受的風險程度[9]。
肆、結論
TRL指標現在已被廣泛的運用在技術評估工作上,透過量化的指標,協助研發人員或是技術管理人員方便掌握每個技術開發案的現況,例如現在技術在TRL哪個階段,技術開發結束後,TRL預計會到達哪個階段。確定目標之後,就可以進一步評估這個計畫開發案的風險並評估組織需投入的資源。
TRL是一個簡易的技術評估指標,但如果要以此做出全面性的技術策略,似乎就還是有所不足,因此,可以再搭配其他技術評估變項,發展為全面性的技術風險管理評估指標,可能可以搭配技術開發困難度指標,用以評估TRL往上提升一級的困難度程度[10],也可以搭配技術需求價值指標[11],這項技術順利成功的話,對整個系統開發而言的價值高低,價值非常高的話,就值得花更多資源與人力去投資。
由此可知,應該可以積極運用TRL指標,用來評估政府技術補助計畫,協助大學技轉辦公室管理各研發團隊之技術開發進程,也可提供技術移轉潛在廠商清楚設定技術規格,減低技術供給方與技術需求方之間的認知差異,進而提升技術移轉成功率,也就可以拉近政府經費投入與研發成果產出的差距。
[1] 行政院國家科學委員會,行政院國家科學委員會102年年報,頁24、98(2013),http://www.most.gov.tw/yearbook/102/bookfile/ch/index.html#98/z,最後瀏覽日2015/07/21。
[2] John C. Mankins, NASA, Technology Readiness Levels: A White Paper (1995).
[3] id.
[4] US DEPARTMENT OF DEFENSE (DoD), Technology Readiness Assessment (TRA) Guidance (2011), http://www.acq.osd.mil/chieftechnologist/publications/docs/TRA2011.pdf (last visited July 22, 2015).
[5] Lewis Chen,<Technology Readiness Level>,工研院網站,http://www.sti.or.th/th/images/stories/files/(3)ITRI_TRL.pdf (最後瀏覽日:2015/07/22)。
[6] Ricardo Valerdi & Ron J. Kohl, An Approach to Technology Risk Management (2004), http://web.mit.edu/rvalerdi/www/TRL%20paper%20ESD%20Valerdi%20Kohl.pdf (last visited July 22, 2015).
[7] John C. Mankins, Technology Readiness and Risk Assessments: A New Approach, ACTA ASTRONAUTICA, 65, 1213, 1208-1215 (2009).
[8] 邱家瑜、蔡誠中、陳禹傑、高皓禎、洪翊恩,<工研院董事長蔡清彥 以新創事業連結全球市場 開創屬於年輕人的大時代>,台灣玉山科技協會,http://www.mjtaiwan.org.tw/pages/?Ipg=1007&showPg=1325 (最後瀏覽日:2015/07/22)。
[9] Ricardo Valerdi & Ron J. Kohl, Massachusetts Institute of Technology, An Approach to Technology Risk Management, http://web.mit.edu/rvalerdi/www/TRL%20paper%20ESD%20Valerdi%20Kohl.pdf (last visited July 21, 2015).
[10] 同註7。
[11] 同註7。
微軟與摩托羅拉移動(谷歌旗下公司)將展開第二次關於智慧型手機及其他技術的專利侵權訴訟之審判。 這場陪審訴訟將於周一在西雅圖舉辦,主要將解決“摩托羅拉是否違反以非合理的條款授權微軟在Xbox遊戲機中無線和視訊技術領域所使用的標準必要專利(standard essential patents)。 去年11月,兩科技公司進行第一次大對決,確認了微軟應支付給摩托羅拉使用其專利技術的費用。經過5個月的審議後,美國地方法院James Robart審判法官裁定給微軟優惠方案,其建議每年支付約略180萬美元的費用給摩托羅拉,雖超過微軟所估算的100萬美元,但仍遠低於摩托羅拉原提出的40億美元的要求。 微軟依據過去的文件資料表示,微軟過去已表示支付給摩托羅拉680萬美元的權利金,但摩托羅拉拒絕這筆權利金的費用。 面對即將到來的訴訟案,微軟將主張摩托羅拉原先所提出的需求屬不合理要求,已違背其費用主張的合理和不帶歧視性的條款(reasonable and non-discriminatory terms)協議。 合理和不帶歧視性的條款(reasonable and non-discriminatory terms),一般稱為“RAND“,其條款主要是為了防止擁有標準必要專利之公司,透過專利龔斷市場,使用不合理的競爭手法,造成其他競爭對手的傷害。
德國柏林高等法院(LG Berlin)判決「Facebook」違反聯邦資料保護法德國柏林高等法院(LG Berlin)於2018年1月16日在德國聯邦消費者中心協會(Verbraucherzentrale Bundesverband)對 Facebook提起之訴訟中,判決 (Az. 16 O 341/15)Facebook網站之預設功能(Voreinstellungen)和部分使用及資料保護條款(Nutzungs- und Datenschutzbedingungen),違反德國聯邦資料保護法(Bundesdatenschutzgesetz)之相關規定,因此,部分針對企業徵求用戶同意使用其資料之條款被判定無效。 Facebook在其隱私設定中心隱藏對用戶資料保護有利之默認設置,且在新用戶注冊帳戶時未充分告知,故未符合用戶同意條款之要求。依據聯邦資料保護法之規定,個人資料僅允許在相關人同意下徵集及使用。為讓用戶能在知情下自行判斷是否同意個資使用,網路供應商須清楚、詳盡告知資料使用之方式、範圍及目的。但Facebook並未遵守該項要求,Facebook在手機App上已自行啟用定位服務,一旦用戶使用聊天功能,將透露其所在位置。尤其在隱私設定中,已預設各種搜尋引擎可取得用戶個人版面之連結,任何人均可快速和簡易的透過此種方式,發現任一用戶在Facebook上的個人資訊。因用戶能否被事先告知無法確實保障,對此,法官判定5項Facebook備受聯邦消費者中心協會批評的預設功能無效。 此外,柏林高等法院亦宣告8項包括預擬同意之服務條款無效,依照這些條款之規定,Facebook可將用戶之姓名和個人資訊運用於商業、贊助商或相關事業之內容,且其條款並未明確說明,哪些資料會被傳送至美國,以及其後續處理過程與所採用之資料安全標準為何。法官認為,上述預擬條款之意思表示並非有效之資料使用同意授權。此外,用戶在Facebook僅可使用實名之義務亦屬違法,德國聯邦消費者中心協會對此表示,電信媒體法(Telemediengesetz; TMG)規定,網路供應商須儘可能讓網路用戶匿名或他名參與網路運作,然而柏林高等法院對此觀點仍持保留態度。 柏林高等法院於判決中強調,本案單就聯邦消費者中心協會對Facebook之用戶使用條款是否有效提起之訴進行判決,並非判斷支援此些條款運作的資料處理過程之合法性。儘管如此,法院之見解仍可能對資料處理過程合法性之判斷造成影響。該項判決目前仍未最終定讞,故本案兩造皆可上訴柏林最高法院(Kammergericht),尤其聯邦消費者中心協會認為,Facebook以免費使用為廣告宣傳用語,不無誤導消費者之可能,故將對此提起上訴。至於未來本案上訴至柏林最高法院後之發展,關係個人資料保護程度之擴張及網絡供應商可用範圍之限制,故仍須持續關注。
美國消費者金融保護局發布最終規則強化消費者金融資料控制權與隱私保護.Pindent{text-indent: 2em;} .Noindent{margin-left: 22px;} .NoPindent{text-indent: 2em; margin-left: 38px;} .No2indent{margin-left: 3em;} .No2Pindent{text-indent: 2em; margin-left: 3em} .No3indent{margin-left: 4em;} .No3Pindent{text-indent: 2em; margin-left: 4em} 美國消費者金融保護局發布最終規則強化消費者金融資料控制權與隱私保護 資訊工業策進會科技法律研究所 2024年12月10日 美國消費者金融保護局(Consumer Financial Protection Bureau, CFPB)於2024年10月22日發布最終規則以落實2010年《消費者金融保護法》(Consumer Financial Protection Act, CFPA)第1033條規定之個人金融資料權利[1],該規則即通常所稱之「開放銀行」(Open Banking)規則。 壹、事件摘要 本次CFPB頒布最終規則旨在賦予消費者對其個人金融資料更大的權利、隱私與安全性。透過開放消費者金融資料,消費者得更自由地更換金融服務提供者以尋求最佳交易,從而促進市場競爭,並激勵金融機構精進其產品與服務[2]。 貳、重點說明 最終規則要求資料提供者在消費者及授權第三方之請求下,提供消費者金融產品或服務相關資料,並應以消費者及授權第三方可使用之電子形式提供。最終規則亦制定標準,以促進資料標準化格式(standardized formats)之發展和使用,同時規範第三方近用消費者資料義務,包括對資料之蒐集、利用及保留限制。相關重點如下: 一、受規範機構主體 最終規則規範對象為資料提供者(data provider),包含銀行、信用合作社等存款機構(depository institution);發行信用卡、持有交易帳戶、發行用於近用帳戶設備或提供支付促進服務(payment facilitation service)等非存款機構[3]。值得注意者,最終規則將數位錢包(digital wallet)及支付應用程式(payment app)業者納入資料提供者範圍,亦即被廣泛使用的金融科技服務亦將受到開放銀行規範體系之約束。此外,資料提供者不得向消費者或第三方收取資料近用之費用。 二、受規範資料範圍 最終規則規範之資料範圍涵蓋:資料提供者控制或擁有之24個月內之歷史交易資訊、帳戶餘額、付款資訊、契約條款與條件、即將到期之帳單、以及基本帳戶驗證資訊(Basic account verification information)等[4],消費者得授權第三方近用此類資料。至於機密商業資訊、蒐集資料僅用於防止詐欺、洗錢,或為偵測或報告其他非法及潛在非法行為,又或基於其他法律要求保密之資訊,以及在正常業務過程中無法檢索之資料,則豁免最終規則之適用[5]。 三、消費者與開發者介面 根據最終規則,資料提供者須建立及維護兩個獨立的介面以利資料之近用,包含:消費者介面,例如提供消費者近用其資料之入口網站,以及授權第三方之開發者介面(developer interface),例如應用程式介面(Application Programming Interface, API),雖最終規則不要求使用任何特定技術,然仍要求資料提供者須以標準化機器可讀格式(Standardized and Machine-Readable Format)提供資料,介面功能要求須達每月最低99.5%之回應率(response rate)[6]。此類資訊須在每月最末日前揭露於資料提供者網站上。此外,介面之設計須遵守《美國金融服務業現代化法》(The Gramm-Leach-Bliley Act, GLBA)」及聯邦貿易委員會(Federal Trade Commission, FTC)之《消費者資訊保障標準》(Standards for Safeguarding Customer Information)等消費者資料保護法規義務[7]。 四、授權第三方之行為義務 授權第三方(authorized third party)為代表消費者向資料提供者請求近用資料,藉以提供消費者產品或服務者。為解決隱私與資料安全問題,該規則對尋求近用消費者資料之第三方提出數項要求[8],包含但不限於: (一)知情同意之取得 第三方須取得消費者明確知情同意(express informed consent),以便代表消費者近用資料。 (二)資料利用之限制 第三方須確保將其資料之蒐集、利用及保留限制在提供消費者所請求的產品或服務之合理必要範圍內。就此部分,精準廣告(targeted advertising)、交叉銷售(Cross-selling),以及銷售資料並非提供產品或服務之合理必要範圍。 (三)遵守聯邦法規 第三方須依GLBA第501條規定或FTC之《消費者資訊保障標準》確保在其系統中採用「資訊安全計畫」(information security program)。 (四)政策與程序文件要求 第三方應擁有合理書面政策和程序,以確保從資料提供者處準確接收資料,並提供於其他第三方,即資料正確性之確保。 (五)資料撤回權之確保 第三方應向消費者提供撤回第三方授權之方法,撤回過程須簡易明瞭。在第三方收到消費者撤回授權之請求時,應通知資料提供者以及已向其提供消費者資料之其他第三方。 (六)第三方監督義務 第三方應透過契約要求其他第三方在向其提供消費者資料前遵守特定第三方法定義務。 (七)資料保存期限 消費者資料之保存期限最長為一年。若繼續蒐集,第三方應取得消費者重新授權。若消費者不提供重新授權或撤回授權,第三方應停止資料之蒐集,並停止利用與保留先前蒐集之資料。 五、實施日期 最終規則將依機構資產規模分階段實施[9],最大規模之機構(資產總額為2500億美元以上之存款機構資料提供者,以及在2023年或2024年任一年中,總收入達到100億美元以上之非存款機構資料提供者)須在2026年4月1日前遵守最終規則。對於規模最小之機構(資產總額低於15億美元但高於8.5億美元之存款機構資料提供者)須於2030年4月1日前遵守該規則。另總資產低於8.5億美元之存款機構不受該規則限制,以減輕小型銀行及信用合作社合規負擔。 參、事件評析 CFPB之CFPA第1033條最終規則將重塑美國金融市場之監理格局,由市場驅動之開放銀行框架走向由政府透過法規實質監理之管制措施,要求業者開放消費者資料。值得留意者,歐盟執委會(European Commission)2023年6月推出之「金融資料近用」(Financial Data Access, FiDA)草案[10]亦基於消費者賦權理念,強化消費者對其資料權利之控制權。由此可觀察國際間金融資料利用與監理規範逐漸走向以消費者資料自主為中心之法制架構,當代金融資料監理趨勢或值得我國主管機關及業者留意關注,除可作為我國金融資料法制與政策制定之參考,亦供我國企業布局全球化金融服務提前作好準備。 [1]Required Rulemaking on Personal Financial Data Rights, 89 Fed. Reg. 90838. [2]Consumer Financial Protection Bureau, CFPB Finalizes Personal Financial Data Rights Rule to Boost Competition, Protect Privacy, and Give Families More Choice in Financial Services, available at https://www.consumerfinance.gov/about-us/newsroom/cfpb-finalizes-personal-financial-data-rights-rule-to-boost-competition-protect-privacy-and-give-families-more-choice-in-financial-services/(last visited Dec. 5, 2024). [3]12 C.F.R. § 1033.111. [4]12 C.F.R. § 1033.211. [5]12 C.F.R. § 1033.221. [6]12 C.F.R. § 1033.311. [7]See id. [8]12 C.F.R. § 1033.421. [9]12 C.F.R. § 1033.121. [10]Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on a framework for Financial Data Access and amending Regulations (EU) No 1093/2010, (EU) No 1094/2010, (EU) No 1095/2010 and (EU) 2022/2554.
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。