• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部申し立て 判示事項別分類コード:なし  G06Q
管理番号 1406757
総通号数 26 
発行国 JP 
公報種別 特許決定公報 
発行日 2024-02-22 
種別 異議の決定 
異議申立日 2023-10-24 
確定日 2024-02-02 
異議申立件数
事件の表示 特許第7265054号発明「情報処理装置及びプログラム」の特許異議申立事件について、次のとおり決定する。 
結論 特許第7265054号の請求項1〜18に係る特許を維持する。 
理由 第1 手続の経緯
特許第7265054号の請求項1〜18に係る特許(以下、「本件特許」という。)についての出願は、令和3年8月26日に出願した特願2021−138439号の一部を令和4年3月14日に新たな特許出願としたものであって、令和5年2月24日に手続補正がされ、同年4月17日にその特許権の設定登録がされ、同年4月25日に特許掲載公報が発行された。その後、本件特許に対し、同年10月24日に特許異議申立人 八木峰子(以下「異議申立人」という。)は、特許異議の申立てを行った。

第2 本件発明
本件特許の請求項1〜18に係る発明(以下、それぞれ「本件発明1」〜「本件発明18」といい、併せて「本件発明」という。)は、特許請求の範囲の請求項1〜18に記載された事項により特定される次のとおりのものである。なお、独立形式の請求項である請求項1〜3に記載された構成要件「1A」〜「3G」は、異議申立人が異議申立書で付与したものである。

「【請求項1】
1A コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法であって、
1B 以下のステップを含み、
1C 管理ステップでは、サービスを管理し、
1D 検出ステップでは、前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出し、
1E 特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定した場合、管理されていないサービスが検出された旨を出力する
1F 情報処理方法。
【請求項2】
2A コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法であって、
2B 以下のステップを含み、
2C 管理ステップでは、サービスを管理し、
2D 検出ステップでは、前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出し、
2E 特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定し、
2F 前記検出ステップでは、前記通信ネットワークを介して取得される前記情報としてブラウザの閲覧履歴を取得することにより、前記閲覧履歴から前記利用されているサービスを検出する
2G 情報処理方法。
【請求項3】
3A コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法であって、
3B 以下のステップを含み、
3C 管理ステップでは、サービスを管理し、
3D 検出ステップでは、前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出し、
3E 特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定し、
3F 前記検出ステップでは、前記通信ネットワークを介して取得される前記情報としてメールの受信履歴を取得することにより、前記受信履歴から前記利用されているサービスを検出する
3G 情報処理方法。
【請求項4】
請求項1〜3のいずれか1項に記載の情報処理方法において、
前記検出ステップでは、前記通信ネットワークを介して取得される前記情報として接続先のアドレスを取得することにより、前記接続先のアドレスから前記利用されているサービスを検出する
情報処理方法。
【請求項5】
請求項1〜4のいずれか1項に記載の情報処理方法において、
前記検出ステップでは、前記通信ネットワークを介して取得される前記情報として利用者端末の利用履歴を取得することにより、前記利用履歴から前記利用されているサービスを検出する
情報処理方法。
【請求項6】
請求項1〜5のいずれか1項に記載の情報処理方法において、
前記特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、所定期間以上利用されていないサービスを特定する
情報処理方法。
【請求項7】
請求項1〜6のいずれか1項に記載の情報処理方法において、
前記通信ネットワークを介して取得される前記情報は、会計サービス、経費サービス、またはプリペイドカードサービスを介して取得される支払情報と、クレジットカード会社が提供する利用明細と、銀行が提供する出金明細との少なくとも一つを含む
情報処理方法。
【請求項8】
請求項1〜7のいずれか1項に記載の情報処理方法において、
前記検出ステップでは、前記通信ネットワークを介して取得される前記情報としてアカウントの利用履歴を取得することにより、前記利用履歴から前記利用されているサービスを検出する
情報処理方法。
【請求項9】
請求項1〜8のいずれか1項に記載の情報処理方法において、
前記管理ステップでは、サービスの名称とアカウントを管理する
情報処理方法。
【請求項10】
請求項1〜9のいずれか1項に記載の情報処理方法において、
前記管理ステップでは、サービスの内容と価格を管理する
情報処理方法。
【請求項11】
請求項1〜10のいずれか1項に記載の情報処理方法において、
前記検出ステップでは、利用者から受け付けた申告からサービスを検出する
情報処理方法。
【請求項12】
請求項1〜11のいずれか1項に記載の情報処理方法において、
前記特定ステップでは、前記検出ステップで検出されたサービスから、利用頻度が予め定めた値以上のサービスを特定し、
前記管理ステップでは、該特定したサービスを新たな管理対象として管理する
情報処理方法。
【請求項13】
請求項1〜12のいずれか1項に記載の情報処理方法において、
前記特定ステップでは、前記検出ステップで検出されたサービスを、最初に利用したアカウントを特定する
情報処理方法。
【請求項14】
請求項1〜13のいずれか1項に記載の情報処理方法において、
前記検出ステップでは、IDプロバイダから該IDプロバイダが提供するアカウントの利用履歴を取得し、該利用履歴に含まれる利用先から利用されているサービスを検出する
情報処理方法。
【請求項15】
請求項1〜14のいずれか1項に記載の情報処理方法において、
判定ステップを実行し、
前記判定ステップでは、前記管理ステップで管理するサービスの利用頻度に基づいて、該サービスの解約が可能であると判定した場合、その旨を報知する
情報処理方法。
【請求項16】
請求項15に記載の情報処理方法において、
前記判定ステップでは、前記管理ステップで管理するサービスの代替サービスの有無を判定し、該判定の結果に基づいて前記解約の可否を判定する
情報処理方法。
【請求項17】
コンピュータを情報処理装置として動作させるプログラムであって、
コンピュータを請求項1〜16のいずれか1項に記載の情報処理装置として機能させる、プログラム。
【請求項18】
情報処理装置であって、
請求項1〜16のいずれか1項に記載の各ステップを実行可能な情報処理装置。」

第3 申立理由の概要
1 異議申立人の提出した証拠
異議申立人は、次の甲第1号証〜甲第10号証(以下、それぞれ、「甲1」〜「甲10」という。)を証拠として提出している。
甲第1号証(甲1):“Introducing Shadow IT Discovery(シャドーITディスカバリーの導入)”、Abe Carryl、令和3年8月16日掲載、<URL:https://web.archive.org/web/20210816132243/https://blog.cloudflare.com/introducing-shadow-it-discovery/ >
甲第2号証(甲2):“Extending MCAS Cloud Discovery into the Managing of Shadow IT(MCASのクラウド・ディスカバリーをシャドーITの管理に拡張する)”、Sami Lamppu、令和3年8月18日掲載、<URL:https://samilamppu.com/2021/08/18/extending-mcas-cloud-discovery-into-the-managing-of-shadow-it/ >
甲第3号証(甲3):“"Sign in with Google" and the hidden cost of convenience(「Googleでログイン」と利便性の隠れた代償)”、Richard Kirby、令和3年4月22日掲載、<URL:https://web.archive.org/web/20210422162621/https://trelica.com/blog/sign-in-with-google-and-the-hidden-cost-of-convenience/ >
甲第4号証(甲4):米国特許出願公開第2018/0027006号明細書
甲第5号証(甲5):米国特許出願公開第2019/0199751号明細書
甲第6号証(甲6):米国特許出願公開第2017/0134506号明細書
甲第7号証(甲7):特表2016−504687号公報
甲第8号証(甲8):“OAuth Token audit log(OAuthトークンの監査ログ)”、Google、令和3年7月29日掲載、<URL:https://web.archive.org/web/20210729102032/https:/support.google.com/a/answer/6124308?hl=en >
甲第9号証(甲)9:特開2021−77271号公報
甲第10号証(甲10):特開2021−51612号公報

2 特許異議の申立理由
異議申立人の主張する特許異議の申立理由の概要は以下のとおりである。
(1) 理由1(新規性
本件発明は、甲1〜甲6に記載された発明であって、特許法29条1項3号に該当するから、本件特許は、同条同項の規定に違反してされたものである。

(2) 理由2(進歩性
本件発明は、甲1〜甲10に記載された事項に基づいて当業者が容易に発明をすることができたものであるから、本件特許は、特許法29条2項の規定に違反してされたものである。

(3) 理由3(明確性
本件発明は、明確であるとはいえないから、本件特許は、特許法36条6項2号に規定する要件を満たしていない特許出願に対してされたものである。

(4) 理由4(サポート要件)
本件発明は、本件特許についての願書に添付された明細書(以下、「本件明細書」という。)の発明の詳細な説明に記載したものではないから、本件特許は、特許法36条6項1号に規定する要件を満たしていない特許出願に対してされたものである。

(5) 理由5(新規事項の追加
本件特許に係る出願について、令和5年2月24日付けで提出された手続補正書における特許請求の範囲の補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものではないから、本件特許は、特許法第17条の2第3項に規定する要件を満たしていない補正をした特許出願に対してされたものである。

第4 異議申立人の提出した証拠の記載
1 甲1について
(1) 甲1の記載
甲1には、以下の記載がある(下線は当審において加筆した。なお、外国語文献の訳文は異議申立人が提出した訳を採用した。以下同じ。)。
「あなたのチームは、あなたが思っている以上に多くのSaaSアプリケーションを使用している可能性があります。ユーザが別のサービスにサインアップしたり、新しい場所にデータを保存したりすると、管理者が使用を許可されたアプリケーションの審査や承認に費やしていた時間が突然無駄になる可能性があります。本日から、Cloudflare for Teamsを使用して、わずか2クリックで未承認のSaaSアプリケーションを検出し、ブロックすることができます。」(1頁1〜5行)
「増加するシャドーITの利用
SaaSアプリケーションは、IT部門の時間と予算を節約します。ツールをホストするためのサーバーにお金を払い、それらのツールを監視し、アップグレードし、トラブルシューティングするスタッフを用意する代わりに、組織はクレジットカードだけでSaaSに相当するものにサインアップすることができ、ホスティングやメンテナンスの心配をする必要はありません。
その利便性が、データ管理の問題を引き起こす。SaaSアプリケーションは、あなたが管理する環境の外に置かれています。あなたのチームにとって使いやすいという同じ理由が、あなたの機密データが第三者に保管されるという潜在的な責任にもなっているのです。ほとんどの組織は、使用されているSaaSアプリケーションを注意深く監査することで、この問題を抑えている。業界や規制の影響に応じて、IT部門は使用するアプリケーションを評価し、承認し、カタログ化する。
しかし、ユーザーは意図的または偶然にこれらの承認をバイパスすることができます。例えば、組織がOneDriveに依存しているが、ユーザーはGoogle Driveの方が使いやすい場合、そのユーザーは仕事のファイルを代わりにGoogle Driveに保存することにするかもしれない。IT部門はこのような事態を把握できず、ユーザーは問題ないと考えるかもしれません。そのユーザーは、組織内の他のユーザーとファイルを共有し始め、そのユーザーもGoogleドライブにサインアップし、突然、認可されていないアプリケーションが機密情報を保持するようになります。これが「シャドーIT」であり、このようなアプリケーションは本来、組織による統制を難読化するものです。」(1頁6行〜2頁19行)
「シャドーITの検出
Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティングし、未知のセキュリティ脅威からユーザをブロックするためのきめ細かな制御を実施します。また、お客様の環境で使用されているSaaSアプリケーションの概要を低負荷で可視化することで、お客様のチームにさらなる保証を提供します。
Gatewayをオンにするだけで、組織に対するすべてのHTTPリクエストが、監査とセキュリティ目的でGatewayアクティビティログに集約されます。アクティビティログには、ユーザー、アクション、リクエストに関する適切な情報が記録されます。これらのレコードには、アプリケーションとアプリケーションタイプに関するデータが含まれます。上記の例では、アプリケーションの種類はコラボレーションとオンラインミーティング、アプリケーションはGoogleドライブです。
そこから、GatewayはアクティビティログのHTTPリクエストを分析し、一見雑多なアプリケーションを分類し、実用的なインサイトに分類することで、シャドーITを表面化します。」(2頁20行〜3頁6行)
「シャドーITディスカバリーの導入
Shadow IT Discovery(シャドーITディスカバリー)では、まずCloudflare for Teamsが組織で使用されているすべてのアプリケーションをカタログ化します。この機能はまず「観察」モードで実行され、すべてのアプリケーションが分析されますが、デフォルトでは「未審査」となっています。
その後、チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定することができます。
これにより管理者は、ユーザーがアクセスしている承認済みアプリケーションと未承認アプリケーションの上位を簡単に追跡し、セキュリティ体制をより適切にプロファイリングできるようになります。より詳細なビューにドリルダウンすると、管理者は新たに検出された複数のアプリケーションを一度に移動する一括アクションを実行できます。このビューでは、ユーザーはアプリケーションの種類でフィルタリングして、組織内の重複を簡単に特定することもできます。
私たちが追加したかったもう一つの機能は、組織で使用されているアプリケーションがすでにCloudflare Accessによって保護されているかどうかを素早くハイライトできる機能です。この情報は「Secured(セキュリティで保護されています)」という列で確認できます。アプリケーションがAccessによってセキュア化されていない場合は、Access for SaaSを使用して今日からそのプロセスを開始できます。(今週は2つの新しいチュートリアルを追加しました。)
Cloudflare for Teamsは、アプリケーションに未承認のマークを付けても、そのアプリケーションを完全にブロックするわけではありません。アプリケーションへのアクセスを完全にブロックする前に、アプリケーションに未承認のラベルを付け、ユーザーに確認する必要がある組織もあるかと思います。チームの準備が整えば、Gatewayルールを適用してアプリケーションへのアクセスをブロックすることができます。」(3頁7行〜5頁5行)

(4頁「(シャドーITレポート)」の画像)


(2) 甲1発明
ア 上記1頁1行〜5行の記載によれば、甲1には、「Cloudflare for Teamsを使用して、わずか2クリックで未承認のSaaSアプリケーションを検出し、ブロックする」方法が記載されている。

イ 上記2頁20行〜3頁6行の記載によれば、Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティングし、未知のセキュリティ脅威からユーザをブロックするためのきめ細かな制御を実施し、お客様の環境で使用されているSaaSアプリケーションの概要を低負荷で可視化することで、お客様のチームにさらなる保証を提供するものである。

ウ また、上記2頁20行〜3頁6行の記載によれば、Gatewayをオンにするだけで、組織に対するすべてのHTTPリクエストが、監査とセキュリティ目的でGatewayアクティビティログに集約され、アクティビティログには、ユーザー、アクション、リクエストに関する適切な情報が記録され、これらのレコードには、アプリケーションとアプリケーションタイプに関するデータが含まれ、GatewayはアクティビティログのHTTPリクエストを分析し、一見雑多なアプリケーションを分類し、実用的なインサイトに分類することで、シャドーITを表面化するものである。

エ 上記3頁7行〜5頁5行の記載によれば、Shadow IT Discovery(シャドーITディスカバリー)では、まず「観察」モードで、Cloudflare for Teamsが組織で使用されているすべてのアプリケーションをカタログ化する機能が実行され、すべてのアプリケーションが分析されるところ、デフォルトでは「未審査」となっており、その後、チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定することができる。

オ また、上記3頁7行〜5頁5行の記載によれば、Cloudflare for Teamsは、アプリケーションに未承認のマークを付けても、そのアプリケーションを完全にブロックするわけではなく、アプリケーションへのアクセスを完全にブロックする前に、アプリケーションに未承認のラベルを付け、ユーザーに確認する必要がある組織もあるから、チームの準備が整えば、Gatewayルールを適用してアプリケーションへのアクセスをブロックすることができる。

以上によれば、甲1には次の発明(以下、「甲1発明」という。)が記載されている。

[甲1発明]
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ルールを適用してアプリケーションへのアクセスをブロックすることができる、
方法。

2 甲2について
甲2には、以下の記載がある。
「ビジネスクリティカルなデータが組織から管理されていないクラウドアプリケーションに流出するシナリオを想像してみてください。あるいは、アプリのレピュテーションに基づき「ハイリスク」アプリとみなされるアプリを使用するユーザーが突然増えたとします。
どちらのシナリオでも、Microsoft Cloud App Security (MCAS)が両方のアクティビティを検出し、さらに管理者はアプリケーションへのアクセスをブロックしたり、コントロールを設定したりすることができます。」(1頁2行〜5行)
「シャドーITの発見と管理
Cloud App Securityの「Cloud Discovery」機能により、企業は各クラウドアプリケーションのアプリケーションやユーザーアクティビティ、トラフィック量、典型的な利用時間を特定することができる。一言で言えば、シャドーITやリスクのあるアプリケーションを検出することができる。
余談:マイクロソフトのレポートによると、平均的な組織ではIT部門が管理していないアプリケーションが1000以上使用されている。
シャドーIT管理のライフサイクルには、次のような柱があります:
フェーズ1 - 発見と特定
シャドーITの発見
アプリケーションのリスクレベルを特定する
フェーズ2 - 評価と分析
コンプライアンスの評価
使用状況の分析
フェーズ3 - 管理と継続的モニタリング
クラウドアプリケーションの管理
継続的モニタリング」(1頁10行〜2頁1行)
「MCASにデータが取り込まれたら、何から始めたらいいのでしょうか?という質問をよく受けますが、Cloud App Securityの「Cloud Discovery」ダッシュボードから「Cloud Discovery Executive」レポートを実行して、環境内のSaaSアプリケーションの使用状況を全体的に把握することから始めるのが1つの方法です。このレポートでは、主要な調査結果とさらなる対策のための推奨事項が強調されています。」(2頁5行〜7行)
「公認/非認可/モニター アプリケーション
アプリケーションが有効で、組織内で使用が許可されているか禁止されているかを決定する。管理者は、アプリケーションをどのように処理するかを決定し、アプリケーションに「認可」、「非認可」、または「監視」タグを割り当てることができます(執筆時点)。カスタムタグは、特定の監視目的、Cloud Discoveryページのフィルタリング、およびポリシーの作成に使用できます。
組織での使用が許可されていないアプリケーションは、"非認可"としてタグ付けすることができ、Microsoft Defender for EndpointとCloud App Securityの統合により、エンドポイントによってWindows 10デバイスからブロックすることができます。
このアクションは、Microsoft Defender for Endpointsや、Zscaler、iBoss、Menlo、Corrataなどの統合アプライアンスに直接伝わり、アプリへのアクセスをブロックすることができます。
アプリケーションに「認可済み」、「非認可」、「監視中」のタグが付いている場合、タグが付いていないアプリケーションをフィルタリングすることができます。これらのアプリケーションは、分析段階の後、さらなるレビューと決定が必要なアプリケーションです。」(3頁5行〜14行)
「条件付きアクセス・アプリ・コントロールによるアプリの保護
Microsoft Cloud App Securityは、あらゆるIDプロバイダ(IdP)と統合され、アクセス制御とセッション制御によって、データ漏えいやデータ盗難からリアルタイムに保護するのに役立ちます。Azure Active Directory(Azure AD)がIdPとして使用されている場合、これらの制御は統合され、Azure ADの条件付きアクセスツールに構築された、よりシンプルでカスタマイズされた展開のために合理化されます。
Conditional Access App Controlは、アクセス・ポリシーとセッション・ポリシーに基づいて、ユーザー・アプリへのアクセスとセッションをリアルタイムで監視・制御することができます。アクセスポリシーとセッションポリシーにより、以下のシナリオを実現できます:
データ流出の防止
ダウンロード時の保護
ラベル付けされていないファイルのアップロードを防止
潜在的なマルウェアをブロック
ユーザー・セッションのコンプライアンス監視
アクセスをブロック
カスタムアクティビティのブロック」(4頁9行〜21行)

3 甲3について
甲3には、以下の記載がある。
「ソーシャルログインは、ユーザーの利便性を提供し、脆弱なパスワードや再利用されるパスワードに関連するリスクを取り除く。ユーザーにサードパーティ製アプリへのアクセス許可を与える権限を与えることは、リスクの高いトレードオフです。ソーシャルログインの背後にあるテクノロジーを説明し、関連するリスクを特定し管理する方法を探ります。」(1頁1〜3行)
「ユーザーの生活を便利にし、セキュリティリスクを減らすという点では、Win-Winの関係だ。このため、多くのIT管理者は、ユーザーが他のウェブサイトやサードパーティのSaaSアプリで「Googleでログイン」(厳密にはOpenID Connect、またはOIDC)を使用することに対して、穏便なアプローチをとっている。」(1頁18〜19行)
「OAuthとは?
OpenID Connect (OIDC)はしばしばOAuth2と呼ばれる別のレイヤーの上に乗っています。OIDCは認証を扱い、OAuth2は認可を扱います。
わかりやすく言うと、OIDCはあなたが誰であるかを確認し、OAuth2はウェブアプリケーションに何を許可するかを伝えます。
OAuth2が実際に使われているのを、Googleの「アプリケーションXがあなたのGoogleアカウントにアクセスしたい」という画面で見たことがあるでしょう。この画面では、アプリケーションが何を許可したいのかが説明され、リスクをよく考えるよう促す小さなテキストと、「許可する」という大きな青いボタンが表示されます。」(1頁20〜27行)
「SaaS管理ツールはG Suiteの管理にどのように役立つのでしょうか?
これは非常に便利な機能ですが、G Suiteの管理コンソールでは、どのアプリケーションがこれらの権限を要求しているかを追跡し、それぞれを調査する作業が残っています。
そこで、TrelicaのようなSaaS管理ツールが役立ちます。
TrelicaをG Suiteドメインに接続するには、数回クリックするだけです(青い「承認」OAuth2ボタンを含む)。使用中のすべてのアプリを自動的に検出し、各GoogleサービスAPI(OAuth Scope)をリスク評価することで、潜在的に危険なアクセスを強調表示します。」(4頁3〜8行)
「結論
TrelicaのようなSaaS管理ソリューションとG Suiteの新しいアプリケーションブロック機能を組み合わせれば、ユーザーがシャドーITの危険なポートフォリオを構築することなく、「ソーシャルログイン」のメリットを享受することができます。管理されないままにしておくと、ユーザーが会社の情報にアクセスできる第三者を決めているという考えに慣れる必要があります。」(5頁6〜9行)

(5頁上段の画像)


4 甲4について
甲4には、以下の記載がある。
「[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つまたは複数のマシンを含むコンピューティングプラットフォーム上で展開することができる。」

(図42)


(図60)


(図75)


5 甲5について
甲5には、以下の記載がある。
「[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システムによって実行されてもよい。」

(図1)


(図3)


6 甲6について
甲6には、以下の記載がある。
「[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と共有されていることを特定することができる。」

(図2)


7 甲7について
甲7には、以下の記載がある。
「【0006】
SWを保守して更新する責任は、SWベンダーに移行する。ベンダーは、自社のSWを実行しているサーバも管理し、その結果、企業IT管理の責任は、社内ユーザが、接続先の円滑な作業およびデバイスを保証するのに十分なリモートサーバへの接続性を有するようにすることだけに軽減される。SWはサービスとして販売される(SaaS−Software as a Service):最も一般的なモデルは月極めサブスクリプションである。」
「【0009】
現在のサービス−デバイスのパラダイムはもはや、IT世界を効率的に説明してないが、それはユーザが異なるデバイスを通じてアプリケーションにアクセスするという事実を無視するからであり、また実際の使用の重要性を無視することに起因している。したがって、ITマネージャが会社またはその他の組織にわたりSaaS使用を容易に測定および分析することができるシステムおよび/または方法を有することが有益であろう。」
「【0013】
本発明の実施形態は、クラウドアプリケーションによって導入されるさまざまな認証メカニズムをサポートするためのユニバーサルメカニズムと、IT関係者がクラウドアプリケーションのサブスクリプションを管理して、アプリケーションをプロビジョンまたはプロビジョン解除するための環境および便利なツールと、デバイス独立の使用追跡と、ロケーション独立の使用追跡と、開発ツールと、さまざまなクラウドアプリケーションベンダーとのSOAおよびオープンソース統合スクリプトとを含む特徴を提供する。」
「【0028】
図3は、本発明の実施形態によるシステム310を示し、図3において説明される要素は、図2を参照して上記で説明されている要素と同一であってもよいか、またはこれらの要素と類似する方法で機能することができる。システム310は、収集モジュールとしての役割を果たすアプリケーションアダプタ320と、記憶モジュール330のようなメモリデバイスと、処理モジュール(プロセッサ)340とを含む。後段においてさらに詳細に説明されるように、アダプタ320は、エンドユーザによって採用されたクライアントデバイス360のセット、および/または1つまたは複数のサーバ380を含むネットワークでホスティングされた複数のソフトウェアアプリケーション370(たとえば、SaaSアプリケーション)と対話するように構成される。実施形態において、アダプタ320は、ターゲットとなるアプリケーション370によって固有のオブジェクトタイプに適用され得る操作のオブジェクトモデルを認識するかまたは発見するように構成され得るアプリケーション固有のコンポーネントである。加えて、アダプタ320は、アプリケーション370の固有のオブジェクト言語を実施形態により汎用モデルに変換するように構成される。」
「【0034】
上記で示され説明される実施形態は、複数のSaaSアプリケーション370から多種多様な使用統計を収集するように構成される。上記で示されるように、これらの統計は、アプリケーションとの直接通信、アプリケーションREST APIまたはアプリケーションプラグイン、ネットワークトラフィックを監視するエージェント、システムログ、アプリケーションログ、ネットワークログ、VPNログ、ファイアウォールログ、ネットワークプロキシサービス、アプリケーション−ユーザ電子メール、および/または会社の課金システムを介して、SaaSアプリケーション自体からもたらされ得る。
【0035】
収集された使用統計は、各アプリケーション370ごとに一意であってもよく、以下のような項目を含むことができる。
【0036】
1. ログインの数
2. 前回ログイン以降の時間
3. 合計アプリケーション使用時間
4. アプリケーションオブジェクトが読み取られた回数
5. アプリケーションオブジェクトが書き込まれたか変更された回数
6. 送信/受信されたバイトの数
7. 送信/受信されたパケットの数
8. 作成されたアプリケーションオブジェクトの数
9. アプリケーション使用に関連したポインタ「クリック」の回数
収集の複数の方法は、1つまたは複数の実施形態が、さまざまなクライアントデバイス360にわたり、および/またはSaaSベンダーのログとの統合を通じてデータを取り込み、固有のユーザに関連付けることができるようにし、その結果デバイスおよびロケーションから独立した使用統計をもたらすことができる。」
「【0039】
さまざまな使用分析が、アプリケーション370に対して以下のように計算されてもよい。
【0040】
1. 個別アプリケーションベース
2. 複数アプリケーションにわたる組合せ、および/または
3. 会社部門または事業単位にわたる組合せ
これらの使用分析は、プロセッサ340によって(予め定められた時間期間および/または固有の時間期間を含む)時間の経過に伴って計算および/または監視されてもよく、使用傾向分析を可能にする。各アプリケーションの使用メトリックは、アプリケーション370に関連する収集された統計に基づいて計算されてもよい。この使用メトリックは、各アプリケーション370ごとに異なっていてもよい。」
「【0060】
計算アルゴリズム
以下に示すのは、実施形態による、アプリケーション/アプリケーション担当者ごとの使用インデックおよびアクティビティレベルを計算するための可能なアルゴリズムの1つである。
【0061】
1. 予想される基準を日次(Daily)表現に正規化することによってDayCriterionを計算する。たとえば、
1日1回=1
週1回=1/NoOfWorkDaysaWeek=0.2
週2回=2/NoOfWorkDaysaWeek=0.4
注:実施形態により就業日のみが考慮に入れられる。
【0062】
2. ユーザのDayLognis−1日に正規化されたログインの数を計算する。
【0063】
DayLogins=NoOfLoginsInPeriod/NoOfWorkDa
ysInPeriod(以下のDayLoginsの計算も参照)
3. ユーザインデックスは、以下のように計算される。
【0064】
UsageIndex=DayLogins/DayCriterion*100%
4. アクティビティレベルは、以下のものと等しい。
【0065】
a. 高利用率 − UsageIndex>75%である場合
b. 中利用率 − 25%>=UsageIndex=<75%である場合
c. 低利用率 − UsageIndex<25%である場合
NoOfLoginInPeriodは、すべての日−就業および非就業についてシステムログから引き出される。1日内の複数のログインは、「1」で表されるものとする。」
「【0073】
実施形態において、顧客(つまり、エンドユーザ360が構成要素である組織)は、各自の詳細な使用分析にアクセスすることができる。実施形態は、組織および/または対組織または組織のグループにわたるベンチマーキング、および顧客のターゲットとなる使用目標を提供することができる。実施形態は、たとえば部門、拠点、事業単位への社内SaaSアプリケーション予算割り振りを顧客に提供するために、この情報を、SaaSライセンス価格設定と組み合わせることができる。」
「【0075】
どのSaaSアプリケーションが使用中であるかをカタログ作成する
アプリケーションが、全体的およびバーティカルマーケットにおいて、その競合アプリケーションに対してどのようなにランクを占めるかを決定する
SaaSアプリケーション使用に関して「業界ベストプラクティス」を定量化する
顧客に、その相対的業界ランキングおよび改善のための提案を提供する
企業にわたり固有の機能に対する好ましいアプリケーションを示す
企業によるパフォーマンスレベルを比較するため、および/または監査の目的で、基準として使用されるように、固有のアプリケーションまたはアプリケーションのクラスに対して集約された使用データをマーケティングおよび販売する
会社に知られていないSaaSアプリケーションまたは使用を発見する
実施形態は、未知の(または既知でもある)各アプリケーション370の既存のユーザが誰であるかを識別する目的で、誰がアプリケーションを使用しているかを決定することができる。そのような機能は、各アプリケーション370ごとにいくつのユーザ360があるか、およびそれらの使用量に関する情報を提供することができる。
【0076】
本明細書において上記で示されるように、1つまたは複数の実施形態により、この機能を達成するための方法は、以下のようなものであってもよい。
【0077】
1. ネットワークトラフィックを検査すること、実施形態は、会社の公認ライセンシングになかったユーザ、たとえばクレジットカードを使用して個別にライセンスを購入した従業員を「発見」することができる。」
「【0087】
実施形態は、固有のベンダーによって送信された納品伝票を認識することができる。出力は、組織にサービスを提供するSaaSベンダーからのものであると実施形態が認識するすべてのそれらの納品伝票のリストであってもよい。実施形態は、合計支払い金額および納品伝票発行日のような納品伝票の内容から、少なくとも一部の最小の情報を抽出することができる。」
「【0094】
実施形態は、SaaSアプリケーションの価格設定モデルを収集して記憶することができる。この情報は、公的に使用可能なソース、および顧客ライセンシングデータからの匿名扱いの情報を含む複数のソースからもたらされる。次いで、実施形態は、それらのSaaS価格設定モデルと、それらが顧客の配備にどのように影響を及ぼすかに関するさまざまな分析を提供することができる。2つの例は、使用に基づく会社のアプリケーションの最適コストを計算することと、同じカテゴリの複数のアプリケーションの最適コストを計算すること(たとえば、使用可能なライセンシングおよび会社全体にわたる使用のタイプに基づいて3つの異なるSaaS記憶アプリケーション370の最適な配備を会社に示すこと)とを含む。」
「【0096】
実施形態は、SaaSアプリケーション370の従業員ライフサイクル管理を提供することができる。実施形態は、会社における従業員の状況を、それらのSaaSプロビジョニングおよび使用を介して監視することができる。実施形態は、たとえば、従業員が1つまたは複数のアプリケーション370でプロビジョン解除される場合、従業員が退社したので他のアプリケーションでプロビジョン解除される必要はないという合図となり得るので、レポートおよびアラートを提供することができてもよい。」

8 甲8について
甲8には、以下の記載がある。
「OAuthトークンの監査ログ
サードパーティアプリケーションの使用状況とデータアクセスリクエストの追跡組織の管理者として、OAuth Token監査ログを使用して、ドメイン内でどのユーザーがどのサードパーティのモバイルまたはWebアプリケーションを使用しているかを追跡できます。例えば、ユーザーがGoogle Workspace Marketplaceアプリを開くと、ログにはアプリ名と使用者が記録されます。」(1頁1〜5行)
「ログには、Googleコンタクト、カレンダー、ドライブファイル(Google Workspaceのみ)など、サードパーティアプリケーションがGoogleアカウント データへのアクセスを許可されるたびに記録されます。」(1頁6〜7行)
「OAuthトークンの監査ログを開く
1.Google管理コンソールにログインします。
管理者アカウント(@gmail.comで終わらない)を使用してログインします。
2.管理コンソールのホーム ページから [レポート]に移動します。
3.左側の「監査ログ」の下にある「トークン」をクリックします。
4.(オプション)表示するデータをカスタマイズするには、右側の「列の管理」をクリックします。表示または非表示にする列を選択し、[保存]をクリックします。
5.(オプション)ログ・データのフィルタリングとエクスポート、およびアラートの作成方法を確認します。」(1頁8〜15行)
「閲覧可能なデータ
管理コンソールは、OAuth トークンの監査ログを以下のユーザーデータに基づいて作成します。」(1頁16〜17行)

(1頁18〜34行の表)


9 甲9について
甲9には、以下の記載がある。
「【0002】
企業などの組織では組織内の利用者によるクラウドサービスの利用を管理することが求められている。組織のイントラネットと外部のインターネットとの間にはプロキシサーバなど接続制御を行うサーバが置かれる。サーバでは利用者によるクラウドサービスの利用のログを取得している(特許文献1参照)。組織内の利用者によるクラウドサービスの利用を管理するためにこのログを利用するのが一般的である。例えば、情報セキュリティ管理者がログを確認するという方法が採られている。」
「【0006】
本開示のひとつの目的は、利用者によるクラウドサービスの利用を管理するための技術を提供することである。」
「【0012】
企業などの組織に属し、外部のクラウドサービスを業務に利用する者(以下「利用者」という)は、一般的に、組織の情報セキュリティ管理者に対して、クラウドサービスの利用申請を行い、正規に利用許可を得た後、クラウドサービスを利用する。以下、クラウドサービスの利用許可を正規に得た利用者を「正規利用者」という。」

10 甲10について
甲10には、以下の記載がある。
「【0002】
ネットワーク上で提供されるサービス(クラウドサービス等)の利用形態の一つとして、ユーザが一つの中継装置を介して複数のサービスに接続可能とすることでユーザの利便性を高めるものがある。
【0003】
特許文献1には、ユーザが複数のクラウドサーバのそれぞれについて保有するアカウントを示すアカウント情報を管理し、ユーザがログインしたときに、複数のクラウドサーバのそれぞれからユーザによる利用の状況を示す利用情報を取得し、利用情報によって示されるユーザによる複数のクラウドサーバのそれぞれの利用の状況を、当該ユーザがログインに際して操作した機器に備わるディスプレイに一覧表示させる情報システムが開示されている。」
「【0009】
本発明は、ユーザによる複数の外部サービスへの接続を一元管理する中継装置において、自発的に外部サービスの状態を確認してユーザに通知し、ユーザの利便性の向上を図ることを目的とする。」
「【0033】
また、通知部180は、端末装置200から受け付けたリクエストの対象である外部サービス300が利用できない状態である場合に、そのリクエストに対する応答として、外部サービス300が利用できないことを示す通知を行っても良い。さらに、利用できない外部サービス300の代替となり得る機能を有する外部サービス300(以下、代替サービス)が存在する場合、端末装置200に代替サービスへのリクエストを提示する通知や、代替サービスの利用を促す通知を行うようにしても良い。リクエスト制御部170および通知部180は、状態通知手段の一例である。」

第5 当審の判断
1 理由1(新規性)について
(1) 本件発明1について
ア 甲1発明に基づく検討
(ア) 対比
a 構成要件1A及び1Fについて
甲1発明は、「SaaSアプリケーションの概要を低負荷で可視化する」ものであるところ、「SaaSアプリケーション」は、コンピュータで利用されるものであり、「サービス」ということもできる。
また、甲1発明の方法において、「Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティング」しているから、甲1発明は、通信ネットワークを介して通信を行うものである。
そして、甲1発明の「Cloudflare for Teamsを使用して、わずか2クリックで未承認のSaaSアプリケーションを検出し、ブロックする方法」は、アプリケーションを分析したり、アプリケーションへのアクセスをブロックしたりするものであって、情報を処理しているといえるから、情報処理方法であるといえる。
そうすると、甲1発明は、本件発明1と同様、「コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法」であるということができる。

b 構成要件1Bについて
後記c及びdのとおり、甲1発明は、構成要件1C及び1Dのステップを含んでいるということができる。

c 構成要件1Cについて
上記aのとおり、甲1発明は、「SaaSアプリケーションの概要を低負荷で可視化する」ものであるから、「SaaSアプリケーション」、すなわち、サービスの概要を可視化するために、サービスを管理しているといえる。また、甲1の4頁「(シャドーITレポート)」の画像をみても、アプリケーションの列に各アプリケーションが並んでおり、各アプリケーションに対して、アプリケーションのタイプや状況が対応付けられていることからも、甲1発明は、サービスを管理しているといえる。
そうすると、甲1発明は、本件発明1と同様、「サービスを管理」する「管理ステップ」を含むものであるということができる。

d 構成要件1Dについて
甲1発明において、「Cloudflare Gatewayは、すべてのインターネット接続トラフィックをCloudflareのネットワークにルーティングし、未知のセキュリティ脅威からユーザをブロックするためのきめ細かな制御を実施し、お客様の環境で使用されているSaaSアプリケーションの概要を低負荷で可視化」しているから、甲1発明は、ネットワーク(通信ネットワーク)を介して、何らかの情報を取得することにより、使用されているSaaSアプリケーション(サービス)を検出するものであるといえる。
そうすると、甲1発明は、本件発明1と同様、「前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出」する「検出ステップ」を含むものであるということができる。

e 構成要件1Eについて
(a) 本件発明1の構成要件1Eは、「前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成を含むものであるところ、当該構成は、構成要件1Cの「サービスを管理」する「管理ステップ」において、あるサービスが管理されていることを前提に、それ以外のサービス、すなわち、管理されていないサービスを特定するものである。
そうすると、本件発明1では、管理ステップにおいて管理されているサービスと、検出ステップによって検出されたサービスとを比較することにより、管理されていないサービスを特定するものであると認められる。
一方、上記cのとおり、甲1発明は、「サービスを管理」する「管理ステップ」を含むものであるといえるものの、管理されているサービスと検出されたサービスとを比較する等、どのようにして管理されていないサービスを特定するのか不明であり、甲1の記載全体をみても、具体的にどのようにして特定するのかは何ら記載も示唆もされていない。
したがって、甲1発明は、本件発明1の「前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成を有していない。また、当該特定する構成を有していないから、それに続く、「特定した場合、管理されていないサービスが検出された旨を出力する」構成も有していない。

(b) これに対し、異議申立人は、「甲1発明は、未承認のアプリケーションを特定し、当該未承認のアプリケーションに未承認のマークを付けて表示する。つまり、甲1発明は、未承認のアプリケーションを特定した場合、未承認のアプリケーションに未承認のマークを付けて表示することによって、未承認のアプリケーションが検出された旨を出力している」(異議申立書52頁中段)と主張する。
しかしながら、甲1発明においては、「Shadow IT Discovery(シャドーITディスカバリー)では、まず「観察」モードで、Cloudflare for Teamsが組織で使用されているすべてのアプリケーションをカタログ化する機能が実行され、すべてのアプリケーションが分析されるところ、デフォルトでは「未審査」となっており、その後、チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定することができ」るのであって、「Cloudflare for Teams」によって「チームは検出されたアプリケーションをレビューし、数回クリックするだけで、単一のアプリケーションまたは一括で、承認または未承認のアプリケーションを指定すること」は、本件発明1の「前記管理ステップによって管理されていないサービスを特定」する構成に相当するものではないから、甲1発明が本件発明1の「前記管理ステップによって管理されていないサービスを特定」する構成を有しているとはいえない。
したがって、異議申立人の主張は採用できない。

以上によれば、本件発明1と甲1発明は、以下の一致点、相違点を有する。

[一致点]
1A コンピュータを利用し、通信ネットワークを介して通信を行う情報処理方法であって、
1B 以下のステップを含み、
1C 管理ステップでは、サービスを管理し、
1D 検出ステップでは、前記通信ネットワークを介して情報を取得することにより、利用されているサービスを検出する
1F 情報処理方法。

[相違点]
本件発明1は、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定した場合、管理されていないサービスが検出された旨を出力する」構成、すなわち、構成要件1Eを備えるのに対し、甲1発明は、そのような構成(構成要件1E)を備えない点。

(イ) 判断
上記(ア)のとおり、本件発明1と甲1発明を対比すると、[相違点]に係る構成を有するから、本件発明1は、甲1発明であるとはいえない。

イ 甲2〜4に記載された発明に基づく検討
(ア) 対比・判断
異議申立人は、本件発明1は、甲2〜4に記載された発明であると主張する。
しかしながら、甲2〜4に記載された事項は、上記第4の2〜4のとおりであるところ、甲2〜4には、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」することは記載されていないし、それに続く、「特定した場合、管理されていないサービスが検出された旨を出力する」ことも記載されていないから、上記アの[相違点]に係る構成は記載されていない。
そうすると、本件発明1と、甲2〜4から認定することができる発明を対比すると、上記アの[相違点]に係る構成で相違することとなる。
したがって、本件発明1は、甲2〜4に記載された発明であるとはいえない。

(イ) 異議申立人の主張について
a 甲2について
異議申立人は、「そして、甲2発明は、「非認可」のアプリケーションをフィルタリングする。そして、甲2発明は、「非認可」でフィルタリングされたアプリケーションを表示する。・・・つまり、甲2発明は、非認可のアプリケーションを特定した場合、非認可のアプリケーションをフィルタリングして表示することによって、非認可のアプリケーションが検出された旨を出力している。」(異議申立書72頁上段)と主張する。
しかしながら、甲2には、「アプリケーションに「認可済み」、「非認可」、「監視中」のタグが付いている場合、タグが付いていないアプリケーションをフィルタリングすることができます。これらのアプリケーションは、分析段階の後、さらなるレビューと決定が必要なアプリケーションです。」(上記第4の2、3頁5行〜14行)と記載されているのみであって、「「非認可」でフィルタリングされたアプリケーションを表示」したり、「非認可のアプリケーションが検出された旨を出力」したりすることは記載も示唆もされていない。

b 甲3について
異議申立人は、「甲3発明は、検出ステップによって検出された利用されているサービスから、危険度の高いアプリを特定した場合、危険度の高いアプリを検出された旨を出力する。」(異議申立書83頁上段)ものであり、「甲3発明の「危険度の高いアプリ」は、管理対象でない危険度の高いアプリを示すことから、「管理対象でないサービス」に相当する。」(異議申立書176頁中段)と主張する。
しかしながら、甲3には、「危険度の低いアプリ(サービス)」が管理されていることを前提に、管理されているサービスと、検出されたサービスとを比較することにより、管理されていない「危険度の高いアプリ(サービス)」を特定することは記載も示唆もされていない。

c 甲4について
異議申立人は、甲4の[0417]、[0419]、[0420]、図42及び図75の記載を根拠とし、甲4発明は、CSF100を使用し、企業が使用する「シャドーIT」の迅速な評価レポートを作成するから、検出ステップによって検出された利用されているアプリケーションから、認可されていないアプリケーションを特定している旨主張する(異議申立書108頁中段)。
しかしながら、異議申立人の主張する甲4の記載箇所をみても、企業に認可されていないシャドーITがあること([0417])、シャドーITを含めユーザが使用しているITリソースを可視化したいというニーズがあること([0419])、図42のシャドーIT報告の例や、図75のシャドーIT情報に提供することができるレポートの種々の形態などが記載されているだけであって、認可されているアプリケーション(サービス)が管理されていることを前提に、管理されているサービスと、利用されているアプリケーション(サービス)とを比較することにより、管理されていないアプリケーション(サービス)を特定することは記載も示唆もされていない。

d 小括
以上のとおり、異議申立人の主張は採用できない。

(2) 本件発明2について
ア 甲4に記載された発明に基づく検討
異議申立人は、本件発明2は、甲4に記載された発明であると主張する。
そこで検討するに、本件発明2は、構成要件2Eを備えるものであるところ、当該構成要件2Eは、本件発明1の構成要件1Eのうち、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成と同じである(上記第2参照。)。
そうすると、上記(1)イのとおり、甲4には、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成は記載されていないから、本件発明2と、甲4に記載された発明を対比すると、当該構成(以下「[相違点′]」という。)で相違することとなる。
したがって、本件発明2は、甲4に記載された発明であるとはいえない。

イ 甲5に記載された発明に基づく検討
(ア) 対比・判断
異議申立人は、本件発明2は、甲5に記載された発明であると主張する。
しかしながら、甲5に記載された事項は、上記第4の5のとおりであるところ、甲5にも、上記アの[相違点′]に係る構成は記載されていない。
そうすると、本件発明2と、甲5に記載された発明を対比すると、上記[相違点′]に係る構成を有することになる。
したがって、本件発明2は、甲5に記載された発明であるとはいえない。

(イ) 異議申立人の主張について
異議申立人は、「甲5発明は、非承認(非認可)のクラウドサービスを検出する。([0005]、[0012]) つまり、甲5発明は、検出された利用されているサービスから、非承認のクラウドサービスを特定する。」と主張する(異議申立書131頁上段)。
しかしながら、異議申立人の主張する甲5の記載箇所をみても、「クラウドサービスにアクセスする要求が検出された場合に、ユーザとクラウドサービスとの間のインタラクションを監視することと、ユーザとクラウドサービスとの間のインタラクションがクラウドサービスの非認可の使用を表しているか否かを判定することと、クラウドサービスの非認可の使用に関連するリスクを管理すること」([0005])、「クラウドベースのサービスの非承認使用に関連するリスクを管理する」こと([0005])などが記載されているだけであって、複数のクラウドサービスの存在を前提として「非承認のクラウドサービスを特定する」ことは記載されていない。
そして、甲5には、承認されているクラウドサービスが管理されていることを前提に、管理されているクラウドサービスと、利用されている非承認のクラウドサービスとを比較することにより、管理されていない非承認のクラウドサービスを特定することは記載も示唆もされていない。
したがって、異議申立人の主張は採用できない。

(3) 本件発明3について
ア 対比・判断
異議申立人は、本件発明3は、甲6に記載された発明であると主張する。
そこで検討するに、本件発明3は、構成要件3Eを備えるものであって、当該構成要件3Eは、本件発明1の構成要件1Eのうち、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定」する構成([相違点′])と同じである(上記第2参照。)。
そして、甲6に記載された事項は、上記第4の6のとおりであるところ、甲6には、上記[相違点′]に係る構成は記載されていない。
そうすると、本件発明3と、甲6に記載された発明を対比すると、[相違点′]に係る構成を有することになる。
したがって、本件発明3は、甲6に記載された発明であるとはいえない。

イ 異議申立人の主張について
異議申立人は、甲6の[0026]の記載を根拠として、「甲6発明は、利用されているサービスから、シャドーITのクラウドサービスを特定する。」と主張する(異議申立書142頁下段)。
しかしながら、異議申立人の主張する甲6の記載箇所をみても、「クラウドサービスヘの加入とクラウドサービスの使用を示すパターンの存在についてメッセージを分析する。メッセージ自体およびそのメタデータのこのような詳細な検査により、利用のタイプが明らかになり、・・・きめ細かなシャドーITディスカバリーが可能になる」になると記載されているだけであって、具体的にどのようにしてシャドーITのクラウドサービスであると特定するのかは記載されていない。
そして、甲6には、シャドーIT以外のクラウドサービスが管理されていることを前提に、管理されているクラウドサービスと、利用されているシャドーITのクラウドサービスとを比較することにより、管理されていないシャドーITのクラウドサービスを特定することは記載も示唆もされていない。
したがって、異議申立人の主張は採用できない。

(4) 本件発明4及び5について
異議申立人は、本件発明4及び5は、甲1発明であると主張する。
しかしながら、本件発明4及び5は、本件発明1を限定した発明を含むものである。
そうすると、甲1発明と対比すると、少なくとも、上記(1)アの[相違点]に係る構成を有することになる。
したがって、本件発明4及び5は、甲1発明であるとはいえない。

(5) 本件発明17及び18について
異議申立人は、本件発明17及び18は、甲1発明及び甲2〜4に記載された発明であると主張する。
しかしながら、本件発明17及び18は、それぞれ、プログラム及び情報処理装置の発明であるところ、いずれも、本件発明1に係る情報処理方法の発明とカテゴリーが相違するのみの発明を含むものである。
そうすると、本件発明1が、上記(1)のとおり、甲1発明及び甲2〜4に記載された発明であるといえない以上、本件発明17及び18も、甲1発明及び甲2〜4に記載された発明であるとはいえない。

(6) 理由1(新規性)のまとめ
以上によれば、本件特許は、特許法29条1項の規定に違反してされたものではない。
したがって、異議申立人の主張する理由1は理由がない。

2 理由2(進歩性)について
(1) 本件発明1、17及び18について
異議申立人は、本件発明1、17及び18は、甲1発明及び甲2〜4に記載された発明のいずれかに基づいて、当業者が容易に発明をすることができたものであると主張する。
しかしながら、本件発明1、17及び18と、甲1発明及び甲2〜4に記載された発明を対比すると、上記1(1)アの[相違点]に係る構成を有するところ、当該構成は、異議申立人が提出する甲5〜10には記載されていないし、周知技術であるということもできない。
そうすると、本件発明1、17及び18は、甲1発明及び甲2〜4に記載された発明のいずれかに基づいて、当業者が容易に発明をすることができたものであるとはいえない。

(2) 本件発明2について
異議申立人は、本件発明2は、甲4及び甲5に記載された発明のいずれかに基づいて、当業者が容易に発明をすることができたものであると主張する。
しかしながら、本件発明2と、甲4及び甲5に記載された発明を対比すると、上記1(2)アの[相違点′]に係る構成を有するところ、当該構成は、異議申立人が提出する甲1〜3及び6〜10には記載されていないし、周知技術であるということもできない。
そうすると、本件発明2は、甲4及び甲5に記載された発明のいずれかに基づいて、当業者が容易に発明をすることができたものであるとはいえない。

(3) 本件発明3について
異議申立人は、本件発明3は、甲6に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。
しかしながら、本件発明3と、甲6に記載された発明を対比すると、上記1(2)アの[相違点′]に係る構成を有するところ、当該構成は、異議申立人が提出する甲1〜5及び7〜10には記載されていないし、周知技術であるということもできない。
そうすると、本件発明3は、甲6に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。

(4) 本件発明4及び5について
異議申立人は、本件発明4及び5は、甲1発明に基づいて、当業者が容易に発明をすることができたものであると主張する。
しかしながら、本件発明4及び5は、本件発明1を限定した発明を含むものであるから、上記(1)のとおり、本件発明1が甲1発明に基づいて、当業者が容易に発明をすることができたものであるといえない以上、本件発明4及び5も、当業者が容易に発明をすることができたものであるとはいえない。

(5) 本件発明6、7、10及び12について
異議申立人は、本件発明6、7、10及び12は、甲1発明及び甲7に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。
しかしながら、本件発明6、7、10及び12は、本件発明1を限定した発明を含むものであるから、本件発明6、7、10及び12と、甲1発明とを対比すると、上記1(1)アの[相違点]に係る構成を有するところ、上述のとおり、当該構成は、異議申立人が提出する甲7には記載されていないし、周知技術であるということもできない。
そうすると、本件発明6、7、10及び12は、甲1発明及び甲7に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。

(6) 本件発明8、9及び14について
異議申立人は、本件発明8、9及び14は、甲3及び甲8に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。
しかしながら、本件発明8、9及び14は、本件発明1を限定した発明を含むものであるから、本件発明8、9及び14と、甲3に記載された発明とを対比すると、上記1(1)アの[相違点]に係る構成を有するところ、上述のとおり、当該構成は、異議申立人が提出する甲8には記載されていないし、周知技術であるということもできない。
そうすると、本件発明8、9及び14は、甲3及び甲8に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。

(7) 本件発明11及び13について
異議申立人は、本件発明11は、甲1発明及び甲9に記載された発明に基づいて、また、本件発明13は、甲1発明及び甲6に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。
しかしながら、本件発明11及び13は、本件発明1を限定した発明を含むものであるから、本件発明11及び13と、甲1発明とを対比すると、上記1(1)アの[相違点]に係る構成を有するところ、上述のとおり、当該構成は、異議申立人が提出する甲9や6には記載されていないし、周知技術であるということもできない。
そうすると、本件発明11は、甲1発明及び甲9に記載された発明に基づいて、また、本件発明13は、甲1発明及び甲6に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。

(8) 本件発明15及び16について
異議申立人は、本件発明15は、甲4及び甲7に記載された発明に基づいて、また、本件発明16は、甲4、甲7及び甲10に記載された発明に基づいて、当業者が容易に発明をすることができたものであると主張する。
しかしながら、本件発明15及び16は、本件発明1を限定した発明を含むものであるから、本件発明15及び16と、甲4に記載された発明とを対比すると、上記1(1)アの[相違点]に係る構成を有するところ、上述のとおり、当該構成は、異議申立人が提出する甲7や10には記載されていないし、周知技術であるということもできない。
そうすると、本件発明15は、甲4及び甲7に記載された発明に基づいて、また、本件発明16は、甲4、甲7及び甲10に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえない。

(9) 理由2(進歩性)のまとめ
以上によれば、本件特許は、特許法29条2項の規定に違反してされたものではない。
したがって、異議申立人の主張する理由2は理由がない。

3 理由3(明確性)について
(1) 判断
異議申立人は、本件発明1の構成要件1Eにおいて、「管理されていないサービスが検出された旨」及び「出力する」の意味が不明であるから、本件発明1は、明確であるとはいえず、本件特許は、特許法36条6項2号に規定する要件を満たしていない特許出願に対してされたものであると主張するから、以下判断する(本件発明4〜18についても同旨。)。

ア 特許請求の範囲の記載について
本件発明1の構成要件1Eについて、特許請求の範囲の請求項1には、「特定ステップでは、前記検出ステップによって検出された前記利用されているサービスから、前記管理ステップによって管理されていないサービスを特定した場合、管理されていないサービスが検出された旨を出力する」と記載されているところ、サービスを管理することについては、構成要件1Cとして、「管理ステップでは、サービスを管理」することが記載されている(上記第2参照、再掲。)。
そうすると、構成要件1Eにおける「管理されていないサービスが検出された旨」とは、構成要件1Cの「サービスを管理」する「管理ステップ」において、あるサービスが管理されていることを前提に、それ以外のサービス、すなわち、管理されていないサービスが検出されたことを意味することは明らかである。
そして、構成要件1Eにおける「出力する」ことについても、「出力」とは、情報などを外部に出すという意味でも用いられるから、結局、構成要件1Eにおける「管理されていないサービスが検出された旨を出力する」とは、管理ステップにおいて管理されていないサービスが検出された場合、検出された旨を外部に出す、という意味であることが明確に理解できる。

イ 発明の詳細な説明について
上記アで検討したとおり、本件発明1の構成要件1Eの記載は明確であるところ、念のため、発明の詳細な説明をみても、構成要件1Eにおける「管理されていないサービスが検出された旨を出力する」ことの意味は明確である。
すなわち、発明の詳細な説明には、「特定部103は、新たなサービスつまり、管理部101で管理されていないサービスを特定した場合には、予め指定された通知先に、新たなサービスが検出された旨を示す警告を発するようにしてもよい。この警告は、特定部103で行うようにしてもよいが、情報処理装置1に図示しない警告部を設けるようにしてもよい。」(【0028】)と具体的な処理が記載されているところ、当該記載によれば、特定部103において、「管理されていないサービスを特定した場合」に、特定部103やそれ以外の警告部で「警告を発する」ことが明確に理解でき、このような理解は、上記アの特許請求の範囲の記載における理解に沿うものである。

(2) 理由3(明確性)のまとめ
以上によれば、本件発明1には、異議申立人が主張する不明確な点はなく、ほかに不明確な点もないから、本件発明1は明確である(本件発明4〜18についても同様である。)。
そうすると、本件発明1及び4〜18は、明確であるから、本件特許は、特許法36条6項2号に規定する要件を満たしていない特許出願に対してされたものであるとはいえない。
したがって、異議申立人の主張する理由3は理由がない。

4 理由4(サポート要件)について
(1) 判断
異議申立人は、本件発明1の構成要件1Eにおける「管理されていないサービスが検出された旨」及び「出力する」ことの具体例が発明の詳細な説明又は図面には記載されていないから、本件発明1は、発明の詳細な説明に記載したものではなく、本件特許は、特許法36条6項1号に規定する要件を満たしていない特許出願に対してされたものであると主張する(本件発明4〜18についても同旨。)。
しかしながら、異議申立人の主張する本件発明1の構成要件1Eにおける「管理されていないサービスが検出された旨」及び「出力する」ことの具体的な処理は、上記3のとおり、本件明細書の発明の詳細な説明の【0028】に記載されている(なお、「出力する」ことの具体的な処理としては、例えば、異議申立書(207頁下段)において、「何等かの警告マークを管理者の画面に「表示する」ことであるのか、「管理されていないサービスが検出された」というメッセージを管理者の画面に「表示する」ことであるのか、「印刷出力する」ことであるのか、警告メールを管理者に送信することであるのか」と記載されているように、当業者であれば種々容易に想定し得るものである。)。

(2) 理由4(サポート要件)のまとめ
以上によれば、本件発明1は、本件明細書の発明の詳細な説明に記載したものである(本件発明4〜18についても同様である。)。
そうすると、本件発明1及び4〜18は、発明の詳細な説明に記載したものであるから、本件特許は、特許法36条6項1号に規定する要件を満たしていない特許出願に対してされたものであるとはいえない。
したがって、異議申立人の主張する理由4は理由がない。

5 理由5(新規事項の追加)について
(1) 判断
異議申立人は、本件特許に係る出願において、令和5年2月24日付けで提出された手続補正書においてされた、本件発明1の構成要件1Eの「出力する」という補正(以下「本件補正」という。)について、出願当初明細書等に記載された「警告を発する」以外の処理を含むように補正されており、本件補正は、出願当初明細書等に記載した事項の範囲を超えるものであるから、本件特許は、特許法第17条の2第3項に規定する要件を満たしていない特許出願に対してされたものであると主張する(本件発明4〜18についても同旨。)。
しかしながら、上記4のとおり、「出力する」ことについて、「警告を発する」以外の処理として、当業者であれば具体的な処理を種々容易に想定し得るものであるから、本件補正において、「出力する」と補正されたことで、出願当初明細書等に記載した事項の範囲を超えるものになったということはできない。

(2) 理由5(新規事項の追加)のまとめ
以上によれば、本件補正は、出願当初明細書等に記載した事項の範囲を超えるものであるとはいえないから、本件特許は、特許法第17条の2第3項に規定する要件を満たしていない補正をした特許出願に対してされたものであるとはいえない。
したがって、異議申立人の主張する理由5は理由がない。

第6 むすび
以上の次第であるから、特許異議の申立ての理由及び異議申立人の提出した証拠によっては、本件特許を取り消すことはできない。
また、他に本件特許を取り消すべき理由を発見しない。
よって、結論のとおり決定する。
 
異議決定日 2024-01-25 
出願番号 P2022-039621
審決分類 P 1 651・ - Y (G06Q)
最終処分 07   維持
特許庁審判長 佐藤 智康
特許庁審判官 古川 哲也
梶尾 誠哉
登録日 2023-04-17 
登録番号 7265054
権利者 株式会社マネーフォワード
発明の名称 情報処理装置及びプログラム  
代理人 弁理士法人IPX  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ