【事件の表示】
　特願２００１−４００７１３「電子メール制御プログラム、記録媒体及びコンピュータ」拒絶査定不服審判事件〔平成１５年　７月１１日出願公開、特開２００３−１９６２０７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続きの経緯
　
　本願は，平成１３年１２月２８日を出願日とする出願であって，平成１８年１２月１４日付けで拒絶査定がされたところ，平成１９年１月２６日に拒絶査定に対する審判が請求されるとともに，同年２月２６日に手続補正書が提出され，当審による平成２２年２月１２日付け拒絶理由通知に対し，同年４月１５日に手続補正書と意見書が提出されたものである。
　
第２　本願の特許請求の範囲
　
　本願の請求項１に係る発明（以下「本願発明」という。）は，平成２２年４月１５日に提出された手続補正書に記載された以下のとおりのものである。
　
「【請求項１】　電子メールにかかる処理をコンピュータに実行させる電子メール制御プログラムにおいて、
　データベースクライアントプログラムに組み込まれて、データベースクライアントコンピュータ上で実行されるプログラムであって、
　送信すべきヘッダ情報を含むメッセージ情報の入力を受け付ける処理１と、
　前記メッセージ情報に固有な識別子を与える処理２と、
　ヘッダ情報のフィールドをそれぞれが前記識別子を含む少なくともひとつのテーブル甲に蓄積する処理３と、
　前記テーブル甲を参照して前記識別子に対応するメッセージ情報の全体を作成する処理４と
をコンピュータに実行させることを特徴とする電子メール制御プログラム。」
　
 第３　引用刊行物について 
　
１　引用刊行物
　
１　特開２０００−２０７３０６号公報（平成１２年７月２８日出願公開）
２　特開平４−２９４６５５号公報（平成４年１０月１９日出願公開）
　
　以下，上記引用刊行物１，２を，それぞれ，引用例１，２という。
　
２　引用例１の記載内容
　
（１）引用例１には，図面とともに，以下の記載がある。なお，下線は当審で付加したものである。
　
（ア）「【００１９】図１は、
この発明の実施形態に係る情報機器の構成を示す
【００２０】図１に示すように、この情報機器は、ＣＰＵ１、ＲＡＭ２、ＲＯＭ３、ＬＣＤ４、タブレット５、キーボード６、外部記憶装置７、ＲＴＣ（リアルタイムクロック）８、電話部９、スピーカ／マイク１０およびモデム１１を有している。
【００２１】ＣＰＵ１は、この情報機器全体の制御を司るものであり、ＲＡＭ２またはＲＯＭ３に格納されたプログラムを実行制御する。ＲＡＭ２およびＲＯＭ３は、ＣＰＵ１によって実行制御されるプログラムやデータを格納する記憶装置である。なお、
この発明の特徴とする送信メールの管理手法は、この情報機器では、ＲＡＭ２またはＲＯＭ３に格納されてＣＰＵ１によって実行制御されるプログラムにより実現される
【００２２】ＬＣＤ４は、文字や図形を表示する表示装置である。タブレット５およびキーボード６は、位置の指定やデータの入力に用いられる入力装置である。外部記憶装置７は、プログラムやデータをファイルとして格納する記憶装置である。ＲＴＣ８は、時計情報を供給する装置である。
 【００２３】電話部９は、電話機能を受け持つものである。スピーカ／マイク１０は、音声の入出力に用いられる装置である。そして、モデム１１は、デジタル信号をアナログ回線で送受信するための変復調を行なう装置である。」
　 
（イ）「【００２４】次に、図２を参照しながら、このような構成をもつこの情報機器の送信メールの管理手法の大まかな流れを説明する。
【００２５】従来においては、メールを記入した後、このメールをメールボックスに入れることで単純に送信処理に移行していた。それに対して、この情報機器では、
メールを記入した後、
メールボックスへの格納へと移行する
【００２６】そして、
メールボックスに格納されたメールを
送信処理へと移行する
　
（ウ）「【００３１】たとえば、図６で示すメール２とメール３とがメールボックスに存在したとすると、この２つのメールの送信時間は１９９８年０８月２１日１８時１０分３０秒までに送信を開始すればよいと判断できる。この判断から、たとえばこの時刻の到来直前にこの２つを送信すれば、
メール送信ホスト（ＡＯＬ）との回線の接続回数を１回で済ませることが可能となる。
　
（エ）「【００４０】なお、
メールボックス内では、図１０に示すようなフォーマットでこれらの送信メールを管理すれば良い
　
（２）ここで，メールボックス内における送信メールの格納フォーマットを例示する図１０を参照すると，メールボックス内では，テーブルによって送信先等の情報を管理することが記載されていると認められる。
　
　そうすると，記載事項（ア）〜（エ）によれば，引用例１には
　
「送信メールの管理手法を情報機器に実行させるプログラムであって，
　記入されたメールをメールボックスに入れ，
　メールボックスでは，送信先等の情報を項目として含むテーブルによって管理し，
　メールボックスに格納されたメールを送信するプログラム。」（以下「引用発明」という。）
　
　が記載されていると認められる。
　
３　引用例２の記載内容
　
（１）引用例２には，図面とともに，以下の記載がある。なお，下線は当審で付加したものである。
　
（オ）「【００１６】図４は、各端末装置１，２，３，４のメール記憶装置３０におけるメール属性記憶部３２が保持するメール属性のうち、
発信メールのメール属性を管理するテーブル（発信メール管理テーブルと称す）の具体例である。発信メール管理テーブルは、タイトル、回答期限、発信種別（同報、回覧等）、回答要否などの所謂発信メールの管理情報を格納するテーブル３２１ａと、宛先ごとの処理状態（回答済、閲覧済等）を格納するテーブル３２１ｂからなる。
【００１７】図５は、同メール属性記憶部３２が保持するメール属性のうち、
受信メールのメール属性を管理するテーブル（受信メール管理テーブルと称す）の具体例である。受信メール管理テーブルは、タイトル、期限、発信種別、回答要否、発信者名及び処理状態等を格納するテーブル３３２ａ、回覧の宛先を格納するテーブル３３２ｂからなる。
　
（２）上記記載事項（オ）及び図４，５を参照すると，引用例２には，送信若しくは受信メールに関する情報をテーブルにて管理するにあたり，メールに関する情報を複数のテーブルに分けて記憶し，それら複数のテーブルそれぞれに連番を含ませることによって，分けて記憶した１通のメールに関する情報を互いに関連付けるという技術的事項が記載されていると認められる。
　
第４　対比・判断
　
１　対比  
　
　本願発明と，引用発明とを対比すると
　
（ア）引用発明の「送信メール」は，本願発明の「電子メール」若しくは「メッセージ情報」に相当する。
（イ）引用発明の「情報機器」は，電子メールの記入，管理，送信を行うコンピュータ機器であるから，本願発明の「コンピュータ」に相当する。
（ウ）引用発明におけるメールボックスは，送信メールの情報を格納及び管理する記憶手段であるから，「データベース」であると認められる。そして，引用発明の情報機器は，そのメールボックスを用いて，記入したメールをメール送信ホストに送信するものであるから，「データベースクライアントコンピュータ」であると認められる。そうすると，引用発明の「プログラム」は，本願発明と同様に，「データベースクライアントコンピュータ上で実行されるプログラム」であると認められる。
（エ）引用発明では，記入されたメールがメールボックスに入れられているから，本願発明と同様に「送信すべきヘッダ情報を含むメッセージ情報の入力を受け付ける処理１」が実行されている。
（オ）引用発明では，メールボックスにおいて，送信先等の情報がテーブルに格納されているから，引用発明のプログラムは，本願発明のプログラムと「ヘッダ情報のフィールドをテーブル甲に蓄積する処理３」をコンピュータに実行させるものである点において共通する。
（カ）引用発明では，メールボックスに格納されたメールが送信されている。ここで，引用発明では，メールは，メールボックス内において，テーブルで管理されており，送信可能なフォーマットで管理されてはいないから，かかる送信にあたり，送信可能なフォーマットのメールにするための作成処理が行われていると認められる。そうすると，引用発明のプログラムは，本願発明のプログラムと「テーブル甲を参照してメッセージ情報の全体を作成する処理４」をコンピュータに実行させるものである点において共通する。
（キ）引用発明の「プログラム」は，電子メールの記入，管理，送信をコンピュータである情報機器に実行させるものであり，本願発明のプログラムと「電子メールにかかる処理をコンピュータに実行させる電子メール制御プログラム」である点において共通している。
　
２　一致点と相違点
　
　以上によれば，本願発明と引用発明の一致点と相違点は，次のとおりと認められる。
　
ア　一致点
　
「電子メールにかかる処理をコンピュータに実行させる電子メール制御プログラムにおいて，
　データベースクライアントコンピュータ上で実行されるプログラムであって，
　送信すべきヘッダ情報を含むメッセージ情報の入力を受け付ける処理１と， 
 　ヘッダ情報のフィールドをテーブル甲に蓄積する処理３と，
 　前記テーブル甲を参照してメッセージ情報の全体を作成する処理４と，
 をコンピュータに実行させることを特徴とする電子メール制御プログラム。」
　
イ　相違点
　
［相違点１］本願発明では，プログラムが，データベースクライアントプログラムに組み込まれているのに対し，引用発明では，それが明らかでない点。
　
［相違点２］本願発明では，プログラムによって，メッセージ情報に固有な識別子を与える処理２が実行され，テーブル甲が，それぞれが前記識別子を含む少なくともひとつのテーブル甲であり，テーブル甲を参照してのメッセージ情報の全体の作成が，前記識別子に対応して実行されるのに対し，引用発明では，それが明らかでない点。
　
３　判断
　
ア　相違点１について
　
　特定の処理を行うプログラムを，複数のプログラムに分けて構成することは，当業者において周知の技術的事項にすぎない。そうすると，引用発明において，データベース処理を行うデータベースクライアントプログラムと電子メールの送受信を処理する電子メール制御プログラムに分けて構成し，電子メール制御プログラムをデータベースクライアントプログラムに組み込むようにして，相違点１にかかる構成とすることは，当業者においては，適宜なし得る程度のことといえる。
　
イ　相違点２について
　
　上記第３，３，（２）で見たように，引用例２には，「送信若しくは受信メールに関する情報をテーブルにて管理するにあたり，メールに関する情報を複数のテーブルに分けて記憶し，それら複数のテーブルそれぞれに連番を含ませることによって，分けて記憶した１通のメールに関する情報を互いに関連付ける」という技術的事項が記載されている。
　そうすると，引用発明において，引用例２に記載されたかかる技術的事項を適用し，メールボックスに入れられるメールに対して連番（本願発明の「メッセージ情報に固有な識別子」に相当。）を与え，ヘッダ情報のフィールドを，複数のテーブルに分けて記憶するとともに，当該連番をそれら複数のテーブルそれぞれに含ませることによって，分けて記憶した１通のメールに関する情報を互いに関連付ける構成とすることは，当業者においては適宜なし得たことといえる。
　そして，テーブル甲をその様に構成すると，テーブル甲を参照してメッセージ全体を作成するにあたり，連番に対応して作成処理が行われる構成となるのは，自明のことといえる。
　そうすると，引用発明に引用例２に記載の技術的事項を適用し，相違点２にかかる構成とすることは，当業者において格別の困難性を有することではないといえる。
　
４　まとめ
　
　以上のとおり，本願発明は，引用発明，引用例２に記載された技術的事項及び周知の技術的事項から，当業者が容易に想到し得たものである。
　
第５　請求人の主張
　
　審判請求人は，平成２２年４月１５日付け意見書において，以下の主張を行っている。
　
『本願明細書の発明が解決しようとする課題の欄に記載したように、本願発明は、「ある電子メール制御アプリケーションが蓄積した電子メールのメッセージは、他の電子メール制御アプリケーションや、電子メール制御アプリケーション以外のアプリケーションから利用できない点」、及び、「電子メール制御アプリケーション以外のアプリケーションで蓄積している情報を、電子メールのメッセージを作成する際に利用することができない点」を問題として認識し、「別種の電子メール制御アプリケーションを含む他のアプリケーションとの間で、データを相互に利用可能な電子メール制御アプリケーションを提供する」ことを課題として掲げています。この課題の背景には、本願明細書の従来の技術にて指摘したように、「電子メール制御アプリケーションには様々な種類が存在する。従来、これらの電子メール制御アプリケーションは、各々独自の形式で電子メールのメッセージを蓄積し、管理を行なっていた。」という事情があります。
　引用例１に記載の電子メール制御アプリケーションもまた、そうした独自形式のデータでメッセージを管理していると考えられます。従来の電子メール制御アプリケーションにて採用されている独自形式の電子メール管理方式と比較すると、データベース管理システムを用いた電子メール管理は、実装コストが大きくなります。また、従来の電子メール制御アプリケーションにおける電子メールの管理目的は、従来の一般的な電子メール管理方式にて達成することができます。電子メール制御アプリケーションに関して従来掲げられていた課題は、従来の電子メール管理方式により、低コストで十分に実現することができました。
　本願出願当時は上述のような状況であったため、電子メール制御アプリケーションにおいて電子メールを管理するために、理由もなく当業者がデータベースクライアントプログラムに組み込むことは考えられません。組み込む当業者がいるとすればコストアップに見合うだけの目的や効果を意図しているはずです。しかしながら、引用例１には、コストアップに繋がるにも関わらず敢えてデータベース管理システムを導入するべき動機や目的について何ら言及されていません。
　このような状況を鑑みれば、引用例１を読んだ当業者が「引用発明１におけるプログラムを、データベースクライアントプログラムに組み込んで構成し、相違点１にかかる構成とすることも、当業者においては、適宜なし得る程度」とは到底考えられません。コストアップと引き替えにしても導入すべき理由が何も意識されていない状況下であれば、データベース管理システムを用いる構成は、当業者であれば採用を避けるべき構成であり、採用には相応の理由が必要です。
　これに対して、本願明細書第５−７段落に記載のように、本発明は他アプリケーションとのデータ相互利用に着目し、その実現のための手段の一部としてデータベースクライアントを用いています。引用例２を検討しても、他アプリケーションとのデータ相互利用性に関する記載を見いだすことはできません。同様のことが拒絶理由通知書第１４ページ（２）（イ）の相違点及び同ページ（３）の判断と、本願請求項６に係る発明との間に言えます。』
　
　しかしながら，本願の請求項１には，メッセージ情報を蓄積するにあたり「ヘッダ情報のフィールドをそれぞれが前記識別子を含む少なくともひとつのテーブル甲に蓄積」させることのみが記載されており，それが『独自形式のデータ』でないことついては，何らの限定も存在しない。そうすると，『引用例１に記載の電子メール制御アプリケーションもまた、そうした独自形式のデータでメッセージを管理していると考えられます。』として，本願発明と引用発明は，電子メール管理方法が異なると主張する審判請求人の意見は，請求項の記載に基づくものであるとは，認めることができない。
　そして，請求項１に記載された構成である，電子メールをテーブルで管理することについては，本願発明と引用発明は，何ら異なることはない。
　なお，特開２００１−３４４１７８号（特に段落【０００８】参照。）に見るように，電子メールを汎用のデータ形式で管理することは，既に知られた技術にすぎない。
　
　そして，審判請求人は，さらに『引用例１には、コストアップに繋がるにも関わらず敢えてデータベース管理システムを導入するべき動機や目的について何ら言及されていません。』と主張するが，引用発明も，図１０に示されるように，電子メールの送信先や内容等の各項目をテーブルの項目として格納及び管理しているから，電子メールは，データベースによって管理されているといえ，そのデータベースの管理を行うためにデータベース管理システムが導入されているのは明らかであり，そのデータベース管理システムが，電子メールプログラムに含まれて存在しているのか，電子メールプログラムとは独立してデータベースクライアントプログラムとして存在しているのかについては明らかではないものの，データベース管理システムが導入されているという点では，本願発明と引用発明は，何ら異なることはない。
　そして，第４，３，アで述べたように，プログラムを，１つのプログラムで構成するか，複数のプログラムに分けて構成するかは，当業者が，必要に応じて適宜選択し得る程度のことであるから，電子メールプログラムとは独立してデータベースクライアントプログラム構成し，電子メール制御プログラムをデータベースクライアントプログラムに組み込むようにし，本願発明の構成とすることは，当業者においては，適宜なし得る程度のことである。
　
　そうすると，審判請求人の主張を格別のものとは，認めることができない。
　
第６　むすび
　
　以上のとおり，本願発明は，引用発明，引用例２に記載された技術的事項及び周知の技術的事項に基づいて当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により，特許を受けることができない。 
　
　したがって，その余の請求項について論及するまでもなく，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。