• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部申し立て 1項3号刊行物記載  G06Q
審判 全部申し立て 2項進歩性  G06Q
管理番号 1404852
総通号数 24 
発行国 JP 
公報種別 特許決定公報 
発行日 2023-12-28 
種別 異議の決定 
異議申立日 2023-09-06 
確定日 2023-12-08 
異議申立件数
事件の表示 特許第7233047号発明「情報管理装置及び情報管理方法」の特許異議申立事件について、次のとおり決定する。 
結論 特許第7233047号の請求項1〜8に係る特許を維持する。 
理由 第1 手続の経緯
特許第7233047号(以下、「本件特許」という。)の請求項1〜8に係る特許についての出願は、平成31年3月4日に出願され、令和5年2月24日にその特許権の設定登録がされ、同年3月6日に特許掲載公報が発行された。その後、本件特許に対し、同年9月6日に異議申立人 久門享(以下、「申立人」という。)は、特許異議の申立てを行った。

第2 本件発明
本件特許の請求項1〜8の特許に係る発明は、それぞれ、その特許請求の範囲の請求項1〜8に記載された事項により特定される次のとおりのものである。(以下、それぞれ、「本件発明1」〜「本件発明8」という。なお、請求項1の「1A」〜「1F」は、申立人が特許異議申立書において付した符号である。)
「 【請求項1】
1A 情報処理装置が、
1B ユーザの属性を属性情報として管理する処理と、
1C 前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する処理と、
1D 前記属性変更情報に基づいて前記イベントが発生したか否かを確認するための確認情報を生成する処理と、
1E 前記確認情報を予め設定されたタイミングで所定の情報処理端末に送信する処理と、
1F を実行する情報処理方法。
【請求項2】
前記所定の情報処理端末は、前記ユーザに対応付けられた情報処理端末を含む、請求項1に記載の情報処理方法。
【請求項3】
前記所定の情報処理端末は、前記ユーザに対応付けられたユーザであって、前記ユーザとは異なるユーザに対応付けられた情報処理端末を含む、請求項1または2に記載の情報処理方法。
【請求項4】
前記情報処理装置が、前記確認情報により前記イベントの発生が確認された場合に、前記ユーザの属性を変更する処理をさらに実行する、請求項1〜3のいずれか1項に記載の情報処理方法。
【請求項5】
前記情報処理装置が、前記確認情報に重要度を付与する処理をさらに実行する、請求項1〜4のいずれか1項に記載の情報処理方法。
【請求項6】
前記予め設定されたタイミングは、前記イベントに基づいて決定される、請求項1〜5のいずれか1項に記載の情報処理方法。
【請求項7】
ユーザの属性を属性情報として管理する手段と、
前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する手段と、
前記属性変更情報に基づいて前記イベントが発生したか否かを確認するための確認情報を生成する手段と、
前記確認情報を予め設定されたタイミングで所定の情報処理端末に送信する手段と、
を備える情報処理装置。
【請求項8】
情報処理装置に、
ユーザの属性を属性情報として管理する処理と、
前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する処理と、
前記属性変更情報に基づいて前記イベントが発生したか否かを確認するための確認情報を生成する処理と、
前記確認情報を予め設定されたタイミングで所定の情報処理端末に送信する処理と、
を実行させるためのプログラム。」

第3 申立理由の概要
1 申立人の提出した証拠
申立人は、次の甲第1号証〜甲第8号証(以下、それぞれ「甲1」〜「甲8」という。)を証拠として提出している。
甲第1号証(甲1):米国特許第7937329号明細書
甲第2号証(甲2):特開2016−148907号公報
甲第3号証(甲3):特開2011−141840号公報
甲第4号証(甲4):特開2007−95023号公報
甲第5号証(甲5):特開2002−297847号公報
甲第6号証(甲6):米国特許出願公開第2007/0255609号明細書
甲第7号証(甲7):米国特許出願公開第2008/0059267号明細書
甲第8号証(甲8):特開2001−350884号公報

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

(2)進歩性欠如
本件発明1〜8は、甲1に記載された発明に基づいて、甲1に記載された発明及び周知技術に基づいて、甲2及び甲5に記載された発明に基づいて、又は、甲2及び甲5に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本件発明1〜8についての特許は、特許法29条2項の規定に違反してされたものである。

第4 甲号証の記載
1 甲1(米国特許第7937329号明細書)
甲1には、以下の記載がある。(なお、外国語文献の日本語翻訳文は、申立人の提出した甲1の抄訳を採用し、一部、合議体が変更した。また、下線は、注目箇所に合議体が付した。以下、同様。)
「図1は、コンピュータ装置12と、それの等しいバックアップ用コンピュータ装置12’とを含む、本発明のシステム10の典型的なアーキテクチャ実装を示す。」(第7欄第19〜21行)

「コンピュータ装置12、12’のそれぞれの基本的な構成は、図2に示されている。例示的な一実施形態では、コンピュータ装置12は、中央処理装置(CPU)32、記憶装置34、システムクロック35、ビデオインターフェース36、入力/出力(I/O)インターフェース38、及び通信インターフェース40の各々に直接接続されるバス30を含み得る。」(第7欄第38〜44行)

「システム10がインターフェース層68の任意の構成要素69a、69b、69c、69dを介してアクセスされた後、任意のユーザ要求又は問い合わせが、統合層50に渡され、統合層50は、要求されたユーザアクションを実行するための統合ファシリティ52と、ビジネスアプリケーション層58及びサードパーティ製品層54の加入しているシステムに共通の基本ユーザ情報を維持するための共有データベース51と、ビジネスアプリケーション層58及びサードパーティ製品層54のすべての加入しているシステムが従う共通ルールを備えるビジネスルールデータベース53と、を備える。」(第7欄第63行〜第8欄第5行)

「統合ファシリティ52は、以下に図7を参照して詳細に説明するが、ユーザ/従業員に関する関連情報、例えば、社会保障番号、氏名、住所、生年月日、婚姻歴、子供の氏名などを収集し、共有する。この情報は、ベネフィットパッケージが購入された時に、初期セットアップ中に、統合ファシリティ52を介して各ユーザ/従業員によってシステム10に提供される。」(第10欄第53〜60行)

「ライフイベント
ユーザとシステム10との間のインタラクションは、やり取りがインターネットを介して進行している場合、一般的に使用されている任意のウェブブラウザを使用することによって達成され得、ここで、インターフェース画面が、会社の所有者/雇用者又はマネージャであるユーザに提示される。図5に示されるように、統合ファシリティ52(図3)は、双方向にかつ特定のライフイベントを予期することによって、各契約者にアドバイス及び案内情報84を提供する。さらに、必要なビジネスタスク88のリマインダが提示され、これもまた、任意の数のライフイベントによってトリガされる。ライフイベントの一例は、個人税暦年の終わりを示す12月31日の経過であってもよく、このイベントは、米国における1月31日の締切日に間に合い、4月15日の納税申告日に間に合うように税務書類を発行する必要性を引き起こす。
図3に戻ると、ライフイベントはまた、以下のトリガデータを含み得る:すなわち、顧客のビジネス、従業員、サプライヤ、政府規制、顧客の財務状態、出産、雇用、解雇、ポリシーの変更、及び他のそのようなイベントの情報である。ライフイベントのトリガデータは、顧客によって連続的に提供されてもよい。ライフイベントがアクションをトリガすると、統合ファシリティ52は、加入されたベネフィットパッケージの製品59、55〜57の各々において適切なアクションを開始し、あるいは、実行される必要がある未決定のHR機能に対してユーザ/従業員に警報し得る。」(第11欄第1〜26行)

「ライフイベントを介して自動的に実行されるタスクとは別に、ユーザ/従業員は、特定のタスク86(図5)が実行されること、又はその手動での実行が許可されることを要求し得る。そのようなタスク86(図5)は、給与の支払い、インターフェース68によって表示される会社メッセージの編集、及び会社のカレンダーの編集を含み得る。
例えば、従業員が解雇される場合、雇用者は、この更新情報を統合ファシリティ52に提供する。システム10は、特に、以下のイベントを開始する:給与処理62がベネフィットパッケージ54のための報酬の支払並びに失業及び所得控除を停止する;健康保険給付が終了され、適切なCOBRAの補償が支給される;且つ投資プログラム(退職、401K、利益分配)が変更要求を発行する、など。各ステップにおいて、雇用者又は従業員は、これらの変化を生じさせるため及びこれらの変化が円滑に行われることを確実にするための特定の情報を入力することを求められる。本システムは雇用者に対し、特定の情報を入力するよう促し、再就職支援サービスの開設、特定の福利厚生又は昇進からの従業員の削除の準備など、望まれる追加の行動を提案する。」(第11欄第27〜48行)

「図7(図7a、図7b、および図7cを含む)は、オープンアーキテクチャソース総合システム(OASIS)として知られる統合ファシリティ52(図3)の一実施形態の例示的なフローを示す。OASISは、システム10の他の構成要素と通信するために、分散コンポーネントオブジェクトモデル(DCOM)、Java、および共通オブジェクトリクエストブローカアーキテクチャ(CORBA)をサポートする、構成要素ベースのイベント駆動型技術で構成される。統合ファシリティ52(図3)はHRMS/給与計算59g(図3)及び総勘定元帳59f(図3)を含む重要な製品、並びにいくつかのサードパーティ製品55〜57(図3)を含む重要でない製品を含む。OASISは、開発をより容易にするために、イベント駆動型アクション反応モデル技術を利用して実装され得る。OASISの構成要素は:
(1)イベントトリガエンジンであって:
イベントプロファイル;
特定のイベントの通知を登録するプロセスのサブスクリプション;
イベントとイベント条件;
アクションとアクション条件_アクションプロセスはイベントの結果としてトリガされる;
ルール/ビジネス・入力ルール;
データ変更に基づいてイベントをトリガする時期を決定するための監視;及び
ソース間でデータを変換するためのデータストレージアダプタ
を含むイベントトリガエンジンと、
(2)ビジネスアクションオブジェクトと、
(3)情報源アダプタ/変換ルールとデータと、
(4)データ管理ツールと、
を含む。」(第12欄第42行〜第13欄第4行)

「図15は、イベントという名称のデータレコードについて、Event_Task、Event_Action、及びUser_Eventという関連データレコードがあることを示す。したがって、システムによって認識される各イベントは、ユーザイベント、イベントタスク、及びイベントアクションに関連付けられる。上述のように、システムで認識及び処理されるイベントには、社員の昇給、税年度終了日、婚姻状況の変化、扶養家族数(世帯サイズ)の変化などが含まれる。」(第20欄第6〜14行)





「イベント処理
したがって、システム800は、データストアを更新するためにデータ処理を開始するイベントをトリガすることによって駆動され、したがって、データレイヤを通して要求されたデータを受信するビジネスプロセスが更新された情報を受信することを確実にする。図16は、そのようなトリガイベントに応答するシステムの処理を示すフロー図である。
図16のフロー図のボックス1602によって示される第1の動作では、システムがトリガイベントを検出する。上述のように、トリガイベントは暦年の変化(例えば、税年度の終了を意味する)などの自動的に検出されたイベントであってもよく、又はトリガイベントは、子供の誕生による追加の扶養家族又は(従業員の住所のためのデータストア入力の変化に加えて、州税計算及び他の規制上の調整の変化を必要とし得る)住居の変化などユーザ入力イベントであってもよい。データレイヤの処理は、そのようなトリガイベントの検出及び認識に関与する。
次に、フロー図のボックス1604によって表されるように、システムは、影響を受けるデータレコードを決定する。例えば、データレイヤの処理は従業員が新しい住所を入力したことを検出し、居住地の変化を示し、新たな居住地の状態が、異なる税計算及び医療保険適用範囲の変化などを必要とすることを自動的に決定する。同様に、データレイヤの処理は暦年の末が過ぎたことを検出し、税計算を自動的に開始し、税務書類及び各従業員に提供するために必要な他の文書を自動的に生成する。
場合によっては、システムが従業員から追加の情報を取得する必要があり得る。システムは、フロー図のボックス1606によって示されるように、そのような情報について従業員に自動的に問い合わせる。したがって、ユーザインターフェース画面(図14)の従業員が、報告する追加の扶養家族を有することを示すとき、システムは、その従業員の記録を更新するためにシステムによって必要とされる情報を要求する質問画面を自動的に生成する。例えば、システムは、扶養家族の氏名、年齢、性別、生年月日などを自動的に要求する。図16のフロー図のボックス1608によって表されるように、任意のそのような追加の情報が、システムのデータストアに記憶される。このようにして、システムはトリガイベントによって影響を受けるすべてのデータレコード(テーブル)が最新の状態に保たれるように、データレイヤのデータストアを自動的に更新する。」(第20欄第39行〜第21欄第16行)

2 甲2(特開2016−148907号公報)
(1)甲2の記載
甲2には、以下の記載がある。
「【0007】
本発明の別の態様は、属性情報管理方法である。この方法は、組織または人に関する将来の属性を示す情報であって、所定の記憶領域に格納された組織または人に関する現在の属性を示す現在属性情報への適用タイミングを含む将来属性情報が入力された場合に、入力された将来属性情報を、所定の記憶領域とは異なる記憶領域へ格納するステップと、異なる記憶領域に格納された将来属性情報のうち適用タイミングに至った将来属性情報にしたがって、新たな現在属性情報を所定の記憶領域へ格納するステップと、所定の記憶領域に格納された新たな現在属性情報を所定の外部装置へ提供するステップと、をコンピュータが実行する。」

「【0011】
図1は、実施の形態のID管理システム10の構成を示す。ID管理システム10は、企業の組織や従業員等に関する各種属性情報の管理に係る情報処理システムである。ID管理システム10は、ID管理装置12、人事部システム14、経営企画部システム16、業務部門システム18、連携先システム20で総称されるシステムA用リポジトリ20a、システムB用リポジトリ20b、システムC用リポジトリ20cを備える。これらの各システム・装置は企業のイントラネットで接続される。なお、ID管理装置12に接続される各装置・システムは、社内(社内網内)に構築された装置・システムに限らず、クラウド等、社外に構築された装置・システムであってもよい。
【0012】
ID管理装置12は、企業に設けられた複数の組織や、企業に雇用された複数の社員に関する様々な属性情報を一元的に管理する情報処理装置である。社員に関する属性情報は、社員番号や氏名、所属組織、役職、権限等を含み、またそれらの識別情報であるIDを含む。人事部システム14は、人事部に設置されたPC等の各種装置を含み、人事異動に関する異動情報22をID管理装置12へ送信する。経営企画部システム16は、経営企画部に設置されたPC等の各種装置を含み、組織改編に関する組織改編情報24をID管理装置12へ送信する。」

「【0017】
(第1の実施の形態)
図2は、第1の実施の形態のID管理装置12の機能構成を示すブロック図である。ID管理装置12は、通信部30、制御部32、記憶部34を備える。通信部30は、種々の通信プロトコルにしたがって外部装置との通信処理を実行する。通信対象の外部装置は、ID管理対象の企業内に構築された装置に限らず、クラウド等の企業外に構築された装置も含む。制御部32は、組織や社員に関する属性情報管理のための各種データ処理を実行する。制御部32は、通信部30を介して外部装置とデータを送受する。記憶部34は、制御部32によるデータ処理のための各種データを記憶する記憶領域である。」

「【0019】
記憶部34は、先付データ保持部36、属性リポジトリ38、定義情報保持部44を備える。先付データ保持部36は、人事部システム14から送信された異動情報22、経営企画部システム16から送信された組織改編情報24、業務部門システム18から送信された付加情報26を保持する。以下、異動情報22、組織改編情報24、付加情報26を総称して「先付データ」とも呼ぶ。先付データは、後述の先付属性情報に反映させるべき組織や社員に関する属性情報を含む。
【0020】
属性リポジトリ38は、組織や社員に関する現在・過去・未来の属性情報を保持する。属性リポジトリ38は、先付属性保持部40と現在過去属性保持部42を含む。属性リポジトリ38は、ID管理装置12とは物理的に別の装置・筐体に設けられてもよい。例えば、属性リポジトリ38を備えるリポジトリサーバ(データベースサーバ)がID管理装置12とは別に設けられ、ID管理装置12は、通信網を介してリポジトリサーバの属性リポジトリ38にアクセスしてもよい。
【0021】
現在過去属性保持部42は、組織や社員に関する現在適用中の属性と、過去適用された属性の両方を含む情報(以下「現在過去属性情報」と呼ぶ)を保持する。現在過去属性情報のうち現在の属性情報と過去の属性情報を区別する場合、前者を「現在属性情報」と呼び、後者を「過去属性情報」と呼ぶ。先付属性保持部40は、組織や社員に関する将来の属性を示す情報(以下「先付属性情報」と呼ぶ)を保持する。先付属性情報は、現在は未確定であるが、将来の割当て・付与が予定されている先日付(未来日付)の属性情報である。現在過去属性情報と先付属性情報の具体例は後述する。」

「【0023】
制御部32は、先付データ取得部46、属性情報取込部48、適用処理部50、属性情報提供部54を備える。先付データ取得部46は、人事部システム14、経営企画部システム16、業務部門システム18から送信された先付データを取得し、先付データ保持部36へ格納する。
【0024】
属性情報取込部48は、先付データ保持部36に新たな先付データが格納されたことを検出すると、その先付データが示す組織や社員の属性情報を先付属性情報として先付属性保持部40へ格納する。属性情報取込部48は、1日の予め定められた時刻になったことを契機に、このような先付属性情報取込処理を実行してもよい。
【0025】
図3は、先付属性保持部40に格納される先付属性情報の一例を示す。同図は、先付データとしての異動情報22に基づいて設定された先付属性情報を示している。先付属性情報は、先付データの内容をそのまま転記したものでもよい。先付属性情報は、その属性値を現在属性情報へ反映すべきタイミング(日付、時刻等)を示す適用開始日を含む。具体的に図3の先付属性情報は、12月1日に「野村太郎」がコンサルティング部の部長へ異動となり、12月1日に「野村花子」が退職することを示している。なお、適用開始日は、人事異動や組織改編の発令日が設定されてもよい。」

「【0027】
なお、属性情報取込部48は、所定の削除操作の入力や、所定の削除指示データの受信に応じて、先付属性保持部40に格納済の先付属性情報を削除してもよい。この削除操作や削除指示データでは、削除対象の先付属性情報を特定するためのキー(例えば社員IDと適用開始日の組み合わせ)が指定されてもよい。同様に属性情報取込部48は、所定の更新操作の入力や、所定の更新指示データの受信に応じて、先付属性保持部40に格納済の先付属性情報を更新・変更してもよい。この更新操作や更新指示データでは、更新対象の先付属性情報を特定するためのキーと、属性の更新値が指定されてもよい。このように、先付属性保持部40に格納された先付属性情報は、その適用開始日に至るまでの期間に更新・削除されうる。」

「【0029】
適用処理部50は、先付属性保持部40に格納された先付属性情報のうち適用開始日に到達した先付属性情報にしたがって、新たな現在属性情報を現在過去属性保持部42に格納する適用処理を実行する。適用処理部50は、1日の所定の時刻に到達した場合にバッチ処理として適用処理を実行してもよい。また適用処理部50は、ID管理装置12のOSが管理する現在日付を参照して、適用処理の対象とする先付属性情報を識別してもよい。適用処理部50は、適用開始日に未達の先付属性情報は適用処理の対象外とする。」

「【0049】
第1の実施の形態のID管理装置12では、先付属性情報を保持する先付属性保持部40を、現在過去属性情報を保持する現在過去属性保持部42とは別に設けた。先付属性情報は、適用開始日に至るまでの期間に変更されうる未確定のデータである。現在過去属性保持部42に未確定のデータを入力する場合、現在確定している属性を取得し、また更新することが複雑になってしまう。また未確定の属性を配信してしまうリスクも高まる。ID管理装置12では、確定した属性情報の記憶領域と、未確定の属性情報の記憶領域を明確に区別することで、属性情報管理を安全かつ効率的に実現する。」

「【図3】



(2)甲2発明
上記(1)によれば、甲2には、以下の甲2発明が記載されている。
[甲2発明]
「企業の組織や従業員等に関する各種属性情報の管理に係る情報処理システムであるID管理システム10が備える、ID管理装置12が実行する属性情報管理方法であって、(【0011】)
ID管理装置12は、企業に設けられた複数の組織や、企業に雇用された複数の社員に関する様々な属性情報を一元的に管理する情報処理装置であって、社員に関する属性情報は、社員番号や氏名、所属組織、役職、権限等を含み、またそれらの識別情報であるIDを含み、(【0012】)
ID管理装置12は、制御部32、記憶部34を備え、(【0017】)、
記憶部34は、先付データ保持部36、属性リポジトリ38、定義情報保持部44を備え、(【0019】)
属性リポジトリ38は、組織や社員に関する現在・過去・未来の属性情報を保持するとともに、先付属性保持部40と現在過去属性保持部42を含み、(【0020】)
現在過去属性保持部42は、組織や社員に関する現在適用中の属性である現在属性情報と、過去適用された属性である過去属性情報の両方を含む情報を保持し、先付属性保持部40は、組織や社員に関する将来の属性を示し、現在は未確定であるが、将来の割当て・付与が予定されている先日付(未来日付)の属性情報である先付属性情報を保持し、(【0021】)
制御部32は、先付データ取得部46、属性情報取込部48、適用処理部50、属性情報提供部54を備え、先付データ取得部46は、先付データを取得し、先付データ保持部36へ格納し、(【0023】)
属性情報取込部48は、先付データ保持部36に新たな先付データが格納されたことを検出すると、その先付データが示す組織や社員の属性情報を先付属性情報として先付属性保持部40へ格納し、(【0024】)
先付属性情報は、先付データとしての異動情報22に基づいて設定され、その属性値を現在属性情報へ反映すべきタイミング(日付、時刻等)を示す適用開始日を含み、例えば、12月1日に「野村太郎」がコンサルティング部の部長へ異動となり、12月1日に「野村花子」が退職することを示し、(【0012】、【0025】、【図3】)
適用処理部50は、先付属性保持部40に格納された先付属性情報のうち適用開始日に到達した先付属性情報にしたがって、新たな現在属性情報を現在過去属性保持部42に格納する適用処理を実行する、(【0029】)
ID管理装置12が実行する属性情報管理方法。」

3 甲3(特開2011−141840号公報)
甲3には、以下の記載がある。
「【0024】
図10は、HDD101に格納され、イベント重要度算出プログラムが更新する将来のイベント管理テーブル2である。本テーブルは、CPU105を介してイベント発生時期予測プログラムが管理する将来のイベント管理テーブル1と同様の構成からなる。イベント発生時期予測プログラムによって、イベントが追加された際に、外部入出力装置114がネットワーク117、外部記憶装置115から入力されたユーザのイベントに関連するデータを基に、イベントの重要度を判断し、重要度(1003)の項目を更新する。」

「【0067】
イベント発生時期予測プログラムが推定するイベントの発生予測日は、イベントを忘れないことが主目的であるため正確な日付をユーザに提示する必要はない。例えば、イベントを発生予想時期より早めに通知して、必要があれば正確な日付にユーザが修正するなどとしてもよい。本実施例においては、イベントの発生日時より20日前に通知することとする。よって、通知イベント(902)「父の日」に対するイベント通知予定日(900)は「2009/6/1」となる。以下、図18も参照して説明する。
【0068】
次に、ユーザが作成した入力データ、嗜好管理テーブルから、将来のイベント管理テーブルにて格納されるイベントの重要度を算出し、算出したイベント重要度を基に将来のイベント管理テーブルを更新する(S206) 。イベント重要度を算出し、将来のイベント管理テーブルを更新するまでの処理手順を下記に示す。」

「【0080】
関連情報通知方法例として、はじめにイベントの通知のみを行い、ユーザからの指示があった場合に、関連情報を表示してもよいとする(図13) 。
本実施例において、外部部出力デバイス104へのイベントの通知は、将来のイベント管理テーブル3(図11)が格納するイベント通知予定日(年/月/日)(1100)と一致する日に電源投入されたタイミングでイベントを通知する。イベント通知予定日(年/月/日)(1100)と一致する日に電源投入がなかった場合は、イベント通知予定日以降、一番初めに電源投入された時にイベントを通知することとする。イベント予想発生日を過ぎて電源気投入があった場合は、イベントは通知しないこととする。ただし不可避のイベント等あるものについては設定により予想発生日を過ぎても通知するのも好適である。
【0081】
また、将来のイベント管理テーブル3(図11)が格納する通知イベント(1102)の重要度(1103)が「高」の場合、通知する外部出力デバイスを複数とし、重要度「低」や「中」のものよりもフォントを大きくし、効果音や音楽なども合わせて通知し、再通知間隔も短くするなどとすることで、ユーザに対してイベントの発生を強く通知する。」

4 甲4(特開2007−95023号公報)
甲4には、以下の記載がある。
「【0023】
図2に示すように、スケジュールの重要度に応じて、「非常に重要」の場合、15日前、7日前、3日前、2日前、1日前、当日の定刻午前9時に通知が行われ、「重要」の場合、10日前、5日前、2日前、1日前、当日の定刻午前9時に通知が行われるなど、スケジュールの重要度に応じて最初の通知日及び通知間隔に差があるが、前記最初の通知日、通知時刻、通知間隔などはユーザにより変更可能である。」

「【0027】
図4は本発明の一実施形態によるスケジュール管理方法を示すフローチャートである。
【0028】
図4に示すように、ユーザは、スケジュール登録時、スケジュールの日付、内容、及び重要度のみを入力して保存する(S410)。保存が完了すると、携帯端末機は、所定時間間隔で前記重要度による通知時刻が現在時刻と一致するか否かを判断する(S420)。
【0029】
前記一致するか否かの判断の結果、前記重要度による通知時刻が現在時刻と一致すると、携帯端末機は、音、振動、ランプ、及びスケジュール内容表示などの通知を行って、ユーザに前記スケジュールを想起させる(S430)。」

5 甲5(特開2002−297847号公報)
甲5には、以下の記載がある。
「【0010】この請求項1に記載の発明によれば、スケジュールを構成するいずれかの要素が未確定の状態にある場合、当該スケジュールのパターンから導出される適切な時期になると、その確定がユーザに対して推奨される。」

「【0037】本発明は要約すれば、曖昧なスケジュール、たとえば日時が漠然としか決まっていない、日時は決まったが場所がまだ決まっていないなどといったスケジュールの登録を可能とし、かつ適切な時期になると、未確定の要素の確定をユーザに促したり、あるいは何らかの情報源から要素値を自動的に推定したりして、曖昧なスケジュールの具体化の支援をおこなうものである。」

「【0051】図2に戻り、つぎにスケジュール記憶部201は、スケジュール登録部200により抽出され変換された各要素とその確定/未確定の種別とを、所定の形式のデータベースに保持する機能部である。図3は、スケジュール記憶部201に保持されるデータベースを模式的に示す説明図である。」

「【0073】図2に戻り、つぎに確定時期判定部205は、スケジュール記憶部201に保持された個々のスケジュールの構成要素が、当該スケジュールにつき選定されたパターンにしたがって確定されているかどうか、言い換えれば、スケジュールの具体化がそのパターンに照らして遅延していないかどうかをチェックする機能部である。なお、このチェックは定期的、たとえば毎回の起動時と毎日の始業時のタイミングでおこなうものとする。
【0074】定期チェックのタイミングになると、確定時期判定部205はスケジュールの構成要素のうちまだ確定されていないもの、すなわちその種別が未確定のままとなっている要素について、当該スケジュールの登録日時、予定日時およびパターンからその確定時期を算出する。そして、現在日時がこの確定時期を超えている要素、すなわち確定時期が到来したにもかかわらず未確定の状態にある要素を特定する。」

「【0076】つぎに、スケジュール確定部206は、確定時期になってもまだ確定されていない要素の確定をユーザに促したり、あるいは可能な場合には、何らかの情報源から当該要素の値を推定してユーザに提示することで、その確定を支援したりする機能部である。
【0077】たとえば、8月3日になってもID=2の会議のメンバーが確定されていない場合には、スケジュール確定部206はその推奨ダイアログ表示部206aにより、図7に示すような推奨ダイアログを画面表示して、ユーザによるメンバーの確定を促す。」

「【図3】


図3と段落【0051】によれば、「スケジュール記憶部201」に保持されるスケジュールの「要素」とは、例えば、「内容」や「日時」、「場所」、「メンバー」を表すものである。

「【図7】



6 甲6(米国特許出願公開第2007/0255609号明細書)
甲6には、以下の記載がある。
「[0008]図1は、本発明での使用に適した例示的なコンピュータシステム100の簡略化されたブロック図である。マネージャは、ディスプレイ102を介してReminder of Dates iViewを閲覧することができる。マネージャは、パーソナライゼーションダイアログにアクセスし、入力/出力(I/0)装置104を介して、Reminder of Dates iViewに表示されるべき特定のカテゴリの日付を選択することができる。マネージャは、また、彼の個人カレンダーにも表示されるべき、Reminder of Dates iViewに表示される日付のサブセットを選択することができる。例えば、マネージャは、従業員の契約がいつ終了するかを示すすべての日付、及び一時的労働不能休暇または出産休暇などの従業員による大規模休暇に関するすべての日付が自分のReminder of Dates iViewに表示されることを望み得る。しかしながら、マネージャは、自分の従業員の契約がいつ終了するかを示す日付のみを自分の個人力レンダーに表示することを望み得る。マネージャは、従業員の契約の終了に関する日付のみを自分の個人カレンダーに表示させることを選択できる。マネージャが、I/0装置104を介してReminder of Dates iView及び自身の個人カレンダーに表示されることを望む日付のタイプをそれぞれ選択すると、CPU106は、この要求を日付リマインダモジュール108に渡し得る。日付リマインダモジュール108は、マネージャによって選択された日付のタイプを取り出すために、人的資源データベース110にアクセスし得る。マネージャのアイデンテイティがその従業員に関連付けられているので、日付リマインドモジュール108は、マネージャの従業員に関連付けられた日付のみにアクセスする。日付リマインダモジュール108は選択された日付をCPU106に戻すことができ、CPU106は、この日付を、Reminder of Dates iView及びマネージャの個人カレンダーそれぞれに表示する。
[0009]マネージャは、また、本発明の一つの実施形態によって、自身の個人カレンダーに入力された日付を変更し得る。マネージャが本発明の実施形態によって自分の個人カレンダーに自動的に入力された日付を変更する場合、この変更は、Reminder of Dates iViewに記録された日付、及びバックエンドに位置する人的資源データベース110に維持された日付にも影響を及ぼし得る。例えば、マネージャは、従業員の休暇に対応するすべての日付が彼のカレンダーに表示されることを要求し得る。彼のカレンダー及び彼のReminder of Dates iViewに、従業員Aが日付Xまで出産休暇中であることが入力されてもよい。マネージャはAが日付Yに職場に戻ることを知らされていてもよい。マネージャが彼のカレンダーの日付をXからYに変更する場合、この変更はReminder of Dates iView及びバックエンドシステムに位置する人的資源データベース110にも反映され得る。」

「[0011]図2は、本発明の一つの実施形態のデータフロー図である。この方法は、CPUl06がユーザの個人カレンダー内に特定のタイプのリマインダ日を表示するユーザ要求を検出したときに開始する(ステップ200)。CPU106は、選択された日付のタイプおよび利用者の識別情報に基づいて要求を作成する(ステップ202)。CPU106は要求を日付リマインダモジュール108に渡し、日付リマインダモジュール108は、要求された日付について人的資源データベース110を検索する(ステップ204)。日付リマインダモジュール108は、ユーザの従業員に関連付けられ、ユーザによって選択された日付のタイプからなる応答を作成する(ステップ206)。日付リマインダモジュール108は、応答をCPU106に送信する(ステップ208)。次いで、CPU106は、ユーザの個人カレンダー内の取得された日付をディスプレイ102上に表示する(ステップ210)。」

「[0015]図6Aは、Reminder of Dates iViewと連携して動作するパーソナライゼーションダイアログ600の画像表示である。この表示は、マネージャがReminder of Dates iViewに表示させたいデータのタイプを選択することができるパーソナライゼーションダイアログを示す。この例では、マネージャが選択することができる日付のカテゴリは記念日、誕生日、タスクの監視、およびリマインダ日である。例えば、「日付の監視」は、従業員の試用期間、出産休暇、又は従業員に関する任意の他のイベントの終了であってもよい。「リマインダ日」は、例えば、従業員の試用期間の終了など、マネージャが来たるべきイベントをリマインダされることを望む日であってもよい。この日付は、実際のイベントの前の予め設定された時間であり得る。」

7 甲7(米国特許出願公開第2008/0059267号明細書)
甲7には、以下の記載がある。
「[0002]従業員が新しく雇用されたり社内のある部門から別の部門に転属されたりする場合(議論の目的のため、転属と新規雇用の両方を「従業員の異動」と称する)、従業員を配置し、業務を開始できるようにするために、調整され実行されなければならない多くのタスクが存在する。本開示の目的のために、これらのタスクの実行を従業員の「セットアップ」と称する。例えば、基本リソースは、しばしば、従業員の新しいオフィスの場所で必要とされる、オフィス家具、コンピュータ、電話などである。さらに、セキュリティ認証/アクセスキー及び/又は符号、IDバッジ、コンピュータアカウント、電子メール、電話、携帯電話など、一定のアカウント及び/又はサービスがしばしば、従業員のために設定される必要がある。さらに、一定の訓練が、従業員に適しているか、又は必要であり得る。そのような訓練は、法律によって要求されることさえある。また、ハンディキャップ、TTL(聴力障害者のための電話設備)など、特別なニーズがある従業員もいる。」

「[0023]図2は、そのような方法の例示的な実施形態を示すフローチャートである。図示の例のように、方法は、従業員セットアップに関する1つ又は複数のタスクの実行のための1つ又は複数のタスク要求を含む、従業員のセットアップに関連する入力を収集することを含み得る(ステップ24)。方法は、また、タスク要求をタスク実行者に向けることを含み得る(ステップ26)。」

「[0025]タスク要求は、任意の数の電子通信手段を介してタスク実行者に送信され得る。例えば、いくつかの実施形態では、タスク要求が電子メールを介して送信され得る。代替的又は追加的に、タスク要求は、タスク要求者及び/又は各要求されたタスクのタスク実行者、ならびに監督/管理者など、システム10にアクセスする個人によって見ることができるように、システム10内に記憶され得る。」

「[0029]システム10は、例えば、部門レベルの監督者などのタスク要求者が、システム10を使用して従業員セットアップを開始することができるように構成され得る。監督者は、様々な予め設定されたセットアップスキームから選択することができる。例えば、監督者はセットアップを必要とする従業員が新たな雇用であるか、他の部門からの社内の転属であるか、部門内で異なるオフィス空間に移動するかなどを指定することができ、それによって、従業員によって必要とされるセットアップのタイプに対応するセットアップスキームを選択することができる。人がすでに会社の従業員である転属などのセットアップの場合、システム10は、会社又は部門のデータベースから従業員に関する個人データを取り出すように構成され得る。そのような個人データは、データベース内の従業員の氏名又は従業員番号を取り出すと、システム10内のデータフィールドに自動的に入力することができる。」

「[0035]システム10は、担当するタスク要求が未完了のままである場合、タスク実行者に通知及び/又はリマインダを送信するように構成され得る。そのようなリマインダは、目標期限が近づくにつれて、及び/又は期限が経過した後、予め設定された時期に送信され得る。」

8 甲8(特開2001−350884号公報)
甲8には、以下の記載がある。
「【0003】リマインダ機能は、ユーザがスケジュールイベントを入力した場合に、そのイベントの時刻からある一定時間前もしくはユーザが指定した時間に、ユーザがスケジュールイベントを見落とさないように、ユーザに対して電子メールなどでメッセージを送信する機能である。」

「【0008】
【発明が解決しようとする課題】従来のリマインダ機能では、スケジュールイベントそのものに対するリマインダ通知のみが可能である。しかしながら、スケジュールイベントによっては、そのイベントに向けてあらかじめ他の作業が必要であったり、イベントの後に他の作業が必要な場合がある。例えば、海外旅行に行く場合には、一ヶ月前に航空券やホテルの予約をしたり、三週間前にパスポートの申請をする必要がある。また、車を購入した場合では、購入後に一ヶ月点検、六ヶ月点検などを行わなければならない。ユーザとしては、スケジュールイベントのリマインダのみでなく、関連する作業アイテムなども合わせて通知してくれることが望ましいが、従来のリマインダ機能では上記のような通知は行うことができない。」

「【0012】
【課題を解決するための手段】本発明のスケジュールリマイダシステムは、スケジュールイベントに関連した作業項目を記述したリマインドメッセージとそのメッセージをユーザに通知するタイミングに関する情報との組を1以上保持するテンプレートテーブルをイベントの種別ごとに備え、ユーザが入力したスケジュールイベントとその日時とに基づき対応するイベント種別の前記テンプレートファイルからリマインドメッセージとそのメッセージを通知すべきタイミングに関する情報とを取得し、ユーザが入力したイベント日時とその通知するタイミング情報とからリマインドメッセージを送付すべき時刻を求めるリマインドメッセージ登録手段と、このリマインドメッセージ登録手段で求められた送信時刻に前記リマインドメッセージをユーザに送信するメッセージ送付手段とを備えている。また、前記リマインドメッセージ登録手段で得たメッセージ送信時刻の情報と、前記リマインドメッセージと送信宛先との組み合わせを複数個保持することが可能なメッセージデータベースを備え、前記メッセージ送付手段は、このデータベースを参照して送信宛先のユーザにリマインドメッセージを送信する手段を含むことができる。」

「【0021】本発明第一実施例は本発明の最も基本的な構成および動作を説明するものであり、ユーザがスケジュールイベントのイベント種別とそのスケジュールイベントの日時を指定した場合にスケジュールイベントに関連する作業項目をリマインダメッセージとしてユーザに送付するためのものである。本発明第二実施例は、ユーザがスケジュールイベントのイベント種別を直接指定するのではなく、スケジュールイベントの内容を自由に記述可能とした場合のものである。本発明第三実施例は、リマインドメッセージに広告が含まれる場合に、リマインドメッセージの送付回数に応じて広告課金を行なうためのものである。本発明第四実施例は、リマインドメッセージに元々広告が含まれていない場合でも適切な広告を選択し追加する場合のものである。」

「【0025】(第一実施例)本発明第一実施例では、ユーザがスケジュールイベントのイベント種別(利用するチェックリストのチェックリストID)を直接選択し、スケジュールリマインダシステムは指定されたチェックリストに含まれるメッセージをチェックリストで指定されている時刻に送信する場合のものである。」

「【0027】チェックリストテンプレートファイル2は、イベント種別ごとに異なるファイルとしてシステム側で用意しておき、各ファイルに固有のIDをあらかじめ割り当てておく。各チェックリストテンプレートファイル2には、あるイベント種別において、送信すべきリマインドメッセージとそのメッセージを送信する時刻の組が1個以上記述されている。・・・」

「【0031】メッセージ送信部4は、メッセージデータベース3を参照し、送信時刻がきたリマインドメッセージを送信先アドレスに送信する。本構成では、ユーザがメッセージ送信先アドレスをそれぞれ指定するため、同一のシステムを複数ユーザで利用することが可能である。」

第5 当審における判断
1 甲2に基づく判断
事案に鑑みて、甲2を主引用例とした場合について判断する。

(1)本件発明1について
ア 本件発明1の構成要件1Dの「確認情報」について
本件発明1の構成要件1Dにおける「確認情報」は、「ユーザの属性」を変更させる「イベント」である「属性変更情報」に基づいて、「イベントが発生したか否かを確認するため」の情報であると特定されている。
そして、本件明細書には、「確認情報」の技術的意義について、「情報入力部に属性変更情報が入力されると、イベントが発生したか否かを確認する確認情報を確認情報生成部が生成することから、属性変更情報の入力後のユーザの事情の変更等によって、入力した属性変更情報と入力後のユーザの実情とが異なることとなった場合であっても、確認情報に基づいて、入力した属性変更情報をユーザの実情に合わせて修正することができ」(【0012】)、「効率的かつ適切にユーザの属性を属性情報として管理することができる」(【0013】、【0019】)という効果を奏することが記載されている。
これに対し、申立人は、本件明細書の【0063】及び【0064】の記載を考慮すれば、「確認情報」とは、イベントが実際に発生したか否かをイベント予定日の後に確認する情報のみならず、イベントがこれから実際に発生するか否かをイベント予定日の前に確認する情報も含むと解釈すべきである旨主張する(特許異議申立書56頁)。
しかしながら、申立人の主張する【0063】及び【0064】は、構成要件1Dの「確認情報」について、それがどのような情報であるのかという内容について記載したものではなく、構成要件1Eについて、確認情報を送信(通知)するタイミングが用途に応じて適宜設定することができることを記載したものであるから、申立人の主張する【0063】及び【0064】の記載によって、構成要件1Dの「確認情報」の解釈が変わることはない。
したがって、申立人の主張は採用できない。

イ 対比
本件発明1と甲2発明とを対比する。
(ア)構成要件1A及び構成要件1Fについて
甲2発明の「ID管理装置12」及び「属性情報管理方法」は、以下の相違点を除き、本件発明1の「情報処理装置」及び「情報処理方法」に相当する。

(イ)構成要件1Bについて
甲2発明の「ID管理装置12」は「記憶部34」を備え、当該「記憶部34」が備える「属性リポジトリ38」において、組織や社員に関する現在・過去・未来の属性情報を保持するものであり、「社員に関する属性情報」は「社員番号や氏名、所属組織、役職、権限等」や、「それらの識別情報であるID」を含むものである。そして、甲2発明の「社員」は本件発明1の「ユーザ」に相当するといえるから、甲2発明の「ID管理装置12」が備える「属性リポジトリ38」において、現在・過去・未来の「社員に関する属性情報」を保持する処理は、本件発明1の「ユーザの属性を属性情報として管理する処理」に相当する。

(ウ)構成要件1Cについて
甲2発明の「組織や社員に関する将来の属性を示し、現在は未確定であるが、将来の割当て・付与が予定されている先日付(未来日付)の属性情報である先付属性情報」を保持する「先付属性保持部40」における「先付属性情報」は、「先付データとしての異動情報22に基づいて設定され」、「その属性値を現在属性情報へ反映すべきタイミング(日付、時刻等)を示す適用開始日」を含むものであり、例えば「12月1日に「野村太郎」がコンサルティング部の部長へ異動となり、12月1日に「野村花子」が退職することを示」す情報であるから、甲2発明の「異動情報22に基づいて設定され」る「先付属性情報」で示される退職等の異動は、本件発明1の「前記ユーザに将来的に発生することが予定されているイベント」に相当する。
そして、甲2発明の「ID管理装置12」においては、「適用処理部50」において、「先付属性保持部40に格納された先付属性情報のうち適用開始日に到達した先付属性情報にしたがって、新たな現在属性情報を現在過去属性保持部42に格納する適用処理」が行われるものであるところ、「先付属性保持部40」に保持される「先付属性情報」は、「適用開始日に到達した」ときに「新たな現在属性情報」として「現在過去属性保持部42」に格納されるものであるから、甲2発明の上記適用処理は、本件発明1の「前記ユーザの前記属性を変更させる」処理であるということができる。
そうすると、甲2発明において、「現在過去属性保持部42」の「現在属性情報」を変更させる「先付属性情報」は、本件発明1の「属性変更情報」に相当し、甲2発明の「先付属性保持部40」が上記「先付属性情報」を保持する処理は、本件発明1の「前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する処理」に相当する。

(エ)構成要件1D及び構成要件1Eについて
甲2発明は、本件発明1の構成要件1D及び構成要件1Eに係る処理を実行するものではない(なお、申立人も、特許異議申立書55頁下段において、甲2発明が本件発明1の構成要件1D及び構成要件1Eに係る処理を実行しない点を認めている。)。

(オ)一致点、相違点
以上、(ア)〜(エ)によると、本件発明1と甲2発明とは、以下の一致点、相違点を有する。
[一致点]
「情報処理装置が、
ユーザの属性を属性情報として管理する処理と、
前記ユーザに将来的に発生することが予定されているイベントであって、前記ユーザの前記属性を変更させるイベントを属性変更情報として記憶する処理と、
を実行する情報処理方法。」

[相違点]
本件発明1の「情報処理装置」は、「前記属性変更情報に基づいて前記イベントが発生したか否かを確認するための確認情報を生成する処理」、及び「前記確認情報を予め設定されたタイミングで所定の情報処理端末に送信する処理」を実行するのに対し、甲2発明の「ID管理装置12」は、そのような「確認情報」の生成や送信を行うものではない点。

ウ 相違点に関する検討
(ア)申立人が、甲2発明と組み合わせて進歩性欠如を主張する甲5には、上記第4の5のとおり、「スケジュール記憶部201に保持された個々のスケジュールの構成要素」(【0073】)に関して、「確定時期になってもまだ確定されていない要素の確定をユーザに促したり、あるいは可能な場合には、何らかの情報源から当該要素の値を推定してユーザに提示することで、その確定を支援したりする」(【0076】))ことが記載されている(上記第4の5の【図7】の「推奨ダイアログ」も参照。)。
しかしながら、甲5に記載された「スケジュール記憶部201」に保持されるスケジュールの「要素」は、例えば、【図3】に示されるように、「内容」、「日時」、「場所」及び「メンバー」を表すものであって、これらの要素は「ユーザの属性」ではない。
したがって、甲5に記載された上述の「要素の確定をユーザに促したり」、「当該要素の値を推定してユーザに提示する」ための情報(【図7】の推奨ダイアログの情報)は、本件発明1の「ユーザの属性」を変更させる「イベント」である「属性変更情報」に基づいて、「イベントが発生したか否かを確認するため」の「確認情報」であるとはいえない。
そして、申立人が提出した甲1、甲3、甲4及び甲6〜甲8(上記第4の1、3、4、6〜8参照。)をみても、本件発明1の「確認情報」に相当する構成は記載されておらず、周知技術であるということもできない。
そうすると、本件発明1は、甲2及び甲5に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲2及び甲5に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。

(イ)これに対し、申立人は、甲5には、スケジュールを構成する要素が未確定の状態にある場合に、適切な時期になると未確定要素の確定をユーザに促したりすることによって、曖昧なスケジュールの具体化を支援する技術が開示されているから、甲2発明に甲5に記載された技術を組み合わせることで、当業者であれば、本件発明1に容易に想到することができた旨主張する(異議申立書58〜59頁)。
しかしながら、上記(ア)のとおり、甲5には、本件発明1の「確認情報」に相当する構成は記載されていない。
したがって、申立人の主張は採用できない。

(2)本件発明2〜6について
本件発明2〜6は、本件発明1の構成にさらに構成を付加し、本件発明1を限定したものであるから、上記(1)イ(オ)の[相違点]を有する。
そうすると、上記(1)ウと同様、本件発明2〜6は、甲2及び甲5に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲2及び甲5に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。

(3)本件発明7及び8について
本件発明7は、本件発明1の「情報処理方法」について、カテゴリーの異なる「情報処理装置」とした発明である。
そうすると、本件発明7は、甲2から認定される「ID管理装置12」と対比すると、上記(1)イ(オ)の[相違点]と同様の相違点を有することとなるから、上記(1)ウと同様、本件発明7は、甲2及び甲5に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲2及び甲5に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。
また、本件発明8も、本件発明1の「情報処理方法」について、カテゴリーの異なる「プログラム」とした発明である。
そうすると、本件発明8は、甲2から認定される「プログラム」と対比すると、上記(1)イ(オ)の[相違点]と同様の相違点を有することとなるから、上記(1)ウと同様、本件発明8は、甲2及び甲5に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲2及び甲5に記載された発明並びに周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。

2 甲1に基づく判断
(1)本件発明1について
ア 甲1に記載された事項は、上記第4の1のとおりである。
しかるところ、上記1(1)ウ(ア)のとおり、甲1には、本件発明1の「確認情報」に相当する構成は記載されていない。
そうすると、本件発明1と甲1に記載された発明は、少なくとも、上記1(1)イ(オ)の[相違点]と同じ相違点を有するから、本件発明1は、甲1に記載された発明であるとはいえない。
また、[相違点]に係る構成は、上記1(1)ウのとおり、甲2〜甲8には記載されておらず、周知技術であるということもできないから、本件発明1は、甲1に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえず、甲1に記載された発明及び周知技術に基づいて、容易に発明をすることができたものであるともいえない。

イ これに対し、申立人は、甲1の【図16】に示された実施形態では、トリガイベントが検出されると、システムは、場合によっては従業員にそのイベントに関する追加の情報を自動的に問い合わせ、例えば、従業員に扶養家族が増えるときに、その扶養家族の氏名、年齢、性別、生年月日などを自動的に要求し、このとき、追加の情報の問合せに対して追加の情報が入力されたか否かで、そのイベントが実際に発生したか否かが事実上確認されることになるから、従業員に対する追加の情報の問合せは、「属性変更情報に基づいてイベントが発生したか否かを確認するための確認情報」に相当し、また、甲1の「ビジネスタスク88のリマインダ」についても、イベントがトリガされると提示されるものであるから、「属性変更情報に基づいてイベントが発生したか否かを確認するための確認情報」に相当すると主張する(異議申立書43〜44頁)。
しかしながら、上記1(1)アのとおり、本件発明1の「確認情報」は、「ユーザの属性」を変更させる「イベント」である「属性変更情報」に基づいて、「イベントが発生したか否かを確認するため」の情報であって、上記1(1)アで説示した技術的意義を有するものであるから、申立人の主張する上述の「従業員に対する追加の情報の問合せ」及び「ビジネスタスク88のリマインダ」のいずれとも異なるものである。
また、申立人は、仮に甲1に記載された発明が「イベントが発生したか否かを確認する確認情報」に係る本件発明1の構成と相違するとしても、甲1発明におけるタスクのリマインダを、イベントが発生したか否かを確認するタスクのリマインダ(「属性変更情報に基づいてイベントが発生したか否かを確認するための確認情報」)とすることは、当業者が容易になし得たことであり、甲1発明においてイベントに関する入力を促す際やタスクをリマインドする際に、イベントに関する情報の入力を依頼する表示とするか、イベントの発生を確認する表示とするかは、単なる設計的事項であると主張する(異議申立書44〜47頁)。
しかしながら、上述のとおり、本件発明1の「確認情報」は、甲1発明の「従業員に対する追加の情報の問合せ」及び「ビジネスタスク88のリマインダ」とは異なるから、申立人の主張する相違点の変更が、単なる設計的事項であるということはできない。
したがって、申立人の主張は採用できない。

(2)本件発明2〜6について
本件発明2〜6は、本件発明1の構成にさらに構成を付加し、本件発明1を限定したものであるから、本件発明2〜6と甲1に記載された発明は、少なくとも、上記1(1)イ(オ)の[相違点]と同じ相違点を有する。
そうすると、上記(1)と同様、本件発明2〜4及び6は、甲1に記載された発明であるとはいえない。また、本件発明2〜6は、甲1に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえないし、甲1に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。

(3)本件発明7及び8について
本件発明7は、本件発明1の「情報処理方法」について、カテゴリーの異なる「情報処理装置」とした発明である。
そうすると、本件発明7は、甲1から認定される発明と対比すると、少なくとも、上記1(1)イ(オ)の[相違点]と同様の相違点を有することとなるから、上記(1)と同様、本件発明7は、甲1に記載された発明であるとはいえない。また、甲1に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえないし、甲1に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。
さらに、本件発明8も、本件発明1の「情報処理方法」について、カテゴリーの異なる「プログラム」とした発明である。
そうすると、本件発明8は、甲1から認定される「プログラム」と対比すると、少なくとも、上記1(1)イ(オ)の[相違点]と同様の相違点を有することとなるから、上記(1)と同様、本件発明8は、甲1に記載された発明であるとはいえない。また、甲1に記載された発明に基づいて、当業者が容易に発明をすることができたものであるとはいえないし、甲1に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるともいえない。

4 小括
以上のとおり、本件発明1〜4及び6〜8は、特許法29条1項3号に該当せず、特許を受けることができるものである。また、本件発明1〜8は、特許法29条2項の規定により特許を受けることができないとはいえない。
したがって、本件発明1〜8に係る特許は、取り消されるべきものではない。

第6 むすび
以上によれば、特許異議の申立ての理由及び申立人の提出した証拠によっては、本件特許の請求項1〜8に係る特許を取り消すことはできない。
また、他に本件特許の請求項1〜8に係る特許を取り消すべき理由を発見しない。
よって、結論のとおり決定する。
 
異議決定日 2023-11-30 
出願番号 P2019-038637
審決分類 P 1 651・ 113- Y (G06Q)
P 1 651・ 121- Y (G06Q)
最終処分 07   維持
特許庁審判長 伏本 正典
特許庁審判官 梶尾 誠哉
古川 哲也
登録日 2023-02-24 
登録番号 7233047
権利者 株式会社SmartHR
発明の名称 情報管理装置及び情報管理方法  
代理人 One ip弁理士法人  

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