2024-700115

特許第７３２５８７９号発明「プログラム、通知装置、および通知方法」の特許異議申立事件について、次のとおり決定する。

結 論 特許第７３２５８７９号の請求項２～４、１２～１４、１６～１８に係る特許を取り消す。 特許第７３２５８７９号の請求項１、５、１１、１５に係る特許を維持する。

理 由 第１ 手続の経緯 特許第７３２５８７９号（以下「本件特許」という。）についての出願は、令和５年５月２日に出願され、同年５年８月４日にその特許権の設定登録がされ、同年８月１５日に特許掲載公報が発行された。その特許ついての本件特許異議の申立ての経緯は、次のとおりである。 令和６年 ２月 ８日 ：特許異議申立人 塩田 将司（以下「特許異議申立人」という。）による請求項１～５、１１～１８に係る特許に対する特許異議の申立て 令和６年 ４月１６日 ：手続補正書（方式） 令和６年 ６月１２日付け：取消理由通知書 なお、令和６年６月１２日付け取消理由通知書により、特許権者 ａｍｐｔａｌｋ株式会社（以下「特許権者」という。）に取消理由を通知し、期間を指定して意見書を提出する機会を与えたが、特許権者による意見書の提出はされていない。 第２ 本件発明 特許第７３２５８７９号の請求項１～１８の特許に係る発明（以下、それぞれ「本件発明１」～「本件発明１８」といい、これらを総称して「本件発明」という。）は、本件特許の特許請求の範囲の請求項１～１８に記載された次の事項により特定されるとおりのものである。 「【請求項１】 コンピュータを、 会話アプリを識別するアプリ識別子に対応付けて、当該会話アプリを用いた会話に関する会話情報を取得する会話情報取得部と、 前記会話情報取得部が取得した前記会話情報が、会話情報に関する通知条件であり、前記アプリ識別子に対応付く通知条件に合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部として機能させるためのプログラムであって、 前記会話情報は、会話の内容を特定する情報である内容情報、着信があったことを示す情報である着信情報、不在着信があったことを示す情報である不在着信情報のうちの１または２種類以上の情報である、プログラム。 【請求項２】 コンピュータを、 会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた着信があったことを特定する着信情報を含む会話情報を取得する会話情報取得部と、 前記会話情報取得部が取得した前記会話情報が、着信があったことである通知条件に合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部として機能させるためのプログラム。 【請求項３】 コンピュータを、 会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた不在着信があったことを特定する不在着信情報を含む会話情報を取得する会話情報取得部と、 前記会話情報取得部が取得した前記会話情報が、不在着信があったことである通知条件に合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部として機能させるためのプログラム。 【請求項４】 コンピュータを、 会話アプリを用いた会話に関する情報であり、会話の内容を特定する内容情報を有する会話情報を取得する会話情報取得部と、 前記内容情報の解析結果を取得する解析部と、 前記解析結果を出力する解析出力部と、 前記解析結果に対するコメントを受け付けるコメント受付部と、 内容情報の解析結果に対するコメントに関する条件である通知条件に、前記コメント受付部が受け付けた前記コメントが合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部として機能させるためのプログラム。 【請求項５】 前記通知条件は、ユーザごとに管理されており、 前記会話情報取得部は、 ユーザ識別子に対応付いた前記会話情報を取得し、 前記判断部は、 前記会話情報に対応付く前記ユーザ識別子で識別されるユーザに対応する前記通知条件に合致するか否かを判断するものとして、前記コンピュータを機能させるための請求項１または請求項４記載のプログラム。 【請求項６】 １または２以上のユーザ識別子に対応付く１以上のチーム識別子が格納されるチーム管理部にアクセス可能な前記コンピュータを機能させるためのプログラムであって、 前記通知条件は、チーム識別子に対応付いており、 前記会話情報取得部は、 ユーザ識別子に対応付いた前記会話情報を取得し、 前記判断部は、 前記ユーザ識別子に対応付く前記チーム識別子に対応付く前記通知条件に合致するか否かを判断するものとして、前記コンピュータを機能させるための請求項１または請求項４記載のプログラム。 【請求項７】 前記会話情報は、ユーザ識別子に対応付いており、 前記コンピュータを、 １以上の各ユーザ識別子に対応するユーザ情報を管理するユーザ管理サーバから、前記会話情報に対応付く前記ユーザ識別子と対になるユーザ情報を取得し、当該ユーザ情報を有する通知情報を取得する通知情報取得部としてさらに機能させ、 前記通知部は、 前記通知情報取得部が取得した前記通知情報を送信するものとして、前記コンピュータを機能させるための請求項１から請求項４いずれか一項に記載のプログラム。 【請求項８】 前記会話情報は、ユーザ識別子に対応付いており、 前記コンピュータを、 １以上の各ユーザ識別子に対応するユーザ情報を管理するユーザ管理サーバから、前記会話情報に対応付く前記ユーザ識別子と対になるユーザ情報を取得し、当該ユーザ情報を有する通知情報を取得する通知情報取得部としてさらに機能させ、 前記通知部は、 前記通知情報取得部が取得した前記通知情報を送信するものとして、前記コンピュータを機能させるための請求項１から請求項４いずれか一項に記載のプログラム。 【請求項９】 前記会話情報は、会話の内容を特定する内容情報を有し、 前記通知条件は、前記内容情報の解析結果が取得されたことである請求項１または請求項４記載のプログラム。 【請求項１０】 前記会話情報は、会話の内容を特定する内容情報を有し、 前記通知条件は、前記内容情報の解析結果に関する条件であり、 前記コンピュータを、 前記内容情報の解析結果を取得する解析部としてさらに機能させ、 前記判断部は、 前記解析結果が前記通知条件に合致するか否かを判断するものとして、前記コンピュータを機能させるための請求項１記載のプログラム。 【請求項１１】 会話アプリを識別するアプリ識別子に対応付けて、当該会話アプリを用いた会話に関する会話情報を取得する会話情報取得部と、 前記会話情報取得部が取得した前記会話情報が、会話情報に関する通知条件であり、前記アプリ識別子に対応付く通知条件に合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部とを具備し、 前記会話情報は、会話の内容を特定する情報である内容情報、着信があったことを示す情報である着信情報、不在着信があったことを示す情報である不在着信情報のうちの１または２種類以上の情報である、通知装置。 【請求項１２】 会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた着信があったことを特定する着信情報を含む会話情報を取得する会話情報取得部と、 前記会話情報取得部が取得した前記会話情報が、着信があったことである通知条件に合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部とを具備する通知装置。 【請求項１３】 会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた不在着信があったことを特定する不在着信情報を含む会話情報を取得する会話情報取得部と、 前記会話情報取得部が取得した前記会話情報が、不在着信があったことである通知条件に合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部とを具備する通知装置。 【請求項１４】 会話アプリを用いた会話に関する情報であり、会話の内容を特定する内容情報を有する会話情報を取得する会話情報取得部と、 前記内容情報の解析結果を取得する解析部と、 前記解析結果を出力する解析出力部と、 前記解析結果に対するコメントを受け付けるコメント受付部と、 内容情報の解析結果に対するコメントに関する条件である通知条件に、前記コメント受付部が受け付けた前記コメントが合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部とを具備する通知装置。 【請求項１５】 会話情報取得部と、判断部と、通知部とにより実現される通知方法であって、 前記会話情報取得部が、会話アプリを識別するアプリ識別子に対応付けて、当該会話アプリを用いた会話に関する会話情報を取得する会話情報取得ステップと、 前記判断部が、前記会話情報取得ステップで取得された前記会話情報が、会話情報に関する通知条件であり、前記アプリ識別子に対応付く通知条件に合致するか否かを判断する判断ステップと、 前記通知部が、前記通知条件に合致すると前記判断ステップで判断された場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知ステップとを具備し、 前記会話情報は、会話の内容を特定する情報である内容情報、着信があったことを示す情報である着信情報、不在着信があったことを示す情報である不在着信情報のうちの１または２種類以上の情報である、通知方法。 【請求項１６】 会話情報取得部と、判断部と、通知部とにより実現される通知方法であって、 前記会話情報取得部が、会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた着信があったことを特定する着信情報を含む会話情報を取得する会話情報取得ステップと、 前記判断部が、前記会話情報取得ステップで取得された前記会話情報が、着信があったことである通知条件に合致するか否かを判断する判断ステップと、 前記通知部が、前記通知条件に合致すると前記判断ステップで判断された場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知ステップとを具備する通知方法。 【請求項１７】 会話情報取得部と、判断部と、通知部とにより実現される通知方法であって、 前記会話情報取得部が、会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた不在着信があったことを特定する不在着信情報を含む会話情報を取得する会話情報取得ステップと、 前記判断部が、前記会話情報取得ステップで取得された前記会話情報が、不在着信があったことである通知条件に合致するか否かを判断する判断ステップと、 前記通知部が、前記通知条件に合致すると前記判断ステップで判断された場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知ステップとを具備する通知方法。 【請求項１８】 会話情報取得部と、解析部と、解析出力部と、コメント受付部と、判断部と、通知部とにより実現される通知方法であって、 前記会話情報取得部が、会話アプリを用いた会話に関する情報であり、会話の内容を特定する内容情報を有する会話情報を取得する会話情報取得ステップと、 前記解析部が、前記内容情報の解析結果を取得する解析ステップと、 前記解析出力部が、前記解析結果を出力する解析出力ステップと、 前記コメント受付部が、前記解析結果に対するコメントを受け付けるコメント受付ステップと、 前記判断部が、内容情報の解析結果に対するコメントに関する条件である通知条件に、前記コメント受付ステップで受け付けられた前記コメントが合致するか否かを判断する判断ステップと、 前記通知部が、前記通知条件に合致すると前記判断ステップで判断された場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知ステップとを具備する通知方法。」 第３ 取消理由通知書に記載した取消理由について １ 取消理由の概要 当審において令和６年６月１２日付け取消理由通知書で特許権者に通知した取消理由の概要は、次のとおりである。 （新規性）請求項３、１３、１７に係る発明は、本件特許出願前に日本国内又は外国において、頒布された刊行物に記載された又は電気通信回線を通じて公衆に利用可能となった以下の甲第７号証（以下「甲７」という。）に記載された発明であって、特許法第２９条第１項第３号に該当するから、請求項３、１３、１７に係る特許は、特許法第２９条第１項の規定に違反してされたものである。 請求項４、１４、１８に係る発明は、本件特許出願前に日本国内又は外国において、頒布された刊行物に記載された又は電気通信回線を通じて公衆に利用可能となった以下の甲第５号証（以下「甲５」という。）に記載された発明であって、特許法第２９条第１項第３号に該当するから、請求項４、１４、１８に係る特許は、特許法第２９条第１項の規定に違反してされたものである。 （進歩性）請求項２、１２、１６に係る発明は、本件特許出願前に日本国内又は外国において、頒布された刊行物に記載された又は電気通信回線を通じて公衆に利用可能となった以下の甲第６号証（以下「甲６」という。）に記載された発明に基いて、本件特許出願前にその発明の属する技術の分野における通常の知識を有する者（以下「当業者」という。）が容易に発明をすることができたものであるから、請求項２、１２、１６に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 請求項３、１３、１７に係る発明は、本件特許出願前に日本国内又は外国において、頒布された刊行物に記載された又は電気通信回線を通じて公衆に利用可能となった以下の甲７に記載された発明に基いて、本件特許出願前に当業者が容易に発明をすることができたものであるから、請求項３、１３、１７に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 請求項４、１４、１８に係る発明は、本件特許出願前に日本国内又は外国において、頒布された刊行物に記載された又は電気通信回線を通じて公衆に利用可能となった以下の甲５に記載された発明に基いて、本件特許出願前に当業者が容易に発明をすることができたものであるから、請求項４、１４、１８に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 甲５：オンライン商談自動化ツールのアンプトークが「Slack」と連携しオンライン商談の書き起こし・コメントを通知可能に、[online]、2022年2月7日、株式会社 PR TIMES、インターネット<https://prtimes.jp/main/html/rd/p/000000007.000084890.html> 甲６：「 BIZTEL 」 が音声テキスト化機能・音声認識 IVR・Slack 連携などの新機能を搭載した 「 最新バージョン 3.3.0 」 を提供開始、[online]、2021年1月15日、株式会社 PR TIMES、インターネット<https://prtimes.jp/main/html/rd/p/000000006.000007832.html> 甲７：会話サマリーAI電話”ピクポン”、Slackへの不在着信通知機能(β版)をリリース、 [online]、2021年1月29日、株式会社 PR TIMES、インターネット<https://prtimes.jp/main/html/rd/p/000000022.000033268.html> ２ 甲５、甲６、甲７の記載 （１）甲５ ア 甲５の記載事項 甲５には、次の事項が記載されている。なお、下線は当審で付与したものである（以下、同じ。）。 「amptalk株式会社（本社：東京都渋谷区、代表取締役：猪瀬 竜馬、以下：amptalk）は、Zoom商談の録画やZoom Phone、Dialpadでの架電内容を自動で取得して書き起こし、さらにSalesforceに自動出力するオンライン商談自動化ツール「アンプトーク（以下：アンプトーク）」と、ビジネスチャットツール「Slack」を連携する新機能をリリースしたことをお知らせいたします。」 「▼アンプトークとは アンプトーク( https://amptalk.co.jp/ )は、Zoom MeetingsやDialpad、Zoom Phoneなどを利用したオンラインの商談や架電内容を書き起こし、自動でSalesforceに入力する仕組みを備えたオンライン商談自動化ツールです。アンプトークをご利用いただくことにより、インサイドセールスやフィールドセールス、カスタマーサクセスの方々は商談の記録などの付加業務の負担が減り、商談に集中できるようになります。また、アンプトーク独自のシステムで商談の内容を自動解析することで、トーク比率、トーク速度や誰が、何を、どれくらい話したのかを可視化することができるようになりました。それらを明らかにすることで、営業のトッププレーヤーとそれ以外のプレーヤーの差を明らかにし、育成指導やナレッジシェアの工数を減らしながらスキルを改善、受注率の向上につなげることができます。」 「▼Slack連携機能でできること Zoom商談やZoom Phoneやdialpadの会話内容の書き起こしや解析が（当審注：「解析の」の誤記と認める。）完了を通知 Salesforce連携で取得した情報を通知 会話の特定の箇所へのタイムスタンプ付きでのコメントの通知 ユーザータグによる通知チャンネルの出し分け ［図：0001418239000001.jpg］ Slack通知 ▼Slack連携する方法 アンプトークを契約後にアンプトークにログイン 連携画面からSlackの連携ボタンを押す アクセスを許可 通知するタイミングやチャンネル、ユーザータグの設定を実施 ［図：0001418239000002.jpg］ 連携画面 ▼Slack連携するメリット ユーザー毎に付与されたタグの情報で通知するチャンネルを出し分けるため、インサイドセールスやフィールドセールスなどチャンネルを分けて通知して効率化が可能 コメントや解析結果の通知をタグに応じて出し分けるため、ユーザーの商談へのアクセスやコミュニケーションが効率よく行える ▼アンプトークのご利用条件 サービスページ：https://amptalk.co.jp/ 推奨環境 ：Windows, MacOS 最新バージョン 推奨ブラウザ ：Google Chrome 最新バージョン 対応している電話ツール：Dialpad, Zoom Phone 対応している商談ツール：Zoom 対応しているSFA ：Salesforce 価格 ：初期費用50,000円、月額3,500円/ユーザー」 イ 甲５発明 前記アの「アンプトーク」は、その「利用条件」の「推奨環境」が「Windows, MacOS 最新バージョン」であるから、該「アンプトーク」は、コンピュータプログラムで実装されていると解される。 前記アの「Zoom商談の録画やZoom Phone、Dialpadでの架電内容」、「Zoom商談やZoom Phoneやdialpadの会話内容」との記載の「Zoom商談」とは、「Zoom MeetingsやDialpad、Zoom Phoneなどを利用したオンラインの商談や架電内容」との記載に照らせば、「Zoom Meetings」でのオンライン「商談」のことであると解される。 前記アの「コメントや解析結果の通知をタグに応じて出し分ける」との記載の「タグ」とは、「ユーザータグによる通知チャンネルの出し分け」及び「通知するタイミングやチャンネル、ユーザータグの設定を実施」との記載に照らせば、「ユーザータグ」（ユーザー毎に付与されたタグ）のことと解される。同様に、上記「コメントや解析結果の通知をタグに応じて出し分ける」の「出し分ける」とは、「通知チャンネル」に「出し分ける」ことと解される。 以上によれば、甲５には、次の発明（以下「甲５発明」という。）が記載されていると認められる。 「Zoom Meetingsでのオンライン商談の録画やZoom Phone、Dialpadでの架電内容を自動で取得して書き起こし、さらにSalesforceに自動出力するオンライン商談自動化ツールのアンプトークであって、 コンピュータプログラムで実装され、 ビジネスチャットツールのSlackと連携し、 Slack連携機能でできることには、会話の特定の箇所へのタイムスタンプ付きでのコメントの通知、ユーザータグによる通知チャンネルの出し分け、があり、 Slack連携する方法には、通知するタイミングやチャンネル、ユーザータグの設定を実施、があり、 コメントの通知をユーザータグに応じて通知チャンネルに出し分ける アンプトーク」 （２）甲６ ア 甲６の記載事項 甲６には、次の事項が記載されている。 「４年連続で国内シェア第１位のクラウド型 CTI / コールセンターシステム 「 BIZTEL （ ビズテル ） 」 を展開する株式会社リンク （ 本社：東京都港区、代表取締役社長：岡田元治 ） は、本日より、音声認識サービスなどコールセンター業務を効率化する先進的な機能を搭載した BIZTEL の最新版「 バージョン 3.3.0 」 の提供を開始します。 BIZTEL は、企業向けインターネット電話サービスを幅広く展開するクラウド型テレフォニーシステムのパイオニアです。インターネットとPCさえあればコールセンターが構築できる 「 BIZTEL コールセンター」 や、在宅勤務に便利な機能をパッケージしたビジネスフォンサービス 「 BIZTEL テレワーク 」 、モバイル端末の内線化が手軽に行える「 BIZTEL モバイル 」 など、クラウドの強みを最大限に活かしたサービスラインナップが特長です。」 「また、電話の着信や通話に関する情報を Slack に自動投稿してタイムリーに周知することができる「 Slack連携 」 のほか、追加のセキュリティ対策機能を実装するなど、スタッフが離れた場所にいても効率的かつ安全に業務するためのサービスを一層充実させました。」 「● Slack 連携 （ 有償オプション ） Slack と連携し、電話着信の通知や通話録音ファイルのリンクなどを投稿することができます。投稿するタイミングやテキスト内容を登録するだけで簡単に設定することが可能です。タイムリーな情報共有により、顧客対応のスピードアップを後押しします。」 イ 甲６発明 前記アの「BIZTEL」は、「クラウド型CTI / コールセンターシステム」であって、「CTI」はComputer Telephony Integrationの略であり、「コールセンター」は「インターネットとPC」で「構築できる」ものであるから、該「BIZTEL」は、コンピュータプログラムで実装されていると解される。 以上によれば、甲６には、次の発明（以下「甲６発明」という。）が記載されていると認められる。 「クラウド型 CTI / コールセンターシステムのBIZTELであって、 コンピュータプログラムで実装され、 Slack と連携し、電話着信の通知や通話録音ファイルのリンクなどを投稿し、 投稿するタイミングやテキスト内容を登録して設定する BIZTEL」 （３）甲７ ア 甲７の記載事項 甲７には、次の事項が記載されている。 「会話サマリーAI電話”ピクポン”、Slackへの不在着信通知機能(β版)をリリース」 「■不在着信のSlack通知機能について 多くの企業が情報共有ツールとして導入しているSlack。これまでSlackとピクポンを連携することで「電話しただけで顧客の課題をテキスト化しチーム内でなめらかに共有する体験」を提供していました。 ＜これまでの連携内容＞ ○１：ピクポンを用いて通話します。 ○２：顧客の課題が含まれる発言が、自動でテキスト化されます。 ○３：顧客の課題が含まれる発言はセンテンスレベルで、Slackの指定したチャンネルで自動で通知。メンバー内で共有されます。 （当審注：「○１」等は、いわゆる丸数字を表す。以下、同じ。） 今回のリリースにより、上記に加え、新たに「不在着信」をSlackに通知できるようになりました。 ＜今回新たにできるようになったこと＞ ○１：お使いのSlackとピクポンを連携させることで、チャンネルに不在の通知が届きます。 ○２：通知を確認し、不在着信にチームで対応することが可能です。 ［図：0001418239000003.jpg］ 顧客の声（VOC）を（当審注：「顧客の声（VOC）の」の誤記と認める。）通知と、不在着信の通知はそれぞれ別チャンネルとして設定できます。 本機能により、ピクポンにログインしていなくても、Slackを見るだけで不在着信が把握でき、より迅速に顧客への対応が可能になります。」 イ 甲７発明 前記アの会話サマリーAI電話の「ピクポン」は、「AI」技術を用いるものであり、「AI」がコンピュータプログラムで実装されることは技術常識であるから、「ピクポン」は、コンピュータプログラムで実装されていると解される。 前記アの「顧客の声（VOC）の通知」との記載の「顧客の声（VOC）」は、「顧客の課題が含まれる発言はセンテンスレベルで、Slackの指定したチャンネルで自動で通知」との記載の「顧客の課題が含まれる発言」のことであると解される。 以上によれば、甲７には、次の発明（以下「甲７発明」という。）が記載されていると認められる。 「会話サマリーAI電話のピクポンであって、 コンピュータプログラムで実装され、 ピクポンを用いて通話し、顧客の課題が含まれる発言が、自動でテキスト化され、顧客の課題が含まれる発言はセンテンスレベルで、Slackの指定したチャンネルで自動で通知し、 不在着信をSlackに通知でき、 顧客の課題が含まれる発言の通知と、不在着信の通知はそれぞれ別チャンネルとして設定できる ピクポン」 ３ 当審の判断 （１）本件発明２について ア 対比 本件発明２と甲６発明とを対比する。 （ア）「プログラム」について 甲６発明の「BIZTEL」は、「コンピュータプログラム」で実装されたものであるから、甲６発明は、「コンピュータ」を「BIZTEL」として機能させる「プログラム」と見ることもできる。そうすると、本件発明２と甲６発明とは、「コンピュータを機能させるためのプログラム」である点で一致する。 （イ）「会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた着信があったことを特定する着信情報を含む会話情報を取得する会話情報取得部」について 甲６発明の「BIZTEL」は、「CTI / コールセンターシステム」の「プログラム」であり、「電話」機能を有するものであるから、本件発明２の「会話アプリ」に相当し、甲６発明における「電話着信」は、「BIZTEL」でのものと解されるから、本件発明２の「会話アプリを用いた着信」に相当する。 甲６発明の「BIZTEL」は、「BIZTEL」に「電話着信」があったことの何らかの情報を当然得ていると解され、かかる情報は、本件発明２の「会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた着信があったことを特定する着信情報を含む会話情報」に相当し、上記情報を得る機能は、本件発明２の「会話情報取得部」に相当するといえる。 したがって、本件発明２と甲６発明とは、コンピュータを「会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた着信があったことを特定する着信情報を含む会話情報を取得する会話情報取得部」として機能させる点で一致する。 （ウ）「前記会話情報取得部が取得した前記会話情報が、着信があったことである通知条件に合致するか否かを判断する判断部」について 甲６発明の「BIZTEL」は、少なくとも「電話着信の通知」の「投稿」と「通話録音ファイルのリンク」の「投稿」をするものであり、２つの「投稿」のどちらを行うか選択するための何らかの判定条件を有していると解され、「電話着信の通知」の「投稿」を選択する条件は、当然「電話着信」があったことであるから、当該条件は、本件発明２の「着信があったことである通知条件」に相当するといえる。 そして、「BIZTEL」が、「電話着信の通知」の「投稿」を選択する上記条件を満たすか否かの判断に、「電話着信」があったことを特定する情報（前記（イ））を用いていることは明らかであるから、かかる判断をする機能は、本件発明２の「判断部」に相当し、本件発明２と甲６発明とは、コンピュータを「前記会話情報取得部が取得した前記会話情報が、着信があったことである通知条件に合致するか否かを判断する判断部」として機能させる点で一致する。 （エ）「前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部」について 甲６発明において、「投稿」される「電話着信の通知」の情報は、本件発明２の「前記会話情報に関する通知情報」に相当する。また、上記「投稿」先は「Slack」、具体的には「Slack」のチャンネルと解され、該「Slack」のチャンネルは、本件発明２の「当該通知条件に対応する通知先」とは、「通知先」である点で共通するといえるが、前記（ウ）の「電話着信の通知」の「投稿」を選択する条件と対応したものであるかは明らかでない。 したがって、本件発明２と甲６発明とは、コンピュータを「前記通知条件に合致すると前記判断部が判断した場合に、通知先に前記会話情報に関する通知情報を送信する通知部」として機能させる点で共通する。 （オ）前記（ア）～（エ）によれば、本件発明２と甲６発明とは、次の一致点、相違点があるといえる。 ［一致点］ コンピュータを、 会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた着信があったことを特定する着信情報を含む会話情報を取得する会話情報取得部と、 前記会話情報取得部が取得した前記会話情報が、着信があったことである通知条件に合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、通知先に前記会話情報に関する通知情報を送信する通知部として機能させるためのプログラム。 ［相違点１］ 「通知先」が、本件発明２は、着信があったことである「通知条件に対応する」ものであるのに対し、甲６発明は、「電話着信の通知」の「投稿」を選択する条件と対応するものであるか明らかでない点。 イ 相違点についての判断 甲６発明における「電話着信の通知」及び「通話録音ファイルのリンク」の投稿先であるSlackが、複数のチャンネルを有することは、甲５（前記２（１）ア）、甲７（前記２（３）ア）にも示されるように周知の事項である。 そして、甲６発明では、上記投稿のタイミングやテキスト内容を設定可能なものであり、また、「電話着信の通知」を利用する者と「通話録音ファイルのリンク」を利用する者は異なり得る（例えば、前者はコールセンターのオペレータ、後者はその管理者）ことに鑑みれば、「電話着信の通知」と「通話録音ファイルのリンク」それぞれの投稿先として、個別にSlackチャンネルを設定することは、当業が適宜設計し得たことであり、その場合の「着信通知の通知」の投稿先として設定された上記Slackチャンネルは、「電話着信の通知」の「投稿」を選択する条件に対応するものといえるから、相違点１に係る本件発明２の構成は、甲６発明に基づいて当業者が容易に想到し得たものである。 ウ 小括 したがって、本件発明２は、甲６発明に基づいて当業者が容易に発明をすることができたものである。 （２）本件発明１２、１６について 請求項１２及び１６は、本件発明２のプログラムを、それぞれ通知装置及び通知方法として表現したものである。 したがって、本件発明２について前記（１）で示したように、本件発明１２及び１６は、甲６発明に基づいて当業者が容易に発明をすることができたものである。 （３）本件発明３について ア 対比 本件発明３と甲７発明とを対比する。 （ア）「プログラム」について 甲７発明の「ピクポン」は、「コンピュータプログラム」で実装されたものであるから、甲７発明は、「コンピュータ」を「ピクポン」として機能させる「プログラム」と見ることもできる。そうすると、本件発明３と甲７発明とは、「コンピュータを機能させるためのプログラム」である点で一致する。 （イ）「会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた不在着信があったことを特定する不在着信情報を含む会話情報を取得する会話情報取得部」について 甲７発明の「ピクポン」は、「電話」の「プログラム」であるから、本件発明３の「会話アプリ」に相当し、甲７発明における「不在着信」は、「ピクポン」での着信のうち応答されなかったものと解されるから、本件発明３の「会話アプリを用いた不在着信」に相当する。 甲７発明の「ピクポン」が、「不在着信」の「通知」をするには、「ピクポン」での着信が「不在着信」となったことを特定する何らかの情報を当然得ていると解され、かかる情報は、本件発明３の「会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた不在着信があったことを特定する不在着信情報を含む会話情報」に相当し、上記情報を得る機能は、本件発明３の「会話情報取得部」に相当するといえる。 したがって、本件発明３と甲７発明とは、コンピュータを「会話アプリを用いた会話に関する会話情報であり、前記会話アプリを用いた不在着信があったことを特定する不在着信情報を含む会話情報を取得する会話情報取得部」として機能させる点で一致する。 （ウ）「前記会話情報取得部が取得した前記会話情報が、不在着信があったことである通知条件に合致するか否かを判断する判断部」について 甲７発明の「ピクポン」は、「不在着信」の「通知」と「顧客の課題が含まれる発言」の「通知」をするものであり、２つの「通知」のどちらを行うのか選択するための何らかの判定条件を有していると解され、「不在着信」の「通知」を選択する条件は、当然「不在着信」があったことであるから、当該条件は、本件発明３の「不在着信があったことである通知条件」に相当するといえる。 そして、「ピクポン」が、「不在着信」の「通知」を選択する上記条件を満たすか否かの判断に、着信が「不在着信」となったことを特定する情報（前記（イ））を用いていることは明らかであるから、かかる判断をする機能は、本件発明３の「判断部」に相当し、本件発明３と甲７発明とは、コンピュータを「前記会話情報取得部が取得した前記会話情報が、不在着信があったことである通知条件に合致するか否かを判断する判断部」として機能させる点で一致する。 （エ）「前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部」について 甲７発明において、「Slack」に「通知」される「不在着信」の情報は、本件発明３の「前記会話情報に関する通知情報」に相当する。また、「不在着信」の「通知」をする「チャンネル」は、「顧客の課題が含まれる発言」の「通知」をする「チャンネル」とは別に設定されるものであり、前記（ウ）の「不在着信」の「通知」を選択する条件と対応する通知先といえるから、本件発明３の「不在着信があったことである通知条件」「に対応する通知先」に相当し、上記「チャンネル」に「不在着信」の「通知」をする機能は、本件発明３の「通知部」に相当する。 したがって、本件発明３と甲７発明とは、コンピュータを「前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部」として機能させる点で一致する。 （オ）前記（ア）～（エ）によれば、本件発明３と甲７発明とに相違点は存在しない。 イ 小括 以上のとおり、本件発明３は、甲７発明と同一である。また、本件発明３は、甲７発明から当業者が容易に発明をすることができたものである。 （４）本件発明１３、１７について 請求項１３及び１７は、本件発明３のプログラムを、それぞれ通知装置及び通知方法として表現したものである。 したがって、本件発明３について前記（３）で示したように、本件発明１３及び１７は、甲７発明と同一であり、また、甲７発明に基づいて当業者が容易に発明をすることができたものである。 （５）本件発明４について ア 対比 本件発明４と甲５発明とを対比する。 （ア）「プログラム」について 甲５発明の「アンプトーク」は、「コンピュータプログラム」で実装されたものであるから、甲５発明は、「コンピュータ」を「アンプトーク」として機能させる「プログラム」と見ることもできる。そうすると、本件発明４と甲５発明とは、「コンピュータを機能させるためのプログラム」である点で一致する。 （イ）「会話アプリを用いた会話に関する情報であり、会話の内容を特定する内容情報を有する会話情報を取得する会話情報取得部」について 甲５発明における「Zoom Meetings」は、ビデオ会議のためのアプリケーションであり、「Dialpad」及び「Zoom Phone」は、ＩＰ電話のためのアプリケーションであり、これらは、いずれも利用者同士が会話をするためのものであるから、本件発明４の「会話アプリ」に相当する。 甲５発明の「アンプトーク」が「取得」する「Zoom Meetingsでのオンライン商談の録画」や「Zoom Phone、Dialpadでの架電内容」は、「オンライン商談」や「架電」の会話の内容を示すものであるから、これらは、本件発明４の「会話アプリを用いた会話に関する情報であり、会話の内容を特定する内容情報を有する会話情報」に相当し、「アンプトーク」の上記の「取得」する機能は、本件発明４の「会話情報取得部」に相当する。 したがって、本件発明４と甲５発明とは、コンピュータを「会話アプリを用いた会話に関する情報であり、会話の内容を特定する内容情報を有する会話情報を取得する会話情報取得部」として機能させる点で一致する。 （ウ）「前記内容情報の解析結果を取得する解析部」について 甲５発明の「アンプトーク」は、取得した「Zoom Meetingsでのオンライン商談の録画やZoom Phone、Dialpadでの架電内容」を「書き起こ」す、より具体的には、「オンライン商談」や「架電」の会話内容をテキスト化するものであり、「アンプトーク」は、会話内容について音声認識等の解析を行い、その結果（会話内容のテキスト）を得ているといえる。そうすると、「書き起こ」しの結果（会話内容テキスト）は、本件発明４の「前記内容情報の解析結果」に相当し、「アンプトーク」の上記「書き起こ」す機能は、本件発明４の「解析部」に相当し、本件発明４と甲５発明とは、コンピュータを「前記内容情報の解析結果を取得する解析部」として機能させる点で一致する。 （エ）「前記解析結果を出力する解析出力部」について 甲５発明の「アンプトーク」は、「Zoom Meetingsでのオンライン商談の録画やZoom Phone、Dialpadでの架電内容」を「書き起こ」した結果（会話内容のテキスト）を、Salesforceに「出力」するから、該「出力」の機能は、本件発明４の「前記解析結果を出力する解析出力部」に相当する。 したがって、本件発明４と甲５発明とは、コンピュータを「前記解析結果を出力する解析出力部」として機能させる点で一致する。 （オ）「前記解析結果に対するコメントを受け付けるコメント受付部」について 甲５発明の「アンプトーク」は、「会話の特定の箇所へのタイムスタンプ付きでのコメント」を通知するものであるから、該「コメント」を受け付ける機能を当然に有すると認められる。 他方、甲５発明の「会話の特定の箇所」への上記「コメント」は、本件発明４の「前記解析結果に対するコメント」とは、「会話に対するコメント」である点で共通するものの、甲５発明の「会話の特定の箇所」への「コメント」が、具体的に如何にしてなされたものであるかは明らかでない。 したがって、本件発明４と甲５発明とは、コンピュータを「会話に対するコメントを受け付けるコメント受付部」として機能させる点で共通する。 （カ）「内容情報の解析結果に対するコメントに関する条件である通知条件に、前記コメント受付部が受け付けた前記コメントが合致するか否かを判断する判断部」について 甲５発明の「アンプトーク」は、「コメント」の「通知」を「ユーザータグ」に応じて「出し分け」ており、そのために「設定」された「ユーザータグ」は、当然「コメント」に関連するものと解され、また、「通知」の「出し分け」の条件といえるものであるから、上記「ユーザータグ」は、本件発明４の「内容情報の解析結果に対するコメントに関する条件である通知条件」とは、「会話に対するコメントに関する条件である通知条件」である点で共通する。 そして、甲５発明の「アンプトーク」が、「コメント」の「通知」を「設定」された「ユーザータグ」に応じて「出し分け」るには、「コメント」が該「ユーザータグ」と合致するか否かを判断する必要があるから、該判断する機能を当然に有すると認められる。 したがって、前記（オ）を踏まえると、本件発明４と甲５発明とは、コンピュータを「会話に対するコメントに関する条件である通知条件に、前記コメント受付部が受け付けた前記コメントが合致するか否かを判断する判断部」として機能させる点で共通する。 （キ）「前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部」について 甲５発明の「アンプトーク」が「コメント」の「通知」を「ユーザータグ」に応じて「出し分ける」「通知チャンネル」は、「ユーザータグ」に対応するものといえるから、本件発明４の「当該通知条件に対応する通知先」に相当する。また、「通知」する「コメント」は、前記（オ）のとおり、「会話の特定の箇所」に対するものであり、「Zoom Meetingsでのオンライン商談の録画」や「Zoom Phone、Dialpadでの架電内容」に関する情報といえるから、本件発明４の「前記会話情報に関する通知情報」に相当する。 そして、上記「コメント」の「通知」は、前記（カ）のとおり、該「コメント」が「ユーザータグ」と合致するか否かを判断し、合致すると判断したときに、「ユーザータグ」と対応する「通知チャンネル」に対して行われるものであるから、本件発明４と甲５発明とは、コンピュータを「前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部」として機能させる点で一致する。 （ク）前記（ア）～（キ）によれば、本件発明４と甲５発明とは、次の一致点、相違点があるといえる。 ［一致点］ コンピュータを、 会話アプリを用いた会話に関する情報であり、会話の内容を特定する内容情報を有する会話情報を取得する会話情報取得部と、 前記内容情報の解析結果を取得する解析部と、 前記解析結果を出力する解析出力部と、 会話に対するコメントを受け付けるコメント受付部と、 会話に対するコメントに関する条件である通知条件に、前記コメント受付部が受け付けた前記コメントが合致するか否かを判断する判断部と、 前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部として機能させるためのプログラム。 ［相違点２］ 「会話に対するコメント」が、本件発明４は、「内容情報の解析結果」に対してされたものであるのに対し、甲５発明は、具体的に如何にしてなされたものであるか明らかでない点。これに付随して、コメントに関する「通知条件」が、本件発明４は、「内容情報の解析結果に対するコメント」に関するものであるのに対し、甲５発明は、「ユーザータグ」が「内容情報の解析結果に対するコメント」に関するものであることは特定されていない点。 イ 相違点についての判断 甲５発明における「コメント」は、「会話の特定の箇所」に対するものであるから、会話の内容及び流れを把握してなされたものと解される。そして、甲５発明のアンプトークは、会話内容を書き起こして出力する機能を有するものであり、書き起こした会話内容のテキストが、会話の内容及び流れを把握可能であることを踏まえると、甲５発明における「コメント」は、書き起こした会話内容のテキストに対して、すなわち、会話内容の解析結果に対してなされたものと解するのが合理的である。 そうすると、前記相違点２は、実質的な相違点ではない。 また、仮に、実質的な相違点であるとしても、甲５発明において、「コメント」を、書き起こした会話内容のテキストに対して行うようにして、相違点２に係る本件発明４の構成とすることは、当業者であれば容易に想到し得たことである。 ウ 小括 したがって、本件発明４は、甲５発明と同一である。また、本件発明４は、甲５発明に基づいて当業者が容易に発明をすることができたものである。 （６）本件発明１４、１８について 請求項１４及び１８は、本件発明４のプログラムを、それぞれ通知装置及び通知方法として表現したものである。 したがって、本件発明４について前記（５）で示したように、本件発明１４及び１８は、甲５発明と同一であり、また、甲５発明に基づいて当業者が容易に発明をすることができたものである。 第４ 取消理由通知において採用しなかった特許異議申立理由について １ 請求項１、５、１１、１５に係る特許に対する特許異議申立理由について 特許異議申立書において特許異議申立人が申立てた、請求項１、５、１１、１５に係る特許に対する特許異議申立理由の概要は、次のとおりである。 本件発明１、１１、１５は、甲第１号証（以下「甲１」という。）に記載された発明であるから、特許法第２９条第１項第３号に掲げる発明であるので、請求項１、１１、１５に係る特許は、同法第１１３条第２号に該当し、取り消すべきものである。 本件発明１、１１、１５は、甲１に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものであるので、請求項１、１１、１５に係る特許は、同法第１１３条第２号に該当し、取り消すべきものである。 本件発明５は、甲第３号証（以下「甲３」という。）に記載された発明及び甲第４号証（以下「甲４」という。）に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものであるので、請求項５に係る特許は、同法第１１３条第２号に該当し、取り消すべきものである。 ２ 甲１、３、４の記載 （１）甲１ ア 甲１の記載事項 甲１には、次の事項が記載されている。 「【請求項１】 状態プロパティ変化に応答してクライアントに通知を提供するための方法であって、 状態プロパティに関連付けられた変化に応答して通知を受け取る通知要求をクライアントから受け取ることと、 デバイス内の異なるコンポーネントによって更新される少なくともいくつかの状態プロパティを含む通知システムに前記状態プロパティが登録されることを確実にすることと、 前記状態プロパティが変化したときを判定することと、 前記クライアントが前記状態プロパティ変化の通知を受け取るべきときを判定することと、 判定されたときに前記状態プロパティ変化を前記クライアントに通知することと を備えることを特徴とする方法。」 「【請求項１０】 状態管理および通知のためのシステムであって、 状態プロパティに関係する情報を格納するように構成されたデータストアであって、前記状態プロパティの少なくともいくつかが異なるコンポーネントによって変更されるデータストアと、 前記状態プロパティに関係する操作を行うように構成されたＡＰＩと、 通知要求を登録し、登録した状態プロパティの変化に応答して通知を受け取るように構成されたクライアントであって、前記通知要求は前記状態プロパティに関連付けられた変化に応答して前記クライアントが通知を受け取るべきときを示すクライアントと、 通知要求を受け取るように登録されているクライアントを記憶するように構成された通知リストと、 前記データストア、前記通知リストおよび前記クライアントに結合された通知ブローカであって、 少なくとも１つのクライアントを前記通知リストに追加する通知要求を受け取ることと、 前記少なくとも１つのクライアントを前記通知リストに追加することと、 登録された状態プロパティが変化したときおよび前記状態プロパティが変化したときを判定し、通知を受け取るべきクライアントを判定し、前記判定されたクライアントに前記状態プロパティ変化を通知することと を含むアクションを行うように構成されたアプリケーションを含む通知ブローカと を備えたことを特徴とするシステム。」 「【請求項１９】 状態プロパティに関して操作を行うためのコンピュータ実行可能命令を有するコンピュータ可読媒体であって、 状態パラメータのグループ内の少なくとも１つの状態プロパティを特定する識別子パラメータを受け取ることであって、状態パラメータの前記グループ内の前記状態パラメータのいくつかは、デバイス内の異なるコンポーネントによって更新されることと、 前記状態パラメータに関連して行うべき操作を判定することと、 前記操作を行うことと を備えたことを特徴とするコンピュータ可読媒体。」 「【発明が解決しようとする課題】 【０００３】 こうした機能のすべてを提供するには、新規の電子メールがあったとき、デバイスのスクリーンがアクティブ化されたとき、電話のコールが受信されたときなど、様々なイベントについて、モバイルデバイス上のアプリケーションに通知する必要がある。しかし、デバイスに関連付けられた様々な状態変化のすべてにアクセスするのは困難である。」 「【００１０】 簡単に説明すると、本発明は、デバイス状態、アプリケーション状態、およびサービス状態を格納するための統一されたメカニズム、ならびに豊かな通知仲介アーキテクチャについての方法およびシステムを提供することを対象とする。一般に、クライアントは、ある状態プロパティが変化したときに通知を受け取るように通知ブローカに登録する。登録された状態プロパティが変化すると、通知ブローカは、どのクライアントにその状態変化を通知するかを判定し、そのクライアントにその変化に関する通知を提供する。クライアントは、状態が変化したときにはいつでも、または状態変化が所定の条件を満たすとき、またはスケジュールに基づいて通知を受けることができる。また、状態変化またはスケジュールに応答してアプリケーションを起動することもできる。また、デバイス内の異なるコンポーネントにわたって状態変化情報にアクセスする統一された方法を提供することを対象とするアプリケーションプログラミングインタフェース（ＡＰＩ）も提供される。」 「【００１７】 「クライアント」という用語は、状態プロパティ変化通知のための登録をする任意のクライアントを指す。クライアントが状態変化コンポーネントであることも、状態変化コンポーネントがクライアントであることもある。 【００１８】 「状態プロパティ識別子」という用語は、状態プロパティの「フレンドリな」文字列（名前）表現を指す。この識別子は、階層的であってよく、固有である。 【００１９】 「条件付き通知」という用語は、状態プロパティが変化し、その状態プロパティが通知要求において指定された条件を満たすときに送られる通知を指す。 【００２０】 （例示的な動作環境） 図１を参照すると、本発明を実施するための例示的なシステムが、コンピューティングデバイス１００のようなコンピューティングデバイスを含んでいる。コンピューティングデバイス１００は、クライアントまたはサーバとして構成することができる。非常に基本的な構成では、コンピューティングデバイス１００は、通常、少なくとも１つの処理装置１０２およびシステムメモリ１０４を含む。コンピューティングデバイスのはっきりした構成およびタイプに応じて、システムメモリ１０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこの２つの何らかの組み合わせとすることができる。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６を含み、プログラムデータ１０７を含むことがある。この基本的な構成は、図１に破線１０８内のコンポーネントによって例示されている。」 「【００２３】 図２を参照すると、本発明を実施するための１つの例示的なシステムが、モバイルデバイス２００のようなモバイルデバイスを含んでいる。モバイルデバイス２００は、プロセッサ２６０、メモリ２６２、ディスプレイ２２８およびキーパッド２３２を有する。メモリ２６２には、一般に、揮発性メモリ（例えば、ＲＡＭ）および不揮発性メモリ（例えば、ＲＯＭ、フラッシュメモリなど）が両方とも含まれる。モバイルデバイス２００は、マイクロソフトコーポレイションからのＷｉｎｄｏｗｓ（登録商標）ＣＥオペレーティングシステム、またはその他のオペレーティングシステムのようなオペレーティングシステム２６４を含み、このオペレーティングシステムは、メモリ２６２の中に存在し、プロセッサ２６０上で実行される。キーパッド２３２は、プッシュボタン数字ダイヤルパッド（通常の電話機上にあるような）、マルチキーのキーボード（従来のキーボードのような）とすることができる。ディスプレイ２２８は、液晶ディスプレイ、またはモバイルデバイスにおいて一般に使用される他の任意のタイプのディスプレイとすることができる。ディスプレイ２２８は、タッチセンシティブとすることができ、その場合は、入力デバイスとしても働く。 【００２４】 １つまたは複数のアプリケーションプログラム２６６がメモリ２６２にロードされ、オペレーティングシステム２６４上で実行される。アプリケーションプログラムの例には、電話ダイヤラプログラム、電子メールプログラム、スケジューリングプログラム、ＰＩＭ（個人情報管理）プログラム、ワードプロセッシングプログラム、スプレッドシートプログラム、インターネットブラウザプログラムなどが含まれる。アプリケーションプログラム２６６は、共通のＡＰＩを使用して、デバイスに関連付けられた状態プロパティに関するアクションを行うことができる。例えば、電話ダイヤラプログラムが、信号強度、電話状態、バッテリ強度などの変化に関する通知を受け取るように通知システムに登録することが可能である。モバイルコンピューティングデバイス２００は、メモリ２６２内に不揮発性ストレージ２６８を含む。不揮発性ストレージ２６８を使用して、モバイルコンピューティングデバイス２００の電源が切れた場合に失われてはならない永続的情報を格納することができる。アプリケーション２６６は、電子メールアプリケーションによって使用される電子メールメッセージまたはその他のメッセージ、ＰＩＭによって使用されるコンタクト情報、スケジューリングプログラムによって使用される予定情報、ワードプロセッシングプログラムによって使用されるドキュメントなどの情報を使用し、ストレージ２６８に格納することができる。」 「【００２８】 （例示的な状態変化通知システム） 図３は、本発明の態様による例示的な状態管理－通知システムを示している。通知システム３００は、状態変化コンポーネント３１０、クライアント３１５および３２０、通知ブローカ３３５およびデータストア３３０を含む。一実施形態によれば、通知ブローカ３３５は、通知リスト３４０、キャッシュプロパティ３４５およびスケジューラ３５０も保持する。 【００２９】 クライアント３１５または３２０のようなクライアントが、状態プロパティの変化に関する通知を受け取るように通知ブローカ３３５に登録する。一般に、クライアントは、状態プロパティが変化したときはいつでも、または変化が条件を満たすとき、またはスケジュールに基づいて通知を受け取るようにクライアントを登録する通知要求を通知ブローカ３３５に対して行うことができる。通知は、永久的なまたは一時的な通知とすることができる。」 「【００３５】 また、データストア３３０に、クライアント３１５および３２０によってアクセスすることができる状態プロパティデータの既定のセットをあらかじめロードすることもできる。状態プロパティデータをあらかじめロードすることにより、クライアントが状態プロパティを追加する必要なく、状態プロパティの多くが利用可能になる。例えば、一実施形態によれば、以下の状態が、その状態を登録することなくクライアントに利用可能になる。これらの状態は、ディスプレイの向き（解像度、明るさ）、未破棄のリマインダ（カウント、件名、日付、時刻、場所）、未破棄のアラーム（カウント、説明、日付、時刻）、バッテリ（残量％、状態）、バックアップバッテリ（残量％、状態）、メモリ（プログラムメモリの空き、使用中のプログラムメモリ、記憶メモリの空き、使用中の記憶メモリ）、メモリカード（総メモリの空き、使用中の総メモリ）、ハードウェア（折りたたみ式電話の状態（開／閉）、キーボード有効、Ｗｉｆｉ有効、Ｂｌｕｅｔｏｏｔｈ有効、ヘッドホンあり、カメラあり）、メッセージング（未読カウント、合計カウント、下書きカウント、送信トレイカウント）、タスク（最優先カウント、本日期限カウント、期限超過カウント）、カレンダ（次の予定、名前、場所、日付、時刻、ＰＯＯＭ ＩＤ）、全日予定（名前、場所、日付、時刻、ＰＯＯＭ ＩＤ）、現在の予定（名前、場所、日付、時刻、ＰＯＯＭ ＩＤ）、現在の空き／ビジーステータス、インスタントメッセンジャー（ステータス、オンラインコンタクトカウント、オフラインコンタクトカウント）、接続（速度、Ｗｉｆｉ、アクセスポイント、信号強度、接続名、接続先（職場、インターネット）、ステータス）、メディアプレーヤー（ステータス、再生リスト（名前、モード（繰り返し、シャッフル）、トラックカウント、合計時間）、トラック（タイプ（オーディオ、ビデオ）、名前、アルバム、アーティスト、トラック番号、ジャンル、年、長さ、再生位置、ファイル名、ビットレート））、同期ステータス、電話（オペレータ、信号強度、電話状態、プロファイル、ローミング、無線状態）、アクティブなコール（発呼者名、発呼者番号）、不在着信カウント、ＳＩＭツールキットメッセージである。理解されうるように、状態は多くの異なるアプリケーションにわたる。」 「【００５１】 図４は、本発明の態様による状態変化通知システムのプロセスを示している。開始ブロックの後、プロセス４００は、ブロック４１０に進み、クライアントが少なくとも１つの状態プロパティの変化について通知を受けるように登録する。その状態プロパティが、別のクライアントによって既にモニタされてはいない場合、状態プロパティは、利用可能な状態プロパティのリストに追加される。前述したとおり、利用可能なプロパティのリストは、通知システムにあらかじめロードされる。クライアントは、プロパティに対してなされたすべての変化、条件を満たす変化に関する通知を受け取るように登録することができ、スケジュールに従って通知を受けることもできる。 【００５２】 ブロック４２０に進むと、変化が登録された状態プロパティに対してなされたとき、通知システムにその変化について知らせるように、コールバックが通知システムに登録される。一実施形態によれば、通知ブローカは、状態プロパティ値に対してなされる変化について、コールバックをオペレーティングシステムレジストリに登録する。 【００５３】 ブロック４３０に進むと、クライアントは、状態プロパティに関係する通知メッセージを受け取るように通知リストに追加される。通知リストに含まれるクライアントが、登録された状態プロパティの変化に関する通知を受け取る。 【００５４】 ブロック４４０に移行すると、登録された状態プロパティのいずれかに変化がなされたとき、コールバックが受信される。一実施形態によれば、コールバックは、状態プロパティ変化および状態プロパティの現在の値を特定する識別子を含む。 【００５５】 ブロック４５０に移動すると、状態変化情報が処理される。一般に、状態変化情報を処理することには、何らかの条件付け、スケジュール、バッチまたはアプリケーション起動条件が、変化した状態プロパティについて登録されたクライアントのそれぞれに適用されるかどうかを判定することが含まれる（図５および関連する説明を参照）。」 「【図３】 ［図：0001418239000004.jpg］ 」 イ 甲１発明 前記アの下線部に着目すると、甲１には、次の発明（以下「甲１発明」という。）が記載されていると認められる。 「状態プロパティに関係する情報を格納するように構成されたデータストアであって、前記状態プロパティの少なくともいくつかが異なるコンポーネントによって変更されるデータストアと、 前記状態プロパティに関係する操作を行うように構成されたＡＰＩと、通知要求を登録し、登録した状態プロパティの変化に応答して通知を受け取るように構成されたクライアントであって、前記通知要求は前記状態プロパティに関連付けられた変化に応答して前記クライアントが通知を受け取るべきときを示すクライアントと、 通知要求を受け取るように登録されているクライアントを記憶するように構成された通知リストと、 前記データストア、前記通知リストおよび前記クライアントに結合された通知ブローカであって、少なくとも１つのクライアントを前記通知リストに追加する通知要求を受け取ることと、前記少なくとも１つのクライアントを前記通知リストに追加することと、登録された状態プロパティが変化したときおよび前記状態プロパティが変化したときを判定し、通知を受け取るべきクライアントを判定し、前記判定されたクライアントに前記状態プロパティ変化を通知することとを含むアクションを行うように構成されたアプリケーションを含む通知ブローカと を備えた状態管理および通知のためのシステムの前記通知ブローカであって、（【請求項１０】） システムは、モバイルデバイスを含み、複数のアプリケーションプログラムが実行され、アプリケーションプログラムには、電話ダイヤラプログラムなどが含まれ、電話ダイヤラプログラムが、電話状態などの変化に関する通知を受け取るように通知システムに登録することが可能であり（【００２３】、【００２４】）、 クライアントは、状態プロパティが変化したときはいつでも、または変化が条件を満たすとき、またはスケジュールに基づいて通知を受け取るようにクライアントを登録する通知要求を通知ブローカに対して行うことができ、（【００２９】） データストアに状態プロパティデータの既定のセットをあらかじめロードし、クライアントに利用可能になる状態には、電話（オペレータ、信号強度、電話状態、プロファイル、ローミング、無線状態）、アクティブなコール（発呼者名、発呼者番号）、不在着信カウントがあり、（【００３５】） 通知ブローカは、状態プロパティ値に対してなされる変化について、コールバックをオペレーティングシステムレジストリに登録し、（【００５２】） 登録された状態プロパティのいずれかに変化がなされたとき、コールバックが受信され、コールバックは、状態プロパティ変化および状態プロパティの現在の値を特定する識別子を含み、状態プロパティ識別子は、状態プロパティのフレンドリな文字列（名前）表現であり、（【００１８】、【００５４】） 何らかの条件付け、スケジュール、バッチまたはアプリケーション起動条件が、変化した状態プロパティについて登録されたクライアントのそれぞれに適用されるかどうかを判定する（【００５５】） 通知ブローカ」 （２）甲３ ア 甲３の記載事項 甲３には、次の事項が記載されている。 「【００１１】 本発明の目的は、コールセンタにおいて、顧客への通話対応時に、リアルタイムでスーパバイザがオペレータに対して適切な指示またはアドバイスを与えることができ、スーパバイザの支援内容の分析を可能にするコールセンタシステムおよびコールセンタ管理方法を提供することにある。 【００１２】 本発明に係るコールセンタシステムは、好ましくは、通話を録音する通話録音装置と、音声データを音声認識してテキスト化する音声認識装置と、音声認識装置の認識結果とスーパバイザからの入力を保持し、管理する認識結果管理装置と、スーパバイザに対して、通話内容を表示し、テキスト入力を受け付ける第一の情報処理装置と、オペレータごとに、そのオペレータの通話内容を表示する第二の情報処理装置とを備え、各装置は、ネットワークにより接続され、通話録音装置は、通話の音声データを音声認識装置に送信して、音声認識装置は、音声データの認識結果を認識結果管理装置に送信し、認識結果管理装置は、認識結果のテキストを第一の情報処理装置と第二の情報処理装置に送信し、第一の情報処理装置は、通話ごとに通話内容を表示する通話表示領域と、通話ごとにテキストを入力する欄を有し、第一の情報処理装置は、入力されたテキストを認識結果管理装置に送信し、認識結果管理装置は、第一の情報処理装置送信されたテキストを、通話を受け付けるオペレータの第二の情報処理装置に送信し、第二の情報処理装置は、通話内容に関するテキストと、区別できる形態で、第一の情報処理装置から入力されたテキストを表示するようにしたものである。 本発明はまた、上記コールセンタシステムにおけるコールセンタ管理方法として把握される。」 「【００１８】 コールセンタシステムには、ネットワーク５を介して、ＩＰ－ＰＢＸ装置１０３、ＣＴＩ（Computer Telephony Integration）サーバ装置１０４、ＩＶＲ（Interactive Voice Response）装置１０５、通話録音装置１０６、通話録音管理装置１０７、音声認識制御装置１０８、音声認識装置１０９、認識結果管理装置１１０、テキスト要約管理装置１１４、テキスト要約装置１１５が接続して構成される。」 「【００４０】 端末通話情報テーブル１１４０は、スーパバイザ用ＰＣ端末１１３における通話の情報を保持するテーブルであり、図１３に示されるように、通話ＩＤ１１４０ａ、オペレータＩＤ１１４０ｂ、オペレータ名１１４０ｃ、音声データファイル１１４０ｄ、認識結果テキスト１１４０ｅ、入力テキスト１１４ｆの各フィールドを有する。」 「【００４４】 次に、図１５Ａおよび図１５Ｂを用いてコールセンタシステムの処理の詳細について説明する。 先ず、図１５Ａおよび図１５Ｂを用いて外部の通話端末の発信から、オペレータ用ＰＣ端末１１２に通話表示とスーパバイザからの指示・アドバイスの表示をおこなうまでの一連の処理について説明する。 【００４５】 先ず、顧客の通話端末１０１から発呼され（Ａ０１）、ＩＰ－ＰＢＸ装置１０３で交換処理されて、コールセンタのオペレータの通話端末１１１に着呼し（Ａ０２）、通話が確立したとする（Ｓ０１）。 【００４６】 ＩＰ－ＰＢＸ装置１０３から通話端末１１１には、ＲＴＰパケットが送信されるが、ＩＰ－ＰＢＸ装置１０３は、同時にコピーしたＲＴＰパケットを通話録音装置１０６に転送する（Ａ０３）。 【００４７】 通話録音装置１０６は、通話開始がされたことを、内線番号をパラメタとし、通話録音管理装置１０７に報告して（Ａ０４）、ＲＴＰパケットに基づいて、分割録音を開始し（Ｓ０４ａ，Ｓ０４ｂ，…）、図８に示したＩＰ内線情報テーブル１０６６を参照し、図９に示した録音情報テーブル１０６７に必要な情報を書き込む。 【００４８】 通話録音管理装置１０７は、受信した内線番号をキーとして、通話認識情報テーブル（図示せず）を参照して、その内線番号にかかってきた電話に音声認識を行うか否かを判定する（Ｓ０２）。通話認識情報テーブルには、内線番号ごとに、その内線番号にかかってきた通話に対して、リアルタイムで音声認識を行うか否かの情報がふくまれているものとする。通話録音管理装置１０７は、その通話がリアルタイム音声認識を行うべきものと判定したときに、音声認識制御装置１０８に、音声認識を行う音声認識装置１０９を問い合わせる（Ａ０５）。音声認識制御装置１０８は、複数の音声認識装置１０９の使用状態、負荷を管理しており、音声認識制御装置１０８は、現段階での最も使用するのが相応しい音声認識装置１０９を判定し（Ｓ０３）、その音声認識装置１０９のＩＤを認識装置ＩＤとして、通話録音管理装置１０７に返答する（Ａ０６）。そして、通話録音管理装置１０７は、その認識装置ＩＤを通話録音装置１０６に転送する（Ａ０７）。 【００４９】 通話録音装置１０６は、その認識装置ＩＤを受取り、音声認識を行うべき音声データをその認識ＩＤに対応する音声認識装置１０９に転送する（Ａ０８）。ここで、認識装置ＩＤは、音声認識装置１０９のＩＰアドレスでもよいし、その認識装置ＩＤに対応して、音声認識装置１０９をアクセスする仕組みを通話録音装置１０６が有するようにしてもよい。 【００５０】 音声認識装置１０９は、通話録音装置１０６から送信されてきた音声データに対して、音声認識を行う（Ｓ０４）。ここで、通話録音装置１０６からは、音声データの他に、通話録音装置ＩＤ、録音ＩＤ、録音開始日時、内線番号がパラメタとして送信される。そして、音声認識装置１０９は、通話録音装置１０６から受取ったパラメタと発話ＩＤなど音声認識を行った情報と対応付けて、認識結果テキストを認識結果管理装置１１０に転送する（Ａ０９）。 【００５１】 一方、ＩＰ－ＰＢＸ１０３は、通話情報をＣＴＩサーバ装置１０４に送信する（図１５ＢのＡ１０）。また、ＣＴＩサーバ装置１０４は、通話情報／オペレータ情報を認識結果管理装置１１０と、スーパバイザ用ＰＣ端末１１３に送信する（Ａ１１、Ａ１２）。 【００５２】 次に、認識結果管理装置１１０は、ＣＴＩサーバ装置１０４から通話情報と、音声認識装置１０９から送られてきた情報と、認識結果テキストを関連付けて、認識結果または入力情報対応テーブル１１０７に格納する（Ｓ０５）。 【００５３】 次に、認識結果管理装置１１０は、オペレータ用ＰＣ端末１１２に認識結果と必要なパラメタを送信する（Ａ１３）。ここで、必要なパラメタは、内線番号、通話ＩＤ、区分（「Ｃ」ｏｒ「Ｏ」）、発話ＩＤ、発話日時である。そして、オペレータ用ＰＣ端末１１２は、オペレータの操作に従って、通話の認識結果のテキストを、オペレータ通話表示画面に表示する（Ｓ１０）。なお、オペレータ通話表示画面の詳細は、後述する。 【００５４】 次に、認識結果管理装置１１０は、スーパバイザ用ＰＣ端末１１３に認識結果と必要なパラメタを送信する（Ａ１４）。ここで、必要なパラメタは、内線番号、通話ＩＤ、区分（「Ｃ」ｏｒ「Ｏ」）、発話ＩＤ、発話日時である。そして、スーパバイザ用ＰＣ端末１１３は、スーパバイザの操作に従って、通話の認識結果のテキストを、スーパバイザ監視画面に表示する（Ｓ１１）。なお、スーパバイザ監視画面の詳細は、後述する。 【００５５】 ここで、スーパバイザが、あるオペレータの通話内容を見て、指示またはアドバイスを与えたくなったとする。そのとき、スーパバイザは、指示またはアドバイスなどのサポート情報を、入力する（Ｓ１２）。 【００５６】 スーパバイザ用ＰＣ端末１１３は、入力されたテキストと必要なパラメタを認識結果管理装置１１０に送信する（Ａ１５）。ここで、必要なパラメタは、内線番号、通話ＩＤ、区分（「Ｓ」）、発話ＩＤ、発話日時である。 【００５７】 ここで、区分は、「Ｓ」固定であり、発話ＩＤは、スーパバイザからのテキスト入力が分かるような一意的なＩＤが付与される。発話日時は、テキスト送信日時である。 【００５８】 認識結果管理装置１１０は、スーパバイザ用ＰＣ端末１１３から送信されてくる情報を、認識結果または入力情報テーブル１１０７に格納する（Ｓ１３）。 【００５９】 次に、認識結果管理装置１１０は、内線番号と対応付けられているオペレータ用ＰＣ端末１１２に、スーパバイザが入力したテキストと必要なパラメタを送信する（Ａ１６）。ここで、必要なパラメタは、Ａ１５のときのパラメタと同様のパラメタであり、内線番号、通話ＩＤ、区分（「Ｓ」）、発話ＩＤ、発話日時（テキスト送信日時）である。 【００６０】 そして、オペレータ用ＰＣ端末１１２は、開いているオペレータ通話画面があるときには、入力されてくるスーパバイザが入力したテキストを、オペレータの通話のテキスト、顧客の通話のテキストと判別される形式で、オペレータ通話表示画面に表示する（Ｓ１４）。 【００６１】 これにより、オペレータは、顧客との通話中であっても、オペレータ通話表示画面を見ることにより、スーパバイザがそのオペレータに与えたい指示やアドバイスなどのサポート情報を、顧客との通話を途絶や中断することなく、受取り、それをリアルタイムで、顧客の通話応答に活かすことができる。」 「【図１１】 ［図：0001418239000005.jpg］ 」 イ 甲３発明 前記アの下線部に着目すると、甲３には、次の発明（以下「甲３発明」という。）が記載されていると認められる。 「コールセンタシステムは、ネットワーク５を介して、ＩＰ－ＰＢＸ装置１０３、通話録音装置１０６、音声認識装置１０９、認識結果管理装置１１０が接続して構成され、（【００１８】） ＩＰ－ＰＢＸ装置１０３から通話端末１１１には、ＲＴＰパケットが送信され、ＩＰ－ＰＢＸ装置１０３は、同時にコピーしたＲＴＰパケットを通話録音装置１０６に転送し、（【００４６】） 通話録音装置１０６は、ＲＴＰパケットに基づいて、分割録音を開始し、（【００４７】） 通話録音装置１０６は、音声認識を行うべき音声データを音声認識装置１０９に転送し、（【００４９】） 音声認識装置１０９は、通話録音装置１０６から送信されてきた音声データに対して、音声認識を行い、通話録音装置１０６から受取ったパラメタと発話ＩＤなど音声認識を行った情報と対応付けて、認識結果テキストを認識結果管理装置１１０に転送し、（【００５０】） 認識結果管理装置１１０は、スーパバイザ用ＰＣ端末１１３に認識結果と必要なパラメタを送信し、ここで、必要なパラメタは、内線番号、通話ＩＤ、区分（「Ｃ」ｏｒ「Ｏ」）、発話ＩＤ、発話日時であり、スーパバイザ用ＰＣ端末１１３は、通話の認識結果のテキストを、スーパバイザ監視画面に表示し、（【００５４】） スーパバイザは、指示またはアドバイスなどのサポート情報を、入力し、（【００５５】） スーパバイザ用ＰＣ端末１１３は、入力されたテキストと必要なパラメタを認識結果管理装置１１０に送信し、ここで、必要なパラメタは、内線番号、通話ＩＤ、区分（「Ｓ」）、発話ＩＤ、発話日時であり、（【００５６】） 認識結果管理装置１１０は、内線番号と対応付けられているオペレータ用ＰＣ端末１１２に、スーパバイザが入力したテキストと必要なパラメタを送信し、ここで、必要なパラメタは、内線番号、通話ＩＤ、区分（「Ｓ」）、発話ＩＤ、発話日時（テキスト送信日時）であり、（【００５９】） オペレータ用ＰＣ端末１１２は、入力されてくるスーパバイザが入力したテキストを、オペレータ通話表示画面に表示する（【００６０】） コールセンタシステム」 （３）甲４ ア 甲４の記載事項 甲４には、次の事項が記載されている。 「【０００１】 本発明は、なりすまし電話のような危険な通話を識別し、識別結果を所定の通知先に通知する技術に関するものである。」 「【００１７】 図２に示すように、本実施の形態に係る認証装置３は、送受信部３１、発信者番号認証部３２、声紋認証部３３、危険度分析・通知部３４、認証制御部３５、及びユーザ情報格納部３６を有する。」 「【００２３】 ユーザ情報格納部３６は、ユーザ情報をテーブルとして格納する機能部である。図３に、ユーザ情報格納部３６が格納するテーブルの一例を示す。図３に示すように、本実施の形態におけるユーザ情報格納部３６には、ユーザ毎に、電話番号１、電話番号１に対応する声紋情報、電話番号２、各電話番号２に対応する声紋情報、危険ワード、通知先メールアドレスが格納されている。」 「【００２７】 ＜システムの動作＞ 次に、図４のシーケンスチャートを参照しながら本実施の形態におけるシステムの動作例について説明する。以下の例では、発信者端末１のユーザを発信者と呼び、着信者端末２のユーザを着信者と呼び、発信者が着信者に対して電話をかけて通話を行う場合について説明する。 【００２８】 発信者が発信者端末１において着信者端末２の電話番号を用いて発呼操作を行うことにより、発信者端末１から着信者端末２に対して発呼がなされ、SIPによる呼制御（ステップ１～４）により発信者端末１と着信者端末２との間の呼接続がなされ、通話が開始される（ステップ５）。 【００２９】 呼制御装置５は、SIPによる呼制御の過程で、発信者端末１の電話番号（発信者番号）と着信者端末２の電話番号（着信者番号）とを取得しており、ステップ６において、呼制御装置５は、発信者番号と着信者番号とを認証装置３に送信し、認証装置３は発信者番号と着信者番号を受信する（ステップ６）。 【００３０】 更に、呼制御装置５は、認証装置３と呼接続を行い、発信者端末１と着信者端末２間で送受信される音声を取得し、取得した音声を順次認証装置３に送信する（ステップ７）。認証装置３は当該音声を取得する。 【００３１】 なお、認証装置３が音声の中継機能を持つ場合、呼制御装置５による呼制御により認証装置３と発信者端末１との間の呼接続、及び認証装置３と着信者端末２との間の呼接続を行い、認証装置３が発信者端末１と着信者端末２との間の通話音声の中継を行うこととしてもよい。この場合、認証装置３は、自分自身が中継する音声を取得し、認証処理に用いる。上記のようにして認証装置３が取得する音声は、認証装置３に備えられている記憶装置に格納される。 【００３２】 ステップ８において認証装置は認証処理を行う。ステップ８で行われる認証処理の詳細を図５のフローチャートを参照して説明する。 【００３３】 認証処理において、まず、認証装置３の発信者番号認証部３２は、発信者番号認証を行う（ステップ８１）。具体的には、発信者番号認証部３２は、発信者番号と着信者番号を用いてユーザ情報格納部３６を検索することにより、電話番号１として格納されている着信者番号を検出し、当該着信者番号に対応付けて電話番号２として格納されている電話番号（一般には複数である）の中に発信者番号が含まれているかどうかをチェックする。 【００３４】 電話番号１として格納されている着信者番号に対応付けて電話番号２として格納されている電話番号の中に発信者番号が含まれていれば（ステップ８２におけるYes）、発信者番号認証部は発信者番号認証が成功したと判定し、その旨を認証制御部３５に通知する。本実施の形態では、当該通知を受けた認証制御部３５は、発信者は正当な者（着信者の家族等、着信者が予期している者）であると判断し、これ以上の認証処理を行わない。もちろん、この発信者番号の認証に加えて、次のステップでの声紋認証も成功した場合にはじめて発信者は正当な者であると判定することとしてもよい。 【００３５】 電話番号１として格納されている着信者番号に対応付けて電話番号２として格納されている電話番号の中に発信者番号が含まれていない場合（ステップ８２におけるNo）、発信者番号認証部３２は発信者番号認証に失敗したと判断し、その旨を認証制御部３５に通知する。 【００３６】 すると、認証制御部３５は、声紋認証部３３に対して声紋認証を行うよう指示し、声紋認証部３３は、声紋認証処理を行う（ステップ８３）。ここでは、声紋認証部３３は、記憶装置に蓄積される音声（音声データ）から、無音で区切られる各音声を取得し、それぞれの声紋情報を取得し、当該声紋情報をユーザ情報格納部３６に格納された声紋情報と比較することにより、それらの一致度合いを判定する。 【００３７】 比較の対象となる声紋情報は、着信者番号（電話番号１）に対応付けられている声紋情報と、着信者番号（電話番号１）に対応する各電話番号２に対応付けられた声紋情報である。 【００３８】 ここで、認証装置３が取得する音声には発信者の音声と着信者の音声が含まれている。上記の比較の結果、取得した音声の声紋が着信者番号（電話番号１）に対応付けられている声紋情報と一致する場合、その音声は着信者の音声であるため、発信者が正当な者であるかどうかの判定の対象とはしない。取得した音声の声紋が着信者番号（電話番号１）に対応付けられている声紋情報と一致しない音声について、それが、電話番号２に対応付けられた声紋情報のいずれかと一致するかどうかを判定することにより、発信者が正当な者であるかどうかの判定を行う。 【００３９】 例えば、声紋認証部３３は、判定対象の複数の音声（無音区間で区切られた複数の音声）のうち、予め定めた割合の個数の音声が、電話番号２に対応付けられた１つの声紋情報と一致すると判定された場合に声紋認証に成功したと判定する。 【００４０】 声紋認証部３３により、声紋認証が成功したと判定された場合には（ステップ８４のOK）、図４のステップ８全体の認証が成功であると判定され、これ以上の認証処理を行わない。声紋認証部３３により、声紋認証が失敗したと判定された場合には（ステップ８４のNG）、その旨が認証制御部３５に通知され、認証制御部３５は、危険度分析・通知部３４に対して危険度分析処理を行うように指示し、これにより危険度分析・通知部３４は、危険度分析処理を行う（ステップ８５）。 【００４１】 ステップ８５において、危険度分析・通知部３４は、認証制御部３５により記憶装置に順次記憶されている音声を当該記憶装置から取得し、それをテキストに変換し、ユーザ情報格納部３６において着信者番号（電話番号１）に対応付けて記憶されている危険ワード（一般には複数）と比較し、当該音声が危険ワードのいずれかに該当するかどうかをチェックする。この処理を、所定の時間長の音声が記憶される度に行う。 【００４２】 そして、例えば、危険度分析・通知部４３は、複数回のチェックのうちの予め定めた割合の個数の音声が危険ワードのいずれかに該当する場合に（ステップ８６のYes）、発信者と着信者との間で行われている会話の危険度が高いと判定し、判定結果を保持しておく（ステップ８７）。複数回のチェックのうち、危険ワードの割合が予め定めた割合より低い場合には（ステップ８６のNo）、認証成功であると判定し、これ以上の認証処理を行わない。 【００４３】 図５のシーケンスチャートに戻って説明を続ける。図５において、発信者と着信者間での通話が終了したことにより、端末間での回線切断処理が行われる（ステップ９～１０）。また、端末間での回線切断を検知した呼制御装置５は、認証装置３にその旨を通知する（ステップ１１）。 【００４４】 認証処理（ステップ８）での危険度分析処理において危険度分析・通知部３４により会話の危険度が高いと判定された場合、回線切断通知を受けた認証装置３における危険度分析・通知部３４は、着信者端末２に対して呼接続を行って（ステップ１２）、発信者は正当な者でない可能性がある旨の音声メッセージを着信者端末２に向けて送信する（ステップ１３）。さらに、危険度分析・通知部３４は、ユーザ情報格納部３６において、着信者番号（電話番号１）に対応付けて格納されている通知先メールアドレスを取得し、当該通知先メールアドレス宛に、着信者が不正な者と通話を行った可能性があることを示すメッセージを電子メールで送信する（ステップ１４）。」 「【図３】 ［図：0001418239000006.jpg］ 」 イ 甲４技術 前記アの下線部に着目すると、甲４には、次の技術（以下「甲４技術」という。）が記載されていると認められる。 「認証装置３は、送受信部３１、発信者番号認証部３２、声紋認証部３３、危険度分析・通知部３４、認証制御部３５、及びユーザ情報格納部３６を有し、（【００１７】） ユーザ情報格納部３６には、ユーザ毎に、電話番号１、電話番号１に対応する声紋情報、電話番号２、各電話番号２に対応する声紋情報、危険ワード、通知先メールアドレスが格納され、（【００２３】） 認証装置３は発信者番号と着信者番号を受信し、認証装置３は発信者端末１と着信者端末２間で送受信される音声を取得し、（【００２９】、【００３０】） 発信者番号認証部３２は、発信者番号と着信者番号を用いてユーザ情報格納部３６を検索することにより、電話番号１として格納されている着信者番号を検出し、当該着信者番号に対応付けて電話番号２として格納されている電話番号の中に発信者番号が含まれているかどうかをチェックし、（【００３３】） 電話番号１として格納されている着信者番号に対応付けて電話番号２として格納されている電話番号の中に発信者番号が含まれていない場合、声紋認証部３３は、音声から、無音で区切られる各音声を取得し、それぞれの声紋情報を取得し、当該声紋情報をユーザ情報格納部３６に格納された声紋情報と比較し、比較の対象となる声紋情報は、着信者番号（電話番号１）に対応付けられている声紋情報と、着信者番号（電話番号１）に対応する各電話番号２に対応付けられた声紋情報であり、（【００３５】、【００３６】、【００３７】） 声紋認証部３３により、声紋認証が失敗したと判定された場合には、危険度分析・通知部３４は、音声をテキストに変換し、ユーザ情報格納部３６において着信者番号（電話番号１）に対応付けて記憶されている危険ワードと比較し、危険度分析・通知部４３は、複数回のチェックのうちの予め定めた割合の個数の音声が危険ワードのいずれかに該当する場合に、発信者と着信者との間で行われている会話の危険度が高いと判定し、（【００４０】、【００４１】、【００４２】） 危険度分析・通知部３４により会話の危険度が高いと判定された場合、危険度分析・通知部３４は、ユーザ情報格納部３６において、着信者番号（電話番号１）に対応付けて格納されている通知先メールアドレスを取得し、当該通知先メールアドレス宛に、着信者が不正な者と通話を行った可能性があることを示すメッセージを電子メールで送信する（【００４４】）」 ３ 当審の判断 （１）本件発明１について ア 対比 本件発明１と甲１発明とを対比すると、以下のことがいえる。 （ア）甲１発明の「データストア」に「あらかじめロード」（登録）される「状態プロパティデータ」には、「電話（オペレータ、信号強度、電話状態、プロファイル、ローミング、無線状態）、アクティブなコール（発呼者名、発呼者番号）、不在着信カウント」があり、これらは電話に関するものといえる。 甲１発明の「通知ブローカ」が「登録された状態プロパティのいずれかに変化がなされたとき」に「受信」する「コールバック」には、「状態プロパティ変化および状態プロパティの現在の値を特定する識別子」（状態プロパティ識別子）が含まれるから、前記「電話（オペレータ、信号強度、電話状態、プロファイル、ローミング、無線状態）、アクティブなコール（発呼者名、発呼者番号）、不在着信カウント」のいずれが変化した場合に「通知ブローカ」が受信（取得）する「状態プロパティ変化および状態プロパティの現在の値を特定する識別子」は、電話に関する情報ということができ、電話（通話）は会話の一種であるから、甲１発明の電話についての「状態プロパティ変化および状態プロパティの現在の値を特定する識別子」は、本件発明１の「会話に関する会話情報」に相当し、本件発明１と甲１発明とは、「会話に関する会話情報を取得する」点で共通する。 他方で、甲１発明の前記「電話（オペレータ、信号強度、電話状態、プロファイル、ローミング、無線状態）、アクティブなコール（発呼者名、発呼者番号）、不在着信カウント」は、「会話アプリ」を用いた電話についてのものかは明らかでない。また、甲１発明の「通知ブローカ」が、電話についての前記「状態プロパティ変化および状態プロパティの現在の値を特定する識別子」を、当該電話に用いた「会話アプリを識別するアプリ識別子に対応付けて」取得することも特定されていない。 （イ）甲１発明の「通知ブローカ」は、「登録された状態プロパティが変化したとき」を「判定し」、「通知を受け取るべきクライアントを判定」するが、その際に「条件付け」が「変化した状態プロパティ」について「クライアント」に「適用されるかどうかを判定」しており、該「条件付け」とは、「状態プロパティ」の「変化が条件を満たすとき」に「クライアント」が「通知を受け取る」ことと解される。そうすると、上記「条件」は、「通知ブローカ」が「クライアント」に「通知」する「条件」といえるから、「変化した状態プロパティ」が前記（ア）の「電話（オペレータ、信号強度、電話状態、プロファイル、ローミング、無線状態）、アクティブなコール（発呼者名、発呼者番号）、不在着信カウント」である場合に「判定」される前記「条件」は、本件発明１の「会話情報に関する通知条件」に相当し、本件発明１と甲１発明とは、「取得した前記会話情報が、会話情報に関する通知条件に合致するか否かを判断する」点で共通するといえる。 他方で、甲１発明は、満たすか否かを判定する前記「条件」が、前記（ア）の「状態プロパティ変化および状態プロパティの現在の値を特定する識別子」と対応付けて取得された「会話アプリを識別するアプリ識別子」「に対応付く」通知条件であることは特定されていない。 （ウ）したがって、本件発明１と甲１発明とは、少なくとも以下の点で相違するといえる。 ［相違点３］ 「会話」について、本件発明１は、「会話アプリを用いた」ものであるのに対し、本件発明１は、電話が「会話アプリを用いた」ものか明らかでなく、これに関連して、「会話に関する会話情報」の「取得」を、本件発明１は、当該「会話アプリを識別するアプリ識別子に対応付けて」取得するのに対し、甲１発明は、そのような特定はされておらず、さらに、「取得した前記会話情報」が「合致するか否かを判断する」「通知条件」が、本件発明１は、前記「会話に関する会話情報」と対応付けられた「前記アプリ識別子に対応付く」通知条件であるのに対し、甲１発明は、そのような特定はされていない点。 イ 相違点についての検討 （ア）相違点３に係る本件発明１の構成は、本件発明１の「プログラム」の機能である「会話情報取得部」、「判断部」を特定するものであって、実質的な相違点であるから、本件発明１は、甲１発明と同一ではない。 （イ）甲１発明における「モバイルデバイス」が実行する「電話ダイヤラプログラム」は、電話用のアプリケーションプログラムであることは周知であり、甲１発明における電話には、「モバイルデバイス」と相手側の双方が上記「電話ダイヤラプログラム」を用いて行うものが含まれ得ることは想定され得る。 しかしながら、甲１には、前記「電話ダイヤラプログラム」を識別するアプリ識別子は記載されていない。そして、甲１発明の「条件」を上記アプリ識別子と対応付けるとともに、「通知ブローカ」が、電話に関する「状態プロパティデータの状態プロパティ変化および状態プロパティの現在の値を特定する識別子」と対応付けて上記アプリ識別子を取得し、該アプリ識別子と対応付けられた「条件」を満たすかどうか判断する構成に、甲１発明を改変することを動機付ける記載は、甲１にもその他の証拠にも見当たらない。 したがって、相違点３に係る本件発明１の構成は、当業者といえども甲１発明に基づいて容易に想到し得たものではない。 （ウ）特許異議申立人は、（i）「本件特許発明１の会話アプリに関する構成「会話アプリを識別するアプリ識別子に対応付けて、当該会話アプリを用いた会話に関する会話情報を取得する」「アプリ識別子に対応付く通知条件に合致するか否かを判断する」ことは、本件特許発明１に係るサブコンビネーションの発明を特定するための意味を有しないものであるから、本件特許発明１と、甲１発明との間に相違点はない。」（特許異議申立書２８頁）、（ii）「発明特定事項１、２は、音声認識処理を実行可能な情報処理装置の技術分野において周知技術にすぎない。（中略）よって、本件特許発明１は、甲１発明に周知技術を適用することにより当業者が容易に発明することができたものである。」（同２９～３０頁）と主張する。 しかしながら、前記（i）について、相違点３は、本件発明１である「プログラム」の機能である「会話情報取得部」及び「判断部」を特定するものであるから、特許異議申立人の前記主張は失当と言わざるをえない。また、前記（ii）について、相違点３に係る本件発明１の構成（前記主張の「発明特定事項１、２」に対応する。）が周知であることを示す証拠はないから、当該構成は周知技術であるとは認められない。 よって、特許異議申立人の前記主張は、採用することができない。 ウ 小括 したがって、本件発明１は、甲１発明と同一ではなく、甲１発明に基づいて当業者が容易に発明をすることができたものでもない。 （２）本件発明１１、１５について 請求項１１及び１５は、本件発明１のプログラムを、それぞれ通知装置及び通知方法として表現したものであり、前記（１）に示した相違点３に係る本件発明１の構成と対応する構成を有する。 したがって、本件発明１について前記（１）に示したように、本件発明１１及び１５は、甲１発明と同一ではなく、甲１発明に基づいて当業者が容易に発明をすることができたものでもない。 （３）本件発明５について 請求項５は、請求項１と請求項４を択一的に引用して、さらに限定を付したものである。この請求項５に係る発明について、特許異議申立人は、甲３発明及び甲４発明に基づいて当業者が容易に発明をすることができたものであると主張するところ、上記甲３発明に基づいて、請求項５が引用する一方の請求項４に係る発明の新規性欠如、進歩性欠如を主張する一方（特許異議申立書３７頁）、上記甲３発明に基づいて、請求項５が引用する他方の請求項１に係る発明の新規性欠如、進歩性欠如は主張していない。これを踏まえ、はじめに、請求項４を引用したときの請求項５に係る発明（以下「本件発明５Ａ」という。）について検討し、その後、請求項１を引用したときの請求項５に係る発明（以下「本件発明５Ｂ」という。）について検討する。 ア 対比 本件発明５Ａと甲３発明とを対比すると、次のことがいえる。 （ア）甲３発明の「認識結果管理装置１１０」が受信する「入力されたテキスト」は、「スーパバイザ」が入力した「指示またはアドバイスなどのサポート情報」であって、該「サポート情報」は「スーパバイザ監視画面に表示」された「通話の認識結果のテキスト」に対してのものであることは明らかであるから、「通話の認識結果のテキスト」に対する上記「テキスト」は、本件発明５Ａの「解析結果に対するコメント」に相当し、本件発明５Ａと甲３発明とは、「解析結果に対するコメントを受け付ける」点で共通する。 （イ）甲３発明の「認識結果管理装置１１０」は、「内線番号と対応付けられているオペレータ用ＰＣ端末１１２」に「スーパバイザが入力したテキスト」と「必要なパラメタ」を送信し、「オペレータ用ＰＣ端末１１２」は、該「スーパバイザが入力したテキスト」を「オペレータ通話表示画面に表示する」から、「オペレータ用ＰＣ端末１１２」に送信される前記「テキスト」と「必要なパラメタ」は、「オペレータ」に通知するための情報といえる。また、前記「テキスト」は、前記（ア）のとおり「通話の認識結果のテキスト」に対してのものであって、「通話」の内容に関するものといえるから、「オペレータ用ＰＣ端末１１２」に送信される前記「テキスト」と「必要なパラメタ」は、本件発明５Ａの「会話情報に関する通知情報」に相当する。そして、送信先である前記「オペレータ用ＰＣ端末１１２」は、本件発明５Ａの「通知先」に相当するから、本件発明５Ａと甲３発明とは、「通知先に会話情報に関する通知情報を送信する」点で共通する。 他方で、甲３発明は、「認識結果管理装置１１０」が、前記「テキスト」と「必要なパラメタ」を「オペレータ用ＰＣ端末１１２」に送信するために、前記「テキスト」が「コメントに関する条件である通知条件」に合致するか否かを判断するものではない。そのため、甲３発明は、前記送信を前記「通知条件」に合致すると判断した場合に行うものでもなく、送信先の「オペレータ用ＰＣ端末１１２」は該「通知条件」に対応するものでもない。 （ウ）したがって、本件発明５Ａと甲３発明とは、少なくとも以下の点で相違するといえる。 ［相違点４］ 「会話情報に関する通知情報を送信する」ために、本件発明５Ａは、受け付けた「コメント」が「コメントに関する条件である通知条件」に合致するか否かを判断し、「前記通知条件に合致する」と判断した場合に送信するものであって、送信先は「当該通知条件に対応する通知先」であるのに対し、甲３発明はそのような構成を備えていない点。 イ 相違点についての判断 （ア）甲３発明は、「テキスト」と「必要なパラメタ」の「オペレータ用ＰＣ端末１１２」への送信に対して、何らかの条件付け（送信の有無、送信先の変更、等）を行うことは想定されておらず、そのような条件付けを行う示唆も甲３にはない。さらに、甲４技術も、相違点４に係る本件発明５Ａの構成を有するものではない。 したがって、相違点４に係る本件発明５Ａの構成は、当業者といえども甲３発明及び甲４技術から容易に想到し得たものではない。 （イ）相違点４に関して、特許異議申立人は、「甲３発明の「スーパバイザ用ＰＣ端末１１３は、…（略）…顧客の通話応答に活かす」（甲第３号証段落００６１）は、スーパバイザによるテキスト入力（通知条件に合致したことの判断）に応じて、通知先（オペレータ）へ、「入力されたテキストと必要なパラメタ（甲第３号証段落００５６）」を送信するもの（甲３Ｆ、Ｇ）であるから、本件特許発明４の「内容情報の解析結果に対するコメントに関する条件である通知条件に、前記コメント受付部が受け付けた前記コメントが合致するか否かを判断する判断部（４Ｆ）」「前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部（４Ｇ）」に相当する。」（特許異議申立書３６頁）と主張する。 しかしながら、前記（ア）のとおり、甲３発明は、「テキスト」と「必要なパラメタ」の送信に対して、本件発明５Ａのような「通知条件」での条件付けを行うものではないから、前記主張は採用することができない。 ウ 次に、本件発明５Ｂ（請求項１を引用したときの請求項５に係る発明）について検討すると、甲３発明及び甲４技術は、少なくとも本件発明５Ｂの「会話アプリを識別するアプリ識別子に対応付けて、当該会話アプリを用いた会話に関する会話情報を取得する会話情報取得部」、「前記会話情報取得部が取得した前記会話情報が、会話情報に関する通知条件であり、前記アプリ識別子に対応付く通知条件に合致するか否かを判断する判断部」、「前記通知条件に合致すると前記判断部が判断した場合に、当該通知条件に対応する通知先に前記会話情報に関する通知情報を送信する通知部」に相当する構成を有しておらず、本件発明５Ｂの前記構成は、当業者といえども甲３発明及び甲４技術から容易に想到し得たものではない。 エ 小括 したがって、本件発明５は、甲３発明及び甲４技術に基づいて当業者が容易に発明をすることができたものではない。 第５ むすび 以上のとおり、本件発明２、１２、１６は、甲６発明に基づいて当業者が容易に発明をすることができたものであるから、請求項２、１２、１６に係る特許は、特許法第２９条第２項に違反してされたものである。本件発明３、１３、１７は、甲７発明と同一であり、また、甲７発明に基いて当業者が容易に発明をすることができたものであり、本件発明４、１４、１８は、甲５発明と同一であり、また、甲５発明に基いて当業者が容易に発明をすることができたものであるから、請求項３、４、１３、１４、１７、１８に係る特許は、特許法第２９条第１項及び第２項の規定に違反してされたものである。よって、請求項２～４、１２～１４、１６～１８に係る特許は、特許法第１１３条第２号に該当するから、取り消されるべきものである。 また、請求項１、５、１１、１５に係る特許は、特許異議申立書に記載された特許異議申立理由によっては、取り消すことはできない。さらに、他に請求項１、５、１１、１５に係る特許を取り消すべき理由を発見しない。 よって、結論のとおり決定する。