2023-701135

特許第７２６５０５４号発明「情報処理装置及びプログラム」の特許異議申立事件について、次のとおり決定する。

結 論 特許第７２６５０５４号の請求項１～１８に係る特許を維持する。

理 由 第１ 手続の経緯 特許第７２６５０５４号の請求項１～１８に係る特許（以下、「本件特許」という。）についての出願は、令和３年８月２６日に出願した特願２０２１－１３８４３９号の一部を令和４年３月１４日に新たな特許出願としたものであって、令和５年２月２４日に手続補正がされ、同年４月１７日にその特許権の設定登録がされ、同年４月２５日に特許掲載公報が発行された。その後、本件特許に対し、同年１０月２４日に特許異議申立人 八木峰子（以下「異議申立人」という。）は、特許異議の申立てを行った。 第２ 本件発明 本件特許の請求項１～１８に係る発明（以下、それぞれ「本件発明１」～「本件発明１８」といい、併せて「本件発明」という。）は、特許請求の範囲の請求項１～１８に記載された事項により特定される次のとおりのものである。なお、独立形式の請求項である請求項１～３に記載された構成要件「１Ａ」～「３Ｇ」は、異議申立人が異議申立書で付与したものである。 「【請求項１】 １Ａ コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法であって、 １Ｂ 以下のステップを含み、 １Ｃ 管理ステップでは、サービスを管理し、 １Ｄ 検出ステップでは、前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出し、 １Ｅ 特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定した場合、管理されていないサービスが検出された旨を出力する １Ｆ 情報処理方法。 【請求項２】 ２Ａ コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法であって、 ２Ｂ 以下のステップを含み、 ２Ｃ 管理ステップでは、サービスを管理し、 ２Ｄ 検出ステップでは、前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出し、 ２Ｅ 特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定し、 ２Ｆ 前記検出ステップでは、前記通信ネットワークを介して取得される前記情報としてブラウザの閲覧履歴を取得することにより、前記閲覧履歴から前記利用されているサービスを検出する ２Ｇ 情報処理方法。 【請求項３】 ３Ａ コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法であって、 ３Ｂ 以下のステップを含み、 ３Ｃ 管理ステップでは、サービスを管理し、 ３Ｄ 検出ステップでは、前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出し、 ３Ｅ 特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定し、 ３Ｆ 前記検出ステップでは、前記通信ネットワークを介して取得される前記情報としてメールの受信履歴を取得することにより、前記受信履歴から前記利用されているサービスを検出する ３Ｇ 情報処理方法。 【請求項４】 請求項１～３のいずれか１項に記載の情報処理方法において、 前記検出ステップでは、前記通信ネットワークを介して取得される前記情報として接続先のアドレスを取得することにより、前記接続先のアドレスから前記利用されているサービスを検出する 情報処理方法。 【請求項５】 請求項１～４のいずれか１項に記載の情報処理方法において、 前記検出ステップでは、前記通信ネットワークを介して取得される前記情報として利用者端末の利用履歴を取得することにより、前記利用履歴から前記利用されているサービスを検出する 情報処理方法。 【請求項６】 請求項１～５のいずれか１項に記載の情報処理方法において、 前記特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、所定期間以上利用されていないサービスを特定する 情報処理方法。 【請求項７】 請求項１～６のいずれか１項に記載の情報処理方法において、 前記通信ネットワークを介して取得される前記情報は、会計サービス、経費サービス、またはプリペイドカードサービスを介して取得される支払情報と、クレジットカード会社が提供する利用明細と、銀行が提供する出金明細との少なくとも一つを含む 情報処理方法。 【請求項８】 請求項１～７のいずれか１項に記載の情報処理方法において、 前記検出ステップでは、前記通信ネットワークを介して取得される前記情報としてアカウントの利用履歴を取得することにより、前記利用履歴から前記利用されているサービスを検出する 情報処理方法。 【請求項９】 請求項１～８のいずれか１項に記載の情報処理方法において、 前記管理ステップでは、サービスの名称とアカウントを管理する 情報処理方法。 【請求項１０】 請求項１～９のいずれか１項に記載の情報処理方法において、 前記管理ステップでは、サービスの内容と価格を管理する 情報処理方法。 【請求項１１】 請求項１～１０のいずれか１項に記載の情報処理方法において、 前記検出ステップでは、利用者から受け付けた申告からサービスを検出する 情報処理方法。 【請求項１２】 請求項１～１１のいずれか１項に記載の情報処理方法において、 前記特定ステップでは、前記検出ステップで検出されたサービスから、利用頻度が予め定めた値以上のサービスを特定し、 前記管理ステップでは、該特定したサービスを新たな管理対象として管理する 情報処理方法。 【請求項１３】 請求項１～１２のいずれか１項に記載の情報処理方法において、 前記特定ステップでは、前記検出ステップで検出されたサービスを、最初に利用したアカウントを特定する 情報処理方法。 【請求項１４】 請求項１～１３のいずれか１項に記載の情報処理方法において、 前記検出ステップでは、ＩＤプロバイダから該ＩＤプロバイダが提供するアカウントの利用履歴を取得し、該利用履歴に含まれる利用先から利用されているサービスを検出する 情報処理方法。 【請求項１５】 請求項１～１４のいずれか１項に記載の情報処理方法において、 判定ステップを実行し、 前記判定ステップでは、前記管理ステップで管理するサービスの利用頻度に基づいて、該サービスの解約が可能であると判定した場合、その旨を報知する 情報処理方法。 【請求項１６】 請求項１５に記載の情報処理方法において、 前記判定ステップでは、前記管理ステップで管理するサービスの代替サービスの有無を判定し、該判定の結果に基づいて前記解約の可否を判定する 情報処理方法。 【請求項１７】 コンピュータを情報処理装置として動作させるプログラムであって、 コンピュータを請求項１～１６のいずれか１項に記載の情報処理装置として機能させる、プログラム。 【請求項１８】 情報処理装置であって、 請求項１～１６のいずれか１項に記載の各ステップを実行可能な情報処理装置。」 第３ 申立理由の概要 １ 異議申立人の提出した証拠 異議申立人は、次の甲第１号証～甲第１０号証（以下、それぞれ、「甲１」～「甲１０」という。）を証拠として提出している。 甲第１号証（甲１）：“Introducing Shadow IT Discovery（シャドーITディスカバリーの導入）”、Abe Carryl、令和３年８月１６日掲載、＜URL：https://web.archive.org/web/20210816132243/https://blog.cloudflare.com/introducing-shadow-it-discovery/ ＞ 甲第２号証（甲２）：“Extending MCAS Cloud Discovery into the Managing of Shadow IT（MCASのクラウド・ディスカバリーをシャドーITの管理に拡張する）”、Sami Lamppu、令和３年８月１８日掲載、＜URL：https://samilamppu.com/2021/08/18/extending-mcas-cloud-discovery-into-the-managing-of-shadow-it/ ＞ 甲第３号証（甲３）：“"Sign in with Google" and the hidden cost of convenience（「Googleでログイン」と利便性の隠れた代償）”、Richard Kirby、令和３年４月２２日掲載、＜URL：https://web.archive.org/web/20210422162621/https://trelica.com/blog/sign-in-with-google-and-the-hidden-cost-of-convenience/ ＞ 甲第４号証（甲４）：米国特許出願公開第２０１８／００２７００６号明細書 甲第５号証（甲５）：米国特許出願公開第２０１９／０１９９７５１号明細書 甲第６号証（甲６）：米国特許出願公開第２０１７／０１３４５０６号明細書 甲第７号証（甲７）：特表２０１６－５０４６８７号公報 甲第８号証（甲８）：“OAuth Token audit log（OAuthトークンの監査ログ）”、Google、令和３年７月２９日掲載、＜URL：https://web.archive.org/web/20210729102032/https:/support.google.com/a/answer/6124308?hl=en ＞ 甲第９号証（甲）９：特開２０２１－７７２７１号公報 甲第１０号証（甲１０）：特開２０２１－５１６１２号公報 ２ 特許異議の申立理由 異議申立人の主張する特許異議の申立理由の概要は以下のとおりである。 （１） 理由１（新規性） 本件発明は、甲１～甲６に記載された発明であって、特許法２９条１項３号に該当するから、本件特許は、同条同項の規定に違反してされたものである。 （２） 理由２（進歩性） 本件発明は、甲１～甲１０に記載された事項に基づいて当業者が容易に発明をすることができたものであるから、本件特許は、特許法２９条２項の規定に違反してされたものである。 （３） 理由３（明確性） 本件発明は、明確であるとはいえないから、本件特許は、特許法３６条６項２号に規定する要件を満たしていない特許出願に対してされたものである。 （４） 理由４（サポート要件） 本件発明は、本件特許についての願書に添付された明細書（以下、「本件明細書」という。）の発明の詳細な説明に記載したものではないから、本件特許は、特許法３６条６項１号に規定する要件を満たしていない特許出願に対してされたものである。 （５） 理由５（新規事項の追加） 本件特許に係る出願について、令和５年２月２４日付けで提出された手続補正書における特許請求の範囲の補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものではないから、本件特許は、特許法第１７条の２第３項に規定する要件を満たしていない補正をした特許出願に対してされたものである。 第４ 異議申立人の提出した証拠の記載 １ 甲１について （１） 甲１の記載 甲１には、以下の記載がある（下線は当審において加筆した。なお、外国語文献の訳文は異議申立人が提出した訳を採用した。以下同じ。）。 「あなたのチームは、あなたが思っている以上に多くのSaaSアプリケーションを使用している可能性があります。ユーザが別のサービスにサインアップしたり、新しい場所にデータを保存したりすると、管理者が使用を許可されたアプリケーションの審査や承認に費やしていた時間が突然無駄になる可能性があります。本日から、Cloudflare for Teamsを使用して、わずか2クリックで未承認のSaaSアプリケーションを検出し、ブロックすることができます。」（１頁１～５行） 「増加するシャドーITの利用 SaaSアプリケーションは、IT部門の時間と予算を節約します。ツールをホストするためのサーバーにお金を払い、それらのツールを監視し、アップグレードし、トラブルシューティングするスタッフを用意する代わりに、組織はクレジットカードだけでSaaSに相当するものにサインアップすることができ、ホスティングやメンテナンスの心配をする必要はありません。 その利便性が、データ管理の問題を引き起こす。SaaSアプリケーションは、あなたが管理する環境の外に置かれています。あなたのチームにとって使いやすいという同じ理由が、あなたの機密データが第三者に保管されるという潜在的な責任にもなっているのです。ほとんどの組織は、使用されているSaaSアプリケーションを注意深く監査することで、この問題を抑えている。業界や規制の影響に応じて、IT部門は使用するアプリケーションを評価し、承認し、カタログ化する。 しかし、ユーザーは意図的または偶然にこれらの承認をバイパスすることができます。例えば、組織がOneDriveに依存しているが、ユーザーはGoogle Driveの方が使いやすい場合、そのユーザーは仕事のファイルを代わりにGoogle Driveに保存することにするかもしれない。IT部門はこのような事態を把握できず、ユーザーは問題ないと考えるかもしれません。そのユーザーは、組織内の他のユーザーとファイルを共有し始め、そのユーザーもGoogleドライブにサインアップし、突然、認可されていないアプリケーションが機密情報を保持するようになります。これが「シャドーIT」であり、このようなアプリケーションは本来、組織による統制を難読化するものです。」（１頁６行～２頁１９行） 「シャドーITの検出 Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティングし、未知のセキュリティ脅威からユーザをブロックするためのきめ細かな制御を実施します。また、お客様の環境で使用されているSaaSアプリケーションの概要を低負荷で可視化することで、お客様のチームにさらなる保証を提供します。 Gatewayをオンにするだけで、組織に対するすべてのHTTPリクエストが、監査とセキュリティ目的でGatewayアクティビティログに集約されます。アクティビティログには、ユーザー、アクション、リクエストに関する適切な情報が記録されます。これらのレコードには、アプリケーションとアプリケーションタイプに関するデータが含まれます。上記の例では、アプリケーションの種類はコラボレーションとオンラインミーティング、アプリケーションはGoogleドライブです。 そこから、GatewayはアクティビティログのHTTPリクエストを分析し、一見雑多なアプリケーションを分類し、実用的なインサイトに分類することで、シャドーITを表面化します。」（２頁２０行～３頁６行） 「シャドーITディスカバリーの導入 Shadow IT Discovery（シャドーITディスカバリー）では、まずCloudflare for Teamsが組織で使用されているすべてのアプリケーションをカタログ化します。この機能はまず「観察」モードで実行され、すべてのアプリケーションが分析されますが、デフォルトでは「未審査」となっています。 その後、チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定することができます。 これにより管理者は、ユーザーがアクセスしている承認済みアプリケーションと未承認アプリケーションの上位を簡単に追跡し、セキュリティ体制をより適切にプロファイリングできるようになります。より詳細なビューにドリルダウンすると、管理者は新たに検出された複数のアプリケーションを一度に移動する一括アクションを実行できます。このビューでは、ユーザーはアプリケーションの種類でフィルタリングして、組織内の重複を簡単に特定することもできます。 私たちが追加したかったもう一つの機能は、組織で使用されているアプリケーションがすでにCloudflare Accessによって保護されているかどうかを素早くハイライトできる機能です。この情報は「Secured（セキュリティで保護されています）」という列で確認できます。アプリケーションがAccessによってセキュア化されていない場合は、Access for SaaSを使用して今日からそのプロセスを開始できます。(今週は2つの新しいチュートリアルを追加しました。） Cloudflare for Teamsは、アプリケーションに未承認のマークを付けても、そのアプリケーションを完全にブロックするわけではありません。アプリケーションへのアクセスを完全にブロックする前に、アプリケーションに未承認のラベルを付け、ユーザーに確認する必要がある組織もあるかと思います。チームの準備が整えば、Gatewayルールを適用してアプリケーションへのアクセスをブロックすることができます。」（３頁７行～５頁５行） （４頁「（シャドーITレポート）」の画像） ［図：0001406757000001.jpg］ （２） 甲１発明 ア 上記１頁１行～５行の記載によれば、甲１には、「Cloudflare for Teamsを使用して、わずか2クリックで未承認のSaaSアプリケーションを検出し、ブロックする」方法が記載されている。 イ 上記２頁２０行～３頁６行の記載によれば、Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティングし、未知のセキュリティ脅威からユーザをブロックするためのきめ細かな制御を実施し、お客様の環境で使用されているSaaSアプリケーションの概要を低負荷で可視化することで、お客様のチームにさらなる保証を提供するものである。 ウ また、上記２頁２０行～３頁６行の記載によれば、Gatewayをオンにするだけで、組織に対するすべてのHTTPリクエストが、監査とセキュリティ目的でGatewayアクティビティログに集約され、アクティビティログには、ユーザー、アクション、リクエストに関する適切な情報が記録され、これらのレコードには、アプリケーションとアプリケーションタイプに関するデータが含まれ、GatewayはアクティビティログのHTTPリクエストを分析し、一見雑多なアプリケーションを分類し、実用的なインサイトに分類することで、シャドーITを表面化するものである。 エ 上記３頁７行～５頁５行の記載によれば、Shadow IT Discovery（シャドーITディスカバリー）では、まず「観察」モードで、Cloudflare for Teamsが組織で使用されているすべてのアプリケーションをカタログ化する機能が実行され、すべてのアプリケーションが分析されるところ、デフォルトでは「未審査」となっており、その後、チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定することができる。 オ また、上記３頁７行～５頁５行の記載によれば、Cloudflare for Teamsは、アプリケーションに未承認のマークを付けても、そのアプリケーションを完全にブロックするわけではなく、アプリケーションへのアクセスを完全にブロックする前に、アプリケーションに未承認のラベルを付け、ユーザーに確認する必要がある組織もあるから、チームの準備が整えば、Gatewayルールを適用してアプリケーションへのアクセスをブロックすることができる。 以上によれば、甲１には次の発明（以下、「甲１発明」という。）が記載されている。 ［甲１発明］ Cloudflare for Teamsを使用して、わずか2クリックで未承認のSaaSアプリケーションを検出し、ブロックする方法であって、 Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティングし、未知のセキュリティ脅威からユーザをブロックするためのきめ細かな制御を実施し、お客様の環境で使用されているSaaSアプリケーションの概要を低負荷で可視化することで、お客様のチームにさらなる保証を提供するものであり、 Gatewayをオンにするだけで、組織に対するすべてのHTTPリクエストが、監査とセキュリティ目的でGatewayアクティビティログに集約され、アクティビティログには、ユーザー、アクション、リクエストに関する適切な情報が記録され、これらのレコードには、アプリケーションとアプリケーションタイプに関するデータが含まれ、GatewayはアクティビティログのHTTPリクエストを分析し、一見雑多なアプリケーションを分類し、実用的なインサイトに分類することで、シャドーITを表面化するものであり、 Shadow IT Discovery（シャドーITディスカバリー）では、まず「観察」モードで、Cloudflare for Teamsが組織で使用されているすべてのアプリケーションをカタログ化する機能が実行され、すべてのアプリケーションが分析されるところ、デフォルトでは「未審査」となっており、その後、チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定することができ、 Cloudflare for Teamsは、アプリケーションに未承認のマークを付けても、そのアプリケーションを完全にブロックするわけではなく、アプリケーションへのアクセスを完全にブロックする前に、アプリケーションに未承認のラベルを付け、ユーザーに確認する必要がある組織もあるから、チームの準備が整えば、Gatewayルールを適用してアプリケーションへのアクセスをブロックすることができる、 方法。 ２ 甲２について 甲２には、以下の記載がある。 「ビジネスクリティカルなデータが組織から管理されていないクラウドアプリケーションに流出するシナリオを想像してみてください。あるいは、アプリのレピュテーションに基づき「ハイリスク」アプリとみなされるアプリを使用するユーザーが突然増えたとします。 どちらのシナリオでも、Microsoft Cloud App Security (MCAS)が両方のアクティビティを検出し、さらに管理者はアプリケーションへのアクセスをブロックしたり、コントロールを設定したりすることができます。」（１頁２行～５行） 「シャドーITの発見と管理 Cloud App Securityの「Cloud Discovery」機能により、企業は各クラウドアプリケーションのアプリケーションやユーザーアクティビティ、トラフィック量、典型的な利用時間を特定することができる。一言で言えば、シャドーITやリスクのあるアプリケーションを検出することができる。 余談：マイクロソフトのレポートによると、平均的な組織ではIT部門が管理していないアプリケーションが1000以上使用されている。 シャドーIT管理のライフサイクルには、次のような柱があります： フェーズ1 - 発見と特定 シャドーITの発見 アプリケーションのリスクレベルを特定する フェーズ2 - 評価と分析 コンプライアンスの評価 使用状況の分析 フェーズ3 - 管理と継続的モニタリング クラウドアプリケーションの管理 継続的モニタリング」（１頁１０行～２頁１行） 「MCASにデータが取り込まれたら、何から始めたらいいのでしょうか？という質問をよく受けますが、Cloud App Securityの「Cloud Discovery」ダッシュボードから「Cloud Discovery Executive」レポートを実行して、環境内のSaaSアプリケーションの使用状況を全体的に把握することから始めるのが1つの方法です。このレポートでは、主要な調査結果とさらなる対策のための推奨事項が強調されています。」（２頁５行～７行） 「公認／非認可／モニター アプリケーション アプリケーションが有効で、組織内で使用が許可されているか禁止されているかを決定する。管理者は、アプリケーションをどのように処理するかを決定し、アプリケーションに「認可」、「非認可」、または「監視」タグを割り当てることができます（執筆時点）。カスタムタグは、特定の監視目的、Cloud Discoveryページのフィルタリング、およびポリシーの作成に使用できます。 組織での使用が許可されていないアプリケーションは、"非認可"としてタグ付けすることができ、Microsoft Defender for EndpointとCloud App Securityの統合により、エンドポイントによってWindows 10デバイスからブロックすることができます。 このアクションは、Microsoft Defender for Endpointsや、Zscaler、iBoss、Menlo、Corrataなどの統合アプライアンスに直接伝わり、アプリへのアクセスをブロックすることができます。 アプリケーションに「認可済み」、「非認可」、「監視中」のタグが付いている場合、タグが付いていないアプリケーションをフィルタリングすることができます。これらのアプリケーションは、分析段階の後、さらなるレビューと決定が必要なアプリケーションです。」（３頁５行～１４行） 「条件付きアクセス・アプリ・コントロールによるアプリの保護 Microsoft Cloud App Securityは、あらゆるIDプロバイダ（IdP）と統合され、アクセス制御とセッション制御によって、データ漏えいやデータ盗難からリアルタイムに保護するのに役立ちます。Azure Active Directory（Azure AD）がIdPとして使用されている場合、これらの制御は統合され、Azure ADの条件付きアクセスツールに構築された、よりシンプルでカスタマイズされた展開のために合理化されます。 Conditional Access App Controlは、アクセス・ポリシーとセッション・ポリシーに基づいて、ユーザー・アプリへのアクセスとセッションをリアルタイムで監視・制御することができます。アクセスポリシーとセッションポリシーにより、以下のシナリオを実現できます： データ流出の防止 ダウンロード時の保護 ラベル付けされていないファイルのアップロードを防止 潜在的なマルウェアをブロック ユーザー・セッションのコンプライアンス監視 アクセスをブロック カスタムアクティビティのブロック」（４頁９行～２１行） ３ 甲３について 甲３には、以下の記載がある。 「ソーシャルログインは、ユーザーの利便性を提供し、脆弱なパスワードや再利用されるパスワードに関連するリスクを取り除く。ユーザーにサードパーティ製アプリへのアクセス許可を与える権限を与えることは、リスクの高いトレードオフです。ソーシャルログインの背後にあるテクノロジーを説明し、関連するリスクを特定し管理する方法を探ります。」（１頁１～３行） 「ユーザーの生活を便利にし、セキュリティリスクを減らすという点では、Win-Winの関係だ。このため、多くのIT管理者は、ユーザーが他のウェブサイトやサードパーティのSaaSアプリで「Googleでログイン」（厳密にはOpenID Connect、またはOIDC）を使用することに対して、穏便なアプローチをとっている。」（１頁１８～１９行） 「OAuthとは？ OpenID Connect (OIDC)はしばしばOAuth2と呼ばれる別のレイヤーの上に乗っています。OIDCは認証を扱い、OAuth2は認可を扱います。 わかりやすく言うと、OIDCはあなたが誰であるかを確認し、OAuth2はウェブアプリケーションに何を許可するかを伝えます。 OAuth2が実際に使われているのを、Googleの「アプリケーションXがあなたのGoogleアカウントにアクセスしたい」という画面で見たことがあるでしょう。この画面では、アプリケーションが何を許可したいのかが説明され、リスクをよく考えるよう促す小さなテキストと、「許可する」という大きな青いボタンが表示されます。」（１頁２０～２７行） 「SaaS管理ツールはG Suiteの管理にどのように役立つのでしょうか？ これは非常に便利な機能ですが、G Suiteの管理コンソールでは、どのアプリケーションがこれらの権限を要求しているかを追跡し、それぞれを調査する作業が残っています。 そこで、TrelicaのようなSaaS管理ツールが役立ちます。 TrelicaをG Suiteドメインに接続するには、数回クリックするだけです（青い「承認」OAuth2ボタンを含む）。使用中のすべてのアプリを自動的に検出し、各GoogleサービスAPI（OAuth Scope）をリスク評価することで、潜在的に危険なアクセスを強調表示します。」（４頁３～８行） 「結論 TrelicaのようなSaaS管理ソリューションとG Suiteの新しいアプリケーションブロック機能を組み合わせれば、ユーザーがシャドーITの危険なポートフォリオを構築することなく、「ソーシャルログイン」のメリットを享受することができます。管理されないままにしておくと、ユーザーが会社の情報にアクセスできる第三者を決めているという考えに慣れる必要があります。」（５頁６～９行） （５頁上段の画像） ［図：0001406757000002.jpg］ ４ 甲４について 甲４には、以下の記載がある。 「[0004]一般的な企業のITバックボーンは、従来の企業ネットワーク上ではなく、SaaS（Software as a Service）モデルを採用した1つまたは複数のクラウドリソースに存在することが多くなっています。一般的なレガシー・セキュリティ・ソリューションは、企業のファイアウォール外のリソースやデータへのアクセスをブロックまたは制限することが多く、このようなSaaSアプリケーションを効果的にサポートすることはできません。企業は機密情報をクラウドに置く必要性が高まっており、それに伴い、適切な人だけがそのような情報にアクセスできるようにする必要がある。企業は、不注意であれ悪意であれ、漏洩や盗難を防ぎたいと考えており、漏洩の防止は、データの暴露、金銭的損失、法的責任に関連するなど、非常に高いリスクを伴う可能性がある。しかし、企業のファイアウォールは、クラウドなどの外部リソースに向かうデータを保護するかもしれないが、クラウドリソースやプラットフォームなど、企業外のネットワークに展開される一般的なリソースとはうまく相互作用しない（SaaSアプリケーションのようなリソースを扱うのは特に難しいかもしれない）。例えば、ファイアウォールはアプリケーションのトランザクションを理解するのに適していないかもしれない。ファイアウォール・ソリューションや、フォワード・プロキシやリバース・プロキシなどのネットワーク・ソリューションは、転送中のデータに重点を置いているため、静止状態のデータや、そもそもファイアウォールが導入される前にクラウド・ソリューション内にあったデータ（ファイアウォールからは決して見えない可能性がある）に対してはうまく機能しない。ファイアウォール・ソリューションは通常、ユーザーのトラフィックがファイアウォールを経由することを前提としているが、多くのクラウドベースのソリューションではそうではない。また、ほとんどのクラウド環境では、アプリケーションやマシンによる重要なアクセスが行われており、場合によってはクラウド間アクセスと呼ばれることもある。そのため、ファイアウォールのようなブロッキングやフィルタリングの仕組みは、クラウド内やクラウド間のデータを保護する仕組みとして効果がない、または適用できないことが多く、そもそもデータがクラウドに行かないようにブロックするという選択肢しか残らない。」 「[0056]図42は、シャドーITレポートの一部の例を示している。」 「[0089]図75は、シャドーIT情報に関して提供可能な様々な形式のレポートを示している。」 「[0302]非アクティブアカウントのユースケースのイベントログデータには、ユーザ管理データ、ログインデータ、およびアクティビティデータが含まれる場合がある。非アクティブアカウントのユースケースの補助データには、ディレクトリデータおよび外部プロビジョニング解除情報が含まれる。非活動アカウントユースケースの時間ウィンドウは、例えば数週間である。いくつかの実施形態では、非アクティブアカウントのユースケースのためのデータエンリッチメントは必要ないかもしれない。」 「[0417]企業のユーザが使用しているすべてのアプリケーションと情報技術リソースの領域において、認可されているものと認可されていないもの、つまり「シャドー」情報技術の割合があります。今日、セキュリティ企業は、一般的に、様々なビジネスにおいて企業が使用する数千の公認アプリケーションの大部分を占める、公認アプリケーションの使用に関連する様々なリスクを低減することに重点を置いています。例えば、オンライン分析処理（OLAP）アプリケーションのカテゴリには、連絡先やドライブ上のドキュメントなど、ユーザーのアカウント内の特定のデータやサービスへのアクセスをユーザーがクラウド上のOLAPアプリケーションなどに許可するアプリケーションも多く含まれています。平均的な企業のユーザーは、何百、時には何千もの異なる認可されていないアプリケーションにアクセスする可能性があり、何百万もの認可されていないインストールが存在します。これらの多くは、信頼できないベンダー、企業やユーザーのデータへの過剰なアクセス、不適切なアプリケーションを含んでいます。このような種類のシャドーアプリケーションは、企業ネットワークから外れた場所で、無人で動作します。このような場合、企業のデータとリソースのセキュリティは、クラウドアプリケーションのセキュリティと同程度にしか保てません。このようなアプリケーションのセキュリティの脆弱性を悪用した攻撃は数多く報告されている。一方、企業はユーザーがアプリケーションを使用していることすら知らないかもしれない。したがって、シャドーITの利用を発見し、必要に応じてその利用をブロックする必要がある。シャドーITを発見することで、企業はユーザーを教育し、特定のポリシーとコントロールの下でアプリケーションを制裁することもできる。」 「[0418]本開示は、本開示の他の箇所で説明するように、クラウドなど他の場所で使用されるアプリケーションにこれらの機能を提供することに加えて、企業ネットワークなどユーザのネットワーク上でアプリケーションの検出、監視、および制御を可能にするCSF100の機能に関する。本明細書で開示する方法およびシステムには、アプリケーションが企業ネットワーク上にある状況、アプリケーションがクラウド内またはクラウド間で相互作用する状況、アプリケーションがネットワーク上およびクラウド内のアクティビティを含む状況など、アプリケーションがどのようにデプロイされ、どこで動作するかに関する広範なシナリオに対して、統一された可視性、監視および制御を提供するCSF100の機能が含まれる。CSF100のこの統合された監視および制御機能は、本開示では、「統合アプリケーション・ファイアウォール」、「統合AFW」、「AFWプラットフォーム」、または単にAFW300と呼ばれる。実施形態では、統合AFWは、アプリケーション・ファイアウォール・サービス148など、CSF100の1つまたは複数のサービスから構成される場合がある。」 「[0419]他の利点の中でも、本明細書で説明する方法とシステムは、シャドーITを含め、ユーザが使用しているITリソースを可視化したいという企業のニーズに対応する。統合されたAFWの方法とシステムによって、企業は、（クラウドと企業のネットワーク上で）どのようなアプリケーションと他のリソースが使用されているかを知ることができ、特定のアプリケーションを制裁する機会を特定し、そのようなアプリケーションの使用を統合し、そのようなアプリケーションのポリシーと使用を管理し、リスクのあるアプリケーションまたはアプリケーション内またはアプリケーションを使用したリスクのある活動をブロックすることができる。」 「[0420]特に、異なる環境および異なるプラットフォームで企業が使用するさまざまなアプリケーションにわたって統一されたビューを提供することにより、CSF100を使用すると、企業が使用する「シャドーIT」の迅速な評価レポートを作成できる。また、CSF100のAFW機能により、ファイルのアップロードやダウンロードなど、特定のアプリケーションおよび／またはアプリケーションの特定の操作の使用をブロックすることができる。」 「[0421]図27に見られるように、EvernoteTM 2702などのアプリケーションは、企業ユーザー2704によってアクセスされる場合があります。ユーザー2704は、ファイアウォール2708の向こう側などの企業ネットワーク2706上にいることがあり、場合によっては、アクセスにプロキシサーバー2710が関与することがある。企業は、企業ネットワーク上で発生するファイルアップロードやダウンロードなどのアプリケーションアクセスや使用イベントを追跡し、それらのイベントをSIEM2712に中継することができる。場合によっては、ユーザ2704は、クラウド2714を介してアプリケーション2702にアクセスすることができ、これはさまざまなAPI2718を介して発生することがある。クラウド2714がファイアウォール2708を介してアクセスされる場合、企業は、アプリケーション2702へのアクセスに関する情報を記録する様々なログ2720を有する可能性があり、ログ2720はSIEM2712の情報源を提供する可能性がある。API2718およびログ2720は、本開示全体を通じて説明するさまざまな機能に従ってデータを収集するCSF100の情報源となる場合もある。場合によっては、ユーザ2704は、管理されたエンタープライズ・ネットワーク2706上にないデバイスからアプリケーション2702にアクセスすることがあり、アプリケーションおよび関連するトラフィックがそのネットワークを通過しなかったため、エンタープライズが、エンタープライズの管理されたネットワーク上の使用状況の追跡に関連する同じAPI2718およびログ2720を介して、完全な使用情報にアクセスできないことがある。これは、ホームコンピュータ、ラップトップまたはモバイルデバイス上のブラウザを介して、または何らかの他の設備2722を介して発生する可能性があり、ユーザによって行われる可能性があり、または（モノのインターネット（IoT）デバイスなどの）プログラムまたは機械によって行われる可能性がある。これらのタイプのアクセスに関する情報は、クラウドプラットフォーム2714内の追跡設備、クラウド2714を介さずにアプリケーションを実現するPaaS／IaaS設備、モバイルデバイス管理設備、コンテンツ配信ネットワーク（CDN）、ID管理システム、シングルサインオンシステム（SSO）など、デバイスアクセスを処理する他の設備で追跡されてもよく、これらの設備はそれぞれ、そのサービスの1つ以上に情報を供給することによって、または本開示全体を通じて説明される様々な実施形態に従ってCSF100が検査することができるAPIを有することによって、CSF100に情報を提供することができる。さらに、クラウドSWGTMまたはクラウドDNSサービスなどのクラウドサービスは、ネットワークまたはデバイスの一部で発生するトラフィックをミラーリングするポートを提供するなどして、要求されたデータのストリームを提供することができる。このように、ユーザ2704によるアプリケーション2702の使用状況の統一されたビューを提供するためには、単にログ2720を見ることによって、または単にクラウド2714内のアクティビティだけを見ることによって得られる以上のことを知る必要がある。」 「[0422]図28を参照すると、プロセス2800は、企業のユーザが使用する各アプリケーションの使用状況、ひいてはアプリケーションのコレクション全体の統一されたビューの開発を可能にする一連のステップを含む場合がある。ステップ2802で、CSF100は、ログ2720、API2718、SIEM2712からのイベントの公開、クラウド2714内のサーバ、およびアプリケーションへのアクセスまたはアプリケーションの使用を可能にするか報告するさまざまな設備の他のAPI、ログ、追跡システムなどからのさまざまなイベントの収集を可能にすることができる。これには、httpメッセージなど、さまざまな形式のメッセージを収集し、フォーマットすることが含まれる。ステップ2804で、CSF100は収集された情報のフィルタリングを有効にすることができる。たとえば、企業は、広告ネットワークからの広告など、いくつかの種類のリソースに関する使用状況の追跡に関心がない場合があり、広告ネットワークの既知の宛先をフィルタリングすることができる。実施形態において、プロセス2800は、オプションとして、API、ログまたはトラッキングシステムなどからのいくつかのコンテンツを難読化、トークン化、および／または暗号化する能力を可能にし、データがクリアテキスト以外の形式で保存されるようにすることができる。」 「[0545]図60は、CSF 100とともに使用されるカスタム・アプリケーションのプラットフォームを構成するために使用されるユーザ・インタフェース6002を示す。図60を参照すると、ユーザ・インターフェース6002は、プラットフォームの選択、表示名、アイデンティティおよびアクセス管理（「IAM」）の役割、アプリケーション・リソース識別子（「ARN」）、スキャンするCloudTrailTMバケット、スキャンするS3バケット、S3ロギング・バケット、外部ID、ASWセットアップ指示、ならびにキャンセルおよび承認機能を含むように、CSF100と共に使用され得るカスタム・アプリケーションのプラットフォームを構成するために使用され得る。」 「[0597]本明細書で説明する方法およびシステムは、全体的または部分的に、プロセッサ上でコンピュータソフトウェア、プログラムコード、および／または命令を実行する1つまたは複数のマシンを含むコンピューティングプラットフォーム上で展開することができる。」 （図４２） ［図：0001406757000003.jpg］ （図６０） ［図：0001406757000004.jpg］ （図７５） ［図：0001406757000005.jpg］ ５ 甲５について 甲５には、以下の記載がある。 「[0001]本発明は、一般にコンピュータおよび類似技術の分野に関し、特にこの分野で利用されるソフトウェアに関する。さらに詳しくは、クラウドベースのサービスの非承認使用に関連するリスクを管理するための方法、システム、およびコンピュータで使用可能な媒体に関する。」 「[0005]クラウドベースのサービスの非認証利用に関連するリスクを管理するための方法、システム、およびコンピュータ使用可能媒体が開示される。特定の実施形態において、本発明は、エンドポイントデバイスを介して開始されるインタラクションを監視することと、インタラクションがクラウドサービス要求を含んでいる場合に、クラウドサービス要求がクラウドサービスにアクセスするユーザによる要求を含んでいることを判定することと、クラウドサービスにアクセスする要求が検出された場合に、ユーザとクラウドサービスとの間のインタラクションを監視することと、ユーザとクラウドサービスとの間のインタラクションがクラウドサービスの非認可の使用を表しているか否かを判定することと、クラウドサービスの非認可の使用に関連するリスクを管理することと、を含む、シャドー情報技術検出動作を実行するための方法、システムおよびコンピュータ使用可能媒体に関する。」 「[0012]クラウドベースのサービスの非承認使用に関連するリスクを管理するための方法、システム、およびコンピュータ使用可能媒体が開示されている。本発明のある側面は、組織内部で特定の情報技術（IT）システムおよびサービスを明示的な組織の承認なしに実装および使用すると、関連するリスクが発生する可能性があるという認識を反映したものである。同様に、本発明のある側面は、そのような「シャドーIT」または「ステルスIT」活動が、組織のIT部門の明示的な知識なしに開発、実装、および使用されるシステム、サービス、およびデータを指す場合があるという認識を反映している。本発明のある側面は、同様に、シャドーITまたはシャドーIT活動が、認可されていない目的のための様々なシステム、サービス、データの認可された使用を含む可能性があるという認識を反映している。」 「[0013]本発明のある側面は、プロキシトラフィックログの分析が、しばしばSaaS（Software as a Service）と呼ばれるクラウドベースのソフトウェアサービスへのアクセスを検出するための既知のアプローチの1つであるという認識を反映している。特に、特定の既知のクラウド・アクセス・セキュリティ・ブローカー（CASB）アプローチは、プロキシ・トラフィック・ログを処理して、どのユーザーがどの時間にどのクラウドベースのサービスにアクセスしたかを示すレポートを生成する。同様に、本発明のある側面は、そのようなCASBアプローチが、セキュリティ、管理、またはその両方を提供するために実装され得るという理解を反映している。」 「[0017]本開示の目的上、情報ハンドリングシステムは、ビジネス、科学、制御、または他の目的のために、任意の形態の情報、インテリジェンス、またはデータを計算、分類、処理、送信、受信、取得、発信、切替、保存、表示、明示、検出、記録、再生、取扱、または利用するように動作可能な任意の機器または機器の集合体を含み得る。例えば、情報ハンドリングシステムは、パーソナルコンピュータ、タブレットやスマートフォンなどのモバイルデバイス、接続された「スマートデバイス」、ネットワークアプライアンス、ネットワークストレージデバイス、または任意の他の適切なデバイスであってよく、サイズ、形状、性能、機能性、および価格は様々であってよい。情報ハンドリングシステムは、ランダムアクセスメモリ（RAM）、中央処理装置（CPU）またはハードウェアもしくはソフトウェア制御ロジックなどの1つまたは複数の処理リソース、ROM、および／または他のタイプの不揮発性メモリを含み得る。情報ハンドリングシステムの追加の構成要素は、1つ以上のストレージシステム、外部と通信するための1つ以上のネットワークポート、ならびにキーボード、マウス、およびグラフィックディスプレイなどの様々な入出力（I／O）デバイスを含み得る。」 「[0018]図1は、本発明のシステムおよび方法を実施するために使用することができる情報ハンドリングシステム100の一般化された説明図である。情報ハンドリングシステム100は、プロセッサ（例えば、中央プロセッサユニットまたは「CPU」）102、ディスプレイ、キーボード、マウス、および関連コントローラなどの入出力（I／O）デバイス104、ストレージシステム106、および様々な他のサブシステム108を含む。様々な実施形態において、情報ハンドリングシステム100は、同様にサービスプロバイダサーバ142によってアクセス可能なネットワーク140に接続するように動作可能なネットワークポート110も含む。情報ハンドリングシステム100は、同様に、1つまたは複数のバス114を介して前記に相互接続されるシステムメモリ112を含む。システムメモリ112は、オペレーティングシステム（OS）116をさらに含み、様々な実施形態では、シャドウIT発見システム118も含み得る。一実施形態では、情報ハンドリングシステム100は、サービスプロバイダサーバ142からシャドーIT発見システム118をダウンロードすることができる。別の実施形態では、シャドーIT発見システム118は、サービスプロバイダサーバ142からサービスとして提供される。」 「[0027]特定の実施形態において、シャドーIT発見オペレーションは、特定のクラウドサービス216へのアクセスに関連するサイバー行動の検出を含み得る。特定の実施形態において、サイバー行動は、クラウドサービス216へのアクセスに関連する様々なサイバー行動要因を含み得る。特定の実施形態において、サイバー振る舞い要因は、ユーザに関連する識別または認証要因、ユーザの役割またはアクセス権、ユーザに関連する他の情報、またはそれらの組み合わせを含み得る。一例として、そのようなサイバー行動要因は、ユーザのログイン情報（例えば、UserIDおよびパスワード）、ユーザに関連する認証情報（例えば、秘密鍵および公開鍵、デジタル証明書など）、ユーザの役割（例えば、販売管理者）、ユーザに関連するアクセス権（例えば、販売予測）を含み得る。」 「[0028]特定の実施形態では、サイバー行動は、同様に、ユーザが特定のクラウドサービス216に対してHTTPリクエストを送信することに関連する情報を含み得る。前の例を続けると、そのような情報は、同様に、ユーザのインタラクション（例えば、クラウドサービス216への内部販売データのアップロード）、そのようなインタラクションの日付、時間、および頻度、ならびにユーザの位置に関連するデータを含むことができる。当業者であれば、このような多くの実施形態および例が可能であることを認識するであろう。したがって、上記は、本発明の精神、範囲または趣旨を限定することを意図するものではない。」 「[0035]図3は、本発明の実施形態に従って実装されるシャドーIT発見環境の動作の簡略化されたブロック図である。特定の実施形態では、シャドーIT発見システム118は、本明細書でより詳細に説明するように、クラウドサービス216の非承認使用に関連するリスクを管理するために実装され得る。特定の実施形態では、シャドーIT発見システム118は、ネットワークエッジデバイス320上に実装され得る。特定の実施形態では、シャドーIT発見システム118は、同様にネットワークエッジデバイス320上に実装されるウェブプロキシ322と組み合わせて実装され得る。」 「[0036]プロキシサーバーは、他のサーバーからのリソースを求めるクライアントデバイスからのリクエストの仲介を行うために、特別な情報ハンドリングシステムとして、またはソフトウェアアプリケーションとして実装することができる。一般的に、クライアントデバイスはまずプロキシサーバーとの通信を確立する。通信が確立されると、ユーザーは、アプリケーション、ファイル、接続、Webページ、または他のサーバーから利用可能な他のリソースなどの特定のサービスを要求することができる。これに対して、プロキシサーバーはリクエストを評価し、その複雑さを簡略化、管理、または抑制できるかどうかを決定する。このような評価が完了すると、プロキシサーバーはリクエストをターゲットサーバーに転送(forward)する。当業者であれば同様に、プロキシサーバーが開発された理由の一つが、分散システムに構造とカプセル化を追加するためであったことを理解するであろう。今日、多くのプロキシサーバーはWebプロキシ322として構成され、匿名性の提供、IPアドレスのブロッキングの回避、またはその2つの組み合わせによって、Webベースのコンテンツへのアクセスを容易にする。」 「[0037]特定の実施形態では、ネットワークエッジデバイス320は、ブリッジ、ファイアウォール、またはパッシブ監視構成で実装されてもよい。特定の実施形態では、エッジデバイス320は、情報処理システム上で実行されるソフトウェアとして実装されてもよい。特定の実施形態において、ネットワークエッジデバイス320は、統合されたロギング、更新および制御を提供するように実装されてもよい。特定の実施形態において、統合されたロギング、更新および制御は、ウェブ・プロキシ・トラフィック・ログ324のリポジトリを管理するために使用される。特定の実施形態において、エッジデバイス320は、本明細書でより詳細に説明されるエンリッチされたサイバー動作情報326の形態で、ネットワーク要求およびコンテキストセンシティブなユーザ動作情報を、同様に本明細書でより詳細に説明されるエンドポイントエージェント206から受信するように実装され得る。」 「[0050]特定の実施形態では、シャドーIT発見システム118は、クラウドサービス要求の検出を含む様々なシャドーIT発見動作を実行するように実装される。特定の実施形態において、シャドーIT発見操作は、ユーザ402、プロセス、デバイス、システム、またはそれらの組み合わせによって実行されてもよい。特定の実施形態において、シャドーIT発見システム118は、様々なクラウドサービスリクエストを識別するために、特定のウェブプロキシトラフィックログ452のシャドーIT発見スキャンを実行するように実装されてもよい。特定の実施形態において、シャドーIT発見スキャンは、クラウドサービス要求とユーザの関連するサイバー行動との比較を含み得る。特定の実施形態において、クラウドサービス要求の比較、およびユーザの関連するサイバー行動は、セキュリティ分析418システムによって実行されてもよい。」 （図１） ［図：0001406757000006.jpg］ （図３） ［図：0001406757000007.jpg］ ６ 甲６について 甲６には、以下の記載がある。 「[0006]クラウドベースのSaaS（Software-as-a-Service）の進化に伴い、組織の従業員は、一元管理されることなく、さらには組織に知られることなく、クラウド・ソリューションを採用するようになっている。このような行動は「シャドーIT」と呼ばれ、特にデータ・ストレージ、データ・アプリケーション、メッセージング・サービスを含むデータ・サービスに、組織の情報技術（IT）プロセス、管理、承認をバイパスして、ユーザーが独自のイニシアティブでサインアップすることで発生する。シャドーITに関する背景情報は、https://en.wikipedia.org/wiki/Shadow_IT。」 「[0011]本発明の実施形態は、クラウド／SaaS環境を発見し監視する堅牢な発見および監視システムおよび方法を提供する。」 「[0012]したがって、本発明の一実施形態に従って、企業に属するユーザーとクラウドサービスとの間の通信を提供する企業のメッセージングサービスを監視し、特定のクラウドサービスに関連するメッセージを発見するメッセージモニターと、メッセージモニターによって発見されたメッセージを分析して、（i）特定のクラウドサービスの性質、および（ii）特定のクラウドサービスを使用する1人または複数の企業ユーザーを決定するメッセージアナライザーと、メッセージアナライザーの結果を企業の管理者に報告する報告者とを含む、シャドーIT発見のためのシステムが提供される。」 「[0020]本発明の実施形態に従って、特に組織の従業員、代理人、請負業者を含む人々が使用するクラウドサービスを発見し、監視するためのシステムおよび方法が提供される。」 「[0023]図2はまた、メッセージ152、153および154を有する電子メールシステムなどのエンタープライズメッセージングシステム150と、メッセージモニタ310、メッセージアナライザ320およびレポーター330を含むシャドウIT発見システム300とを示す。シャドーIT発見システム300は、アプリケーションプログラミングインターフェース（API）および／またはネットワークプロトコルを介して、エンタープライズメッセージングシステム150に接続する。」 「[0024]メッセージ・モニター310、メッセージ・アナライザー320、レポーター330は、コンピューター・プロセッサーのプログラム制御下にあるソフトウェア・モジュールまたはハードウェア・モジュールであってもよい。」 「[0025]メッセージ・モニタ310は、クラウド・サービスを示すメッセージを監視する。このため、ユーザがセールスフォース・ドットコムなどのサービスの利用を開始すると、ユーザはまずサービスに登録し、サービスからユーザの電子メールアドレスを認証する電子メールを受信し、任意でユーザをサービスに歓迎するメッセージを送信する。クラウドサービスで特定のイベントが発生すると、ユーザはそのイベントについて通知する電子メールを受け取る。メッセージ・モニター310は、このようなメッセージが存在するかどうか、エンタープライズ・メッセージ・システム150をモニターする。」 「[0026]メッセージ・モニタ310がこのようなメッセージを発見すると、メッセージはメッセージ・アナライザ320に転送され、メッセージ・アナライザ320は、特にメタデータ、件名、コンテンツ、リンク、ヘッダ、メッセージ宛先、および添付ファイルを含むプロパティに基づいてメッセージを分析する。メッセージアナライザ320はまた、パターンマッチングアルゴリズムを適用して、特にクラウドサービスへの加入とクラウドサービスの使用を示すパターンの存在についてメッセージを分析する。メッセージ自体およびそのメタデータのこのような詳細な検査により、利用のタイプが明らかになり、サインアップ日、ファーストユーザー発見、最近の利用を含む、きめ細かなシャドーITディスカバリーが可能になる。」 「[0027]メッセージアナライザ320はさらに、特に（i）ユーザUがクラウドサービスの管理者権限を持っているかどうか、（ii）ユーザUによる利用が有料サブスクリプションまたはトライアルサブスクリプション経由であるかどうか、（iii）サービス5の利用においてユーザUと協働する外部ユーザの存在、（iv）クラウドサービスSを採用した組織の最初のユーザ（「ユーザゼロ」）、（v）クラウドサービスSが最初に採用された時期、および（vi）サービスSの直近の利用を含む追加情報を決定することができる。(v）クラウドサービスSが最初に採用された時期、及び（vi）サービスSの直近の利用（複数可）。メッセージ解析器320は、サービス5の利用内容、及びこの利用内容に協力している人々を特定する。例えば、メッセージアナライザ320は、salesforce.comからの電子メールメッセージが顧客から受信されたこと、ユーザーUがsalesforce.comを使用していること、salesforce.comからのファイルが別のユーザーVと共有されていることを特定することができる。」 （図２） ［図：0001406757000008.jpg］ ７ 甲７について 甲７には、以下の記載がある。 「【０００６】 ＳＷを保守して更新する責任は、ＳＷベンダーに移行する。ベンダーは、自社のＳＷを実行しているサーバも管理し、その結果、企業ＩＴ管理の責任は、社内ユーザが、接続先の円滑な作業およびデバイスを保証するのに十分なリモートサーバへの接続性を有するようにすることだけに軽減される。ＳＷはサービスとして販売される（ＳａａＳ－Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：最も一般的なモデルは月極めサブスクリプションである。」 「【０００９】 現在のサービス－デバイスのパラダイムはもはや、ＩＴ世界を効率的に説明してないが、それはユーザが異なるデバイスを通じてアプリケーションにアクセスするという事実を無視するからであり、また実際の使用の重要性を無視することに起因している。したがって、ＩＴマネージャが会社またはその他の組織にわたりＳａａＳ使用を容易に測定および分析することができるシステムおよび／または方法を有することが有益であろう。」 「【００１３】 本発明の実施形態は、クラウドアプリケーションによって導入されるさまざまな認証メカニズムをサポートするためのユニバーサルメカニズムと、ＩＴ関係者がクラウドアプリケーションのサブスクリプションを管理して、アプリケーションをプロビジョンまたはプロビジョン解除するための環境および便利なツールと、デバイス独立の使用追跡と、ロケーション独立の使用追跡と、開発ツールと、さまざまなクラウドアプリケーションベンダーとのＳＯＡおよびオープンソース統合スクリプトとを含む特徴を提供する。」 「【００２８】 図３は、本発明の実施形態によるシステム３１０を示し、図３において説明される要素は、図２を参照して上記で説明されている要素と同一であってもよいか、またはこれらの要素と類似する方法で機能することができる。システム３１０は、収集モジュールとしての役割を果たすアプリケーションアダプタ３２０と、記憶モジュール３３０のようなメモリデバイスと、処理モジュール（プロセッサ）３４０とを含む。後段においてさらに詳細に説明されるように、アダプタ３２０は、エンドユーザによって採用されたクライアントデバイス３６０のセット、および／または１つまたは複数のサーバ３８０を含むネットワークでホスティングされた複数のソフトウェアアプリケーション３７０（たとえば、ＳａａＳアプリケーション）と対話するように構成される。実施形態において、アダプタ３２０は、ターゲットとなるアプリケーション３７０によって固有のオブジェクトタイプに適用され得る操作のオブジェクトモデルを認識するかまたは発見するように構成され得るアプリケーション固有のコンポーネントである。加えて、アダプタ３２０は、アプリケーション３７０の固有のオブジェクト言語を実施形態により汎用モデルに変換するように構成される。」 「【００３４】 上記で示され説明される実施形態は、複数のＳａａＳアプリケーション３７０から多種多様な使用統計を収集するように構成される。上記で示されるように、これらの統計は、アプリケーションとの直接通信、アプリケーションＲＥＳＴ ＡＰＩまたはアプリケーションプラグイン、ネットワークトラフィックを監視するエージェント、システムログ、アプリケーションログ、ネットワークログ、ＶＰＮログ、ファイアウォールログ、ネットワークプロキシサービス、アプリケーション－ユーザ電子メール、および／または会社の課金システムを介して、ＳａａＳアプリケーション自体からもたらされ得る。 【００３５】 収集された使用統計は、各アプリケーション３７０ごとに一意であってもよく、以下のような項目を含むことができる。 【００３６】 １． ログインの数 ２． 前回ログイン以降の時間 ３． 合計アプリケーション使用時間 ４． アプリケーションオブジェクトが読み取られた回数 ５． アプリケーションオブジェクトが書き込まれたか変更された回数 ６． 送信／受信されたバイトの数 ７． 送信／受信されたパケットの数 ８． 作成されたアプリケーションオブジェクトの数 ９． アプリケーション使用に関連したポインタ「クリック」の回数 収集の複数の方法は、１つまたは複数の実施形態が、さまざまなクライアントデバイス３６０にわたり、および／またはＳａａＳベンダーのログとの統合を通じてデータを取り込み、固有のユーザに関連付けることができるようにし、その結果デバイスおよびロケーションから独立した使用統計をもたらすことができる。」 「【００３９】 さまざまな使用分析が、アプリケーション３７０に対して以下のように計算されてもよい。 【００４０】 １． 個別アプリケーションベース ２． 複数アプリケーションにわたる組合せ、および／または ３． 会社部門または事業単位にわたる組合せ これらの使用分析は、プロセッサ３４０によって（予め定められた時間期間および／または固有の時間期間を含む）時間の経過に伴って計算および／または監視されてもよく、使用傾向分析を可能にする。各アプリケーションの使用メトリックは、アプリケーション３７０に関連する収集された統計に基づいて計算されてもよい。この使用メトリックは、各アプリケーション３７０ごとに異なっていてもよい。」 「【００６０】 計算アルゴリズム 以下に示すのは、実施形態による、アプリケーション／アプリケーション担当者ごとの使用インデックおよびアクティビティレベルを計算するための可能なアルゴリズムの１つである。 【００６１】 １． 予想される基準を日次（Ｄａｉｌｙ）表現に正規化することによってＤａｙＣｒｉｔｅｒｉｏｎを計算する。たとえば、 １日１回＝１ 週１回＝１／ＮｏＯｆＷｏｒｋＤａｙｓａＷｅｅｋ＝０．２ 週２回＝２／ＮｏＯｆＷｏｒｋＤａｙｓａＷｅｅｋ＝０．４ 注：実施形態により就業日のみが考慮に入れられる。 【００６２】 ２． ユーザのＤａｙＬｏｇｎｉｓ－１日に正規化されたログインの数を計算する。 【００６３】 ＤａｙＬｏｇｉｎｓ＝ＮｏＯｆＬｏｇｉｎｓＩｎＰｅｒｉｏｄ／ＮｏＯｆＷｏｒｋＤａ ｙｓＩｎＰｅｒｉｏｄ（以下のＤａｙＬｏｇｉｎｓの計算も参照） ３． ユーザインデックスは、以下のように計算される。 【００６４】 ＵｓａｇｅＩｎｄｅｘ＝ＤａｙＬｏｇｉｎｓ／ＤａｙＣｒｉｔｅｒｉｏｎ＊１００％ ４． アクティビティレベルは、以下のものと等しい。 【００６５】 ａ． 高利用率 － ＵｓａｇｅＩｎｄｅｘ＞７５％である場合 ｂ． 中利用率 － ２５％＞＝ＵｓａｇｅＩｎｄｅｘ＝＜７５％である場合 ｃ． 低利用率 － ＵｓａｇｅＩｎｄｅｘ＜２５％である場合 ＮｏＯｆＬｏｇｉｎＩｎＰｅｒｉｏｄは、すべての日－就業および非就業についてシステムログから引き出される。１日内の複数のログインは、「１」で表されるものとする。」 「【００７３】 実施形態において、顧客（つまり、エンドユーザ３６０が構成要素である組織）は、各自の詳細な使用分析にアクセスすることができる。実施形態は、組織および／または対組織または組織のグループにわたるベンチマーキング、および顧客のターゲットとなる使用目標を提供することができる。実施形態は、たとえば部門、拠点、事業単位への社内ＳａａＳアプリケーション予算割り振りを顧客に提供するために、この情報を、ＳａａＳライセンス価格設定と組み合わせることができる。」 「【００７５】 どのＳａａＳアプリケーションが使用中であるかをカタログ作成する アプリケーションが、全体的およびバーティカルマーケットにおいて、その競合アプリケーションに対してどのようなにランクを占めるかを決定する ＳａａＳアプリケーション使用に関して「業界ベストプラクティス」を定量化する 顧客に、その相対的業界ランキングおよび改善のための提案を提供する 企業にわたり固有の機能に対する好ましいアプリケーションを示す 企業によるパフォーマンスレベルを比較するため、および／または監査の目的で、基準として使用されるように、固有のアプリケーションまたはアプリケーションのクラスに対して集約された使用データをマーケティングおよび販売する 会社に知られていないＳａａＳアプリケーションまたは使用を発見する 実施形態は、未知の（または既知でもある）各アプリケーション３７０の既存のユーザが誰であるかを識別する目的で、誰がアプリケーションを使用しているかを決定することができる。そのような機能は、各アプリケーション３７０ごとにいくつのユーザ３６０があるか、およびそれらの使用量に関する情報を提供することができる。 【００７６】 本明細書において上記で示されるように、１つまたは複数の実施形態により、この機能を達成するための方法は、以下のようなものであってもよい。 【００７７】 １． ネットワークトラフィックを検査すること、実施形態は、会社の公認ライセンシングになかったユーザ、たとえばクレジットカードを使用して個別にライセンスを購入した従業員を「発見」することができる。」 「【００８７】 実施形態は、固有のベンダーによって送信された納品伝票を認識することができる。出力は、組織にサービスを提供するＳａａＳベンダーからのものであると実施形態が認識するすべてのそれらの納品伝票のリストであってもよい。実施形態は、合計支払い金額および納品伝票発行日のような納品伝票の内容から、少なくとも一部の最小の情報を抽出することができる。」 「【００９４】 実施形態は、ＳａａＳアプリケーションの価格設定モデルを収集して記憶することができる。この情報は、公的に使用可能なソース、および顧客ライセンシングデータからの匿名扱いの情報を含む複数のソースからもたらされる。次いで、実施形態は、それらのＳａａＳ価格設定モデルと、それらが顧客の配備にどのように影響を及ぼすかに関するさまざまな分析を提供することができる。２つの例は、使用に基づく会社のアプリケーションの最適コストを計算することと、同じカテゴリの複数のアプリケーションの最適コストを計算すること（たとえば、使用可能なライセンシングおよび会社全体にわたる使用のタイプに基づいて３つの異なるＳａａＳ記憶アプリケーション３７０の最適な配備を会社に示すこと）とを含む。」 「【００９６】 実施形態は、ＳａａＳアプリケーション３７０の従業員ライフサイクル管理を提供することができる。実施形態は、会社における従業員の状況を、それらのＳａａＳプロビジョニングおよび使用を介して監視することができる。実施形態は、たとえば、従業員が１つまたは複数のアプリケーション３７０でプロビジョン解除される場合、従業員が退社したので他のアプリケーションでプロビジョン解除される必要はないという合図となり得るので、レポートおよびアラートを提供することができてもよい。」 ８ 甲８について 甲８には、以下の記載がある。 「OAuthトークンの監査ログ サードパーティアプリケーションの使用状況とデータアクセスリクエストの追跡組織の管理者として、OAuth Token監査ログを使用して、ドメイン内でどのユーザーがどのサードパーティのモバイルまたはWebアプリケーションを使用しているかを追跡できます。例えば、ユーザーがGoogle Workspace Marketplaceアプリを開くと、ログにはアプリ名と使用者が記録されます。」（１頁１～５行） 「ログには、Googleコンタクト、カレンダー、ドライブファイル（Google Workspaceのみ）など、サードパーティアプリケーションがGoogleアカウント データへのアクセスを許可されるたびに記録されます。」（１頁６～７行） 「OAuthトークンの監査ログを開く 1.Google管理コンソールにログインします。 管理者アカウント（@gmail.comで終わらない）を使用してログインします。 2.管理コンソールのホーム ページから [レポート]に移動します。 3.左側の「監査ログ」の下にある「トークン」をクリックします。 4.(オプション）表示するデータをカスタマイズするには、右側の「列の管理」をクリックします。表示または非表示にする列を選択し、[保存]をクリックします。 5.(オプション)ログ・データのフィルタリングとエクスポート、およびアラートの作成方法を確認します。」（１頁８～１５行） 「閲覧可能なデータ 管理コンソールは、OAuth トークンの監査ログを以下のユーザーデータに基づいて作成します。」（１頁１６～１７行） （１頁１８～３４行の表） ［図：0001406757000009.jpg］ ９ 甲９について 甲９には、以下の記載がある。 「【０００２】 企業などの組織では組織内の利用者によるクラウドサービスの利用を管理することが求められている。組織のイントラネットと外部のインターネットとの間にはプロキシサーバなど接続制御を行うサーバが置かれる。サーバでは利用者によるクラウドサービスの利用のログを取得している（特許文献１参照）。組織内の利用者によるクラウドサービスの利用を管理するためにこのログを利用するのが一般的である。例えば、情報セキュリティ管理者がログを確認するという方法が採られている。」 「【０００６】 本開示のひとつの目的は、利用者によるクラウドサービスの利用を管理するための技術を提供することである。」 「【００１２】 企業などの組織に属し、外部のクラウドサービスを業務に利用する者（以下「利用者」という）は、一般的に、組織の情報セキュリティ管理者に対して、クラウドサービスの利用申請を行い、正規に利用許可を得た後、クラウドサービスを利用する。以下、クラウドサービスの利用許可を正規に得た利用者を「正規利用者」という。」 １０ 甲１０について 甲１０には、以下の記載がある。 「【０００２】 ネットワーク上で提供されるサービス（クラウドサービス等）の利用形態の一つとして、ユーザが一つの中継装置を介して複数のサービスに接続可能とすることでユーザの利便性を高めるものがある。 【０００３】 特許文献１には、ユーザが複数のクラウドサーバのそれぞれについて保有するアカウントを示すアカウント情報を管理し、ユーザがログインしたときに、複数のクラウドサーバのそれぞれからユーザによる利用の状況を示す利用情報を取得し、利用情報によって示されるユーザによる複数のクラウドサーバのそれぞれの利用の状況を、当該ユーザがログインに際して操作した機器に備わるディスプレイに一覧表示させる情報システムが開示されている。」 「【０００９】 本発明は、ユーザによる複数の外部サービスへの接続を一元管理する中継装置において、自発的に外部サービスの状態を確認してユーザに通知し、ユーザの利便性の向上を図ることを目的とする。」 「【００３３】 また、通知部１８０は、端末装置２００から受け付けたリクエストの対象である外部サービス３００が利用できない状態である場合に、そのリクエストに対する応答として、外部サービス３００が利用できないことを示す通知を行っても良い。さらに、利用できない外部サービス３００の代替となり得る機能を有する外部サービス３００（以下、代替サービス）が存在する場合、端末装置２００に代替サービスへのリクエストを提示する通知や、代替サービスの利用を促す通知を行うようにしても良い。リクエスト制御部１７０および通知部１８０は、状態通知手段の一例である。」 第５ 当審の判断 １ 理由１（新規性）について （１） 本件発明１について ア 甲１発明に基づく検討 （ア） 対比 ａ 構成要件１Ａ及び１Ｆについて 甲１発明は、「SaaSアプリケーションの概要を低負荷で可視化する」ものであるところ、「SaaSアプリケーション」は、コンピュータで利用されるものであり、「サービス」ということもできる。 また、甲１発明の方法において、「Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティング」しているから、甲１発明は、通信ネットワークを介して通信を行うものである。 そして、甲１発明の「Cloudflare for Teamsを使用して、わずか2クリックで未承認のSaaSアプリケーションを検出し、ブロックする方法」は、アプリケーションを分析したり、アプリケーションへのアクセスをブロックしたりするものであって、情報を処理しているといえるから、情報処理方法であるといえる。 そうすると、甲１発明は、本件発明１と同様、「コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法」であるということができる。 ｂ 構成要件１Ｂについて 後記ｃ及びｄのとおり、甲１発明は、構成要件１Ｃ及び１Ｄのステップを含んでいるということができる。 ｃ 構成要件１Ｃについて 上記ａのとおり、甲１発明は、「SaaSアプリケーションの概要を低負荷で可視化する」ものであるから、「SaaSアプリケーション」、すなわち、サービスの概要を可視化するために、サービスを管理しているといえる。また、甲１の４頁「（シャドーITレポート）」の画像をみても、アプリケーションの列に各アプリケーションが並んでおり、各アプリケーションに対して、アプリケーションのタイプや状況が対応付けられていることからも、甲１発明は、サービスを管理しているといえる。 そうすると、甲１発明は、本件発明１と同様、「サービスを管理」する「管理ステップ」を含むものであるということができる。 ｄ 構成要件１Ｄについて 甲１発明において、「Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティングし、未知のセキュリティ脅威からユーザをブロックするためのきめ細かな制御を実施し、お客様の環境で使用されているSaaSアプリケーションの概要を低負荷で可視化」しているから、甲１発明は、ネットワーク（通信ネットワーク）を介して、何らかの情報を取得することにより、使用されているSaaSアプリケーション（サービス）を検出するものであるといえる。 そうすると、甲１発明は、本件発明１と同様、「前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出」する「検出ステップ」を含むものであるということができる。 ｅ 構成要件１Ｅについて （ａ） 本件発明１の構成要件１Ｅは、「前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成を含むものであるところ、当該構成は、構成要件１Ｃの「サービスを管理」する「管理ステップ」において、あるサービスが管理されていることを前提に、それ以外のサービス、すなわち、管理されていないサービスを特定するものである。 そうすると、本件発明１では、管理ステップにおいて管理されているサービスと、検出ステップによって検出されたサービスとを比較することにより、管理されていないサービスを特定するものであると認められる。 一方、上記ｃのとおり、甲１発明は、「サービスを管理」する「管理ステップ」を含むものであるといえるものの、管理されているサービスと検出されたサービスとを比較する等、どのようにして管理されていないサービスを特定するのか不明であり、甲１の記載全体をみても、具体的にどのようにして特定するのかは何ら記載も示唆もされていない。 したがって、甲１発明は、本件発明１の「前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成を有していない。また、当該特定する構成を有していないから、それに続く、「特定した場合、管理されていないサービスが検出された旨を出力する」構成も有していない。 （ｂ） これに対し、異議申立人は、「甲１発明は、未承認のアプリケーションを特定し、当該未承認のアプリケーションに未承認のマークを付けて表示する。つまり、甲１発明は、未承認のアプリケーションを特定した場合、未承認のアプリケーションに未承認のマークを付けて表示することによって、未承認のアプリケーションが検出された旨を出力している」（異議申立書５２頁中段）と主張する。 しかしながら、甲１発明においては、「Shadow IT Discovery（シャドーITディスカバリー）では、まず「観察」モードで、Cloudflare for Teamsが組織で使用されているすべてのアプリケーションをカタログ化する機能が実行され、すべてのアプリケーションが分析されるところ、デフォルトでは「未審査」となっており、その後、チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定することができ」るのであって、「Cloudflare for Teams」によって「チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定すること」は、本件発明１の「前記管理ステップによって管理されていないサービスを特定」する構成に相当するものではないから、甲１発明が本件発明１の「前記管理ステップによって管理されていないサービスを特定」する構成を有しているとはいえない。 したがって、異議申立人の主張は採用できない。 以上によれば、本件発明１と甲１発明は、以下の一致点、相違点を有する。 ［一致点］ １Ａ コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法であって、 １Ｂ 以下のステップを含み、 １Ｃ 管理ステップでは、サービスを管理し、 １Ｄ 検出ステップでは、前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出する １Ｆ 情報処理方法。 ［相違点］ 本件発明１は、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定した場合、管理されていないサービスが検出された旨を出力する」構成、すなわち、構成要件１Ｅを備えるのに対し、甲１発明は、そのような構成（構成要件１Ｅ）を備えない点。 （イ） 判断 上記（ア）のとおり、本件発明１と甲１発明を対比すると、［相違点］に係る構成を有するから、本件発明１は、甲１発明であるとはいえない。 イ 甲２～４に記載された発明に基づく検討 （ア） 対比・判断 異議申立人は、本件発明１は、甲２～４に記載された発明であると主張する。 しかしながら、甲２～４に記載された事項は、上記第４の２～４のとおりであるところ、甲２～４には、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」することは記載されていないし、それに続く、「特定した場合、管理されていないサービスが検出された旨を出力する」ことも記載されていないから、上記アの［相違点］に係る構成は記載されていない。 そうすると、本件発明１と、甲２～４から認定することができる発明を対比すると、上記アの［相違点］に係る構成で相違することとなる。 したがって、本件発明１は、甲２～４に記載された発明であるとはいえない。 （イ） 異議申立人の主張について ａ 甲２について 異議申立人は、「そして、甲２発明は、「非認可」のアプリケーションをフィルタリングする。そして、甲２発明は、「非認可」でフィルタリングされたアプリケーションを表示する。・・・つまり、甲２発明は、非認可のアプリケーションを特定した場合、非認可のアプリケーションをフィルタリングして表示することによって、非認可のアプリケーションが検出された旨を出力している。」（異議申立書７２頁上段）と主張する。 しかしながら、甲２には、「アプリケーションに「認可済み」、「非認可」、「監視中」のタグが付いている場合、タグが付いていないアプリケーションをフィルタリングすることができます。これらのアプリケーションは、分析段階の後、さらなるレビューと決定が必要なアプリケーションです。」（上記第４の２、３頁５行～１４行）と記載されているのみであって、「「非認可」でフィルタリングされたアプリケーションを表示」したり、「非認可のアプリケーションが検出された旨を出力」したりすることは記載も示唆もされていない。 ｂ 甲３について 異議申立人は、「甲３発明は、検出ステップによって検出された利用されているサービスから、危険度の高いアプリを特定した場合、危険度の高いアプリを検出された旨を出力する。」（異議申立書８３頁上段）ものであり、「甲３発明の「危険度の高いアプリ」は、管理対象でない危険度の高いアプリを示すことから、「管理対象でないサービス」に相当する。」（異議申立書１７６頁中段）と主張する。 しかしながら、甲３には、「危険度の低いアプリ（サービス）」が管理されていることを前提に、管理されているサービスと、検出されたサービスとを比較することにより、管理されていない「危険度の高いアプリ（サービス）」を特定することは記載も示唆もされていない。 ｃ 甲４について 異議申立人は、甲４の［０４１７］、［０４１９］、［０４２０］、図４２及び図７５の記載を根拠とし、甲４発明は、ＣＳＦ１００を使用し、企業が使用する「シャドーＩＴ」の迅速な評価レポートを作成するから、検出ステップによって検出された利用されているアプリケーションから、認可されていないアプリケーションを特定している旨主張する（異議申立書１０８頁中段）。 しかしながら、異議申立人の主張する甲４の記載箇所をみても、企業に認可されていないシャドーＩＴがあること（［０４１７］）、シャドーＩＴを含めユーザが使用しているＩＴリソースを可視化したいというニーズがあること（［０４１９］）、図４２のシャドーＩＴ報告の例や、図７５のシャドーＩＴ情報に提供することができるレポートの種々の形態などが記載されているだけであって、認可されているアプリケーション（サービス）が管理されていることを前提に、管理されているサービスと、利用されているアプリケーション（サービス）とを比較することにより、管理されていないアプリケーション（サービス）を特定することは記載も示唆もされていない。 ｄ 小括 以上のとおり、異議申立人の主張は採用できない。 （２） 本件発明２について ア 甲４に記載された発明に基づく検討 異議申立人は、本件発明２は、甲４に記載された発明であると主張する。 そこで検討するに、本件発明２は、構成要件２Ｅを備えるものであるところ、当該構成要件２Ｅは、本件発明１の構成要件１Ｅのうち、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成と同じである（上記第２参照。）。 そうすると、上記（１）イのとおり、甲４には、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成は記載されていないから、本件発明２と、甲４に記載された発明を対比すると、当該構成（以下「［相違点′］」という。）で相違することとなる。 したがって、本件発明２は、甲４に記載された発明であるとはいえない。 イ 甲５に記載された発明に基づく検討 （ア） 対比・判断 異議申立人は、本件発明２は、甲５に記載された発明であると主張する。 しかしながら、甲５に記載された事項は、上記第４の５のとおりであるところ、甲５にも、上記アの［相違点′］に係る構成は記載されていない。 そうすると、本件発明２と、甲５に記載された発明を対比すると、上記［相違点′］に係る構成を有することになる。 したがって、本件発明２は、甲５に記載された発明であるとはいえない。 （イ） 異議申立人の主張について 異議申立人は、「甲５発明は、非承認（非認可）のクラウドサービスを検出する。（［０００５］、［００１２］） つまり、甲５発明は、検出された利用されているサービスから、非承認のクラウドサービスを特定する。」と主張する（異議申立書１３１頁上段）。 しかしながら、異議申立人の主張する甲５の記載箇所をみても、「クラウドサービスにアクセスする要求が検出された場合に、ユーザとクラウドサービスとの間のインタラクションを監視することと、ユーザとクラウドサービスとの間のインタラクションがクラウドサービスの非認可の使用を表しているか否かを判定することと、クラウドサービスの非認可の使用に関連するリスクを管理すること」（［０００５］）、「クラウドベースのサービスの非承認使用に関連するリスクを管理する」こと（［０００５］）などが記載されているだけであって、複数のクラウドサービスの存在を前提として「非承認のクラウドサービスを特定する」ことは記載されていない。 そして、甲５には、承認されているクラウドサービスが管理されていることを前提に、管理されているクラウドサービスと、利用されている非承認のクラウドサービスとを比較することにより、管理されていない非承認のクラウドサービスを特定することは記載も示唆もされていない。 したがって、異議申立人の主張は採用できない。 （３） 本件発明３について ア 対比・判断 異議申立人は、本件発明３は、甲６に記載された発明であると主張する。 そこで検討するに、本件発明３は、構成要件３Ｅを備えるものであって、当該構成要件３Ｅは、本件発明１の構成要件１Ｅのうち、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成（［相違点′］）と同じである（上記第２参照。）。 そして、甲６に記載された事項は、上記第４の６のとおりであるところ、甲６には、上記［相違点′］に係る構成は記載されていない。 そうすると、本件発明３と、甲６に記載された発明を対比すると、［相違点′］に係る構成を有することになる。 したがって、本件発明３は、甲６に記載された発明であるとはいえない。 イ 異議申立人の主張について 異議申立人は、甲６の［００２６］の記載を根拠として、「甲６発明は、利用されているサービスから、シャドーＩＴのクラウドサービスを特定する。」と主張する（異議申立書１４２頁下段）。 しかしながら、異議申立人の主張する甲６の記載箇所をみても、「クラウドサービスヘの加入とクラウドサービスの使用を示すパターンの存在についてメッセージを分析する。メッセージ自体およびそのメタデータのこのような詳細な検査により、利用のタイプが明らかになり、・・・きめ細かなシャドーＩＴディスカバリーが可能になる」になると記載されているだけであって、具体的にどのようにしてシャドーＩＴのクラウドサービスであると特定するのかは記載されていない。 そして、甲６には、シャドーＩＴ以外のクラウドサービスが管理されていることを前提に、管理されているクラウドサービスと、利用されているシャドーＩＴのクラウドサービスとを比較することにより、管理されていないシャドーＩＴのクラウドサービスを特定することは記載も示唆もされていない。 したがって、異議申立人の主張は採用できない。 （４） 本件発明４及び５について 異議申立人は、本件発明４及び５は、甲１発明であると主張する。 しかしながら、本件発明４及び５は、本件発明１を限定した発明を含むものである。 そうすると、甲１発明と対比すると、少なくとも、上記（１）アの［相違点］に係る構成を有することになる。 したがって、本件発明４及び５は、甲１発明であるとはいえない。 （５） 本件発明１７及び１８について 異議申立人は、本件発明１７及び１８は、甲１発明及び甲２～４に記載された発明であると主張する。 しかしながら、本件発明１７及び１８は、それぞれ、プログラム及び情報処理装置の発明であるところ、いずれも、本件発明１に係る情報処理方法の発明とカテゴリーが相違するのみの発明を含むものである。 そうすると、本件発明１が、上記（１）のとおり、甲１発明及び甲２～４に記載された発明であるといえない以上、本件発明１７及び１８も、甲１発明及び甲２～４に記載された発明であるとはいえない。 （６） 理由１（新規性）のまとめ 以上によれば、本件特許は、特許法２９条１項の規定に違反してされたものではない。 したがって、異議申立人の主張する理由１は理由がない。 ２ 理由２（進歩性）について （１） 本件発明１、１７及び１８について 異議申立人は、本件発明１、１７及び１８は、甲１発明及び甲２～４に記載された発明のいずれかに基づいて、当業者が容易に発明をすることができたものであると主張する。 しかしながら、本件発明１、１７及び１８と、甲１発明及び甲２～４に記載された発明を対比すると、上記１（１）アの［相違点］に係る構成を有するところ、当該構成は、異議申立人が提出する甲５～１０には記載されていないし、周知技術であるということもできない。 そうすると、本件発明１、１７及び１８は、甲１発明及び甲２～４に記載された発明のいずれかに基づいて、当業者が容易に発明をすることができたものであるとはいえない。 （２） 本件発明２について 異議申立人は、本件発明２は、甲４及び甲５に記載された発明のいずれかに基づいて、当業者が容易に発明をすることができたものであると主張する。 しかしながら、本件発明２と、甲４及び甲５に記載された発明を対比すると、上記１（２）アの［相違点′］に係る構成を有するところ、当該構成は、異議申立人が提出する甲１～３及び６～１０には記載されていないし、周知技術であるということもできない。 そうすると、本件発明２は、甲４及び甲５に記載された発明のいずれかに基づいて、当業者が容易に発明をすることができたものであるとはいえない。 （３） 本件発明３について 異議申立人は、本件発明３は、甲６に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。 しかしながら、本件発明３と、甲６に記載された発明を対比すると、上記１（２）アの［相違点′］に係る構成を有するところ、当該構成は、異議申立人が提出する甲１～５及び７～１０には記載されていないし、周知技術であるということもできない。 そうすると、本件発明３は、甲６に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 （４） 本件発明４及び５について 異議申立人は、本件発明４及び５は、甲１発明に基づいて、当業者が容易に発明をすることができたものであると主張する。 しかしながら、本件発明４及び５は、本件発明１を限定した発明を含むものであるから、上記（１）のとおり、本件発明１が甲１発明に基づいて、当業者が容易に発明をすることができたものであるといえない以上、本件発明４及び５も、当業者が容易に発明をすることができたものであるとはいえない。 （５） 本件発明６、７、１０及び１２について 異議申立人は、本件発明６、７、１０及び１２は、甲１発明及び甲７に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。 しかしながら、本件発明６、７、１０及び１２は、本件発明１を限定した発明を含むものであるから、本件発明６、７、１０及び１２と、甲１発明とを対比すると、上記１（１）アの［相違点］に係る構成を有するところ、上述のとおり、当該構成は、異議申立人が提出する甲７には記載されていないし、周知技術であるということもできない。 そうすると、本件発明６、７、１０及び１２は、甲１発明及び甲７に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 （６） 本件発明８、９及び１４について 異議申立人は、本件発明８、９及び１４は、甲３及び甲８に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。 しかしながら、本件発明８、９及び１４は、本件発明１を限定した発明を含むものであるから、本件発明８、９及び１４と、甲３に記載された発明とを対比すると、上記１（１）アの［相違点］に係る構成を有するところ、上述のとおり、当該構成は、異議申立人が提出する甲８には記載されていないし、周知技術であるということもできない。 そうすると、本件発明８、９及び１４は、甲３及び甲８に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 （７） 本件発明１１及び１３について 異議申立人は、本件発明１１は、甲１発明及び甲９に記載された発明に基づいて、また、本件発明１３は、甲１発明及び甲６に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。 しかしながら、本件発明１１及び１３は、本件発明１を限定した発明を含むものであるから、本件発明１１及び１３と、甲１発明とを対比すると、上記１（１）アの［相違点］に係る構成を有するところ、上述のとおり、当該構成は、異議申立人が提出する甲９や６には記載されていないし、周知技術であるということもできない。 そうすると、本件発明１１は、甲１発明及び甲９に記載された発明に基づいて、また、本件発明１３は、甲１発明及び甲６に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 （８） 本件発明１５及び１６について 異議申立人は、本件発明１５は、甲４及び甲７に記載された発明に基づいて、また、本件発明１６は、甲４、甲７及び甲１０に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。 しかしながら、本件発明１５及び１６は、本件発明１を限定した発明を含むものであるから、本件発明１５及び１６と、甲４に記載された発明とを対比すると、上記１（１）アの［相違点］に係る構成を有するところ、上述のとおり、当該構成は、異議申立人が提出する甲７や１０には記載されていないし、周知技術であるということもできない。 そうすると、本件発明１５は、甲４及び甲７に記載された発明に基づいて、また、本件発明１６は、甲４、甲７及び甲１０に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 （９） 理由２（進歩性）のまとめ 以上によれば、本件特許は、特許法２９条２項の規定に違反してされたものではない。 したがって、異議申立人の主張する理由２は理由がない。 ３ 理由３（明確性）について （１） 判断 異議申立人は、本件発明１の構成要件１Ｅにおいて、「管理されていないサービスが検出された旨」及び「出力する」の意味が不明であるから、本件発明１は、明確であるとはいえず、本件特許は、特許法３６条６項２号に規定する要件を満たしていない特許出願に対してされたものであると主張するから、以下判断する（本件発明４～１８についても同旨。）。 ア 特許請求の範囲の記載について 本件発明１の構成要件１Ｅについて、特許請求の範囲の請求項１には、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定した場合、管理されていないサービスが検出された旨を出力する」と記載されているところ、サービスを管理することについては、構成要件１Ｃとして、「管理ステップでは、サービスを管理」することが記載されている（上記第２参照、再掲。）。 そうすると、構成要件１Ｅにおける「管理されていないサービスが検出された旨」とは、構成要件１Ｃの「サービスを管理」する「管理ステップ」において、あるサービスが管理されていることを前提に、それ以外のサービス、すなわち、管理されていないサービスが検出されたことを意味することは明らかである。 そして、構成要件１Ｅにおける「出力する」ことについても、「出力」とは、情報などを外部に出すという意味でも用いられるから、結局、構成要件１Ｅにおける「管理されていないサービスが検出された旨を出力する」とは、管理ステップにおいて管理されていないサービスが検出された場合、検出された旨を外部に出す、という意味であることが明確に理解できる。 イ 発明の詳細な説明について 上記アで検討したとおり、本件発明１の構成要件１Ｅの記載は明確であるところ、念のため、発明の詳細な説明をみても、構成要件１Ｅにおける「管理されていないサービスが検出された旨を出力する」ことの意味は明確である。 すなわち、発明の詳細な説明には、「特定部１０３は、新たなサービスつまり、管理部１０１で管理されていないサービスを特定した場合には、予め指定された通知先に、新たなサービスが検出された旨を示す警告を発するようにしてもよい。この警告は、特定部１０３で行うようにしてもよいが、情報処理装置１に図示しない警告部を設けるようにしてもよい。」（【００２８】）と具体的な処理が記載されているところ、当該記載によれば、特定部１０３において、「管理されていないサービスを特定した場合」に、特定部１０３やそれ以外の警告部で「警告を発する」ことが明確に理解でき、このような理解は、上記アの特許請求の範囲の記載における理解に沿うものである。 （２） 理由３（明確性）のまとめ 以上によれば、本件発明１には、異議申立人が主張する不明確な点はなく、ほかに不明確な点もないから、本件発明１は明確である（本件発明４～１８についても同様である。）。 そうすると、本件発明１及び４～１８は、明確であるから、本件特許は、特許法３６条６項２号に規定する要件を満たしていない特許出願に対してされたものであるとはいえない。 したがって、異議申立人の主張する理由３は理由がない。 ４ 理由４（サポート要件）について （１） 判断 異議申立人は、本件発明１の構成要件１Ｅにおける「管理されていないサービスが検出された旨」及び「出力する」ことの具体例が発明の詳細な説明又は図面には記載されていないから、本件発明１は、発明の詳細な説明に記載したものではなく、本件特許は、特許法３６条６項１号に規定する要件を満たしていない特許出願に対してされたものであると主張する（本件発明４～１８についても同旨。）。 しかしながら、異議申立人の主張する本件発明１の構成要件１Ｅにおける「管理されていないサービスが検出された旨」及び「出力する」ことの具体的な処理は、上記３のとおり、本件明細書の発明の詳細な説明の【００２８】に記載されている（なお、「出力する」ことの具体的な処理としては、例えば、異議申立書（２０７頁下段）において、「何等かの警告マークを管理者の画面に「表示する」ことであるのか、「管理されていないサービスが検出された」というメッセージを管理者の画面に「表示する」ことであるのか、「印刷出力する」ことであるのか、警告メールを管理者に送信することであるのか」と記載されているように、当業者であれば種々容易に想定し得るものである。）。 （２） 理由４（サポート要件）のまとめ 以上によれば、本件発明１は、本件明細書の発明の詳細な説明に記載したものである（本件発明４～１８についても同様である。）。 そうすると、本件発明１及び４～１８は、発明の詳細な説明に記載したものであるから、本件特許は、特許法３６条６項１号に規定する要件を満たしていない特許出願に対してされたものであるとはいえない。 したがって、異議申立人の主張する理由４は理由がない。 ５ 理由５（新規事項の追加）について （１） 判断 異議申立人は、本件特許に係る出願において、令和５年２月２４日付けで提出された手続補正書においてされた、本件発明１の構成要件１Ｅの「出力する」という補正（以下「本件補正」という。）について、出願当初明細書等に記載された「警告を発する」以外の処理を含むように補正されており、本件補正は、出願当初明細書等に記載した事項の範囲を超えるものであるから、本件特許は、特許法第１７条の２第３項に規定する要件を満たしていない特許出願に対してされたものであると主張する（本件発明４～１８についても同旨。）。 しかしながら、上記４のとおり、「出力する」ことについて、「警告を発する」以外の処理として、当業者であれば具体的な処理を種々容易に想定し得るものであるから、本件補正において、「出力する」と補正されたことで、出願当初明細書等に記載した事項の範囲を超えるものになったということはできない。 （２） 理由５（新規事項の追加）のまとめ 以上によれば、本件補正は、出願当初明細書等に記載した事項の範囲を超えるものであるとはいえないから、本件特許は、特許法第１７条の２第３項に規定する要件を満たしていない補正をした特許出願に対してされたものであるとはいえない。 したがって、異議申立人の主張する理由５は理由がない。 第６ むすび 以上の次第であるから、特許異議の申立ての理由及び異議申立人の提出した証拠によっては、本件特許を取り消すことはできない。 また、他に本件特許を取り消すべき理由を発見しない。 よって、結論のとおり決定する。