Trademark Appeal Case
本データベースは、特許庁の審決例をAIで解析・要約したものです。拒絶理由通知に対する意見書作成や、審判請求書等の作成時の参考としてお役立てください。
| 審判番号 | 2024700892 |
|---|---|
| 審判種別 | 記載はありません。 |
| 結論 | 敗訴（請求棄却） |
理 由
本件特許第7466814号(以下、「本件特許」という。)についての特許出願は、令和6年1月22日に出願され、令和6年4月4日にその特許権が設定登録され、令和6年4月12日にその特許公報が発行された。そして、特許異議申立人 五明公代(以下、単に「申立人」という。)による特許異議の申立て(以下、「本件異議申立て」という。)に係る手続の経緯は、以下のとおりである。
令和6年 9月17日 :特許異議申立書の提出
令和6年10月 1日付け:手続補正指令書(方式)
令和6年10月15日 :手続補正書の提出
令和6年11月28日付け:取消理由通知書
令和7年 1月29日 :訂正請求書、意見書の提出
令和7年 2月20日付け:手続補正指令書(方式)
令和7年 3月19日 :手続補正書の提出
令和7年 5月 8日付け:通知書
令和7年 6月 4日差出:意見書
特許異議申立書の全趣旨からして、申立人が主張する特許異議の申立ての理由(以下、「申立理由」という。)及び証拠は、以下のとおりのものと認められる。
本件特許の特許請求の範囲の請求項1ないし7、9ないし12及び15に係る発明は、甲第1号証に記載の発明及び甲第2号証ないし甲第7号証の記載事項に基いて、請求項8に係る発明は、甲第1号証に記載の発明及び甲第2号証ないし甲第8号証の記載事項に基いて、請求項13に係る発明は、甲第1号証に記載の発明並びに甲第2号証ないし甲第7号証及び甲第9号証ないし甲第11号証の記載事項に基いて、請求項14に係る発明は、甲第1号証に記載の発明並びに甲第2号証ないし甲第7号証及び甲第12号証の記載事項に基いて、本件特許出願前にその発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであり、請求項1ないし15に係る特許は、特許法第29条第2項の規定に違反してされたものであるから、特許法第113条第2号の規定により取り消すべきものである。
甲第1号証:米国特許出願公開第2022/0350931号明細書
甲第2号証:AWSの基本・仕組み・重要用語が全部わかる教科書
甲第3号証:AWS継続的セキュリティ実践ガイド
甲第4号証:要点整理から攻略する『AWS認定セキュリティ - 専門知識』
甲第5号証:CloudFormation StackSetsでスイッチロール用のIAM Roleを一括作成する
甲第6号証:AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第3版
甲第7号証:Deploy AWS Organizations resources by using CloudFormation
甲第8号証:エバンジェリストの知識と経験を1冊にまとめたAWS開発を≪成功≫させる技術
甲第9号証:特開2023-096365号公報
甲第10号証:特許第7279227号公報
甲第11号証:特開2021-119500号公報
甲第12号証:国際公開第2021/156966号パンフレット
なお、以下において、上記甲第1号証~甲第12号証を、単に「甲1」~「甲12」という場合がある。
令和6年11月28日付けで当審が通知した取消理由は、概略、以下のとおりである。
(明確性)本件特許の特許請求の範囲の請求項1ないし15に係る発明は、明確ではないから、請求項1ないし15に係る特許は、特許法第36条第6項第2号の規定に違反してされたものである。
(サポート要件)本件特許の特許請求の範囲の請求項1ないし15に係る発明は、発明の詳細な説明に記載したものではないから、請求項1ないし15に係る特許は、特許法第36条第6項第1号の規定に違反してされたものである。
令和7年1月29日に提出された訂正請求書による訂正(以下、「本件訂正」という。)の請求の趣旨は、本件特許の特許請求の範囲を、本件訂正請求書に添付した訂正特許請求の範囲のとおり、訂正後の請求項1ないし15について訂正することを求める、というものである。
本件訂正の内容は、次のとおりのものである。
(1)訂正事項1
特許請求の範囲の請求項1ないし14を削除する。
(2)訂正事項2-1
特許請求の範囲の請求項15に、処理の主体を「情報処理装置」とする「情報処理方法」が記載されているのを、「階層化されたリソースと対応付けられるシステム環境を有する対象システム及び情報処理装置を備える情報処理システムで用いる情報処理方法」に訂正する。
(3)訂正事項2-2
特許請求の範囲の請求項15に、「情報処理装置が、階層化されたリソースと対応付けられるシステム環境を有する対象システムにおいて、前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて所定階層のリソースに伝搬するロールに基づいて、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得するステップA」及び「前記情報処理装置が、前記所定階層のリソースへの前記ロールの付与によって、前記所定階層のリソースと対応付けられたシステム環境をスキャンする権限を取得するステップC」と記載されているのを、「前記対象システムが、前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて、前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与するステップ」、「前記対象システムが、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を前記情報処理装置に送信するステップ」、「前記情報処理装置が、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得するステップ」に訂正する。
(4)訂正事項2-3
特許請求の範囲の請求項15に、「前記情報処理装置が、前記ステップA によって取得された前記アセット情報に基づいて、前記所定階層のリソースと対応付けられたシステム環境の脆弱性情報を特定するステップB」と記載されているのを、「前記情報処理装置が、取得された前記アセット情報に基づいて、前記所定階層のリソースと対応付けられたシステム環境の脆弱性情報を特定するステップ」に訂正する。
本件訂正前の請求項2ないし14は、本件訂正前の請求項1を直接又は間接的に引用しているものであるから、訂正事項1によって記載が訂正される請求項1に連動して訂正されるものである。
したがって、本件訂正前の請求項1ないし14に対応する本件訂正後の請求項1ないし14は、特許法第120条の5第4項に規定する一群の請求項である。
(1)訂正の目的
訂正事項1は、請求項1ないし14を削除するというものであるから、特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」を目的とするものである。
(2)願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であること
訂正事項1は、請求項1ないし14を削除するというものであるから、願書に添付した明細書、特許請求の範囲又は図面(以下、これらをまとめて「本件明細書等」という。)に記載した事項の範囲内の訂正であり、特許法第120条の5第9項で準用する第126条第5項に適合するものである。
(3)実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと
訂正事項1は、請求項1ないし14を削除するというものであるから、実質上特許請求の範囲を拡張し、又は変更するものには該当せず、特許法第120条の5第9項で準用する第126条第6項に適合するものである。
(1)訂正の目的
訂正事項2-1は、以下の訂正事項2-2と連動して、訂正前の請求項15における「情報処理方法」において実行される処理の主体に「階層化されたリソースと対応付けられるシステム環境を有する対象システム」を直列的に付加するとともに、「情報処理装置」と「対象システム」とで「情報処理システム」を構成することを付加するものであるから、特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」及び特許法第120条の5第2項ただし書第3号に規定する「明瞭でない記載の釈明」を目的とするものである。
(2)願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であること
訂正後の請求項15における「階層化されたリソースと対応付けられるシステム環境を有する対象システム及び情報処理装置を備える情報処理システムで用いる情報処理方法」については、本件明細書の「
情報処理システム
100は、
情報処理装置
10と、端末20と、
システムサーバ
30と、脆弱性サーバ40と、を有する。」(【0016】)、及び「
システムサーバ
30は、ネットワーク200上に設けられる1以上のサーバ(クラウドサーバ)であり、クラウド上において
対象システム
を構築するサーバである。」(【0019】)、並びに「以下において、実施形態に係る
情報処理方法
について説明する。・・・(中略)・・・テンプレートが実行されると、テンプレートに記述されたロールは、第2
対象システム
を構成する階層化されたリソースに伝搬する。・・・(中略)・・・
情報処理装置
10は、スキャン用ユーザアカウントを用いて、ロールが付与されたリソースに対するスキャン要求を
システムサーバ
30に送信する。・・・(中略)・・・
情報処理装置
10は、スキャン要求に対する応答として、システム環境のアセット情報を特定可能なスキャン応答を
システムサーバ
30から受信する。・・・(中略)・・・
情報処理装置
10は、スキャン応答に基づいて、ロールが付与されたリソースに対応するシステム環境のアセット情報を取得する。・・・
情報処理装置
10は、アセット情報に基づいて脆弱性DBを参照して、ロールが付与されたリソースに対応するシステム環境の脆弱性情報を特定する。」(【0074】ないし【0084】)との記載の範囲のものである。
したがって、訂正事項2-1は、本件明細書等に記載した事項の範囲内の訂正であり、特許法第120条の5第9項で準用する第126条第5項に適合するものである。
(3)実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと
訂正事項2-1は、上記(1)及び(2)のとおり、「特許請求の範囲の減縮」及び「明瞭でない記載の釈明」を目的として、本件明細書等に記載した事項の範囲内で訂正するものであるから、実質上特許請求の範囲を拡張し、又は変更するものには該当せず、特許法第120条の5第9項で準用する第126条第6項に適合するものである。
(1)訂正の目的
訂正前の請求項15に記載の「階層化されたリソースと対応付けられるシステム環境を有する
対象システムにおいて
、前記階層化されたリソースの最上位のルートを操作する権限を有する
特定アカウントを用いて
所定階層のリソースに伝搬するロール」において、「特定アカウント」を用いて行う処理の主体が「情報処理装置」であるのか「対象システム」であるのかが明瞭でなかったものを「対象システム」が主体であることを明瞭にするとともに、「特定のアカウント」を用いて行う処理が「前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」ことであることを明瞭にしかつ限定し、さらに、「対象システム」が「アセット情報」を「情報処理装置」に送信することによって「情報処理装置」が当該「アセット情報」を「取得」することを明瞭にしかつ限定し、これらに伴って語順等を整えたものであるから、特許法第120条の5第2項ただし書第3号に規定する「明瞭でない記載の釈明」及び特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」を目的とするものである。
加えて、「ステップA」、「ステップC」から、特段意味があるとはいえない記号「A」及び「C」を削除する訂正は、特許法第120条の5第2項ただし書第2号に規定する「誤記の訂正」を目的としたものと認められる。
以上のことから、訂正事項2-2は、特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」、特許法第120条の5第2項ただし書第3号に規定する「明瞭でない記載の釈明」及び特許法第120条の5第2項ただし書第2号に規定する「誤記の訂正」を目的とするものである。
(2)願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であること
訂正後の請求項15における「前記対象システムが、前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて、前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」ことについて、本件明細書における「
対象システム
は、階層化された
リソース
と対応付けられるシステム環境を有するシステムである。」(【0020】)、「上位の階層の
リソース
(ここでは、
ルート
)
にロールが付与されると、同じロールが、配下にある下位の階層のリソース
(ここでは、ユニット及びメンバーアカウント)
に
継承されて
付与される。
」(【0051】)という記載を踏まえると、所定階層のリソースにロールを付与する主体は、リソース(ルート)を有する「対象システム」であると認められる。さらに、本件明細書には「送信部11(
情報処理装置10
)
がリソースをスキャンする権限を割り当てるロール
(すなわち、送信部11(情報処理装置10)からのスキャン要求を許可するロール)が付与されている場合に、」(【0027】)、「
ロールは、
階層化されたリソースの最上位の階層に位置するルートを操作する権限を有する特定アカウントを用いて、階層化されたリソースの
所定階層のリソースに伝搬する。
」(【0028】)、「
ロールの伝搬
は、
ロールの付与
と読み替えられてもよい。」(【0037】)、「テンプレートは、
リソースと対応付けられたシステム環境をスキャンする権限を情報処理装置10に割り当てるロール
に関する記述を含んでもよい。」(【0038】)と記載されている。以上を踏まえると、訂正後の請求項15における「前記対象システムが、前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて、前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」ことについては、本件明細書等に記載した事項の範囲のものである。
また、訂正後の請求項15における「前記対象システムが、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を前記情報処理装置に送信する」こと、及び、「前記情報処理装置が、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得する」ことは、本件明細書の【0019】の記載、並びに、「対象システムと対応付けられた各リソースは、送信部11(情報処理装置10)がリソースをスキャンする権限を割り当てるロール(すなわち、送信部11(情報処理装置10)からのスキャン要求を許可するロール)が付与されている場合に、リソースに対応付けられたシステム環境のアセット情報を特定可能なスキャン応答を情報処理装置10に送信する。」(【0027】)、「情報処理装置10は、スキャン要求に対する応答として、システム環境のアセット情報を特定可能なスキャン応答をシステムサーバ30から受信する。」(【0082】)、「情報処理装置10は、スキャン応答に基づいて、ロールが付与されたリソースに対応するシステム環境のアセット情報を取得する。」(【0083】)との記載の範囲のものである。
したがって、訂正事項2-2は、本件明細書等に記載した事項の範囲内の訂正であり、特許法第120条の5第9項で準用する第126条第5項に適合するものである。
(3)実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと
訂正事項2-2は、上記(1)及び(2)のとおり、「特許請求の範囲の減縮」、「明瞭でない記載の釈明」及び「誤記の訂正」を目的として、本件明細書等に記載した事項の範囲内で訂正するものであるから、実質上特許請求の範囲を拡張し、又は変更するものには該当せず、特許法第120条の5第9項で準用する第126条第6項に適合するものである。
(1)訂正の目的
訂正前の請求項15における「前記ステップAによって取得された」から特段意味がある構成とはいえない「前記ステップAによって」を削除し、「ステップB」から、特段意味があるとはいえない記号「B」を削除する訂正は、特許法第120条の5第2項ただし書第2号に規定する「誤記の訂正」を目的としたものと認められる。
(2)願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であること
訂正後の請求項15における「前記情報処理装置が、取得された前記アセット情報に基づいて、前記所定階層のリソースと対応付けられたシステム環境の脆弱性情報を特定するステップ」については、本件明細書の「情報処理装置10は、アセット情報に基づいて脆弱性DBを参照して、ロールが付与されたリソースに対応するシステム環境の脆弱性情報を特定する。」(【0084】)との記載の範囲のものである。
したがって、訂正事項2-3は、本件明細書等に記載した事項の範囲内の訂正であり、特許法第120条の5第9項で準用する第126条第5項に適合するものである。
(3)実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと
訂正事項2-3は、上記(1)及び(2)のとおり、「誤記の訂正」を目的として、本件明細書等に記載した事項の範囲内で訂正するものであるから、実質上特許請求の範囲を拡張し、又は変更するものには該当せず、特許法第120条の5第9項で準用する第126条第6項に適合するものである。
本件特許異議の申立ては、本件訂正前の請求項1ないし15についてなされているので、訂正事項1に係る請求項1ないし14、並びに、訂正事項2-1ないし2-3に係る請求項15には、訂正の適否の要件として、特許法120条の5第9項で読み替えて準用する同法126条第7項の独立特許要件は課されない。
申立人は、令和7年6月4日差出の意見書(以下、「意見書」という。)の3(1)ないし(4)において、要するに、請求項15に係る訂正は、「情報処理方法」において実行される処理の主体について、削除又は変更するものであるから、特許請求の範囲を拡張又は変更するものであると主張している。しかしながら、上記2(3)のとおりであるから、申立人の当該主張は採用できない。
また、申立人は、意見書の3(5)において、訂正前の「情報処理装置が、・・・前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて所定階層のリソースに伝搬するロールに基づいて、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得するステップA」との発明特定事項を、「前記対象システムが、前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて、前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与するステップ」との発明特定事項とする訂正は、「前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得する」との発明特定事項を削除し、かつ、「前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」との発明特定事項を追加する訂正であるから、特許請求の範囲を変更するものであると主張している。しかしながら、「前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得する」ことは、訂正後の請求項15において特定されており、また、「前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」ことは、上記3(1)のとおり、訂正前の請求項15において記載されていた「特定アカウント」を用いて行う処理の主体が「対象システム」であることを明瞭にするとともに、当該処理が「前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」ことであることを明瞭にしかつ限定したものにすぎない。したがって、申立人の当該主張は採用できない。
また、申立人は、意見書の3(6)において、要するに、訂正後の特許請求の範囲の記載「前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」からは、ロールが付与されるとスキャンする権限が与えられるという前後関係が読み取れないため、結果、ロールが付与されていないリソースに対しても、情報処理装置が権限を付与され得ることとなっており、このような態様は、発明の詳細な説明に記載されていないと主張している。しかしながら、「前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」との記載は、「ロール」を付与することによる作用として「前記システム環境をスキャンする権限を前記情報処理装置に割り当てる」ものであると解するのが合理的であり、ロールが付与されるとスキャンする権限が割り当てられるという前後関係を読み取ることができる。さらに、本件明細書の【0027】を参酌すれば、「情報処理装置」に割り当てられる「スキャンする権限」は、
ロールが付与された「所定階層のリソース」に対応付けられた「システム環境」
をスキャンする権限であるから、訂正後の請求項15に係る発明は、申立人が主張するような「ロールが付与されていないリソースに対しても、情報処理装置が権限を付与され得る」ものではない。したがって、申立人の当該主張は採用できない。
また、申立人は、意見書の3(7)において、訂正前の「情報処理装置が、・・・伝搬するロールに基づいて、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得するステップA」との発明特定事項を、訂正後の「前記情報処理装置が、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得するステップ」との発明特定事項とする訂正は、訂正後においてロールに基づかない取得も含むこととなっているから、特許請求の範囲を拡張するものであると主張している。しかしながら、訂正後の請求項15には「前記対象システムが、・・・
前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロール
を所定階層のリソースに付与するステップ」と記載されているところ、訂正後の「前記情報処理装置が、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得するステップ」との発明特定事項は、ロールに基づくものであると解するのが合理的である。したがって、申立人の当該主張は採用できない。
また、申立人は、意見書の3(8)において、訂正前の「前記情報処理装置が、前記所定階層のリソースへの前記ロールの付与によって、前記所定階層のリソースと対応付けられたシステム環境をスキャンする権限を取得するステップC」が、訂正後において削除されているから、特許請求の範囲を拡張するものであると主張している。しかしながら、訂正後の請求項15には「
前記システム環境をスキャンする権限を前記情報処理装置に割り当てる
ロールを所定階層のリソースに付与する」と記載されており、上記3(3)のとおりであるから、特許請求の範囲を実質的に拡張、又は変更するものではない。したがって、申立人の当該主張は採用できない。
以上のとおりであるから、本件訂正は、特許法第120条の5第2項ただし書第1号及び第3号に掲げる事項を目的とするものであり、かつ、同条第9項において準用する同法第126条第5項及び第6項に適合するものである。
したがって、本件特許の特許請求の範囲を、訂正請求書に添付した訂正特許請求の範囲のとおり、訂正後の請求項〔1~14〕、15について訂正することを認める。
上記第5のとおり、本件訂正は認められるので、特許請求の範囲の請求項 1ないし15に係る発明(以下、「本件特許発明1」ないし「本件特許発明15」という。)は、次の事項により特定されるものである。
(削除)
階層化されたリソースと対応付けられるシステム環境を有する対象システム及び情報処理装置を備える情報処理システムで用いる情報処理方法であって、
前記対象システムが、前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて、前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与するステップと、
前記対象システムが、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を前記情報処理装置に送信するステップと、
前記情報処理装置が、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得するステップと、
前記情報処理装置が、取得された前記アセット情報に基づいて、前記所定階層のリソースと対応付けられたシステム環境の脆弱性情報を特定するステップ
と、を備え、
前記所定階層のリソースは、前記階層化されたリソースのうち、前記ルートよりも下位階層のリソースである、情報処理方法。
上記第6のとおり、本件訂正によって請求項1ないし14が削除されたことにより申立ての対象が存在しなくなったため、特許法第120条の8第1項で準用する同法第135条の規定により、本件特許の請求項1ないし14に係る特許についての特許異議の申立てを却下する。
(1)理由1(明確性)について
上記第6のとおり、本件特許発明1ないし14は削除された。また、本件訂正により、本件特許発明15は、「前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロール」を付与する処理、及び、「システム環境のアセット情報」を送信する処理について、その主体が「対象システム」であること、及び、その処理の内容が明確となった。
(2)理由2(サポート要件)について
上記第6のとおり、本件特許発明1ないし14は削除された。また、本件訂正により、本件特許発明15は、本件特許の課題解決手段が反映されたものであるといえ、発明の詳細な説明に記載したものとなった。
以上のとおりであるから、取消理由はいずれも解消した。
(1)甲号証の記載事項
ア.甲第1号証
(ア)甲第1号証の記載事項
甲1には、次の事項が記載されている。(下線は当審で付与した。以下同様である。)
「[0002] Disclosed embodiments include new systems and methods for securing cloud infrastructure to help meet compliance mandates, without disrupting business operations in live environments.」
(当審訳)
「[0002] 開示される実施形態は、ライブ環境におけるビジネスオペレーションを中断することなく、コンプライアンス要求を満たすのを助けるためにクラウドインフラストラクチャをセキュア化するための新しいシステムおよび方法を含む。」
「[0003] Modern organizations typically depend on cloud infrastructure for data storage and processing. Data storage and processing nodes, among other things, power today's electronic infrastructure. In contrast to early network-centric days, an organization may have little in the way of “on-prem” (on-premises) systems and may run its entire business through systems having shared resources. Such an infrastructure may be the entire inventory of cloud assets for an organization, including running and stopped workloads of all types: virtual machines, containers, storage objects, load balancers, IAM (Identity and Access Management) configurations, and more. Organizations are searching for effective ways to scan their entire cloud estate to look for risks stemming from vulnerabilities, misconfigurations, malware, lateral movement risk, weak and leaked passwords, and improperly secured PII.」
(当審訳)
「[0003] 現代の組織は、典型的には、データ記憶および処理のためのクラウドインフラストラクチャに依存する。データ記憶および処理ノードは、とりわけ、今日の電子インフラストラクチャに動力を供給する。初期のネットワーク中心の時代とは対照的に、組織は、「on-prem」(オンプレミス)システムをほとんど持たずに、共有リソースを有するシステムを介してそのビジネス全体を実行する場合がある。そのようなインフラストラクチャは、仮想マシン、コンテナ、ストレージオブジェクト、ロードバランサ、IAM(Identity and Access Management)構成などのすべてのタイプの実行中および停止中のワークロードを含む、組織のクラウドアセットのインベントリ全体であってもよい。組織は、脆弱性、誤構成、マルウェア、ラテラルムーブメントリスク、弱いパスワードおよび漏洩したパスワード、ならびに不適切にセキュア化されたPIIから生じるリスクを探すために、クラウドアセット全体をスキャンする効果的な方法を探索している。」
「[0011] Therefore, there is a need for improved security scanning systems that solve the problem with existing systems and are more adapted for use in cloud infrastructures.」
(当審訳)
「[0011] したがって、既存のシステムの問題を解決し、クラウドインフラストラクチャでの使用により適合された、改善されたセキュリティスキャンシステムが必要とされている。」
「[0048]
Cloud infrastructure 106 includes scanning system 101, databases 103A-103D, virtual machines 107A-107D, databases 109A-109D, storage 111A-111D, keystores 113A-113D, and load balancer 115.
While particular numbers and arrangements of devices, systems, and connections, are depicted in exemplary FIG. 1, in some embodiments, each of the devices, systems, or connections may be omitted, duplicated, or modified. For example, in some embodiments, databases 109A-109D may exist as only a single database; in other embodiments, cloud infrastructure 106 may exist as one or more distinct or combined infrastructures (e.g., operated by the same or different cloud services). In some embodiments, scanning system 101 and/or databases 103A-103D may be part of cloud infrastructure 106 (and may be connected to the various other systems and devices in cloud infrastructure 106); in other embodiments,
scanning system 101 and/or databases 103A-103D may be separate from cloud infrastructure 106 (e.g., connected to the systems and devices in cloud infrastructure 106 through network 105).
」
(当審訳)
「[0048]
クラウドインフラストラクチャ106は、スキャンシステム101、データベース103A~103D、仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115を含む。
デバイス、システム、および接続の特定の数および配置が例示的な図1に示されているが、いくつかの実施形態では、デバイス、システム、または接続の各々は、省略、重複、または修正され得る。例えば、いくつかの実施形態では、データベース109A~109Dは、単一のデータベースとしてのみ存在してもよく、他の実施形態では、クラウドインフラストラクチャ106は、1つ以上の別個のまたは組み合わされたインフラストラクチャ(例えば、同じまたは異なるクラウドサービスによって動作される)として存在してもよい。いくつかの実施形態では、スキャンシステム101および/またはデータベース103A~103Dは、クラウドインフラストラクチャ106の一部であってもよい(また、クラウドインフラストラクチャ106内の様々な他のシステムおよびデバイスに接続されてもよい)。他の実施形態では、
スキャンシステム101および/またはデータベース103 A~103 Dは、クラウドインフラストラクチャ106とは別個であってもよい(例えば、ネットワーク105を介してクラウドインフラストラクチャ106内のシステムおよびデバイスに接続されてもよい)。
」
「[0049] Scanning system 101, in some embodiments, may include one or more computer systems. Each of the one or more computer systems may include memory storing instructions and at least one CPU configured to execute those instructions to perform operations as discussed herein. In some embodiments, the instructions cause the CPU to perform scanning operations. In some embodiments,
scanning system 101 may perform a scanning operation on one or more workloads (e.g., systems, devices, resources, etc.) in cloud infrastructure 106.
」
(当審訳)
「[0049] スキャンシステム101は、いくつかの実施形態では、1つ以上のコンピュータシステムを含んでもよい。1つまたは複数のコンピュータシステムの各々は、命令を記憶するメモリと、本明細書で説明する動作を実行するためにそれらの命令を実行するように構成された少なくとも1つのCPUとを含み得る。いくつかの実施形態では、命令は、CPUにスキャン動作を実行させる。いくつかの実施形態では、スキャンシステム101は、クラウドインフラストラクチャ106内の1つまたは複数のワークロード(例えば、システム、デバイス、リソースなど)に対してスキャン動作を実行することができる。」
「[0053] Cloud infrastructure 106 may be implemented as a set of devices and systems offered by a single cloud service provider.
For example, cloud infrastructure 106 may comprise devices and systems that are part of Amazon Web Services, Microsoft Azure, Google Cloud Platform, IBM Cloud, Alibaba Cloud, or any other cloud platform provider.
In some embodiments, one or more of the devices and systems in cloud infrastructure may require authentication or other identity validation for access. For example, to access virtual machine 107A, a user may be required to enter a password or provide a key. Systems (e.g., scanning system 101 or user device 102) may administer or interact with cloud infrastructure 106 using a cloud service provider's system (not pictured).」
(当審訳)
「[0053] クラウドインフラストラクチャ106は、単一のクラウドサービスプロバイダによって提供されるデバイスおよびシステムのセットとして実装され得る。
例えば、クラウドインフラストラクチャ106は、Amazon Web Services、Microsoft Azure、Google Cloud Platform、IBM Cloud、Alibaba Cloud、または任意の他のクラウドプラットフォームプロバイダの一部であるデバイスおよびシステムを含み得る。
いくつかの実施形態では、クラウドインフラストラクチャ内のデバイスおよびシステムのうちの1つまたは複数は、アクセスのために認証または他のアイデンティティ検証を必要とする場合がある。例えば、仮想マシン107Aにアクセスするために、ユーザは、パスワードを入力するか、またはキーを提供することを要求され得る。システム(例えば、スキャンシステム101またはユーザデバイス102)は、クラウドサービスプロバイダのシステム(図示せず)を使用して、クラウドインフラストラクチャ106を管理するか、またはそれと相互作用してもよい。」
「FIG.2A
59
43
0001429995000001.jpg
」
(当審訳は省略)
「[0062] Process 200 begins with step 201. In step 201, scanning system 101 may execute a process of integration. The integration process may be performed by scanning system 101 with cloud infrastructure 106. In some embodiments, the integration process includes creating a connection between an account on scanning system 101 and
an account on cloud infrastructure 106
. The process of integration in step 201 may, in some embodiments, be implemented as described below with respect to FIG. 2B.」
(当審訳)
「[0062] プロセス200はステップ201から開始する。ステップ201において、スキャンシステム101は統合のプロセスを実行することができる。統合プロセスは、クラウドインフラストラクチャ106を有するスキャンシステム101によって実行され得る。いくつかの実施形態では、統合プロセスは、スキャンシステム101上のアカウントと
クラウドインフラストラクチャ106上のアカウント
との間の接続を作成することを含む。ステップ201における統合のプロセスは、いくつかの実施形態では、図2Bに関して以下で説明するように実装され得る。」
「[0066] In some embodiments, analyzing/reporting in step 207 may include scanning system 101 combining conclusions from different environmental perspectives (e.g., metadata) into a single model. For example, scanning system 101 may map the running services on cloud infrastructure 106 and consider collected vulnerability data. Scanning system 101, in some embodiments, may generate a visualization of the map for review, listing where the vulnerabilities are on a two-dimensional graphical representation of cloud infrastructure 106.」
(当審訳)
「[0066] いくつかの実施形態では、ステップ207における分析/報告は、スキャンシステム101が異なる環境的観点(例えば、メタデータ)からの結論を単一のモデルに組み合わせることを含み得る。例えば、スキャンシステム101は、実行中のサービスをクラウドインフラストラクチャ106上にマッピングし、収集された脆弱性データを考慮することができる。いくつかの実施形態では、スキャンシステム101は、クラウドインフラストラクチャ106の2次元グラフィカル表現上のどこに脆弱性があるかを列挙するレビューのためにマップの視覚化を生成することができる。」
「[0074] Process 210 may begin with step 211 to initiate a connection to cloud infrastructure 106. In step 211, scanning system 101 may send a message to user device 102 instructing a user to authenticate, or log in, to a cloud service provider's system operating cloud infrastructure 106. For example, the user may use a username, password, one-time password, two-factor authentication, or any other authentication mechanism to gain access to a cloud service provider's system.」
(当審訳)
「[0074] プロセス210は、ステップ211から開始して、クラウドインフラストラクチャ106への接続を開始することができる。ステップ211において、スキャンシステム101は、クラウドインフラストラクチャ106を動作させるクラウドサービスプロバイダのシステムに認証またはログインするようにユーザに指示するメッセージをユーザデバイス102に送信し得る。例えば、ユーザは、ユーザ名、パスワード、ワンタイムパスワード、2要素認証、または任意の他の認証機構を使用して、クラウドサービスプロバイダのシステムへのアクセスを得ることができる。」
「[0075] Concurrently with or after the first message, scanning system 101 may send a second message to user device 102, instructing the user to generate a role. The second message may include instructions for the user to follow to generate the role. In step 213,
a user may provide (e.g., via a keyboard at user device 102) a role definition to the cloud service provider's system.
」
(当審訳)
「[0075] 第1のメッセージと同時にまたはその後に、スキャンシステム101は、ロールを生成するようにユーザに命令する第2のメッセージをユーザデバイス102に送信することができる。第2のメッセージは、ロールを生成するためにユーザが従うための命令を含み得る。ステップ213において、
ユーザは、ロール定義をクラウドサービスプロバイダのシステムに(例えば、ユーザデバイス102のキーボードを介して)提供してもよい。
」
「[0076] In some embodiments,
the role definition includes read-only permissions and permissions to read a block storage layer (containing block storage volumes).
In some embodiments,
scanning system 101 provides a role formation template (e.g., an Amazon Web Services CloudFormation Template) for use with cloud infrastructure 106 to create the necessary role.
In step 213, the user may utilize user device 102, for example, by copying and pasting a URL of the template, downloading and uploading the template to the cloud service provider's system, or selecting the template from a list of templates.」
(当審訳)
「[0076] いくつかの実施形態では、
ロール定義は、読み取り専用許可と、ブロック記憶層(ブロック記憶ボリュームを含む)を読み取る許可とを含む。
いくつかの実施形態では、
スキャンシステム101は、必要なロールを生成するためにクラウドインフラストラクチャ106が使用するロール形成テンプレート(例えば、Amazon Web Services CloudFormation Template)を提供する。
ステップ213において、ユーザは、例えば、テンプレートのURLをコピーしてペースト、テンプレートをクラウドサービスプロバイダのシステムにダウンロードおよびアップロードし、またはテンプレートのリストからテンプレートを選択することによって、ユーザデバイス102を利用することができる。」
「[0077] In step 215,
the cloud service provider's system may generate a string (e.g., a “key” or “resource name”) for use by scanning system 101.
In some embodiments,
this string may be used to enable access by scanning system 101 to the workload of cloud infrastructure as permitted by the generated role.
A user using user device 102 may copy the string and paste it into a user interface presented by scanning system 101 on user device 102. Other aspects of transmitting this string to scanning system 101 are possible as well.」
(当審訳)
「[0077] ステップ215において、
クラウドサービスプロバイダのシステムは、スキャンシステム101による使用のための文字列(例えば、「キー」または「リソース名」)を生成し得る。
いくつかの実施形態では、
この文字列は、生成されたロールによって許可されるようなクラウドインフラストラクチャのワークロードへのスキャンシステム101によるアクセスを可能にするために使用され得る。
ユーザデバイス102を使用するユーザは、文字列をコピーし、それをユーザデバイス102上のスキャンシステム101によって提示されるユーザインターフェースにペーストすることができる。この文字列をスキャンシステム101に送信する他の態様も可能である。」
「[0081] In step 223,
scanning system 101 may generate a “snapshot” of devices and systems in cloud infrastructure 106.
In some embodiments,
generating a snapshot may include reading devices and systems in cloud infrastructure, such as storage 111A-111D, databases 109A-109D, and virtual machines 107A-107D, and copying the information read from those devices and systems to storage at scanning system 101.
Generating a snapshot, in some embodiments, may include recording a reference count to data blocks in one or more of storage 111A-111D, databases 109A-109D, and virtual machines 107A-107D, and copying each block them like a copy and write operation. In some embodiments, scanning system 101 may generate an Elastic Block Storage snapshot in step 223.」
(当審訳)
「[0081] ステップ223において、
スキャンシステム101は、クラウドインフラストラクチャ106内のデバイスおよびシステムの「スナップショット」を生成することができる。
いくつかの実施形態では、
スナップショットを生成することは、ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステムを読み取ることと、これらのデバイス及びシステムから読み取られた情報をスキャンシステム101のストレージにコピーすることとを含み得る。
スナップショットを生成することは、いくつかの実施形態では、ストレージ111A~111D、データベース109A~109D、および仮想マシン107A~107Dのうちの1つまたは複数にデータブロックに対する参照カウントを記録することと、コピーおよび書込み動作のようにそれらの各ブロックをコピーすることとを含み得る。いくつかの実施形態では、スキャンシステム101は、ステップ223においてエラスティックブロックストレージスナップショットを生成することができる。」
「[0083] In step 225, scanning system 101 may apply “tags” to the snapshot. This process may include, in some embodiments, adding information to the snapshot to identify the snapshot as being associated with scanning system 101. Scanning system 101, in some embodiments, may be configured to delete only snapshots with the associated tags.」
(当審訳)
「[0083] ステップ225において、スキャンシステム101は、スナップショットに「タグ」を適用することができる。このプロセスは、いくつかの実施形態では、スナップショットに情報を追加して、スナップショットをスキャンシステム101に関連付けられているものとして識別することを含むことができる。スキャンシステム101は、いくつかの実施形態では、関連付けられたタグを伴うスナップショットのみを削除するように構成されてもよい。」
「[0084] In step 227, scanning system 101 may generate a map of cloud infrastructure 106. In some embodiments, this map may be in a form of graph: a plurality of interconnected vectors connecting the plurality of systems and devices, based on the networking configuration. Scanning system 101, or other devices, may traverse the map to identify vectors originating in the Internet and reaching the devices and systems in cloud infrastructure 106. In some embodiments, generating the map may include enumerating Internet-accessible services that are capable of serving as an Internet proxy. In some embodiments, a user may control scanning system 101 (e.g., via user device 102) to display the map on a graphical user interface.」
(当審訳)
「[0084] ステップ227において、スキャンシステム101は、クラウドインフラストラクチャ106のマップを生成してもよい。いくつかの実施形態では、このマップは、ネットワーキング構成に基づいて、複数のシステムおよびデバイスを接続する複数の相互接続されたベクトルであるグラフの形態であり得る。スキャンシステム101または他のデバイスは、マップを横断して、インターネットを起点とし、クラウドインフラストラクチャ106内のデバイスおよびシステムに到達するベクトルを識別することができる。いくつかの実施形態では、マップを生成することは、インターネットプロキシとして働くことが可能なインターネットアクセス可能サービスを列挙することを含み得る。いくつかの実施形態では、ユーザは、グラフィカルユーザインターフェース上にマップを表示するように、(例えば、ユーザデバイス102を介して)スキャンシステム101を制御してもよい。」
「[0085] In some embodiments, generating the map may include enumerating properties of all assets, including: virtual machines 107A-107D, databases 109A-109D, storage 111A-111D, keystores 113A-113D, load balancer 115, log files or databases, API gateway resources, API gateway REST APIs, Autoscaling groups, CloudTrail logs, CloudFront services, volumes, snapshots, VPCs, subnets, route tables, network ACLs, VPC endpoints, NAT gateways, ELB and ALB, ECR repositories, ECS clusters, services, and tasks, EKS, S3 bucket and Glacier storage, SNS topics, IAM roles, policies, groups, users, KMS keys, and Lambda functions. In some embodiments, generating the map in step 227 may further include analyzing devices or systems for a subset of risk related situations, including determinations of compromise situations (e.g., where an attacker has already gained access), imminent compromise situations (e.g., a known attack vector exists and can be used, such as a data store that is exposed to the public Internet without authentication), hazardous situations (e.g., a serious security implication, but no full attack vector exists), or informational situations (e.g., when storage 111A-111D has a limited amount of free space, or an unexploitable vulnerability exists).」
(当審訳)
「[0085] いくつかの実施形態では、マップを生成することは、仮想マシン107A~107D、データベース109A~109D、ストレージ111A~111D、キーストア113A~113D、ロードバランサ115、ログファイルまたはデータベース、APIゲートウェイリソース、APIゲートウェイREST API、オートスケーリンググループ、CloudTrailログ、CloudFrontサービス、ボリューム、スナップショット、VPC、サブネット、ルートテーブル、ネットワークACL、VPCエンドポイント、NATゲートウェイ、ELBおよびALB、ECRリポジトリ、ECSクラスタ、サービス、およびタスク、EKS、S3バケットおよびGlacierストレージ、SNSトピック、IAMロール、ポリシー、グループ、ユーザ、KMSキー、ならびにラムダ関数を含む、すべてのアセットのプロパティを列挙することを含み得る。いくつかの実施形態では、ステップ227においてマップを生成することは、危険に関連する状況のサブセットについてデバイスまたはシステムを分析することをさらに含むことができ、危険に関連する状況のサブセットは、危険な状況(たとえば、攻撃者がすでにアクセスを得ている場合)、差し迫った危険な状況(たとえば、認証なしに公衆インターネットに公開されるデータストアなど、既知の攻撃ベクトルが存在し、使用され得る)、危険な状況(たとえば、深刻なセキュリティ含意であるが、完全な攻撃ベクトルは存在しない)、または情報状況(たとえば、ストレージ111A~111Dが限られた量の自由空間を有するとき、または利用不可能な脆弱性が存在するとき)の決定を含む。」
「[0086] Generating the map in step 227 may include recording information such a region identifier, site identifier, datacenter identifier, physical address, network address, workload name, or any other identifier which may be acquired via an API provided through a cloud service provider's system.」
(当審訳)
「[0086] ステップ227においてマップを生成することは、クラウドサービスプロバイダのシステムを通じて提供されるAPIを介して取得され得る、領域識別子、サイト識別子、データセンタ識別子、物理アドレス、ネットワークアドレス、ワークロード名、または任意の他の識別子などの情報を記録することを含み得る。」
「[0090] Process 230 begins with step 231.
In step 231, scanning system 101 may perform a step of vulnerability scanning.
In some embodiments, step 231 comprises extracting everything in the snapshot, including operating system packages, installed software applications, libraries, and program language libraries such as Java archives, Python packages, Go modules, Ruby gems, PHP packages, and Node.js modules, or other software applications.」
(当審訳)
「[0090] プロセス230はステップ231から開始する。
ステップ231において、スキャンシステム101は、脆弱性スキャンのステップを実行することができる。
いくつかの実施形態では、ステップ231は、オペレーティングシステムパッケージ、インストールされたソフトウェアアプリケーション、ライブラリ、ならびにJava(登録商標)アーカイブ、Pythonパッケージ、Goモジュール、Ruby gem、PHPパッケージ、およびNode.jsモジュールなどのプログラム言語ライブラリ、または他のソフトウェアアプリケーションを含む、スナップショット内のすべてを抽出することを含む。」
「[0091] In some embodiments,
step 231 may determine library versions, software versions, and other identifying characteristics of software and operating systems in the snapshot.
Scanning system 101 may then try to match them to known vulnerabilities stored in a vulnerability database (e.g., one of databases 103A-103D).
The vulnerability database, in some embodiments, may include vulnerability data from: NVD, WPVulnDB, US-CERT, Node.js Security Working Group, OVAL―Red Hat, Oracle Linux, Debian, Ubuntu, SUSE, Ruby Advisory Database, JVN, Safety DB(Python), Alpine secdb, PHP Security Advisories Database, Amazon ALAS, RustSec Advisory Database, Red Hat Security Advisories, Microsoft MSRC, KB, Debian Security Bug Tracker, Kubernetes security announcements, Exploit Database, Drupal security advisories, JPCERT. The vulnerability database may also include other vulnerability data (including, e.g., manually-added vulnerability data or vulnerability sources not listed above).」
(当審訳)
「[0091] いくつかの実施形態では、
ステップ231は、スナップショット内のソフトウェアおよびオペレーティングシステムのライブラリバージョン、ソフトウェアバージョン、および他の識別特性を決定することができる。
次いで、
スキャンシステム101は、それらを脆弱性データベース(例えば、データベース103A~103Dのうちの1つ)に記憶された既知の脆弱性と照合することを試みてもよい。
脆弱性データベースは、いくつかの実施形態では、NVD、WPVulnDB、US-CERT、Node.js Security Working Group、OVAL Red Hat、Oracle Linux、Debian、Ubuntu、SUSE、Ruby Advisory Database、JVN、Safety DB(Python)、Alpine secdb、PHP Security Advisors Database、Amazon ALAS、RustSec Advisory Database、Red Hat Security Advisors、Microsoft MSRC、KB、Debian Security Bug Tracker、Kubernetes security announcement、Exploit Database、Drupal Security Advisors、JPCERTからの脆弱性データを含み得る。脆弱性データベースはまた、他の脆弱性データ(例えば、上に列挙されていない手動で追加された脆弱性データまたは脆弱性ソースを含む)を含み得る。」
「[0093] In some embodiments, scanning system 101 may perform a benchmarking process to detect misconfigurations of any services based on the information gathered in step 233. For example, scanning system 101 may determine the software version of each service and examine it against known vulnerabilities (e.g., stored in database 103A).」
(当審訳)
「[0093] いくつかの実施形態において、スキャンシステム101は、ステップ233において収集された情報に基づいて、任意のサービスの誤構成を検出するために、ベンチマーキングプロセスを実行し得る。例えば、スキャンシステム101は、各サービスのソフトウェアバージョンを決定し、(例えば、データベース103Aに記憶された)既知の脆弱性に対してそれを検査してもよい。」
「[0104] Scanning system 101 may read network information from the snapshot in order to determine which services within which containers are exposed externally and within which ports they are accessible. For example, scanning system 101 may identify a port on which a vulnerable application is accessible based on known software vulnerabilities for a versions of software application. Scanning system 101 may query network accessibility information via an API provided through a cloud service provider's system and may use it to identify specific vulnerabilities susceptible to attack.」
(当審訳)
「[0104] スキャンシステム101は、どのコンテナ内のどのサービスが外部に公開され、どのポート内でそれらがアクセス可能であるかを決定するために、スナップショットからネットワーク情報を読み取ることができる。例えば、スキャンシステム101は、ソフトウェアアプリケーションのバージョンに対する既知のソフトウェア脆弱性に基づいて、脆弱なアプリケーションがアクセス可能なポートを識別することができる。スキャンシステム101は、クラウドサービスプロバイダのシステムを通じて提供されるAPIを介してネットワークアクセシビリティ情報に問い合わせてもよく、攻撃を受けやすい特定の脆弱性を識別するためにそれを使用してもよい。」
「[0109] Aspects of this disclosure may include using the established trust relationship, utilizing at least one cloud provider API to identify workloads in the source account. A cloud provider API, as used herein, may refer to any application program interface that allows an end user to interact with a cloud providers service. A cloud provider, may include any entity through whom information is accessible over the Internet or other shared network. Workloads, as used herein, may refer to systems, devices, or resources in a network (or available via a network) such as a cloud infrastructure. By way of example, FIG. 1 illustrates examples of a workload: virtual machines 107A-107D, databases 109A-109D, storage 111A-111D, keystores 113A-113D, and load balancer 115. In some embodiments, scanning system 101 of FIG. 1 may perform a scanning operation on workload (e.g., systems, devices, resources, etc.) in cloud infrastructure 106.」
(当審訳)
「[0109] 本開示の態様は、確立された信頼関係を使用することと、少なくとも1つのクラウドプロバイダAPIを利用してソースアカウント内のワークロードを識別することとを含み得る。クラウドプロバイダAPIは、本明細書で使用される場合、エンドユーザがクラウドプロバイダサービスと相互作用することを可能にする任意のアプリケーションプログラムインターフェースを指し得る。クラウドプロバイダは、インターネットまたは他の共有ネットワークを介して情報がアクセス可能である任意のエンティティを含み得る。本明細書で使用本明細書で使用される場合、クラウドインフラストラクチャなどのネットワーク内の(またはネットワークを介して利用可能な)システム、デバイス、またはリソースを指し得る。例として、図1は、
仮想マシン107 A~107 D、データベース109 A~109 D、ストレージ111 A~111 D、キーストア113 A~113 D、およびロードバランサ115というワークロード
の例を示す。いくつかの実施形態では、図1のスキャンシステム101は、クラウドインフラストラクチャ106内のワークロード(例えば、システム、デバイス、リソースなど)に対してスキャン動作を実行することができる。」
「[0110] In some embodiments, scanning system 101 of FIG. 1 may use an API to detect workloads such as
virtual machines 107A-107D, databases 109A-109D, storage 111A-111D, keystores 113A-113D, and load balancer 115 in the source account.
」
(当審訳)
「[0110] いくつかの実施形態では、図1のスキャンシステム101は、APIを使用して、
ソースアカウント内の仮想マシン107 A~107 D、データベース109 A~109 D、ストレージ111 A~111 D、キーストア113 A~113 D、およびロードバランサ115
などのワークロードを検出することができる。」
「[0209] Prioritization Techniques」
(当審訳)
「[0209] 優先順位付け技術」
「[0210] FIG. 6 is a block diagram of method 600 for risk prioritization, consistent with disclosed embodiments.」
(当審訳)
「[0210] 図6は、開示される実施形態による、リスク優先順位付けのための方法600のブロック図である。」
「[0366] Aspects of this disclosure may include correlating each of the identified plurality of cybersecurity vulnerabilities with one of the plurality of assets. In some embodiments, scanning system 101 of FIG. 1 may connect a security risk with an asset in the cloud environment. In such embodiments, the connection or correlation of vulnerability to asset may allow the system to address the vulnerability.」
(当審訳)
「[0366] 本開示の態様は、識別された複数のサイバーセキュリティ脆弱性のそれぞれを複数のアセットのうちの1つと相関させるステップを含んでもよい。いくつかの実施形態では、図1のスキャンシステム101は、セキュリティリスクをクラウド環境内のアセットと結び付けてもよい。そのような実施形態では、脆弱性のアセットへの接続または相関は、システムが脆弱性に対処することを可能にし得る。」
「[0367] Aspects of this disclosure may include generating a report correlating the plurality of cybersecurity vulnerabilities with the plurality of assets. A report as used herein, may refer to a document containing information. For example, a report may notify the administrator of a website or application about a problem such as a security issue or vulnerability in the system that should be addressed. In some embodiments, scanning system 101 of FIG. 1 may create a report providing information related to the vulnerability and asset. In such an embodiment, the report may allow for the vulnerability to be addressed and resolved.」
(当審訳)
「[0367] 本開示の態様は、複数のサイバーセキュリティ脆弱性を複数のアセットと相関させる報告を生成するステップを含んでもよい。本明細書で使用されるレポートは、情報を含む文書を指すことができる。例えば、レポートは、対処されるべきシステムにおけるセキュリティ問題または脆弱性などの問題についてウェブサイトまたはアプリケーションの管理者に通知することができる。いくつかの実施形態では、図1のスキャンシステム101は、脆弱性およびアセットに関連する情報を提供する報告を作成してもよい。そのような実施形態では、報告は、脆弱性が対処され、解決されることを可能にし得る。」
(イ)甲1発明
甲1のFIG.2A、並びに、[0066]、[0074]ないし[0077]、[0081]、[0083]ないし[0086]、[0090]、[0091]、[0093]及び[0104]の記載によれば、甲1には、各ステップを実行するプロセス、すなわち「方法」が記載されているといえ、また、「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」と、「クラウドインフラストラクチャ106とは別個」である「スキャンシステム101」は、一体として「システム」を構成し、上記「方法」は「システム」で用いるものであると認められる。
よって、上記(ア)より、甲1には、次の発明(以下、「甲1発明」という。)が記載されていると認められる。
「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115とスキャンシステム101を備えるシステムで用いる方法であって、
クラウドインフラストラクチャ106は、仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115を含み、スキャンシステム101およびデータベース103 A~103 Dは、クラウドインフラストラクチャ106とは別個であり、
スキャンシステム101は、クラウドインフラストラクチャ106内の1つまたは複数のワークロード(例えば、システム、デバイス、リソースなど)に対してスキャン動作を実行し、
ユーザは、ロール定義をクラウドサービスプロバイダのシステムに提供し、ロール定義は、読み取り専用許可と、ブロック記憶層を読み取る許可とを含み、スキャンシステム101は、必要なロールを生成するためにクラウドインフラストラクチャ106が使用するロール形成テンプレート(例えば、Amazon Web Services CloudFormation Template)を提供し、
クラウドサービスプロバイダのシステムは、スキャンシステム101による使用のための文字列を生成し、この文字列は、生成されたロールによって許可されるようなクラウドインフラストラクチャのワークロードへのスキャンシステム101によるアクセスを可能にするために使用され、
スキャンシステム101は、クラウドインフラストラクチャ106内のデバイスおよびシステムの「スナップショット」を生成し、スナップショットを生成することは、ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステムを読み取ることと、これらのデバイス及びシステムから読み取られた情報をスキャンシステム101のストレージにコピーすることとを含み、
ステップ231において、スキャンシステム101は、脆弱性スキャンのステップを実行し、ステップ231は、スナップショット内のソフトウェアおよびオペレーティングシステムのライブラリバージョン、ソフトウェアバージョン、および他の識別特性を決定し、スキャンシステム101は、それらを脆弱性データベースに記憶された既知の脆弱性と照合する、方法。」
イ.甲第2号証
甲2には、次の事項が記載されている。
「03 AWS Organizations
AWS Organizationsの概要
・・・(中略)・・・
一方で、AWSアカウントが増えてくると、管理が行き届かなくなってガバナンスを効かせることが難しくなるというデメリットもあります。例えば、プロジェクトの管理者が把握していないAWSアカウントがある場合、ここがセキュリティホールとなって、情報漏洩などのセキュリティインシデントに発展する可能性が考えられます。
AWS Organizationsを利用すると、複数のAWSアカウントを一元管理できます。なお、先述したConfigのアグリゲータは、複数のAWSアカウントからAWSの構成情報を集約して一元管理するためのサービスであり、本項で紹介するOrganizationsとは役割が異なります。「一元管理」という意味では2つのサービスは共通していますが、目的や一元管理する対象が違うので、混同しないように注意しましょう。」(第485ページ)
「基本的な概念
・・・(中略)・・・
組織
一元管理可能な複数AWSアカウントのセットを「組織(Organization)」と呼びます。
組織単位(OU)
組織単位(Organizational Unit:OU)とは、組織内で作成した複数のAWSアカウントからなるグループです。例えば、上図に示したように「環境」に着目して、本番、開発、検証用のOUをそれぞれ「Prod OU」「Dev OU」「Test OU」と設定することができます。OUは入れ子構造にできるため、「A事業部OU」の配下に「A担当OU」を作成するなど企業の組織構造などに合わせて設定することができます。」(第486~487ページ)
ウ.甲第3号証
甲3には、次の事項が記載されている。
「マルチアカウント戦略とは
・・・(中略)・・・しかし、2017年2月にOrganizationsがリリースされて以降、AWSとしてもマルチアカウント戦略を推奨するようになりました。昨今のエンタープライズ向けシステムでは、Organizationsでマルチアカウント環境を組織化し、OU(Organizational Unit)を使って、複数のAWSアカウントを同じセキュリティポリシーで管理することがスタンダードになりました。しかし、本番環境とステージング/開発環境では守るべき資産やそのための要件やポリシーが異なります。開発環境では機密性の高い情報資産を持たず、システム開発におけるトライアンドエラーを許容しスピーディな開発を実現するため、ある程度の自由度を優先させます。」(第203ページ)
「図4.24 マルチアカウント構成イメージ
47
73
0001429995000002.jpg
」(第204ページ)
「図4.26 AWS Organizationsによるマルチアカウント管理
47
73
0001429995000003.jpg
」(第205ページ)
エ.甲第4号証
甲4には、次の事項が記載されている。
「2-5-2 AWS Organizationsの構成要素
AWS Organizationsは、次のような要素で構成されています。
28
73
0001429995000004.jpg
アカウントの種類と組織単位、サービスコントロール(SCP)など、用語が指す意味を最初に理解しておきましょう。」(第58ページ)
「2-5-3 組織単位(OU)と階層構造
まずOrganizationsの管理単位についての解説です。Organizationsでは、組織単位(OU)という単位で管理します。このOUは階層構造を取ることが可能で、かつ上位階層の設定は、下位の階層のOUに引き継がれます。
また、最上位の階層については、管理用ルート(root)となります。ここに直接メンバーアカウントを配置することも可能ですし、後述のサービスコントロールポリシー(SCP)を適用することも可能です。
ただし、管理用ルートにポリシーを設定すると、組織内全てに適用されることになります。そのため、管理用ルートについてはメンバーアカウントを配置せず、かつポリシーも適用しない方が良いでしょう。」(第58~59ページ)
「図2-10 組織単位と階層構造
60
62
0001429995000005.jpg
」(第59ページ)
「2-5-4 サービスコントロールポリシー(SCP)
論理的なグループは、OUとして管理するということでした。これに対してサービスコントロールポリシー(SCP)は、どのようなAWSリソースを利用可能あるいは禁止とするのかを記述するものです。
IAMと対比すると、IAMグループとIAMポリシーに似た関係になります。SCPはOUもしくはメンバーアカウントに設定します。OUに設定すると、そのOU内の全てのメンバーアカウントに適用されます。
また、上位のOUの設定は、下位のOUにも引き継がれます。
IAMの場合と同様に、個々のメンバーアカウントで設定するのではなく、OUに対してポリシーを設定していきましょう。OUに対して適用することにより、SCPの効率的な管理と、抜け漏れを防止することができます。」(第60ページ)
「図2-11 サービスコントロールポリシー(SCP)
60
63
0001429995000006.jpg
」(第60ページ)
「2-5-5 階層構造の組織単位によるSCPの継承
前述の通り、組織単位(OU)は階層構造をとることができます。そして組織単位に付与されたSCPも、下位の組織単位に継承されます。これを利用して、効率的なポリシー設計をすることができます」(第61ページ)
「図2-12 階層構造の組織単位によるSCPの継承
52
73
0001429995000007.jpg
」(第61ページ)
オ.甲第5号証
甲5には、次の事項が記載されている。
「今回の構成
・・・(中略)・・・
63
63
0001429995000008.jpg
」
「利用サービスについて
・・・(中略)・・・
AWS Organizationsについて
・・・(中略)・・・
AWSサービスの統合
AWS Organizationsでは、いくつかのAWSサービスを統合することが可能です。例えばCloudTrailを統合した場合、組織内の全アカウントでCloudTrailを一括で有効化したり、一括で設定を変更できるようになります。
なお統合されたサービスの操作は、通常マネジメントアカウント(AWS Organizationsのルートとなるアカウント)で行うことになります。サービスによっては、操作をマネジメントアカウント以外のアカウントに委任することも可能です。
・・・(中略)・・・
Organizational Unit(OU)
AWS Organizationsでは、アカウントをOUという単位でグルーピング可能です。上述のSCPや後述のCloudFormation StackSetsはアカウントのグループであるOUに適用することが可能です。
またOUはネスト可能であり(OUの中にOUを作れる)、上位のOUに適用されたSCPなどは下位のOUにも適用(=継承)されます。OUをうまく活用することで、アカウントの管理を効率的に行うことが可能です。
AWS CloudFormationについて
・・・(中略)・・・
AWS CloudFormation StackSets
CloudFormationによるリソースのデプロイを、マルチアカウント・マルチリージョンに拡張させたものがAWS CloudFormation StackSetsです。StackSetsはAWS Organizationsに統合することが可能で、また上述の委任にも対応しています。つまりマネジメントアカウント(もしくは委任されたアカウント)でテンプレートを流すことで、複数アカウントに一括してリソースをデプロイすることが可能になります。また一括デプロイのターゲットはアカウントを1つずつ選択するだけでなく、OUを選択することも可能です。」
「設計
・・・(中略)・・・
CloudFormation StackSets
上述のIAMリソースをデプロイするCloudFormation StackSetsテンプレートは以下となります。
CreateIAMRoleForAssumeRole.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: "Create IAM Role for Assume Role"
Resources:
IAMPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Action:
- "s3:*"
- "s3-object-lambda:*"
Resource: "*"
PolicyName: StackSetsTestPolicy
Roles:
- StackSetsTestRole
DependsOn: IAMRole
IAMRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: "Allow"
Principal:
AWS:
- "arn:aws:iam::<AWSアカウントID>:root"
Action:
- "sts:AssumeRole"
Condition:
Bool:
aws:MultiFactorAuthPresent: "true"
RoleName: StackSetsTestRole
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/ReadOnlyAccess"」
「構築手順
では構築していきます。 まずはマネジメントアカウントにログインしてStackSetsの画面を開き、「StackSetsの作成」をクリックします。
47
73
0001429995000009.jpg
「テンプレートの指定」で作成したYAMLテンプレートを指定し、あとはデフォルトで進みます。
ちなみにStackSetsを実行すると、ターゲットとなるAWSアカウントにCloudFormationスタックが作成されます。なのでStackSetsには、ターゲットに対してスタックを作成する権限を予め付与する必要があるのですが、「アクセス許可」で「サービスマネージドアクセス許可」を指定すると、この権限設定を自動で処理してくれます。詳細はこちらをご参照ください。
57
73
0001429995000010.jpg
StackSets名を適当に入力し、次へ進みます。説明はYAMLに予め埋め込んでいるので入力不要、パラメータは宣言していないので無視します。
55
73
0001429995000011.jpg
タグの設定はスキップして次に進みます。
40
73
0001429995000012.jpg
「デプロイターゲット」はOU-01のOU-IDを入力します。残念ながらこのウィザードから検索できないので、OU-IDが分からない場合はOrganizationsの画面を開いて確認します。
47
73
0001429995000013.jpg
「リージョンの指定」は「東京リージョン」を指定しました。ここで指定したリージョンはYAMLテンプレートで定義したリソース(今回の場合はIAMロールとポリシー)を作成するリージョンではなく、CloudFormationスタックを作成するリージョンである点にご注意ください。IAMはグローバルサービスでかつリソース名の重複は許されないはずなので、ここで複数リージョンを指定するとエラーになります。
29
73
0001429995000014.jpg
最後に設定内容を見返してメッセージにチェックを入れ、「送信」でStackSetsを作成します。
51
73
0001429995000015.jpg
作成されたStackSetsのステータスが「Succeed」になることを確認します。これで完了になりますので、実際にリソースが作成されているかを見てみます。
24
73
0001429995000016.jpg
StackSetsのターゲットとしたアカウントにログインすると、CloudFormationスタックが作成されています。
27
72
0001429995000017.jpg
IAM Roleもちゃんと作成されていますね。
36
73
0001429995000018.jpg
」
カ.甲第6号証
甲6には、次の事項が記載されている。
「7-2 AWS Organizations
・・・(中略)・・・
AWS Organizationsの機能
AWS Organizationsは、複数のAWSアカウントを階層的に管理できます。組織内には、請求アカウントでもある管理アカウントが1つ存在します。その下に、組織単位(Organization Unit、OU)と呼ばれる論理グループを複数作成することができ、さらには階層構造を作ることも可能です。OUを使って論理的なグループを作ることで、用途に応じてアカウントを管理することができます。」(第178ページ)
「AWS Organizationsの階層構造
31
72
0001429995000019.jpg
」(第178ページ)
「サービスコントロールポリシー(SCP)
サービスコントロールポリシー(Service Control Policies、SCP)は、組織のAWSアカウントに対する特定の権限や操作の許可/拒否を管理するための機能です。IAMポリシーに似ていますが、アカウント内のIAMユーザーやIAMロールではなく、アカウントレベルで権限を設定します。つまり、SCPで制限された機能は、アカウント内のIAMユーザーやIAMロールで権限を付与しても使えません。また、そのアカウントのルートユーザーですら制限されます。」(第179ページ)
「AWS CloudFormation StackSetsとの連携
AWS CloudFormation StackSetsは、AWS CloudFormationテンプレートを使用して、リソースの作成と管理を一元化するための機能です。StackSetsはAWS Organizationsと連携することを前提としており、Organizations内の複数のAWSアカウントに、CloudFormationを実行できます。使い方としては、組織内で共通に適用する必要があるセキュリティ設定などをCloudFormationのテンプレートとしておき、StackSetsを利用してアカウント作成時に自動的に実行させるといったことができます。
組織内全体のみならず、特定のOUのみといった適用の仕方もできます。その場合は、対象のOUに所属したタイミングで、自動的にCloudFormationを発動させるといったことも可能です。また、逆にOUから離脱したら、その設定を取り消すことも可能です。マルチアカウント運用をする上で、セキュリティとガバナンスを担保するための必須機能の1つとも言えます。」(第179~180ページ)
キ.甲第7号証
甲7には、次の事項が記載されている。
「How does it work?
A CloudFormation template describes your desired resources and their dependencies so that you can launch and configure them together as a stack. You can use a template to create, update, and delete an entire stack as a single unit instead of managing resources individually.
With CloudFormation support for AWS Organizations, you can now do the following:
-Create, delete, or update an organizational unit (OU). An OU is a container for accounts that allows you to organize your accounts to apply policies according to your needs.
-Create accounts in your organization, add tags, and attach them to OUs.
-Add or remove a tag on an OU.
-Create, delete, or update a service control policy (SCP), backup policy, tag policy and artificial intelligence (AI) services opt-out policy.
-Add or remove a tag on an SCP, backup policy, tag policy, and AI services opt-out policy.
-Attach or detach an SCP, backup policy, tag policy, and AI services opt-out policy to a target (root, OU, or account).
To create AWS Organizations resources using CloudFormation, you will need to use your organization’s management account. As of this writing, the new resource types may only be deployed from the organization’s management account or delegated administration account.」
(当審訳)
「どのように機能するか?
CloudFormationテンプレートは、所望のリソースおよびそれらの依存性を記述するので、それらを一緒にスタックとして起動し構成することができる。リソースを個々に管理する代わりに、テンプレートを使用して、スタック全体を単一のユニットとして作成、更新、および削除することができる。
AWS OrganizationsのためのCloudFormationサポートを用いて、次のことを行うことができる。
-Organizational Unit(OU)を作成、削除、または更新する。OUは、必要に応じてポリシーを適用するためにアカウントを編成することを可能にするアカウント用のコンテナである。
-組織にアカウントを作成し、タグを追加し、それらをOUにアタッチする。
-OU上のタグを追加または削除する。
-Service Control Policy(SCP)、バックアップポリシー、タグポリシーおよび人工知能(AI)サービスのオプトアウトポリシーを作成、削除または更新する。
-SCP、バックアップポリシー、タグポリシー、およびAIサービスのオプトアウトポリシー上のタグを追加または削除する。
-SCP、バックアップポリシー、タグポリシー、およびAIサービスのオプトアウトポリシーをターゲット(ルート、OU、またはアカウント)にアタッチまたはデタッチする。
CloudFormationを使用してAWS Organizationsリソースを作成するためには、組織の管理アカウントを使用する必要がある。本記事の時点で、新しいリソースタイプは、組織の管理アカウントまたは委託管理アカウントからのみデプロイされ得る。」
ク.甲第8号証
甲8には、次の事項が記載されている。
「IAMポリシー作成の考え方
IAMユーザーの取り扱いを決めたら、続いてIAMポリシーをいかに作るかが重要になります。IAMポリシーは、AWSのAPIへのアクセス権限、要するに操作権限を管理するための機能です。200を超えるAWSサービスごとに複数定義されている個別APIごとに設定できるため、かなり細かい権限設定が可能となっており、「どのAWSサービスの」「どういう操作を」「どのリソースに対して」「許可するor禁止する」といった具合で記述します。」(第113ページ)
ケ.甲第9号証
甲9には、次の事項が記載されている。
「【請求項3】
請求項2に記載のセキュリティ管理システムであって、
共通脆弱性評価システム(CVSS:Common Vulnerability Scoring System)における評価基準により前記評価対象モデルの脆弱性を評価した情報を記憶し、
前記情報に基づき前記リスク値を求める、
セキュリティ管理システム。
【請求項4】
請求項3に記載のセキュリティ管理システムであって、
前記評価基準は、攻撃元区分 (AV:Access Vector)、攻撃条件の複雑さ (AC:Access Complexity)、攻撃前の認証要否 (AU:Authentication)、機密性への影響 (C: Confidentiality Impact )、完全性への影響 (I:Integrity Impact )、及び可用性への影響 (AI:Availability Impact )のうちの少なくともいずれかである、
セキュリティ管理システム。」
「【0081】
脅威一覧生成部140は、影響度区分テーブル1211及び攻撃容易性区分テーブル1212を用いて抽出した各脅威のリスク値を算出する。脅威一覧生成部140は、例えば、次の各式からリスク値を算出する。
【0082】
[数1]
影響度 =10.41×(1-(1-C)×(1-I)×(1-A))
[数2]
攻撃容易性=20×AV×AC×Au
[数3]
f(影響度)=0(影響度が0の場合),1.176(影響度が0以外の場合)
[数4]
リスク値=((0.6×影響度)+(0.4×攻撃容易性)-1.5)×f(影響度)」
「【図12A】
60
73
0001429995000020.jpg
」
コ.甲第10号証
甲10には、次の事項が記載されている。
「【0111】
さまざまな実現例において、クラウドセキュリティシステム200は、脅威に対応するための手動および/または自動化されたプロセスを提供する救済機能を含むことができる。いくつかの例では、分析は、テナントによって提供される脅威インテリジェンスを記述する、テナントシステムから受信した情報を用いることができる。例示的なシステム200においてテナントベースライン217と呼ばれるこれらのソースには、監視またはブロックすべき特定のIPアドレス、監視またはブロックすべきユーザ、監視またはブロックすべき電子メールアドレス、監視すべきソフトウェア脆弱性、誤用の影響を受けやすいブラウザもしくはブラウザバージョン、および/またはモバイルハードウェアもしくはソフトウェアの脆弱なモバイルデバイスもしくはバージョンなどが含まれ得る。いくつかの例では、分析は外部のサードパーティフィード218から受信した情報を用いることができる。サードパーティフィード218のソースは、例えば、脅威インテリジェンスアグリゲータまたはディストリビュータであり得る。サードパーティフィード218からの情報を用いて、セキュリティ脅威に関する外部情報を提供することにより、クラウドセキュリティシステム200の脅威分析を強化することができる。外部情報には、たとえば、感染したノードポイントの識別、特定のソースIPアドレスからの悪意のあるアクティビティ、マルウェアに感染した電子メールメッセージ、脆弱なウェブブラウザバージョン、クラウドに対する既知の攻撃などが含まれ得る。」
「【0168】
リスクスコアの計算に用いられるインジケータは、特定のリスク要因をスコアの形式でも提供することができる。たとえば、異常検出の結果には、標準からの逸脱の程度および/または異常が組織にもたらすリスクの程度を示すスコア形式のインジケータを含めることができる。一部の例では、同じユーザまたは同じサービスに関連付けられた各異常を個別のインジケータとして用いることができる。さまざまな例において、リスクスコアの計算に用いることができる他のインジケータは、ユーザ、サービス、サービスプロバイダ、ユーザがいると思われるジオロケーション、ユーザがいると思われるドメイン、時刻もしくは曜日もしくは時節、または別の要因に関連付けられることができる。ユーザのインジケータは、たとえば、ユーザが関連付けられている組織、評判サイト、ソーシャルメディアサイト、ニュース組織、または別のソースから取得することができる。サービスまたはサービスプロバイダのインジケータは、たとえば、サービスもしくはサービスプロバイダの評判を追跡することができる脅威インテリジェンスアグリゲータまたはディストリビュータから取得することができる。他のインジケータは、内部脅威インテリジェンスデータ314によって提供されてもよい。」
「【0176】
生成され得る別の部類の分析として、予測分析およびヒューリスティック分析がある。これらは、機械学習アルゴリズムを組み込んで、たとえば、基準となる期待値からの偏差、めったに起こらないイベント、およびユーザの怪しい挙動を得るための挙動分析などの脅威モデルを生成してもよい。普通でない挙動がセキュリティリスクであるかどうかをインテリジェントに予測するようにアルゴリズムおよびプロファイルを訓練できる。これらに限定されないが、IP(Internet Protocol)アドレスの評判、マルウェア、感染したノードポイントのID、脆弱なウェブブラウザのバージョン、ユーザによるプロキシサーバまたはVPNサーバの使用、およびクラウドに対する既知の攻撃など、潜在的なセキュリティ脅威の外部情報および潜在的なセキュリティ脅威に関する外部情報を提供することによって、これらに限られないが、MaxMind、FireEye、Qualy、Mandiant、AlienVault、およびNorse STIXなどのプロバイダからのサードパーティフィードを統合して、脅威インテリジェンスを強化することができる。これらのサードパーティフィードは、たとえば、IPアドレス評判、マルウェア、感染ノードポイントの識別、脆弱なウェブブラウザバージョン、ユーザによるプロキシまたは仮想プライベートネットワーク(VPN)サーバの使用、クラウドに対する既知の攻撃など、潜在的なセキュリティ脅威に関する外部情報を提供することができる。一部の例では、脅威情報は、Structured Threat Information eXpression(STIX)データフォーマットで表される。たとえば、1つ以上のサービスが、評判(たとえば、ソフトウェア脆弱性がある、悪意のあるソフトウェアのホストである、または攻撃のソースであると知られている)および/またはIPアドレスに対応付けられた地理的位置など、特定のIPアドレスに関する情報を提供してもよい。この情報は、何時にそのIPアドレスからログインが試みられたかなど、IPアドレスを伴う取り出されたアクティビティデータ、および、ログインの試みの間隔など、アクティビティデータから得られた情報と組み合わせることができる。これらの要因を用いて、「ログイン速度(login velocity)」評価指標を決定することができる。ファイルアクセス、売買取引、または仮想マシンのインスタンスなど、他のアクティビティの評価指標を決定することができる。」
サ.甲第11号証
甲11には、次の事項が記載されている。
「【0010】
本開示に係る技術は、このような事情を鑑みて開発されたものである。即ち、本開示は、サイバー攻撃等のセキュリティに関する攻撃の状況をわかりやすく可視化する技術を提供することを、主たる目的の一つとする。」
「【0083】
本実施形態における情報源520は特に限定されない。情報源520は、例えば、セキュリティ及び通信ネットワークに関する情報を提供可能な、各種の情報提供サービス等であってもよい。一例として、情報源520には、DNS、WHOIS等のIPネットワークに関する情報を提供する各種の外部サービスが含まれてもよい。他の一例として、情報源520には、例えば、セキュリティベンダやセキュリティ関連の組織により運営される、セキュリティ関連情報(各種脆弱性、サイバー攻撃、マルウェア等)を提供するサービスが含まれてもよい。更に他の一例として、情報源520には、例えば、セキュリティベンダ等により運営される、オンラインのセキュリティ分析サービス(例えば、マルウェア検査、悪質なサイト(URL)の検査等)が含まれてもよい。更に他の一例として、情報源520には、セキュリティに関連する情報を発信する、現在では一般的なソーシャルネットワーキングサービス等が含まれてもよい。更に他の一例として、情報源520には、セキュリティに関するコンテンツを提供するWeb(World Wide Web)サイト、セキュリティに関する情報が蓄積されたデータベース、等が含まれてもよい。」
シ.甲第12号証
甲12には、次の事項が記載されている。
「【0025】
スキャナ101が収集する構成情報は、機器に含まれている脆弱性、機器に搭載されているOS(Operating System)およびOSのバージョン、機器に搭載されているハードウェアの構成情報、機器に搭載されているソフトウェア、ソフトウェアのバージョンおよびソフトウェアの設定等である。」
「【0039】
確定ファクト生成部103は、例えば、ある機器にインストールされているOSおよびOSのバージョンを構成情報から参照して、対象の機器に参照されたバージョンのOSがインストールされている、という状況を表す初期ファクトを生成する。」
「【0119】
また、未確定ファクト生成部104は、インストール済みのソフトウェアのサポートが終了している場合、サポート終了からの経過時間を基に統計的に判断する。サポートが終了すると、ソフトウェアは、ベンダにより管理されなくなる。また、サポート終了からの経過時間が長くなるほど、ソフトウェアに脆弱性が発見されている確率が高くなる。よって、経過時間が閾値を超えたら、未確定ファクト生成部104は、ソフトウェアに未知の脆弱性が存在すると判断する。」
(2)申立理由(進歩性欠如)について
ア 本件特許発明15について
(ア)対比
本件特許発明15と甲1発明とを対比する。
a 甲1発明の「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」は、一体として「システム」を構成するものであると認められ、また、「システム」とは、ユーザに対してシステムを利用するための環境、すなわち「システム環境」を提供するものであることが、本件特許出願時における技術常識であるから、「システム環境を有する」ものであるといい得る。そして、甲1発明は、「スキャンシステム101」が「クラウドインフラストラクチャ106」内の「
ワークロード
(例えば、システム、デバイス、リソースなど)
に対して
スキャン動作を実行」するものであるところ、甲1の「仮想マシン107 A~107 D、データベース109 A~109 D、ストレージ111 A~111 D、キーストア113 A~113 D、およびロードバランサ115という
ワークロード
」([0109])という記載を踏まえると、甲1発明の「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」は、「スキャンシステム101」によるスキャン動作の対象のシステム、すなわち「対象システム」であるといい得る。
以上のことから、甲1発明の「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」と、本件特許発明15の「階層化されたリソースと対応付けられるシステム環境を有する対象システム」は、「システム環境を有する対象システム」である点で共通する。
b 甲1発明において「
ワークロードへの
スキャンシステム101による
アクセス
」は「生成されたロールによって許可される」ものであると認められる。そして、甲1発明は、「スキャンシステム101」が「
ワークロード
(例えば、システム、デバイス、リソースなど)に対して
スキャン動作を実行
」し、「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステムを
読み取
」り、「これらのデバイス及びシステムから
読み取られた情報
をスキャンシステム101のストレージにコピーする」ものであること、及び、「ロール定義」が、「
読み取り
専用
許可
と、ブロック記憶層を
読み取る許可
とを含」むものであることを踏まえると、甲1発明は、「スキャンシステム101」が「ワークロード」に対して「スキャン動作を実行」して情報を「読み取る」ことを、「ロールによって許可」するものであると認められる。
一方、本件明細書には「構成管理ツールで構築するリソースは、少なくとも、情報処理装置10がリソースと対応付けられた
システム環境をスキャンする
ことを許可するロール(例えば、情報処理装置10による
Read
Onlyなど)を含んでもよい。」(【0038】)と記載されており、本件特許発明15における「前記システム環境をスキャンする」ことは、システム環境を「Read」する、すなわち、
読み取る
ことを含むものと解される。
してみると、甲1発明において、「ワークロード」に対して「スキャン動作を実行」して情報を「読み取る」ことは、本件特許発明15の「前記システム環境をスキャンする」ことに相当する。そして、甲1発明において、「ワークロード」に対して「スキャン動作を実行」して情報を「読み取る」ことは、「ロールによって許可」されるものであるところ、「ロール」によって割り当てられる“権限”といい得るものであり、甲1発明の「スキャンシステム101」は、「ロール」によって上記“権限”が割り当てられている点において、本件特許発明15において、「ロール」によって「前記システム環境をスキャンする権限」が割り当てられている「情報処理装置」に相当する。
また、甲1発明の「ロール」は、「読み取り専用許可と、ブロック記憶層を読み取る許可」を「定義」するものであると認められるところ、読み取りを許可する定義は、読み取りの対象となるシステムにおいて設定するものであることが、本件特許出願時における技術常識であるから、甲1発明の「ロール」は、「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」において設定するものであると認められ、甲1発明において「ロール」を設定することは、「ロール」を「付与」することであるということができる。
以上のことから、甲1発明において、「ワークロード」に対して「スキャン動作を実行」して情報を「読み取る」ことを「スキャンシステム101」に「許可」する「ロール」を設定することと、本件特許発明15の「前記対象システムが、前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて、前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを所定階層のリソースに付与する」ことは、「前記対象システムが、前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを付与する」点で共通する。
c 本件明細書には「ここで、
アセット
は、
クラウドプラットフォーム上で管理できる全てのシステム環境
、エンティティ及びサービス
を含み
、例えば、仮想マシン、仮想ネットワーク、ストレージアカウント、Webアプリケーション、データベースなどを含んでもよい。」(【0031】)と記載されており、本件特許発明15の「アセット」は、クラウドプラットフォーム上のシステム環境を含むものと解されるから、甲1発明の「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」は、本件特許発明15の「アセット」に相当し、甲1発明において「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」から読み取った「情報」は、本件特許発明15の「アセット情報」に相当する。
d 甲1発明は、「スキャンシステム101」が「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」から読み取った「情報」を「スキャンシステム101のストレージにコピーする」ものである。ここで、対象のシステムから情報を読み取るに際し、対象のシステムが、読み取りの要求に対する応答として情報を返す、すなわち、情報を送信することが、本件特許出願時における技術常識であるから、甲1発明の「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」は「スキャンシステム101」に対して「情報」を送信するものと認められる。
以上のことから、甲1発明において、「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」が「情報」を「スキャンシステム101」に対して送信することと、本件特許発明15の「前記対象システムが、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を前記情報処理装置に送信」することは、「前記対象システムが、システム環境のアセット情報を前記情報処理装置に送信」する点で共通し、甲1発明において、「スキャンシステム101」が「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」から読み取った「情報」を「スキャンシステム101のストレージにコピーする」ことと、本件特許発明15の「前記情報処理装置が、前記所定階層のリソースと対応付けられたシステム環境のアセット情報を取得する」ことは、「前記情報処理装置が、システム環境のアセット情報を取得する」点で共通する。
e 甲1発明の「スナップショット内のソフトウェアおよびオペレーティングシステムのライブラリバージョン、ソフトウェアバージョン、および他の識別特性」は、「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」から読み取った「情報」であると認められる。また、甲1発明は「スナップショット内のソフトウェアおよびオペレーティングシステムのライブラリバージョン、ソフトウェアバージョン、および他の識別特性」を「脆弱性データベースに記憶された既知の脆弱性と照合する」ものであるところ、「照合」の結果として、「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」の「脆弱性」を特定するものと認められる。
以上のことから、甲1発明において「スナップショット内のソフトウェアおよびオペレーティングシステムのライブラリバージョン、ソフトウェアバージョン、および他の識別特性」を「脆弱性データベースに記憶された既知の脆弱性と照合」して「ストレージ111A~111D、データベース109A~109D、及び仮想マシン107A~107Dなどのクラウドインフラストラクチャ内のデバイス及びシステム」の「脆弱性」を特定することと、本件特許発明15の「前記情報処理装置が、取得された前記アセット情報に基づいて、前記所定階層のリソースと対応付けられたシステム環境の脆弱性情報を特定する」ことは、「前記情報処理装置が、取得された前記アセット情報に基づいて、システム環境の脆弱性情報を特定する」点で共通する。
f 甲1発明の「システム」は「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」と「スキャンシステム101」を備えるものであるから、本件特許発明15の「階層化されたリソースと対応付けられるシステム環境を有する対象システム及び情報処理装置を備える情報処理システム」と、「システム環境を有する対象システム及び情報処理装置を備える情報処理システム」である点で共通する。
g 甲1発明の「方法」は、後述する相違点を除いて、本件特許発明15の「情報処理方法」に相当する。
(イ)一致点・相違点
以上から、本件特許発明15と甲1発明とは、以下の点において一致ないし相違する。
[一致点]
「システム環境を有する対象システム及び情報処理装置を備える情報処理システムで用いる情報処理方法であって、
前記対象システムが、前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロールを付与するステップと、
前記対象システムが、システム環境のアセット情報を前記情報処理装置に送信するステップと、
前記情報処理装置が、システム環境のアセット情報を取得するステップと、
前記情報処理装置が、取得された前記アセット情報に基づいて、システム環境の脆弱性情報を特定するステップと、を備える、
情報処理方法。」
[相違点]
(相違点1)本件特許発明15の「システム環境」は「階層化されたリソースと対応付けられる」ものであるのに対し、甲1発明の「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」には、当該事項が特定されていない点。
(相違点2)本件特許発明15は「前記システム環境をスキャンする権限を前記情報処理装置に割り当てるロール」を「前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用いて」「所定階層のリソースに」付与するのに対し、甲1発明は、当該構成について具体的に特定していない点。
(相違点3)本件特許発明15は「前記所定階層のリソース」が「前記階層化されたリソースのうち、前記ルートよりも下位階層のリソースである」のに対し、甲1発明は、当該構成について具体的に特定していない点。
(ウ)相違点についての判断
事案に鑑みて、相違点1ないし3について、まとめて検討する。
本件明細書の【0021】には「
ツリー構造の最下位の階層に位置するリソースは、
メンバーアカウント又はプロジェクトと称されてもよい。メンバーアカウント又はプロジェクトは、サブスクリプション又はテナントと称されてもよく、以下、これらを総称して、
メンバーアカウントと称する。
メンバーアカウントは、システム環境を構成し、使用されるアセットを対応付けることができるリソースであり、ユーザの識別情報で構成されるユーザアカウントとは区別される。また、最上位の階層に位置するルートと最下位の階層に位置するメンバーアカウントとの間に、複数のメンバーアカウントを束ねるリソースが設けられてもよい。
複数のメンバーアカウントを束ねるリソースは、ユニットと称されてもよい。
ユニットは、フォルダ又はディレクトリと称されてもよい。」と記載されているところ、本件特許発明15の「階層化されたリソース」は、メンバーアカウント、又は、複数のメンバーアカウントを束ねるユニット、を含むものであると解される。
一方、甲1には「クラウドインフラストラクチャ106上の
アカウント
」([0062])、「ソース
アカウント
内の
仮想マシン107 A~107 D、データベース109 A~109 D、ストレージ111 A~111 D、キーストア113 A~113 D、およびロードバランサ115」
([0110])と記載されており、甲1発明の「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」が、特定のアカウントと対応付けられることは示唆されているといえるが、複数のアカウントを束ねて階層化することについては、記載も示唆もされていない。
ここで、甲2ないし4の記載によれば、AWS Organizationsにおいて、複数のAWSアカウントをOUという単位で管理して階層化することは、本件特許出願時における周知技術であると認められる。しかしながら、甲1には、複数のアカウントを束ねて階層化することが記載も示唆もされておらず、逆に、甲2ないし4には、階層化されたリソース(アカウント)に「システム環境をスキャンする権限」に付与すること等について記載も示唆もないから、甲1発明において、甲2ないし4に記載の周知技術を参酌して、「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」を「階層化されたリソースと対応付けられ」たものとすべき動機付けがあるとはいえない。
したがって、上記相違点1に係る本件特許発明15の構成、すなわち、甲1発明において、「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」を「階層化されたリソースと対応付けられ」たものとすることは、甲2ないし4に記載の周知技術を参酌しても、当業者が容易に想到することができたものとはいえない。
また、甲5ないし甲12にも、相違点1に係る本件特許発明15の構成は記載されておらず、当該構成は、本件特許出願時における技術常識とも認められない。
そして、相違点1に係る本件特許発明15の構成が、当業者が容易に想到することができたものではない以上、相違点1に係る本件特許発明15の構成を前提とする、相違点2及び3に係る本件特許発明15の構成についても、当業者が容易に想到することができたものとはいえない。
(エ)申立人の主張について
申立人は、特許異議申立書において、甲1の[0053]にはAWSを用いてクラウドインフラストラクチャを構成することが記載されているから、甲1発明のクラウドインフラストラクチャを保護するに際し、甲1ないし4に記載のAWSアカウントに関する技術を用い、システム環境を「階層化されたリソースと対応付けられる」ものとすることは、当業者であれば容易に想到し得る事項である旨を主張している。しかしながら、当該記載は、甲1発明の「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」がAWSのアカウントと対応付けられることを示唆するにとどまり、上記(ウ)のとおり、特定のアカウントを束ねて階層化することを示唆するものではないから、甲1発明に甲2ないし4に記載の周知技術を適用する動機付けを見いだすことはできない。
さらに、申立人は、相違点2に係る構成に関して、甲1の[0076]には、Amazon Web Services CloudFormation テンプレートを用いてロールを形成することが記載されているから、甲5ないし7に記載のCloudFormationテンプレートに関する技術を用い、甲1発明において、「前記階層化されたリソースの最上位のルートを操作する権限を有する特定アカウントを用い」ることは、当業者であれば容易に想到し得る事項である旨を主張しているが、甲1の[0076]に記載の「Amazon Web Services CloudFormation テンプレート」は、「クラウドインフラストラクチャ106」が含む「仮想マシン107A~107D、データベース109A~109 D、ストレージ111A~111D、キーストア113A~113D、およびロードバランサ115」において設定する「ロール」を「ユーザ」が定義するためのツールとして使用されているにすぎず、特定のアカウントを束ねて階層化すること、及び、最上位のルートを操作する権限を有する特定アカウントを用いることを、何ら示唆するものではないから、甲1発明に甲5ないし7に記載の技術を適用する動機付けを見いだすことはできない。
(オ)小括
以上のとおりであるから、本件特許発明15は、当業者が、甲第1号証に記載された発明に基いて、甲第2号証~甲第12号証に記載された事項を参酌して、容易に発明をすることができたものではない。
上記第7のとおり、本件特許の請求項1ないし14に係る特許についての特許異議の申立ては、請求項1ないし14が本件訂正により削除されたことにより申立ての対象が存在しないものとなったため、特許法第120条の8第1項で準用する同法第135条の規定により却下する。
本件特許の請求項15に係る特許は、当審が通知した取消理由及び特許異議の申立ての理由によっては取り消すことはできない。
また、他に本件特許の請求項15に係る特許を取り消すべき理由を発見しない。
よって、上記結論のとおり決定する。
Next Action
類似審決の追加調査から中間応答、新規出願の費用確認まで、この審決を起点に次のアクションへ進めます。
商標の登録可能性を無料で確認するか、費用の目安を料金表・シミュレーターで把握できます。