• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1377053
審判番号 不服2020-4471  
総通号数 262 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-10-29 
種別 拒絶査定不服の審決 
審判請求日 2020-04-03 
確定日 2021-08-12 
事件の表示 特願2015-181312「電子メール管理装置、方法およびプログラム」拒絶査定不服審判事件〔平成29年 3月23日出願公開、特開2017- 58798〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、平成27年9月15日に出願された特願2015-181312号であり、その手続の経緯は、概略、以下のとおりである。

令和元年 5月20日付け:拒絶理由通知
令和元年 7月24日 :意見書の提出
令和元年12月23日付け:拒絶査定
令和2年 4月 3日 :拒絶査定不服審判請求書、手続補正書の提出
令和3年 3月23日付け:拒絶理由通知
令和3年 5年11日 :意見書、手続補正書の提出

第2 本願発明
令和3年5月11日に提出された手続補正書による手続補正によって補正された特許請求の範囲の請求項1(以下、「本願発明」という。)は、以下のとおりである。

「 メールサーバから配送処理中の電子メールを取得するメール取得部と、
期限を表す文字列と期限を表す情報の組み合わせパターンとしてあらかじめ設定された期限文字列パターンに基づいて、前記電子メールの内容から抽出された前記期限文字列パターンから前記期限を表す情報を抽出する期限抽出部と、
前記電子メールが未処理であるか否かを判定するとともに、前記電子メールが他の電子メールに対する返信メールである場合に返信対象となった電子メールが返信により処理済となったか否かを判定する未処理判定部と、
前記未処理であると判定された電子メールを、前記期限を表す情報に対応付けて未処理メールリストに登録し、前記返信対象となった電子メールが処理済であると判定されると、前記未処理メールリストから前記返信対象となった電子メールを削除するとともに、前記未処理であると判定された前記返信メールを、前記期限を表す情報に対応付けて前記未処理メールリストに登録する未処理メールリスト管理部と、
前記未処理メールリストに登録されたメール(未処理メール)のうち、その期限を表す情報に基づいて通知対象の未処理メールを選択し、選択した未処理メールの受信者に対して通知処理を行う未処理メール通知部と、
を備えたメール管理装置。」

第3 拒絶の理由
令和3年3月23日付けで当審が通知した拒絶理由は、次のとおりのものである。

本願発明は、本願の出願前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった以下の引用文献1に記載された発明及び引用文献2ないし4に記載された事項に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない、というものである。

引用文献1:特開2010-218363号公報
引用文献2:特開2011-188245号公報
引用文献3:特開2006-41829号公報
引用文献4:特開2007-249915号公報

第4 引用文献の記載及び引用発明
1 引用文献1について
(1)引用文献1記載事項
引用文献1には、図面とともに、以下の事項が記載されている(下線は、強調のため当審が付した。以下同じ。)。

「【0009】
本発明の目的は、メール送信時に予め設定した期限の前にスケジュール登録されている送信先に対し再周知させるためのリマインドメールを送信でき、また、メール送信時に予め設定した期限の前に返信のなかった送信先に対し返信を催促するためのリマインドメールを送信できる、電子メールリマインダシステムを提供することにある。」

「【0013】
以下、本発明による電子メールリマインダシステムの一実施形態について説明する。
図1は、本発明の一実施形態を例示するシステム構成図である。電子メールリマインダシステムは、送信者端末101及び送信先端末103の各々が、メールサーバ102に接続されていることで、ネットワークを介して個々の端末間でメール送受信ができる仕組みとなっている。また、メールサーバ102には、本発明の種々の処理機能を実現するプログラムが導入されており、これが起動することにより電子メールリマインダサーバ104として機能する。
【0014】
電子メールリマインダサーバ104は、主要機能として、イベント管理部121とスケジュール管理部122を備え、これらの機能の制御下に、データベース(DB)データ格納処理部105、DB検索処理部106、DB更新処理部107の各処理手段が設けられている。
【0015】
電子メールリマインダサーバ104には、送信メール管理DB108と送信者管理DB109が接続されている。メール送信をすると、DBデータ格納処理部105、DB検索処理部106、DB更新処理部107の各処理手段により、これらのDBの追加/更新が行われる。
【0016】
送信者端末101は、入力部として機能し送信メールを作成する。本発明の送信者端末101では、通常のメール作成のための入力画面とは異なる付加情報入力画面が表示される。付加情報入力画面では、送信前に付加情報111として、「スケジュール日程」112、「返信期限」113、「リマインダ日時」114、「管理ID」115を、所定の入力条件に従って入力する。これらの項目は全て’YYYY/MM/DD hh:ss’形式で入力するため、1分単位で日時を指定できるようになっている。また、送信メール管理DB108及び送信者管理DB109へのデータ格納を正しく行うために、「スケジュール日程」112または「返信期限」113を入力した場合、「リマインダ日時」114は必須入力とする。さらに、「スケジュール日程」112と「返信期限」113は、同時に両方を入力することはできず、また「管理ID」115を入力した場合は、その他全ての項目に入力できない仕様とする。
【0017】
これらの付加情報111を添付しない状態でメールが送信されると、電子メールリマインダサーバ104は起動せず、通常どおりにメールが送信される。
【0018】
付加情報111にスケジュール日程112が入力されている場合は、スケジュール日程を再周知するための再周知メールの送信対象となる。付加情報111のうち、返信期限113が入力されている場合は、送信先に対して返信を催促する返信催促メールの送信対象となる。再周知メール及び返信催促メール(これらをまとめて「リマインダメール」と総称する)は、それぞれ「リマインダ日時」114に入力した日時になると送信される。」

「【0020】
付加情報111が添付された状態で送信者端末101から送信メールが送信されると、メールサーバ102に導入されている電子メールリマインダサーバ104が起動する。
この場合、電子イベント管理部121が、メールが送信されたことを検知して、付加情報111を読み取る。
【0021】
電子イベント管理部121は、付加情報111に「スケジュール日程」112または「返信期限」113が入力されている場合は、送信メール管理DB格納処理(後述する図6)、及び送信者管理DB格納処理(後述する図7)を起動する。この処理が終了すると、送信者端末101に対して、当該送信メール用の「管理ID」を本文に記載したメールを送信する。」

「【0023】
さらに、電子イベント管理部121は、送信先端末103から返信メールが返信された場合は、返信FLG更新処理(後述する図8)を起動し、処理が終了したら、送信者端末101に対して当該返信メールを送信する。
【0024】
一方、スケジュール管理部122は、1分ごとに、リマインダメール送信処理(送信先用)(後述する図4)を起動し、対象データが存在する場合、送信先端末103及び送信者端末101にリマインダメールを送信する。
【0025】
また、スケジュール管理部122は、30分ごとに、未返信送信先送付処理(後述する図9)を起動し、対象データが存在する場合、送信者端末101に対し未返信送信先リストを送付する。
【0026】
さらに、スケジュール管理部122は、1時間送信メール管理DB削除処理(後述する図10)を起動し、その後で送信者管理DB削除処理(後述する図11)を起動する機能を備えている。」
(当審注:【0026】において「1時間送信メール管理DB削除処理(後述する図10)を起動し」は、「1時間ごとに、送信メール管理DB削除処理(後述する図10)を起動し」の誤記と認められる。)

「【0027】
図2は、送信メール管理DBのデータ構成を例示したものである。
送信メール管理DBのデータ項目は、「管理ID」201、「送信先メールアドレス」202、「件名」203、「送信日時」204、「スケジュール日程or返信期限」205、「リマインダ日時」206、「返信FLG」207、「スケジュールor返信要」208、「DeleteFLG」209の全部で9項目からなり、キー項目は、「管理ID」201と「送信先メールアドレス」202で一意となるようになっている。」

「【0030】
「スケジュール日程or返信期限」205及び「リマインダ日時」206は、メール送信時の付加情報(図1の符号111)として送られてきたスケジュール日程(図1の符号112)、返信期限(図1の符号113)、リマインダ日時(図1の符号114)をそのまま格納する。リマインダ日時とは、いつリマインダメールを送るかを自由に設定することができるもので、これにより、会議のような直前に思い出したいものは、開始時刻の10分前に設定したり、返信に時間がかかることが予想されるメールであれば、返信期限の半日程度前に設定するなど、臨機応変な対応が可能となる。
【0031】
「返信FLG」207は、送信先からメールの返信が来た場合に’1’(返信済状態)をセットする返信状況を示すフラグであり、送信メール管理DBへのデータの格納時はデフォルトで’0’(未返信状態)が設定される。
「スケジュールor返信要」208は、リマインダメールが再周知メールであるか返信催促メールであるかによってメールのテンプレートを区別するために使用するもので、メール送信時の付加情報(図1の符号111)にスケジュール日程(図1の符号112)が設定されている場合は’S’が、返信期限(図1の符号113)が設定されている場合には’R’が格納される。
「DeleteFLG」は、データを削除してもよくなった時点で’1’(削除可状態)をセットする削除可否状況を示すフラグであり、送信メール管理DBへのデータの格納時はデフォルトで’0’(削除不可状態)が設定される。
送信メール1件のデータ項目毎に個々に更新されるのは、返信フラグ「返信FLG」と削除フラグ「DeleteFLG」の2つのフラグであり、それ以外は、当該データが削除されるまで格納された時の値のままである。」

「【0032】
図3は送信者管理DBのデータ構成を例示したものである。
送信者管理DBのデータ項目は、「管理ID」301、「送信者メールアドレス」302、「スケジュール日程or返信期限」303、「リマインダ日時」304、「スケジュールor返信要」305の全部で5項目からなり、キー項目は、「管理ID」301となっている。
これは、送信者を管理するためのDBであり、送信メール1件を送信すると、1件のデータが追加される仕組みとなっている。データ項目の定義は図2の説明と同様であるため、ここでは省略する。」

「【0033】
図4?図12は、本システムのフロー図となっており、実際の処理概要について図に合わせて説明する。
図4は、送信先にリマインダメールを送信する送信先用リマインダメール送信処理のフロー図である。
先ず、リマインダメール送信処理(送信先用)を開始(ステップ401)する。この機能は、送信メールの付加情報(図1の111)で予め設定したリマインダ日時が到来したら対象者全員に、自動でメールを送信するという機能である。リマインダ日時を分単位で設定できることから、1分ごとに起動するようにスケジュール管理されている。尚、ここで言う対象者とは、再周知メールであれば、メール送信時の送信先全員であり、また返信催促メールであれば、メール送信時のあて先のうち、リマインダ時期を過ぎても返信FLGが’0’(未返信)である送信先となる。つまり、返信催促メールの場合、既に返信が来た送信先メールアドレスにはリマインダメールは送信されないことになる。
【0034】
上記の対象者を抜き出す条件としては、「システム日付+時刻≧送信メール管理DB_リマインダ日時」であること(ステップ402)、「送信メール管理DB_返信FLG=0」であること(ステップ(403)、を全て満たしている必要がある。また、リマインダメールが再周知メールであるか返信催促メールであるかにより、テンプレートを変える必要があることから、送信メール管理DBの「スケジュールor返信要フラグ」が’S’かどうかの判定(ステップ404)を行う。’S’の場合は、再周知メール作成処理を行いかつその対象データの「DeleteFLG」を’1’に更新(ステップ405)する。’R’の場合は、返信催促メール作成処理(ステップ406)を行う。続いて、対象データについての送信メール管理DBの「送信先メールアドレス」あてに、上記ステップ405または406で作成したリマインダメールを送信(ステップ407)し、処理を終了(ステップ408)する。)」

「【0037】
図6は、メール送信時に送信メール管理DBにデータを格納する送信メール管理DB格納処理のフロー図である。
先ず、送信メール管理DB格納処理を開始(ステップ601)する。この処理はイベント管理部により行われ、付加情報付のメールが1件送信されるごとに起動する(ステップ602)仕組みとなっている。また、1通の送信における繰り返し回数はあて先に指定されている送信先メールアドレスの数と同じ回数(ステップ603)となる。
【0038】
先ず、「管理ID」に対し、「件名」と「送信日時」を結合した値をセット(ステップ604)し、「送信先メールアドレス」にはあて先に指定されているアドレスを1つセット(ステップ605)し、「件名」にはメールの件名をセット(ステップ606)し、「送信日時」にはメールの送信日時を秒単位までセット(ステップ607)する。「スケジュール日程or返信期限」には、送信メールの付加情報(図1の111)に記載されているスケジュール日程か返信期限のどちらかをセット(ステップ608)し、「リマインダ日時」にも付加情報に記載されているリマインダ日時をセット(ステップ609)する。「返信FLG」は、メールを送信した後に返信が来たら'1'に更新するものであるため、デフォルトで'0'をセット(ステップ610)する。」

「【0040】
図7は、メール送信時に送信者管理DBにデータを格納する送信者管理DB格納処理のフロー図である。
先ず、送信者管理DB格納処理を開始(ステップ701)する。この処理もイベント管理部にり行われ、付加情報付のメールが1件送信されるごとに起動する(ステップ702)仕組みとなっている。送信者情報を管理するものであるために、送信メール1件に付き、後述する要領でデータが1件追加される。」

「【0042】
図8は、送信メール管理DBの返信FLGを更新する送信FLG更新処理のフロー図である。
先ず、送信FLG更新処理を開始(ステップ801)する。この機能は、既に返信済みのあて先には、返信催促メールを送信しないようにするために送信メール管理DBの「返信FLG」を返信済み’1’に更新する処理である。
【0043】
手順としては、受信メールに付与されている管理IDが送信メール管理DBの「管理ID」であり(ステップ802)、かつ、受信メールの送信者アドレスが送信メール管理DBの「送信先メールアドレス」であること(ステップ803)である条件を満たす場合に、当該受信メールが返信メールであると判断し、送信メール管理DBの「返信FLG」と「DeleteFLG」を’0’から’1’に更新(ステップ804)し、処理を終了(ステップ805)する。」

「【0044】
図9は、返信メールを未だ送信していない送信先のリストを送信者へ送信する未返信送信先リスト送付処理のフロー図である。
先ず、未返信送信先リスト送付処理を開始(ステップ901)する。返信期限を過ぎても返信がなかった送信先のリストを作成し、送信メール毎に1件にまとめ、送信者へ送信する機能である。尚このリストに表示される内容は、送信先メールアドレスのみである。
【0045】
本処理は、スケジュール管理部により行われ、30分ごとに起動される。概要は、「システム日付+時刻≧送信者管理DB_返信期限」であり(ステップ902)、かつ、送信者管理DBの「スケジュールor返信要」が’R’である(ステップ903)のデータの「管理ID」と「送信者メールアドレス」を取り出す(ステップ904)。次に、送信メール管理DBの全てのデータを検索(ステップ905)し、送信者管理DBから取り出した「管理ID」と、送信メール管理DBの「管理ID」が一致(ステップ906)し、かつ、送信メール管理DBの「返信FLG」が’0’のデータを検索(ステップ907)する。該当するデータがある場合は、そのデータの送信メール管理DBの「送信先メールアドレス」をメール本文に記述し、メール本文更新変数に’1’(初期値’0’)を格納し、送信メール管理DBの「DeleteFLG」を’1’に更新(ステップ908)する。1つの「管理ID」で送信メール管理DBの全てのデータを検索し終わった時点(ステップ909)で、メール本文更新変数が1の場合には、そのメール本文のあて先に予め取り出しておいた送信者メールアドレスを設定し、メールを送信(ステップ910)する。」

「【0046】
図10は、送信メール管理DBからデータを削除する送信メール管理DB削除処理のフロー図である。
先ず、送信メール管理DB削除処理を開始(ステップ1001)する。この処理は、スケジュール管理部により行われ、1時間ごとに起動する仕組みとなっている。データが膨大に増えてDB検索に時間が掛かることのないよう、送信メール管理DBの「DeleteFLG」が’1’の場合(ステップ1002)にそのデータを送信メール管理DBから削除(ステップ1003)するようになっている。」

「【0047】
図11は、送信者管理DBからデータを削除する送信者管理DB削除処理のフロー図である。
先ず、送信者管理DB削除処理を開始(ステップ1101)する。これもスケジュール管理部により行われ、送信メール管理DB削除処理(上述の図10)が終了すると起動される仕組みとなっている。これは、1時間ごとに「DeleteFlG」が'1'のデータが削除される送信メール管理DBと、「DeleteFLG」を持たない送信者管理DBの整合性を持たせるための処理である。送信者管理DBの「管理ID」が送信メール管理DBの「管理ID」にない場合(ステップ1102)に、該当するデータを削除(ステップ1103)する。」

「【図1】



「【図2】



「【図3】



「【図4】



「【図6】



「【図7】



「【図8】



「【図9】



「【図10】



「【図11】



(2)引用発明
上記(1)より、引用文献1には、以下の発明(以下、「引用発明」という。)が記載されている。

「 メール送信時に予め設定した期限の前にスケジュール登録されている送信先に対し再周知させるためのリマインドメールを送信でき、また、メール送信時に予め設定した期限の前に返信のなかった送信先に対し返信を催促するためのリマインドメールを送信でき、送信者端末101及び送信先端末103の各々が、メールサーバ102に接続されていることで、ネットワークを介して個々の端末間でメール送受信ができる仕組みとなっている電子メールリマインダシステムにおいて、メールサーバ102に導入されている種々の処理機能を実現するプログラムが起動することにより機能する電子メールリマインダサーバ104であって、
電子メールリマインダサーバ104は、主要機能として、イベント管理部121とスケジュール管理部122を備え、これらの機能の制御下に、データベース(DB)データ格納処理部105、DB検索処理部106、DB更新処理部107の各処理手段が設けられ、
電子メールリマインダサーバ104には、送信メール管理DB108と送信者管理DB109が接続され、
送信者端末101では、通常のメール作成のための入力画面とは異なる付加情報入力画面が表示され、付加情報入力画面では、送信前に付加情報111として、「スケジュール日程」112、「返信期限」113、「リマインダ日時」114、「管理ID」115を、所定の入力条件に従って入力し、「返信期限」113を入力した場合、「リマインダ日時」114は必須入力とし、「スケジュール日程」112と「返信期限」113は、同時に両方を入力することはできず、
これらの付加情報111を添付しない状態でメールが送信されると、電子メールリマインダサーバ104は起動せず、通常どおりにメールが送信され、
付加情報111に返信期限113が入力されている場合は、送信先に対して返信を催促する返信催促メールの送信対象となり、返信催促メール(「リマインダメール」)は、「リマインダ日時」114に入力した日時になると送信され、
付加情報111が添付された状態で送信者端末101から送信メールが送信されると、メールサーバ102に導入されている電子メールリマインダサーバ104が起動し、電子イベント管理部121が、メールが送信されたことを検知して、付加情報111を読み取り、
電子イベント管理部121は、付加情報111に「返信期限」113が入力されている場合は、送信メール管理DB格納処理及び送信者管理DB格納処理を起動し、
電子イベント管理部121は、送信先端末103から返信メールが返信された場合は、返信FLG更新処理を起動し、
スケジュール管理部122は、1分ごとに、リマインダメール送信処理(送信先用)を起動し、対象データが存在する場合、送信先端末103にリマインダメールを送信し、また、30分ごとに、未返信送信先送付処理を起動し、対象データが存在する場合、送信者端末101に対し未返信送信先リストを送付し、さらに、1時間ごとに送信メール管理DB削除処理を起動し、その後で送信者管理DB削除処理を起動する機能を備え、
送信メール管理DBのデータ項目は、「管理ID」201、「送信先メールアドレス」202、「件名」203、「送信日時」204、「スケジュール日程or返信期限」205、「リマインダ日時」206、「返信FLG」207、「スケジュールor返信要」208、「DeleteFLG」209の全部で9項目からなり、キー項目は、「管理ID」201と「送信先メールアドレス」202で一意となるようになっており、
「返信FLG」207は、送信先からメールの返信が来た場合に’1’(返信済状態)をセットする返信状況を示すフラグであり、送信メール管理DBへのデータの格納時はデフォルトで’0’(未返信状態)が設定され、
「スケジュールor返信要」208は、返信期限が設定されている場合には’R’が格納され、
「DeleteFLG」は、データを削除してもよくなった時点で’1’(削除可状態)をセットする削除可否状況を示すフラグであり、送信メール管理DBへのデータの格納時はデフォルトで’0’(削除不可状態)が設定され、
送信者管理DBのデータ項目は、「管理ID」301、「送信者メールアドレス」302、「スケジュール日程or返信期限」303、「リマインダ日時」304、「スケジュールor返信要」305の全部で5項目からなり、キー項目は、「管理ID」301となっており、これは、送信者を管理するためのDBであり、送信メール1件を送信すると、1件のデータが追加される仕組みとなっており、
リマインダメール送信処理(送信先用)の機能は、送信メールの付加情報で予め設定したリマインダ日時が到来したら対象者全員に、自動でメールを送信するという機能であり、対象者とは、返信催促メールであれば、メール送信時のあて先のうち、リマインダ時期を過ぎても返信FLGが’0’(未返信)である送信先となり、既に返信が来た送信先メールアドレスにはリマインダメールは送信されないことになり、
対象者を抜き出す条件としては、「システム日付+時刻≧送信メール管理DB_リマインダ日時」であること、「送信メール管理DB_返信FLG=0」であることを全て満たしている必要があり、送信メール管理DBの「スケジュールor返信要フラグ」が’R’の場合は、返信催促メール作成処理を行い、対象データについての送信メール管理DBの「送信先メールアドレス」あてに、作成したリマインダメールを送信し、
メール送信時に送信メール管理DBにデータを格納する送信メール管理DB格納処理はイベント管理部により行われ、付加情報付のメールが1件送信されるごとに起動する仕組みとなっており、「スケジュール日程or返信期限」には、送信メールの付加情報に記載されているスケジュール日程か返信期限のどちらかをセットし、
メール送信時に送信者管理DBにデータを格納する送信者管理DB格納処理もイベント管理部により行われ、付加情報付のメールが1件送信されるごとに起動する仕組みとなっており、送信メール1件に付きデータが1件追加され、
送信メール管理DBの返信FLGを更新する送信FLG更新処理において、受信メールに付与されている管理IDが送信メール管理DBの「管理ID」であり、かつ、受信メールの送信者アドレスが送信メール管理DBの「送信先メールアドレス」であることである条件を満たす場合に、当該受信メールが返信メールであると判断し、送信メール管理DBの「返信FLG」と「DeleteFLG」を’0’から’1’に更新し、
返信メールを未だ送信していない送信先のリストを送信者へ送信する未返信送信先リスト送付処理は、返信期限を過ぎても返信がなかった送信先のリストを作成し、送信メール毎に1件にまとめ、送信者へ送信する機能であり、
本処理は、「システム日付+時刻≧送信者管理DB_返信期限」であり、かつ、送信者管理DBの「スケジュールor返信要」が’R’であるデータの「管理ID」と「送信者メールアドレス」を取り出し、送信メール管理DBの全てのデータを検索し、送信者管理DBから取り出した「管理ID」と、送信メール管理DBの「管理ID」が一致し、かつ、送信メール管理DBの「返信FLG」が’0’のデータを検索し、該当するデータがある場合は、そのデータの送信メール管理DBの「送信先メールアドレス」をメール本文に記述し、そのメール本文のあて先に予め取り出しておいた送信者メールアドレスを設定し、メールを送信し、
送信メール管理DBからデータを削除する送信メール管理DB削除処理は、スケジュール管理部により行われ、1時間ごとに起動する仕組みとなっており、データが膨大に増えてDB検索に時間が掛かることのないよう、送信メール管理DBの「DeleteFLG」が’1’の場合にそのデータを送信メール管理DBから削除するようになっており、
送信者管理DBからデータを削除する送信者管理DB削除処理もスケジュール管理部により行われ、送信メール管理DB削除処理が終了すると起動される仕組みとなっており、送信者管理DBの「管理ID」が送信メール管理DBの「管理ID」にない場合に、該当するデータを削除する
電子メールリマインダサーバ104。」

2 引用文献2について
引用文献2には、図面とともに、以下の事項が記載されている。

「【0001】
本発明は、メール処理サーバ、制御方法及び制御プログラムに関する。」

「【0041】
依頼テーブル作成処理部401は、新規の依頼メールであると判定した電子メールから処理期限を取得する。例えば、依頼テーブル作成処理部401は、依頼メールのメール本文から、期限を示す語句を検索し、検索結果として得られた語句以降に出現した日付のうち最も未来を示す日付を取得することで、処理期限を取得する。より詳細な一例をあげて説明すると、依頼テーブル作成処理部401は、メール本文から「期限」や「納期」などの語句を検索する。そして、依頼テーブル作成処理部401は、検索結果として得られた語句以降に出現する日付を処理期限として取得する。日付は、例えば、「○○年○月○日」や「YYYY/MM/DD」などの書式で記載される。「○」や「Y」、「M」、「D」には、数字が記載される。」

以上より、引用文献2には、次の技術事項(以下、「引用文献2記載事項」という。)が記載されていると認められる。

「 メール処理サーバにおいて、
依頼メールのメール本文から、期限を示す語句を検索し、検索結果として得られた語句以降に出現した日付のうち最も未来を示す日付を取得することで、処理期限を取得し、
一例では、メール本文から「期限」や「納期」などの語句を検索し、そして、依頼テーブル作成処理部401は、検索結果として得られた語句以降に出現する日付を処理期限として取得し、
日付は、例えば、「○○年○月○日」や「YYYY/MM/DD」などの書式で記載され、「○」や「Y」、「M」、「D」には、数字が記載されること。」

3 引用文献3について
引用文献3には、図面とともに、以下の事項が記載されている。

「【0006】
本発明は、上述の課題に鑑みてなされ、その目的は、回答期限までに返信メールを受け取るために、送信した電子メールに対して回答を促す連絡管理方法、連絡管理システム及び連絡管理プログラムを提供することにある。」

「【0020】
以下、本発明を具体化した一実施形態を図1?図9に基づいて説明する。本実施形態においては、社内で電子メールを用いて連絡を行う場合を想定する。本実施形態の連絡管理システム20には、図1に示すように、ネットワークNを介して、複数の利用者端末が接続されている。この利用者端末は、連絡管理システム20を用いて電子メールにより相手と連絡を取り合う利用者の端末である。この端末は、具体的には、コンピュータ端末であり、ディスプレイ、キーボード及びマウスを備える。ディスプレイは、作成する電子メールの内容などを表示する画面や、処理操作を指示する画面などを表示する。また、キーボードやマウスは、電子メール内容や回答期限、又は送信先のアドレスなどを入力したり、電子メールの送信や受信した電子メールの取得などを行ったりするときに用いられる。本実施形態においては、この利用者端末には、電子メールを送信する送信者が用いる送信者用端末10と、電子メールを受信した受信者が用いる受信者用端末30とがある。
【0021】
連絡管理システム20は、送信者と受信者との間で送受信される電子メールを管理するために用いられるコンピュータシステム(サーバシステム)である。この連絡管理システム20は、管理コンピュータ21を備える。管理コンピュータ21は、図示しないCPU、RAM及びROM等を有し、後述する処理(送信管理段階、期限管理段階及び課金管理段階等を含む処理)を行う。そして、このための連絡管理プログラムを実行することにより、管理コンピュータ21は、送信管理手段、期限管理手段及び課金管理手段等として機能する。この送信管理手段は、送信者アドレスから受信した返信要求メールを、課金対象であることを示して受信者アドレスに送信する。期限管理手段は、メールデータ記憶手段に記録された回答期限を経過しても、受信者アドレスから返信メールを受信していない返信要求メールを特定する。課金管理手段は、返信要求メールの受信者アドレスに基づいて前記評価値データ記憶手段に記録された受信者の利用者残高を特定し、この利用者残高から、前記課金データ記憶手段に基づいて決定された課金額を減算する。
【0022】
また、管理コンピュータ21は、評価値データ記憶手段としての利用者データ記憶部22、メールデータ記憶手段としてのメールデータ記憶部23、課金データ記憶手段としての課金データ記憶部24及び連絡順位データ記憶部25に接続されている。」

「【0026】
一方、メールデータ記憶部23には、図3に示すように、連絡管理システム20が管理する電子メールに関するメールデータ230が記録される。このメールデータ230は、利用者端末である送信者用端末10又は受信者用端末30から電子メールを受信した場合に記録される。このメールデータ230には、管理識別子、送信者アドレス、受信者アドレス、開封期限、回答期限、重要度、課金対象フラグ、メール内容、送信日時、開封日時、返信日時、返信メール管理識別子及び完了フラグに関するデータが含まれる。」

「【0040】
(メール送信処理)
まず、送信者用端末10から電子メールを送信するメール送信処理について、図6を用いて説明する。
【0041】
ここで、送信者用端末10は、まず、電子メールの作成処理を行う(ステップS1-1)。具体的には、送信者は、送信者用端末10のキーボード及びマウスを用いて、電子メールの宛て先である受信者氏名を選択し、電子メールの内容を入力する。また、利用者は、この電子メールの開封期限や回答期限及び重要度を選択する。そして、この電子メールを課金対象とするか否かを選択する。この場合、利用者は、更に送信者用端末10を用いて連絡順位の指示を行なう。この連絡順位の指示には、優先順位、確認項目及び連絡日時に関するデータを含む。
【0042】
そして、電子メールの作成処理を完了してメール送信指示が行われると、送信者用端末10は、作成された電子メールを連絡管理システム20に送信する(ステップS1-2)。このとき、送信者用端末10は、電子メールの宛て先である受信者アドレス、電子メールの内容、開封期限や回答期限、重要度及び課金対象フラグに関するデータとともに、電子メールを送信した送信者アドレスに関するデータを連絡管理システム20に送信する。
【0043】
連絡管理システム20は、受信した電子メールの登録を行う(ステップS1-3)。具体的には、連絡管理システム20の管理コンピュータ21は、受信した電子メールに対して管理識別子を付与し、この管理識別子を含むメールデータ230を生成して、メールデータ記憶部23に記録する。このメールデータ230には、管理コンピュータ21が受信した電子メールに含まれる送信者アドレス、受信者アドレス、開封期限や回答期限、重要度、課金対象フラグ及びメール内容を含める。更に、管理コンピュータ21は、メールデータ230をメールデータ記憶部23に記録した日時を送信日時として記録する。更に、連絡順位データ記憶部25に、連絡順位データ250を記録する。以上により、メール送信処理を完了する。」

「【0049】
そして、選択された電子メールのメール内容データを受け取った受信者用端末30は、ディスプレイにその内容を表示させる。
次に、利用者は、受信者用端末30を用いて返信メールの作成処理を行う(ステップS2-6)。具体的には、受信者の指示に応じて、この受信メール(返信要求メール)に対する返信メールを作成する。
【0050】
そして、受信者により返信メールの送信が指示されると、受信者用端末30は、返信メールを連絡管理システム20に送信する(ステップS2-7)。このとき、受信者用端末30は、この返信メールに、メールの内容の他、この返信メールの起因となった返信要求メールの管理識別子、返信メールを送信する送信者アドレス(すなわち、返信要求メールの受信者アドレス)に関するデータを含める。
【0051】
連絡管理システム20の管理コンピュータ21は、受信した返信メールをメールデータ230に登録する(ステップS2-8)。具体的には、上記ステップS1-3と同様に、管理コンピュータ21は、受信した返信メールに対して管理識別子を付与し、この管理識別子を含むメールデータ230を生成して、メールデータ記憶部23に記録する。そして、管理コンピュータ21は、受信したメールに含まれる送信者アドレス(返信要求メールの受信者アドレス)及びメール内容に関するデータを記録する。また、この返信メールに開封期限や回答期限、重要度が設定されていた場合には、これらのデータも合わせて記録する。更に、管理コンピュータ21は、返信メールをメールデータ記憶部23に記録した日時を送信日時として記録する。
【0052】
更に、管理コンピュータ21は、受信した返信メールに対応する返信要求メールのメールデータ230を更新する(ステップS2-9)。具体的には、管理コンピュータ21は、返信メールに含まれる返信要求メールの管理識別子に基づいて、この返信メールの起因となった返信要求メールのメールデータ230を特定する。そして、管理コンピュータ21は、返信メールの送信日時を、その返信要求メールの返信日時としてメールデータ230に更新記録する。更に、管理コンピュータ21は、返信メールの管理識別子を、その返信要求メールの返信メール管理識別子としてメールデータ230に記録する。以上により、受信メール取得処理を完了する。」

「【0056】
(メール管理処理)
次に、連絡管理システム20におけるメール管理処理について、図9を用いて説明する。このメール管理処理は、所定時間毎に行われる。
【0057】
このメール管理処理において、まず、連絡管理システム20の管理コンピュータ21は、取得したメールデータ230から、完了フラグが記録されていないメールデータ230を抽出する。
【0058】
そして、管理コンピュータ21は、開封期限が経過したかどうかを判断する(ステップS4-1)。具体的には、管理コンピュータ21は、抽出したメールデータ230に記録されている開封期限と現在日時とを比較する。そして、開封期限がまだ経過していない場合(ステップS4-1において「NO」の場合)には、この電子メールに関する処理を終了する。
【0059】
一方、開封期限を経過している場合(ステップS4-1において「YES」の場合)には、管理コンピュータ21は、開封日時がメールデータ230に記録されているか否かを判断する(ステップS4-2)。
【0060】
ここで、開封日時が記録されていない場合(ステップS4-2において「NO」の場合)、すなわち受信者が電子メールを閲覧していない場合には、送信者用端末10に未読の通知を行う(ステップS4-3)。具体的には、管理コンピュータ21は、メールデータ230に記録されている送信者アドレスを用いて、送信者用端末10に対して、「まだ、電子メールが読まれていない」ことを通知するための電子メールを送信する。
【0061】
次に、メールデータ230に課金対象フラグが記録されている場合には、管理コンピュータ21は、電子メールを開封しなかった受信者に対して課金を行う(ステップS4-4)。具体的には、管理コンピュータ21は、メールデータ230の送信日時と回答期限から猶予期間を算出する。そして、この猶予期間とメールデータ230の重要度に基づいて、課金額データ240からこの受信者の課金額を算出する。更に、管理コンピュータ21は、メールデータ230の受信者識別子に基づいて、この電子メールの利用者データ220を取得する。そして、この利用者データ220の利用者残高から、算出した課金額を減算して新たな利用者残高として、受信者の利用者データ220に記録する。
【0062】
次に、管理コンピュータ21は、その電子メールのメールデータ230に完了フラグを記録する(ステップS4-5)。これにより、管理コンピュータ21は、この電子メールの処理を終了する。
【0063】
一方、開封日時が記録されている場合(ステップS4-2において「YES」の場合)、管理コンピュータ21は、回答期限が経過したか否かを判断する(ステップS4-6)。具体的には、管理コンピュータ21は、現在日時と、その電子メールのメールデータ230に記録されている回答期限とを比較する。そして、回答期限を経過していない場合(ステップS4-6において「NO」の場合)には、この電子メールに関する処理を終了する。
【0064】
また、回答期限を経過している場合(ステップS4-6において「YES」の場合)には、管理コンピュータ21は、返信日時が記録されているか否かを判断する(ステップS4-7)。ここで、返信日時が記録されていない場合(ステップS4-7において「NO」の場合)、すなわち返信メールが送信されていない場合には、送信者用端末10に未回答の通知を行う(ステップS4-8)。具体的には、管理コンピュータ21は、メールデータ230に記録されている送信者アドレスを取得し、このメールアドレスに基づいて送信者用端末10に対して、「まだ、回答メールが送信されていない」ことを通知するための電子メールを送信する。
【0065】
ここで、メールデータ230に課金対象フラグが記録されている場合には、管理コンピュータ21は、電子メールの返信を行わなかった受信者に対して課金を行う(ステップS4-9)。具体的には、管理コンピュータ21は、メールデータ230の送信日時と回答期限から猶予期間を算出し、これとメールデータ230の重要度に基づいて、課金額データ240からこの電子メールの課金額を算出する。更に、管理コンピュータ21は、メールデータ230の受信者アドレスに基づいて利用者データ220を取得する。そして、この利用者データ220の利用者残高から、算出した課金額を減算して新たな利用者残高として、受信者の利用者データ220に記録する。
【0066】
次に、管理コンピュータ21は、その電子メールのメールデータ230に完了フラグを記録する(ステップS4-10)。これにより、管理コンピュータ21は、この電子メールに関する処理を終了する。」

「【図1】



「【図3】



「【図6】



「【図7】



「【図9】



以上より、引用文献3には、次の技術事項(以下、「引用文献3記載事項」という。)が記載されていると認められる。

「 回答期限までに返信メールを受け取るために、送信した電子メールに対して回答を促す連絡管理システムであって、
社内で電子メールを用いて連絡を行う場合を想定し、連絡管理システム20には、ネットワークNを介して、複数の利用者端末が接続され、
利用者端末には、電子メールを送信する送信者が用いる送信者用端末10と、電子メールを受信した受信者が用いる受信者用端末30とがあり、
連絡管理システム20は、送信者と受信者との間で送受信される電子メールを管理するために用いられるコンピュータシステム(サーバシステム)であり、連絡管理システム20は、管理コンピュータ21を備え、管理コンピュータ21は、CPU、RAM及びROM等を有し、後述する処理(送信管理段階、期限管理段階及び課金管理段階等を含む処理)を行い、そして、このための連絡管理プログラムを実行することにより、管理コンピュータ21は、送信管理手段、期限管理手段及び課金管理手段等として機能し、
管理コンピュータ21は、メールデータ記憶部23、及び連絡順位データ記憶部25に接続され、
メールデータ記憶部23には、連絡管理システム20が管理する電子メールに関するメールデータ230が記録され、メールデータ230は、利用者端末である送信者用端末10又は受信者用端末30から電子メールを受信した場合に記録され、管理識別子、送信者アドレス、受信者アドレス、開封期限、回答期限、重要度、課金対象フラグ、メール内容、送信日時、開封日時、返信日時、返信メール管理識別子及び完了フラグに関するデータが含まれ、
送信者用端末10は、作成された電子メールを連絡管理システム20に送信し、連絡管理システム20は、受信した電子メールの登録を行い、具体的には、連絡管理システム20の管理コンピュータ21は、受信した電子メールに対して管理識別子を付与し、この管理識別子を含むメールデータ230を生成して、メールデータ記憶部23に記録し、このメールデータ230には、管理コンピュータ21が受信した電子メールに含まれる送信者アドレス、受信者アドレス、開封期限や回答期限、重要度、課金対象フラグ及びメール内容を含め、
受信者用端末30は、返信メールを連絡管理システム20に送信し、連絡管理システム20の管理コンピュータ21は、受信した返信メールをメールデータ230に登録し、具体的には、上記と同様に、管理コンピュータ21は、受信した返信メールに対して管理識別子を付与し、この管理識別子を含むメールデータ230を生成して、メールデータ記憶部23に記録し、この返信メールに開封期限や回答期限、重要度が設定されていた場合には、これらのデータも合わせて記録し、
更に、管理コンピュータ21は、受信した返信メールに対応する返信要求メールのメールデータ230を更新し、具体的には、返信メールに含まれる返信要求メールの管理識別子に基づいて、この返信メールの起因となった返信要求メールのメールデータ230を特定し、返信メールの送信日時を、その返信要求メールの返信日時としてメールデータ230に更新記録し、更に、返信メールの管理識別子を、その返信要求メールの返信メール管理識別子としてメールデータ230に記録し、
管理コンピュータ21は、取得したメールデータ230から、完了フラグが記録されていないメールデータ230を抽出し、現在日時と、その電子メールのメールデータ230に記録されている回答期限とを比較し、回答期限を経過している場合には、返信日時が記録されているか否かを判断し、返信日時が記録されていない場合、すなわち返信メールが送信されていない場合には、送信者用端末10に未回答の通知を行い、具体的には、メールデータ230に記録されている送信者アドレスを取得し、このメールアドレスに基づいて送信者用端末10に対して、「まだ、回答メールが送信されていない」ことを通知するための電子メールを送信する、
連絡管理システム。」

4 引用文献4について
引用文献4には、図面とともに、以下の事項が記載されている。

「【0006】
そこで本発明者は、返信期限付きの電子メールに記載された返信期限と、受信者のスケジュールを参照することによって、実際に受信者が通知を見られるタイミングで返信期限の通知を行う電子メール返信期限通知システムを発明した。」

「【0024】
本発明の電子メール返信期限通知システム1は、発信元から電子メールを受信する電子メールサーバ上で実現されると良いが、それ以外のサーバ、コンピュータ端末で実現されても良い。」

「【0039】
返信期限付き電子メール受信部2で発信元が送信した返信期限付き電子メールを受信すると、返信期限抽出部4は、その返信期限付き電子メールに含まれる「返信期限」に対応する日時の情報を抽出する(S110)。図4に示す返信期限付き電子メールの場合には、その本文において、「返信期限」と記載された部分を検索し、それに対応付けられた日時「1月31日(火)」を返信期限として抽出する。なお返信期限としては日にちのみならず時刻まで設定されていても良い。」

「【0050】
電子メール返信期限通知システム1は、返信期限付き電子メール受信部2と返信期限付き電子メール送信部3と返信期限抽出部4とスケジュール参照部5と確認通知設定部6と確認通知記憶部7と確認通知送信部8と返信メール受信部9と電子メール管理記憶部10と返信メール送信部11とを有している。また電子メール返信期限通知システム1を実現するサーバ(好適には電子メールサーバ)は、スケジュール管理サーバ20と情報の送受信が可能である。」

「【0052】
返信期限付き電子メール受信部2は、発信元が受信者に送信した返信期限付き電子メールを、発信元が利用するコンピュータ端末(発信元端末)又は発信元が利用する電子メールサーバから受信する手段である。また受信した返信期限付き電子メールに関する情報、受信日時、発信元の電子メールアドレス、受信者の電子メールアドレス、件名などを後述する電子メール管理記憶部10に記憶する。
【0053】
確認通知設定部6は、スケジュール参照部5が参照した受信者のスケジュールと、後述する電子メール管理記憶部10に記憶する、受信者が返信期限付き電子メールに対して返信を行う時間帯の情報とに基づいて、返信期限付き電子メール受信部2で受信した返信期限付き電子メールの返信に対する確認通知をいつ行うかの日時を設定する手段である。
【0054】
返信メール受信部9は、返信期限付きの電子メールに対して受信者が返信の電子メール(返信メール)を行った場合に、その返信メールを受信者が利用するコンピュータ端末から受信し、返信メールの受信日時、返信メールの発信元(返信期限付き電子メールの受信者)の電子メールアドレス、返信メールの受信者(返信期限付き電子メールの発信元)の電子メールアドレス、件名などを電子メール管理記憶部10に記憶させる手段である。
【0055】
電子メール管理記憶部10は、返信期限付き電子メールの受信日時、返信期限付き電子メールの発信元の電子メールアドレス、返信期限付き電子メールの受信者の電子メールアドレス、返信メールの受信日時、返信メールの発信元(返信期限付き電子メールの受信者)の電子メールアドレス、返信メールの受信者(返信期限付き電子メールの発信元)の電子メールアドレスなどを記憶する手段である。」

「【0069】
そうすると、上述において確認通知設定部6は、「1月31日の9時から19時30分」、「1月30日の9時から20時」、「1月27日の10時から12時」、「1月27日の15時から18時」までが返信不可の状態であり、最も返信メールの多い時間帯が「11時から13時」であるので、「1月27日13時」が返信不可でない状態で、最も返信を行いやすい日時のうち最も遅い日時であると判定できる。つまり、確認通知設定部6は、返信期限付き電子メールの受信者が返信不可の状態ではなく、返信の最も多い時間帯であって、且つ、実際の返信期限に最も近い日時(或いはその日時から所定時間分早い日時)を確認通知を送信する日時として設定する。そうすると、「1月27日13時」(或いはそれから所定時間早い時刻)を確認通知を送信する日時として設定し、この日時「1月27日13時」と、確認通知を送信する受信者の情報(例えば受信者の電子メールアドレスなど)を確認通知記憶部7に記憶する。
【0070】
そして確認通知送信部8は、確認通知記憶部7に記憶した日時(1月27日13時)が到来すると(S140)、その受信者に対して、電子メールの返信期限があることを通知する(S150)。この際に、電子メールにより通知しても良いし、それ以外の手段、例えば受信者がログインしているコンピュータ端末に対して、ポップアップメッセージ等を表示することによって、通知しても良い。またこの通知には、当該電子メールを表示可能にしても良い。」

「【0073】
このような一連の処理を繰り返すことによって、返信期限付き電子メールの受信者がいつ返信したか、の情報が蓄積されていき、最も良く返信する時間帯の傾向を反映させることが出来る。また複数の受信者に送信された返信期限付き電子メールの返信率、未返信者などを管理することも出来る。」

「【実施例4】
【0076】
また特定の業者などが勝手に返信期限付き電子メールを送信した際に、受信者が無用な返信期限付き電子メールの受信を防ぐために、予め設定された特定の電子メールアドレスから送信された返信期限付き電子メールについては、返信期限付き電子メール送信部が返信期限付き電子メールを受信者に送信しない構成とすることも出来る。また逆に予め設定された特定の電子メールアドレスから送信された返信期限付き電子メールのみを、返信期限付き電子メール送信部が受信者に送信すると共に、確認通知などの処理を実行可能にするように構成することも出来る。」

「【0078】
…(中略)…
【図7】電子メール管理記憶部の一例を示す概念図である。
…(後略)」

「【図6】



「【図7】



以上より、引用文献4には、次の技術事項(以下、「引用文献4記載事項」という。)が記載されていると認められる。

「 返信期限付きの電子メールに記載された返信期限と、受信者のスケジュールを参照することによって、実際に受信者が通知を見られるタイミングで返信期限の通知を行う電子メール返信期限通知システムであって、
電子メール返信期限通知システム1は、発信元から電子メールを受信する電子メールサーバ上で実現されると良いが、それ以外のサーバ、コンピュータ端末で実現されても良く、
返信期限付き電子メール受信部2で発信元が送信した返信期限付き電子メールを受信すると、返信期限抽出部4は、電子メールの本文において、「返信期限」と記載された部分を検索し、それに対応付けられた日時を返信期限として抽出し、
電子メール返信期限通知システム1は、返信期限付き電子メール受信部2と返信期限付き電子メール送信部3と返信期限抽出部4とスケジュール参照部5と確認通知設定部6と確認通知記憶部7と確認通知送信部8と返信メール受信部9と電子メール管理記憶部10と返信メール送信部11とを有し、電子メール返信期限通知システム1を実現するサーバ(好適には電子メールサーバ)は、スケジュール管理サーバ20と情報の送受信が可能であり、
返信期限付き電子メール受信部2は、発信元が受信者に送信した返信期限付き電子メールを、発信元が利用するコンピュータ端末(発信元端末)又は発信元が利用する電子メールサーバから受信する手段であり、受信した返信期限付き電子メールに関する情報、受信日時、発信元の電子メールアドレス、受信者の電子メールアドレス、件名などを後述する電子メール管理記憶部10に記憶し、
確認通知設定部6は、スケジュール参照部5が参照した受信者のスケジュールと、後述する電子メール管理記憶部10に記憶する、受信者が返信期限付き電子メールに対して返信を行う時間帯の情報とに基づいて、返信期限付き電子メール受信部2で受信した返信期限付き電子メールの返信に対する確認通知をいつ行うかの日時を設定する手段であり、
返信メール受信部9は、返信期限付きの電子メールに対して受信者が返信の電子メール(返信メール)を行った場合に、その返信メールを受信者が利用するコンピュータ端末から受信し、返信メールの受信日時、返信メールの発信元(返信期限付き電子メールの受信者)の電子メールアドレス、返信メールの受信者(返信期限付き電子メールの発信元)の電子メールアドレス、件名などを電子メール管理記憶部10に記憶させる手段であり、
電子メール管理記憶部10は、返信期限付き電子メールの受信日時、返信期限付き電子メールの発信元の電子メールアドレス、返信期限付き電子メールの受信者の電子メールアドレス、返信メールの受信日時、返信メールの発信元(返信期限付き電子メールの受信者)の電子メールアドレス、返信メールの受信者(返信期限付き電子メールの発信元)の電子メールアドレスなどを記憶する手段であり、
確認通知設定部6は、返信期限付き電子メールの受信者が返信不可の状態ではなく、返信の最も多い時間帯であって、且つ、実際の返信期限に最も近い日時(或いはその日時から所定時間分早い日時)を確認通知を送信する日時として設定し、確認通知記憶部7に記憶し、
確認通知送信部8は、確認通知記憶部7に記憶した日時が到来すると、その受信者に対して、電子メールの返信期限があることを通知し、この際に、電子メールにより通知しても良いし、それ以外の手段、例えば受信者がログインしているコンピュータ端末に対して、ポップアップメッセージ等を表示することによって、通知しても良く、
このような一連の処理を繰り返すことによって、返信期限付き電子メールの受信者がいつ返信したか、の情報が蓄積されていき、最も良く返信する時間帯の傾向を反映させることが出来、また複数の受信者に送信された返信期限付き電子メールの返信率、未返信者などを管理することも出来、
また特定の業者などが勝手に返信期限付き電子メールを送信した際に、受信者が無用な返信期限付き電子メールの受信を防ぐために、予め設定された特定の電子メールアドレスから送信された返信期限付き電子メールについては、返信期限付き電子メール送信部が返信期限付き電子メールを受信者に送信しない構成とすることも出来、また逆に予め設定された特定の電子メールアドレスから送信された返信期限付き電子メールのみを、返信期限付き電子メール送信部が受信者に送信すると共に、確認通知などの処理を実行可能にするように構成することも出来る、
電子メール返信期限通知システム。」

第5 対比
本願発明と引用発明を対比すると、以下のとおりとなる。

(ア)引用発明は、「送信者端末101及び送信先端末103の各々が、メールサーバ102に接続されていることで、ネットワークを介して個々の端末間でメール送受信ができる仕組みとなっている」、「メールサーバ102に導入されている種々の処理機能を実現するプログラムが起動することにより機能する電子メールリマインダサーバ104」及び「付加情報111が添付された状態で送信者端末101から送信メールが送信されると、メールサーバ102に導入されている電子メールリマインダサーバ104が起動し、電子イベント管理部121が、メールが送信されたことを検知して、付加情報111を読み取り」との構成を備えるため、「メールサーバ102」上で起動される「電子メールリマインダサーバ104」の「電子イベント管理部121」は、「送信者端末101」と「送信先端末103」との間で「配送処理中」の、「付加情報111」が添付された「電子メール」を取得する「メール取得部」として機能するものと理解することができる。
そうすると、引用発明の「電子イベント管理部121」と本願発明の「メールサーバから配送処理中の電子メールを取得するメール取得部」とは、「配送処理中の電子メールを取得するメール取得部」との点において共通する。

(イ)引用発明の「返信期限113」は、返信の「期限を表す情報」といえる。
また、引用発明の「電子イベント管理部121」は、「付加情報111を読み取」る機能を備え、また、「メール送信時に送信メール管理DBにデータを格納する送信メール管理DB格納処理」を行うものであって、当該「送信メール管理DB格納処理」においては、「「スケジュール日程or返信期限」には、送信メールの付加情報に記載されているスケジュール日程か返信期限のどちらかをセット」する機能を備えるものであるから、「電子メール」に添付される「付加情報111」から「返信期限」を抽出する「期限抽出部」として機能するものといえる。
また、本願発明の「電子メールの内容から抽出された前記期限文字列パターン」と、引用発明の「電子メール」に添付される「付加情報111」とは、「電子メールに関連する情報」である点において共通する。
以上から、引用発明の「電子イベント管理部121」と、本願発明の「期限を表す文字列と期限を表す情報の組み合わせパターンとしてあらかじめ設定された期限文字列パターンに基づいて、前記電子メールの内容から抽出された前記期限文字列パターンから前記期限を表す情報を抽出する期限抽出部」とは、「前記電子メールに関連する情報から期限を表す情報を抽出する期限抽出部」である点において共通する。

(ウ)本願明細書の【0028】には、「例えば、未処理判定部13は、メールから期限を表す情報が抽出されたか否かに基づいて、そのメールが未処理であるか否かを判定してもよい。」と記載されていることから、本願発明の「前記電子メールが未処理であるか否かを判定する」ことは、電子メールから期限を表す情報が抽出されたか否かに基づいて判定する場合を含む。
一方、引用発明は、「付加情報111に「返信期限」113が入力されている場合は、送信メール管理DB格納処理及び送信者管理DB格納処理を起動」との構成を備えるから、前記(イ)を参酌すれば、引用発明の「電子イベント管理部121」は、「電子メール」に添付された「付加情報111」から「返信期限」が抽出されたか否かを判定する機能を備えるものといえる。
よって、引用発明の「電子イベント管理部121」は、本願発明の「前記電子メールが未処理であるか否かを判定する」機能を備えるものといえる。

(エ)本願発明は、「返信メールである場合に返信対象となった電子メールが返信により処理済となったか否かを判定する」との構成を含むことから、「処理済」とは、「電子メール」に対して少なくとも「返信」がなされた後の当該「電子メール」の状態を含み、逆に、「未処理」とは、「電子メール」に対して少なくとも「返信」がなされていない当該「電子メール」の状態を含むものと理解することができる。
一方、引用発明は、
「電子イベント管理部121は、送信先端末103から返信メールが返信された場合は、返信FLG更新処理を起動し」、
「「返信FLG」207は、送信先からメールの返信が来た場合に’1’(返信済状態)をセットする返信状況を示すフラグであり、送信メール管理DBへのデータの格納時はデフォルトで’0’(未返信状態)が設定され」及び
「送信メール管理DBの返信FLGを更新する送信FLG更新処理において、受信メールに付与されている管理IDが送信メール管理DBの「管理ID」であり、かつ、受信メールの送信者アドレスが送信メール管理DBの「送信先メールアドレス」であることである条件を満たす場合に、当該受信メールが返信メールであると判断し、送信メール管理DBの「返信FLG」と「DeleteFLG」を’0’から’1’に更新し」
との構成を備えることから、引用発明の「電子イベント管理部121」は、「受信メール」が所定の条件を満たす場合に、「送信先端末103から返信メールが返信された」と判断して、「返信メール」と同じ「管理ID」が付与された「送信メール」の「返信状況を示すフラグ」である「送信メール管理DB」の「返信FLG」を、「送信先からメールの返信が来た」ことを示す「’1’」にセットするものであるから、「送信メール管理DB」に格納された、「付加情報111」に「返信期限」が入力されている「送信メール」に対して「返信」がなされたか否か、すなわち「送信メール」が、本願発明の「処理済」に相当する状態となったか否かを判断する機能を備えているといえる。
よって、引用発明の「電子イベント管理部121」は、本願発明の「前記電子メールが他の電子メールに対する返信メールである場合に返信対象となった電子メールが返信により処理済となったか否かを判定する」機能を備えているといえる。

(オ)前記(ウ)及び(エ)より、引用発明の「電子イベント管理部121」は、前記(イ)で述べた点に加え、本願発明の「前記電子メールが未処理であるか否かを判定するとともに、前記電子メールが他の電子メールに対する返信メールである場合に返信対象となった電子メールが返信により処理済となったか否かを判定する未処理判定部」に相当する構成を含むものである。

(カ)引用発明は、
「付加情報111に「返信期限」113が入力されている場合は、送信メール管理DB格納処理及び送信者管理DB格納処理を起動し」、
「メール送信時に送信メール管理DBにデータを格納する送信メール管理DB格納処理はイベント管理部により行われ、付加情報付のメールが1件送信されるごとに起動する仕組みとなっており、「スケジュール日程or返信期限」には、送信メールの付加情報に記載されているスケジュール日程か返信期限のどちらかをセットし、」
「メール送信時に送信者管理DBにデータを格納する送信者管理DB格納処理もイベント管理部により行われ、付加情報付のメールが1件送信されるごとに起動する仕組みとなっており、送信メール1件に付きデータが1件追加され、」
「これは、送信者を管理するためのDBであり、送信メール1件を送信すると、1件のデータが追加される仕組みとなっており」、
「1時間ごとに送信メール管理DB削除処理を起動し、その後で送信者管理DB削除処理を起動する機能を備え」
及び「送信者管理DBからデータを削除する送信者管理DB削除処理もスケジュール管理部により行われ、送信メール管理DB削除処理が終了すると起動される仕組みとなっており、送信者管理DBの「管理ID」が送信メール管理DBの「管理ID」にない場合に、該当するデータを削除する」
との構成を備えることから、「送信メール管理DB」と「送信者管理DB」はいずれも、送信者端末が送信した、添付された「付加情報111」に「返信期限」が入力されている「電子メール」(送信メール)に関する情報(以下、単に「管理情報」という。)を管理し、かつ、「管理ID」によって紐付けられて一体となったデータベースであって、かつ、引用文献1の【図2】及び【図3】を参照すると、「リスト」といい得るものである。
そして、前記(ウ)及び(エ)を参酌すると、引用発明において、「付加情報111」に「返信期限」が入力されていると判定された「電子メール」(送信メール)は、本願発明の「未処理であると判定された電子メール」に相当し、引用発明の「送信メール管理DB」及び「送信者管理DB」は、本願発明の「未処理メールリスト」に相当し、引用発明の「電子イベント管理部121」が、「付加情報111」に「返信期限」が入力されていると判定された「電子メール」(送信メール)の管理情報を「送信メール管理DB」と「送信者管理DB」に格納し、特に「返信期限」を「送信者管理DB」に格納することは、本願発明の「前記未処理であると判定された電子メールを、前記期限を表す情報に対応付けて未処理メールリストに登録」する処理に相当する。
よって、引用発明の「電子イベント管理部121」は、前記(イ)及び(オ)で述べた点に加え、本願発明の「前記未処理であると判定された電子メールを、前記期限を表す情報に対応付けて未処理メールリストに登録し、前記返信対象となった電子メールが処理済であると判定されると、前記未処理メールリストから前記返信対象となった電子メールを削除するとともに、前記未処理であると判定された前記返信メールを、前記期限を表す情報に対応付けて前記未処理メールリストに登録する未処理メールリスト管理部」と、「前記未処理であると判定された電子メールを、前記期限を表す情報に対応付けて未処理メールリストに登録する手段」との点において共通する。

(キ)前記(エ)を参酌すると、「送信メール管理DB」の「返信FLG」が「’1’」であることをもって「送信先からメールの返信が来た」こと、即ち、「(送信)メール」が「処理済」であることを判定することができる。
さらに、引用発明は、
「送信メール管理DBの返信FLGを更新する送信FLG更新処理において、受信メールに付与されている管理IDが送信メール管理DBの「管理ID」であり、かつ、受信メールの送信者アドレスが送信メール管理DBの「送信先メールアドレス」であることである条件を満たす場合に、当該受信メールが返信メールであると判断し、送信メール管理DBの「返信FLG」と「DeleteFLG」を’0’から’1’に更新し、」及び
「「DeleteFLG」は、データを削除してもよくなった時点で’1’(削除可状態)をセットする削除可否状況を示すフラグであり、送信メール管理DBへのデータの格納時はデフォルトで’0’(削除不可状態)が設定され、」
との構成を備える。これらの構成によれば、「返信FLG」が「’1’」に更新される際には、「DeleteFLG」も「’1’」に更新され、「付加情報111」に「返信期限」が入力されていると判定された「電子メール」(送信メール)の管理情報のうち、「DeleteFLG」が「’1’」であるものは、削除可能なものといえる。
そして、引用発明は、
「スケジュール管理部122は、1分ごとに、リマインダメール送信処理(送信先用)を起動し、対象データが存在する場合、送信先端末103にリマインダメールを送信し、また、30分ごとに、未返信送信先送付処理を起動し、対象データが存在する場合、送信者端末101に対し未返信送信先リストを送付し、さらに、1時間ごとに送信メール管理DB削除処理を起動し、その後で送信者管理DB削除処理を起動する機能を備え」
「送信メール管理DBからデータを削除する送信メール管理DB削除処理は、スケジュール管理部により行われ、1時間ごとに起動する仕組みとなっており、データが膨大に増えてDB検索に時間が掛かることのないよう、送信メール管理DBの「DeleteFLG」が’1’の場合にそのデータを送信メール管理DBから削除するようになっており、」及び
「送信者管理DBからデータを削除する送信者管理DB削除処理もスケジュール管理部により行われ、送信メール管理DB削除処理が終了すると起動される仕組みとなっており、送信者管理DBの「管理ID」が送信メール管理DBの「管理ID」にない場合に、該当するデータを削除する」
との構成を備えることから、引用発明の「スケジュール管理部122」は、「送信メール管理DB」の「DeleteFLG」が「’1’」であると判定された「電子メール」(送信メール)の管理情報を「送信メール管理DB」及び「送信者管理DB」から削除する機能を備えるものといえる。そして、「電子メール」(送信メール)の管理情報を「送信メール管理DB」及び「送信者管理DB」から削除することは、「電子メール」(送信メール)自体をこれらのDBから削除することに他ならない。
よって、前記(ウ)、(エ)及び(カ)を参酌すると、引用発明において、「スケジュール管理部122」が、「送信メール管理DB」の「DeleteFLG」が「’1’」であると判定された「電子メール」(送信メール)の管理情報を「送信メール管理DB」及び「送信者管理DB」から削除することは、本願発明の「前記返信対象となった電子メールが処理済であると判定されると、前記未処理メールリストから前記返信対象となった電子メールを削除する」処理に相当する。
したがって、引用発明の「スケジュール管理部122」と、本願発明の「前記未処理であると判定された電子メールを、前記期限を表す情報に対応付けて未処理メールリストに登録し、前記返信対象となった電子メールが処理済であると判定されると、前記未処理メールリストから前記返信対象となった電子メールを削除するとともに、前記未処理であると判定された前記返信メールを、前記期限を表す情報に対応付けて前記未処理メールリストに登録する未処理メールリスト管理部」とは、「前記返信対象となった電子メールが処理済であると判定されると、前記未処理メールリストから前記返信対象となった電子メールを削除する手段」との点において共通する。

(ク)引用発明は、
「「スケジュールor返信要」208は、返信期限が設定されている場合には’R’が格納され、」、
「スケジュール管理部122は、1分ごとに、リマインダメール送信処理(送信先用)を起動し、対象データが存在する場合、送信先端末103にリマインダメールを送信し、」及び
「リマインダメール送信処理(送信先用)の機能は、送信メールの付加情報で予め設定したリマインダ日時が到来したら対象者全員に、自動でメールを送信するという機能であり、対象者とは、返信催促メールであれば、メール送信時のあて先のうち、リマインダ時期を過ぎても返信FLGが’0’(未返信)である送信先となり、既に返信が来た送信先メールアドレスにはリマインダメールは送信されないことになり、
対象者を抜き出す条件としては、「システム日付+時刻≧送信メール管理DB_リマインダ日時」であること、「送信メール管理DB_返信FLG=0」であることを全て満たしている必要があり、送信メール管理DBの「スケジュールor返信要フラグ」が’R’の場合は、返信催促メール作成処理を行い、対象データについての送信メール管理DBの「送信先メールアドレス」あてに、作成したリマインダメールを送信し、」、
との構成を備えることから、引用発明の「スケジュール管理部122」は、「送信メール管理DB」及び「送信者管理DB」に登録された、「返信期限」が設定されている「送信メール」であって、「送信メール管理DB_返信FLG=0」であるもののうち、「リマインダ日時」に基づいて「リマインダメール」の対象となる電子メールを選択して、選択した電子メールの「送信先メールアドレス」(送信先端末103)に対して「リマインダメール」(返信催促メール)を送信する「リマインダメール送信処理」を実施するものといえる。
ここで、引用発明の「送信メール管理DB」及び「送信者管理DB」に登録された、「返信期限」が設定されている「送信メール」であって、「送信メール管理DB_返信FLG=0」であるものは、本願発明の「前記未処理メールリストに登録されたメール(未処理メール)」に相当し、引用発明の「リマインダメール」の対象として選択された電子メールは、本願発明の「通知対象の未処理メール」に相当し、引用発明の「送信先メールアドレス」(送信先端末103)は、本願発明の「選択した未処理メールの受信者」に相当し、また、引用発明において、「リマインダメール」(返信催促メール)を送信することは、本願発明の「通知処理を行う」ことに相当する。
また、引用発明の「リマインダ日時」と本願発明の「その期限を表す情報」とは、「所定の時間情報」である点で共通する。
以上より、引用発明の「スケジュール管理部122」と、本願発明の「前記未処理メールリストに登録されたメール(未処理メール)のうち、その期限を表す情報に基づいて通知対象の未処理メールを選択し、選択した未処理メールの受信者に対して通知処理を行う未処理メール通知部」とは、「前記未処理メールリストに登録されたメール(未処理メール)のうち、所定の時間情報に基づいて通知対象の未処理メールを選択し、選択した未処理メールの受信者に対して通知処理を行う未処理メール通知部」との点において共通する。

(ケ)引用発明において、「電子イベント管理部121」及び「スケジュール管理部122」を備える「電子メールリマインダサーバ104」は、メールサーバ上でプログラムが起動することにより実現されるものであり、電子メールを管理する「メール管理モジュール」といい得るものの、「装置」ではない。
よって、引用発明の「電子メールリマインダサーバ104」と本願発明の「メール管理装置」とは、「メール管理モジュール」である点において共通する。

したがって、本願発明と引用発明とは、以下の点で一致ないし相違する。

[一致点]
「 配送処理中の電子メールを取得するメール取得部と、
前記電子メールに関連する情報から期限を表す情報を抽出する期限抽出部と、
前記電子メールが未処理であるか否かを判定するとともに、前記電子メールが他の電子メールに対する返信メールである場合に返信対象となった電子メールが返信により処理済となったか否かを判定する未処理判定部と、
前記未処理であると判定された電子メールを、前記期限を表す情報に対応付けて未処理メールリストに登録する手段と、
前記返信対象となった電子メールが処理済であると判定されると、前記未処理メールリストから前記返信対象となった電子メールを削除する手段と、
前記未処理メールリストに登録されたメール(未処理メール)のうち、所定の時間情報に基づいて通知対象の未処理メールを選択し、選択した未処理メールの受信者に対して通知処理を行う未処理メール通知部と、
を備えたメール管理モジュール。」

[相違点]
<相違点1>
「メール取得部」が、本願発明は「メールサーバ」からメールを取得するものであるのに対し、引用発明の「電子メールリマインダサーバ104」は、「メールサーバ102」上で起動されるものであるため、その「電子イベント管理部121」は、「メールサーバ」からメールを取得するものとはいえない点。

<相違点2>
「期限抽出部」が抽出する「期限を表す情報」について、本願発明は、「期限を表す文字列と期限を表す情報の組み合わせパターンとしてあらかじめ設定された期限文字列パターンに基づいて、前記電子メールの内容から抽出された前記期限文字列パターン」から抽出されるのに対し、引用発明は、電子メールに添付される「付加情報111」から抽出される点。

<相違点3>
「登録する手段」及び「削除する手段」が、本願発明においてはいずれも「未処理メールリスト管理部」であるのに対し、引用発明においては、それぞれ「電子イベント管理部121」と「スケジュール管理部122」との異なる手段である点。

<相違点4>
本願発明は、「前記未処理であると判定された前記返信メールを、前記期限を表す情報に対応付けて前記未処理メールリストに登録する未処理メールリスト管理部」との構成を備えるのに対し、引用発明は、当該構成について特定するものではない点。

<相違点5>
「未処理メール通知部」において「未処理メールを選択」する際の基礎となる「所定の時間情報」が、本願発明は、「期限を表す情報」であるのに対し、引用発明は、電子メールの送信者が入力し、当該電子メールに添付される「付加情報111」に含まれる「リマインダ日時」であって、「返信期限113」ではない点。

<相違点6>
「メール管理モジュール」が、本願発明では、「メール管理装置」であるのに対し、引用発明では、メールサーバ上でプログラムが起動することにより実現される「電子メールリマインダサーバ104」である点。

第6 判断
1 相違点についての判断
以下、上記各相違点について、検討する。

(1)相違点2について
引用文献2記載事項は、電子メールから処理期限を取得するにあたり、メール本文から「期限」や「納期」などの語句を検索し、検索結果として得られた語句以降に出現する日付を処理期限として取得し、日付は、例えば、「○○年○月○日」や「YYYY/MM/DD」などの書式で記載されるものである。そして、引用文献2記載事項において、電子メールの本文(内容)から、「期限」や「納期」といった語句は、「期限を表す文字列」といい得るものであり、当該語句以降に出現する「○○年○月○日」や「YYYY/MM/DD」などの書式は、「期限を表す情報」といい得るものである。さらに、「パターン」とは、型、類型といった意味であるから、「期限を表す文字列」の以降に「期限を表す情報」が出現する、という類型は、「期限を表す文字列」と「期限を表す情報」との「組み合わせ」の「パターン」(「組み合わせパターン」)といい得るものである。また、引用文献2記載事項においては、このような「組み合わせパターン」があらかじめ設定されていることは自明である。
そして、引用文献2記載事項のように、「期限を表す文字列と期限を表す情報」の「あらかじめ設定された」「組み合わせパターン」に基づいて、電子メールの内容から当該「組み合わせパターン」に適合する「期限を表す文字列」と「期限を表す情報」との組み合わせ、すなわち「期限文字列パターン」を抽出し、当該抽出された「期限文字列パターン」から「期限を表す情報」を抽出することは、本願出願時の周知技術といえる。
よって、引用発明に当該周知技術を適用して、引用発明において、電子メールに添付される「付加情報111」に替えて、又はこれに加えて、期限を表す文字列と期限を表す情報の組み合わせパターンとしてあらかじめ設定された期限文字列パターンに基づいて、前記電子メールの内容から抽出された前記期限文字列パターンから期限を表す情報を抽出する構成(相違点2に係る本願発明の構成)を採用することは、当業者にとって容易なことである。

(2)相違点3について
同じシステム内で実施する複数の処理をどの機能手段で実現するかは種々の事項を考慮して当業者が適宜に配分すればよい事項にすぎず、引用発明において、登録する処理と削除する処理とを同じ手段(未処理メールリスト管理部)で実現するように構成を変更することは当業者が適宜になし得ることにすぎない。
よって、引用発明において、相違点3に係る本願発明の構成を採用することは、当業者によって容易なことである。

(3)相違点4について
引用文献3記載事項に「受信者用端末30は、返信メールを連絡管理システム20に送信し、連絡管理システム20の管理コンピュータ21は、受信した返信メールをメールデータ230に登録し、具体的には、上記と同様に、管理コンピュータ21は、受信した返信メールに対して管理識別子を付与し、この管理識別子を含むメールデータ230を生成して、メールデータ記憶部23に記録し、この返信メールに開封期限や回答期限、重要度が設定されていた場合には、これらのデータも合わせて記録し」とあるように、回答期限までに返信メールを受け取るために、送信した電子メールに対して回答を促すシステムにおいて、送信側から受信した電子メールのみならず、受信側から電子メール(返信メール)を受信した場合においても、当該電子メールに関するメールデータを記録し、かつ、返信メールに回答期限が設定されていた場合には、これらのデータも合わせて記録することにより、当該返信メール自体が回答を要求する電子メールである場合にもその処理状況を管理できるようにすることは本願出願時の周知技術である。
よって、引用発明に当該周知技術を適用し、返信メールについても期限を表す情報に対応付けて「送信メール管理DB」及び「送信者管理DB」(未処理メールリスト)に登録、管理するようにして、相違点4に係る本願発明の構成を付加することは当業者にとって容易なことである。

(4)相違点5について
引用文献4記載事項にあるように、「返信期限付きの電子メールに記載された返信期限と、受信者のスケジュールを参照することによって、実際に受信者が通知を見られるタイミングで返信期限の通知を行う電子メール返信期限通知システム」において、「返信期限付き電子メールの受信者が返信不可の状態ではなく、返信の最も多い時間帯であって、且つ、実際の返信期限に最も近い日時(或いはその日時から所定時間分早い日時)を確認通知を送信する日時として設定」すること、すなわち、返信期限(期限を表す情報)に基づいて、受信者に対して返信期限の通知を行うことは、本願出願時の周知技術である。
よって、引用発明に当該周知技術を適用して、「付加情報111」に含まれる「リマインダ日時」に替えて又はこれに加えて「返信期限113」に基づいて「リマインダメール」を送信するよう構成することにより、相違点5に係る本願発明の構成を想到することは当業者にとって容易なことである。

(5)相違点1及び6について
引用文献4記載事項に「電子メール返信期限通知システム1は、発信元から電子メールを受信する電子メールサーバ上で実現されると良いが、それ以外のサーバ、コンピュータ端末で実現されても良く」とあるように、メールサーバ上で実現されるシステムを、それ以外のサーバ、コンピュータ端末等の装置により実現することは、本願出願時の周知技術である。
よって、引用発明に当該周知技術を適用して、「電子メールリマインダサーバ104」をメールサーバとは別の装置(メール管理装置)として実現し、相違点6に係る本願発明の構成を想到することは当業者にとって容易なことである。
そして、「電子メールリマインダサーバ104」を「メールサーバ102」とは別の装置(メール管理装置)として実現する構成を採用すると、「電子メールリマインダサーバ104」の「電子イベント管理部121」は、「メールサーバから配送処理中の電子メールを取得する」ものとなり、相違点1に係る本願発明の構成となる。

また、上記の各相違点に係る本願発明の構成を採用することによる効果も当業者が容易に予測し得る範囲のものにすぎない。

2 請求人の主張について
請求人は、令和3年5月11日に提出した意見書(第2ページ)において、
「 引用文献2の手法では、期限を示す語句以降に現れる日付であれば、期限と関係のない日付であっても処理期限として取得される可能性があります。そのため、引用文献2の手法では、期限管理とは全く関係のない日時に、リマインドメールが送信され、返信する側にとっては余計なことが増える可能性があります。
それに対し、補正後の本願請求項では、「期限を表す文字列と期限を表す情報の組み合わせパターンとしてあらかじめ設定された期限文字列パターンに基づいて、電子メールの内容から抽出された期限文字列パターンから前記期限を表す情報を抽出」します。そのため、補正後の本願請求項によれば、期限を表す文字列に関係の無い日時にリマインドメールが送信されることはありません。そのため、補正後の本願請求項によれば、返信が必要なメールがある場合、的確なタイミングで返信側の利用者に通知することができます。
以上のように、補正後の本願請求項は、返信する側の期限管理が徹底されることによって、返信期限付きのメールの送信側および受信側の双方の利用者の処理期限管理を支援することができるという、引用文献1-7を如何様に組み合わせても得ることのできない効果を奏するものであるため、引用文献1-7に対して進歩性を有するものであると信じます。」
と主張している。(なお、当該主張における下線は、審判請求書において請求人が付したものである。)
しかしながら、本願発明の「期限を表す文字列と期限を表す情報の組み合わせパターンとしてあらかじめ設定された期限文字列パターン」は、「期限を表す文字列」と「期限を表す情報」の「組み合わせ」である「パターン」であれば足りるから、引用文献2記載事項にある、期限を表す語句の後に日付が出現するという「パターン」も含まれるため、請求人の主張は、請求項1の記載に基づくものではなく、採用することができない。
なお、仮に、請求人の主張を採用するとしても、請求人は、本願発明の「期限を表す文字列と期限を表す情報の組み合わせパターンとしてあらかじめ設定された期限文字列パターン」としていかなるものを想定しているのか具体的ではないため、本願明細書の記載を参酌することとする。
そして、本願明細書の【0026】には、「期限文字列パターン」に関し、次の記載がある。
「期限文字列パターンとしては、例えば、「{期限}締切」、「締切{期限}」、「{期限}〆」、「〆{期限}」等を登録しておく。この場合、{期限}は、「YYYY/MM/DD hh:mm:ss」や「YYYY年MM月DD日 hh時mm分ss秒」に合致する文字列を表していてもよい。なお、「YYYY」は、4桁の西暦年を表す文字列であり、「MM」は2桁の月を表す文字列であり、「DD」は、2桁の日付を表す文字列である。また、「hh」は2桁の時間を表す文字列であり、「mm」は2桁の分を表す文字列であり、「ss」は2桁の秒を表す文字列である。」
上記明細書の記載によれば、「期限文字列パターン」は、「期限を表す文字列」である「閉切」、「〆」といった文字列と、「期限を表す情報」({期限})である「YYYY/MM/DD hh:mm:ss」や「YYYY年MM月DD日 hh時mm分ss秒」に合致する文字列とが前後に連結した「パターン」と理解することができる。
しかしながら、本願の出願前である平成10年3月10日に公開された特開平10-69472号公報(以下、「周知文献1」という。)には、「期限情報パタン」を保持しておき、電子メール本文において、「期限情報パタン」にマッチする表現から期限時刻を抽出する文書処理装置(【0041】?【0043】)において、「期限情報パタン」の例として、以下の【図5】が記載されている。

「【図5】


上記【図5】の記載によれば、「期限情報パタン」は、「期限を表す文字列」(「返事は」「回答は」等)と、「期限を表す情報」(<期限時刻>)とが前後連結したパターンといえるから、「期限を表す文字列」と「期限を表す情報」とが前後に連結したパターンを使用して、電子メール本文から「期限を表す情報」を抽出することは、本願出願時の周知技術といえる。

また、請求人は、上記主張において、「補正後の本願請求項によれば、期限を表す文字列に関係の無い日時にリマインドメールが送信されることはありません。」と、期限を表す情報を抽出する処理の正確性について言及しているが、本願出願前である平成25年1月17日に公開された特開2013-12099号公報(以下、「周知文献2」という。)には、回答要求を示す言語表現(語句)の意味構造を定義し、または、一致してはならない言語表現の意味構造も定義する「マッチ規則」を定義しておき(【0027】)、受信したメールの本文を言語解析して得られた意味構造のうち、前記「マッチ規則」と一致するものから回答期限を抽出すること(【0081】?【0092】)が記載されており、ここで、「マッチ規則」は、以下の【図2】に記載したものである。

「【図2】

」(なお、上図は、一致すべきマッチ規則であり、下図は、一致してはならないマッチ規則である(【0038】)。)
ここで、「マッチ規則」は、意味構造としては、「期限を表す文字列」と「期限を表す情報」とが前後に連結したパターンといい得るものであり、また、意味構造である「マッチ規則」を使用した場合、単なる文字列の並びに基づく表現上のパターンを使用した場合よりもより正確に期限を表す情報を抽出することができることは明らかである。
よって、意味構造において「期限を表す文字列」と「期限を表す情報」とが前後に連結したパターンを用いることにより、電子メール本文から「期限を表す情報」をより正確に抽出することも、本願出願時の周知技術にすぎない。
以上から、仮に、請求人の上記主張を参酌したとしても、本願発明は、当業者が、引用発明に基づいて引用文献2ないし4に記載された技術事項ないし周知文献1及び2に記載されたような周知技術を参酌することにより容易に発明をすることができたものである。

第7 むすび
以上のとおり、本願発明は、当業者が、その出願前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献1に記載された発明及び引用文献2ないし4に記載された技術事項(並びに必要に応じて周知文献1及び2に記載された周知技術)に基いて、容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2021-06-01 
結審通知日 2021-06-08 
審決日 2021-06-22 
出願番号 特願2015-181312(P2015-181312)
審決分類 P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 北川 純次  
特許庁審判長 角田 慎治
特許庁審判官 林 毅
富澤 哲生
発明の名称 電子メール管理装置、方法およびプログラム  
代理人 下坂 直樹  
代理人 机 昌彦  

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