2025-700191

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

結 論 特許第７５３８９７９号の特許請求の範囲を訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項〔１－８〕，９，１０について訂正することを認める。 特許第７５３８９７９号の請求項１，３，６，８－１０に係る特許を維持する。 特許第７５３８９７９号の請求項２に係る特許についての特許異議の申立てを却下する。

理 由 第１ 手続の経緯 本件特許第７５３８９７９号（以下、「本件特許」という。）についての出願は、令和６年５月３０日に出願され、令和６年８月１４日にその特許権の設定登録がされ、令和６年８月２２日に特許掲載公報が発行された。 そして、特許異議申立人 黒川美千代（以下、単に「申立人」という。）による特許異議の申立て（以下、「本件異議申立て」という。）に係る手続の経緯は、以下のとおりである。 令和７年 ２月１３日 ：特許異議申立書の提出 令和７年 ５月２９日付け：取消理由通知書 令和７年 ７月２５日 ：訂正請求書、意見書の提出 令和７年 ７月３１日付け：通知書 令和７年 ８月２２日 ：意見書の提出（申立人） 令和７年 ９月 ４日付け：取消理由通知書 令和７年 ９月１９日 ：訂正請求書、意見書の提出 令和７年 ９月２５日付け：通知書 なお、特許法第１２０条の５第７項の規定により、令和７年７月２５日に提出された訂正請求書に係る訂正の請求は、令和７年９月１９日に提出された訂正請求書に係る訂正の請求（以下、この請求に係る訂正を「本件訂正」という。）により、取り下げられたものとみなす。 第２ 特許異議の申立ての理由及び証拠 特許異議申立書の全趣旨からして、申立人が主張する特許異議の申立ての理由（以下、「申立理由」という。）及び証拠は、以下のとおりのものと認められる。 １ 特許異議の申立ての理由の概要 （１）申立理由１ 本件特許発明１－３，６，８－１０は、本件特許出願前に公然知られる状況又は公然知られるおそれのある状況で実施された引用発明１と同一であるか、或いは、引用発明１に基づいて当業者が容易に想到し得たものである。よって、本件特許発明１－３，６，８－１０は、特許法第２９条第１項第２号又は同条第２項の規定により特許を受けることができない。したがって、請求項１－３，６，８－１０に係る本件特許は、特許法第１１３条第２号により取り消すべきものである。 （２）申立理由２ 本件特許発明１－３，６，８－１０は、引用発明２に基づいて当業者が容易に想到し得たものである。よって、本件特許発明１－３，６，８－１０は、特許法第２９条第２項の規定により特許を受けることができない。したがって、請求項１－３，６，８－１０に係る本件特許は、特許法第１１３条第２号により取り消すべきものである。 申立理由１における引用発明１とは、以下の２に記載の証拠のうち甲第１号証から甲第３号証に係る「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」についての公然実施された発明（以下、「公然実施発明」と呼ぶ）であり、申立理由２における引用発明２とは、甲第４号証に記載の発明であると認められる。 ２ 証拠 甲第１号証：クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携した引用システム１についてのプレスリリース記事を掲載するウェブサイト URL :https://smarthr.jp/release/33413/ 甲第２号証：「SmartHRがSCIM対応したので早速試してみた！」と題した、一般のユーザが引用システム１を利用・検証した内容を紹介するブログ記事を掲載するウェブサイト URL: https://blog.cloudnative.co.jp/11154/ 甲第３号証： Okta Japan株式会社の公式ウェブサイト上に掲載されている、プロダクトマーケティング担当ディレクターであるKevin Gough 氏が記述した「SCIMとは」と題した記事を掲載するウェブサイト URL: https://www.okta.com/jp/blog/2017/01/what-is-scim/, 甲第４号証：特許第６６２９６１０号公報 なお、以下において、上記甲第１号証から甲第４号証を、単に「甲１」から「甲４」という場合がある。 第３ 取消理由の概要 １ 令和７年５月２９日付けで当審が通知した取消理由 令和７年５月２９日付けで当審が通知した取消理由は、特許異議の申立てがされていない請求項４及び５について審理したものであった。請求項４及び５を除く取消理由については、令和７年９月４日付け取消理由において通知した取消理由（以下、「当審取消理由」という。）と同一であるから、下記２において述べる。 ２ 当審取消理由 当審取消理由は、概略、以下のとおりである。 （進歩性） 本件特許の特許請求の範囲の請求項１，３，６，８－１０に係る発明は、本件特許出願前に日本国内又は外国において頒布された引用文献１に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、請求項１，３，６，８－１０に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 引用文献１：特開２０１３－２５０７６０号公報 第４ 本件訂正について １ 本件訂正の請求の趣旨 本件訂正の請求の趣旨は、本件特許の特許請求の範囲を、本件訂正請求書に添付した訂正特許請求の範囲のとおり、訂正後の請求項１－１０について訂正することを求める、というものである。 ２ 本件訂正の内容 本件訂正の内容は、次のとおりのものである（下線部は訂正箇所を示す）。 （１）訂正事項１ 特許請求の範囲における請求項１を、 「提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶する中継記憶部と、 前記認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部と、 前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、 前記送信情報を情報受取装置に送信する送信部と、 を有し、 前記所定形式は、SCIMに準拠したJSON形式である、 情報中継装置。」に訂正する。 （請求項１の記載を引用する請求項３－８も同様に訂正する。） （２）訂正事項２ 特許請求の範囲の請求項２を削除する。 （３）訂正事項３ 特許請求の範囲における請求項９を、 「ユーザ情報取得部により、提供元ユーザ情報を提供する情報提供装置にアクセスするための中継記憶部に記憶された認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させ、 送信情報生成部により、前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成し、 送信部により、前記送信情報を情報受取装置に送信し、 前記所定形式は、SCIMに準拠したJSON形式である、 情報中継方法。」に訂正する。 （４）訂正事項４ 特許請求の範囲における請求項１０を、 「提供元ユーザ情報を提供する情報提供装置にアクセスするための中継記憶部に記憶された認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部のコードと、 前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部のコードと、 前記送信情報を情報受取装置に送信する送信部のコードと、 をコンピュータに実行させ、 前記所定形式は、SCIMに準拠したJSON形式である、 情報中継プログラム。」に訂正する。 ３ 一群の請求項 本件訂正前の請求項２－８は、本件訂正前の請求項１を直接的に引用しているものであるから、訂正事項１によって記載が訂正される請求項１に連動して訂正されるものである。 したがって、本件訂正前の請求項１－８に対応する本件訂正後の請求項１－８は、特許法第１２０条の５第４項に規定する一群の請求項である。 第５ 本件訂正についての適否についての判断 １ 訂正事項１について （１）訂正の目的 訂正事項１は、本件訂正前の請求項１において、「所定形式」について、「SCIMに準拠したJSON形式である」ように限定したものである。 よって、訂正事項１は、特許法第１２０条の５第２項ただし書第１号に規定する「特許請求の範囲の減縮」を目的とするものである。 同様に、訂正後の請求項の記載を引用する訂正後の各請求項についても、当該訂正事項１は、特許法第１２０条の５第２項ただし書第１号に規定する「特許請求の範囲の減縮」を目的とするものである。 （２）願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であること 訂正事項１は、設定登録時の請求項２の「前記所定形式は、SCIMに準拠したJSON形式である」なる記載に基づくものであるから、願書に添付した明細書、特許請求の範囲又は図面（以下、これらをまとめて「本件明細書等」という。）に記載した事項の範囲内の訂正である。 よって、訂正事項１は、特許法第１２０条の５第９項で準用する第１２６条第５項に適合するものである。 （３）実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと 訂正事項１は、上記（１）（２）のとおり、本件明細書等に記載した事項の範囲内で特許請求の範囲を減縮するものであって、カテゴリーや対象、目的を変更するものではないので、実質上特許請求の範囲を拡張し、又は変更するものには該当しない。 よって、訂正事項１は、特許法第１２０条の５第９項で準用する第１２６条第６項に適合するものである。 ２ 訂正事項２について （１）訂正の目的 訂正事項２は、請求項２を削除するというものであるから、特許法第１２０条の５第２項ただし書第１号に規定する「特許請求の範囲の減縮」を目的とするものである。 （２）本件明細書等に記載した事項の範囲内の訂正であること 訂正事項２は、請求項２を削除するというものであるから、本件明細書等に記載した事項の範囲内の訂正であり、特許法第１２０条の５第９項で準用する第１２６条第５項に適合するものである。 （３）実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと 訂正事項２は、請求項２を削除するというものであるから、実質上特許請求の範囲を拡張し、又は変更するものには該当せず、特許法第１２０条の５第９項で準用する第１２６条第６項に適合するものである。 ３ 訂正事項３について （１）訂正の目的 訂正事項３は、本件訂正前の請求項９の「所定形式」を、「SCIMに準拠したJSON形式である」ものと限定する訂正であるから、特許法第１２０条の５第２項ただし書第１号に規定する「特許請求の範囲の減縮」を目的とするものである。 （２）本件明細書等に記載した事項の範囲内の訂正であること 訂正事項３は、設定登録時の請求項２の「前記所定形式は、SCIMに準拠したJSON形式である」なる記載に基づくものであるから、本件明細書等に記載した事項の範囲内の訂正である。 よって、訂正事項３は、特許法第１２０条の５第９項で準用する第１２６条第５項に適合するものである。 （３）実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと 訂正事項３は、上記（１）（２）のとおり、本件明細書等に記載した事項の範囲内で特許請求の範囲を減縮するものであって、カテゴリーや対象、目的を変更するものではないので、実質上特許請求の範囲を拡張し、又は変更するものには該当しない。 よって、訂正事項３は、特許法第１２０条の５第９項で準用する第１２６条第６項に適合するものである。 ４ 訂正事項４について （１）訂正の目的 訂正事項４は、本件訂正前の請求項１０の「所定形式」を、「SCIMに準拠したJSON形式である」ものと限定する訂正であるから、特許法第１２０条の５第２項ただし書第１号に規定する「特許請求の範囲の減縮」を目的とするものである。 （２）本件明細書等に記載した事項の範囲内の訂正であること 訂正事項４は、設定登録時の請求項２の「前記所定形式は、SCIMに準拠したJSON形式である」なる記載に基づくものであるから、本件明細書等に記載した事項の範囲内の訂正である。 よって、訂正事項４は、特許法第１２０条の５第９項で準用する第１２６条第５項に適合するものである。 （３）実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと 訂正事項４は、上記（１）（２）のとおり、本件明細書等に記載した事項の範囲内で特許請求の範囲を減縮するものであって、カテゴリーや対象、目的を変更するものではないので、実質上特許請求の範囲を拡張し、又は変更するものには該当しない。 よって、訂正事項４は、特許法第１２０条の５第９項で準用する第１２６条第６項に適合するものである。 ５ 特許出願の際独立して特許を受けることができること （１）上記第２で述べたように、本件特許異議の申立ては、本件訂正前の請求項１－３，６，８－１０に係る特許に対して申し立てられたものであるから、これらに対応する本件訂正後の請求項１－３，６，８－１０に係る発明には特許法第１２０条の５第９項で読み替えて準用する特許法第１２６条第７項の規定（いわゆる独立特許要件）は課されない。 （２）そして、本件訂正後の一群の請求項である請求項〔１－８〕のうち、請求項４，５，７については、本件特許異議の申立て対象となっていない本件訂正前の請求項４，５，７に対応する請求項であり、かつ、訂正事項１は特許法第１２０条の５第２項第１号に掲げる事項を目的とする訂正であるから、訂正事項１による請求項１の訂正に連動して訂正される請求項４，５，７については、独立特許要件が課されるため、以下検討する。 （３）訂正後の請求項４，５，７は訂正後の請求項１を直接引用する関係にあり、訂正後の請求項１に係る発明は、下記第８に説示するとおり、当業者が容易に発明をすることができたものであるとはいえない。そうすると、訂正後の請求項１に係る発明の構成をすべて含む訂正後の請求項４，５，7に係る発明も、請求後の請求項１に係る発明と同様に、当業者が容易に発明をすることができたものであるとはいえない。 そして、訂正後の請求項４，５，７の記載について不備は見当たらないし、他に請求項４，５，７に係る発明が特許出願の際独立して特許を受けることができないとする理由も見当たらない。 よって、訂正事項１は、特許法第１２０条の５第９項で読み替えて準用する特許法第１２６条第７項の規定に適合する。 ６ まとめ 以上のとおりであるから、本件訂正は適正であるので、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項〔１－８〕，９，１０について訂正することを認める。 第６ 本件特許発明 上記第５のとおり、本件訂正は認められるので、特許請求の範囲の請求項１－１０に係る発明（以下、「本件特許発明１」－「本件特許発明１０」という。）は、次の事項により特定されるものである。 １ 本件特許発明１ 提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶する中継記憶部と、 前記認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部と、 前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、 前記送信情報を情報受取装置に送信する送信部と、 を有し、 前記所定形式は、SCIMに準拠したJSON形式である、 情報中継装置。 ２ 本件特許発明２ （削除） ３ 本件特許発明３ 前記中継記憶部は、前記中継ユーザ情報を記憶し、 前記送信情報生成部は、前記中継記憶部に記憶された前記中継ユーザ情報に基づいて、前記送信情報を生成する、 請求項１に記載の情報中継装置。 ４ 本件特許発明４ 前記ユーザ情報取得部が、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく前記中継ユーザ情報を取得すると、前記送信情報生成部が、前記中継ユーザ情報に基づいて、前記所定形式の前記送信情報を生成し、前記送信部が前記送信情報を前記情報受取装置に送信する、請求項１に記載の情報中継装置。 ５ 本件特許発明５ リクエスト受信部を有し、 前記リクエスト受信部は、前記情報受取装置から情報提供リクエストを受信し、 前記ユーザ情報取得部は、前記情報提供リクエストの受信に応じ、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく前記中継ユーザ情報を前記中継記憶部に記憶させ、 前記送信情報生成部は、前記中継ユーザ情報に基づいて、前記所定形式の前記送信情報を生成し、 前記送信部は、前記送信情報を前記情報受取装置に送信する、 請求項１に記載の情報中継装置。 ６ 本件特許発明６ 前記認証情報は、HTTP認証に用いられる情報である、請求項１に記載の情報中継装置。 ７ 本件特許発明７ 前記情報提供装置は、第1の情報提供装置と第2の情報提供装置を有し、 前記ユーザ情報取得部は、前記第1の情報提供装置から取得した第1の提供元ユーザ情報に基づく第1の中継ユーザ情報と、前記第2の情報提供装置から取得した第2の提供元ユーザ情報に基づく第2の中継ユーザ情報とを前記中継記憶部に記憶させ、 前記送信情報生成部は、前記第1の中継ユーザ情報に不足項目があるとき、前記第2の中継ユーザ情報から前記不足項目を取得し、前記送信情報を生成する、 請求項１に記載の情報中継装置。 ８ 本件特許発明８ 前記中継ユーザ情報は、組織における人事に関する情報である、請求項１に記載の情報中継装置。 ９ 本件特許発明９ ユーザ情報取得部により、提供元ユーザ情報を提供する情報提供装置にアクセスするための中継記憶部に記憶された認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させ、 送信情報生成部により、前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成し、 送信部により、前記送信情報を情報受取装置に送信し、 前記所定形式は、SCIMに準拠したJSON形式である、 情報中継方法。 １０ 本件特許発明１０ 提供元ユーザ情報を提供する情報提供装置にアクセスするための中継記憶部に記憶された認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部のコードと、 前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部のコードと、 前記送信情報を情報受取装置に送信する送信部のコードと、 をコンピュータに実行させ、 前記所定形式は、SCIMに準拠したJSON形式である、 情報中継プログラム。 第７ 引用文献等の記載事項、引用発明 １ 引用文献１について （１） 引用文献１記載事項 当審取消理由において引用した引用文献１には、次の事項が記載されている（なお、下線は、強調のため当審が付した。以降においても同様）。 「【０００５】 本明細書では、第１のサービスを提供する第１のサービス提供サーバと、特定の通信装置と、の間のデータ通信を中継する中継サーバが開示される。中継サーバは、登録部と中継部とを備える。登録部は、特定の通信装置を利用する特定のユーザのための特定のアカウント情報と、特定のユーザのための第１のアカウント情報と、を含む第１の組合せ情報を、記憶部に登録する。第１のアカウント情報は、第１のサービス提供サーバに登録される。中継部は、第１の組合せ情報が記憶部に登録された後に、特定の通信装置から、特定のアカウント情報が受信される場合に、特定のアカウント情報を含む第１の組合せ情報に含まれる第１のアカウント情報を用いて、第１のサービス提供サーバと特定の通信装置との間の第１のデータ通信を中継する。第１のデータ通信は、特定の通信装置が、第１のサービス提供サーバから、第１のサービスの提供を受けるための通信である。」 「【００１４】 （通信システムの構成） 図１に示されるように、通信システム２は、中継サーバ１０と、複数個のサービス提供サーバ８０，８２と、複数個の多機能機９０～９４と、を備える。中継サーバ１０と、複数個のサービス提供サーバ８０，８２と、複数個の多機能機９０～９４と、は、インターネット４に接続されている。」 「【図１】 ［図：0001434141000001.jpg］ 」 「【００１５】 （中継サーバ１０の構成） 中継サーバ１０は、通信機器（例えば多機能機９０）のベンダによって設置される。中継サーバ１０は、サービス提供サーバ８０，８２と、通信機器（例えば多機能機９０）と、の間のデータ通信を中継する。中継サーバ１０は、ネットワークインターフェイス２０と制御部３０とを備える。ネットワークインターフェイス２０は、インターネット４に接続されている。制御部３０は、ＣＰＵ３２とメモリ３４とを備える。ＣＰＵ３２は、メモリ３４に格納されているプログラム３６に従って、様々な処理を実行する。ＣＰＵ３２が上記のプログラムに従って処理を実行することによって、各部７０～７４の機能が実現される。」 「【００１６】 メモリ３４は、ＲＡＭ、ＲＯＭ等のメモリを含む。なお、メモリ３４は、ＨＤＤ（Hard Disk Driveの略）を含んでいてもよい。プログラム３６の他に、アカウントテーブル４０と、デバイステーブル５０と、利用テーブル６０と、を格納している。アカウントテーブル４０は、中継アカウント情報と、サービスＩＤと、サービスアカウント情報と、デバイスＩＤと、が対応付けられた情報を記憶するためのテーブルである。デバイステーブル５０は、デバイスＩＤと、ＩＰアドレスと、形式情報と、が対応付けられた情報を記憶するためのテーブルである。利用テーブル６０は、デバイスＩＤとサービスＩＤとが対応付けられた情報を記憶するためのテーブルである。各テーブル４０，５０，６０がどのようにして生成されるのかについては、後で詳しく説明する。」 「【００１７】 （サービス提供サーバ８０，８２の構成） 各サービス提供サーバ８０，８２は、例えば、「Ｅｖｅｒｎｏｔｅ（登録商標）」、「Ｇｏｏｇｌｅ（登録商標） Ｄｏｃｓ」、「ＰＩＣＡＳＡ（登録商標）」、「ＦＡＣＥＢＯＯＫ（登録商標）」等の公知のクラウドサーバである。各サービス提供サーバ８０，８２は、多機能機９０等の様々な通信機器にサービスを提供可能である。各サービス提供サーバ８０，８２からサービスの提供を受けるためには、通信機器のユーザは、サービスアカウント情報を、サービス提供サーバ８０，８２に、事前に登録する必要がある。サービスアカウント情報は、ユーザＩＤとパスワードとを含む。」 「【００２０】 （多機能機９０，９２，９４の構成） 多機能機９０は、インターネット４を介して、外部装置（例えば中継サーバ１０）と通信可能に接続されている。多機能機９０は、表示機能と印刷機能とスキャン機能とを実行可能である。表示機能は、インターネット４を介して受信されるデータで表される画像を、表示部に表示する機能である。印刷機能は、インターネット４を介して受信されるデータで表される画像を、印刷媒体に印刷する機能である。スキャン機能は、スキャン実行部にセットされた原稿を読み取って、スキャンデータを生成する機能である。多機能機９２，９４は、多機能機９０と同様の構成を有する。各多機能機９０，９２，９４には、多機能機を識別するデバイスＩＤ（「ＭＦＰ－Ａ」、「ＭＦＰ－Ｂ」及び「ＭＦＰ－Ｃ」）が、予め付与されている。なお、デバイスＩＤは、多機能機９０，９２，９４のＭＡＣアドレス等の多機能機に固有に付与されている情報である。」 「【００２６】 登録部７０は、多機能機９０からサービス登録指示を受信すると、Ｓ８において、サービス登録指示に含まれる中継アカウント情報と、サービスアカウント情報と、サービスＩＤと、多機能機９０のデバイスＩＤと、を含む組合せ情報を、アカウントテーブル４０に登録する。なお、サービス登録指示に含まれる中継アカウント情報が、アカウントテーブル４０に既に登録されている場合、登録済みの中継アカウント情報に組み合わせて、サービス登録指示に含まれるサービスアカウント情報と、サービスＩＤと、多機能機９０のデバイスＩＤと、をアカウントテーブル４０に登録する。Ｓ８が終了すると、Ｓ１０に進む。一方、サービス登録指示が受信されない場合、Ｓ８をスキップして、Ｓ１０に進む。」 「【００３０】 多機能機９０は、サービスリストを受信すると、サービスリストに含まれる１個以上のサービスＩＤを、多機能機９０の表示部に表示させる。多機能機９０のユーザは、１個以上のサービスＩＤのうち、１個のサービスＩＤを選択することができる。多機能機９０は、ユーザによって選択されたサービスＩＤを、中継サーバ１０に送信する。」 「【００３２】 Ｓ１８では、中継部７２は、Ｓ１０で受信済みのデバイスＩＤと、対象サービスＩＤと、を対応付けて利用テーブル６０に登録する。次いで、Ｓ２０では、中継部７２は、対象サービスＩＤのサービス提供サーバ（例えばサービス提供サーバ８０）に、１個以上の対象組合せ情報のうちの対象サービスＩＤを含む１個の対象組合せ情報に含まれるサービスアカウント情報を送信する。さらに、対象サービスＩＤがＮＥＷＳ－ｒｅｐｏｒｔである場合、Ｓ２０において、中継部７２は、Ｓ１０で受信済みのデバイスＩＤに対応付けて、デバイステーブル５０に登録されている形式情報を、対象サービスＩＤのサービス提供サーバに送信する。」 「【００４６】 （ニュース配信サービスの提供を受けるケース：図４） 次いで、第１のユーザが、多機能機９０を利用して、サービス提供サーバ８０からニュース配信サービスの提供を受ける際の各サーバ１０，８０及び多機能機９０の処理を説明する。」 「【００５１】 サービス提供サーバ８０は、サービスアカウント情報を受信すると、認証処理を実行する。認証処理が認証成功である場合、サービス提供サーバ８０は、多機能機９０の形式情報を利用して、Ａ４サイズのカラー画像を表すデータ形式のニュースを、中継サーバ１０に送信する。なお、サービス提供サーバ８０は、サービス提供サーバ８０に格納されているニュースのデータ形式が、形式情報に適合しないデータ形式である場合、データ形式を変換することによって生成されるニュースを、中継サーバ１０に送信する。中継サーバ１０は、サービス提供サーバ８０からニュースを受信すると、利用テーブル６０のサービスＩＤ「ＮＥＷＳ－ｒｅｐｏｒｔ」に対応付けられているデバイスＩＤ「ＭＦＰ－Ａ」を特定する（図２のＳ２６）。そして、中継サーバ１０は、受信済みのニュースを、デバイスＩＤ「ＭＦＰ－Ａ」の多機能機９０に送信する。多機能機９０は、ニュースを受信すると、Ａ４の印刷用紙に、受信済みのニュースで表される画像のカラー印刷を実行する。」 「【００８０】 （３）本実施例では、中継部７２は、形式情報を、対象サービスＩＤのサービス提供サーバに送信する。しかしながら、中継部７２は、形式情報を、対象サービスＩＤのサービス提供サーバに送信しなくてもよい。この場合、中継部７２は、サービス提供サーバから受信済みのデータが、形式情報によって示されるデータ形式を有するのか否かを判断してもよい。そして、中継部７２は、受信済みのデータが、形式情報によって示されるデータ形式を有する場合、受信済みのデータを、通信機器（例えば多機能機９０）に送信してもよい。一方、中継部７２は、受信済みのデータが、形式情報によって示されるデータ形式を有しない場合、受信済みのデータのデータ形式を、形式情報によって示されるデータ形式に変換してもよい。中継部７２は、変換済みのデータを、通信機器（例えば多機能機９０）に送信してもよい。本変形例では、中継部７２は、「形式情報を用いて、特定のデータ形式を有する特定のデータを特定の通信装置に送信する」構成を有する。」 （２） 引用発明 前記（１）より、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。 「中継サーバは、登録部と中継部とを備え、 登録部は、サービスアカウント情報を、アカウントテーブルに登録し、 中継サーバは、メモリを備え、 メモリは、アカウントテーブルを格納し、 サービスアカウント情報は、ユーザＩＤとパスワードとを含み、 中継部は、サービス提供サーバに、サービスアカウント情報を送信し、 サービス提供サーバは、サービスアカウント情報を受信すると、認証処理を実行し、認証処理が認証成功である場合、ニュースを、中継サーバに送信し、中継サーバは、サービス提供サーバからニュースを受信し、中継部は、受信済みのデータのデータ形式を、形式情報によって示されるデータ形式に変換し、変換済みのデータを、多機能機に送信し、 ユーザが、多機能機を利用して、サービス提供サーバからニュース配信サービスの提供を受け、 多機能機は、インターネットを介して、中継サーバと通信可能に接続されている、 中継サーバ。」 ２ 甲第１号証から甲第３号証について （１）甲第１号証の記載事項 甲第１号証には、「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」に関して、次の事項が記載されている。 （第２ページ） 「■連携によって実現すること この度のSCIM連携により、「SmartHR」の導入企業は「SmartHR」に登録している人事情報に基づいて、Oktaのアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーションのアクセス権の作成、更新、停止などのアカウント管理を自動化できます。具体的には、従業員の人事情報に基づいて、業務で使用するアプリケーションのアクセス権を自動的に割り当てたり、従業員が退職した情報をもとにアクセス権を自動で停止することが可能です。手作業によるアカウント管理が不要となり、システム管理者の負荷を大幅に減らすほか、アクセス権の更新漏れによる情報漏洩のセキュリティリスクも低減します。」 ＜人事情報に基づくアカウント管理自動化のイメージ＞ ［図：0001434141000002.jpg］ （第３，４ページ） 「■Oktaについて Oktaは、すべての人のアイデンティティとアクセスを安全に管理するベンダーニュートラルなサービスプロバイダーです。Oktaが提供するプラットフォーム「Okta Identity Cloud」により、クラウド、オンプレミスを問わず、適切な人に適切なテクノロジーを適切なタイミングで安全に利用できるようにします。7,300以上のアプリケーションとの事前統合が完了している「Okta Integration Network」を活用して、あらゆる人や組織にシンプルかつ安全なアクセスを提供し、お客様の潜在能力を最大限発揮できるように支援します。JetBlue、Nordstrom、Siemens、Slack、T-Mobile、武田薬品、Teach for America、Twilioを含む4,000以上のお客様がOktaを活用して、職場や顧客のアイデンティティを保護しています。」 （第４ページ） 「■クラウド人事労務ソフト「SmartHR 」について SmartHRは、労務管理クラウド4年連続シェアNo.1(※2)のクラウド人事労務ソフトです。雇用契約や入社手続き、年末調整などの多様な労務手続きをペーパーレス化し、データとして蓄積。また、勤怠管理システムや給与計算システム等との連携により、様々なデータの一元管理も可能に。さらに、SmartHRに溜まった従業員データを活用した「人事評価」「従業員サーベイ」などの人材マネジメント機能により、組織の活性化や組織変革を推進。すべての人が働きやすい環境づくりに貢献します。 SmartHRは、煩雑で時間のかかる人事・労務業務から経営者、人事・労務担当者、従業員を解放し、企業の生産性向上を後押しします。」 （２）甲第２号証の記載事項 甲第２号証には、「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」に関して、次の事項が記載されている。 （第１ページ） 「SmartHRがOktaとのSSO/SCIMによるプロビジョニングに対応したとの話題を見つけて早速検証してみました。」 （甲第１号証へのリンク） （第２ページ） 「大きな特徴はSmartHRをリソースとしてOkta側に反映できることですよね。通常であればOktaからSaasに対して反映させるため逆の流れとなります。」 （第４－９ページ） 「SCIM設定 事前設定 1. SmartHRの共通設定＞SCIM設定へ移動します。 2. email設定で従業員のemailを利用するのチェックを外し、更新するをクリックします。これは従業員情報のメールアドレスではなくSCIM用のカスタム項目のメールアドレスを利用したいためです。 3. SCIM設定の項目内の下線部分のAuthToken部分をコピーしておきます。 4. OktaのSmartHRアプリケーションのProvisioning設定のAPITokenに反映し、TestAPICredentialsをクリックし、問題がないことを確認したのちに、Saveします。 既存SmartHRユーザーのOktaへの反映 この操作はSmartHRにだけ存在しているユーザーをOktaに反映させる場合に設定します。すでにOktaにユーザーが作成されている場合は不要な操作です。 1. SCIM設定画面の最下部にあるSCIMSyncアカウント一覧をクリックします。 2. Provisioningの情報の編集をクリックします。 3. Oktaへ連携する情報を編集し、更新するをクリックします。 4. SCIM syncアカウントの編集からSCIMsyncの対象にチェックを入れます。 5.必要なユーザーについて手順2．から手順4．を繰り返します。 6. OktaのSmartHRアプリケーションのImportからImportNowをクリックします。 7.検出されたユーザーが表示されるため、Oktaに反映させるアカウントを選択し、ConfirmAssigmentsをクリックします。 8.確認画面が表示されます。ここでアクテイベーションを実施する場合は、Auto-activate users after confirmationにチェックを入れて、Confirmをクリックします。」 （３）甲第３号証の記載事項 甲第３号証には、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」に関して、次の事項が記載されている。 （第１ページ） 「SCIM (Systemf or Cross-domainI dentity Management:クロスドメインアイデンテイティ管理システム）は、ユーザープロビジョニングの自動化を可能にするオープン標準規格です。将来、テクノロジーがクラウドベースになることが明白になったことを受けて2011年に策定されました。SCIMは、アイデンテイテイプロバイダー（多数のユーザーを持つ企業など）とユーザーアイデンテイティ情報を要求するサービスプロバイダー（エンタープライズSaasアプリケーションなど）との間でユーザーアイデンテイテイデータをやり取りします」 （第２ページ） 「SCIMの仕組み SCIMはRESTおよびJSONベースのプロトコルで、クライアントとサーバーの役割を定義付けます。クライアントは通常、Oktaのようなアイデンテイテイプロバイダー(ldP) であり、ユーザーアイデンテイティの豊富な情報を収めたディレクトリを含みます。サービスプロバイダー(SP) は通常、BoxやSlackなどのSaasアプリケーションで、これらのアイデンテイティからの情報のサブセットを必要とします。ldPで作成、更新、削除といったアイデンテイティヘの変更が行われると、これらの変更はSCIMプロトコルに従って自動的にSPに同期されます。また、ldPはSPからアイデンテイティを読み取ってディレクトリに追加し、SPでセキュリティ上の脆弱性につながる不正な値を検出します。これにより、エンドユーザーは、最新のプロファイルとアクセス権を使って、自身が割り当てられたアプリケーションにシームレスにアクセスできるのです。 SCIMをベースにしたOktaをビジネスで体験 Oktaには、SCIMベースのものを含む、80以上の主要アプリとの統合のプロビジョニングが統合されています。また、Oktaは、5,000以上のアプリでシングルサインオンをサポートしています。さらに、業界をリードする何千ものアプリをAPIで統合することで、ユーザーデータを迅速かつ安全にやり取りします。ぜひ、Oktaのソリューションを30日間無料でお試しいただき、実際にユーザーアイデンテイティ管理がどう簡素化されるかをお確かめください。」 （４）甲１から甲３より把握される事項 甲１はSmartHRとOktaとの連携について記載されている、株式会社SmartHRの公式ウェブサイト上で公開されたプレスリリース記事であり、冒頭に記事の日付として「2022/03/02」と記載されている。 甲２は、SmartHRのアカウント情報をOktaに反映する際の実際の操作について言及している、一般ユーザによるブログ記事であり、記事中で甲１をリンクしており、冒頭に記事の日付として「2022.03.08」と記載されている。 甲３はOkta Japan株式会社の公式ウェブサイト上に掲載されている、Oktaについて言及されている記事であり、冒頭に記事の日付として「January 4, 2017」と記載されている。 加えて、甲１及び甲２はいずれも「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」について開示するものと認められ、甲３はアイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」について開示するものと認められる。 以上の点に鑑みれば、甲１から甲３に係る「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」は、本件特許出願前に公然知られる状況又は公然知られるおそれのある状況で実施された発明であるものと認められる。 ア 甲１に記載の事項によれば、クラウド人事労務ソフトである「SmartHR」の導入企業は、「SmartHR」に登録している人事情報に基づいて、Oktaの提供するアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーションのアカウント管理を自動化できる。 また、甲１の図面より、甲１には、SmartHRが、人事情報を管理するものであり、SmartHRからOktaに対し、「入社」、「従業員情報の更新」又は「退職」の情報が通知されると、Oktaは、「ユーザー発行」、「ユーザ情報更新」又は「ユーザー停止」の処理を行うとともに、対応APPに対し、「アカウント発行」、「アカウント更新」及び「アカウント停止」の通知を行うことが開示されているといえる。 イ 甲２に記載の事項によれば、SmartHRにだけ存在しているユーザーをOktaに反映させる場合に少なくとも以下の手順を行う。 ［事前設定］ （ア）SmartHRの共通設定のSCIM設定の項目内からAuth Tokenをコピーしておく。 （イ）OktaのSmartHRアプリケーションのProvisioning設定のAPI Tokenに反映し、 TestAPICredentialsをクリックし、問題がないことを確認したのちに、 Saveする。 ［Oktaへの反映］ （ウ）SmartHRのSCIM設定画面のSCIM Sync アカウント一覧において、必要なユーザーについて、 Provisioningの情報の編集をクリックし、Oktaへ連携する情報を編集し、更新するをクリックしのSCIM Syncアカウントの編集からSCIM Syncの対象にチェックを入れる。 （エ）OktaのSmartHRアプリケーションのImportからImport Nowをクリックする。 （オ）検出されたユーザ（（ウ）でチェックが入ったアカウントと同一と考えられる）が表示されるため、Oktaに反映させるアカウントを選択し、Comfirm Assigmnetsをクリックすると確認画面が表示され、アクテイベーションを実施する場合は、Auto-activate users after confirmationにチェックを入れて、Confirmをクリックする操作を行う。 ウ 甲３の記載によれば、SCIMはRESTおよびJSONベースのプロトコルであり、 Oktaには、SCIMベースのものを含む、80以上の主要アプリとの統合のプロビジョニングが統合されており、 Oktaのようなアイデンテイテイプロバイダー(ldP) で作成、更新、削除といったアイデンテイティヘの変更が行われると、これらの変更はSCIMプロトコルに従って自動的にサービスプロバイダー(SP) に同期される。 （５）甲１公然実施発明 上記（４）より、以下の発明（以下、「甲１公然実施発明」という。）が本願出願時において公然に実施されたものと認められる。 「クラウド人事労務ソフトである「SmartHR」と、アイデンティティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステムにおいて、 「SmartHR」の導入企業は「SmartHR」に登録している人事情報に基づいて、Oktaのアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーションのアクセス権の作成、更新、停止などのアカウント管理を自動化でき、 SmartHRは、人事情報を管理するものであり、SmartHRからOktaに対し、「入社」、「従業員情報の更新」又は「退職」の情報が通知されると、Oktaは、「ユーザー発行」、「ユーザ情報更新」又は「ユーザー停止」の処理を行うとともに、対応APPに対し、「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報の通知を行い、 SCIM設定における事前設定処理として、SmartHRにおけるSCIM設定の項目内のAuthTokenをコピーしておき、OktaのSmartHRアプリケーションのProvisioning設定のAPITokenに反映し、TestAPICredentialsをクリックし、問題がないことを確認したのちに、Saveし、 既存SmartHRユーザーのOktaへの反映処理として、必要なユーザーについて、Provisioningの情報の編集をクリックし、Oktaへ連携する情報を編集し、更新するをクリックし、SCIM syncアカウントの編集からSCIMsyncの対象にチェックを入れる処理を繰り返し、OktaのSmartHRアプリケーションのImportからImportNowをクリックし、検出されたユーザーが表示されるため、Oktaに反映させるアカウントを選択し、ConfirmAssigmentsをクリックすると確認画面が表示され、アクテイベーションを実施する場合は、Auto-activate users after confirmationにチェックを入れて、Confirmをクリックする操作を行い、 SCIMはRESTおよびJSONベースのプロトコルであり、Oktaには、SCIMベースのものを含む、80以上の主要アプリとの統合のプロビジョニングが統合されている、 システム。」 ３ 甲第４号証について （１）甲第４号証の記載事項 甲第４号証には、次の事項が記載されている。 「【００１６】 ［システムの構成］ 図１は、本実施形態に係るアカウント情報連携システムの構成を示した図である。 【００１７】 同図に示すように、このシステムは、１つの企業内の例えばイントラネット内に設けられたシステムであり、アカウント情報連携サーバ１００と、人事部システム２００と、その他の複数の社内システム１０（１０Ａ，１０Ｂ，１０Ｃ）を有する。 【００１８】 アカウント情報連携サーバ１００は、人事部システム２００及び複数の社内システム１０と通信可能である。アカウント情報連携サーバ１００は、人事部システム２００から送信される、従業員の人事に関するイベント情報を基に、当該イベントに伴って発生する各社員のアカウント情報の変更を、複数の社内システム１０において同期させることができる。」 （図１） ［図：0001434141000003.jpg］ 「【００４１】 ［アカウント情報連携サーバの機能ブロック構成］ 次に、上記アカウント情報連携サーバ１００が有する機能ブロックについて説明する。 【００４２】 （人事イベント（発令情報）に伴う連携処理） 図４は、上記アカウント情報連携サーバ１００による、人事イベント（発令情報）に伴うアカウント情報の連携処理に必要な機能ブロックを示した図である。 【００４３】 同図に示すように、アカウント情報連携サーバ１００は、人事イベントに伴うアカウント情報の連携処理のために、発令情報取込部４１及び複数のシステム連携制御部４２（Ａシステム連携制御部４２Ａ，Ｂシステム連携制御４２Ｂ，Ｃシステム連携制御４２Ｃ等）を有する。 【００４４】 人事部の担当者から人事部システム２００を介して発令情報Ｐがアカウント情報連携サーバ１００へ送信されると、上記発令情報取込部４１が当該発令情報を受信し、当該発令情報を基にＴｏＤｏリスト３４が生成される。 【００４５】 このＴｏＤｏリスト３４の生成には、上記発令情報の送信に伴って社内の情報システム部の担当者から社員管理画面を介して入力された社員ＩＤや、総務部の担当者からカード管理画面及び入室権限管理画面を介して入力された社員カード番号等も使用される。 【００４６】 生成されたＴｏＤｏリスト３４は、上記記憶部１８に記憶され、各システム連携制御部４２は、定期的に（１日に数回等の頻度で）当該ＴｏＤｏリストを参照する。」 「【００５１】 そして、上記各システム連携制御部４２は、ＴｏＤｏリスト３４を参照した日が、当該ＴｏＤｏリスト３４に含まれる実行予定日である場合に、上記人事イベントに対応するアカウント情報の同期要求を、上記対応する社内システム１０へ（すなわち、例えばＡシステム連携制御部４２ＡはＡシステム１０Ａへ、Ｂシステム連携制御部４２ＢはＢシステム１０Ｂへ）それぞれ送信する。」 （図４） ［図：0001434141000004.jpg］ （２）甲４から把握される発明 上記（１）から、甲４には次の発明（以下、「甲４発明」と呼ぶ）が記載されている。 「人事部の担当者から人事部システム２００を介して発令情報Ｐがアカウント情報連携サーバ１００へ送信されると、発令情報Ｐを送信する人事部システム２００から発令情報を受信し、当該発令情報を基にＴｏＤｏリスト３４を生成する発令情報取込部４１と、 ＴｏＤｏリスト３４を記憶する記憶部１８と、 ＴｏＤｏリスト３４を参照して、社内システム１０にアカウント情報の同期要求を送信するシステム連携制御部４２と、 を有するアカウント情報連携サーバ１００。」 第８ 取消理由についての判断 当審取消理由（進歩性）について以下検討する。 １ 本件特許発明１について （１） 対比 本件特許発明１と引用発明とを対比する。 ア 引用発明の「ユーザＩＤとパスワードとを含」む「サービスアカウント情報」は、これを受信した「サービス提供サーバ」が「認証処理を実行」するための情報であるから、本件特許発明１の「提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報」と、「認証情報」である点で共通する。そして、引用発明において「中継サーバ」が備える「登録部」が「サービスアカウント情報を、アカウントテーブルに登録」することは、本件特許発明１の「認証情報を記憶」することに相当し、「アカウントテーブルを格納」する「メモリ」は、本願発明１の「中継記憶部」に相当する。 イ 引用発明において「中継サーバ」が備える「中継部」が「サービス提供サーバに、サービスアカウント情報を送信」し、「サービス提供サーバ」が「サービスアカウント情報を受信すると、認証処理を実行し、認証処理が認証成功である」とすることは、上記アを踏まえると、本件特許発明１の「前記認証情報によって認証を受け」ることに相当する。 ウ 引用発明は「ユーザが、多機能機を利用して、サービス提供サーバからニュース配信サービスの提供を受ける」ものであるところ、「サービス提供サーバ」が「中継サーバに送信」する「ニュース」は、「情報」と言い得るものであり、「提供」元である「サービス提供サーバ」から「ユーザ」に「提供」されるものであるから、「提供元ユーザ情報」と言い得るものである。また、引用発明の「サービス提供サーバ」は「ニュース」を「提供」する「装置」、すなわち、「情報提供装置」と言い得るものである。したがって、引用発明において「中継サーバ」が「サービス提供サーバからニュースを受信」することは、本件特許発明１の「前記情報提供装置から前記提供元ユーザ情報を取得」することに相当する。 エ 引用発明は「中継サーバ」が備える「中継部」が「受信済みのデータのデータ形式を、形式情報によって示されるデータ形式に変換し、変換済みのデータを、多機能機に送信」するものであるところ、「受信済みのデータ」は「サービス提供サーバ」から「中継サーバに送信」された「ニュース」であると認められ、上記ウのとおり、「提供元ユーザ情報」と言い得るものである。また、「形式情報によって示されるデータ形式に変換」された「変換済みのデータ」は、「中継」する機能を有する「中継部」によって「ユーザ」に「利用」される「多機能機に送信」される情報であるから、「中継ユーザ情報」と言い得るものである。さらに、「中継ユーザ情報」は「提供元ユーザ情報」の「データ形式を、形式情報によって示されるデータ形式に変換」したものであるから、「提供元ユーザ情報に基づく」ものといえる。 オ 引用発明の「変換済みのデータ」は「受信済みのデータ」を「変換」する処理の結果であるといえるところ、装置においてデータを処理した結果をメモリ等に記憶することは、本件特許出願時における技術常識であるから、引用発明において「受信済みのデータのデータ形式を、形式情報によって示されるデータ形式に変換」する処理は、「変換済みのデータ」を「メモリ」に「記憶させる」処理を含むものと認められる。 カ 引用発明は「変換済みのデータを、多機能機に送信」するものであり、「多機能機は、インターネットを介して、中継サーバと通信可能に接続されている」ものであるところ、「変換済みのデータ」は「インターネットを介して」「多機能機に送信」されるものと認められる。ここで、ネットワークを介してデータを通信相手に送信する際、データからネットワークや通信プロトコル等に応じた所定形式を有する送信情報を生成して、当該送信情報をネットワークに送信することは、本件特許出願時における技術常識であるから、引用発明の「変換済みのデータを、多機能機に送信」する処理は、「変換済みのデータ」に基づいて、「所定形式を有する送信情報を生成する」処理を含むものと認められる。また、引用発明において「変換済みのデータ」を「送信」された「多機能機」は、「変換済みのデータ」を受け取る「装置」、すなわち、「情報受取装置」と言い得るものである。 以上のことから、引用発明において「変換済みのデータを、多機能機に送信」することは、本件特許発明１の「前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する」こと、及び「前記送信情報を情報受取装置に送信する」ことに相当する。 キ 上記イからカを踏まえると、引用発明の「中継部」を備える「中継サーバ」は、本件特許発明１の「前記認証情報によって認証を受け」て、「前記情報提供装置から前記提供元ユーザ情報を取得」し、「前記提供元ユーザ情報に基づく中継ユーザ情報」を「記憶させる」「ユーザ情報取得部」、「前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する」「送信情報生成部」、及び「前記送信情報を情報受取装置に送信する」「送信部」に相当する機能を備えているといえる。 ク 上記アからキを踏まえると、引用発明の「登録部と中継部とを備え」る「中継サーバ」は、後述する相違点を除いて、本件特許発明１の「情報中継装置」に相当する。 （２） 一致点・相違点 以上から、本件特許発明１と引用発明とは、以下の点において一致ないし相違する。 ア 一致点 「認証情報を記憶する中継記憶部と、 前記認証情報によって認証を受けて、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部と、 前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、 前記送信情報を情報受取装置に送信する送信部と、 を有する情報中継装置。」 イ 相違点 （ア）相違点１ 本件特許発明１の「認証情報」は「情報提供装置にアクセスするための」ものであり、「情報中継装置」は「提供元ユーザ情報を取得」するために「情報提供装置にアクセス」するのに対し、引用発明における「ユーザＩＤとパスワードとを含」む「サービスアカウント情報」は、「ユーザが、多機能機を利用して、サービス提供サーバからニュース配信サービスの提供を受け」るためのものといえるものの、「サービス提供サーバ」にアクセスするためのものとはいえない点。 （イ）相違点２ 本件特許発明１の「所定形式」は、「SCIMに準拠したJSON形式」であるのに対し、引用発明における「変換済みのデータ」は「インターネットを介して」「多機能機に送信」されるものであって、データからネットワークや通信プロトコル等に応じた「所定形式」を有するとはいえるものの、「SCIMに準拠したJSON形式」ではない点。 （３）相違点についての判断 事案に鑑みて、先に相違点２について検討する。 ここで、相違点２における「SCIM」が、System for Cross-domain Identity Management の略であり、サービスやシステム間でユーザのＩＤ情報をやり取りするための標準仕様であることは、本件特許出願時における技術常識である。一方、上記第７のとおり、引用文献１に記載された発明は、多機能機等の通信機器に対して、ニュース配信等のサービスを提供するものであり、多機能機等の通信機器との間でユーザのＩＤ情報をやり取りすることは記載も示唆もされておらず、かつ、そのような態様が本件特許出願時における周知技術であったともいえないから、引用文献１に記載された発明において、所定形式を「SCIMに準拠したJSON形式」とする動機付けがあるとはいえない。 （４）まとめ よって、相違点１について検討するまでもなく、本件特許発明１は、当業者が、引用文献１に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。 ２ 本件特許発明３，６，８について 本件特許発明３，６，８は、本件特許発明１の構成をすべて含む発明であるから、本件特許発明１と同様に、当業者が、引用文献１に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。 ３ 本件特許発明９について 本件特許発明９は、本件特許発明１を方法の発明として特定したものと認められる。 よって、本件特許発明１と同様に、当業者が、引用文献１に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。 ４ 本件特許発明１０について 本件特許発明１０は、本件特許発明１をプログラムの発明として特定したものと認められる。 よって、本件特許発明１と同様に、当業者が、引用文献１に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。 ５ 令和７年５月２９日付け取消理由について 上記１から４のとおり、令和７年５月２９日付けで通知した取消理由の対象となる請求項１，３，６，８－１０に対応する本件特許発明１，３，６，８－１０は引用発明に対して進歩性を有する。 したがって、当該取消理由は、解消した。 ６ 当審取消理由について 上記１から４のとおり、令和７年９月４日付けで通知した取消理由の対象となる請求項１，３，６，８－１０に対応する本件特許発明１，３，６，８－１０は引用発明に対して進歩性を有する。 したがって、当該取消理由は、解消した。 第９ 取消理由として採用しなかった申立理由について １ 申立理由１について （１）本件特許発明１について ア 対比 以下、本件特許発明１と甲１公然実施発明とを対比する。 （ア） 甲１公然実施発明における「クラウド人事労務ソフトである「SmartHR」」は、直接的には、「Okta」に対し、「「入社」、「従業員情報の更新」又は「退職」の情報」（本件特許発明１の「提供元ユーザ情報」に相当する。）を通知（提供）し、また、間接的には、「対応APP」に対し、「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」を通知（提供）するものであるところ、“情報提供手段”として機能しているといえ、甲１公然実施発明における「SmartHR」と、本件特許発明１の「情報提供装置」とは、「情報提供手段」である点において共通する。 甲１公然実施発明における「AuthToken」は、“Authentication Token”のことと解されるところ、“認証情報”といい得るものである。そして、当該「AuthToken」は、「OktaのSmartHRアプリケーションのProvisioning設定のAPITokenに反映」し、「Save」すなわち、記憶されるものであるところ、「Okta」は、「AuthToken」を記憶する“記憶部”として機能するものと認められる。 しかしながら、甲１公然実施発明における「AuthToken」は、何に使用される認証情報であるのかが具体的に特定されておらず、また、甲１公然実施発明においては、そもそも、「Okta」が「SmartHR」に“アクセス”することは開示されていない。 よって、甲１公然実施発明の「Okta」が備える“記憶部”と、本件特許発明１の「提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶する中継記憶部」とは、「認証情報を記憶する記憶部」である点において共通する。 （イ） 甲１公然実施発明において、「Okta」は、「SmartHR」から、「「入社」、「従業員情報の更新」又は「退職」の情報」を取得する“ユーザ情報取得部”として機能しているといえる。 また、甲１公然実施発明において、「Okta」は、通知（提供）された情報に基づいて「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」を生成しこれを「対応APP」に通知（送信）するものと解されるところ、当該「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」は、本件特許発明１の「前記提供元ユーザ情報に基づく中継ユーザ情報」に相当する。また、甲１公然実施発明において、「Okta」は、「対応APP」に通知（送信）する情報を一時的に記憶していると認められるものの、当該記憶する場所が、「AuthToken」が記憶される“記憶部”と同じであるかどうかまでは特定されていない。 よって、上記（ア）を参酌すれば、甲１公然実施発明の「Okta」が備える“ユーザ情報取得部”と、本件特許発明１の「前記認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部」とは、「情報提供手段から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を記憶させるユーザ情報取得部」である点において共通する。 （ウ） アプリケーション等の間で通信するデータを、当該アプリケーション等の間通信において採用されている所定の形式に変換して通信がなされることは本願出願時における技術常識であるところ、甲１公然実施発明において、「Okta」は、通知（送信）すべき情報を所定の形式に変換する“送信情報生成部”及び、変換した情報を「対応APP」に送信する、“送信部”として機能していると認められる。 また、甲１公然実施発明において、「対応APP」は、「Okta」から通知（送信）された情報を受け取る“情報受取手段”として機能しているといえ、当該“情報受取手段”と、本件特許発明１における「情報受取装置」とは、「情報受取手段」である点において共通する。 よって、甲１公然実施発明の「Okta」が備える“送信情報生成部”は、本件特許発明１における「前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部」に相当し、甲１公然実施発明の「Okta」が備える“送信部”と、本件特許発明１における「前記送信情報を情報受取装置に送信する送信部」とは、「前記送信情報を情報受取手段に送信する送信部」である点において共通する。 （エ） 甲１公然実施発明において、「SCIMはRESTおよびJSONベースのプロトコルであり、Oktaには、SCIMベースのものを含む、80以上の主要アプリとの統合のプロビジョニングが統合されている」との事項によれば、甲１公然実施発明におけるシステムは、SCIMに準拠したJSON形式を採用したものであることは明らかである。よって、甲１公然実施発明における前記事項と、本件特許発明１における「前記所定形式は、SCIMに準拠したJSON形式である」こととは、「SCIMに準拠したJSON形式を採用している」ことである点において共通する。 （オ） 甲１公然実施発明の「アイデンティティ管理・認証基盤プラットフォームを提供する「Okta」」は、情報を中継する“情報中継手段”として機能しているといえる。よって、甲１公然実施発明の「Okta」と、本件特許発明１における「情報中継装置」とは、「情報中継手段」である点において共通する。 イ 一致点、相違点 以上によれば、本件特許発明１と甲１公然実施発明とは、以下の点において一致ないし相違する。 （ア）一致点 「認証情報を記憶する記憶部と、 情報提供手段から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を記憶させるユーザ情報取得部と、 前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、 前記送信情報を情報受取手段に送信する送信部と、 を有し、 SCIMに準拠したJSON形式を採用している、 情報中継手段。」 （イ）相違点 ａ 相違点１－１ 本件特許発明１は、「提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報」を記憶すると共に、「前記認証情報によって認証を受けて前記情報提供装置にアクセス」することにより、提供元ユーザ情報を取得するのに対し、甲１公然実施発明において、「Okta」が記憶する「AuthToken」が、「SmartHR」にアクセスするためのものであって、「AuthToken」によって認証を受けて「SmartHR」にアクセスし、「SmartHR」から「「入社」、「従業員情報の更新」又は「退職」の情報」を取得することを具体的に特定していない点。 ｂ 相違点１－２ 共通する「情報提供手段」が、本件特許発明１においては、「情報提供装置」であるのに対し、甲１公然実施発明においては、「クラウド人事労務ソフトである「SmartHR」」であり、共通する「情報受取手段」が、本件特許発明１においては、「情報受取装置」であるのに対し、甲１公然実施発明においては「対応APP」であり、また、共通する「情報中継手段」が、本件特許発明１においては、「情報中継装置」であるのに対し、甲１公然実施発明においては「アイデンティティ管理・認証基盤プラットフォームを提供する「Okta」」である点。 すなわち、本件特許発明１は、複数の「装置」が連携してなるシステムを前提としているのに対し、甲１公然実施発明は、全体としてみれば、プラットフォームとソフトウェアが連携したシステムである点。 ｃ 相違点１－３ 共通する「記憶部」が、本件特許発明１においては、「認証情報」のみならず、「中継ユーザ情報」をも記憶する「中継記憶部」であるのに対し、甲１公然実施発明において、「AuthToken」が記憶される“記憶部”に、「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」が記憶されることを具体的に特定していない点。 ｄ 相違点１－４ 本件特許発明１においては、「前記所定形式は、SCIMに準拠したJSON形式である」との構成を有するのに対し、甲１公然実施発明においては、「SCIMはRESTおよびJSONベースのプロトコルであり、Oktaには、SCIMベースのものを含む、80以上の主要アプリとの統合のプロビジョニングが統合されている」との事項を含むものの、「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」を「SCIMに準拠したJSON形式」で送信することを具体的に特定していない点。 ウ 相違点についての判断 まず、上記相違点１－１～１－４はいずれも、形式的なものではないから、本件特許発明１は、甲１公然実施発明と同一であるとはいえない。 また、相違点１－１について検討するに、「「SmartHR」の導入企業は「SmartHR」に登録している人事情報に基づいて、Oktaのアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーションのアクセス権の作成、更新、停止などのアカウント管理を自動化でき」との構成によれば、甲１公然実施発明における「AuthToken」は、「Oktaのアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーション」に対する「アクセス権」を認証するものであるとも解されるところ、甲１公然実施発明の構成から直ちに、当業者が、「AuthToken」が「SmartHR」にアクセスするためのものであって、「AuthToken」によって認証を受けて「SmartHR」にアクセスし、「SmartHR」から「「入社」、「従業員情報の更新」又は「退職」の情報」を取得するとの構成を想到することが容易であるとはいえない。 また、当該相違点１－１に係る本件特許発明１の構成は、甲４にも記載がなく、また、本願出願時における技術常識であったとも認められない。 また、事案に鑑みて、次に相違点１－３について検討するに、当該相違点１－３に係る本件特許発明１の構成は、当業者といえども、甲１公然実施発明の構成から容易に想到し得るものではなく、また、アクセスを認証するための認証情報とユーザ提供元情報に基づく情報とを同じ記憶部に記憶することは、甲４にも記載がなく、また、本願出願時における技術常識とも認められない。 以上のことから、相違点１－２及び１－４について検討するまでもなく、本件特許発明１は、当業者が甲１公然実施発明に基づいて容易に発明をすることができたものとはいえない。 エ まとめ 以上のとおりであるから、本件特許発明１は、当業者が、甲第１号証から甲第３号証より把握される甲１公然実施発明ではなく、甲１公然実施発明に基づいて、容易に発明をすることができたものともいえない。 （２）本件特許発明３，６，８について 本件特許発明３，６，８は、本件特許発明１の構成をすべて含む発明であるから、本件特許発明１と同様に、当業者が、甲第１号証から甲第３号証より把握される甲１公然実施発明ではなく、甲１公然実施発明に基づいて、容易に発明をすることができたものともいえない。 （３）本件特許発明９について 本件特許発明９は、本件特許発明１を方法の発明として特定したものと認められる。 よって本件特許発明１と同様に、当業者が、甲第１号証から甲第３号証より把握される甲１公然実施発明ではなく、甲１公然実施発明に基づいて、容易に発明をすることができたものともいえない。 （４）本件特許発明１０について 本件特許発明１０は、本件特許発明１をプログラムの発明として特定したものと認められる。 よって本件特許発明１と同様に、当業者が、甲第１号証から甲第３号証より把握される甲１公然実施発明ではなく、甲１公然実施発明に基づいて、容易に発明をすることができたものともいえない。 ２ 申立理由２について （１）本件特許発明１について ア 対比 以下、本件特許発明１と甲４発明とを対比する。 （ア）甲４発明の「発令情報Ｐ」はユーザの情報を含む情報であるから、本件特許発明１の「提供元ユーザ情報」に相当する。 甲４発明の「人事部システム２００」は「発令情報Ｐ」を「アカウント情報連携サーバ１００」に提供する装置であるから、本件特許発明１の「提供元ユーザ情報を提供する情報提供装置」に相当する。 しかしながら、甲４発明の「アカウント情報連携サーバ１００」は下記（イ）でも述べる「記憶部１８」を有するものの、甲４にはアクセスするための「認証情報」を記憶することは記載されていない。加えて甲４には「アカウント情報連携サーバ１００」が「人事部システム２００」にアクセスすることも記載されていない。 よって、甲４発明の「記憶部１８」と、「提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶する中継記憶部」とは、「記憶部」である点において共通する。 （イ）上記（ア）で述べたとおり、甲４発明の「アカウント情報連携サーバ１００」は「認証情報によって認証を受けて情報提供装置にアクセス」するものではないが、「人事部システム２００」から「発令情報Ｐ」を受信するものであるから、本件特許発明１の「ユーザ情報取得部」と、「提供元ユーザ情報を取得」する点で共通する。 甲４発明の「ＴｏＤｏリスト３４」は、「発令情報Ｐ」を基に生成されるものであるから、本件特許発明１の「提供元ユーザ情報に基づく中継ユーザ情報」に相当する。 甲４発明の「記憶部１８」は、生成された「ＴｏＤｏリスト３４」を記憶しているから、「中継ユーザ情報」を「記憶する」点で本件特許発明１の「中継記憶部」と共通している。 そして、甲４発明の「発令情報取込部４１」は、受信した「発令情報Ｐ」に基づいて「ＴｏＤｏリスト３４」を生成して「記憶部１８」に記憶させているから、本件特許発明１の「前記認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部」とは、「前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部」点である点において共通する。 （ウ）甲４発明の「社内システム１０」は、「アカウント連携サーバ１００」からアカウント情報の同期要求が送信されるものであるから、本件特許発明１の「情報受取装置」と、「情報中継装置」から情報が送信される点で共通する。 甲４発明の「システム連携制御部４２」は、「アカウント情報連携サーバ１００」が記憶する「ＴｏＤｏリスト３４」を参照して、「社内システム１０」に「アカウント情報の同期要求」を送信するものである。ここで、甲４には「アカウント情報の同期要求」を、「社内システム１０」に送信すると、「社内システム１０」のアカウント情報が同期されることが記載されているから、「中継ユーザ情報」を基にした、何らかの所定形式を有する情報が送信されているものと認められる。 よって、甲４発明の「システム連携制御部４２」は、「中継ユーザ情報に基づいて」、「所定形式を有する情報を生成」する点で本件特許発明１の「送信情報生成部」と共通し、生成した情報を「情報受取装置に送信」する点で、本件特許発明１の「送信部」と共通する。 イ 一致点、相違点 以上から、本件特許発明１と甲４発明とは、以下の点において一致又は相違する。 （ア）一致点 「記憶部と、 情報提供装置から提供元ユーザ情報を取得し、提供元ユーザ情報に基づく中継ユーザ情報を記憶部に記憶させるユーザ情報取得部と、 中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、 送信情報を情報受取装置に送信する送信部と、 を有する情報中継装置。」 （イ）相違点 ａ 相違点２－１ 本件特許発明１の中継記憶部は提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶しているが、甲４発明の記憶部１８はそのような情報を有していない点。 ｂ 相違点２－２ 本件特許発明１のユーザ情報取得部は認証情報によって認証を受けて情報提供装置にアクセスし、情報提供装置から提供元ユーザ情報を取得しているのに対し、甲４発明の発令情報取込部（アカウント連携サーバ１００）は人事部システム２００から発令情報Ｐを受信するにあたり、認証情報によって認証を受けて人事部システム２００にアクセスすることを具体的に特定していない点。 ｃ 相違点２－３ 本件特許発明１の「送信情報」はSCIMに準拠したJSON形式であるのに対し、甲４発明の「アカウント情報の同期要求」とはどのような形式であるのか不明である点。 ウ 相違点についての判断 事案に鑑みて、先に相違点２－２について検討する。 甲４にはアカウント連携サーバ１００が認証情報によって認証を受けて人事部システム２００にアクセスすること、アカウント連携サーバ１００が人事部システム２００に情報を取得するためにアクセスすること、について記載も示唆もなく、そのことが、本願出願時における技術常識であったともいえない。加えて、甲４発明は、人事部の担当者から人事部システム２００を介して発令情報Ｐがアカウント情報連携サーバ１００へ送信されることを契機として、人事部システム２００から一方的に発令情報Ｐが送信されることを前提としていることに鑑みれば、当業者といえども、アカウント連携サーバ１００が能動的に人事部システム２００にアクセスして情報を取得するように構成を変更することを容易に想到することができたとはいえない。 なお、上記と同様の理由により、相違点２－１についても、甲４発明において記憶部に人事部システム２００にアクセスするための認証情報を記憶するよう構成することは、当業者が容易に想到し得たものではない。 エ まとめ 以上のとおりであるから、他の相違点について検討するまでもなく、本件特許発明１は、当業者が、甲第４号証に記載された発明に基づいて、容易に発明をすることができたものではない。 （２）本件特許発明３，６，８について 本件特許発明３，６，８は、本件特許発明１の構成をすべて含む発明であるから、本件特許発明１と同様に、当業者が、甲第４号証に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。 （３）本件特許発明９について 本件特許発明９は、本件特許発明１を方法の発明として特定したものと認められる。 よって、本件特許発明１と同様に、当業者が、甲第４号証に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。 （４）本件特許発明１０について 本件特許発明１０は、本件特許発明１をプログラムの発明として特定したものと認められる。 よって、本件特許発明１と同様に、当業者が、甲第４号証に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。 ３ 申立人の主張について （１） 申立人の主張 申立人は、申立理由１又は２について、次のように述べている。 ア 主張１（特許異議申立書第１８ページ） 「（Ｉ-1-6) 小括 以上より、引用発明１は、本件特許発明１の構成要件１Ａ～１Ｅを全て充足するから、本件特許発明１は、引用発明１に基づいて新規性を有さない。 また、上記のとおり、本件特許発明１と引用発明１との間には差異が認められないが、仮に何らかの差異が認められるとしても、本件特許発明１は、引用発明１に基づいて当業者が容易に想到し得たものであり、進歩性を有さない。」 イ 主張２（特許異議申立書第２６ページ） 「よって、引用発明２は、以下の相違点１に係る構成を備えるか不明である点においてのみ、本件特許発明１と相違する。 （相違点１）情報中継装置が、情報提供装置にアクセスするための認証情報を記憶する中継記憶部を有し、前記認証情報によって認証を受けて前記情報提供装置にアクセスする。 しかし、甲第４号証には、アカウント情報連携サーバ１００（情報中継装置）が人事部システム２００（情報提供装置）へ認証を受けてアクセスすることは特に記載されていないものの、人事部システム２００から発令情報Ｐがアカウント情報連携サーバ１００へ送信されることは記載されている。この点、引用発明２において、アカウント情報連携サーバ１００が人事部システム２００から発令情報Ｐを取得するに当たり、人事部システム２００側から、予め記憶した認証情報による認証を受けてアクセスすることには格別の技術的意義はなく、このような構成を採用することは、当業者が適宜選択し得る設計的事項であると言える。 以上より、引用発明２において相違点１に係る構成を採用することは、当業者の通常の創作能力の発揮であると言えるから、本件特許発明１は、引用発明２に基づいて当業者が容易に想到し得たものであり、進歩性を有さない。」 ウ 主張３（令和７年８月２２日提出意見書第２ページ） 「相違点２については、当業者が適宜選択し得る設計事項に過ぎません」 （２）申立人の主張についての検討 ア 主張１について 上記１のとおり、本件特許発明１と、甲第１号証から甲第３号証より把握される甲１公然実施発明との間には、上記相違点１－１～１－４が認められるところ、少なくとも相違点１－２及び１－３に係る本件特許発明１の構成については、当業者が容易に想到し得たものではない以上、本件特許発明１は、新規性及び進歩性を有する。よって、申立人の上記主張は、その前提に誤りがある。 イ 主張２について 申立人が主張する上記相違点１は、相違点２－１及び２－２に対応したものと解されるが、上記２において説示したとおり、相違点２－１及び２－２に係る本件特許発明１の構成を当業者が容易に想到し得たとはいえない。また、申立人は、人事部の担当者から人事部システム２００を介して発令情報Ｐがアカウント情報連携サーバ１００へ送信されることを契機として、人事部システム２００から一方的に発令情報Ｐが送信されることを前提としている甲４発明において、「アカウント情報連携サーバ１００が人事部システム２００から発令情報Ｐを取得するに当たり、人事部システム２００側から、予め記憶した認証情報による認証を受けてアクセスすることには格別の技術的意義はなく、このような構成を採用することは、当業者が適宜選択し得る設計的事項であると言える。」と主張する根拠について具体的に説明をしていない。 ウ 主張３について 上記１（１）で述べたように、少なくとも相違点１－２及び１－３に係る本件特許発明１の構成については、当業者が容易に想到し得たものではない以上、相違点１－４（申立人が主張する相違点２に相当）について検討するまでもなく、本件特許発明１は、当業者が公然実施発明に基づいて容易に発明することができたものとはいえない。 以上のとおりであるから、申立人の主張はいずれも採用しない。 第１０ むすび 以上のとおりであるから、請求項１，３，６，８－１０に係る発明は、各取消理由通知書に記載した取消理由並びに特許異議申立書に記載された特許異議の申立ての理由及びその証拠によって取り消すことはできない。さらに、他に請求項１，３，６，８－１０に係る特許を取り消すべき理由を発見しない。 また、請求項２は、本件訂正により削除されたため、申立人による特許異議の申立てにおける請求項２に係る特許についての申立ては、申立ての対象が存在しないものとなったので、特許法第１２０条の８第１項で準用する同法第１３５条の規定により却下する。