• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1116942
審判番号 不服2002-16886  
総通号数 67 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2000-07-28 
種別 拒絶査定不服の審決 
審判請求日 2002-09-03 
確定日 2005-05-12 
事件の表示 平成11年特許願第 5551号「情報提供装置」拒絶査定不服審判事件〔平成12年 7月28日出願公開、特開2000-209255〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯・本願発明
本願は、平成11年1月12日の出願であって、その請求項1に係る発明は、平成14年7月8日付けの手続補正書により補正された明細書及び図面の記載からみて、特許請求の範囲の請求項1に記載されたとおりの次のものと認める。(以下、「本願発明」という。)
「情報管理装置と、複数の端末装置とを備え、
前記情報管理装置は、各会員毎に、店舗コードと、送信先情報と、各情報IDに対応する情報を当該会員に送信するか否かを示す送信種別情報とを記憶するとともに、情報ID毎に、店舗コードと、当該情報IDに対応する情報の送信タイミング情報とを記憶し、送信タイミングに達した情報を、当該情報の情報IDに対応する送信種別情報が送信を示している送信種別情報が記憶されているとともに、当該情報IDに対応する店舗コードと一致する店舗コードが記憶されている会員に対応する送信先情報の端末装置に送信する、情報提供装置。」

2.引用例及び周知例
これに対して、原査定の拒絶の理由に引用された特開平10-173648号公報(以下、「引用例」という。)、及び、原査定の備考欄において周知例として引用された特開平9-101990号公報(以下、「周知例」という。)には、それぞれ、図面とともに次の事項が記載されている。

[引用例]
A.「【発明の属する技術分野】本発明は、情報送信装置と情報受信装置間の情報伝送方法に関する。」(第3頁右欄第41〜42行)
B.「【0013】また本発明の別の目的は、内容コード通信方法において、受け手の属性を、送り手が送り手の意志で様々に組み合わせて、対象となる受け手だけに情報を選択受信させることを可能にすることである。具体的には、例えば、情報受信装置側のユーザの意志だけでなく、情報送信装置側の情報提供者の意志または戦略に基づき、情報受信装置側の対象ユーザに選択受信させることを可能にすることである。」(第4頁右欄第31〜38行)
C.「【0015】本発明の具体的な目的は、情報送信装置側の情報提供者の意志または戦略で、情報受信装置側のユーザに情報を選択受信させることができる情報の送受信方法及びそれを用いた情報の送受信システムを提供することである。
【0016】より具体的には、情報受信装置側のユーザの属性を、情報送信装置側の情報提供者が情報提供者の意志で様々に組み合わせて、対象となるユーザだけに情報を選択受信させることができる情報の送受信方法及びそれを用いた情報の送受信システムを提供することである。」(第4頁右欄第43行〜第5頁左欄第3行)
D.「【課題を解決するための手段】上記目的を達成するため、本発明は、複数の情報受信装置と、複数の情報送信装置が伝送媒体を介して送信・受信するシステムにおいて、情報送信装置が、データの内容を表わす内容コードと、その内容コードを登録すべき条件とを登録メッセージとして送信し、情報受信装置は、登録メッセージを受信し、受信した条件と予め設定された属性とに基づき、内容コードを登録するか否かを決定し、情報送信装置が、データの内容を表わす内容コードをデータに付加しデータメッセージとして送信し、情報受信装置は、データメッセージ到着時、受信した内容コードと前記登録された内容コードに基づき、データを受信するか否かを決定するようにした。特に、属性として、情報受信装置のユーザのプロファイル、ユーザの好み、ユーザの状況に関する情報、または既に登録された内容コードを使用した。」(第5頁左欄第14〜29行)
E.「【0064】図16に内容コード管理テーブル108の構造の一例を示す。内容コード管理テーブル108は、内容コード1081と、その内容コードに定義された内容即ち、戦略条件1082、状態1083、登録時刻1084、休止時刻1085、再開時刻1086、削除時刻1087との7つのフィールドを持つ。ユーザ(送信側の戦略者)は、戦略条件1082を戦略定義画面114により指定するだけであり、後の6つのフィールドは一般的には自動的に内容コード管理機能102が指定する。
【0065】例えば、内容コード1081は使用されていない番号が割り当てられ、登録時刻1084は現在時間が設定され、休止時刻1085は登録時間の6ヶ月後の時間が設定され、再開時刻1086は空白(「-」)が設定され、削除時刻1087は、休止時刻の1年後の時刻が設定されるようにデフォルトで決定しておくことができる。もちろん、戦略者が手動で内容コードの番号や各種時刻を設定することも可能である。
【0066】内容コード1081は定義されたデータの内容を表わすコードである。戦略条件1082は、データ提供の戦略のための条件を表わすもので、同時に、内容コードの意味も表わすことになる。例えば、内容コード「101」番が付加されたデータは、データの内容が「30代&性別=男」向きのデータであることを示す。逆に言えば、「30代&性別=男」に薦めたいデータには内容コード「101」番を付けて送信すれば良いことを示す。」(第8頁左欄第43行〜右欄第19行)
F.「【0071】図15に戦略管理テーブル109の構造の一例を示す。戦略管理テーブル109は、戦略番号1091、データ番号1092、内容コード1093、同期番号1094、送信時刻1095、の5つのフィールドを持つ。ユーザ(送信側の戦略者)は、戦略定義画面114(図14)による商品(データ)番号1142、同期番号1145、送信時刻1146の指定により、データ番号1092、同期番号1094、送信時刻1095を明示的に、内容コードを暗示的に(戦略条件から導出されるので)指定する。
【0072】戦略番号1091は戦略をユニークに識別する番号であり、戦略管理機能103によって自動的に設定される。データ番号1092は戦略が指定されたデータの番号をしめす。内容コードは、暗示的に戦略条件1082を表現している。」(第9頁左欄第4〜18行)
G.「【0118】図38は本発明の実施例の構成を示す図である。機能構成要素としてデータ送信装置30に、ユーザ属性管理機能306が加わる以外は、基本的に図1の構成と同様である。差異については後述する。
【0119】図39に、データ送信装置30の機能構成の詳細を示す。機能構成要素としてユーザ属性管理機能313が、テーブルとしてユーザ属性管理テーブル314が加わる以外は、基本的に図2の構成と同様である。差異については後述する。
【0120】データ送信装置30のハードウェア構成の詳細は、図3と同様であるので説明を省略する。
【0121】図40はデータ送信装置において、CPUが実行する主要な処理フロー図である。処理フローとして、ユーザ属性登録メッセージ受信イベント発生時の処理であるユーザ属性管理機能の呼出3009が加わる以外は、基本的に図4と同様である。
【0122】最初の実施例と同様に、戦略者が4つの手順(1)商品情報(データ)の登録(2)属性項目の登録(3)述語の登録(4)戦略の設定、を順に行った場合について説明する。
【0123】(1)の商品情報(データ)の登録に関しては、図5の処理フローと変わらないので省略する。
【0124】(2)の属性項目の登録に関しても、図6の処理フローと基本的に変わらない。ただし、属性項目登録メッセージ送信(1023)において、送信されるメッセージのフォーマットが異なる。
【0125】図45に、属性項目登録メッセージのフォーマットを示す。宛先アドレス3151、送信元アドレス3152、内容コード3153、同期番号3154、通番3155、属性コード3156、属性名3157、属性値制限3158を構成要素として持つ。宛先アドレス3151には、このメッセージがブロードキャスト(同報通信)であることを表わすアドレス、例えば「111111」が設定される。送信元アドレスには、データ送信装置30の通信用アドレス(例えば「000001」)が設定される。その他の項目は、図17と同様に設定される。
【0126】図49に属性項目登録メッセージ3171としての設定の例を示す。このメッセージを受信したデータ送信装置40は、ユーザ属性登録メッセージを返信してくる(詳しくは後述する)。図46に、このユーザ属性登録メッセージのフォーマットを示す。属性項目登録メッセージ(図45)に比べ、属性値制限3158が属性値3159に置き換わった点が異なる。図49にユーザ属性登録メッセージ3172としての設定の例を示す。宛先アドレス3151にはデータ送信装置30の通信用アドレス(例えば「000001」)が設定される。送信元アドレス3152には、データ受信装置40の通信用アドレス(例えば「001001」)が設定される。これは1対1の通信である。属性値3159には、データ受信装置40のユーザによって設定された属性値(例えば[東京都…])が設定されている。このユーザ属性登録メッセージは、データ送信装置30において通信装置135を介して受信され、ユーザ属性管理機能の呼出(図40の3009)が行われる。
【0127】図42は、呼び出されたユーザ属性管理機能313の処理フローを示す。ユーザ属性管理機能313は、受信したメッセージの送信元アドレスによりユーザを識別し、ユーザ毎に存在するユーザ属性管理テーブル314に、メッセージ上の属性項目と属性値を設定する。図43にユーザ属性管理テーブル314の構成を示す。これは、最初の実施例において、データ受信装置20が管理していたユーザ性管理テーブル209(図34)と同内容である。
【0128】(3)の述語の登録に関しては、図41に処理フローを示す。述語登録メッセージの送信処理が削除された以外は、図7と同様である。
【0129】(4)の戦略の設定に関しては、図9の処理フローと基本的に変わらない。ただし、2つの処理において、若干の差異があるので以下に説明する。
【0130】図9の処理フローでは、途中で内容コード管理機能が呼び出される。呼び出された内容コード管理機能の処理フロー(図8)の処理1043について差異を記述する。
【0131】内容コード管理機能102は、前処理ステップ(1042)で登録された内容コードの戦略条件と、すべてのユーザのユーザ属性管理テーブル314を比較し、どのユーザがこの戦略条件を満たしているかを調べる。この戦略条件を満たしているすべてのユーザに対して、1対1通信で内容コード登録メッセージを送信する。
【0132】図47に内容コード登録メッセージのフォーマットを示す。宛先アドレス3151には戦略条件を満たしたユーザ(データ受信装置)の通信用アドレスが設定される。内容コード3153は、内容コード登録用内容コード「001」が、内容コード群3160には、登録したい内容コードが設定される。図49に内容コード登録メッセージ3173、3174としての設定の例を示す。内容コード登録メッセージ3173は、宛先アドレス「001001」のデータ受信装置に対して、内容コード「101」つまり「30代&性別=男性」の登録が依頼されていることを示す。
【0133】また、図9の処理フローにおけるデータメッセージ送信(1054)において、送信されるメッセージのフォーマットが異なる。
【0134】図48に、データメッセージのフォーマットを示す。宛先アドレス3151、送信元アドレス3152、内容コード3153、同期番号3154、通番3155、データ3161を構成要素として持つ。宛先アドレス3151には、このメッセージがブロードキャスト(同報通信)であることを表わすアドレス、例えば「111111」が設定される。送信元アドレスには、データ送信装置30の通信用アドレス(例えば「000001」)が設定される。その他の項目は、図20と同様に設定される。図49にデータメッセージ3175、3176、3177としての設定の例を示す。
【0135】次に、本実施例での受信装置40について説明する。
【0136】図50に、データ受信装置40の機能構成の詳細を示す。機能構成要素として述語管理機能207が、テーブルとして述語管理テーブル211が削除されている以外は、基本的に図24の構成と同様である。差異については後述する。
【0137】データ受信装置40のハードウェア構成の詳細は、図25と同様であるので説明を省略する。
【0138】図51はデータ受信装置において、CPUが実行する主要な処理フロー図である。処理フローとして、述語登録メッセージ受信イベント発生時の処理である述語管理機能の呼出2006が削除される以外は、基本的に図26と同様である。以下最初の実施例との差異部分について説明する。
【0139】図49に示した順序でメッセージが、放送受信装置434からデータ受信装置40に到着し、イベントが発生したとする。データ受信装置40はイベント発生時、イベントの種類を判断する(4002)。メッセージ受信時、メッセージの受信をメッセージ受信イベントとしてとらえ、メッセージ選択受信機能401を呼び出す(4003)。メッセージ選択受信機能401は、メッセージの選択受信を行う。
【0140】図52に呼出されたメッセージ選択受信機能401における主要な処理フロー図を示す。最初の処理4010が追加された以外は、図27と同様なので省略する。まず、到着したメッセージの宛先アドレスを判断し(4010)、自分のアドレスまたはブロードキャストアドレスなら以降の処理へ(4011)、そうでないならメッセージ廃棄処理(4041)へ遷移する処理が付け加わるだけである。
【0141】図53に、ユーザ属性管理機能403における主要な処理フロー図を示す。ユーザ属性登録メッセージ送信処理(4033)が、図29に追加されている。図46に、このユーザ属性登録メッセージのフォーマットを示す。属性項目登録メッセージ(図45)に比べ、属性値制限3158が属性値3159に置き換わった点が異なる。図49にユーザ属性登録メッセージ3172としての設定の例を示す。宛先アドレス3151にはデータ送信装置30の通信用アドレス(例えば「000001」)が設定される。送信元アドレス3152には、データ受信装置40の通信用アドレス(例えば「001001」)が設定される。これは1対1の通信である。属性値3159には、データ受信装置40のユーザによって設定された属性値(例えば[東京都…])が設定されている。このユーザ属性登録メッセージは、入出力管理機能405を経由、通信装置を介してネットワークに送信される。
【0142】図54に、内容コード管理機能402における主要な処理フロー図を示す。単順に、受信した内容コード登録メッセージに基づき、登録内容コードを内容コード管理テーブルに設定するだけである。
【0143】上記実施例では、データ送信装置側にも、ユーザ属性管理テーブルを持つ。そのため、基本的には、データ受信装置側にユーザ属性管理テーブルを持つ必要が無い(上記実施例では持たせているが、存在しなくても内容コード通信に影響はでないのは明らかである)。また、ユーザ属性管理テーブルのデータを使って、さまざまなマーケット分析を行えるというメリットがある。例えば、データ送信装置において、戦略設定時、戦略設定画面(図44)において、戦略条件に適合するユーザが何人存在するのかを計算する事(3147)が可能である。この数字は、戦略の効果を推定する上で使用できる。」(第12頁右欄第27行〜第14頁左欄第46行)

ここで、図15の「戦略管理テーブル109」の「内容コード1093」は、「暗示的に戦略条件1082を表現している」(第9頁左欄第17〜18行)ものであり、その中身には、例えば、「30代&性別=男」等のユーザの属性値が含まれるものである(第8頁右欄第11〜19行の記載参照)ので、「戦略管理テーブル109」は、「戦略番号1091」毎に情報を送りたい相手方の属性値を記憶しているものであるということができる。
よって、上記A〜Gの記載を参照すると、引用例には、次の発明が記載されているものと認められる。(以下、「引用例記載の発明」という。)
「情報送信装置と、複数の情報受信装置とを備え、
前記情報送信装置は、各ユーザ毎に、属性値と、送信先情報とを記憶するとともに、戦略番号毎に、属性値と、当該戦略番号に対応する情報の送信時刻情報とを記憶し、送信時刻に達した情報を、当該戦略番号に対応する属性値と一致する属性値が記憶されているユーザに対応する送信先情報の情報受信装置に送信する、情報提供装置。」

[周知例]
H.「【発明の属する技術分野】この発明は、膨大なテキスト記事からユーザの要求・興味にあったものを選出して定期的にユーザに提供する情報フィルタリング装置に関する。」(第2頁右欄第23〜26行)
I.「【0279】例えば、図59のように、どのユーザにどの記事を送信するかという情報が記事選出部25により格納されていたとする。
【0280】この例では、例えばユーザ1には記事1、2を提示することが、ユーザ2には記事2、3、4を提示することが記されている。」(第16頁左欄第33〜38行)

上記H,Iの記載及び図59を参照すると、周知例には、次の事項が記載されているものと認められる。
「ユーザに情報を送信する際に、当該情報をユーザに送信するか否かを示す識別情報を、ユーザ毎に記憶するようにすること。」

3.対比
そこで、本願発明と引用例記載の発明とを対比すると、まず、引用例記載の発明における「情報送信装置」は、データ管理機能を有するものであり、本願発明における「情報管理装置」に対応する構成である。
次に、引用例記載の発明における「情報受信装置」は、「端末装置」であることには変わりない。
また、引用例記載の発明における「ユーザ」と、本願発明における「会員」は、ともに、「情報受信者」であるということができる。
さらに、本願発明において、会員毎に対応して設定される「店舗コード」は、その会員が属している店舗を表しているものと解され、その会員の属性を表す「属性値」の一種であるものと認められる。
そして、引用例記載の発明における「戦略番号」、「送信時刻」は、それぞれ、本願発明における「情報ID」、「送信タイミング」に対応するものと認められる。
よって、本願発明と引用例記載の発明とは、ともに、
「情報管理装置と、複数の端末装置とを備え、
前記情報管理装置は、各情報受信者毎に、属性値と、送信先情報とを記憶するとともに、情報ID毎に、属性値と、当該情報IDに対応する情報の送信タイミング情報とを記憶し、送信タイミングに達した情報を、当該情報IDに対応する属性値と一致する属性値が記憶されている情報受信者に対応する送信先情報の端末装置に送信する、情報提供装置。」
である点で一致し、次の点で相違する。
相違点(1):本願発明においては、「情報受信者」が「会員」であり、情報受信者に設定される「属性値」が「店舗コード」であるのに対し、引用例記載の発明においては、そのようなものではない点。
相違点(2):本願発明においては、各会員毎に、「各情報IDに対応する情報を当該会員に送信するか否かを示す送信種別情報」を記憶するようにするとともに、送信タイミングに達した情報を、「当該情報の情報IDに対応する送信種別情報が送信を示している送信種別情報が記憶されている」会員に対応する送信先情報の端末装置に送信するようにしているのに対し、引用例記載の発明においては、送信時刻に達した情報を、当該戦略番号に対応する属性値と一致する属性値が記憶されているユーザに対応する送信先情報の情報受信装置に送信するようにしているものの、「送信種別情報」は用いていない点。

4.当審の判断
上記相違点について検討する。
[相違点(1)について]
引用例記載の発明は、ある戦略の下に、受信側ユーザーが広告・宣伝対象とするのに適するユーザーであるのかどうかを、そのユーザーの属性値を基に判断しているものである。
そして、遊技店等において、店舗毎に会員を募り、その会員対象に広告・宣伝を行うことは、広く行われていることであり、その場合、会員の属性値であるところの所属店舗を見て、その店舗に属する会員対象に該店舗に関わる広告・宣伝を行うようにすることは、ごく普通に考えられる戦略であるものと認められる。
してみれば、引用例記載の発明において、情報受信者及びその属性値を「会員」及び「店舗コード」とし、当該店舗に属する会員対象に該店舗に関わる広告・宣伝を行うような戦略をとるようにすることは、当業者が適宜になし得ることにすぎないものと認められる。

[相違点(2)について]
上記周知例に見られるように、ユーザに情報を送信する際に、当該情報をユーザに送信するか否かを示す識別情報を、ユーザ毎に記憶するようにすることは、周知の技術にすぎない。
してみれば、引用例記載の発明において、上記周知の技術を適用し、各会員毎に「各情報IDに対応する情報を当該会員に送信するか否かを示す送信種別情報」を記憶し、送信タイミングに達した情報を「当該情報の情報IDに対応する送信種別情報が送信を示している送信種別情報が記憶されている」会員に対応する送信先情報の端末装置に送信するように構成することは、当業者が適宜に設計できる事項にすぎないものと認められる。

そして、本願発明の構成によってもたらされる効果も、引用例記載の発明及び上記周知の技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。

5.むすび
したがって、本願発明は、引用例記載の発明及び上記周知の技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第29条第2項の規定により特許を受けることができない。
よって、結論のとおり審決する。
 
審理終結日 2005-03-15 
結審通知日 2005-03-22 
審決日 2005-03-28 
出願番号 特願平11-5551
審決分類 P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 玉木 宏治小林 紀和  
特許庁審判長 武井 袈裟彦
特許庁審判官 長島 孝志
望月 章俊
発明の名称 情報提供装置  
代理人 中村 敦子  
代理人 岡田 英彦  
代理人 犬飼 達彦  
代理人 福田 鉄男  

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