美國最高法院判決單離DNA片段不具專利標的適格性

  2013年6月13日美國最高法院(the Supreme Court of the United States)就備受矚目之Association for Molecular Pathology v. Myriad Genetics, Inc.一案做出判決,認定如乳癌易感基因BRCA1、BRCA2等經單離(isolated)的人類DNA片段不具美國專利法第101條(35 U.S.C. §101)所規定之專利標的適格性。

 

  美國最高法院指出,雖然專利權人發現了BRCA1與BRCA2基因的位置與序列,但是其並未創造或改變BRCA1與BRCA2基因上的任何遺傳資訊,亦並未創造或改變該DNA片段的基因結構,所以即使其是發現了一個重要而有用的基因,但僅是將其從周遭其他基因材料中分離出來,並非為一項發明行為。亦即是說,突破性、創新或卓越的發現並不必然符合美國專利法第101條之要件要求。

 

  不過,美國最高法院認為,cDNA片段可以具備專利標的適格性,因為其為從mRNA所創造出來、僅具備外顯子(exons-only)的分子,而非自然發生之自然產物。然而美國最高法院對於cDNA是否符合其他可專利要件之要求並不表示意見。

 

  美國最高法院亦強調,本案判決並未涉及任何方法發明,亦未就將有關BRCA1與BRCA2基因之知識予以應用的發明做出判斷,且未判斷自然發生之核苷酸順序經改變的DNA片段是否具備專利標的適格性的問題。

本文為「經濟部產業技術司科技專案成果」

相關連結
相關附件
※ 美國最高法院判決單離DNA片段不具專利標的適格性, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?d=6211&no=55&tp=1 (最後瀏覽日:2026/05/17)
引註此篇文章
你可能還會想看
聯邦通訊委員會禁止無線麥克風使用700MHz頻段

  美國聯邦通訊委員會(Federal Communication Commission, FCC)於今年1月15日頒佈一項新命令,禁止進一步經銷或出售使用700MHz頻段(698-806MHz)的無線麥克風等設備。700MHz頻段在2009年6月12日數位電視轉換完成後,已不再供電視台廣播使用。FCC表示此項命令的頒佈,目的在清空700MHz頻段,以避免上述設備對目前使用此一頻段的公共安全通訊(如警察、消防及緊急服務)與商用無線通訊服務,產生妨害性干擾。上述設備所使用之頻段,先前已由主要無線通訊業者以約200億美元標得執照。   FCC頒佈此項新命令,將影響百老匯劇院、運動聯盟及其他公眾娛樂團體目前利用700MHz頻段經營的無線麥克風系統。在新命令頒佈前,上述團體曾表示希望維持繼續使用部份700MHz頻段,並表示其使用將不會對新的使用者造成干擾,惟FCC並未採納其意見。   為確保目前使用700MHz頻段免執照設備的個人或團體,能有充分時間轉換至適當之替代頻段,FCC將允許其繼續使用至今年6月12日止。同時,對於先前已購買使用700MHz頻段設備之消費者,亦提出相關計畫以提供協助。

德國科隆行政法院判決Google公司所提供之Gmail電子郵件服務為德國電信法「電信服務」定義下之規範對象

  德國科隆行政法院於2015年11月11日判決美商Google公司所提供之Gmail電子郵件服務為德國電信法「電信服務」定義下之規範對象,依據德國電信法第3條24之規定。因此,以該服務之提供者Google公司得依據德國電信法第6條第1項履行其「通報義務」。繼德國聯邦網路局(Bundesnetzagentur)於2012年7月透過正式通知美商Google Inc.需履行德國電信法第6條第1項之「通報義務」。   Google公司指出Gmail不是電信服務,因為Google本身所提供之服務目的不是在於電子信號的傳送。   德國聯邦網路局則指出,因為Google公司的伺服器,以專業術語來說,依據OSI模型(開放式系統互聯通訊參考模型,Open System Interconnection Reference Model, ISO/IEC 7498-1)定義,係有信號傳送服務提供的事實。Google透過獨特的傳送技術傳送數據信號,且針對其所傳輸的有所管控能力。此外,亦應更宏觀的來以電信法立法的宗旨與角度去審視是否此服務應受規範。德國聯邦網路局並不企圖於規範網路世界的一切。但是,像是Gmail或其他OTT服務業者應需要如同傳統電信服務業者般的,重視並履行其資料保護(Datenschutz)、消費者保護(Kundenschutz)、資訊安全(Sicherheit)上的義務。   德國聯邦科隆行政法院判決支持德國聯邦網路局的見解,Google公司因其所提供之Gmail服務應履行德國電信法之通報義務。在定義上是否電信服務,並不是完全以技術面去做認知,更為重要的在於電信法的立法價值初衷。德國聯邦科隆法院已准許透過飛躍上訴(Sprungrevision)的方式將該案送於德國聯邦最高行政法院(Bundesverwaltungsgericht),此案將可能有最高行政法院的判決。若Gmail被認定為係屬「電信服務」,此判決將會針對全德國的OTT服務規範有所影響,需被德國聯邦網路局所監管。

Facebook v.s. Lamebook商標嘲諷性使用之爭

  Facebook是全球最大的社交網站,而Lamebook則是於2009年4月創辦,專門供網路使用者上傳搞笑文章、照片或發表瘋狂評論的小型網站。今年三月開始,Facebook對Lamebook發出許多警告信(cease and desist letter),要求Lamebook停止使用Lamebook字眼作為商標,否則將對其提出商標侵權的訴訟。今年七月時,Facebook的律師寫信給Lamebook主張其侵權,信中並聲稱Lamebook作為商標的使用,並非屬於受法律保護的嘲諷性商標使用(parody use),因為Lamebook的網站並未針對Facebook給予任何批評或評論。   然而Lamebook則認為其網站是專門供網友上傳他們在最愛的社交網站上所看到的搞笑照片或近況動態,屬於嘲諷性商標使用。為了先聲奪人,Lamebook搶在Facebook提出商標侵權訴訟前,於11月4日向德州Austin聯邦法院提出請求確認Lamebook詞語的使用並未侵害Facebook的商標權。   在歷經幾個月的溝通及發送警告信皆未果的情況下,Facebook的律師11月9日於加州San Jose聯邦法院,向Lamebook提起商標侵權訴訟,並對外說明Lamebook網頁呈現方式、Logo皆和Facebook非常相似,他們相信Lamebook網站有不正當企圖假借Facebook的名譽和名氣,吸引更多使用者使用Lamebook網站,Facebook將會持續保護自己的品牌和商標。   針對Facebook提出的商標侵權訴訟,Lamebook則回應其和Facebook所提供的服務並不相同,其並未提供社交服務予使用者。此外,Lamebook認為網站僅是提供一個機會予使用者對於全球最盛行的社交網站進行嘲諷、評論,Lamebook詞語的使用是屬於嘲諷性商標使用,屬於美國憲法第一修正案(First Amendment)所保障的言論自由權利,是一種受保護的言論表達形式,並未侵害或淡化Facebook的商標權。   值得一提的是,Lamebook並非屬於第一個被Facebook警告有商標侵權疑義的網站,在Lamebook訴訟案之前,已陸續有幾個網站受到Facebook指控商標侵權。而最近也出現許多聲浪開始撻伐Facebook不該以巨人之姿,將”face”和”book”兩個通用詞語予以壟斷,完全禁止他人使用這兩個詞語。   究竟Lamebook小型網站最終是否可以嘲諷性使用為由,於商標侵權大戰中,戰勝目前全球最熱門社交網站Facebook,容我們拭目以待。

美國國家安全局發布「軟體記憶體安全須知」

  美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。

TOP