2023-700916

特許第７２３３０４７号発明「情報管理装置及び情報管理方法」の特許異議申立事件について、次のとおり決定する。

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

理 由 第１ 手続の経緯 特許第７２３３０４７号（以下、「本件特許」という。）の請求項１～８に係る特許についての出願は、平成３１年３月４日に出願され、令和５年２月２４日にその特許権の設定登録がされ、同年３月６日に特許掲載公報が発行された。その後、本件特許に対し、同年９月６日に異議申立人 久門享（以下、「申立人」という。）は、特許異議の申立てを行った。 第２ 本件発明 本件特許の請求項１～８の特許に係る発明は、それぞれ、その特許請求の範囲の請求項１～８に記載された事項により特定される次のとおりのものである。（以下、それぞれ、「本件発明１」～「本件発明８」という。なお、請求項１の「１Ａ」～「１Ｆ」は、申立人が特許異議申立書において付した符号である。） 「 【請求項１】 １Ａ 情報処理装置が、 １Ｂ ユーザの属性を属性情報として管理する処理と、 １Ｃ 前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する処理と、 １Ｄ 前記属性変更情報に基づいて前記イベントが発生したか否かを確認するための確認情報を生成する処理と、 １Ｅ 前記確認情報を予め設定されたタイミングで所定の情報処理端末に送信する処理と、 １Ｆ を実行する情報処理方法。 【請求項２】 前記所定の情報処理端末は、前記ユーザに対応付けられた情報処理端末を含む、請求項１に記載の情報処理方法。 【請求項３】 前記所定の情報処理端末は、前記ユーザに対応付けられたユーザであって、前記ユーザとは異なるユーザに対応付けられた情報処理端末を含む、請求項１または２に記載の情報処理方法。 【請求項４】 前記情報処理装置が、前記確認情報により前記イベントの発生が確認された場合に、前記ユーザの属性を変更する処理をさらに実行する、請求項１～３のいずれか１項に記載の情報処理方法。 【請求項５】 前記情報処理装置が、前記確認情報に重要度を付与する処理をさらに実行する、請求項１～４のいずれか１項に記載の情報処理方法。 【請求項６】 前記予め設定されたタイミングは、前記イベントに基づいて決定される、請求項１～５のいずれか１項に記載の情報処理方法。 【請求項７】 ユーザの属性を属性情報として管理する手段と、 前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する手段と、 前記属性変更情報に基づいて前記イベントが発生したか否かを確認するための確認情報を生成する手段と、 前記確認情報を予め設定されたタイミングで所定の情報処理端末に送信する手段と、 を備える情報処理装置。 【請求項８】 情報処理装置に、 ユーザの属性を属性情報として管理する処理と、 前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する処理と、 前記属性変更情報に基づいて前記イベントが発生したか否かを確認するための確認情報を生成する処理と、 前記確認情報を予め設定されたタイミングで所定の情報処理端末に送信する処理と、 を実行させるためのプログラム。」 第３ 申立理由の概要 １ 申立人の提出した証拠 申立人は、次の甲第１号証～甲第８号証（以下、それぞれ「甲１」～「甲８」という。）を証拠として提出している。 甲第１号証（甲１）：米国特許第７９３７３２９号明細書 甲第２号証（甲２）：特開２０１６－１４８９０７号公報 甲第３号証（甲３）：特開２０１１－１４１８４０号公報 甲第４号証（甲４）：特開２００７－９５０２３号公報 甲第５号証（甲５）：特開２００２－２９７８４７号公報 甲第６号証（甲６）：米国特許出願公開第２００７／０２５５６０９号明細書 甲第７号証（甲７）：米国特許出願公開第２００８／００５９２６７号明細書 甲第８号証（甲８）：特開２００１－３５０８８４号公報 ２ 特許異議の申立理由 申立人の主張する特許異議の申立ての理由の概要は以下のとおりである。 （１）新規性欠如 本件発明１～４及び６～８は、甲１に記載された発明であって、特許法２９条１項３号に該当するから、本件発明１～４及び６～８についての特許は、特許法２９条１項の規定に違反してされたものである。 （２）進歩性欠如 本件発明１～８は、甲１に記載された発明に基づいて、甲１に記載された発明及び周知技術に基づいて、甲２及び甲５に記載された発明に基づいて、又は、甲２及び甲５に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本件発明１～８についての特許は、特許法２９条２項の規定に違反してされたものである。 第４ 甲号証の記載 １ 甲１（米国特許第７９３７３２９号明細書） 甲１には、以下の記載がある。（なお、外国語文献の日本語翻訳文は、申立人の提出した甲１の抄訳を採用し、一部、合議体が変更した。また、下線は、注目箇所に合議体が付した。以下、同様。） 「図１は、コンピュータ装置１２と、それの等しいバックアップ用コンピュータ装置１２’とを含む、本発明のシステム１０の典型的なアーキテクチャ実装を示す。」（第７欄第１９～２１行） 「コンピュータ装置１２、１２’のそれぞれの基本的な構成は、図２に示されている。例示的な一実施形態では、コンピュータ装置１２は、中央処理装置（ＣＰＵ）３２、記憶装置３４、システムクロック３５、ビデオインターフェース３６、入力／出力（Ｉ／Ｏ）インターフェース３８、及び通信インターフェース４０の各々に直接接続されるバス３０を含み得る。」（第７欄第３８～４４行） 「システム１０がインターフェース層６８の任意の構成要素６９ａ、６９ｂ、６９ｃ、６９ｄを介してアクセスされた後、任意のユーザ要求又は問い合わせが、統合層５０に渡され、統合層５０は、要求されたユーザアクションを実行するための統合ファシリティ５２と、ビジネスアプリケーション層５８及びサードパーティ製品層５４の加入しているシステムに共通の基本ユーザ情報を維持するための共有データベース５１と、ビジネスアプリケーション層５８及びサードパーティ製品層５４のすべての加入しているシステムが従う共通ルールを備えるビジネスルールデータベース５３と、を備える。」（第７欄第６３行～第８欄第５行） 「統合ファシリティ５２は、以下に図７を参照して詳細に説明するが、ユーザ／従業員に関する関連情報、例えば、社会保障番号、氏名、住所、生年月日、婚姻歴、子供の氏名などを収集し、共有する。この情報は、ベネフィットパッケージが購入された時に、初期セットアップ中に、統合ファシリティ５２を介して各ユーザ／従業員によってシステム１０に提供される。」（第１０欄第５３～６０行） 「ライフイベント ユーザとシステム１０との間のインタラクションは、やり取りがインターネットを介して進行している場合、一般的に使用されている任意のウェブブラウザを使用することによって達成され得、ここで、インターフェース画面が、会社の所有者／雇用者又はマネージャであるユーザに提示される。図５に示されるように、統合ファシリティ５２（図３）は、双方向にかつ特定のライフイベントを予期することによって、各契約者にアドバイス及び案内情報８４を提供する。さらに、必要なビジネスタスク８８のリマインダが提示され、これもまた、任意の数のライフイベントによってトリガされる。ライフイベントの一例は、個人税暦年の終わりを示す１２月３１日の経過であってもよく、このイベントは、米国における１月３１日の締切日に間に合い、４月１５日の納税申告日に間に合うように税務書類を発行する必要性を引き起こす。 図３に戻ると、ライフイベントはまた、以下のトリガデータを含み得る：すなわち、顧客のビジネス、従業員、サプライヤ、政府規制、顧客の財務状態、出産、雇用、解雇、ポリシーの変更、及び他のそのようなイベントの情報である。ライフイベントのトリガデータは、顧客によって連続的に提供されてもよい。ライフイベントがアクションをトリガすると、統合ファシリティ５２は、加入されたベネフィットパッケージの製品５９、５５～５７の各々において適切なアクションを開始し、あるいは、実行される必要がある未決定のＨＲ機能に対してユーザ／従業員に警報し得る。」（第１１欄第１～２６行） 「ライフイベントを介して自動的に実行されるタスクとは別に、ユーザ／従業員は、特定のタスク８６（図５）が実行されること、又はその手動での実行が許可されることを要求し得る。そのようなタスク８６（図５）は、給与の支払い、インターフェース６８によって表示される会社メッセージの編集、及び会社のカレンダーの編集を含み得る。 例えば、従業員が解雇される場合、雇用者は、この更新情報を統合ファシリティ５２に提供する。システム１０は、特に、以下のイベントを開始する：給与処理６２がベネフィットパッケージ５４のための報酬の支払並びに失業及び所得控除を停止する；健康保険給付が終了され、適切なＣＯＢＲＡの補償が支給される；且つ投資プログラム（退職、４０１Ｋ、利益分配）が変更要求を発行する、など。各ステップにおいて、雇用者又は従業員は、これらの変化を生じさせるため及びこれらの変化が円滑に行われることを確実にするための特定の情報を入力することを求められる。本システムは雇用者に対し、特定の情報を入力するよう促し、再就職支援サービスの開設、特定の福利厚生又は昇進からの従業員の削除の準備など、望まれる追加の行動を提案する。」（第１１欄第２７～４８行） 「図７（図７ａ、図７ｂ、および図７ｃを含む）は、オープンアーキテクチャソース総合システム（ＯＡＳＩＳ）として知られる統合ファシリティ５２（図３）の一実施形態の例示的なフローを示す。ＯＡＳＩＳは、システム１０の他の構成要素と通信するために、分散コンポーネントオブジェクトモデル（ＤＣＯＭ）、Ｊａｖａ、および共通オブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ）をサポートする、構成要素ベースのイベント駆動型技術で構成される。統合ファシリティ５２（図３）はＨＲＭＳ／給与計算５９ｇ（図３）及び総勘定元帳５９ｆ（図３）を含む重要な製品、並びにいくつかのサードパーティ製品５５～５７（図３）を含む重要でない製品を含む。ＯＡＳＩＳは、開発をより容易にするために、イベント駆動型アクション反応モデル技術を利用して実装され得る。ＯＡＳＩＳの構成要素は： （１）イベントトリガエンジンであって： イベントプロファイル； 特定のイベントの通知を登録するプロセスのサブスクリプション； イベントとイベント条件； アクションとアクション条件＿アクションプロセスはイベントの結果としてトリガされる； ルール／ビジネス・入力ルール； データ変更に基づいてイベントをトリガする時期を決定するための監視；及び ソース間でデータを変換するためのデータストレージアダプタ を含むイベントトリガエンジンと、 （２）ビジネスアクションオブジェクトと、 （３）情報源アダプタ／変換ルールとデータと、 （４）データ管理ツールと、 を含む。」（第１２欄第４２行～第１３欄第４行） 「図１５は、イベントという名称のデータレコードについて、Event_Task、Event_Action、及びUser_Eventという関連データレコードがあることを示す。したがって、システムによって認識される各イベントは、ユーザイベント、イベントタスク、及びイベントアクションに関連付けられる。上述のように、システムで認識及び処理されるイベントには、社員の昇給、税年度終了日、婚姻状況の変化、扶養家族数（世帯サイズ）の変化などが含まれる。」（第２０欄第６～１４行） 「 ［図：0001404852000001.jpg］ 」 「イベント処理 したがって、システム８００は、データストアを更新するためにデータ処理を開始するイベントをトリガすることによって駆動され、したがって、データレイヤを通して要求されたデータを受信するビジネスプロセスが更新された情報を受信することを確実にする。図１６は、そのようなトリガイベントに応答するシステムの処理を示すフロー図である。 図１６のフロー図のボックス１６０２によって示される第１の動作では、システムがトリガイベントを検出する。上述のように、トリガイベントは暦年の変化（例えば、税年度の終了を意味する）などの自動的に検出されたイベントであってもよく、又はトリガイベントは、子供の誕生による追加の扶養家族又は（従業員の住所のためのデータストア入力の変化に加えて、州税計算及び他の規制上の調整の変化を必要とし得る）住居の変化などユーザ入力イベントであってもよい。データレイヤの処理は、そのようなトリガイベントの検出及び認識に関与する。 次に、フロー図のボックス１６０４によって表されるように、システムは、影響を受けるデータレコードを決定する。例えば、データレイヤの処理は従業員が新しい住所を入力したことを検出し、居住地の変化を示し、新たな居住地の状態が、異なる税計算及び医療保険適用範囲の変化などを必要とすることを自動的に決定する。同様に、データレイヤの処理は暦年の末が過ぎたことを検出し、税計算を自動的に開始し、税務書類及び各従業員に提供するために必要な他の文書を自動的に生成する。 場合によっては、システムが従業員から追加の情報を取得する必要があり得る。システムは、フロー図のボックス１６０６によって示されるように、そのような情報について従業員に自動的に問い合わせる。したがって、ユーザインターフェース画面（図１４）の従業員が、報告する追加の扶養家族を有することを示すとき、システムは、その従業員の記録を更新するためにシステムによって必要とされる情報を要求する質問画面を自動的に生成する。例えば、システムは、扶養家族の氏名、年齢、性別、生年月日などを自動的に要求する。図１６のフロー図のボックス１６０８によって表されるように、任意のそのような追加の情報が、システムのデータストアに記憶される。このようにして、システムはトリガイベントによって影響を受けるすべてのデータレコード（テーブル）が最新の状態に保たれるように、データレイヤのデータストアを自動的に更新する。」（第２０欄第３９行～第２１欄第１６行） ２ 甲２（特開２０１６－１４８９０７号公報） （１）甲２の記載 甲２には、以下の記載がある。 「【０００７】 本発明の別の態様は、属性情報管理方法である。この方法は、組織または人に関する将来の属性を示す情報であって、所定の記憶領域に格納された組織または人に関する現在の属性を示す現在属性情報への適用タイミングを含む将来属性情報が入力された場合に、入力された将来属性情報を、所定の記憶領域とは異なる記憶領域へ格納するステップと、異なる記憶領域に格納された将来属性情報のうち適用タイミングに至った将来属性情報にしたがって、新たな現在属性情報を所定の記憶領域へ格納するステップと、所定の記憶領域に格納された新たな現在属性情報を所定の外部装置へ提供するステップと、をコンピュータが実行する。」 「【００１１】 図１は、実施の形態のＩＤ管理システム１０の構成を示す。ＩＤ管理システム１０は、企業の組織や従業員等に関する各種属性情報の管理に係る情報処理システムである。ＩＤ管理システム１０は、ＩＤ管理装置１２、人事部システム１４、経営企画部システム１６、業務部門システム１８、連携先システム２０で総称されるシステムＡ用リポジトリ２０ａ、システムＢ用リポジトリ２０ｂ、システムＣ用リポジトリ２０ｃを備える。これらの各システム・装置は企業のイントラネットで接続される。なお、ＩＤ管理装置１２に接続される各装置・システムは、社内（社内網内）に構築された装置・システムに限らず、クラウド等、社外に構築された装置・システムであってもよい。 【００１２】 ＩＤ管理装置１２は、企業に設けられた複数の組織や、企業に雇用された複数の社員に関する様々な属性情報を一元的に管理する情報処理装置である。社員に関する属性情報は、社員番号や氏名、所属組織、役職、権限等を含み、またそれらの識別情報であるＩＤを含む。人事部システム１４は、人事部に設置されたＰＣ等の各種装置を含み、人事異動に関する異動情報２２をＩＤ管理装置１２へ送信する。経営企画部システム１６は、経営企画部に設置されたＰＣ等の各種装置を含み、組織改編に関する組織改編情報２４をＩＤ管理装置１２へ送信する。」 「【００１７】 （第１の実施の形態） 図２は、第１の実施の形態のＩＤ管理装置１２の機能構成を示すブロック図である。ＩＤ管理装置１２は、通信部３０、制御部３２、記憶部３４を備える。通信部３０は、種々の通信プロトコルにしたがって外部装置との通信処理を実行する。通信対象の外部装置は、ＩＤ管理対象の企業内に構築された装置に限らず、クラウド等の企業外に構築された装置も含む。制御部３２は、組織や社員に関する属性情報管理のための各種データ処理を実行する。制御部３２は、通信部３０を介して外部装置とデータを送受する。記憶部３４は、制御部３２によるデータ処理のための各種データを記憶する記憶領域である。」 「【００１９】 記憶部３４は、先付データ保持部３６、属性リポジトリ３８、定義情報保持部４４を備える。先付データ保持部３６は、人事部システム１４から送信された異動情報２２、経営企画部システム１６から送信された組織改編情報２４、業務部門システム１８から送信された付加情報２６を保持する。以下、異動情報２２、組織改編情報２４、付加情報２６を総称して「先付データ」とも呼ぶ。先付データは、後述の先付属性情報に反映させるべき組織や社員に関する属性情報を含む。 【００２０】 属性リポジトリ３８は、組織や社員に関する現在・過去・未来の属性情報を保持する。属性リポジトリ３８は、先付属性保持部４０と現在過去属性保持部４２を含む。属性リポジトリ３８は、ＩＤ管理装置１２とは物理的に別の装置・筐体に設けられてもよい。例えば、属性リポジトリ３８を備えるリポジトリサーバ（データベースサーバ）がＩＤ管理装置１２とは別に設けられ、ＩＤ管理装置１２は、通信網を介してリポジトリサーバの属性リポジトリ３８にアクセスしてもよい。 【００２１】 現在過去属性保持部４２は、組織や社員に関する現在適用中の属性と、過去適用された属性の両方を含む情報（以下「現在過去属性情報」と呼ぶ）を保持する。現在過去属性情報のうち現在の属性情報と過去の属性情報を区別する場合、前者を「現在属性情報」と呼び、後者を「過去属性情報」と呼ぶ。先付属性保持部４０は、組織や社員に関する将来の属性を示す情報（以下「先付属性情報」と呼ぶ）を保持する。先付属性情報は、現在は未確定であるが、将来の割当て・付与が予定されている先日付（未来日付）の属性情報である。現在過去属性情報と先付属性情報の具体例は後述する。」 「【００２３】 制御部３２は、先付データ取得部４６、属性情報取込部４８、適用処理部５０、属性情報提供部５４を備える。先付データ取得部４６は、人事部システム１４、経営企画部システム１６、業務部門システム１８から送信された先付データを取得し、先付データ保持部３６へ格納する。 【００２４】 属性情報取込部４８は、先付データ保持部３６に新たな先付データが格納されたことを検出すると、その先付データが示す組織や社員の属性情報を先付属性情報として先付属性保持部４０へ格納する。属性情報取込部４８は、１日の予め定められた時刻になったことを契機に、このような先付属性情報取込処理を実行してもよい。 【００２５】 図３は、先付属性保持部４０に格納される先付属性情報の一例を示す。同図は、先付データとしての異動情報２２に基づいて設定された先付属性情報を示している。先付属性情報は、先付データの内容をそのまま転記したものでもよい。先付属性情報は、その属性値を現在属性情報へ反映すべきタイミング（日付、時刻等）を示す適用開始日を含む。具体的に図３の先付属性情報は、１２月１日に「野村太郎」がコンサルティング部の部長へ異動となり、１２月１日に「野村花子」が退職することを示している。なお、適用開始日は、人事異動や組織改編の発令日が設定されてもよい。」 「【００２７】 なお、属性情報取込部４８は、所定の削除操作の入力や、所定の削除指示データの受信に応じて、先付属性保持部４０に格納済の先付属性情報を削除してもよい。この削除操作や削除指示データでは、削除対象の先付属性情報を特定するためのキー（例えば社員ＩＤと適用開始日の組み合わせ）が指定されてもよい。同様に属性情報取込部４８は、所定の更新操作の入力や、所定の更新指示データの受信に応じて、先付属性保持部４０に格納済の先付属性情報を更新・変更してもよい。この更新操作や更新指示データでは、更新対象の先付属性情報を特定するためのキーと、属性の更新値が指定されてもよい。このように、先付属性保持部４０に格納された先付属性情報は、その適用開始日に至るまでの期間に更新・削除されうる。」 「【００２９】 適用処理部５０は、先付属性保持部４０に格納された先付属性情報のうち適用開始日に到達した先付属性情報にしたがって、新たな現在属性情報を現在過去属性保持部４２に格納する適用処理を実行する。適用処理部５０は、１日の所定の時刻に到達した場合にバッチ処理として適用処理を実行してもよい。また適用処理部５０は、ＩＤ管理装置１２のＯＳが管理する現在日付を参照して、適用処理の対象とする先付属性情報を識別してもよい。適用処理部５０は、適用開始日に未達の先付属性情報は適用処理の対象外とする。」 「【００４９】 第１の実施の形態のＩＤ管理装置１２では、先付属性情報を保持する先付属性保持部４０を、現在過去属性情報を保持する現在過去属性保持部４２とは別に設けた。先付属性情報は、適用開始日に至るまでの期間に変更されうる未確定のデータである。現在過去属性保持部４２に未確定のデータを入力する場合、現在確定している属性を取得し、また更新することが複雑になってしまう。また未確定の属性を配信してしまうリスクも高まる。ＩＤ管理装置１２では、確定した属性情報の記憶領域と、未確定の属性情報の記憶領域を明確に区別することで、属性情報管理を安全かつ効率的に実現する。」 「【図３】 ［図：0001404852000002.jpg］ 」 （２）甲２発明 上記（１）によれば、甲２には、以下の甲２発明が記載されている。 ［甲２発明］ 「企業の組織や従業員等に関する各種属性情報の管理に係る情報処理システムであるＩＤ管理システム１０が備える、ＩＤ管理装置１２が実行する属性情報管理方法であって、（【００１１】） ＩＤ管理装置１２は、企業に設けられた複数の組織や、企業に雇用された複数の社員に関する様々な属性情報を一元的に管理する情報処理装置であって、社員に関する属性情報は、社員番号や氏名、所属組織、役職、権限等を含み、またそれらの識別情報であるＩＤを含み、（【００１２】） ＩＤ管理装置１２は、制御部３２、記憶部３４を備え、（【００１７】）、 記憶部３４は、先付データ保持部３６、属性リポジトリ３８、定義情報保持部４４を備え、（【００１９】） 属性リポジトリ３８は、組織や社員に関する現在・過去・未来の属性情報を保持するとともに、先付属性保持部４０と現在過去属性保持部４２を含み、（【００２０】） 現在過去属性保持部４２は、組織や社員に関する現在適用中の属性である現在属性情報と、過去適用された属性である過去属性情報の両方を含む情報を保持し、先付属性保持部４０は、組織や社員に関する将来の属性を示し、現在は未確定であるが、将来の割当て・付与が予定されている先日付（未来日付）の属性情報である先付属性情報を保持し、（【００２１】） 制御部３２は、先付データ取得部４６、属性情報取込部４８、適用処理部５０、属性情報提供部５４を備え、先付データ取得部４６は、先付データを取得し、先付データ保持部３６へ格納し、（【００２３】） 属性情報取込部４８は、先付データ保持部３６に新たな先付データが格納されたことを検出すると、その先付データが示す組織や社員の属性情報を先付属性情報として先付属性保持部４０へ格納し、（【００２４】） 先付属性情報は、先付データとしての異動情報２２に基づいて設定され、その属性値を現在属性情報へ反映すべきタイミング（日付、時刻等）を示す適用開始日を含み、例えば、１２月１日に「野村太郎」がコンサルティング部の部長へ異動となり、１２月１日に「野村花子」が退職することを示し、（【００１２】、【００２５】、【図３】） 適用処理部５０は、先付属性保持部４０に格納された先付属性情報のうち適用開始日に到達した先付属性情報にしたがって、新たな現在属性情報を現在過去属性保持部４２に格納する適用処理を実行する、（【００２９】） ＩＤ管理装置１２が実行する属性情報管理方法。」 ３ 甲３（特開２０１１－１４１８４０号公報） 甲３には、以下の記載がある。 「【００２４】 図10は、HDD101に格納され、イベント重要度算出プログラムが更新する将来のイベント管理テーブル2である。本テーブルは、CPU105を介してイベント発生時期予測プログラムが管理する将来のイベント管理テーブル1と同様の構成からなる。イベント発生時期予測プログラムによって、イベントが追加された際に、外部入出力装置114がネットワーク117、外部記憶装置115から入力されたユーザのイベントに関連するデータを基に、イベントの重要度を判断し、重要度(1003)の項目を更新する。」 「【００６７】 イベント発生時期予測プログラムが推定するイベントの発生予測日は、イベントを忘れないことが主目的であるため正確な日付をユーザに提示する必要はない。例えば、イベントを発生予想時期より早めに通知して、必要があれば正確な日付にユーザが修正するなどとしてもよい。本実施例においては、イベントの発生日時より20日前に通知することとする。よって、通知イベント(902)「父の日」に対するイベント通知予定日(900)は「2009/6/1」となる。以下、図１８も参照して説明する。 【００６８】 次に、ユーザが作成した入力データ、嗜好管理テーブルから、将来のイベント管理テーブルにて格納されるイベントの重要度を算出し、算出したイベント重要度を基に将来のイベント管理テーブルを更新する(S206) 。イベント重要度を算出し、将来のイベント管理テーブルを更新するまでの処理手順を下記に示す。」 「【００８０】 関連情報通知方法例として、はじめにイベントの通知のみを行い、ユーザからの指示があった場合に、関連情報を表示してもよいとする(図13) 。 本実施例において、外部部出力デバイス104へのイベントの通知は、将来のイベント管理テーブル3(図11)が格納するイベント通知予定日(年/月/日)(1100)と一致する日に電源投入されたタイミングでイベントを通知する。イベント通知予定日(年/月/日)(1100)と一致する日に電源投入がなかった場合は、イベント通知予定日以降、一番初めに電源投入された時にイベントを通知することとする。イベント予想発生日を過ぎて電源気投入があった場合は、イベントは通知しないこととする。ただし不可避のイベント等あるものについては設定により予想発生日を過ぎても通知するのも好適である。 【００８１】 また、将来のイベント管理テーブル3(図11)が格納する通知イベント(1102)の重要度(1103)が「高」の場合、通知する外部出力デバイスを複数とし、重要度「低」や「中」のものよりもフォントを大きくし、効果音や音楽なども合わせて通知し、再通知間隔も短くするなどとすることで、ユーザに対してイベントの発生を強く通知する。」 ４ 甲４（特開２００７－９５０２３号公報） 甲４には、以下の記載がある。 「【００２３】 図２に示すように、スケジュールの重要度に応じて、「非常に重要」の場合、１５日前、７日前、３日前、２日前、１日前、当日の定刻午前９時に通知が行われ、「重要」の場合、１０日前、５日前、２日前、１日前、当日の定刻午前９時に通知が行われるなど、スケジュールの重要度に応じて最初の通知日及び通知間隔に差があるが、前記最初の通知日、通知時刻、通知間隔などはユーザにより変更可能である。」 「【００２７】 図４は本発明の一実施形態によるスケジュール管理方法を示すフローチャートである。 【００２８】 図４に示すように、ユーザは、スケジュール登録時、スケジュールの日付、内容、及び重要度のみを入力して保存する（Ｓ４１０）。保存が完了すると、携帯端末機は、所定時間間隔で前記重要度による通知時刻が現在時刻と一致するか否かを判断する（Ｓ４２０）。 【００２９】 前記一致するか否かの判断の結果、前記重要度による通知時刻が現在時刻と一致すると、携帯端末機は、音、振動、ランプ、及びスケジュール内容表示などの通知を行って、ユーザに前記スケジュールを想起させる（Ｓ４３０）。」 ５ 甲５（特開２００２－２９７８４７号公報） 甲５には、以下の記載がある。 「【００１０】この請求項１に記載の発明によれば、スケジュールを構成するいずれかの要素が未確定の状態にある場合、当該スケジュールのパターンから導出される適切な時期になると、その確定がユーザに対して推奨される。」 「【００３７】本発明は要約すれば、曖昧なスケジュール、たとえば日時が漠然としか決まっていない、日時は決まったが場所がまだ決まっていないなどといったスケジュールの登録を可能とし、かつ適切な時期になると、未確定の要素の確定をユーザに促したり、あるいは何らかの情報源から要素値を自動的に推定したりして、曖昧なスケジュールの具体化の支援をおこなうものである。」 「【００５１】図２に戻り、つぎにスケジュール記憶部２０１は、スケジュール登録部２００により抽出され変換された各要素とその確定／未確定の種別とを、所定の形式のデータベースに保持する機能部である。図３は、スケジュール記憶部２０１に保持されるデータベースを模式的に示す説明図である。」 「【００７３】図２に戻り、つぎに確定時期判定部２０５は、スケジュール記憶部２０１に保持された個々のスケジュールの構成要素が、当該スケジュールにつき選定されたパターンにしたがって確定されているかどうか、言い換えれば、スケジュールの具体化がそのパターンに照らして遅延していないかどうかをチェックする機能部である。なお、このチェックは定期的、たとえば毎回の起動時と毎日の始業時のタイミングでおこなうものとする。 【００７４】定期チェックのタイミングになると、確定時期判定部２０５はスケジュールの構成要素のうちまだ確定されていないもの、すなわちその種別が未確定のままとなっている要素について、当該スケジュールの登録日時、予定日時およびパターンからその確定時期を算出する。そして、現在日時がこの確定時期を超えている要素、すなわち確定時期が到来したにもかかわらず未確定の状態にある要素を特定する。」 「【００７６】つぎに、スケジュール確定部２０６は、確定時期になってもまだ確定されていない要素の確定をユーザに促したり、あるいは可能な場合には、何らかの情報源から当該要素の値を推定してユーザに提示することで、その確定を支援したりする機能部である。 【００７７】たとえば、８月３日になってもＩＤ＝２の会議のメンバーが確定されていない場合には、スケジュール確定部２０６はその推奨ダイアログ表示部２０６ａにより、図７に示すような推奨ダイアログを画面表示して、ユーザによるメンバーの確定を促す。」 「【図３】 ［図：0001404852000003.jpg］ 」 図３と段落【００５１】によれば、「スケジュール記憶部２０１」に保持されるスケジュールの「要素」とは、例えば、「内容」や「日時」、「場所」、「メンバー」を表すものである。 「【図７】 ［図：0001404852000004.jpg］ 」 ６ 甲６（米国特許出願公開第２００７／０２５５６０９号明細書） 甲６には、以下の記載がある。 「［０００８］図１は、本発明での使用に適した例示的なコンピュータシステム１００の簡略化されたブロック図である。マネージャは、ディスプレイ１０２を介してReminder of Dates iViewを閲覧することができる。マネージャは、パーソナライゼーションダイアログにアクセスし、入力／出力（Ｉ／０）装置１０４を介して、Reminder of Dates iViewに表示されるべき特定のカテゴリの日付を選択することができる。マネージャは、また、彼の個人カレンダーにも表示されるべき、Reminder of Dates iViewに表示される日付のサブセットを選択することができる。例えば、マネージャは、従業員の契約がいつ終了するかを示すすべての日付、及び一時的労働不能休暇または出産休暇などの従業員による大規模休暇に関するすべての日付が自分のReminder of Dates iViewに表示されることを望み得る。しかしながら、マネージャは、自分の従業員の契約がいつ終了するかを示す日付のみを自分の個人力レンダーに表示することを望み得る。マネージャは、従業員の契約の終了に関する日付のみを自分の個人カレンダーに表示させることを選択できる。マネージャが、Ｉ／０装置１０４を介してReminder of Dates iView及び自身の個人カレンダーに表示されることを望む日付のタイプをそれぞれ選択すると、ＣＰＵ１０６は、この要求を日付リマインダモジュール１０８に渡し得る。日付リマインダモジュール１０８は、マネージャによって選択された日付のタイプを取り出すために、人的資源データベース１１０にアクセスし得る。マネージャのアイデンテイティがその従業員に関連付けられているので、日付リマインドモジュール１０８は、マネージャの従業員に関連付けられた日付のみにアクセスする。日付リマインダモジュール１０８は選択された日付をＣＰＵ１０６に戻すことができ、ＣＰＵ１０６は、この日付を、Reminder of Dates iView及びマネージャの個人カレンダーそれぞれに表示する。 ［０００９］マネージャは、また、本発明の一つの実施形態によって、自身の個人カレンダーに入力された日付を変更し得る。マネージャが本発明の実施形態によって自分の個人カレンダーに自動的に入力された日付を変更する場合、この変更は、Reminder of Dates iViewに記録された日付、及びバックエンドに位置する人的資源データベース１１０に維持された日付にも影響を及ぼし得る。例えば、マネージャは、従業員の休暇に対応するすべての日付が彼のカレンダーに表示されることを要求し得る。彼のカレンダー及び彼のReminder of Dates iViewに、従業員Ａが日付Ｘまで出産休暇中であることが入力されてもよい。マネージャはＡが日付Ｙに職場に戻ることを知らされていてもよい。マネージャが彼のカレンダーの日付をＸからＹに変更する場合、この変更はReminder of Dates iView及びバックエンドシステムに位置する人的資源データベース１１０にも反映され得る。」 「［００１１］図２は、本発明の一つの実施形態のデータフロー図である。この方法は、ＣＰＵｌ０６がユーザの個人カレンダー内に特定のタイプのリマインダ日を表示するユーザ要求を検出したときに開始する（ステップ２００）。ＣＰＵ１０６は、選択された日付のタイプおよび利用者の識別情報に基づいて要求を作成する（ステップ２０２）。ＣＰＵ１０６は要求を日付リマインダモジュール１０８に渡し、日付リマインダモジュール１０８は、要求された日付について人的資源データベース１１０を検索する（ステップ２０４）。日付リマインダモジュール１０８は、ユーザの従業員に関連付けられ、ユーザによって選択された日付のタイプからなる応答を作成する（ステップ２０６）。日付リマインダモジュール１０８は、応答をＣＰＵ１０６に送信する（ステップ２０８）。次いで、ＣＰＵ１０６は、ユーザの個人カレンダー内の取得された日付をディスプレイ１０２上に表示する（ステップ２１０）。」 「［００１５］図６Ａは、Reminder of Dates iViewと連携して動作するパーソナライゼーションダイアログ６００の画像表示である。この表示は、マネージャがReminder of Dates iViewに表示させたいデータのタイプを選択することができるパーソナライゼーションダイアログを示す。この例では、マネージャが選択することができる日付のカテゴリは記念日、誕生日、タスクの監視、およびリマインダ日である。例えば、「日付の監視」は、従業員の試用期間、出産休暇、又は従業員に関する任意の他のイベントの終了であってもよい。「リマインダ日」は、例えば、従業員の試用期間の終了など、マネージャが来たるべきイベントをリマインダされることを望む日であってもよい。この日付は、実際のイベントの前の予め設定された時間であり得る。」 ７ 甲７（米国特許出願公開第２００８／００５９２６７号明細書） 甲７には、以下の記載がある。 「［０００２］従業員が新しく雇用されたり社内のある部門から別の部門に転属されたりする場合（議論の目的のため、転属と新規雇用の両方を「従業員の異動」と称する）、従業員を配置し、業務を開始できるようにするために、調整され実行されなければならない多くのタスクが存在する。本開示の目的のために、これらのタスクの実行を従業員の「セットアップ」と称する。例えば、基本リソースは、しばしば、従業員の新しいオフィスの場所で必要とされる、オフィス家具、コンピュータ、電話などである。さらに、セキュリティ認証／アクセスキー及び／又は符号、ＩＤバッジ、コンピュータアカウント、電子メール、電話、携帯電話など、一定のアカウント及び／又はサービスがしばしば、従業員のために設定される必要がある。さらに、一定の訓練が、従業員に適しているか、又は必要であり得る。そのような訓練は、法律によって要求されることさえある。また、ハンディキャップ、ＴＴＬ（聴力障害者のための電話設備）など、特別なニーズがある従業員もいる。」 「［００２３］図２は、そのような方法の例示的な実施形態を示すフローチャートである。図示の例のように、方法は、従業員セットアップに関する１つ又は複数のタスクの実行のための１つ又は複数のタスク要求を含む、従業員のセットアップに関連する入力を収集することを含み得る（ステップ２４）。方法は、また、タスク要求をタスク実行者に向けることを含み得る（ステップ２６）。」 「［００２５］タスク要求は、任意の数の電子通信手段を介してタスク実行者に送信され得る。例えば、いくつかの実施形態では、タスク要求が電子メールを介して送信され得る。代替的又は追加的に、タスク要求は、タスク要求者及び／又は各要求されたタスクのタスク実行者、ならびに監督／管理者など、システム１０にアクセスする個人によって見ることができるように、システム１０内に記憶され得る。」 「［００２９］システム１０は、例えば、部門レベルの監督者などのタスク要求者が、システム１０を使用して従業員セットアップを開始することができるように構成され得る。監督者は、様々な予め設定されたセットアップスキームから選択することができる。例えば、監督者はセットアップを必要とする従業員が新たな雇用であるか、他の部門からの社内の転属であるか、部門内で異なるオフィス空間に移動するかなどを指定することができ、それによって、従業員によって必要とされるセットアップのタイプに対応するセットアップスキームを選択することができる。人がすでに会社の従業員である転属などのセットアップの場合、システム１０は、会社又は部門のデータベースから従業員に関する個人データを取り出すように構成され得る。そのような個人データは、データベース内の従業員の氏名又は従業員番号を取り出すと、システム１０内のデータフィールドに自動的に入力することができる。」 「［００３５］システム１０は、担当するタスク要求が未完了のままである場合、タスク実行者に通知及び／又はリマインダを送信するように構成され得る。そのようなリマインダは、目標期限が近づくにつれて、及び／又は期限が経過した後、予め設定された時期に送信され得る。」 ８ 甲８（特開２００１－３５０８８４号公報） 甲８には、以下の記載がある。 「【０００３】リマインダ機能は、ユーザがスケジュールイベントを入力した場合に、そのイベントの時刻からある一定時間前もしくはユーザが指定した時間に、ユーザがスケジュールイベントを見落とさないように、ユーザに対して電子メールなどでメッセージを送信する機能である。」 「【０００８】 【発明が解決しようとする課題】従来のリマインダ機能では、スケジュールイベントそのものに対するリマインダ通知のみが可能である。しかしながら、スケジュールイベントによっては、そのイベントに向けてあらかじめ他の作業が必要であったり、イベントの後に他の作業が必要な場合がある。例えば、海外旅行に行く場合には、一ヶ月前に航空券やホテルの予約をしたり、三週間前にパスポートの申請をする必要がある。また、車を購入した場合では、購入後に一ヶ月点検、六ヶ月点検などを行わなければならない。ユーザとしては、スケジュールイベントのリマインダのみでなく、関連する作業アイテムなども合わせて通知してくれることが望ましいが、従来のリマインダ機能では上記のような通知は行うことができない。」 「【００１２】 【課題を解決するための手段】本発明のスケジュールリマイダシステムは、スケジュールイベントに関連した作業項目を記述したリマインドメッセージとそのメッセージをユーザに通知するタイミングに関する情報との組を１以上保持するテンプレートテーブルをイベントの種別ごとに備え、ユーザが入力したスケジュールイベントとその日時とに基づき対応するイベント種別の前記テンプレートファイルからリマインドメッセージとそのメッセージを通知すべきタイミングに関する情報とを取得し、ユーザが入力したイベント日時とその通知するタイミング情報とからリマインドメッセージを送付すべき時刻を求めるリマインドメッセージ登録手段と、このリマインドメッセージ登録手段で求められた送信時刻に前記リマインドメッセージをユーザに送信するメッセージ送付手段とを備えている。また、前記リマインドメッセージ登録手段で得たメッセージ送信時刻の情報と、前記リマインドメッセージと送信宛先との組み合わせを複数個保持することが可能なメッセージデータベースを備え、前記メッセージ送付手段は、このデータベースを参照して送信宛先のユーザにリマインドメッセージを送信する手段を含むことができる。」 「【００２１】本発明第一実施例は本発明の最も基本的な構成および動作を説明するものであり、ユーザがスケジュールイベントのイベント種別とそのスケジュールイベントの日時を指定した場合にスケジュールイベントに関連する作業項目をリマインダメッセージとしてユーザに送付するためのものである。本発明第二実施例は、ユーザがスケジュールイベントのイベント種別を直接指定するのではなく、スケジュールイベントの内容を自由に記述可能とした場合のものである。本発明第三実施例は、リマインドメッセージに広告が含まれる場合に、リマインドメッセージの送付回数に応じて広告課金を行なうためのものである。本発明第四実施例は、リマインドメッセージに元々広告が含まれていない場合でも適切な広告を選択し追加する場合のものである。」 「【００２５】（第一実施例）本発明第一実施例では、ユーザがスケジュールイベントのイベント種別(利用するチェックリストのチェックリストＩＤ)を直接選択し、スケジュールリマインダシステムは指定されたチェックリストに含まれるメッセージをチェックリストで指定されている時刻に送信する場合のものである。」 「【００２７】チェックリストテンプレートファイル２は、イベント種別ごとに異なるファイルとしてシステム側で用意しておき、各ファイルに固有のＩＤをあらかじめ割り当てておく。各チェックリストテンプレートファイル２には、あるイベント種別において、送信すべきリマインドメッセージとそのメッセージを送信する時刻の組が１個以上記述されている。・・・」 「【００３１】メッセージ送信部４は、メッセージデータベース３を参照し、送信時刻がきたリマインドメッセージを送信先アドレスに送信する。本構成では、ユーザがメッセージ送信先アドレスをそれぞれ指定するため、同一のシステムを複数ユーザで利用することが可能である。」 第５ 当審における判断 １ 甲２に基づく判断 事案に鑑みて、甲２を主引用例とした場合について判断する。 （１）本件発明１について ア 本件発明１の構成要件１Ｄの「確認情報」について 本件発明１の構成要件１Ｄにおける「確認情報」は、「ユーザの属性」を変更させる「イベント」である「属性変更情報」に基づいて、「イベントが発生したか否かを確認するため」の情報であると特定されている。 そして、本件明細書には、「確認情報」の技術的意義について、「情報入力部に属性変更情報が入力されると、イベントが発生したか否かを確認する確認情報を確認情報生成部が生成することから、属性変更情報の入力後のユーザの事情の変更等によって、入力した属性変更情報と入力後のユーザの実情とが異なることとなった場合であっても、確認情報に基づいて、入力した属性変更情報をユーザの実情に合わせて修正することができ」（【００１２】）、「効率的かつ適切にユーザの属性を属性情報として管理することができる」（【００１３】、【００１９】）という効果を奏することが記載されている。 これに対し、申立人は、本件明細書の【００６３】及び【００６４】の記載を考慮すれば、「確認情報」とは、イベントが実際に発生したか否かをイベント予定日の後に確認する情報のみならず、イベントがこれから実際に発生するか否かをイベント予定日の前に確認する情報も含むと解釈すべきである旨主張する（特許異議申立書５６頁）。 しかしながら、申立人の主張する【００６３】及び【００６４】は、構成要件１Ｄの「確認情報」について、それがどのような情報であるのかという内容について記載したものではなく、構成要件１Ｅについて、確認情報を送信（通知）するタイミングが用途に応じて適宜設定することができることを記載したものであるから、申立人の主張する【００６３】及び【００６４】の記載によって、構成要件１Ｄの「確認情報」の解釈が変わることはない。 したがって、申立人の主張は採用できない。 イ 対比 本件発明１と甲２発明とを対比する。 （ア）構成要件１Ａ及び構成要件１Ｆについて 甲２発明の「ＩＤ管理装置１２」及び「属性情報管理方法」は、以下の相違点を除き、本件発明１の「情報処理装置」及び「情報処理方法」に相当する。 （イ）構成要件１Ｂについて 甲２発明の「ＩＤ管理装置１２」は「記憶部３４」を備え、当該「記憶部３４」が備える「属性リポジトリ３８」において、組織や社員に関する現在・過去・未来の属性情報を保持するものであり、「社員に関する属性情報」は「社員番号や氏名、所属組織、役職、権限等」や、「それらの識別情報であるＩＤ」を含むものである。そして、甲２発明の「社員」は本件発明１の「ユーザ」に相当するといえるから、甲２発明の「ＩＤ管理装置１２」が備える「属性リポジトリ３８」において、現在・過去・未来の「社員に関する属性情報」を保持する処理は、本件発明１の「ユーザの属性を属性情報として管理する処理」に相当する。 （ウ）構成要件１Ｃについて 甲２発明の「組織や社員に関する将来の属性を示し、現在は未確定であるが、将来の割当て・付与が予定されている先日付（未来日付）の属性情報である先付属性情報」を保持する「先付属性保持部４０」における「先付属性情報」は、「先付データとしての異動情報２２に基づいて設定され」、「その属性値を現在属性情報へ反映すべきタイミング（日付、時刻等）を示す適用開始日」を含むものであり、例えば「１２月１日に「野村太郎」がコンサルティング部の部長へ異動となり、１２月１日に「野村花子」が退職することを示」す情報であるから、甲２発明の「異動情報２２に基づいて設定され」る「先付属性情報」で示される退職等の異動は、本件発明１の「前記ユーザに将来的に発生することが予定されているイベント」に相当する。 そして、甲２発明の「ＩＤ管理装置１２」においては、「適用処理部５０」において、「先付属性保持部４０に格納された先付属性情報のうち適用開始日に到達した先付属性情報にしたがって、新たな現在属性情報を現在過去属性保持部４２に格納する適用処理」が行われるものであるところ、「先付属性保持部４０」に保持される「先付属性情報」は、「適用開始日に到達した」ときに「新たな現在属性情報」として「現在過去属性保持部４２」に格納されるものであるから、甲２発明の上記適用処理は、本件発明１の「前記ユーザの前記属性を変更させる」処理であるということができる。 そうすると、甲２発明において、「現在過去属性保持部４２」の「現在属性情報」を変更させる「先付属性情報」は、本件発明１の「属性変更情報」に相当し、甲２発明の「先付属性保持部４０」が上記「先付属性情報」を保持する処理は、本件発明１の「前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する処理」に相当する。 （エ）構成要件１Ｄ及び構成要件１Ｅについて 甲２発明は、本件発明１の構成要件１Ｄ及び構成要件１Ｅに係る処理を実行するものではない（なお、申立人も、特許異議申立書５５頁下段において、甲２発明が本件発明１の構成要件１Ｄ及び構成要件１Ｅに係る処理を実行しない点を認めている。）。 （オ）一致点、相違点 以上、（ア）～（エ）によると、本件発明１と甲２発明とは、以下の一致点、相違点を有する。 ［一致点］ 「情報処理装置が、 ユーザの属性を属性情報として管理する処理と、 前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する処理と、 を実行する情報処理方法。」 ［相違点］ 本件発明１の「情報処理装置」は、「前記属性変更情報に基づいて前記イベントが発生したか否かを確認するための確認情報を生成する処理」、及び「前記確認情報を予め設定されたタイミングで所定の情報処理端末に送信する処理」を実行するのに対し、甲２発明の「ＩＤ管理装置１２」は、そのような「確認情報」の生成や送信を行うものではない点。 ウ 相違点に関する検討 （ア）申立人が、甲２発明と組み合わせて進歩性欠如を主張する甲５には、上記第４の５のとおり、「スケジュール記憶部２０１に保持された個々のスケジュールの構成要素」（【００７３】）に関して、「確定時期になってもまだ確定されていない要素の確定をユーザに促したり、あるいは可能な場合には、何らかの情報源から当該要素の値を推定してユーザに提示することで、その確定を支援したりする」（【００７６】））ことが記載されている（上記第４の５の【図７】の「推奨ダイアログ」も参照。）。 しかしながら、甲５に記載された「スケジュール記憶部２０１」に保持されるスケジュールの「要素」は、例えば、【図３】に示されるように、「内容」、「日時」、「場所」及び「メンバー」を表すものであって、これらの要素は「ユーザの属性」ではない。 したがって、甲５に記載された上述の「要素の確定をユーザに促したり」、「当該要素の値を推定してユーザに提示する」ための情報（【図７】の推奨ダイアログの情報）は、本件発明１の「ユーザの属性」を変更させる「イベント」である「属性変更情報」に基づいて、「イベントが発生したか否かを確認するため」の「確認情報」であるとはいえない。 そして、申立人が提出した甲１、甲３、甲４及び甲６～甲８（上記第４の１、３、４、６～８参照。）をみても、本件発明１の「確認情報」に相当する構成は記載されておらず、周知技術であるということもできない。 そうすると、本件発明１は、甲２及び甲５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲２及び甲５に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。 （イ）これに対し、申立人は、甲５には、スケジュールを構成する要素が未確定の状態にある場合に、適切な時期になると未確定要素の確定をユーザに促したりすることによって、曖昧なスケジュールの具体化を支援する技術が開示されているから、甲２発明に甲５に記載された技術を組み合わせることで、当業者であれば、本件発明１に容易に想到することができた旨主張する（異議申立書５８～５９頁）。 しかしながら、上記（ア）のとおり、甲５には、本件発明１の「確認情報」に相当する構成は記載されていない。 したがって、申立人の主張は採用できない。 （２）本件発明２～６について 本件発明２～６は、本件発明１の構成にさらに構成を付加し、本件発明１を限定したものであるから、上記（１）イ（オ）の［相違点］を有する。 そうすると、上記（１）ウと同様、本件発明２～６は、甲２及び甲５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲２及び甲５に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。 （３）本件発明７及び８について 本件発明７は、本件発明１の「情報処理方法」について、カテゴリーの異なる「情報処理装置」とした発明である。 そうすると、本件発明７は、甲２から認定される「ＩＤ管理装置１２」と対比すると、上記（１）イ（オ）の［相違点］と同様の相違点を有することとなるから、上記（１）ウと同様、本件発明７は、甲２及び甲５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲２及び甲５に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。 また、本件発明８も、本件発明１の「情報処理方法」について、カテゴリーの異なる「プログラム」とした発明である。 そうすると、本件発明８は、甲２から認定される「プログラム」と対比すると、上記（１）イ（オ）の［相違点］と同様の相違点を有することとなるから、上記（１）ウと同様、本件発明８は、甲２及び甲５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲２及び甲５に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。 ２ 甲１に基づく判断 （１）本件発明１について ア 甲１に記載された事項は、上記第４の１のとおりである。 しかるところ、上記１（１）ウ（ア）のとおり、甲１には、本件発明１の「確認情報」に相当する構成は記載されていない。 そうすると、本件発明１と甲１に記載された発明は、少なくとも、上記１（１）イ（オ）の［相違点］と同じ相違点を有するから、本件発明１は、甲１に記載された発明であるとはいえない。 また、［相違点］に係る構成は、上記１（１）ウのとおり、甲２～甲８には記載されておらず、周知技術であるということもできないから、本件発明１は、甲１に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲１に記載された発明及び周知技術に基づいて、容易に発明をすることができたものであるともいえない。 イ これに対し、申立人は、甲１の【図１６】に示された実施形態では、トリガイベントが検出されると、システムは、場合によっては従業員にそのイベントに関する追加の情報を自動的に問い合わせ、例えば、従業員に扶養家族が増えるときに、その扶養家族の氏名、年齢、性別、生年月日などを自動的に要求し、このとき、追加の情報の問合せに対して追加の情報が入力されたか否かで、そのイベントが実際に発生したか否かが事実上確認されることになるから、従業員に対する追加の情報の問合せは、「属性変更情報に基づいてイベントが発生したか否かを確認するための確認情報」に相当し、また、甲１の「ビジネスタスク８８のリマインダ」についても、イベントがトリガされると提示されるものであるから、「属性変更情報に基づいてイベントが発生したか否かを確認するための確認情報」に相当すると主張する（異議申立書４３～４４頁）。 しかしながら、上記１（１）アのとおり、本件発明１の「確認情報」は、「ユーザの属性」を変更させる「イベント」である「属性変更情報」に基づいて、「イベントが発生したか否かを確認するため」の情報であって、上記１（１）アで説示した技術的意義を有するものであるから、申立人の主張する上述の「従業員に対する追加の情報の問合せ」及び「ビジネスタスク８８のリマインダ」のいずれとも異なるものである。 また、申立人は、仮に甲１に記載された発明が「イベントが発生したか否かを確認する確認情報」に係る本件発明１の構成と相違するとしても、甲１発明におけるタスクのリマインダを、イベントが発生したか否かを確認するタスクのリマインダ（「属性変更情報に基づいてイベントが発生したか否かを確認するための確認情報」）とすることは、当業者が容易になし得たことであり、甲１発明においてイベントに関する入力を促す際やタスクをリマインドする際に、イベントに関する情報の入力を依頼する表示とするか、イベントの発生を確認する表示とするかは、単なる設計的事項であると主張する（異議申立書４４～４７頁）。 しかしながら、上述のとおり、本件発明１の「確認情報」は、甲１発明の「従業員に対する追加の情報の問合せ」及び「ビジネスタスク８８のリマインダ」とは異なるから、申立人の主張する相違点の変更が、単なる設計的事項であるということはできない。 したがって、申立人の主張は採用できない。 （２）本件発明２～６について 本件発明２～６は、本件発明１の構成にさらに構成を付加し、本件発明１を限定したものであるから、本件発明２～６と甲１に記載された発明は、少なくとも、上記１（１）イ（オ）の［相違点］と同じ相違点を有する。 そうすると、上記（１）と同様、本件発明２～４及び６は、甲１に記載された発明であるとはいえない。また、本件発明２～６は、甲１に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえないし、甲１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。 （３）本件発明７及び８について 本件発明７は、本件発明１の「情報処理方法」について、カテゴリーの異なる「情報処理装置」とした発明である。 そうすると、本件発明７は、甲１から認定される発明と対比すると、少なくとも、上記１（１）イ（オ）の［相違点］と同様の相違点を有することとなるから、上記（１）と同様、本件発明７は、甲１に記載された発明であるとはいえない。また、甲１に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえないし、甲１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。 さらに、本件発明８も、本件発明１の「情報処理方法」について、カテゴリーの異なる「プログラム」とした発明である。 そうすると、本件発明８は、甲１から認定される「プログラム」と対比すると、少なくとも、上記１（１）イ（オ）の［相違点］と同様の相違点を有することとなるから、上記（１）と同様、本件発明８は、甲１に記載された発明であるとはいえない。また、甲１に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえないし、甲１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。 ４ 小括 以上のとおり、本件発明１～４及び６～８は、特許法２９条１項３号に該当せず、特許を受けることができるものである。また、本件発明１～８は、特許法２９条２項の規定により特許を受けることができないとはいえない。 したがって、本件発明１～８に係る特許は、取り消されるべきものではない。 第６ むすび 以上によれば、特許異議の申立ての理由及び申立人の提出した証拠によっては、本件特許の請求項１～８に係る特許を取り消すことはできない。 また、他に本件特許の請求項１～８に係る特許を取り消すべき理由を発見しない。 よって、結論のとおり決定する。