Trademark Appeal Case
本データベースは、特許庁の審決例をAIで解析・要約したものです。拒絶理由通知に対する意見書作成や、審判請求書等の作成時の参考としてお役立てください。
| 審判番号 | 2025700191 |
|---|---|
| 審判種別 | 記載はありません。 |
| 結論 | 敗訴（請求棄却） |
理 由
本件特許第7538979号(以下、「本件特許」という。)についての出願は、令和6年5月30日に出願され、令和6年8月14日にその特許権の設定登録がされ、令和6年8月22日に特許掲載公報が発行された。
そして、特許異議申立人 黒川美千代(以下、単に「申立人」という。)による特許異議の申立て(以下、「本件異議申立て」という。)に係る手続の経緯は、以下のとおりである。
令和7年 2月13日 :特許異議申立書の提出
令和7年 5月29日付け:取消理由通知書
令和7年 7月25日 :訂正請求書、意見書の提出
令和7年 7月31日付け:通知書
令和7年 8月22日 :意見書の提出(申立人)
令和7年 9月 4日付け:取消理由通知書
令和7年 9月19日 :訂正請求書、意見書の提出
令和7年 9月25日付け:通知書
なお、特許法第120条の5第7項の規定により、令和7年7月25日に提出された訂正請求書に係る訂正の請求は、令和7年9月19日に提出された訂正請求書に係る訂正の請求(以下、この請求に係る訂正を「本件訂正」という。)により、取り下げられたものとみなす。
特許異議申立書の全趣旨からして、申立人が主張する特許異議の申立ての理由(以下、「申立理由」という。)及び証拠は、以下のとおりのものと認められる。
(1)申立理由1
本件特許発明1-3,6,8-10は、本件特許出願前に公然知られる状況又は公然知られるおそれのある状況で実施された引用発明1と同一であるか、或いは、引用発明1に基づいて当業者が容易に想到し得たものである。よって、本件特許発明1-3,6,8-10は、特許法第29条第1項第2号又は同条第2項の規定により特許を受けることができない。したがって、請求項1-3,6,8-10に係る本件特許は、特許法第113条第2号により取り消すべきものである。
(2)申立理由2
本件特許発明1-3,6,8-10は、引用発明2に基づいて当業者が容易に想到し得たものである。よって、本件特許発明1-3,6,8-10は、特許法第29条第2項の規定により特許を受けることができない。したがって、請求項1-3,6,8-10に係る本件特許は、特許法第113条第2号により取り消すべきものである。
申立理由1における引用発明1とは、以下の2に記載の証拠のうち甲第1号証から甲第3号証に係る「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」についての公然実施された発明(以下、「公然実施発明」と呼ぶ)であり、申立理由2における引用発明2とは、甲第4号証に記載の発明であると認められる。
甲第1号証:クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携した引用システム1についてのプレスリリース記事を掲載するウェブサイト
URL :https://smarthr.jp/release/33413/
甲第2号証:「SmartHRがSCIM対応したので早速試してみた!」と題した、一般のユーザが引用システム1を利用・検証した内容を紹介するブログ記事を掲載するウェブサイト
URL: https://blog.cloudnative.co.jp/11154/
甲第3号証: Okta Japan株式会社の公式ウェブサイト上に掲載されている、プロダクトマーケティング担当ディレクターであるKevin Gough 氏が記述した「SCIMとは」と題した記事を掲載するウェブサイト
URL: https://www.okta.com/jp/blog/2017/01/what-is-scim/,
甲第4号証:特許第6629610号公報
なお、以下において、上記甲第1号証から甲第4号証を、単に「甲1」から「甲4」という場合がある。
令和7年5月29日付けで当審が通知した取消理由は、特許異議の申立てがされていない請求項4及び5について審理したものであった。請求項4及び5を除く取消理由については、令和7年9月4日付け取消理由において通知した取消理由(以下、「当審取消理由」という。)と同一であるから、下記2において述べる。
当審取消理由は、概略、以下のとおりである。
(進歩性)
本件特許の特許請求の範囲の請求項1,3,6,8-10に係る発明は、本件特許出願前に日本国内又は外国において頒布された引用文献1に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、請求項1,3,6,8-10に係る特許は、特許法第29条第2項の規定に違反してされたものである。
引用文献1:特開2013-250760号公報
本件訂正の請求の趣旨は、本件特許の特許請求の範囲を、本件訂正請求書に添付した訂正特許請求の範囲のとおり、訂正後の請求項1-10について訂正することを求める、というものである。
本件訂正の内容は、次のとおりのものである(下線部は訂正箇所を示す)。
(1)訂正事項1
特許請求の範囲における請求項1を、
「提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶する中継記憶部と、
前記認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部と、
前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、
前記送信情報を情報受取装置に送信する送信部と、
を有
し、
前記所定形式は、SCIMに準拠したJSON形式である、
情報中継装置。」に訂正する。
(請求項1の記載を引用する請求項3-8も同様に訂正する。)
(2)訂正事項2
特許請求の範囲の請求項2を削除する。
(3)訂正事項3
特許請求の範囲における請求項9を、
「ユーザ情報取得部により、提供元ユーザ情報を提供する情報提供装置にアクセスするための中継記憶部に記憶された認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させ、
送信情報生成部により、前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成し、
送信部により、前記送信情報を情報受取装置に送信
し、
前記所定形式は、SCIMに準拠したJSON形式である、
情報中継方法。」に訂正する。
(4)訂正事項4
特許請求の範囲における請求項10を、
「提供元ユーザ情報を提供する情報提供装置にアクセスするための中継記憶部に記憶された認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部のコードと、
前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部のコードと、
前記送信情報を情報受取装置に送信する送信部のコードと、
をコンピュータに実行させ
、
前記所定形式は、SCIMに準拠したJSON形式である
、
情報中継プログラム。」に訂正する。
本件訂正前の請求項2-8は、本件訂正前の請求項1を直接的に引用しているものであるから、訂正事項1によって記載が訂正される請求項1に連動して訂正されるものである。
したがって、本件訂正前の請求項1-8に対応する本件訂正後の請求項1-8は、特許法第120条の5第4項に規定する一群の請求項である。
(1)訂正の目的
訂正事項1は、本件訂正前の請求項1において、「所定形式」について、「SCIMに準拠したJSON形式である」ように限定したものである。
よって、訂正事項1は、特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」を目的とするものである。
同様に、訂正後の請求項の記載を引用する訂正後の各請求項についても、当該訂正事項1は、特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」を目的とするものである。
(2)願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であること
訂正事項1は、設定登録時の請求項2の「前記所定形式は、SCIMに準拠したJSON形式である」なる記載に基づくものであるから、願書に添付した明細書、特許請求の範囲又は図面(以下、これらをまとめて「本件明細書等」という。)に記載した事項の範囲内の訂正である。
よって、訂正事項1は、特許法第120条の5第9項で準用する第126条第5項に適合するものである。
(3)実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと
訂正事項1は、上記(1)(2)のとおり、本件明細書等に記載した事項の範囲内で特許請求の範囲を減縮するものであって、カテゴリーや対象、目的を変更するものではないので、実質上特許請求の範囲を拡張し、又は変更するものには該当しない。
よって、訂正事項1は、特許法第120条の5第9項で準用する第126条第6項に適合するものである。
(1)訂正の目的
訂正事項2は、請求項2を削除するというものであるから、特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」を目的とするものである。
(2)本件明細書等に記載した事項の範囲内の訂正であること
訂正事項2は、請求項2を削除するというものであるから、本件明細書等に記載した事項の範囲内の訂正であり、特許法第120条の5第9項で準用する第126条第5項に適合するものである。
(3)実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと
訂正事項2は、請求項2を削除するというものであるから、実質上特許請求の範囲を拡張し、又は変更するものには該当せず、特許法第120条の5第9項で準用する第126条第6項に適合するものである。
(1)訂正の目的
訂正事項3は、本件訂正前の請求項9の「所定形式」を、「SCIMに準拠したJSON形式である」ものと限定する訂正であるから、特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」を目的とするものである。
(2)本件明細書等に記載した事項の範囲内の訂正であること
訂正事項3は、設定登録時の請求項2の「前記所定形式は、SCIMに準拠したJSON形式である」なる記載に基づくものであるから、本件明細書等に記載した事項の範囲内の訂正である。
よって、訂正事項3は、特許法第120条の5第9項で準用する第126条第5項に適合するものである。
(3)実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと
訂正事項3は、上記(1)(2)のとおり、本件明細書等に記載した事項の範囲内で特許請求の範囲を減縮するものであって、カテゴリーや対象、目的を変更するものではないので、実質上特許請求の範囲を拡張し、又は変更するものには該当しない。
よって、訂正事項3は、特許法第120条の5第9項で準用する第126条第6項に適合するものである。
(1)訂正の目的
訂正事項4は、本件訂正前の請求項10の「所定形式」を、「SCIMに準拠したJSON形式である」ものと限定する訂正であるから、特許法第120条の5第2項ただし書第1号に規定する「特許請求の範囲の減縮」を目的とするものである。
(2)本件明細書等に記載した事項の範囲内の訂正であること
訂正事項4は、設定登録時の請求項2の「前記所定形式は、SCIMに準拠したJSON形式である」なる記載に基づくものであるから、本件明細書等に記載した事項の範囲内の訂正である。
よって、訂正事項4は、特許法第120条の5第9項で準用する第126条第5項に適合するものである。
(3)実質上特許請求の範囲を拡張し、又は変更する訂正ではないこと
訂正事項4は、上記(1)(2)のとおり、本件明細書等に記載した事項の範囲内で特許請求の範囲を減縮するものであって、カテゴリーや対象、目的を変更するものではないので、実質上特許請求の範囲を拡張し、又は変更するものには該当しない。
よって、訂正事項4は、特許法第120条の5第9項で準用する第126条第6項に適合するものである。
(1)上記第2で述べたように、本件特許異議の申立ては、本件訂正前の請求項1-3,6,8-10に係る特許に対して申し立てられたものであるから、これらに対応する本件訂正後の請求項1-3,6,8-10に係る発明には特許法第120条の5第9項で読み替えて準用する特許法第126条第7項の規定(いわゆる独立特許要件)は課されない。
(2)そして、本件訂正後の一群の請求項である請求項〔1-8〕のうち、請求項4,5,7については、本件特許異議の申立て対象となっていない本件訂正前の請求項4,5,7に対応する請求項であり、かつ、訂正事項1は特許法第120条の5第2項第1号に掲げる事項を目的とする訂正であるから、訂正事項1による請求項1の訂正に連動して訂正される請求項4,5,7については、独立特許要件が課されるため、以下検討する。
(3)訂正後の請求項4,5,7は訂正後の請求項1を直接引用する関係にあり、訂正後の請求項1に係る発明は、下記第8に説示するとおり、当業者が容易に発明をすることができたものであるとはいえない。そうすると、訂正後の請求項1に係る発明の構成をすべて含む訂正後の請求項4,5,7に係る発明も、請求後の請求項1に係る発明と同様に、当業者が容易に発明をすることができたものであるとはいえない。
そして、訂正後の請求項4,5,7の記載について不備は見当たらないし、他に請求項4,5,7に係る発明が特許出願の際独立して特許を受けることができないとする理由も見当たらない。
よって、訂正事項1は、特許法第120条の5第9項で読み替えて準用する特許法第126条第7項の規定に適合する。
以上のとおりであるから、本件訂正は適正であるので、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項〔1-8〕,9,10について訂正することを認める。
上記第5のとおり、本件訂正は認められるので、特許請求の範囲の請求項1-10に係る発明(以下、「本件特許発明1」-「本件特許発明10」という。)は、次の事項により特定されるものである。
提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶する中継記憶部と、
前記認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部と、
前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、
前記送信情報を情報受取装置に送信する送信部と、
を有し、
前記所定形式は、SCIMに準拠したJSON形式である、
情報中継装置。
(削除)
前記中継記憶部は、前記中継ユーザ情報を記憶し、
前記送信情報生成部は、前記中継記憶部に記憶された前記中継ユーザ情報に基づいて、前記送信情報を生成する、
請求項1に記載の情報中継装置。
前記ユーザ情報取得部が、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく前記中継ユーザ情報を取得すると、前記送信情報生成部が、前記中継ユーザ情報に基づいて、前記所定形式の前記送信情報を生成し、前記送信部が前記送信情報を前記情報受取装置に送信する、請求項1に記載の情報中継装置。
リクエスト受信部を有し、
前記リクエスト受信部は、前記情報受取装置から情報提供リクエストを受信し、
前記ユーザ情報取得部は、前記情報提供リクエストの受信に応じ、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく前記中継ユーザ情報を前記中継記憶部に記憶させ、
前記送信情報生成部は、前記中継ユーザ情報に基づいて、前記所定形式の前記送信情報を生成し、
前記送信部は、前記送信情報を前記情報受取装置に送信する、
請求項1に記載の情報中継装置。
前記認証情報は、HTTP認証に用いられる情報である、請求項1に記載の情報中継装置。
前記情報提供装置は、第1の情報提供装置と第2の情報提供装置を有し、
前記ユーザ情報取得部は、前記第1の情報提供装置から取得した第1の提供元ユーザ情報に基づく第1の中継ユーザ情報と、前記第2の情報提供装置から取得した第2の提供元ユーザ情報に基づく第2の中継ユーザ情報とを前記中継記憶部に記憶させ、
前記送信情報生成部は、前記第1の中継ユーザ情報に不足項目があるとき、前記第2の中継ユーザ情報から前記不足項目を取得し、前記送信情報を生成する、
請求項1に記載の情報中継装置。
前記中継ユーザ情報は、組織における人事に関する情報である、請求項1に記載の情報中継装置。
ユーザ情報取得部により、提供元ユーザ情報を提供する情報提供装置にアクセスするための中継記憶部に記憶された認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させ、
送信情報生成部により、前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成し、
送信部により、前記送信情報を情報受取装置に送信し、
前記所定形式は、SCIMに準拠したJSON形式である、
情報中継方法。
提供元ユーザ情報を提供する情報提供装置にアクセスするための中継記憶部に記憶された認証情報によって認証を受けて前記情報提供装置にアクセスし、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部のコードと、
前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部のコードと、
前記送信情報を情報受取装置に送信する送信部のコードと、
をコンピュータに実行させ、
前記所定形式は、SCIMに準拠したJSON形式である、
情報中継プログラム。
(1) 引用文献1記載事項
当審取消理由において引用した引用文献1には、次の事項が記載されている(なお、下線は、強調のため当審が付した。以降においても同様)。
「【0005】
本明細書では、第1のサービスを提供する第1のサービス提供サーバと、特定の通信装置と、の間のデータ通信を中継する中継サーバが開示される。
中継サーバは、登録部と中継部とを備える。
登録部は、特定の通信装置を利用する特定のユーザのための特定のアカウント情報と、特定のユーザのための第1のアカウント情報と、を含む第1の組合せ情報を、記憶部に登録する。第1のアカウント情報は、第1のサービス提供サーバに登録される。中継部は、第1の組合せ情報が記憶部に登録された後に、特定の通信装置から、特定のアカウント情報が受信される場合に、特定のアカウント情報を含む第1の組合せ情報に含まれる第1のアカウント情報を用いて、第1のサービス提供サーバと特定の通信装置との間の第1のデータ通信を中継する。第1のデータ通信は、特定の通信装置が、第1のサービス提供サーバから、第1のサービスの提供を受けるための通信である。」
「【0014】
(通信システムの構成)
図1に示されるように、通信システム2は、
中継サーバ
10と、複数個の
サービス提供サーバ
80,82と、複数個の
多機能機
90~94と、を備える。中継サーバ10と、複数個のサービス提供サーバ80,82と、複数個の多機能機90~94と、は、インターネット4に接続されている。」
「【図1】
47
71
0001434141000001.jpg
」
「【0015】
(中継サーバ10の構成)
中継サーバ10は、通信機器(例えば多機能機90)のベンダによって設置される。中継サーバ10は、サービス提供サーバ80,82と、通信機器(例えば多機能機90)と、の間のデータ通信を中継する。
中継サーバ10は、ネットワークインターフェイス20と制御部30とを備える。
ネットワークインターフェイス20は、インターネット4に接続されている。
制御部30は、CPU32とメモリ34とを備える。
CPU32は、メモリ34に格納されているプログラム36に従って、様々な処理を実行する。CPU32が上記のプログラムに従って処理を実行することによって、各部70~74の機能が実現される。」
「【0016】
メモリ34は、
RAM、ROM等のメモリを含む。なお、メモリ34は、HDD(Hard Disk Driveの略)を含んでいてもよい。プログラム36の他に、
アカウントテーブル40
と、デバイステーブル50と、利用テーブル60と、
を格納している。
アカウントテーブル40は、中継アカウント情報と、サービスIDと、サービスアカウント情報と、デバイスIDと、が対応付けられた情報を記憶するためのテーブルである。デバイステーブル50は、デバイスIDと、IPアドレスと、形式情報と、が対応付けられた情報を記憶するためのテーブルである。利用テーブル60は、デバイスIDとサービスIDとが対応付けられた情報を記憶するためのテーブルである。各テーブル40,50,60がどのようにして生成されるのかについては、後で詳しく説明する。」
「【0017】
(サービス提供サーバ80,82の構成)
各サービス提供サーバ80,82は、例えば、「Evernote(登録商標)」、「Google(登録商標) Docs」、「PICASA(登録商標)」、「FACEBOOK(登録商標)」等の公知のクラウドサーバである。各サービス提供サーバ80,82は、多機能機90等の様々な通信機器にサービスを提供可能である。各サービス提供サーバ80,82からサービスの提供を受けるためには、通信機器のユーザは、サービスアカウント情報を、サービス提供サーバ80,82に、事前に登録する必要がある。
サービスアカウント情報は、ユーザIDとパスワードとを含む。
」
「【0020】
(多機能機90,92,94の構成)
多機能機90は、インターネット4を介して、外部装置(例えば中継サーバ10)と通信可能に接続されている。
多機能機90は、表示機能と印刷機能とスキャン機能とを実行可能である。表示機能は、インターネット4を介して受信されるデータで表される画像を、表示部に表示する機能である。印刷機能は、インターネット4を介して受信されるデータで表される画像を、印刷媒体に印刷する機能である。スキャン機能は、スキャン実行部にセットされた原稿を読み取って、スキャンデータを生成する機能である。多機能機92,94は、多機能機90と同様の構成を有する。各多機能機90,92,94には、多機能機を識別するデバイスID(「MFP-A」、「MFP-B」及び「MFP-C」)が、予め付与されている。なお、デバイスIDは、多機能機90,92,94のMACアドレス等の多機能機に固有に付与されている情報である。」
「【0026】
登録部70は、
多機能機90からサービス登録指示を受信すると、S8において、サービス登録指示に含まれる中継アカウント情報と、
サービスアカウント情報
と、サービスIDと、多機能機90のデバイスIDと、を含む組合せ情報
を、アカウントテーブル40に登録する。
なお、サービス登録指示に含まれる中継アカウント情報が、アカウントテーブル40に既に登録されている場合、登録済みの中継アカウント情報に組み合わせて、サービス登録指示に含まれるサービスアカウント情報と、サービスIDと、多機能機90のデバイスIDと、をアカウントテーブル40に登録する。S8が終了すると、S10に進む。一方、サービス登録指示が受信されない場合、S8をスキップして、S10に進む。」
「【0030】
多機能機90は、サービスリストを受信すると、サービスリストに含まれる1個以上のサービスIDを、多機能機90の表示部に表示させる。多機能機90のユーザは、1個以上のサービスIDのうち、1個のサービスIDを選択することができる。
多機能機90は、ユーザによって選択されたサービスIDを、中継サーバ10に送信する。
」
「【0032】
S18では、中継部72は、S10で受信済みのデバイスIDと、対象サービスIDと、を対応付けて利用テーブル60に登録する。次いで、S20では、中継部72は、対象サービスIDのサービス提供サーバ(例えば
サービス提供サーバ80
)に、1個以上の対象組合せ情報のうちの対象サービスIDを含む1個の対象組合せ情報に含まれる
サービスアカウント情報を送信する。
さらに、対象サービスIDがNEWS-reportである場合、S20において、中継部72は、S10で受信済みのデバイスIDに対応付けて、デバイステーブル50に登録されている形式情報を、対象サービスIDのサービス提供サーバに送信する。」
「【0046】
(ニュース配信サービスの提供を受けるケース:図4)
次いで、
第1のユーザが、多機能機90を利用して、サービス提供サーバ80からニュース配信サービスの提供を受ける
際の各サーバ10,80及び多機能機90の処理を説明する。」
「【0051】
サービス提供サーバ80は、サービスアカウント情報を受信すると、認証処理を実行する。認証処理が認証成功である場合、サービス提供サーバ80は、多機能機90の形式情報を利用して、A4サイズのカラー画像を表すデータ形式のニュースを、中継サーバ10に送信する。
なお、サービス提供サーバ80は、サービス提供サーバ80に格納されているニュースのデータ形式が、形式情報に適合しないデータ形式である場合、データ形式を変換することによって生成されるニュースを、中継サーバ10に送信する。
中継サーバ10は、サービス提供サーバ80からニュースを受信する
と、利用テーブル60のサービスID「NEWS-report」に対応付けられているデバイスID「MFP-A」を特定する(図2のS26)。そして、中継サーバ10は、受信済みのニュースを、デバイスID「MFP-A」の多機能機90に送信する。多機能機90は、ニュースを受信すると、A4の印刷用紙に、受信済みのニュースで表される画像のカラー印刷を実行する。」
「【0080】
(3)本実施例では、中継部72は、形式情報を、対象サービスIDのサービス提供サーバに送信する。しかしながら、中継部72は、形式情報を、対象サービスIDのサービス提供サーバに送信しなくてもよい。この場合、中継部72は、サービス提供サーバから受信済みのデータが、形式情報によって示されるデータ形式を有するのか否かを判断してもよい。そして、中継部72は、受信済みのデータが、形式情報によって示されるデータ形式を有する場合、受信済みのデータを、通信機器(例えば多機能機90)に送信してもよい。一方、中継部72は、受信済みのデータが、形式情報によって示されるデータ形式を有しない場合、
受信済みのデータのデータ形式を、形式情報によって示されるデータ形式に変換してもよい。中継部72は、変換済みのデータを、通信機器(例えば多機能機90)に送信してもよい。
本変形例では、中継部72は、「形式情報を用いて、特定のデータ形式を有する特定のデータを特定の通信装置に送信する」構成を有する。」
(2) 引用発明
前記(1)より、引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。
「中継サーバは、登録部と中継部とを備え、
登録部は、サービスアカウント情報を、アカウントテーブルに登録し、
中継サーバは、メモリを備え、
メモリは、アカウントテーブルを格納し、
サービスアカウント情報は、ユーザIDとパスワードとを含み、
中継部は、サービス提供サーバに、サービスアカウント情報を送信し、
サービス提供サーバは、サービスアカウント情報を受信すると、認証処理を実行し、認証処理が認証成功である場合、ニュースを、中継サーバに送信し、中継サーバは、サービス提供サーバからニュースを受信し、中継部は、受信済みのデータのデータ形式を、形式情報によって示されるデータ形式に変換し、変換済みのデータを、多機能機に送信し、
ユーザが、多機能機を利用して、サービス提供サーバからニュース配信サービスの提供を受け、
多機能機は、インターネットを介して、中継サーバと通信可能に接続されている、
中継サーバ。」
(1)甲第1号証の記載事項
甲第1号証には、「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」に関して、次の事項が記載されている。
(第2ページ)
「■連携によって実現すること
この度のSCIM連携により、
「SmartHR」の導入企業は「SmartHR」に登録している人事情報に基づいて、Oktaのアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーションのアクセス権の作成、更新、停止などのアカウント管理を自動化できます。
具体的には、従業員の人事情報に基づいて、業務で使用するアプリケーションのアクセス権を自動的に割り当てたり、従業員が退職した情報をもとにアクセス権を自動で停止することが可能です。手作業によるアカウント管理が不要となり、システム管理者の負荷を大幅に減らすほか、アクセス権の更新漏れによる情報漏洩のセキュリティリスクも低減します。」
<人事情報に基づくアカウント管理自動化のイメージ>
34
89
0001434141000002.jpg
(第3,4ページ)
「■Oktaについて
Oktaは、すべての人のアイデンティティとアクセスを安全に管理するベンダーニュートラルなサービスプロバイダーです。Oktaが提供するプラットフォーム「Okta Identity Cloud」により、クラウド、オンプレミスを問わず、適切な人に適切なテクノロジーを適切なタイミングで安全に利用できるようにします。7,300以上のアプリケーションとの事前統合が完了している「Okta Integration Network」を活用して、あらゆる人や組織にシンプルかつ安全なアクセスを提供し、お客様の潜在能力を最大限発揮できるように支援します。JetBlue、Nordstrom、Siemens、Slack、T-Mobile、武田薬品、Teach for America、Twilioを含む4,000以上のお客様がOktaを活用して、職場や顧客のアイデンティティを保護しています。」
(第4ページ)
「■クラウド人事労務ソフト「SmartHR 」について
SmartHRは、労務管理クラウド4年連続シェアNo.1(※2)のクラウド人事労務ソフトです。雇用契約や入社手続き、年末調整などの多様な労務手続きをペーパーレス化し、データとして蓄積。また、勤怠管理システムや給与計算システム等との連携により、様々なデータの一元管理も可能に。さらに、SmartHRに溜まった従業員データを活用した「人事評価」「従業員サーベイ」などの人材マネジメント機能により、組織の活性化や組織変革を推進。すべての人が働きやすい環境づくりに貢献します。
SmartHRは、煩雑で時間のかかる人事・労務業務から経営者、人事・労務担当者、従業員を解放し、企業の生産性向上を後押しします。」
(2)甲第2号証の記載事項
甲第2号証には、「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」に関して、次の事項が記載されている。
(第1ページ)
「SmartHRがOktaとのSSO/SCIMによるプロビジョニングに対応したとの話題を見つけて早速検証してみました。」
(甲第1号証へのリンク)
(第2ページ)
「大きな特徴はSmartHRをリソースとしてOkta側に反映できることですよね。通常であればOktaからSaasに対して反映させるため逆の流れとなります。」
(第4-9ページ)
「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をクリックします。」
(3)甲第3号証の記載事項
甲第3号証には、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」に関して、次の事項が記載されている。
(第1ページ)
「SCIM (Systemf or Cross-domainI dentity Management:クロスドメインアイデンテイティ管理システム)は、ユーザープロビジョニングの自動化を可能にするオープン標準規格です。将来、テクノロジーがクラウドベースになることが明白になったことを受けて2011年に策定されました。SCIMは、アイデンテイテイプロバイダー(多数のユーザーを持つ企業など)とユーザーアイデンテイティ情報を要求するサービスプロバイダー(エンタープライズSaasアプリケーションなど)との間でユーザーアイデンテイテイデータをやり取りします」
(第2ページ)
「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日間無料でお試しいただき、実際にユーザーアイデンテイティ管理がどう簡素化されるかをお確かめください。」
(4)甲1から甲3より把握される事項
甲1はSmartHRとOktaとの連携について記載されている、株式会社SmartHRの公式ウェブサイト上で公開されたプレスリリース記事であり、冒頭に記事の日付として「2022/03/02」と記載されている。
甲2は、SmartHRのアカウント情報をOktaに反映する際の実際の操作について言及している、一般ユーザによるブログ記事であり、記事中で甲1をリンクしており、冒頭に記事の日付として「2022.03.08」と記載されている。
甲3はOkta Japan株式会社の公式ウェブサイト上に掲載されている、Oktaについて言及されている記事であり、冒頭に記事の日付として「January 4, 2017」と記載されている。
加えて、甲1及び甲2はいずれも「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」について開示するものと認められ、甲3はアイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」について開示するものと認められる。
以上の点に鑑みれば、甲1から甲3に係る「クラウド人事労務ソフトである「SmartHR」と、アイデンテイティ管理・認証基盤プラットフォームを提供する「Okta」とを連携したシステム」は、本件特許出願前に公然知られる状況又は公然知られるおそれのある状況で実施された発明であるものと認められる。
ア 甲1に記載の事項によれば、クラウド人事労務ソフトである「SmartHR」の導入企業は、「SmartHR」に登録している人事情報に基づいて、Oktaの提供するアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーションのアカウント管理を自動化できる。
また、甲1の図面より、甲1には、SmartHRが、人事情報を管理するものであり、SmartHRからOktaに対し、「入社」、「従業員情報の更新」又は「退職」の情報が通知されると、Oktaは、「ユーザー発行」、「ユーザ情報更新」又は「ユーザー停止」の処理を行うとともに、対応APPに対し、「アカウント発行」、「アカウント更新」及び「アカウント停止」の通知を行うことが開示されているといえる。
イ 甲2に記載の事項によれば、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をクリックする操作を行う。
ウ 甲3の記載によれば、SCIMはRESTおよびJSONベースのプロトコルであり、 Oktaには、SCIMベースのものを含む、80以上の主要アプリとの統合のプロビジョニングが統合されており、 Oktaのようなアイデンテイテイプロバイダー(ldP) で作成、更新、削除といったアイデンテイティヘの変更が行われると、これらの変更はSCIMプロトコルに従って自動的にサービスプロバイダー(SP) に同期される。
(5)甲1公然実施発明
上記(4)より、以下の発明(以下、「甲1公然実施発明」という。)が本願出願時において公然に実施されたものと認められる。
「クラウド人事労務ソフトである「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以上の主要アプリとの統合のプロビジョニングが統合されている、
システム。」
(1)甲第4号証の記載事項
甲第4号証には、次の事項が記載されている。
「【0016】
[システムの構成]
図1は、本実施形態に係るアカウント情報連携システムの構成を示した図である。
【0017】
同図に示すように、
このシステムは、
1つの企業内の例えばイントラネット内に設けられたシステムであり、ア
カウント情報連携サーバ100と、人事部システム200と、その他の複数の社内システム10(10A,10B,10C)を有する。
【0018】
アカウント情報連携サーバ100は、人事部システム200及び複数の社内システム10と通信可能である。アカウント情報連携サーバ100は、人事部システム200から送信される、従業員の人事に関するイベント情報を基に、当該イベントに伴って発生する各社員のアカウント情報の変更を、複数の社内システム10において同期させることができる。」
(図1)
46
81
0001434141000003.jpg
「【0041】
[アカウント情報連携サーバの機能ブロック構成]
次に、上記アカウント情報連携サーバ100が有する機能ブロックについて説明する。
【0042】
(人事イベント(発令情報)に伴う連携処理)
図4は、上記アカウント情報連携サーバ100による、人事イベント(発令情報)に伴うアカウント情報の連携処理に必要な機能ブロックを示した図である。
【0043】
同図に示すように、
アカウント情報連携サーバ100は、
人事イベントに伴うアカウント情報の連携処理のために、
発令情報取込部41及び複数のシステム連携制御部42
(Aシステム連携制御部42A,Bシステム連携制御42B,Cシステム連携制御42C等)
を有する。
【0044】
人事部の担当者から人事部システム200を介して発令情報Pがアカウント情報連携サーバ100へ送信されると、上記発令情報取込部41が当該発令情報を受信し、当該発令情報を基にToDoリスト34が生成される。
【0045】
このToDoリスト34の生成には、上記発令情報の送信に伴って社内の情報システム部の担当者から社員管理画面を介して入力された社員IDや、総務部の担当者からカード管理画面及び入室権限管理画面を介して入力された社員カード番号等も使用される。
【0046】
生成されたToDoリスト34は、上記記憶部18に記憶され、
各システム連携制御部42は、定期的に(1日に数回等の頻度で)当該ToDoリストを参照する。」
「【0051】
そして、上記各
システム連携制御部42は、
ToDoリスト34を参照した日が、当該ToDoリスト34に含まれる実行予定日である場合に、上記人事イベントに対応する
アカウント情報の同期要求を、
上記対応する
社内システム10へ
(すなわち、例えばAシステム連携制御部42AはAシステム10Aへ、Bシステム連携制御部42BはBシステム10Bへ)それぞれ
送信する。
」
(図4)
50
81
0001434141000004.jpg
(2)甲4から把握される発明
上記(1)から、甲4には次の発明(以下、「甲4発明」と呼ぶ)が記載されている。
「人事部の担当者から人事部システム200を介して発令情報Pがアカウント情報連携サーバ100へ送信されると、発令情報Pを送信する人事部システム200から発令情報を受信し、当該発令情報を基にToDoリスト34を生成する発令情報取込部41と、
ToDoリスト34を記憶する記憶部18と、
ToDoリスト34を参照して、社内システム10にアカウント情報の同期要求を送信するシステム連携制御部42と、
を有するアカウント情報連携サーバ100。」
当審取消理由(進歩性)について以下検討する。
(1) 対比
本件特許発明1と引用発明とを対比する。
ア 引用発明の「ユーザIDとパスワードとを含」む「サービスアカウント情報」は、これを受信した「サービス提供サーバ」が「認証処理を実行」するための情報であるから、本件特許発明1の「提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報」と、「認証情報」である点で共通する。そして、引用発明において「中継サーバ」が備える「登録部」が「サービスアカウント情報を、アカウントテーブルに登録」することは、本件特許発明1の「認証情報を記憶」することに相当し、「アカウントテーブルを格納」する「メモリ」は、本願発明1の「中継記憶部」に相当する。
イ 引用発明において「中継サーバ」が備える「中継部」が「サービス提供サーバに、サービスアカウント情報を送信」し、「サービス提供サーバ」が「サービスアカウント情報を受信すると、認証処理を実行し、認証処理が認証成功である」とすることは、上記アを踏まえると、本件特許発明1の「前記認証情報によって認証を受け」ることに相当する。
ウ 引用発明は「ユーザが、多機能機を利用して、サービス提供サーバからニュース配信サービスの提供を受ける」ものであるところ、「サービス提供サーバ」が「中継サーバに送信」する「ニュース」は、「情報」と言い得るものであり、「提供」元である「サービス提供サーバ」から「ユーザ」に「提供」されるものであるから、「提供元ユーザ情報」と言い得るものである。また、引用発明の「サービス提供サーバ」は「ニュース」を「提供」する「装置」、すなわち、「情報提供装置」と言い得るものである。したがって、引用発明において「中継サーバ」が「サービス提供サーバからニュースを受信」することは、本件特許発明1の「前記情報提供装置から前記提供元ユーザ情報を取得」することに相当する。
エ 引用発明は「中継サーバ」が備える「中継部」が「受信済みのデータのデータ形式を、形式情報によって示されるデータ形式に変換し、変換済みのデータを、多機能機に送信」するものであるところ、「受信済みのデータ」は「サービス提供サーバ」から「中継サーバに送信」された「ニュース」であると認められ、上記ウのとおり、「提供元ユーザ情報」と言い得るものである。また、「形式情報によって示されるデータ形式に変換」された「変換済みのデータ」は、「中継」する機能を有する「中継部」によって「ユーザ」に「利用」される「多機能機に送信」される情報であるから、「中継ユーザ情報」と言い得るものである。さらに、「中継ユーザ情報」は「提供元ユーザ情報」の「データ形式を、形式情報によって示されるデータ形式に変換」したものであるから、「提供元ユーザ情報に基づく」ものといえる。
オ 引用発明の「変換済みのデータ」は「受信済みのデータ」を「変換」する処理の結果であるといえるところ、装置においてデータを処理した結果をメモリ等に記憶することは、本件特許出願時における技術常識であるから、引用発明において「受信済みのデータのデータ形式を、形式情報によって示されるデータ形式に変換」する処理は、「変換済みのデータ」を「メモリ」に「記憶させる」処理を含むものと認められる。
カ 引用発明は「変換済みのデータを、多機能機に送信」するものであり、「多機能機は、インターネットを介して、中継サーバと通信可能に接続されている」ものであるところ、「変換済みのデータ」は「インターネットを介して」「多機能機に送信」されるものと認められる。ここで、ネットワークを介してデータを通信相手に送信する際、データからネットワークや通信プロトコル等に応じた所定形式を有する送信情報を生成して、当該送信情報をネットワークに送信することは、本件特許出願時における技術常識であるから、引用発明の「変換済みのデータを、多機能機に送信」する処理は、「変換済みのデータ」に基づいて、「所定形式を有する送信情報を生成する」処理を含むものと認められる。また、引用発明において「変換済みのデータ」を「送信」された「多機能機」は、「変換済みのデータ」を受け取る「装置」、すなわち、「情報受取装置」と言い得るものである。
以上のことから、引用発明において「変換済みのデータを、多機能機に送信」することは、本件特許発明1の「前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する」こと、及び「前記送信情報を情報受取装置に送信する」ことに相当する。
キ 上記イからカを踏まえると、引用発明の「中継部」を備える「中継サーバ」は、本件特許発明1の「前記認証情報によって認証を受け」て、「前記情報提供装置から前記提供元ユーザ情報を取得」し、「前記提供元ユーザ情報に基づく中継ユーザ情報」を「記憶させる」「ユーザ情報取得部」、「前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する」「送信情報生成部」、及び「前記送信情報を情報受取装置に送信する」「送信部」に相当する機能を備えているといえる。
ク 上記アからキを踏まえると、引用発明の「登録部と中継部とを備え」る「中継サーバ」は、後述する相違点を除いて、本件特許発明1の「情報中継装置」に相当する。
(2) 一致点・相違点
以上から、本件特許発明1と引用発明とは、以下の点において一致ないし相違する。
ア 一致点
「認証情報を記憶する中継記憶部と、
前記認証情報によって認証を受けて、前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部と、
前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、
前記送信情報を情報受取装置に送信する送信部と、
を有する情報中継装置。」
イ 相違点
(ア)相違点1
本件特許発明1の「認証情報」は「
情報提供装置にアクセス
するための」ものであり、「情報中継装置」は「提供元ユーザ情報を取得」するために「
情報提供装置にアクセス
」するのに対し、引用発明における「ユーザIDとパスワードとを含」む「サービスアカウント情報」は、「ユーザが、多機能機を利用して、サービス提供サーバからニュース配信サービスの提供を受け」るためのものといえるものの、「サービス提供サーバ」にアクセスするためのものとはいえない点。
(イ)相違点2
本件特許発明1の「所定形式」は、「
SCIMに準拠したJSON形式
」であるのに対し、引用発明における「変換済みのデータ」は「インターネットを介して」「多機能機に送信」されるものであって、データからネットワークや通信プロトコル等に応じた「所定形式」を有するとはいえるものの、「SCIMに準拠したJSON形式」ではない点。
(3)相違点についての判断
事案に鑑みて、先に相違点2について検討する。
ここで、相違点2における「SCIM」が、System for Cross-domain Identity Management の略であり、サービスやシステム間でユーザのID情報をやり取りするための標準仕様であることは、本件特許出願時における技術常識である。一方、上記第7のとおり、引用文献1に記載された発明は、多機能機等の通信機器に対して、ニュース配信等のサービスを提供するものであり、多機能機等の通信機器との間でユーザのID情報をやり取りすることは記載も示唆もされておらず、かつ、そのような態様が本件特許出願時における周知技術であったともいえないから、引用文献1に記載された発明において、所定形式を「SCIMに準拠したJSON形式」とする動機付けがあるとはいえない。
(4)まとめ
よって、相違点1について検討するまでもなく、本件特許発明1は、当業者が、引用文献1に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。
本件特許発明3,6,8は、本件特許発明1の構成をすべて含む発明であるから、本件特許発明1と同様に、当業者が、引用文献1に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。
本件特許発明9は、本件特許発明1を方法の発明として特定したものと認められる。
よって、本件特許発明1と同様に、当業者が、引用文献1に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。
本件特許発明10は、本件特許発明1をプログラムの発明として特定したものと認められる。
よって、本件特許発明1と同様に、当業者が、引用文献1に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。
上記1から4のとおり、令和7年5月29日付けで通知した取消理由の対象となる請求項1,3,6,8-10に対応する本件特許発明1,3,6,8-10は引用発明に対して進歩性を有する。
したがって、当該取消理由は、解消した。
上記1から4のとおり、令和7年9月4日付けで通知した取消理由の対象となる請求項1,3,6,8-10に対応する本件特許発明1,3,6,8-10は引用発明に対して進歩性を有する。
したがって、当該取消理由は、解消した。
(1)本件特許発明1について
ア 対比
以下、本件特許発明1と甲1公然実施発明とを対比する。
(ア) 甲1公然実施発明における「クラウド人事労務ソフトである「SmartHR」」は、直接的には、「Okta」に対し、「「入社」、「従業員情報の更新」又は「退職」の情報」(本件特許発明1の「提供元ユーザ情報」に相当する。)を通知(提供)し、また、間接的には、「対応APP」に対し、「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」を通知(提供)するものであるところ、“情報提供手段”として機能しているといえ、甲1公然実施発明における「SmartHR」と、本件特許発明1の「情報提供
装置
」とは、「情報提供
手段
」である点において共通する。
甲1公然実施発明における「AuthToken」は、“Authentication Token”のことと解されるところ、“認証情報”といい得るものである。そして、当該「AuthToken」は、「OktaのSmartHRアプリケーションのProvisioning設定のAPITokenに反映」し、「Save」すなわち、記憶されるものであるところ、「Okta」は、「AuthToken」を記憶する“記憶部”として機能するものと認められる。
しかしながら、甲1公然実施発明における「AuthToken」は、何に使用される認証情報であるのかが具体的に特定されておらず、また、甲1公然実施発明においては、そもそも、「Okta」が「SmartHR」に“アクセス”することは開示されていない。
よって、甲1公然実施発明の「Okta」が備える“記憶部”と、本件特許発明1の「
提供元ユーザ情報を提供する情報提供装置にアクセスするための
認証情報を記憶する中継記憶部」とは、「認証情報を記憶する記憶部」である点において共通する。
(イ) 甲1公然実施発明において、「Okta」は、「SmartHR」から、「「入社」、「従業員情報の更新」又は「退職」の情報」を取得する“ユーザ情報取得部”として機能しているといえる。
また、甲1公然実施発明において、「Okta」は、通知(提供)された情報に基づいて「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」を生成しこれを「対応APP」に通知(送信)するものと解されるところ、当該「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」は、本件特許発明1の「前記提供元ユーザ情報に基づく中継ユーザ情報」に相当する。また、甲1公然実施発明において、「Okta」は、「対応APP」に通知(送信)する情報を一時的に記憶していると認められるものの、
当該記憶する場所が、「AuthToken」が記憶される“記憶部”と同じであるかどうかまでは特定されていない。
よって、上記(ア)を参酌すれば、甲1公然実施発明の「Okta」が備える“ユーザ情報取得部”と、本件特許発明1の「
前記認証情報によって認証を受けて前記情報提供装置にアクセスし、
前記情報提供
装置
から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を
前記中継記憶部に
記憶させるユーザ情報取得部」とは、「情報提供
手段
から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を記憶させるユーザ情報取得部」である点において共通する。
(ウ) アプリケーション等の間で通信するデータを、当該アプリケーション等の間通信において採用されている所定の形式に変換して通信がなされることは本願出願時における技術常識であるところ、甲1公然実施発明において、「Okta」は、通知(送信)すべき情報を所定の形式に変換する“送信情報生成部”及び、変換した情報を「対応APP」に送信する、“送信部”として機能していると認められる。
また、甲1公然実施発明において、「対応APP」は、「Okta」から通知(送信)された情報を受け取る“情報受取手段”として機能しているといえ、当該“情報受取手段”と、本件特許発明1における「情報受取
装置
」とは、「情報受取
手段
」である点において共通する。
よって、甲1公然実施発明の「Okta」が備える“送信情報生成部”は、本件特許発明1における「前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部」に相当し、甲1公然実施発明の「Okta」が備える“送信部”と、本件特許発明1における「前記送信情報を情報受取
装置
に送信する送信部」とは、「前記送信情報を情報受取
手段
に送信する送信部」である点において共通する。
(エ) 甲1公然実施発明において、「SCIMはRESTおよびJSONベースのプロトコルであり、Oktaには、SCIMベースのものを含む、80以上の主要アプリとの統合のプロビジョニングが統合されている」との事項によれば、甲1公然実施発明におけるシステムは、SCIMに準拠したJSON形式を採用したものであることは明らかである。よって、甲1公然実施発明における前記事項と、本件特許発明1における「
前記所定形式は、
SCIMに準拠したJSON形式
である
」こととは、「SCIMに準拠したJSON形式
を採用している
」ことである点において共通する。
(オ) 甲1公然実施発明の「アイデンティティ管理・認証基盤プラットフォームを提供する「Okta」」は、情報を中継する“情報中継手段”として機能しているといえる。よって、甲1公然実施発明の「Okta」と、本件特許発明1における「情報中継
装置
」とは、「情報中継
手段
」である点において共通する。
イ 一致点、相違点
以上によれば、本件特許発明1と甲1公然実施発明とは、以下の点において一致ないし相違する。
(ア)一致点
「認証情報を記憶する記憶部と、
情報提供手段から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を記憶させるユーザ情報取得部と、
前記中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、
前記送信情報を情報受取手段に送信する送信部と、
を有し、
SCIMに準拠したJSON形式を採用している、
情報中継手段。」
(イ)相違点
a 相違点1-1
本件特許発明1は、
「提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報」を記憶する
と共に、「
前記認証情報によって認証を受けて前記情報提供装置にアクセス
」することにより、提供元ユーザ情報を取得するのに対し、甲1公然実施発明において、「Okta」が記憶する「AuthToken」が、「SmartHR」にアクセスするためのものであって、「AuthToken」によって認証を受けて「SmartHR」にアクセスし、「SmartHR」から「「入社」、「従業員情報の更新」又は「退職」の情報」を取得することを具体的に特定していない点。
b 相違点1-2
共通する「情報提供
手段
」が、本件特許発明1においては、「情報提供
装置
」であるのに対し、甲1公然実施発明においては、「クラウド人事労務ソフトである「SmartHR」」であり、共通する「情報受取
手段
」が、本件特許発明1においては、「情報受取
装置
」であるのに対し、甲1公然実施発明においては「対応APP」であり、また、共通する「情報中継
手段
」が、本件特許発明1においては、「情報中継
装置
」であるのに対し、甲1公然実施発明においては「アイデンティティ管理・認証基盤プラットフォームを提供する「Okta」」である点。
すなわち、本件特許発明1は、複数の「
装置
」が連携してなるシステムを前提としているのに対し、甲1公然実施発明は、全体としてみれば、プラットフォームとソフトウェアが連携したシステムである点。
c 相違点1-3
共通する「記憶部」が、本件特許発明1においては、「認証情報」のみならず、
「中継ユーザ情報」をも記憶する「中継記憶部」
であるのに対し、甲1公然実施発明において、「AuthToken」が記憶される“記憶部”に、「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」が記憶されることを具体的に特定していない点。
d 相違点1-4
本件特許発明1においては、「
前記所定形式は、
SCIMに準拠したJSON形式
である
」との構成を有するのに対し、甲1公然実施発明においては、「SCIMはRESTおよびJSONベースのプロトコルであり、Oktaには、SCIMベースのものを含む、80以上の主要アプリとの統合のプロビジョニングが統合されている」との事項を含むものの、「「アカウント発行」、「アカウント更新」及び「アカウント停止」の情報」を「SCIMに準拠したJSON形式」で送信することを具体的に特定していない点。
ウ 相違点についての判断
まず、上記相違点1-1~1-4はいずれも、形式的なものではないから、本件特許発明1は、甲1公然実施発明と同一であるとはいえない。
また、相違点1-1について検討するに、「「SmartHR」の導入企業は「SmartHR」に登録している人事情報に基づいて、Oktaのアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーションのアクセス権の作成、更新、停止などのアカウント管理を自動化でき」との構成によれば、甲1公然実施発明における「AuthToken」は、「Oktaのアイデンティティ管理・認証基盤プラットフォーム「Okta Identity Cloud」で管理しているアプリケーション」に対する「アクセス権」を認証するものであるとも解されるところ、甲1公然実施発明の構成から直ちに、当業者が、「AuthToken」が「SmartHR」にアクセスするためのものであって、「AuthToken」によって認証を受けて「SmartHR」にアクセスし、「SmartHR」から「「入社」、「従業員情報の更新」又は「退職」の情報」を取得するとの構成を想到することが容易であるとはいえない。
また、当該相違点1-1に係る本件特許発明1の構成は、甲4にも記載がなく、また、本願出願時における技術常識であったとも認められない。
また、事案に鑑みて、次に相違点1-3について検討するに、当該相違点1-3に係る本件特許発明1の構成は、当業者といえども、甲1公然実施発明の構成から容易に想到し得るものではなく、また、アクセスを認証するための認証情報とユーザ提供元情報に基づく情報とを同じ記憶部に記憶することは、甲4にも記載がなく、また、本願出願時における技術常識とも認められない。
以上のことから、相違点1-2及び1-4について検討するまでもなく、本件特許発明1は、当業者が甲1公然実施発明に基づいて容易に発明をすることができたものとはいえない。
エ まとめ
以上のとおりであるから、本件特許発明1は、当業者が、甲第1号証から甲第3号証より把握される甲1公然実施発明ではなく、甲1公然実施発明に基づいて、容易に発明をすることができたものともいえない。
(2)本件特許発明3,6,8について
本件特許発明3,6,8は、本件特許発明1の構成をすべて含む発明であるから、本件特許発明1と同様に、当業者が、甲第1号証から甲第3号証より把握される甲1公然実施発明ではなく、甲1公然実施発明に基づいて、容易に発明をすることができたものともいえない。
(3)本件特許発明9について
本件特許発明9は、本件特許発明1を方法の発明として特定したものと認められる。
よって本件特許発明1と同様に、当業者が、甲第1号証から甲第3号証より把握される甲1公然実施発明ではなく、甲1公然実施発明に基づいて、容易に発明をすることができたものともいえない。
(4)本件特許発明10について
本件特許発明10は、本件特許発明1をプログラムの発明として特定したものと認められる。
よって本件特許発明1と同様に、当業者が、甲第1号証から甲第3号証より把握される甲1公然実施発明ではなく、甲1公然実施発明に基づいて、容易に発明をすることができたものともいえない。
(1)本件特許発明1について
ア 対比
以下、本件特許発明1と甲4発明とを対比する。
(ア)甲4発明の「発令情報P」はユーザの情報を含む情報であるから、本件特許発明1の「提供元ユーザ情報」に相当する。
甲4発明の「人事部システム200」は「発令情報P」を「アカウント情報連携サーバ100」に提供する装置であるから、本件特許発明1の「提供元ユーザ情報を提供する情報提供装置」に相当する。
しかしながら、甲4発明の「アカウント情報連携サーバ100」は下記(イ)でも述べる「記憶部18」を有するものの、甲4にはアクセスするための「認証情報」を記憶することは記載されていない。加えて甲4には「アカウント情報連携サーバ100」が「人事部システム200」にアクセスすることも記載されていない。
よって、甲4発明の「記憶部18」と、「
提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶する
中継記憶部」とは、「記憶部」である点において共通する。
(イ)上記(ア)で述べたとおり、甲4発明の「アカウント情報連携サーバ100」は「認証情報によって認証を受けて情報提供装置にアクセス」するものではないが、「人事部システム200」から「発令情報P」を受信するものであるから、本件特許発明1の「ユーザ情報取得部」と、「提供元ユーザ情報を取得」する点で共通する。
甲4発明の「ToDoリスト34」は、「発令情報P」を基に生成されるものであるから、本件特許発明1の「提供元ユーザ情報に基づく中継ユーザ情報」に相当する。
甲4発明の「記憶部18」は、生成された「ToDoリスト34」を記憶しているから、「中継ユーザ情報」を「記憶する」点で本件特許発明1の「中継記憶部」と共通している。
そして、甲4発明の「発令情報取込部41」は、受信した「発令情報P」に基づいて「ToDoリスト34」を生成して「記憶部18」に記憶させているから、本件特許発明1の「
前記認証情報によって認証を受けて前記情報提供装置にアクセスし、
前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部」とは、「前記情報提供装置から前記提供元ユーザ情報を取得し、前記提供元ユーザ情報に基づく中継ユーザ情報を前記中継記憶部に記憶させるユーザ情報取得部」点である点において共通する。
(ウ)甲4発明の「社内システム10」は、「アカウント連携サーバ100」からアカウント情報の同期要求が送信されるものであるから、本件特許発明1の「情報受取装置」と、「情報中継装置」から情報が送信される点で共通する。
甲4発明の「システム連携制御部42」は、「アカウント情報連携サーバ100」が記憶する「ToDoリスト34」を参照して、「社内システム10」に「アカウント情報の同期要求」を送信するものである。ここで、甲4には「アカウント情報の同期要求」を、「社内システム10」に送信すると、「社内システム10」のアカウント情報が同期されることが記載されているから、「中継ユーザ情報」を基にした、何らかの所定形式を有する情報が送信されているものと認められる。
よって、甲4発明の「システム連携制御部42」は、「中継ユーザ情報に基づいて」、「所定形式を有する情報を生成」する点で本件特許発明1の「送信情報生成部」と共通し、生成した情報を「情報受取装置に送信」する点で、本件特許発明1の「送信部」と共通する。
イ 一致点、相違点
以上から、本件特許発明1と甲4発明とは、以下の点において一致又は相違する。
(ア)一致点
「記憶部と、
情報提供装置から提供元ユーザ情報を取得し、提供元ユーザ情報に基づく中継ユーザ情報を記憶部に記憶させるユーザ情報取得部と、
中継ユーザ情報に基づいて、所定形式を有する送信情報を生成する送信情報生成部と、
送信情報を情報受取装置に送信する送信部と、
を有する情報中継装置。」
(イ)相違点
a 相違点2-1
本件特許発明1の中継記憶部は
提供元ユーザ情報を提供する情報提供装置にアクセスするための認証情報を記憶している
が、甲4発明の記憶部18はそのような情報を有していない点。
b 相違点2-2
本件特許発明1のユーザ情報取得部は
認証情報によって認証を受けて情報提供装置にアクセスし、
情報提供装置から提供元ユーザ情報を取得しているのに対し、甲4発明の発令情報取込部(アカウント連携サーバ100)は人事部システム200から発令情報Pを受信するにあたり、認証情報によって認証を受けて人事部システム200にアクセスすることを具体的に特定していない点。
c 相違点2-3
本件特許発明1の「送信情報」はSCIMに準拠したJSON形式であるのに対し、甲4発明の「アカウント情報の同期要求」とはどのような形式であるのか不明である点。
ウ 相違点についての判断
事案に鑑みて、先に相違点2-2について検討する。
甲4にはアカウント連携サーバ100が認証情報によって認証を受けて人事部システム200にアクセスすること、アカウント連携サーバ100が人事部システム200に情報を取得するためにアクセスすること、について記載も示唆もなく、そのことが、本願出願時における技術常識であったともいえない。加えて、甲4発明は、人事部の担当者から人事部システム200を介して発令情報Pがアカウント情報連携サーバ100へ送信されることを契機として、人事部システム200から一方的に発令情報Pが送信されることを前提としていることに鑑みれば、当業者といえども、アカウント連携サーバ100が能動的に人事部システム200にアクセスして情報を取得するように構成を変更することを容易に想到することができたとはいえない。
なお、上記と同様の理由により、相違点2-1についても、甲4発明において記憶部に人事部システム200にアクセスするための認証情報を記憶するよう構成することは、当業者が容易に想到し得たものではない。
エ まとめ
以上のとおりであるから、他の相違点について検討するまでもなく、本件特許発明1は、当業者が、甲第4号証に記載された発明に基づいて、容易に発明をすることができたものではない。
(2)本件特許発明3,6,8について
本件特許発明3,6,8は、本件特許発明1の構成をすべて含む発明であるから、本件特許発明1と同様に、当業者が、甲第4号証に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。
(3)本件特許発明9について
本件特許発明9は、本件特許発明1を方法の発明として特定したものと認められる。
よって、本件特許発明1と同様に、当業者が、甲第4号証に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。
(4)本件特許発明10について
本件特許発明10は、本件特許発明1をプログラムの発明として特定したものと認められる。
よって、本件特許発明1と同様に、当業者が、甲第4号証に記載された発明及び周知技術に基づいて、容易に発明をすることができたものではない。
(1) 申立人の主張
申立人は、申立理由1又は2について、次のように述べている。
ア 主張1(特許異議申立書第18ページ)
「(I-1-6) 小括
以上より、引用発明1は、本件特許発明1の構成要件1A~1Eを全て充足するから、本件特許発明1は、引用発明1に基づいて新規性を有さない。
また、上記のとおり、本件特許発明1と引用発明1との間には差異が認められないが、仮に何らかの差異が認められるとしても、本件特許発明1は、引用発明1に基づいて当業者が容易に想到し得たものであり、進歩性を有さない。」
イ 主張2(特許異議申立書第26ページ)
「よって、引用発明2は、以下の相違点1に係る構成を備えるか不明である点においてのみ、本件特許発明1と相違する。
(相違点1)情報中継装置が、情報提供装置にアクセスするための認証情報を記憶する中継記憶部を有し、前記認証情報によって認証を受けて前記情報提供装置にアクセスする。
しかし、甲第4号証には、アカウント情報連携サーバ100(情報中継装置)が人事部システム200(情報提供装置)へ認証を受けてアクセスすることは特に記載されていないものの、人事部システム200から発令情報Pがアカウント情報連携サーバ100へ送信されることは記載されている。この点、引用発明2において、アカウント情報連携サーバ100が人事部システム200から発令情報Pを取得するに当たり、人事部システム200側から、予め記憶した認証情報による認証を受けてアクセスすることには格別の技術的意義はなく、このような構成を採用することは、当業者が適宜選択し得る設計的事項であると言える。
以上より、引用発明2において相違点1に係る構成を採用することは、当業者の通常の創作能力の発揮であると言えるから、本件特許発明1は、引用発明2に基づいて当業者が容易に想到し得たものであり、進歩性を有さない。」
ウ 主張3(令和7年8月22日提出意見書第2ページ)
「相違点2については、当業者が適宜選択し得る設計事項に過ぎません」
(2)申立人の主張についての検討
ア 主張1について
上記1のとおり、本件特許発明1と、甲第1号証から甲第3号証より把握される甲1公然実施発明との間には、上記相違点1-1~1-4が認められるところ、少なくとも相違点1-2及び1-3に係る本件特許発明1の構成については、当業者が容易に想到し得たものではない以上、本件特許発明1は、新規性及び進歩性を有する。よって、申立人の上記主張は、その前提に誤りがある。
イ 主張2について
申立人が主張する上記相違点1は、相違点2-1及び2-2に対応したものと解されるが、上記2において説示したとおり、相違点2-1及び2-2に係る本件特許発明1の構成を当業者が容易に想到し得たとはいえない。また、申立人は、人事部の担当者から人事部システム200を介して発令情報Pがアカウント情報連携サーバ100へ送信されることを契機として、人事部システム200から一方的に発令情報Pが送信されることを前提としている甲4発明において、「アカウント情報連携サーバ100が人事部システム200から発令情報Pを取得するに当たり、人事部システム200側から、予め記憶した認証情報による認証を受けてアクセスすることには格別の技術的意義はなく、このような構成を採用することは、当業者が適宜選択し得る設計的事項であると言える。」と主張する根拠について具体的に説明をしていない。
ウ 主張3について
上記1(1)で述べたように、少なくとも相違点1-2及び1-3に係る本件特許発明1の構成については、当業者が容易に想到し得たものではない以上、相違点1-4(申立人が主張する相違点2に相当)について検討するまでもなく、本件特許発明1は、当業者が公然実施発明に基づいて容易に発明することができたものとはいえない。
以上のとおりであるから、申立人の主張はいずれも採用しない。
以上のとおりであるから、請求項1,3,6,8-10に係る発明は、各取消理由通知書に記載した取消理由並びに特許異議申立書に記載された特許異議の申立ての理由及びその証拠によって取り消すことはできない。さらに、他に請求項1,3,6,8-10に係る特許を取り消すべき理由を発見しない。
また、請求項2は、本件訂正により削除されたため、申立人による特許異議の申立てにおける請求項2に係る特許についての申立ては、申立ての対象が存在しないものとなったので、特許法第120条の8第1項で準用する同法第135条の規定により却下する。
Next Action
類似審決の追加調査から中間応答、新規出願の費用確認まで、この審決を起点に次のアクションへ進めます。
商標の登録可能性を無料で確認するか、費用の目安を料金表・シミュレーターで把握できます。