【事件の表示】
　平成１１年特許願第　　５５５１号「情報提供装置」拒絶査定不服審判事件〔平成１２年　７月２８日出願公開、特開２０００−２０９２５５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成１１年１月１２日の出願であって、その請求項１に係る発明は、平成１４年７月８日付けの手続補正書により補正された明細書及び図面の記載からみて、特許請求の範囲の請求項１に記載されたとおりの次のものと認める。（以下、「本願発明」という。）
「情報管理装置と、複数の端末装置とを備え、
　前記情報管理装置は、各会員毎に、店舗コードと、送信先情報と、各情報ＩＤに対応する情報を当該会員に送信するか否かを示す送信種別情報とを記憶するとともに、情報ＩＤ毎に、店舗コードと、当該情報ＩＤに対応する情報の送信タイミング情報とを記憶し、送信タイミングに達した情報を、当該情報の情報ＩＤに対応する送信種別情報が送信を示している送信種別情報が記憶されているとともに、当該情報ＩＤに対応する店舗コードと一致する店舗コードが記憶されている会員に対応する送信先情報の端末装置に送信する、情報提供装置。」
　
２．引用例及び周知例
　これに対して、原査定の拒絶の理由に引用された特開平１０−１７３６４８号公報（以下、「引用例」という。）、及び、原査定の備考欄において周知例として引用された特開平９−１０１９９０号公報（以下、「周知例」という。）には、それぞれ、図面とともに次の事項が記載されている。
　
［引用例］
Ａ．「【発明の属する技術分野】本発明は、情報送信装置と情報受信装置間の情報伝送方法に関する。」（第３頁右欄第４１〜４２行）
Ｂ．「【００１３】また本発明の別の目的は、内容コード通信方法において、受け手の属性を、送り手が送り手の意志で様々に組み合わせて、対象となる受け手だけに情報を選択受信させることを可能にすることである。具体的には、例えば、情報受信装置側のユーザの意志だけでなく、情報送信装置側の情報提供者の意志または戦略に基づき、情報受信装置側の対象ユーザに選択受信させることを可能にすることである。」（第４頁右欄第３１〜３８行）
Ｃ．「【００１５】本発明の具体的な目的は、情報送信装置側の情報提供者の意志または戦略で、情報受信装置側のユーザに情報を選択受信させることができる情報の送受信方法及びそれを用いた情報の送受信システムを提供することである。
【００１６】より具体的には、情報受信装置側のユーザの属性を、情報送信装置側の情報提供者が情報提供者の意志で様々に組み合わせて、対象となるユーザだけに情報を選択受信させることができる情報の送受信方法及びそれを用いた情報の送受信システムを提供することである。」（第４頁右欄第４３行〜第５頁左欄第３行）
Ｄ．「【課題を解決するための手段】上記目的を達成するため、本発明は、複数の情報受信装置と、複数の情報送信装置が伝送媒体を介して送信・受信するシステムにおいて、情報送信装置が、データの内容を表わす内容コードと、その内容コードを登録すべき条件とを登録メッセージとして送信し、情報受信装置は、登録メッセージを受信し、受信した条件と予め設定された属性とに基づき、内容コードを登録するか否かを決定し、情報送信装置が、データの内容を表わす内容コードをデータに付加しデータメッセージとして送信し、情報受信装置は、データメッセージ到着時、受信した内容コードと前記登録された内容コードに基づき、データを受信するか否かを決定するようにした。特に、属性として、情報受信装置のユーザのプロファイル、ユーザの好み、ユーザの状況に関する情報、または既に登録された内容コードを使用した。」（第５頁左欄第１４〜２９行）
Ｅ．「【００６４】図１６に内容コード管理テーブル１０８の構造の一例を示す。内容コード管理テーブル１０８は、内容コード１０８１と、その内容コードに定義された内容即ち、戦略条件１０８２、状態１０８３、登録時刻１０８４、休止時刻１０８５、再開時刻１０８６、削除時刻１０８７との７つのフィールドを持つ。ユーザ（送信側の戦略者）は、戦略条件１０８２を戦略定義画面１１４により指定するだけであり、後の６つのフィールドは一般的には自動的に内容コード管理機能１０２が指定する。
【００６５】例えば、内容コード１０８１は使用されていない番号が割り当てられ、登録時刻１０８４は現在時間が設定され、休止時刻１０８５は登録時間の６ヶ月後の時間が設定され、再開時刻１０８６は空白（「−」）が設定され、削除時刻１０８７は、休止時刻の１年後の時刻が設定されるようにデフォルトで決定しておくことができる。もちろん、戦略者が手動で内容コードの番号や各種時刻を設定することも可能である。
【００６６】内容コード１０８１は定義されたデータの内容を表わすコードである。戦略条件１０８２は、データ提供の戦略のための条件を表わすもので、同時に、内容コードの意味も表わすことになる。例えば、内容コード「１０１」番が付加されたデータは、データの内容が「３０代＆性別＝男」向きのデータであることを示す。逆に言えば、「３０代＆性別＝男」に薦めたいデータには内容コード「１０１」番を付けて送信すれば良いことを示す。」（第８頁左欄第４３行〜右欄第１９行）
Ｆ．「【００７１】図１５に戦略管理テーブル１０９の構造の一例を示す。戦略管理テーブル１０９は、戦略番号１０９１、データ番号１０９２、内容コード１０９３、同期番号１０９４、送信時刻１０９５、の５つのフィールドを持つ。ユーザ（送信側の戦略者）は、戦略定義画面１１４（図１４）による商品（データ）番号１１４２、同期番号１１４５、送信時刻１１４６の指定により、データ番号１０９２、同期番号１０９４、送信時刻１０９５を明示的に、内容コードを暗示的に（戦略条件から導出されるので）指定する。
【００７２】戦略番号１０９１は戦略をユニークに識別する番号であり、戦略管理機能１０３によって自動的に設定される。データ番号１０９２は戦略が指定されたデータの番号をしめす。内容コードは、暗示的に戦略条件１０８２を表現している。」（第９頁左欄第４〜１８行）
Ｇ．「【０１１８】図３８は本発明の実施例の構成を示す図である。機能構成要素としてデータ送信装置３０に、ユーザ属性管理機能３０６が加わる以外は、基本的に図１の構成と同様である。差異については後述する。
【０１１９】図３９に、データ送信装置３０の機能構成の詳細を示す。機能構成要素としてユーザ属性管理機能３１３が、テーブルとしてユーザ属性管理テーブル３１４が加わる以外は、基本的に図２の構成と同様である。差異については後述する。
【０１２０】データ送信装置３０のハードウェア構成の詳細は、図３と同様であるので説明を省略する。
【０１２１】図４０はデータ送信装置において、ＣＰＵが実行する主要な処理フロー図である。処理フローとして、ユーザ属性登録メッセージ受信イベント発生時の処理であるユーザ属性管理機能の呼出３００９が加わる以外は、基本的に図４と同様である。
【０１２２】最初の実施例と同様に、戦略者が４つの手順（１）商品情報（データ）の登録（２）属性項目の登録（３）述語の登録（４）戦略の設定、を順に行った場合について説明する。
【０１２３】（１）の商品情報（データ）の登録に関しては、図５の処理フローと変わらないので省略する。
【０１２４】（２）の属性項目の登録に関しても、図６の処理フローと基本的に変わらない。ただし、属性項目登録メッセージ送信（１０２３）において、送信されるメッセージのフォーマットが異なる。
【０１２５】図４５に、属性項目登録メッセージのフォーマットを示す。宛先アドレス３１５１、送信元アドレス３１５２、内容コード３１５３、同期番号３１５４、通番３１５５、属性コード３１５６、属性名３１５７、属性値制限３１５８を構成要素として持つ。宛先アドレス３１５１には、このメッセージがブロードキャスト（同報通信）であることを表わすアドレス、例えば「１１１１１１」が設定される。送信元アドレスには、データ送信装置３０の通信用アドレス（例えば「０００００１」）が設定される。その他の項目は、図１７と同様に設定される。
【０１２６】図４９に属性項目登録メッセージ３１７１としての設定の例を示す。このメッセージを受信したデータ送信装置４０は、ユーザ属性登録メッセージを返信してくる（詳しくは後述する）。図４６に、このユーザ属性登録メッセージのフォーマットを示す。属性項目登録メッセージ（図４５）に比べ、属性値制限３１５８が属性値３１５９に置き換わった点が異なる。図４９にユーザ属性登録メッセージ３１７２としての設定の例を示す。宛先アドレス３１５１にはデータ送信装置３０の通信用アドレス（例えば「０００００１」）が設定される。送信元アドレス３１５２には、データ受信装置４０の通信用アドレス（例えば「００１００１」）が設定される。これは１対１の通信である。属性値３１５９には、データ受信装置４０のユーザによって設定された属性値（例えば［東京都…］）が設定されている。このユーザ属性登録メッセージは、データ送信装置３０において通信装置１３５を介して受信され、ユーザ属性管理機能の呼出（図４０の３００９）が行われる。
【０１２７】図４２は、呼び出されたユーザ属性管理機能３１３の処理フローを示す。ユーザ属性管理機能３１３は、受信したメッセージの送信元アドレスによりユーザを識別し、ユーザ毎に存在するユーザ属性管理テーブル３１４に、メッセージ上の属性項目と属性値を設定する。図４３にユーザ属性管理テーブル３１４の構成を示す。これは、最初の実施例において、データ受信装置２０が管理していたユーザ性管理テーブル２０９（図３４）と同内容である。
【０１２８】（３）の述語の登録に関しては、図４１に処理フローを示す。述語登録メッセージの送信処理が削除された以外は、図７と同様である。
【０１２９】（４）の戦略の設定に関しては、図９の処理フローと基本的に変わらない。ただし、２つの処理において、若干の差異があるので以下に説明する。
【０１３０】図９の処理フローでは、途中で内容コード管理機能が呼び出される。呼び出された内容コード管理機能の処理フロー（図８）の処理１０４３について差異を記述する。
【０１３１】内容コード管理機能１０２は、前処理ステップ（１０４２）で登録された内容コードの戦略条件と、すべてのユーザのユーザ属性管理テーブル３１４を比較し、どのユーザがこの戦略条件を満たしているかを調べる。この戦略条件を満たしているすべてのユーザに対して、１対１通信で内容コード登録メッセージを送信する。
【０１３２】図４７に内容コード登録メッセージのフォーマットを示す。宛先アドレス３１５１には戦略条件を満たしたユーザ（データ受信装置）の通信用アドレスが設定される。内容コード３１５３は、内容コード登録用内容コード「００１」が、内容コード群３１６０には、登録したい内容コードが設定される。図４９に内容コード登録メッセージ３１７３、３１７４としての設定の例を示す。内容コード登録メッセージ３１７３は、宛先アドレス「００１００１」のデータ受信装置に対して、内容コード「１０１」つまり「３０代＆性別＝男性」の登録が依頼されていることを示す。
【０１３３】また、図９の処理フローにおけるデータメッセージ送信（１０５４）において、送信されるメッセージのフォーマットが異なる。
【０１３４】図４８に、データメッセージのフォーマットを示す。宛先アドレス３１５１、送信元アドレス３１５２、内容コード３１５３、同期番号３１５４、通番３１５５、データ３１６１を構成要素として持つ。宛先アドレス３１５１には、このメッセージがブロードキャスト（同報通信）であることを表わすアドレス、例えば「１１１１１１」が設定される。送信元アドレスには、データ送信装置３０の通信用アドレス（例えば「０００００１」）が設定される。その他の項目は、図２０と同様に設定される。図４９にデータメッセージ３１７５、３１７６、３１７７としての設定の例を示す。
【０１３５】次に、本実施例での受信装置４０について説明する。
【０１３６】図５０に、データ受信装置４０の機能構成の詳細を示す。機能構成要素として述語管理機能２０７が、テーブルとして述語管理テーブル２１１が削除されている以外は、基本的に図２４の構成と同様である。差異については後述する。
【０１３７】データ受信装置４０のハードウェア構成の詳細は、図２５と同様であるので説明を省略する。
【０１３８】図５１はデータ受信装置において、ＣＰＵが実行する主要な処理フロー図である。処理フローとして、述語登録メッセージ受信イベント発生時の処理である述語管理機能の呼出２００６が削除される以外は、基本的に図２６と同様である。以下最初の実施例との差異部分について説明する。
【０１３９】図４９に示した順序でメッセージが、放送受信装置４３４からデータ受信装置４０に到着し、イベントが発生したとする。データ受信装置４０はイベント発生時、イベントの種類を判断する（４００２）。メッセージ受信時、メッセージの受信をメッセージ受信イベントとしてとらえ、メッセージ選択受信機能４０１を呼び出す（４００３）。メッセージ選択受信機能４０１は、メッセージの選択受信を行う。
【０１４０】図５２に呼出されたメッセージ選択受信機能４０１における主要な処理フロー図を示す。最初の処理４０１０が追加された以外は、図２７と同様なので省略する。まず、到着したメッセージの宛先アドレスを判断し（４０１０）、自分のアドレスまたはブロードキャストアドレスなら以降の処理へ（４０１１）、そうでないならメッセージ廃棄処理（４０４１）へ遷移する処理が付け加わるだけである。
【０１４１】図５３に、ユーザ属性管理機能４０３における主要な処理フロー図を示す。ユーザ属性登録メッセージ送信処理（４０３３）が、図２９に追加されている。図４６に、このユーザ属性登録メッセージのフォーマットを示す。属性項目登録メッセージ（図４５）に比べ、属性値制限３１５８が属性値３１５９に置き換わった点が異なる。図４９にユーザ属性登録メッセージ３１７２としての設定の例を示す。宛先アドレス３１５１にはデータ送信装置３０の通信用アドレス（例えば「０００００１」）が設定される。送信元アドレス３１５２には、データ受信装置４０の通信用アドレス（例えば「００１００１」）が設定される。これは１対１の通信である。属性値３１５９には、データ受信装置４０のユーザによって設定された属性値（例えば［東京都…］）が設定されている。このユーザ属性登録メッセージは、入出力管理機能４０５を経由、通信装置を介してネットワークに送信される。
【０１４２】図５４に、内容コード管理機能４０２における主要な処理フロー図を示す。単順に、受信した内容コード登録メッセージに基づき、登録内容コードを内容コード管理テーブルに設定するだけである。
【０１４３】上記実施例では、データ送信装置側にも、ユーザ属性管理テーブルを持つ。そのため、基本的には、データ受信装置側にユーザ属性管理テーブルを持つ必要が無い（上記実施例では持たせているが、存在しなくても内容コード通信に影響はでないのは明らかである）。また、ユーザ属性管理テーブルのデータを使って、さまざまなマーケット分析を行えるというメリットがある。例えば、データ送信装置において、戦略設定時、戦略設定画面（図４４）において、戦略条件に適合するユーザが何人存在するのかを計算する事（３１４７）が可能である。この数字は、戦略の効果を推定する上で使用できる。」（第１２頁右欄第２７行〜第１４頁左欄第４６行）
　
　ここで、図１５の「戦略管理テーブル１０９」の「内容コード１０９３」は、「暗示的に戦略条件１０８２を表現している」（第９頁左欄第１７〜１８行）ものであり、その中身には、例えば、「３０代＆性別＝男」等のユーザの属性値が含まれるものである（第８頁右欄第１１〜１９行の記載参照）ので、「戦略管理テーブル１０９」は、「戦略番号１０９１」毎に情報を送りたい相手方の属性値を記憶しているものであるということができる。
　よって、上記Ａ〜Ｇの記載を参照すると、引用例には、次の発明が記載されているものと認められる。（以下、「引用例記載の発明」という。）
「情報送信装置と、複数の情報受信装置とを備え、
　前記情報送信装置は、各ユーザ毎に、属性値と、送信先情報とを記憶するとともに、戦略番号毎に、属性値と、当該戦略番号に対応する情報の送信時刻情報とを記憶し、送信時刻に達した情報を、当該戦略番号に対応する属性値と一致する属性値が記憶されているユーザに対応する送信先情報の情報受信装置に送信する、情報提供装置。」
　
［周知例］
Ｈ．「【発明の属する技術分野】この発明は、膨大なテキスト記事からユーザの要求・興味にあったものを選出して定期的にユーザに提供する情報フィルタリング装置に関する。」（第２頁右欄第２３〜２６行）
Ｉ．「【０２７９】例えば、図５９のように、どのユーザにどの記事を送信するかという情報が記事選出部２５により格納されていたとする。
【０２８０】この例では、例えばユーザ１には記事１、２を提示することが、ユーザ２には記事２、３、４を提示することが記されている。」（第１６頁左欄第３３〜３８行）
　
　上記Ｈ，Ｉの記載及び図５９を参照すると、周知例には、次の事項が記載されているものと認められる。
「ユーザに情報を送信する際に、当該情報をユーザに送信するか否かを示す識別情報を、ユーザ毎に記憶するようにすること。」
　
 ３．対比
　そこで、本願発明と引用例記載の発明とを対比すると、まず、引用例記載の発明における「情報送信装置」は、データ管理機能を有するものであり、本願発明における「情報管理装置」に対応する構成である。
　次に、引用例記載の発明における「情報受信装置」は、「端末装置」であることには変わりない。
　また、引用例記載の発明における「ユーザ」と、本願発明における「会員」は、ともに、「情報受信者」であるということができる。
　さらに、本願発明において、会員毎に対応して設定される「店舗コード」は、その会員が属している店舗を表しているものと解され、その会員の属性を表す「属性値」の一種であるものと認められる。
　そして、引用例記載の発明における「戦略番号」、「送信時刻」は、それぞれ、本願発明における「情報ＩＤ」、「送信タイミング」に対応するものと認められる。
　よって、本願発明と引用例記載の発明とは、ともに、
「情報管理装置と、複数の端末装置とを備え、
　前記情報管理装置は、各情報受信者毎に、属性値と、送信先情報とを記憶するとともに、情報ＩＤ毎に、属性値と、当該情報ＩＤに対応する情報の送信タイミング情報とを記憶し、送信タイミングに達した情報を、当該情報ＩＤに対応する属性値と一致する属性値が記憶されている情報受信者に対応する送信先情報の端末装置に送信する、情報提供装置。」
である点で一致し、次の点で相違する。
　相違点（１）：本願発明においては、「情報受信者」が「会員」であり、情報受信者に設定される「属性値」が「店舗コード」であるのに対し、引用例記載の発明においては、そのようなものではない点。
　相違点（２）：本願発明においては、各会員毎に、「各情報ＩＤに対応する情報を当該会員に送信するか否かを示す送信種別情報」を記憶するようにするとともに、送信タイミングに達した情報を、「当該情報の情報ＩＤに対応する送信種別情報が送信を示している送信種別情報が記憶されている」会員に対応する送信先情報の端末装置に送信するようにしているのに対し、引用例記載の発明においては、送信時刻に達した情報を、当該戦略番号に対応する属性値と一致する属性値が記憶されているユーザに対応する送信先情報の情報受信装置に送信するようにしているものの、「送信種別情報」は用いていない点。
　
４．当審の判断
　上記相違点について検討する。
［相違点（１）について］
　引用例記載の発明は、ある戦略の下に、受信側ユーザーが広告・宣伝対象とするのに適するユーザーであるのかどうかを、そのユーザーの属性値を基に判断しているものである。
　そして、遊技店等において、店舗毎に会員を募り、その会員対象に広告・宣伝を行うことは、広く行われていることであり、その場合、会員の属性値であるところの所属店舗を見て、その店舗に属する会員対象に該店舗に関わる広告・宣伝を行うようにすることは、ごく普通に考えられる戦略であるものと認められる。
　してみれば、引用例記載の発明において、情報受信者及びその属性値を「会員」及び「店舗コード」とし、当該店舗に属する会員対象に該店舗に関わる広告・宣伝を行うような戦略をとるようにすることは、当業者が適宜になし得ることにすぎないものと認められる。
　
［相違点（２）について］
　上記周知例に見られるように、ユーザに情報を送信する際に、当該情報をユーザに送信するか否かを示す識別情報を、ユーザ毎に記憶するようにすることは、周知の技術にすぎない。
　してみれば、引用例記載の発明において、上記周知の技術を適用し、各会員毎に「各情報ＩＤに対応する情報を当該会員に送信するか否かを示す送信種別情報」を記憶し、送信タイミングに達した情報を「当該情報の情報ＩＤに対応する送信種別情報が送信を示している送信種別情報が記憶されている」会員に対応する送信先情報の端末装置に送信するように構成することは、当業者が適宜に設計できる事項にすぎないものと認められる。
　
　そして、本願発明の構成によってもたらされる効果も、引用例記載の発明及び上記周知の技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。
　
５．むすび
　したがって、本願発明は、引用例記載の発明及び上記周知の技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。