【課題】通信装置の所有者の意思通りに制御し、通信資源、付属装置を効率的な活用する。迷惑通信を排除し、無駄な通信量を削減し、監護、匿名通信、通信装置の付属装置を活用し効率的な経路誘導サービスシステム、安全で便利な電子決済および移動体料金収受システムを実現する。
【解決手段】通信装置の支配者が予め通信装置とネットワークの間に介在する電子秘書に指示を出し、前記電子秘書が前記支配者の指示内容に従って、発信者または通信内容を識別した上で、個々の発信者の通信要求に対して、拒否から制御許可まで複数の処置する方法を備え、内外から到着する通信要求を処理する。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信網上電子装置を用いた通信に関し、特に、通信接続の確立する段階に関し、通信のセキュリティの確保に関する。着信者又は着信側通信設備を支配する当事者の意思に従って、すべての作動を決定する通信とリモート制御機能との一体化に関する。
【背景技術】
【０００２】
電気通信は広範囲に普及した。インターネットを活用したさまざまな情報技術サービスが一般社会に急速に浸透し、高速大容量常時接続通信が一般家庭に普及し、また発信者番号通知も一般化している。現在では発信者が通信の主導権を握っている。
しかしながら、着信者の意思に反する迷惑通信、発信者の身元を偽る詐欺、青少年に悪影響を及ぼすメール、頻繁にメールの大量送信による「攻撃」、受信メールの画面を見ただけで感染してしまうウイルス、「ワン切り」不完了呼によって電気通信事業者のネットワークに障害が発生し、長時間にわたり電話回線が広範囲に麻痺するという状況が生じるなど深刻な被害が発生している。また通信インフラの麻痺及び機能の低下、正常通信の溺没、等マイナスの問題も浮上した。既存の公衆通信仕組みの弱みによる以上の不法的または合法的な行為を誘発している。
従来の迷惑通信防止技術は、各警戒レベルに分けるものが有る。しかし、多様な状況に同時に対応できるものがない。例えば、「指定拒否」は指定された相手に対して受信拒否をするが、不特定多数の相手を全部指定しきれないという問題がある。「指定受信」では指定された相手からしか受信しないが、「鎖国主義」になってしまう（例えば、特許文献１、非特許文献１、２参照。）。特許文献６の方法では、拒否番号を登録・解除するときの利便性を高めることができる。受信者が指定する受信条件により受信拒否し、電子メール送信者側で電子メールの転送可否を判定するが、しかし、条件の決め方自体が難しい、指定しきれないという問題もある（例えば、特許文献２、３参照）。受信した迷惑メールに未開封を記録し送信主へ逆課金するという方法もある（例えば、特許文献４参照）。到着した電子メールから発信者の識別情報を抽出するものもある（例えば、特許文献５参照）。
【０００３】
しかし、これらの技術は、（ａ）少なくとも迷惑通信が１回発生した後、いかに対応する（例えば、特許文献６参照）、及び、オプト・アウト方式の様な法規制は、当事者個人がすべての発信者を対応することを強制され、特にメールの場合ほとんど効果がない。その理由は：１．発信者の数が膨大である。１回のみの発信でも迷惑であり、一つずつに拒否返信することは現実的ではない。例え拒否登録しても登録できる件数の記憶領域が限られ、無限に増やすことはできない。前記法規制も解決できない、例えば外国語の発信内容に対していかに規制するか、発信規制の法制度がない国の存在や、違反者を起訴することは発信者が組織ではなく個人の場合、現実的ではない。２．ワン切り迷惑通信に対処できない。３．「オレオレ詐欺」のような発信者身元を偽ることによる犯罪行為、在宅確認電話が空巣犯罪者に利用されてしまう問題に対応できない。
（ｂ）完璧な受信条件の設定ができない。「指定受信」技術は、重要な通信が受信されない可能性が十分に存在する。厳しい法規制、登録者に対してのみ発信を許すオプト・イン方式は、表現の自由や営業の自由を妨げる。迷惑メールの概念として、どの内容のメールが迷惑メールに当たるかは、個別の着信者側の主観的要素を抜きに決定することができない、共通の基準が存在しない。公知の迷惑メール発信者データベース等の方法によるフィルタリング等の技術は着信者側の主観をまったく反映できないうえ、発信者アドレスが絶えず変化している現状では明らかに対応できる限界がある。
【０００４】
（ｃ）一般に、従来の通信システムは、通信当事者が互いのアイデンティティを知っているという概念に前提としている。例えば個人の電話番号が個人のアイデンティティの役割を果たしている。このため安易に電話番号を未知の相手に公表すると、何かの危険が潜むことになる。一方、ネットワーク上一般向けの個人対個人、個人対会社などの取引、交際、求職など活動において、最初又は最後まで匿名通信必要な場合、一旦相手を招待したら、自分のメールアドレスまたは電話番号が相手に開示されるため、身をひきたい時簡単に相手と関係を断ち切れない。特許文献１０では、匿名通信について、２つのステップを要し、専用の匿名通信センターを通して通信内容から双方の身元情報を取り除く通信チャンネルを設立するという方法が示されている。
（ｄ）技術の進歩に伴い、小形携帯通信装置が多機能化している。通信設備の付属カメラ、付属位置情報装置、などの付属機能の活用、子供、ボケ老人、無人でも安全に通信手段としても監護のためにも使える、潜在的なニーズが満足されていない。例えば位置情報の活用について、走行経路を設定する制御手段を備えるものあるが、計算量が大きく、携帯電話など小形装置に向かない（例えば、特許文献７、８参照）。ＧＰＳ衛星からの電波の受信手段を備えた携帯電話に関するものもあるが、迷惑通信を防止手段がない（例えば、特許文献９参照）。
特許文献１９〜２０、２７〜２９では、移動装置を決済に利用する技術が示されている。しかし、決済暗証番号を安全に使えない。特許文献３０〜３１では、商取引時のキャッシュレス化に関する技術が示されている。しかし、資金の流動性が損なわれる。
【特許文献１】特開平５−１４４８８号公報（請求項１、第１−４図）
【特許文献２】特開２００２−３４４５２４号公報（請求項１−１５、第１−１９図）
【特許文献３】特開２０００−１０８８０号公報（請求項１−５、第１−１８図）
【特許文献４】日本国特許第３２８３８７３号明細書（請求項１−２、第１−３図）
【特許文献５】日本国特許第３００３６４０号公報（請求項１−２、第１−２図）
【特許文献６】特開２００２−２９０５６６号公報（全文、第１−３図）
【特許文献７】特許第３４６００３３号明細書
【特許文献８】特公平６−６０８２１号公報明細書（請求項１−２、第１図）
【特許文献９】日本国特許第３０３９５３６号明細書（全文、第１−７図）
【特許文献１０】米国特許第５８８４２７０号明細書（全文、第１−９図）
【特許文献１１】米国特許第６０７０１４９号明細書
【特許文献１２】米国特許第６３７０２３５号明細書
【特許文献１３】米国特許第６６９１１５６号明細書
【特許文献１４】特開２００１−１４８０９４号公報（全文、第１−７図）
【特許文献１５】特開平１０−３０７９９３号公報
【特許文献１６】特開平９−２２４９７号公報
【特許文献１７】特許第３４８８１９２号公報
【特許文献１８】特許第３０２８７９６号公報
【特許文献１９】特開平８−３３９４０７号公報
【特許文献２０】特開２００１−３３８２５０号公報
【特許文献２１】特開２００３−１４１０４３号公報
【特許文献２２】特開２００２−３７４３０７号公報
【特許文献２３】特開２００３−３６２３０号公報
【特許文献２４】特開２００１−２１７８６１号公報
【特許文献２５】特開２００３−３３３０９７号公報
【特許文献２６】特開２００３−２１６５４８号公報
【特許文献２７】特表２００４−５１９０２２号公報
【特許文献２８】特許第３４９７１４４号公報
【特許文献２９】特許第３３３９８４３号公報
【特許文献３０】特開２０００−２４２７１７号公報
【特許文献３１】特開２００１−３０６９８２号公報
【特許文献３２】特開２０００−４８２８３号公報
【特許文献３３】特開２００２−４２２７３号公報
【特許文献３４】特開平１１−２３４３９３号公報
【特許文献３５】特開２００３−１８６３６号公報
【非特許文献１】迷惑メールへの対応の在り方に関する研究会、”中間取りまとめ”、［online］、平成１４年１月２４日、総務省、ｐ．１０、［平成１６年１月９日検索］、インターネット＜URL：http://www.soumu.go.jp/s-news/2002/020124_4.html＞4
【非特許文献２】迷惑メールへの対応の在り方に関する研究会、”報告書”、［online］、平成１４年１０月７日、総務省、ｐ．３−５［平成１６年１月９日検索］、インターネット＜URL：http://www.soumu.go.jp/s-news/2002/021007_1.html＞
【非特許文献３】ミアス（J. Myers）、”ＲＦＣ１９３９、ＰＯＰ３（Post Office Protocol - Version 3）”、［online］、１９９６年５月、ＩＡＢ(Internet Architecture Boad)標準勧告文書RFC(Request for Comments)、ｐ．１１［平成１６年１月１２日検索］、インターネット＜URL：（ftp://ftp.rfc-editor.org/in-notes/rfc1939.txt）
【非特許文献４】クレシン（J. Klensin）、”ＲＦＣ２８２１、（Simple Mail Transfer Protocol)”、［online］、２００１年４月、ＩＡＢ(InternetArchitecture Boad)標準勧告文書RFC(Request for Comments)、ｐ．３２、［ 平成１６年１月１４日検索］、インターネット＜URL：（ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt）
【非特許文献５】リスリック（P. Resnick）、”ＲＦＣ２８２２、（Internet Message Format)”、［online］、２００１年４月、ＩＡＢ(InternetArchitecture Boad)標準勧告文書RFC(Request for Comments)、ｐ．２６［ 平成１６年１月２０日検索］、インターネット＜URL：（ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
これらはすべて通信機能および通信に関係した機能を備えた電子装置（以下通信装置という）の管理者の意思、即ち迷惑通信をはじめとする他人意思による装置の動作を防止したい、及び自分意思から装置を制御したいという意思に関するものである。従来技術の問題点はこの意思を満足できないことである。この問題点を解決し、前記当事者の意思を満足させることが本発明の目的である。具体的に、前記当事者の意思通りに安心に通信資源を効率的な活用することは本発明の目的である。通信、通信装置を制御する機能、正常的に開放的に従来の通信機能を損なうことなく迷惑通信を排除し、無駄な通信量を削減し、監護、緊急通信、匿名通信、効率的な移動機位置情報サービス、等通信装置の付属装置を活用することが本発明の目的である。経路誘導サービスを提供するとともに、専用設備を設けることなく、交通状態を把握することと、安全で便利な電子決済および移動体料金収受システムを実現することも本発明の目的である。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、図１に示すように、本発明は通信装置の管理者が予め通信装置とネットワークの間に介在する電子秘書に指示を出し、前記電子秘書が前記管理者の指示内容に従って、内側又は外側（通信装置又はネットワーク）から到着する通信要求に対して、複数の処置する方法を備え、前記通信要求を受けた時、前記複数の処置する方法から一つを選び出して、前記通信要求を処置する；本明細書中に前記処置する方法を「待遇」といい、管理者により決める特定の通信要求に対する特定の処置をする方法を意味する。
従来概念の通信は発信者主導が普通であり、例えば相手に電話をかけると相手が受けることが当然と考えられてきた。応答方法も単純であるため、特別な用語で記述する必要がない。本発明は応答方法が多様に成っていて、簡潔に表現する適当な技術用語が存在しない。そのため「待遇」という言葉を使い、当事者双方の関係を表現する。
受信拒否待遇は発信者を完全拒否するという意思表現であり、通信許可待遇は従来の通信ニーズであり、制御許可待遇は潜在的なニーズ、発信者に通信装置の制御をあげたいという意思表現である。
本明細書中に使用する用語「制御許可」は、通信設備は被制御状態になり、発信者の命令を実行し、又は、指定される機能やプログラムを起動できるようにするという管理者の意思を表す。例えば、発信者が遠隔から通信装置付属のカメラを起動し着信側を監視でき、電子決済の確認を求める通信要求を受けた場合、本人認証プログラムが起動される。
本発明の思想は全ての発信者の通信が事前許可を得てから始まる。未知の発信者が許可なしに発信してきた場合、まず発信者の名前を尋ね、発信者身分を判断し、通信するか否かを決定する。これを申請受理という。この流れは受付や秘書の例にたとえることができる。所定のルールを事前に秘書に指示し、秘書は指示された訪問者が来た場合、指示された扱い方で応接し、知られない訪問者が来た場合、氏名や、用件を尋ね、上司に教えられたルールに基づき、訪問者を通させるか否かを決定する。例えば上司が来訪者の用件に興味があったら通させる。上司の古い知り合いと判明したら通させる。賢い秘書なら訪問者を覚え、二回目の訪問者を親切に扱うか、門前払いするかをすぐに決められるだろう。
【０００７】
もし上司本人が来たら命令に従う。上司が制御権あるからである。これは通信機械をリモート制御することにたとえる。
本発明は当事者が予め前記秘書の役割を実現する電子秘書に指示を出し、前記電子秘書が前記当事者の指示内容に従って、通信要求を処理する。電子秘書に発信者ＩＤと、与える待遇の対からなる第１ルールを教え、通信要求に対して、先ず第１ルールに基づいて処置する。また、電子秘書に質問と正解と待遇からなる第２ルールを教えて、第１ルールにより処置方法が分からない場合、発信者に質問し、正解を得られたものを第２ルールに基づいて処置して、発信者のＩＤと待遇を第１ルールとして記憶する。また、正解を得られなかった発信者にどう対応するかも電子秘書に指示しておく。
第２ルールには、当事者の個人情報を含めることができる。例えば当事者の名前を知っていることがルールとして指定されれば、着信者の名前も知らない発信者を拒否することができる。家族や身内の人を合言葉やパスワードで判断することもできる。電話通信の場合音声認識や声紋認識を活用することもできる。
待遇の種類には、外側から到着する通信要求に対して、受信拒否と通信許可があり、内側から発信する通信要求に対して、発信拒否と発信許可がある。決済には、仮想口座（後述）を導入する。
【発明の効果】
【０００８】
（ａ）迷惑メール、迷惑電話の防止。本発明最大の特徴は、迷惑通信が発生する前にその発生が論理上１回でも許されることなく阻止される。１．発信者ＩＤと着信者ＩＤの対が合わないと通信が許さない。たとえ発信者ＩＤを偽造できでも、受信者ＩＤの対と合うようにすることはできない。発信者番号通知など、発信者ＩＤが偽造できない場合、未知の発信者に限られる回数の申し込みの機会を与え、以後は無条件に拒否することで、プログラムによる自動的な迷惑通信の試みを阻止できる。２．ワン切り電話を行おうとする者に対し、自動的に申し込みの手順が始まり、送信者側に通信料金の課金が始まるため、制裁を与えることができる。３．登録されなかった相手に対し決められた手順で自動確認されるので、老人などが不注意に騙される「オレオレ詐欺」にも対処できる。
（ｂ）同時に、着信者の質問を正確に答える相手の場合、例えば着信者の名前を回答できる場合、ほぼ従来と同様の正常的に開放的に通信機能をほぼ損なうことはない。発信者側の自由が制限されることはない。物を売りたい、宣伝する場合、相手が興味ある場合だけ、双方の利益になる。本発明は着信側に予め興味を声明する手段を備え、双方の利益になる通信を拒否しない。
（ｃ）本発明を受信サーバで運用する場合、迷惑通信の通信要求を発信する時点でそれを阻止できる。公衆網に大量の無駄なメールによる通信量の削減、設備の有効利用、通信会社の迷惑通信補償金の節約ができる。受信サーバで運用しなくても、通信契約の変更、法の整備実行のための社会的負担を減らし、迷惑メールの手動判断、削除処理時間の節約ができる。迷惑通信を排除することで、結果的に通信手段の活用が拡大する。
（ｄ）簡単な匿名通信、片側だけが発信を許す片道通信ができる。交際、求人求職活動などをより安心に、気楽に公衆通信網を介して行えるようになる。
（ｅ）当事者の一人一人の主観意識に合わせて自動的に相手を識別し、万一自動処理の問題で相手が不正な通信許可を入手しても、その許可を取消せる。
（ｆ）着信側通信機械の支配者の意思通りに安心に通信装置、通信付属装置を効率的に活用できる。監護、防犯、緊急通信、及び車両用走行誘導機能の一体化が実現できる。このため、新しい使い道、新しいニーズが生まれる。
その他、各実施例別に課題、手段、効果を記述する。
【０００９】
本明細書中に使用された用語、・「通信要求」は、発信者本来の通信目的を達成する前に、電子秘書に届いた通信内容を意味する、例えば、接続要求、又は、着信者が受信する前、電子秘書が受信したメール又はデータ又は承諾要請などが通信要求である、・「ルール」は、処理対象物の検索条件と該検索条件が満たされた時の行動の定義情報の対で表現された、処理の制御に用いられる知識を意味し、・「第１のルール」は、発信者ＩＤ（発信者の識別子）に関する適用条件を有する条件部と、待遇に対応させた行動の実施を指示する実行部とを有するルールであり、「実際に発信者からの通信要求を受ける時、もし前記通信要求から検出される前記発信者のＩＤ（以下「事実発信者ＩＤ」という）が条件部の前記発信者ＩＤと一致すれば、前記待遇に基づいて前記通信要求を処置する」という事柄を表している、・「第１ルールセット」は、第１のルールのセットであり、本明細書において、第１のルールを作成し、第１ルールセットに加えることは、発信者に待遇を与えるという、・「第２のルール」は、期待する申請内容に関する適用条件を有する条件部と、待遇に対応した行動の実施を指示する実行部とを有するルールであり、「もし通信要求から前記期待する申請内容が検出されたら、前記待遇に基づいて前記通信要求を処置する」という事柄を表している、・「第３のルール」は、発信者ＩＤと受信時刻に関する適用条件を有する条件部と、待遇に対応させた行動の実施を指示する実行部とを有するルールであり、「もし通信要求から検出される事実発信者ＩＤが条件部の前記発信者ＩＤと一致し、且つ、前記受信時刻から所定の時間を経過していないとすれば、前記待遇に基づいて前記通信要求を処置する」という事柄を表している、・「第４のルール」は、発信者に提示する質問と、前記質問の正解に関する適用条件を有する条件部と、得点に関する行動の実行部とを有するルールであり、「もし前記発信者から前記質問の回答が正解であるならば、前記得点を計上し、合計の得点を集計する」という事柄を表している、・「第５のルール」は、着信者ＩＤと発信時刻に関する適用条件を有する条件部と、待遇に対応させた行動の実施を指示する実行部とを有するルールであり、「もし宛先ＩＤ（着信者のＩＤ）が条件部の前記着信者ＩＤと一致し、且つ、前記発信時刻から所定の時間を経過していないとすれば、前記待遇に基づいて前記発信要求を処置する」という事柄を表している、・「発信者」は、通信の開始を要求する側当事者及び設備からなる群から選択されるものを意味し、・「待遇情報」は、着信者ＩＤと、第１ルールセットの情報であり、但し前記着信者ＩＤが一つしかない場合、第１ルールセットを意味し、・「ＩＤ」は、通信サービスの提供者により通信サービスを利用する当事者に提供した識別子を意味し、一つの当事者に複数の識別子を提供することが可能である、・「通信許可」は、通信要求を着信者に伝達することを意味し、電子秘書が通信を許可できると判断し、通信要求を着信者に伝達して、従来の通信手段の通信要求を着信する時と同じ状態にし、着信者が通信するか否かの最終判断ができる、・「受信クライアント」は、サーバ上に保存されている着信者のメールを回収できる装置を意味し、例えばメールを受信する携帯電話、及びIAB(Internet Architecture Boad)によって発行された標準勧告文書RFC (Request
for Comments)に規定されたPOP3(Post Office Protocol - Version 3)に準拠したサービスを使おうとしているホストがこれに該当し、・「送信クライアント」は、メールを送信する装置を意味し、例えばメールを送信するクライアント端末、メールを送信するＩＳＰサーバが該当し、・「サーバ」は、サービスを提供する側を意味し、電話の交換機がサーバに該当し、・「受信サーバ」は、メールを受信して保存し、着信者がアクセスする場合、保存されたメールを着信者に渡すサービスを提供する装置を意味し、例えば携帯電話会社のメールセンター、及びPOP3サービスを提供しているホストが該当し、・「通信」は、情報及び制御信号を伝達することを意味し、・「メール」は、電子メールを意味し、・「事前申請」は、当事者が自分のＩＤ(識別子）を含む情報を開示して、発信者に通信の許可を申請させ、発信者が通信要求を出す前に、前記当事者に対して通信の許可を申請することを意味し、・「身元登録」は、通信サービスを利用する当事者をＩＤにより特定し、前記通信サービスの提供者は、前記ＩＤを前記当事者に提供し、前記通信サービスの提供者及び第三者からなる群から選択されるものが前記当事者の身元確認情報を登録することを意味し、・「傍聴許可」は、発信者に着信者側通信装置の送話器により取得する音声信号を取得させることを意味し、・「監視許可」は、発信者に着信者側通信装置を通して、着信者側に設置される撮像装置により取得する画像信号を取得させることを意味し、・「位置取得許可」は、発信者に着信者側通信装置を通して、着信者側に設置される位置取得手段により取得する位置情報を取得させることを意味し、・「注意喚起許可」は、発信者に着信者側通信装置を通して情報を出力させ、着信者の注意を喚起させることを意味し、・「情報転送許可」は、発信者に着信者側通信装置へ情報を転送させることを意味し、・「初期待遇」は、適用すべきルールセットにより待遇が決められない場合に適用する、予め設定された待遇を意味し、・「件名」は、メールヘッダに含まれる人がよめる情報の内容を持つ目的がある情報フィールド（Informational fields）を意味し、・「発信者電子メールアドレス」は、発信者自ら指定した返信用宛先メールアドレスを含み発信者にメールを送信する宛先メールアドレスを意味し、・「待遇申請」は、通信許可を申請することを意味し、従来の発信行為も待遇申請の一形態として考えられ、・「待遇関係」は、当事者双方がお互いに相手に与える待遇によって築く関係であり、・「待遇セット」は、複数の待遇の集合を意味し、・「申請内容」は、通信の許可を申請する内容を意味し、・「期待する申請内容」は、着信側当事者が期待する申請内容を意味し、例えば相手に着信側当事者の名前を尋ねる場合、正確の名前が期待する申請内容であり、即ち質問の正解が期待する申請内容であり、又は興味がある話題や、キーワードや期待する申請内容として指定可能である、・「プログラム実行許可」は、発信者に着信者側通信装置でプログラムを実行させることを許可すること意味し、前記通信装置はＣＰＵ等プログラムを実行する手段が備える。
【００１０】
メール関係用語概念説明。メールの送信の流れは、一般に発信者端末（送信クライアント）から送信メールサーバ（受信サーバ）、送信メールサーバ（送信クライアント）から受信サーバ、受信サーバから着信者端末（受信クライアント）までである。送信メールサーバは、受信サーバと、送信クライアントの二つ役割を持つ。
以下、本発明の実施の形態について図面を用いて説明する。
図１は本発明の一実施形態の概略構成例を示す図である。当事者端末１０１が電子秘書１０２を介在して網１０４における通信を行い、電子秘書は、当事者端末側又は通信サービスを提供するサーバ側に、電話通信の場合は、電話機側又は交換機側に組み込んでも良い。
サーバ側に組み込む場合、通信チャンネルを通して当事者端末とつなげる。指示ファイル１０３は電子秘書に組み込み又は電子秘書と独立しても良い。管理者が直接に指示ファイルにデータを入力しても良い（図に示さず）。指示ファイルはデータ記憶装置の中に保存される。本発明の目的を達成して得る記憶装置であれば、例えば磁気記憶装置、ＲＡＭ、ＲＯＭなどの電子メモリ回路の他に、光学記憶媒体などを採用することができる。指示ファイルの望ましい実装は、マルチメディア情報を含め、相互に関連するデータを整理・統合し、検索しやすいデータベースである。以下、各図面における共通または類似の構成要素については同一の符号を用いる。
図２Ｂはアイテムと待遇に関する第１ルールセットを記録するデータ・データベース（以下Ｒ１ＤＢという）の内容を示すレコードのレイアウト図である。複数のアイテムがありえる。例えば、後述「通信確認」待遇の条件部に発信番号とコマンドの二つのアイテムがある。
【００１１】
テーブルは、データベースのすべてのデータを含む。テーブルは列（column）の集まりである。データが行と列の形式にまとめられている。各行（rows）はレコードを表し、各列はそのレコードのフィールドを表す。レコードのレイアウトは、「フィールド名」（図に示す表の左側）と「フィールド特徴」（図に示す表の右側）により整理された情報から成る。行は、それぞれのフィールドと一致する。主キーはテーブルの各行を一意に識別する値が入った列である。外部キーは、２つのテーブルのデータ間のリンクを設定するための列である。
Ｒ１ＤＢは発信者ＩＤと待遇ＩＤのフィールドがある。
図２Ａは待遇セットの一実施例を記録するデータ・データベース（以下ＴＤＢという）の内容を示すレコードのレイアウト図である。各待遇の具体的な実現は通信装置の違いによって違い、実現できる待遇種類の総数は通信装置の違いによって違う。当事者個人の必要に合わせて待遇セットを拡張、簡略化できる。待遇ＩＤはプログラム内部で呼び出す処理方法（機能）を識別するのに使われ、テキストは利用者に機能の内容を表示に使われる。
図２Ｃは提示情報の一実施例を記録するデータ・データベース（以下ＧＤＢという）の内容を示すレコードのレイアウト図である。前記提示情報は、発信者に提示する質問を含む場合、図２Ｆに示す形式にしてもいい。
図２Ｄは期待する申請内容と待遇に関する第２ルールセットの一実施例を記録するデータ・データベース（以下Ｒ２ＤＢという）の内容を示すレコードのレイアウト図である。
図２Ｅは発信者と受信時刻と待遇に関する第３ルールセットの一実施例を記録するデータ・データベース（以下Ｒ３ＤＢという）の内容を示すレコードのレイアウト図である。
【００１２】
図２Ｆは発信者に提示する質問と、前記質問の正解と、得点に関する第４ルールセットの一実施例を記録するデータ・データベース（以下Ｒ４ＤＢという）の内容を示すレコードのレイアウト図である。前記質問、及びＧＤＢに保存する提示情報は、は、テキスト、音声、及び画像からなる群から選択されるものを含む。
図２Ｇは着信者ＩＤと発信時刻と待遇に関する第５ルールセットの一実施例を記録するデータ・データベース（以下Ｒ５ＤＢという）の内容を示すレコードのレイアウト図である。
図２Ｈは、待遇関係マスタの一実施例を記録するデータ・データベース（以下ＴＲＤＢという）の内容を示すレコードのレイアウト図である。
図４は本発明の一実施形態のフローチャートである。
電気通信網における通信を支援する電子秘書システム（以下「電子秘書」という）を介在する通信を行う方法であって、管理者は予め電子秘書に指示を出し、前記電子秘書が通信装置と電気通信網の間に設置され、前記電子秘書が前記管理者の指示内容に従って、内側（通信装置）又は外側（電気通信網）からの通信要求を処理し、当該方法は、（ａ）前記電子秘書に業務を指示する指示ファイルを構築するためにデータを入力するステップと、前記指示ファイルが以下を有する、アイテムに関する適用条件を有する条件部と、待遇に対応させた行動の実施を指示する実行部とを有するルールで記述された第１のルールのセット（本明細書中「第１ルールセット」という）と（前記第１のルールは、「実際に発信者からの前記通信要求を受ける時、もし前記通信要求から検出される前記アイテム（以下「事実アイテム」という）が条件部の前記アイテムと一致すれば、前記待遇に基づいて前記通信要求を処置する」という事柄を表している、本明細書において、前記第１のルールを作成し、前記第１ルールセットに加えることは、発信者に待遇を与えるという）、（ｂ）以下の操作が可能な前記電子秘書を用いて通信を行うステップと、を有することを特徴とする方法
。（１）発信者からの前記通信要求から前記アイテムを検出する、（２）前記指示ファイルにアクセスする、（３）前記第１ルールセット内の全てのルールを対象として、適用条件が成立しているルールを見つけ出し、前記ルールの実行部を実行する（以下単に、所定のルールのセットを適用するという）、（４）個々の前記通信要求に対して、前記通信要求を着信者に伝達すること（以下、「通信許可」という）と、を含む複数の処置する方法（以下、「待遇セット」という）を備え、前記通信要求を受けた時、前記複数の処置する方法から一つを選び出して、前記通信要求を処置する。
内外の発信者の通信要求を着信した時、前記通信要求から前記アイテム、即ち事実アイテムを検出し（４０１）、指示ファイルを読み込み（４０２）、次の第１ルールセット適用手順で第１ルールセットを適用する。即ち、アイテムと待遇に関する第１ルールセット内の全てのルールを対象として、適用条件が成立しているルールを見つけ出し、アイテムと事実アイテムが一致する条件で、Ｒ１ＤＢ（図２Ｂ参照）を検索し（４０３）、見つかったかどうかを判断し（４０４）、当該レコードが検出された場合、即ち適用条件が成立しているルールを見つけた場合、待遇ＩＤのフィールドから前記発信者に与えた待遇を抽出できる。そして、ルールの実行部を実行する（４０６）。見つからない場合には、予め決めた処置方法、即ち初期待遇に基づいて通信要求を処置する（４０５）。
【００１３】
ルールセットは、構造を有するデータにより処理の制御の記述である。つまり、同じルールセットで異なるデータが複数ある。同じルールセットで異なるデータは類似する処理の制御に用いられる。本明細書は、異なるデータで記述する同じルールセットの場合、何々用ルールセットという。
まず、外側からの通信要求を処理し、発信者毎に待遇を与える場合を説明する。第１ルールセットは、前記アイテムが発信者ＩＤ（発信者の識別子）であり、前記通信要求を拒否する待遇は「受信拒否」といい、前記通信要求を受理する待遇は「申請受理」という。
申請受理は、発信者が着信者に通信の希望を表明する行為を許可することを意味し、前記行為は発信者識別ための情報を含む通信用件を電子秘書に伝えることが可能であり、且つ、提示情報を発信者に提示されてから、発信者の反応を受け取り、前記反応に基づいて通信要求を許可できると判断される前に、発信者本来の通信目的を達成できない。
前記用語「通信用件」は、発信者本来の通信目的を達成する前に、発信者と前記電子秘書の間通信接続を確立して、前記電子秘書に届いた着信者と通信を要求する通信内容を意味する。例えば電話通信の場合、発信者氏名や電話番号、用件を録音して受信者に伝え、且つ、電子秘書が音声案内を送出し、発信者の返事を受け取るが、返事内容が正しいと判断される前に、受信者と会話を許可しない。繰り返しの問答が可能である。すぐに判断と着信者事後の判断が可能である。返事がダイヤル番号、又は音声識別により受け取ることが可能である。
この発明の目的のために、用語「申請受理」は、案内メッセージの提示と反応の受け取る進行中のサイクルを促進するどんなやりとりにも言及するものである。
【００１４】
電子メール通信の場合、メールアドレス、件名などを受信するが、内容が正しいと判断される前に受信者に渡さない、且つ、電子秘書が提示情報を返信して、提示情報に従って発信者の返事内容が正しいと判断される前に受信者に渡さない。
提示情報は着信者が自由に決定できる。例えば、着信者の名前など個人情報を発信者に尋ねるなどできる。
従来の電話技術には、居留守ができる機能をもつものがある。本発明では発信者が誰か判らない場合だけ相手を確認し、確認できたら通信可能にし、発信者が誰か判った場合通話又は拒否することと異なる。
図５は本発明別の一実施形態のフローチャートである。前記指示ファイルは、発信者に提示する提示情報を含み、前記電子秘書は、前記提示情報を前記発信者に提示する操作が可能である。前記指示ファイルは、期待する申請内容に関する適用条件を有する条件部と、待遇に対応した行動の実施を指示する実行部とを有するルールで記述された第２のルールのセット（本明細書中「第２ルールセット」という）と（前記第２のルールは、「もし通信要求から前記期待する申請内容が検出されたら、前記待遇に基づいて前記通信要求を処置する」という事柄を表している）、を含み、前記申請受理は、以下の操作を含み、（ａ）前記通信要求から前記期待する申請内容を検出する、（ｂ）前記第２ルールセットを適用する。ＩＤ検出し（５０１）、指示ファイルを読み（５０２）、第１ルールセットを適用し（５０３）、結果を判断し（５０４）、申請受理は、期待する申請内容と待遇に関す第２ルールセット内の全てのルールを対象として、適用条件が成立しているルールを見つけ出し（５０５）、見つかったか否かを判断し（５０６）、見つからない場合には、予め決めた処置方法、即ち初期待遇に基づき処置する。
【００１５】
例えば、提示情報を前記発信者に提示してから受信を拒否する。又は案内も提示しないで受信を拒否する。当事者により決めることが望ましい。初期待遇は申請受理待遇を除いて待遇セットから選択させることが望ましい（５０７）、第１ルールセットの適用条件が成立しているルールが見つからない時、申請受理待遇を実行するか否かを利用者に選択させる事ができる。
適用条件が成立しているルールを見つけた場合、与えた待遇、即ちルールの実行部に記載した待遇に基づいて通信要求を処置する（５０８）。前記待遇は通信許可及び受信拒否を含み、通信を一部許可、発信者の用件を記録するなど、着信側の通信設備の性能により多様な待遇、即ち多様な処置する方法を通信設備の支配者の意思に従って指定することが可能である。例えば、通信設備が基本的な通信機能しかない場合、電子秘書の通信許可待遇の実施が単に邪魔しない様に通信内容を通過させ、通信許可しないは、単に通信内容を全て遮断する。
本発明の一実施形態を組み込む通信設備が、基本の通信機能と制御させる機能を備える。電子秘書の制御許可待遇の実施が通信設備に被制御状態になるように命令してから、発信者の命令を含む通信内容を通過させる。さらに、情報転送許可、注意喚起許可、位置取得許可、傍聴許可、監視許可、のような多様な被制御状態が実現可能である。
第２ルールセットを利用して送信者にパスワードを発行することによりフィッシング（発信者身元偽造）詐欺を防げる。
第２ルールセットを利用して通信内容から判断して通信を許可することができる。発信の自由が制限されない。通信双方の利益になる通信販売や宣伝等が可能である。
【００１６】
外側からの通信要求を処理する仕組みと同様に、内側からの通信要求を処理できる。例えば、前記アイテムが着信者ＩＤ（着信者の識別子）である発信用第１ルールセットを使用できる。「発信拒否」という通信要求を拒否する待遇と、「発信許可」という通信要求を許可する待遇と、「発信認証」という待遇が使用できる。前記発信認証待遇は、認証プログラムを起動し、パスワード照合などによる認証は成功する場合発信を許可する。例えば、会社の場合、この発明を利用して国際通話等の発信を管理できる。
本明細書において、ある通信要求に待遇を与えるとは、特定の通信内容の通信要求に対する特定の処置をすることをいう。
図６は、図５の説明に記載の本発明において、別の実施形態のフローチャートである。前記通信は電子メール通信であり、前記発信者ＩＤは発信者のメールアドレス（返信用宛先）であり、前記提示情報は電子メールを受信する条件の説明を含み、前記通信許可待遇は電子メールを受信させることであり、前記提示することは発信者に返信することであり、前記通信要求が着信する時、前記電子秘書が、先ず前記第１ルールセットを適用し、適用条件が成立しているルールが見つからない場合には、申請受理を行い、前記申請受理を行うステップには、前記第２ルールセットを適用する時、適用条件が成立しているルールが見つからない、即ち待遇が決められない場合には、前記提示情報を前記発信者に提示してから前記通信要求を拒否する。
発信者のメールアドレスを検出し（６０１）、指示ファイルを読み（６０２）、第１ルールセットを適用し（６０３）、結果を判断し（６０４）、第２ルールセットを適用し（６０５）、結果を判断し（６０６）、提示情報はメールを受信する条件の説明を含み、通信許可の待遇はメールを受信させることである。即ち電子秘書はメールを通過させ、着信者がメールを受信する。受信拒否待遇はメールを受信しない（６０８）、提示情報を発信者に提示することは、提示情報を発信者に返信する（６０７）ことである。
図７は図６の説明に記載の本発明において、別の実施形態の構成を示す図である。電子秘書及び指示ファイルＲ１ＤＢ，ＧＤＢ，Ｒ２ＤＢが受信クライアント側利用者端末７０１に組み込まれてある。符号７０２はＩＳＰ（インターネット・サービス・プロバイダー）の受信サーバを示す。
【００１７】
図８は、図６の説明に記載の本発明において、別の実施形態のフローチャートである。前記電子秘書が、受信クライアント側に設置され、前記通信要求を拒否することは、受信サーバへ削除コマンドを送出して該電子メールを受信サーバから削除させることであり、発信者に提示する通信の許可を申請するための方法は、メールの件名に申請内容を記載することである。提示情報は、少なくとも前記メールの件名に前記申請内容を記載するように促す内容を含み、例えば質問を提示して、その回答を件名に記入する様に促す。
そして、受信サーバにログインし（８０１）、前記メールのヘッダから発信者のＩＤ、即ち発信者のメールアドレスを検出する（８０２）。例えば、一般的なメール受信プロトコールであるPOP3（非特許文献３）に記載したコマンド「TOP 1 0」を送出し、POP3サーバから１番目のメールのヘッダを受信して解析することにより発信者電子メールアドレスを検出できる。
そして、指示ファイルを読み（８０３）、前記第１ルールセット適用手順で第１ルールセットを適用し（８０４，８０５，８０９）、第１ルールセットから適用条件が成立しているルールが見つからない場合、次の例示手順で第２ルールセットを適用する（８０６、８０７）。まず、Ｒ４ＤＢの全てのレコードを対象として、一つずつ正解内容を抽出し（図２Ｆ参照）、抽出した内容に基づいて、前記メールのヘッダに含まれる件名から該当する内容を検索し、採点する。
そして、Ｒ２ＤＢの全てのレコードを対象として、得点数値と一致するレコードを検出し、検出された場合、即ち適用条件が成立しているルールを見つけた場合、待遇ＩＤのフィールドから待遇ＩＤを抽出できる。そして、ルールの実行部を実行する（８０９）。初期待遇を処理する（８０８）。
【００１８】
到着した電子メールから発信者の識別情報を抽出する発明もある（特許文献５）。本発明は到着した電子メールのヘッダから発信者ＩＤを抽出することが異なる。本発明はメールの本体を開封せずに目的を達成できる。そのためメールの本体を開封する前記発明と比べて、特に携帯電話等、サーバとの通信の課金部分の通信量が大幅に減少できる。
図９は、図６の説明に記載の本発明において、別の実施形態の構成を示す図である。電子秘書及び指示ファイルＲ１ＤＢ，ＧＤＢ，Ｒ２ＤＢが受信サーバ９０１側に組み込まれてある。符号９０２が受信クライアントを示す。符号９０３がメールの送信クライアントを示す。
図１０は、図６の説明に記載の本発明において、別の実施形態のフローチャートである。発信者に提示する通信の許可を申請するための方法がメールの件名に申請内容を記載することである。提示情報は、少なくとも前記メールの件名に前記申請内容を記載するように促す内容を含み、前記電子秘書が受信サーバ側に設置され、前記通信要求を拒否することは、前記電子メールの送信クライアントにエラー発生を通告してから通信を中止することであり、エンベロープ（封筒）まで受信して（１００１）、発信者のメールアドレスを検出し、指示ファイルを読み（１００２）、前記第１ルールセット適用手順で第１ルールセットを適用する（１００３、１００４、１００９）。第１ルールセットから適用条件が成立しているルールが見つからない場合、メールの件名を受信するため、前記メールの件名が含まれるヘッダまで受信し（１００５）、そして、前記第２ルールセット適用手順で第２ルールセットを適用する（１００６，１００７，１００９）。初期待遇を処理する（１００８）。
【００１９】
図１１は、図１０の説明に記載の本発明において、別の実施形態の早期決定処理の部分フローチャートである。前記早期決定とは、メール本体の受信が終わる前に、メールの受信を拒否することを決定し実行することを意味する。本発明はメールの件名内容を判断することによりメール本体の受信を拒否することを決定できる。しかし、従来技術のＳＭＴＰ準拠メール送り手はメールのエンベロープを送った後、コンテントを送る前に、認可されているかチェックするステップはあるが、メールのコンテントの送信始めると、ボディを送る前に、認可されているかチェックするステップは無い（非特許文献４参照）。そのためコンテントの送信中通信チャンネルを閉じることにより強制中止（即ち、早期決定）された送信クライアントは、終了されたとき返されたエラーコードを無視して再送信するように実装されたメール送り手が存在する可能性がある。この発明はこの様な従来技術の送り手から受信する場合にも、むだな通信量の発生を阻止できる早期決定を実現できる。
早期決定処理は第１ルールセットを適用するステップ（図１０、１００４）の適用条件が成立しているルールが見つからない時点から始まる。次の第３ルールセットの適用手順で第３ルールセットを適用する。即ち、発信者ＩＤ（この実施例は発信者のメールアドレス）が一致することかつ、受信時刻から検索時刻まで所定の時間を経過していないことの条件に基づいてＲ３ＤＢを検索し（１１０１）、結果を判断し（１１０２）、当該レコードが検出された、即ち適用条件が成立しているルールを見つけた場合、待遇ＩＤのフィールドから待遇を抽出できる。そして、ルールの実行部を実行する（１１１０）。適用条件が成立しているルールが見つからない場合には、メールの件名が含まれるヘッダまで受信し（１１０３）、第２ルールセット適用手順で第２ルールセットを適用し（１１０４、１１０５、１１１２）、初期待遇を処理する（１１０６）。ただし、第２ルールセット実行部の待遇及び初期待遇の中に、受信拒否を含む場合（判定：１１０７）は、事実発信者ＩＤと受信時刻と受信拒否待遇を基にして、第３のルールを作成し、第３ルールセットに加えて（１１０８）、待遇に基づいて通信要求を処置し、ただ待遇中の受信拒否は一時的なエラー状態を送信クライアントへ返してから、通信を強制中止する（１１０９）、そうでない場合は与えた待遇に基づいて通信要求を処置する（１１１２）。第３のルールの実行目的は従来技術のＳＭＴＰ準拠の送り手を従来技術の正式中止できるステップ：ヘッダの受信前で中止させることである。一回実行すれば良いので、第３のルールの実行部が実行されたら、該当ルールを削除する（１１１１）。
【００２０】
ＴＣＰプロトコールのソケット切断コマンド（close）を発行することは前記強制中止の一実施例である。ＳＭＴＰに準拠した送り手は一定時間後送信の再試行が発生する場合、第３ルールセットは拒否履歴として使われる。履歴から強制中止された送信者の再試行を検出できた場合、システムはＳＭＴＰの標準手法によってコンテントの送信を拒否する。再試行が発生しない場合、古い拒否履歴を削除する。この様に、むだな通信量の発生を阻止できる早期決定を実現できる。この目的用の第３ルールセットを中止用第３ルールセットという。
図３０、図３１に示す実施形態は従来のＳＭＴＰの拡張機能として提案する。この機能を実装した送り手と図１０が示す発明を同時に利用する場合、受け手の電子秘書は前記再試行を対応する必要がなく、ＳＭＴＰと別の層に位置するＴＣＰ層のコマンドによる強制中止手段を頼る必要なく、迷惑電子メールに対して公衆網の通信量削減と接続メールサーバの処理がさらに軽減できる。
第３のルールに所定の時間が再試行の間隔（非特許文献４参照）より長く設定すれば、確実に再実行送信を捉え（１１０２のＹＥＳ）、送り手を断念させ、望まない繰り返しの再実行を阻止できる。
ステップ１１０９に、一時的なエラー状態の替わりに失敗応答を送信クライアントへ返しても良い。ヘッダの替わりにコンテントの一部、又は全部を受信してから質問の正解、又は、期待するキーワードが検出されない又は検出された場合が迷惑メールであると判断しても良い。
図１２は、図６の説明に記載の本発明において、別の実施形態のフローチャートである。前記発信者に提示する提示情報は通信の許可を申請させる、前記提示情報は、少なくとも前記電子メールに申請内容を記載するように促す内容を含み、前記電子秘書が受信サーバ側に設置され、前記通信要求を拒否することは、前記電子メールの送信クライアントにエラー発生を通告してから通信を中止することであり、そして、前記電子秘書は前記通信要求が着信する時、先ず前記事実発信者ＩＤが含まれた前記電子メールのエンベロープ（封筒）まで受信して、前記第１ルールセットを適用し、適用条件が成立しているルールが見つからない場合には、前記電子メールのコンテントを受信して、申請受理を行う。エンベロープ（封筒）まで受信して（１２０１）、発信者のメールアドレスを検出し、指示ファイルを読み（１２０２）、前記第１ルールセット適用手順で第１ルールセットを適用する（１２０３，１２０４，１２０９）。第１ルールセットから適用条件が成立しているルールが見つからない場合、コンテントを受信し（１２０５）、そして、前記第２ルールセット適用手順で第２ルールセットを適用する（１２０６，１２０７，１２０９）。初期待遇を処理する（１２０８）。
【００２１】
図１３は、図６の説明に記載の本発明において、別の実施形態のフローチャートである。前記第２ルールセットを適用する時、適用条件が成立している第２のルールを見つけた場合、見つけた前記第２のルールの実行部の待遇を発信者に与える。ＩＤ検出し（１３０１）、指示ファイルを読み（１３０２）、第１ルールセットを適用し（１３０３）、結果を判断し（１３０４）、第２ルールセットを適用し（１３０５）、結果を判断し（１３０６）、初期待遇を処理する（１３０７）。図５との違いは、適用条件が成立している第２のルールを見つけた場合、さらに、保存条件を判定し（１３１０）、条件が満足される場合、電子秘書は見つけた前記第２のルールの実行部の待遇を発信者に与えることである。即ち、前記発信者のＩＤと前記待遇を基にして、第１のルールを作成し、第１ルールセットに加え（１３０９）、待遇に基づいて通信要求を処置する（１３０８）。通常は、見つけた前記第２のルールの実行部の待遇は申請受理でないことが保存条件の一つとする。保存条件が当事者により指定又は変更することが可能である。
この処理を自動審査という。着信者指定の質問を正確に答えた等の場合、この方法利用すれば、受信者に対して一回でも連絡した関係者が全て第１ルールに自動的に記憶され、二度目に同じ質問はされない。申請受理待遇は通常特定の相手に与えない。通信許可待遇を与えた相手にその待遇を降格し、申請受理待遇を与える場合、その相手と通信したこと等の記録として役に立つ。
ステップ１３０７は初期待遇に基づき処置する。この例の初期待遇は、提示情報を前記発信者に提示してから受信を拒否することである。発信者不明の場合、発信者に通信の許可を申請させるために、提示情報を提示することが必要である。申請受理のやりとりで、提示情報を提示しなかった場合、このステップで提示可能である。当事者の意思により提示しないことも可能である。
図１４は、図５の説明に記載の本発明において、別の実施形態の一部分のフローチャートである。この部分の処理は初期待遇の処理ブロック（図５、５０７）に含まれる。即ち第１及び第２のルールにより待遇を決めない場合、前記第３ルールセット適用手順で第３ルールセットを適用する（１４０１、１４０２，１４０５）。適用したら、該当ルールを前記第３ルールセットから削除し（１４０６）、発信者ＩＤと所定の待遇を基にして、第１のルールを作成し、第１ルールセットに加える（１４０７）。適用条件が成立しているルールが見つからない場合には、発信者ＩＤと受信時刻と所定の待遇を基にして、第３のルールを作成し、第３ルールセットに加える（１４０３）。電子秘書は元の初期待遇を実行する（１４０４）。
【００２２】
本発明は発信者不明の場合、発信者に自動返信し、発信者の身元を確認する。しかし、現在大部分のスパムメールの返信先アドレスが偽造されている。自動返信すると、新たなスパムメールを作ってしまう可能性がある。この発明は前記返信先アドレスから二度目のメールを受信したら、所定の身元を確認できる情報が含まれない場合には、当事者が前記所定の待遇を、例えば無視して受信拒否と指定すると、該当アドレスを無視して受信拒否待遇を与え、それから自動返信なしに受信を拒否する。
第３ルールと類似するように、時刻の要素を第１ルールの条件部に取り込んでも良い。例えば、拒否待遇を有する第１ルールを１月以上を経過すると削除する。すると、拒否された発信者に再度初期待遇に戻ることができ、第１ルールセットの膨大化を防ぐことができる。偽造された返信不能のアドレスを直ちに拒否待遇を与える。
電話の場合、この発明は繰り返しの申し込みによる攻撃行為を阻止できる。 本発明は有限回数の申し込み機会を相手に与え、機械などによる繰り返し申し込みを対応する。回数を実行条件に入れ、又は有限回数の申し込み待遇を与えることにより実現できる。ここで第３ルールセットの使用目的と、前記強制中止ための使用目的と異なることを留意して欲しい。
図１５は、図５の説明に記載の本発明において、別の実施形態の構成を示す図である。電子秘書及び指示ファイルＲ１ＤＢ，ＧＤＢ，Ｒ２ＤＢが当事者端末側１５０１に組み込んでいる。リアルタイム相互作用を通して通信する手段を備える。制御権を持つ当事者端末１５０２は、着信者の介入なしで着信当事者端末１５０１と通信でき、制御コマンド１５１０を端末１５０１に送れる。通信許可待遇を与えた当事者端末１５０３は、端末１５０１と通常の双方向通信１５２０が行える。通信と制御が共存できる。
図１６は、図５の説明に記載の本発明において、別の実施形態のフローチャートである。通信は電話通信であり、提示情報は前記通信を受ける条件の説明を含み、そして、通信要求が着信する時、電子秘書が、先ず第１ルールセットを適用し、適用条件が成立しているルールが見つからない場合には、申請受理を行い、前記申請受理を行うステップには、前記提示情報を発信者に提示して、前記発信者の反応を受け取って、第２ルールセットを適用し、適用条件が成立しているルールも見つからない、即ち待遇が決められない場合には、初期待遇に基づき、前記通信要求を処置する。ＩＤ検出し（１６０１）、指示ファイルを読み（１６０２）、第１ルールセットの適用し結果を判断し（１６０３、１６０４）、条件が成立しているルールが見つからない場合には、提示情報を発信者に提示してから、前記発信者の反応を受け取り（１６０５）、第２ルールセットを適用し結果を判断し（１６０６、１６０７）、結果によって初期待遇又は与えた待遇に基づいて通信要求を処置する（１６０８、１６０９）。
【００２３】
図１７は、図５の説明に記載の本発明において、別の実施形態のフローチャートである。提示情報は、発信者に提示する質問を含み、期待する申請内容は、所定の合計の得点を得た前記質問の回答であり、指示ファイルは、前記発信者に提示する前記質問と、前記質問の正解に関する適用条件を有する条件部と、得点に関する行動の実行部とを有するルールで記述された第４のルールのセット（以下「第４ルールセット」という）（前記第４のルールは、「もし前記発信者から前記質問の回答が正解であるならば、前記得点を計上し、合計の得点を集計する」という事柄を表している）を含み、前記電子秘書は、さらに以下の操作が可能である。（ａ）前記質問を前記発信者に提示する、（ｂ）前記質問への前記発信者の回答を受け取る、（ｃ）前記第４のルールのセットを適用する。
この部分の処理は繰り返し案内メッセージの提示と反応の受け取り及び反応の正確さの判断手順を例示する。図１６の「提示情報を前記発信者に提示して、前記発信者の反応を受け取る」の処理ブロック（図１６、１６０５）に相当する。Ｒ４ＤＢからルールのデータ・レコードの処理完了判断し（１７０１）、抽出し（１７０２）、質問を発信者に提示して、前記発信者の回答を受け取る（１７０４）。一つの質問は複数の正解を存在することがある。例えば、識別番号を確認する場合、複数の識別番号が存在する。この実施例は、複数の正解を確認する（１７０５）ための仕組みは、同じ質問をしなくて、前回の質問時受け取った回答を次の正解であるかどうかを照合する。Ｒ４ＤＢに質問の提示不要標識を追加すること、または、質問フィールドを空欄にすることにより判断する（１７０３）。全ての質問を提示することが必要でないケースがある。例えば、相手の身元が最初の質問により判断できるケースがある。この実施例は、合計の得点（１７０６）が所定の点数を超える場合は問答を早期終了する仕組みを持つ（１７０７）。この部分の処理を実施するシステムは、提示情報の種類に応じて、発信者の反応を受け取る手段を備える。例えば、電話のダイヤル番号を押すことにより回答を得る場合、押された番号を認識する手段を備える。
【００２４】
電話の場合、発信者の識別は発信電話番号により行う。この発明は当事者が発行する識別番号またはパスワードにより発信者を識別することが可能である。識別番号を使い、不特定の発信端末から通信が可能である。
図１８は，本発明別の実施形態の構成を示す図である。電子秘書及び指示ファイルは通信サービス提供サーバ１８０１側に組み込む。当事者別に指示ファイルを有し、複数の当事者が利用可能である。利用権が有る当事者は任意の端末１８０３または電話機から自分の指示ファイルを構築するためにデータを入力する（１８２０）。発信者端末１８０２の通信要求または制御コマンドが電子秘書サーバ経由で送られる（１８１０）。
図１９は、本発明別の実施形態の構成を示す図である。電子秘書はネットワークを通して指示ファイルにアクセスする（１９３０）手段を有し、一人の支配者は複数の電子秘書（１９０１、１９０４）を利用する。前記複数の電子秘書は一つの指示ファイル１０３にアクセスする。符号１９４０はサーバ１９０４経由のメールを示す。電子秘書が作成する第５ルールセット（図２Ｇ、Ｒ５ＤＢ）も指示ファイル１０３に保存する（図１９に示さず）。
図２０は、図５の説明に記載の本発明において、別の実施形態の発信処理部分フローチャートである。
前記指示ファイルは、さらに、着信者ＩＤと発信時刻に関する適用条件を有する条件部と、待遇に対応させた行動の実施を指示する実行部とを有するルールで記述された第５のルールのセット（以下「第５ルールセット」という）と、を含み、前記電子秘書は、さらに、以下の操作が可能であることを特徴とする方法。（ａ）前記第５ルールセットを適用する、（ｂ）通信要求を着信者に送り、待遇を受け取る、（ｃ）前記第５のルールを作成し、前記第５ルールセットに加える。
【００２５】
宛先の着信者ＩＤ、発信時刻、待遇に関する第５ルールセット内の全てのルールを対象として、適用条件が成立しているルールを見つけ出し、結果を判断し（２００１、２００２）、適用条件が成立しているルールが見つかった場合、与えられた待遇に基づいて発信要求を処置する（２００４）。前記ルールが見つからない場合、通信要求を着信者に送り、待遇を受け取る（２００３）。着信の相手は本発明の電子秘書の場合、所定の返却コードにより受けた待遇を判別し通信する（２００５、２００６）。着信の相手が従来技術を用いている場合、例えば、従来のメール受信サーバである場合は、永続のエラーコードが受信されたら、受信拒否とみなすことが望ましい。
受けた待遇が「直ちに通信できない」待遇の場合、着信者ＩＤ、発信時刻、と待遇を基にして、第５のルールを作成し、第５ルールセットに加える（２００７）。この発明の主な目的は迷惑通信を発生源において阻止することである。好ましくは図１８、１９のようにサーバで運用し、発信者がＲ５ＤＢに、受信拒否待遇を含む「直ちに通信できない」待遇の入力（２００７）を阻止できない。相手に与えられた待遇が受信拒否である場合、所定の時間内に繰り返しの発信は阻止される。サーバの管理者により前記の所定の時間を設定することが望ましい。例えば、「一時間以後再度掛けてください」等の待遇が与えられれば、送信サーバ側で実施可能である。Ｒ５ＤＢをクリアしない場合、無差別に大量迷惑通信の発信者のＲ５ＤＢレコード数が大きくなる。サーバの管理者がＲ５ＤＢレコード数によって、当該発信者の送信効率を下げるか、警告するなどの管理が可能である。
内側から発信する通信要求に対して、通信装置の管理者が設定する発信用第１ルールセットにより待遇を実施できる。発信用第１と第５のルールセットの目的が異なることに留意して欲しい。
【００２６】
図２１は電子秘書利用者同士の間で匿名通信を行うシステムを示す。第１及び第２の当事者は本発明の電子秘書の利用者である。電子秘書は図１に示すように、端末と通信網のあいだで動作し、当事者端末側又は通信サービスを提供するサーバ側に組み込んでいる（図２１に示せず）。第１及び第２のデータはそれぞれ第１及び第２の当事者の個人情報である。これらの情報はＰＤＤＢを記述する図３Ａに示され、電話番号等当事者ＩＤ、名前、筆名、住所、学歴、職歴...などを含む。サーバ・システム２１０３は匿名通信を希望する当事者の個人情報ＰＤＤＢ及びＶＤＢを保存し、匿名通信を始めるために、通信相手を検索するなどサービスを提供する。
この形態は、２つ以上の当事者の間で匿名の通信に関する。対照的な背景技術が主に特許文献１０参照。課題が簡単に手軽な匿名通信の実現すること。主な手段は制御許可待遇により当事者間の通信チャンネルの作成である。
図３Ａは当事者データに関する一実施例の当事者データ・データベース
（以下ＰＤＤＢという）の内容を示すレコードのレイアウト図である。
図３Ｂは確認要請を記録するデータに関する一実施例の確認データ・データベース
（以下ＶＤＢという）の内容を示すレコードのレイアウト図である。
図３Ｃは立証者情報を記録するデータに関する一実施例の立証者データ・データベース
（以下ＶＲＤＢという）の内容を示すレコードのレイアウト図である。
図２２は前記第１の当事者の処理の部分フローチャートである。図２３は前記第２の当事者の処理の部分フローチャートである。図２４は前記サーバの検索、データの送り、待遇交換処理部分のフローチャートである。
本発明は二人以上の複数の当事者同時に利用可能である。以下の記述は、第１の当事者がデータ開示相手に与える待遇をＰＤＤＢに入力し、サーバに代行許可待遇を与え（２２０２）、第２の当事者が検索要求を前記サーバに送信する（２３０２）こととする。

ＰＤＤＢの他、当事者データに関するもう一つの一実施例は実施例４参照。
【００２７】
当事者２１０１、２１０２が第１、第２のデータと、前記データを開示するための少なくとも１つの当事者ルールと、サーバ２１０３に入力し、前記サーバに通信許可待遇を与える（２１１０，２１１１、２２０１、２３０１）。サーバが当事者データ、当事者ルールを受信し、ＰＤＤＢに保存する（２４０１）。当事者ルールは、情報を開示して、開示しない候補者のプロフィール、情報を開示する前に確認が必要かどうか、また、どんな情報がどんな候補者に開示されるかの情報を含み、ＰＤＤＢの開示認可プロフィールに保存する。第２当事者が検索基準を含んでいる検索要求を送信（２１１２、２３０２）し、サーバがそれを受信し、ＰＤＤＢを検索する（２４０２）。前記基準を満たす記録の数等の検索結果を第２当事者に送る（２３０３、２４０３）。第１のデータが検索基準を満たすかどうかを決定し（２４０４）、前記検索基準を満たす第１のデータがあった場合、第１当事者ルールを満たすかどうかを決定し（２４０５）、満たした場合、第１のデータを第２の当事者に送る（２１１３、２３０３、２４０６）。第１の当事者がサーバに代行許可待遇を与え、第１のデータを開示する対象となる第２の当事者に与える待遇をＰＤＤＢに入力した場合、サーバが第１の当事者の操作を代行して、第２の当事者に、前記第１のデータに含まれた開示する対象に与える待遇を前記第２の当事者を与える（２１１３、２４０７）。第２当事者ルールを満たすかを判断し（２４０８）、満たした場合、第２の当事者の第２のデータを前記第１の当事者に送る（２１１４、２２０３、２４０９）。
当事者ルールに、情報を開示する前に、本人の確認が必要条件として含めることが可能である。当事者ルールに、当事者に関する情報が確認されたことを条件として指定することが可能である。
当事者に関する情報の確認をサーバに依頼することが可能である。確認に関する情報を確認データベースＶＤＢに保存し、立証者情報を立証者データ・データベースＶＲＤＢに保存する。
【００２８】
当事者の指示ファイルがネットワーク中のサーバに保存する場合、アクセス許可情報（ＩＤ、パスワード）に基づき、サーバにログインして、指示ファイルにデータを入力する。代行許可の実施は依頼者から入力されたアクセス許可情報に基づき、指示ファイルに入力する。指示ファイルがローカルに保存される場合、代行許可の実施はサーバに情報転送許可待遇を与え、ローカルの指示ファイルに入力することにより実現する。
サーバが検索要求を処理し、第１のデータが検索基準を満たすかどうかを決定する処理、及び、第１（第２）のデータを開示する第１（第２）当事者ルールを満たすかどうかを決定する処理の実施は、特許文献１０による公知である。キーワード、ファジー論理と自然言語検索ツールを含め、使うことができる多くの検索テクニックがある。
本発明によると、着信者が通信成否のかぎを握るため、電話番号等当事者ＩＤとアイデンティティのつながりを切断できる。個人の電話や、メールが容易に信頼できる範囲の相手としか接続しない。公衆網における専用網のような効果が得られる。本発明は相手に知られた、使っていた公衆網通信ＩＤでも、後から相手の通信を拒否できるため、自らアイデンティティを公表しない限り、匿名性が保ちながら、通常の番号を使って、簡単に、全ての通信機能が使える匿名通信を実現できる。たとえば、本発明はアイデンティティを通信内容から取り除く専用の中央コントローラを介在させる必要がない。特別な通信チャンネルを作る必要もない。
専用の中央コントローラを介在し、また、当事者の間データ交換のために２つのステップを要する匿名通信の技術（特許文献１０参照）と比べ、本発明は簡単に匿名通信や手軽なデータ交換を実現することできる。
通信サービスの提供者は、ＩＤを前記通信サービスの利用する当事者に提供し、前記通信サービスの提供者及び第三者からなる群から選択されるものが前記当事者の身元確認情報を登録する方法を利用して、当事者の身元確認情報がサーバに保存される。サーバを管理する通信サービス提供者又はそれと連携するセキュリティサービス業者などの第三者は法定の情報保護義務が有る。違法行為による被害の場合は法的手段による相手の身元調査が可能であるので、安心に通信できる。
【００２９】
相手に待遇を受信拒否に設定し直せば、通信関係を断ち切れる。必要な場合、追加ＩＤを使い、通常使用の電話番号と別に、匿名通信専用の電話番号を新規契約する。例えば東日本電信電話株式会社(NIPPON TELEGRAPH AND TELEPHONE EAST CORPORATION)は本来の契約者回線番号の他に追加番号サービスを利用でき、追加番号を発信者番号として利用もできる。メールの場合新規アドレスを追加ＩＤとして使える。匿名通信の必要が無くなったら、待遇を受信拒否に設定することが負担と感じる場合、追加ＩＤの契約を廃止すれば良い。 通常言葉の待遇の概念は授受関係である。本発明の用語待遇も授受関係であるが、「待遇交換」とは必ずしも同時に交換ではない。本発明は片方だけが通信許可を与え、もう片方だけが通信することもできる。
図２５は、図４の説明に記載の本発明において、制御許可待遇を加えた別の実施形態のフローチャートである。図２６は、図２５の説明に記載の本発明において、一実施形態の構成を示す図である。端末Ａ２６０１の管理者が端末Ｃ２６０３に情報転送許可、プログラム実行許可待遇を与えた。端末Ｃから端末Ａに情報を転送し、データを端末Ａの記憶装置１３に書き込み（２６１０）、注意喚起許可待遇を与えた場合、端末Ａを通して表示部１８に情報を出力させ、スピーカー１７に音声を出させ、近くにいる当事者の注意を喚起させることが可能である。端末Ｂ２６０２と端末Ａは通常の双方向通信を行う（２６２０）。
端末Ｃから銀行の電子決済の確認を求める情報を受信した場合、認証プログラムが起動され、端末Ａの所持者は指紋センサーを通して指紋を入力し、認証プログラムは入力される指紋情報を基に、登録した指紋情報と照合し、一致する場合にのみ、予め登録された暗証番号を端末Ｃに送信して決済を確認する。
【００３０】
図２７は本発明別の実施形態の構成を示す概念図である。移動機２７０１の支配者は端末Ａ２７０２の発信者に位置取得許可待遇を与えた。端末Ａから位置情報取得コマンド２７１１を発行し、移動機はそのコマンドに従って、設置される位置取得手段により位置情報を取得し、取得した位置情報を端末Ａに転送する（２７１２）。前記位置情報は、受信したＧＰＳ（Global Positioning System）位置信号、受信したＧＰＳ位置信号から変換された位置情報、ＰＨＳ（Personal handy phone）端末の現在位置情報、及び携帯電話基地局位置情報に基づいて提供された移動端末位置情報からなる群から選択されるもの（以下「具体位置」という）を含む。具体位置は、ＧＰＳ衛星２７０４から受信したＧＰＳ位置信号、受信したＧＰＳ位置信号から変換された位置情報、ＰＨＳ端末の基地局２７０５位置情報に基づいて提供された現在位置情報、及び携帯電話基地局２７０６位置情報に基づいて提供された移動端末位置情報からなる群から選択されるものを含む。着信者側通信装置は移動通信装置（以下、「移動機」という）は、予め登録されたＩＤを有する端末Ａに通信要求を出す場合には、速度又は、前記位置情報を検知して端末Ａに転送し（２７１４）、移動計画情報を端末Ａに転送し、端末Ａに、さらに、（ａ）情報転送許可と、（ｂ）注意喚起許可と、の待遇を与える。端末Ａは移動機に情報転送し、移動機の情報表示手段に情報を出力させ、移動機の注意喚起手段を通して、近くにいる当事者の注意を喚起させる（２７１５）。
例えば、近くにある移動中の車両、登山者、等の相互位置通告希望グループが相互の位置を通告し、表示できる。速度取得許可を与えた端末Ａに前記位置情報取得コマンドと同様に、移動機の速度を取得できる。すると、端末Ａが必要な時だけ、移動機から移動情報を取得できる。移動機の電気的構成、移動速度及び方向の算出、交通状態を推定は特許文献１４により公知である。前記注意を喚起させることは、音声、光、及び振動からなる群から選択されるものを前記移動機に発生させることを含む。前記移動計画情報は到着目的地情報を含み、前記移動機に転送する情報は地図情報、推薦ルート、現在ルート、前方渋滞情報、迂回路情報及び天気情報からなる群から選択されるものを含む。前記位置情報は、具体位置を含む。端末Ｂ２７０３と移動機は通常の双方向通信を行う（２７１３）。
徘徊老人を監護するシステムは数年前にも現れた。本発明は着信者の位置情報を取得（制御）できる要素だけではない。本発明は通話もできる要素が含まれることを留意されたい。
【００３１】
図２８は動的に経路誘導に関する本発明別の実施形態のフローチャートである（図２７参照）。この例は位置情報取得機能を有する移動端末、例えばＧＰＳ搭載の携帯電話に、効率的に車両用走行誘導機能を提供することを目的とするものである。予め登録されたＩＤを有する固定機のサーバ端末に通信要求を出す場合には、移動機の現在地、目的地情報をサーバに送信し、サーバがそれを受信する（２８０１）。サーバが推薦経路を検索し、移動機に送信してから（２８０２）、所定の間隔で推薦経路の渋滞情報を検索し（２８０３）、渋滞が発生するかを判断し（２８０４）、発生する場合、位置取得許可待遇が与えられたサーバが移動機の現在位置を取得し、進行経路を確認して（２８０５）、進行経路の前に渋滞が発生する場合、迂回路を検索し（２８０６，２８０７）、迂回路存在する場合、情報転送許可と、注意喚起許可待遇を与えられたサーバが、迂回路情報を移動機に転送してから、音声で運転手に知らせる（２８０８）。
経路探索は多くの計算量と計算速度が必要である。動的な道路交通情報を移動機から検索することは非効率である。本発明は安価な携帯式移動端末が行うことができない操作をサーバに任せて、巻き込まれる可能性の有る渋滞が発生する時だけ移動機に通信し、迂回路情報を知らせる。サーバに制御許可待遇を与えることにより、着信側運転手が自ら行う操作は必要でない。経路探索、迂回路検索は、特許文献７、８により公知である。
図２９は位置情報等に関する本発明別の形態の概念図である。移動機２７０１が、位置変化を検知した場合に、前記変化した位置情報を予め登録されたＩＤを有する端末Ａ２７０２に転送する（２９１１）。端末Ａは移動機に情報転送許可、注意喚起許可の待遇を与える。制御許可が傍聴許可を含む。移動機の支配者は端末Ａの発信者に傍聴許可、監視許可待遇を与えたとする。
端末Ａから通信要求、傍聴コマンド、監視コマンドを発行する（２９２１）。移動機はそのコマンドに従って、設置される送話器により取得する音声信号、撮像装置により取得する画像信号、を端末Ａに送る（２９２２）。この例は、子供を監護するための移動機に使える。例えば、親は子供の居場所を調べ、子供の公園遊びや、通学など活動環境を傍聴できる。子供が放課時、移動中などに変化した位置情報を親の端末Ａに自動的に転送する。移動機は望ましくＰＨＳを使い、情報の転送はパケット通信であるメールにより行う。端末Ａは望ましくＡＤＳＬ回線などでインターネットに常時接続するパソコンを使い、移動機を携帯する子供の居場所を地図上に実時間表示する。車の防犯にも使える。予定外の車両の移動があれば所有者に警告が送られ、追跡できる。タクシーや運送業務など高い位置精度が必要な場合は、ＧＰＳ位置取得手段を用いることが望ましい。
【００３２】
地図データに移動機の位置情報を付加して画像に表示する画像表示部が特許文献９により公知である。
本発明の第１ルールセットは着信者（管理者）主導の仕組みであり、管理者が決める任意の発信者に位置取得許可待遇を与えることがでる。そのため、受信機に固定されたサービスセンター等第三者の中継を頼ることなく、発信者は直接に移動機の位置を取得できることが特許文献９に示す発明と異なる。
図３０は請求項１３１記載のシステムの一実施例本発明のメール受信の実施形態（図１０）とペアに運用するためのメール送信クライアントの構成を示す図である。送信クライアント３００１の記憶装置１３に保存される電子メール３００３を受信サーバ３００２に送信する。電子メール３００３の構成の実施例は従来技術のＳＭＴＰ（非特許文献４、非特許文献５）参照。図３１は請求項１３１記載のシステムが利用する請求項１１３記載の方法の前記送信クライアントの一実施例のフローチャートである。セッションの初期化、送信クライアントの初期化（３１０１）。エンベロープ送信は（３１０２）、ＳＭＴＰ準拠コマンド：MAILコマンド、RCPTコマンドを発行することにより行い、発信者及び受信者メールアドレスを受信サーバに伝え、エンベロープが受け入れられたか否かをチェックする（３１０３）。ここまでの処理はＳＭＴＰと同じである。ボディを送信する認可がヘッダに含まれた情報により判定するため、ヘッダに含まれた情報フィールドを送信し（３１０４）、情報フィールドに着信者が指定の受信条件を判断できる情報を含み、認可されているかをチェックする（３１０５）。本発明はこのステップを「INFOコマンド」という。受信サーバは受信した前記エンベロープと、情報フィールドに基づいて、着信者が指定する受信条件と照合し、次のボディの送信を認可するか否かを決定することができる。認可された場合、従来のDATAコマンドを発行しコンテントを送信する（３１０６）。認可され受け入れられた場合、送信の正常処理、記憶装置１３から送信済みメールを削除する（３１０７、３１０９）。認可されない場合エラー処理する（３１０８）。
【００３３】
従来技術ＳＭＴＰはエンベロープを認可した後、コンテントが一つのブロックとして送信し、認可チェックをする。メール転送プロトコールの階層のコマンドだけ利用する場合、コンテント全体の受信が終わらないと、コンテントの受信を拒否することができない。そのためコンテントの内容により受信拒否すべきと判断できでも、すでに無駄な通信が発生してしまう。一方、すでに広範囲に使われたコンテント仕様（非特許文献５）に、人がよめる情報の内容を持つ目的をもつ件名(Subject)、注釈(Comments)、キーワード(Keywords)という情報フィールドは、着信者が指定の受信条件を判断できる情報を記載できる。既存のメール通信ソフトでも前記フィールドに情報を記載する手段が備えている。発信者が最初に着信者の受信条件が分からない場合、受信サーバ側が自動返信手段により、着信者の受信条件を発信者に伝える。更に、一回だけその受信条件を満足した発信者のメールアドレスが記録され、２回目以後の送信は、エンベロープに含まれる発信者アドレスから判断して、前回受信条件を満足した発信者であった場合、情報フィールドをチェックしないで、コンテントを通過させる。以上によって、受信サーバは、受信したエンベロープと、前記ボディを受信する前に受信した情報に基づいて、前記ボディの送信を認可するか否かを決定できる。
ボディの送り認可基準として、前記情報フィールドをヘッダから切り分け、コンテントの前に送ることが望ましいが、既存の通信ソフトを最大限に利用するため、前記情報フィールドをヘッダから抽出して、先に送り、認可されたら、コンテントを従来から変えずに、即ち従来のコンテントを送信するDATAコマンドで送信しても良い（３１０６）。または、ヘッダを先に送信して、認可されたら、ボディを送信してもいい。
以上のように、本発明はすでに広く受け入れられている件名フィールド利用し、迷惑メール通信を防止できる効率的なメール通信システムを構築する。
【発明を実施するための最良の形態】
【００３４】
本発明はサーバ側で運用する場合、迷惑通信の防止と網全体の通信量を削減できる効果が同時に得られる。制御許可機能を同時に使用すると、多機能端末が実現される。パケット通信による接続と、仮想口座に基づく与える待遇と、携帯電話付属の指紋認識機能により認証と、から構成される決済システムにより、強固で便利なキャッシュレス商取引が行える。
【実施例１】
【００３５】
多機能電話機（３２０１）
図３２は、構成を示すブロック図である。符号１７はマイク、スピーカーである。図３３Ａ〜Ｄは、ＴＤＢ、Ｒ１ＤＢ、Ｒ２ＤＢ、Ｒ４ＤＢ）を示す。提示情報は、発信者に提示する質問である。質問は予め録音された音声ファイルである。この例では、質問フィールドが空欄であることは質問が提示不要であることを示し、問答が早期終了するための所定の合計の得点が３であり（図１７、１７０７参照）、自動審査の保存条件は合計得点が５であった場合は、自動的に発信者に第２のルール実行部の待遇を与える（図１３、１３１０参照）。
図３４は処理の概略フローチャートであり、基本部分は図１３と同じである。本実施例は当事者端末が電話機であるか、または当事者端末機能がパソコンに組み込まれ、または電話機専用の外付けアダプター等としても実現できる。初めて着信者が知らない電話番号からかかってくる相手に質問のメッセージを流し、相手がダイヤルボタンを押して応答する。応答を判断して待遇を決める。
図３５は自動審査により関係者の電話番号に正常通話できる待遇を自動的に与える一作動例を示す図である。
基本的な迷惑通信防止機能から多彩な機能が設定可能である。この例の指示ファイル設定は次の機能を実現できる。相手の電話番号毎に指定受信（待遇ＩＤ＝４）、指定拒否（待遇ＩＤ＝１）、未知の相手の場合申請受理が必要なので、呼出音を鳴らずに自動的に直ぐに受話するので、相手側は通信料金を課金される。これにより機械からの不完了呼（ワン切り）電話の発信者に経済上の制裁を与えることができ、且つ発信者が正確の返事がないので、合計採点＝０、待遇ＩＤ＝０、拒否し、番号が受信履歴に残ることもない。
ただし許可を与えた相手は通常と同じ呼出音を鳴らし、受信者が受話するまで課金はされない。最初の質問で着信者の名前を間違えると、ただちに受信を拒否される。他の用件で、４を押すと第２問が送出され、不動産の販売に関するものなら１、英会話なら２、生活用品なら３、スポーツ用品なら４、のダイヤルボタンを押すように促す。各選択がされると得点に応じて自動的に着信音を鳴らしたり、着信音を鳴らさずに録音したり、通話を切断したり、通話しても発信者番号を自動記憶しない、又は自動記憶する。暗証番号５６７８が押されると、呼出音を鳴らさずに自動的に通話接続する。これにより自宅のベビーシッターや子供を監視傍聴ができる。例えば子供用の携帯電話に親が通話するか傍聴するかを選択できる。
【００３６】
この例の最初の質問は簡単であるが、実際の使用状況に合わせて複雑に設定することが可能である。例えば姓と名とを２つの質問に分けて順番に提示し（一つ目に正解してから２つ目が提示される）、それぞれ５つの選択肢を提示する場合、でたらめに回答して正解になる確率は２５分の１に下がる。
正解欄に設定する番号は工夫次第で多彩な機能を持たせることができる。例えば内線番号と名乗って使用可能であり、案内質問を”内線番号を押して下さい”にすると、その番号を知っている相手の電話が発信番号と無関係に受けられる。
相手の自宅電話機の発信番号に待遇を与えた場合、同じ相手が公衆電話から発信したら、案内メッセージに身分確認として、相手の自宅番号を入力してもらい、入力した番号と待遇情報とを照合して待遇を確定できる。
待遇申請を審査する具体方法は、当事者の装置の具体構成によって違う。本発明の審査段階の目的を達成して得る方法であれば、多様な方法を採用することができる。例えば音声認識や、画像認識を活用することが考えられる。
銀行等で使われている既存技術の自動電話取引は発信者に音声案内を流し、発信者がダイヤルボタンを押して操作し、暗証番号による客様本人の確認をするものがある。本発明は発信番号毎に応答方法が違うことと、発信者が事前に暗証番号などを登録する必要がないことと異なる。
この例は電子秘書が当事者意思をルールと点数によって受け付けるが、自然言語による受付も可能である。例えば”私の名前を知っている人の電話を受ける。”、”中古車販売関係の勧誘電話を受ける。”。電子秘書は公知のルールベース技術（例えば、特許文献１１参照）によって、これらの要求を聞き取り、足りない情報をユーザに入力させ、必要なルールを編成することが可能である。
本発明電子秘書は、公知技術（例えば、特許文献６参照）により電話交換機及び関連サービス提供サーバ側に設置することができる。
記号２１は電気錠制御ユニットであり、記号２２は被制御装置の電気錠である。番号８７６５が押されると、得点＝１０、待遇ＩＤ＝６、解錠信号が出力され、玄関扉を解錠する。解錠用通信回線は、電話回線以外では、赤外線等近距離通信手段を用いても良い。
本発明は、通信可否の判断が発信者ＩＤに依存しない第２ルールセットという要素が含まれる点が特許文献２１に示す発明と異なる。そのため、通信内容から発信者を認証でき、リアルタイムの制御ができる。
【実施例２】
【００３７】
留守番電話機（３６０１）
図３６は、本実施例の電話機構成を示す図である。図３７Ａ〜Ｃは、ＴＤＢ、Ｒ１ＤＢ、応答ガイダンス（提示情報）を記録するデータ・データベース（ＧＤＢ）を示す。
この例は本発明の概念、全ての通信が複数の待遇による許可制であり、許可なしの相手に許可を与える手段を提供することを例示する。この例は判らない相手が掛けた電話を録音し、直接受けない。これより老人など弱者を詐欺犯罪から守る。業務など不特定相手に使用する場合を除いて、ある程度限定された通信範囲を持つ利用者に適している。登録なしの部外者からの電話を全て拒否することも可能であり、使用時間の累積に伴い、待遇設定が自然に完成し、当事者に過度の負担なく目的が達成できる。
例示する初期待遇は居留守であり、相手の声で身分確認できる場合直ぐ通話できる。最後通話した相手の番号をボタン一つで簡単に登録できる等操作上の利便性を工夫することが望ましい。大事なお客様がある場合、予め相手の番号を登録しておく事ができる。
発信者の識別はグループによる識別が可能である。例えば地域番号による識別し、故郷の番号に通信許可を与えることができる。この例は単純で使いやすく、製造コストも低い。電話機専用の外付けアダプターや、交換機及び関連サービスを提供するサーバ側において実施することができる。
【００３８】
従来はお金を払って通信要求をすると、受ける側は受信することが当然とされてきた。しかし、通信網の発達に伴って、通信要求を発することがますます低コスト化し、通信網にアクセスできる人がますます多くなる中で、だれからの通信要求も受けなければならない理由は存在しない。少なくとも全く関係のない人からの電話を拒否できるようになるべきである。逆に言えば、公衆サービスを除いて、電話を掛ける側は、予め話したい相手と知り合いで、用件がある場合が通常である。従って、本発明の許可制による通信は従来の通信機能をほとんど犠牲しないで迷惑通信を防止できる。
居留守待遇によって、受信者の意思に反しない、通信販売員等着信者との一回切りの通話ができる点が特許文献１２に示す発明と異なる。通話拒否待遇を持つ事が特許文献３４に示す発明と異なる。

【実施例３】
【００３９】
メール受信クライアントシステム
本実施例は、電子秘書が当事者端末側に組み込まれる。ＰＣ（パソコン）アプリケーションとして製品化し（URL:http://www.netinfotech.co.jp、http://www.Emailship.com）、じき公開販売する予定である。
図３８は、本実施例３の構成を示すブロック図である。この図において、符号１０はＩＳＰのサーバ機器である。符号３８１はメール・サービス当事者端末である。本実施例はＩＳＰのメール・サービス・サーバのクライアントであり、符号１１はプロセッサーであり、ＣＰＵ等から構成され、各部の制御や、データの転送、種々の演算、データの一時的な格納等を行なう。符号１２は入出力制御手段であり、通信回線を介して接続されたサーバから入力されるデータを制御し、サーバに出力されるデータを制御する。符号１５は通信転送装置であり、ＩＳＰと接続する。符号１６はキーボード及び表示部を示し、符号１３は記憶装置である。
まず、かかるプログラムは、プロセッサー１１において用いられるものであり、例えば、表示部に待遇、初期待遇、要求確認質問、正解（キーワード）、正解に与える待遇の設定用プログラムや、電子秘書本体プログラム等から構成される。
次に、記憶装置１３には、指示ファイル等データが格納される。記憶装置として磁気記憶媒体を採用する。図３９Ａ〜ＤはＴＤＢ、Ｒ１ＤＢ、Ｒ２ＤＢ、ＧＤＢを示す。発信者に質問と提示情報を自動返信する。図４０は受信処理の概略フローチャートである。基本部分は図８と同じである。
【００４０】
プロセッサー１１は、端末３８１の表示部に対し、図４１に示すような質問入力画面を表示させ、端末操作者に対して、この待遇を決める基準、即ち要求確認質問と正解と正解に与える待遇、を入力する（４１０１）ように促す。許可なしの発信者からのメールをサーバに届くと、許可申請を案内する提示情報、質問を発信者へ自動返信し、申請案内中に確認質問の答えを応答メールの件名に記入ように求める。迷惑メールの多くは機械により自動送信されたものである。
例えば「一足す一はいくつですか」といった確認質問に対して正しい回答が得られれば発信者は機械ではなく人間であることがわかり、このような人間の相手に対して、相手がメール自動送信機械などの場合と異なり、今後の受信を希望するかとか着信者が自分の意思で決定できる。勿論足し算のできる機械はたくさんあるが、自動的に、一人一人出した問題文を理解できる機械を作ることは採算に合わないはずである。
本発明はメールの本体を開封せずに目的を達成できる。特に携帯電話等サーバと接続の課金部分の通信量が大幅に減少できる。メールの件名又は本文から正解、例えば着信者の名前や、興味のあるカテゴリーのキーワードが検出されたら所定の待遇を与える。つまり暗黙的に許可申請手順を行い、発信者に便宜を図る事ができる。本文から検索する場合、本発明のサーバ側に常駐する形態を使用することが望ましい。
プロセッサー１１は、端末３８１の表示部に対し、図４２に示すような画面を表示させ、端末操作者に対して、リスト４２０１の中から初期待遇４２０２を選択するように促す。図３９Ａは本例採用の待遇セットであり、申請受理種類の待遇の具体的な実現が「要求確認質問を発信者に返信し、受信を拒否する」の一つの待遇である。必要であれば、「要求確認質問を発信者に返信し、件名だけを受信する」などを追加できる。
【００４１】
通信を一部許可する種類の待遇の具体的な実現が「限定サイズ受信して一時フォルダに保存し、着信者に知らせる」。更に手動審査に必要な「受信する」の待遇である。「受信して、受信する待遇を与える」待遇は受信してから発信者に受信する待遇を与える。未知のメールアドレスから受信した場合は、初期待遇として要求確認質問を発信者に返信し、受信を拒否する。
本実施例製品の初期設定ではまず、当事者の確認を得て既存のメールソフトのアドレス帳等に記載されている相手に受信許可待遇（待遇ＩＤ＝４）を与え（図４２、４２０３）、その後いつでも個別に受信許可、受信拒否アドレス・ドメイン名を入力でき、発信者毎に待遇を設定、変更できる。また、当事者が送信したメールから宛先アドレスを抽出し、自動的に受信許可待遇を与えるように設定できる。
図３９Ａ〜Ｄは設定した待遇情報の一例であり、次の機能が同時に実現できる。即ち、アドレスやドメイン毎にして指定受信（待遇ＩＤ＝４）及び指定拒否（待遇ＩＤ＝１）、
機械により自動的に送られた望まないメールを拒否する（待遇ＩＤ＝２）、関係のない人間（１+１＝２が答える）が送ったメールを限定受信して手動待遇審査を待つ（待遇ＩＤ＝３）、着信者の名前を知っている人が送ったメールを受信してから発信者に受信する待遇を与える。待遇ＩＤ＝５）。
本実施例はメールヘッダ情報に含まれる文字コード情報や発信者アドレスのドメイン名の接尾語に含まれる地域情報に基づいて提示情報の多国言語対応処理を行う。
本発明は、通信可否の判断が発信者ＩＤに依存しない第２ルールセットという要素が含まれることが特許文献２１と異なる。そのため、送信者にパスワード（図３９Ｃ、５６７８）を発行することにより発信者アドレスを偽造するフィッシング詐欺を防ぐことができる。提示情報（図３９Ｄ）を通して送信者に興味を声明する手段を備え、件名ないし本体から相手の回答やキーワードを検索でき、双方の利益になる通信が可能になる。

【実施例４】
【００４２】
インターネットテレビ電話及び監視システム
本実施例はサーバ側に運用する電子秘書とクライアント側に前記電子秘書を介在して通信する当事者テレビ電話端末が完成したものである。
１：図４３は、全体構成を示すブロック図である。図４４は、本第１の実施例の内部構成を示すブロック図である。この図において、符号４３０はサーバであり、経路制御装置、電話回線を経由してインターネットに接続されている。符号４３１〜４３４、…は各種の端末であり、サーバ４３０と同様にしてインターネットに接続される。ここで、端末４３１、４３２、…は、それぞれＣＲＴやＬＣＤ、スピーカー等の出力部とともに、キーボード、マウス、カメラ、マイク等の入力部、及びテレビ電話プログラムを実行させる機能を有する。
１−１：サーバの構成次に、サーバ４３０の詳細構成について説明する。図４４はサーバ４３０及び端末の構成を示すブロック図である。この図において、符号１１はプロセッサーであり、ＣＰＵ等から構成され、各部の制御や、データの転送、種々の演算、データの一時的な格納等を行なう。符号１２は入出力制御手段であり、インターネットを介して接続された端末から入力されるデータを制御し、端末に出力されるデータを制御する。符号１５は通信転送装置であり、インターネットと接続する。符号１３〜１４は記憶装置であり、それぞれ以下のファイルが格納、記憶されている。
まず、記憶装置１４には、メインプログラムが記憶されている。かかるメインプログラムは、プロセッサー１１において用いられるものであり、例えば、端末の表示部に待遇申請画面を表示させるプログラムや、待遇申請を送った当事者の詳細情報を表示させる待遇審査用プログラム、当事者の連絡帳に待遇申請を行った当事者の公開名前や、他の当事者の状態表示や、テレビ電話プログラムの起動及び相手に発信するアイコンの表示用プログラム等から構成される。
【００４３】
次に、記憶装置１３には、当事者マスタデータベーステーブルと待遇関係マスタデータベーステーブルが格納される。当事者マスタは、当事者情報レコードが格納される。一つの当事者情報レコードは、当事者ＩＤ、パスワード、メールアドレス、ＩＰアドレス、自己紹介等のように当事者固有の情報から構成される（当事者データに関するもう一つの一実施例はＰＤＤＢ参照）。
この実施例の当事者ＩＤは、サービス参加の新規登録をするときにプロセッサー１１により自動的に付与されるものであるが、身元登録の実行はこの段階で行うことができる。パスワード、メールアドレス、自己紹介は当事者が端末４３１、４３２、…から登録して送信されてきた情報が格納される。
ＩＰアドレスは、端末４３１、４３２、…のテレビ電話通信プログラム起動するときに送信してきた端末のアドレスが格納される。待遇関係マスタは、待遇情報レコードが格納される。一つ待遇情報レコードは、待遇情報、待遇申請標示情報から構成される。
本発明はクライアント側で運用する場合はＲ１ＤＢによる相手に与える待遇を記録する。サーバ側で運用する場合は、効率の高い本実施例の待遇関係マスタＴＲＤＢ（図２Ｈ参照）を望ましい。待遇情報は、着信者自身のＩＤと、着信者が待遇を与えた発信者ＩＤと、前記与えた待遇から構成される。待遇情報、待遇申請標示情報は、端末の表示部に待遇申請画面を表示させるプログラムのユーザインタフェースから入力された情報であり、端末４３１、４３２、…から送信されてきた情報である。
２：動作について説明する。ここで、端末４３１、４３２、…は、それぞれサーバ４３０と接続されて通信を行ない、いずれもテレビ電話当事者の端末として機能するが、説明便宜上、サーバ４３０には端末４３１が接続されたとして、以下説明を行なう。サーバ４３０に端末４３１が接続されると、プロセッサー１１は、入出力制御手段１２を介してこの接続を検知し、メインプログラムにしたがって端末４３１を制御する。図４５は、かかるメインプログラムの動作を示すフローチャートである。
【００４４】
２−１：当事者情報レコードの作成過程を説明するため、端末操作者が新規の当事者であるとする。新規登録を説明する。図４５に示したステップＳａ１において、プロセッサー１１は、端末４３１の表示部に対し、図４６に示すようなメインメニュー画面を表示させ、端末操作者に対して、サービスを利用するために、「ログイン」及び「新規登録」の中から所望する処理を選択するように促す。
かかる、メインメニュー画面においては、マウスカーソルＭＣが表示され、所定の場所をクリックすることにより、種々の操作を行なえるようになっている。例えば、リンクボタン４６０１、４６０２のいずれかの表示領域に、マウスカーソルＭＣを位置させてクリックすれば、当該表示領域で示された処理が行なわれる。ここでは、端末操作者は、マウスカーソルＭＣをリンクボタン４６０２の表示領域に位置させた後、クリック操作（この操作は、以下は簡単にクリックと記述する）を行なって「新規登録」の処理を選択する。すると、これを検知したプロセッサー１１は、手順を図４５に示したステップＳａ２に進ませて、このステップで、名前、メール
アドレス、パスワードを端末操作者に対し、入力するように促される。
入力されたメールアドレスが当事者マスタに使用されていないと判定すれば、入力された情報に基づいてユーザＩＤをプロセッサー１１により自動的に付与され、当該ユーザＩＤは当事者の公開ＩＤとして使う。次のステップＳａ３の処理を行なう。ステップＳａ３において、プロセッサー１１は、端末４３１に対して、図４７に示す連絡帳画面を表示させる制御を行う。
なお、以下のステップＳａ４〜Ｓａ７では、所定の操作によって、いつでも、連絡帳画面及びメインメニュー画面に戻ることができるようになっている。さて、この連絡帳画面には、新規登録した当事者の場合は、連絡帳に相手が一つも表示されないが、説明便宜上、すでに数人の相手が存在した画面を使って説明する。
【００４５】
先ず新規相手の追加を説明する。本発明は相手と通信するために、先ず相手に対しての待遇を申請する。新規相手の追加は待遇申請の具体手順である。新規相手の追加画面は、相手に対して待遇申請と同時に、自分が相手に与える待遇を指定する。
端末操作者に対し、メンバーの追加を促す。端末操作者は、リンクボタン４７０１をクリックする。すると、プロセッサー１１は、次のステップＳａ４の処理を行なう。ステップＳａ４において、プロセッサー１１は、端末４３１に対して、図４８に示すメンバーの追加画面を表示させる制御を行なって、端末操作者に対し、公開ＩＤ情報の入力を促す。
ここは、事前申請の実施例を示す。公開ＩＤは当事者自らインターネットの掲示板や通信網上のチャットに公開した、或いは直接相手から教えたものである。このメンバーの追加画面には、ＩＤ、自己紹介の入力ボックス４８０１、４８０２が示されて、相手に与える情報開示待遇について「このメンバーにメールアドレスを公開する
」、「プライベートメールアドレスを公開」、「ホームページアドレスを公開」、「プロファイルアドレスを公開」、「このメンバーに自分の状態を公開する」に対応するチェックボタン４８０３〜４８０７が示されて、相手に与える着信許可待遇について「着信許可」に対応する選択ボックス４８０８が示されて、端末操作者に対し、入力と選択をするように促される端末操作者は、相手の公開ＩＤを２００と「識別ＩＤ」ボックスに入力し、自己紹介は”・・・です。”と「自己紹介」ボックスに入力とし、次に実行リンクボタン４８１０をクリックする。
本実施例の待遇セットは、テレビ電話の着信応答方法に対しての着信許可は、「受信自動拒否」、「毎回問い合わせ」、「自動受信」３種類有る。「自動受信」は制御許可待遇である。発信者が制御権を持つことを着信者側通信装置：ＴＶ電話端末に指示し、前記発信者に着信者の介入なしで通信できる。勿論端末は常に受信できる状態にする必要がある。
【００４６】
相手に情報開示範囲については、「このメンバーにメールアドレスを公開する」、「プライベートメールアドレスを公開」、「ホームページアドレスを公開」、「プロファイルアドレスを公開」、「このメンバーに自分の状態を公開する」、を複数選択可能により構成され（４８０９）、待遇申請については、「待遇申請許可」、「待遇申請拒否」２種類有り、既定の初期待遇は「毎回問い合わせ」と、情報すべて開示しないと、「待遇申請許可」である。本実施例は初期待遇を変更する機能が含まれない。
さて、かかる操作により、手順が待遇申請の次の実行処理を行う（図４９参照）。ここで端末操作者は当事者ａとし、通信したい相手は当事者ｂとし、当事者ｂの公開ＩＤは２００である。プロセッサー１１は、当事者ｂが当事者ａに与えた待遇に基づいて待遇申請を処理すべく、まず当事者ａが当事者ｂの発信者リストにすでに存在したか否かを、すでに作成した当事者マスタを検索することによりチェックし（４９０１）、存在した場合、当事者ｂがａに待遇申請について与えた待遇をチッェクし（４９０２）、与えた待遇は「待遇申請拒否」の場合、端末４３１の表示部に対して「メンバー追加が拒否されました」（Ｓａ８）を表示させる制御をした後、手順をステップＳａ３に戻して再び連絡帳画面を表示させ、当事者ａが当事者ｂの発信者リストに存在しない及び与えた待遇は「待遇申請拒否」ではない場合は、既定の初期待遇を当事者ａに与え、ｂとａのＩＤと初期待遇と待遇申請標示情報から構成される新たに待遇情報レコードを作成し、待遇関係マスタに格納し、連絡帳画面に戻る。
ステップＳａ３において、プロセッサー１１は、端末４３１に対して、図４７に示す連絡帳画面を表示させる制御を行う。端末操作者に対し、個人設定の確認を促す。端末操作者は、リンクボタン４７０２をクリックする。すると、プロセッサー１１は、次のステップＳａ７の処理を行なう。
【００４７】
ステップＳａ７において、プロセッサー１１は、端末４３１に対して、図５０に示す当事者の個人設定画面を表示させる制御を行なって、端末操作者に対し、公開ＩＤ５００１を表示し、公開ＩＤの表示領域は書き込み禁止に制御し、個人情報５００２の変更をできるように制御する。
２−２：ログイン、２−１では、端末４３１の操作者は当事者ａとし、当事者ｂに待遇申請を完成したとする。ここは既存の当事者ｂが端末４３２を操作しているとする。
説明便宜上、２−１の説明で端末４３１に表示した画面、図４６、図４７がここで当事者ｂの端末４３２に表示した画面として引き続き説明に利用する。サーバ４３０には端末４３２が接続されたとして、以下説明を行なう。サーバ４３０に端末４３２が接続されると、プロセッサー１１は、この接続が入出力制御手段１２を介して検知され、メインプログラムにしたがって端末４３２を制御する。図５１は、かかるメインプログラムのログイン処理動作を示すフローチャートである。
さて、図４５に示したステップＳａ１において、プロセッサー１１は、端末４３２の表示部に対し、図４６に示すようなメインメニュー画面を表示させ、端末操作者に対して、サービスを利用するために、「ログイン」及び「新規登録」の中から所望する処理を選択するように促す。ここでは、端末操作者は、「メールアドレス」入力ボックス４６０３、「パスワード」入力ボックス４６０４にメールアドレスとパスワードを入力し、リンクボタン４６０１に対しクリック操作を行なって「ログイン」の処理を選択する。すると、これを検知したプロセッサー１１は、入力されたメールアドレスとパスワードに基づいてすでに作成した当事者マスタを検索することによりチェックする（図５１、５１０１）。
【００４８】
ここで、プロセッサー１１は、メールアドレスとパスワードが正しくないと判定すれば、手順をステップＳａ７に進ませ、端末４３２の表示部に対して「メールアドレスかパスワードが正しくない」を表示させる制御をした後、手順をステップＳａ１に戻して再びメインメニュー画面を表示させる。一方、プロセッサー１１は、入力されたメールアドレスとパスワードが正しいと判定すれば、次のステップＳａ３の処理を行なう。
ステップＳａ３において、プロセッサー１１は、端末４３２に対して、図４７に示す連絡帳画面を表示させる制御を行い、新規に待遇を申請した相手を待遇関係マスタから抽出し、当事者ｂに知らせ、当事者ｂの連絡帳に待遇申請を行った当事者ａが緑色と当事者ａの公開名前ｓｏｕｓｓで表示され（４７０５）、他の当事者が当事者ｂに与えた情報開示待遇に従い、色とアイコンで状態を公開させ（４７０６）、メールアドレスを公開した相手についてはメール作成アイコンを表示させ（４７０３）、プロファイルアドレスを公開した相手についてはリンクアイコンを表示させ（４７０４）、鉛筆アイコンが対応した相手の詳細情報を表示させるように制御する。
リンクボタン（４７０７）をクリックすると、プロセッサー１１は、次のステップＳａ５の処理を行なう。ステップＳａ５において、プロセッサー１１は、端末４３２に対して、図５２に示す友達リストの項目編集画面を表示させる制御を行い、この画面で待遇審査及び待遇変更を行い、当事者ｂに待遇申請を送った当事者ａの詳細情報５２０３を表示させ、当事者ａに与える待遇５２０１を編集する制御を行なって、これにより、当事者ｂは当事者ａの待遇申請を審査し、当事者ａに与える待遇を決め、各待遇内容を選択することを促す。また、待遇申請の審査だけではなく、既存相手に与えた待遇の変更もこの友達リストの項目編集画面によって行う。
【００４９】
さて、当事者ｂは、各待遇内容を選択して、リンクボタン５２０４をクリックする。すると、プロセッサー１１は、選択された待遇内容に基づいて、待遇情報レコードを更新し、待遇関係マスタに格納する。相手と関係断ち切る場合、相手の削除を実行するため、リンクボタン５２０２をクリックする。すると、プロセッサー１１は、ステップＳａ６の処理を行なう。ステップＳａ６において、プロセッサー１１は、端末４３２に対して、図５３に示す待遇申請資格指定画面を表示させる制御を行い、待遇申請資格５３０１には「待遇申請拒否」を選択すれば、今後当該相手からの連絡を断ち切れる。当事者ｂは、リンクボタン更新５３０２をクリックする。すると、プロセッサー１１は、選択された待遇内容に基づいて、待遇情報レコードを更新し、待遇関係マスタに格納する。
この例が本発明の匿名通信機能部分の実施を例示する。当事者が自らアイデンティティを公表しない限り、匿名性が保ながら、通常の番号（ＩＤ）を使って、簡単に、全ての通信機能使える匿名通信を実現できる。ここのサーバはアイデンティティを通信内容から取り除く専用の中央コントローラではなく、特別の通信チャンネルを作る必要もない。犯罪防止ため、前記ＩＤを取得段階で、しっかり身元登録すれば良い。
２−３：テレビ電話通信、２−１と２−２で説明した処理より、当事者ａと当事者ｂが待遇関係を築いたとし、サーバ４３０に当事者ａの端末４３１、当事者ｂの端末４３２が接続されたとする。図５４は、テレビ電話通信プログラムの動作を示すフローチャートである。ステップＳａ３において、プロセッサー１１は、図４７に示す連絡帳画面を表示させる制御を行い、当事者ｂがリンクボタン「プログラムを起動する」（４７０８）をクリックする。すると、プロセッサー１１は、当事者ｂの端末に対して、テレビ電話通信プログラムを起動させ、起動パラメータとして”−”をわたす。テレビ電話通信プログラムが起動されたら、自端末のＩＰアドレスをサーバに送信（５４０１）してから、起動パラメータはＩＰアドレスか否かを判断する（５４０２）、パラメータはＩＰアドレスではないと判断したら、接続待機中画面を表示させ、接続待機する（Ｓｂ３：接続待機中画面、図５５）。待機中接続要求をチェックする（５４０５）。プロセッサー１１は、当事者ｂの端末テレビ電話通信プログラムが送ってきたＩＰアドレス情報に基づいて、当事者ｂの情報レコードを更新し、当事者マスタに格納する。
【００５０】
すると、当事者ａの連絡帳画面に当事者ｂの状態表示アイコン（図４７、４７０９）をカメラアイコンに表示させる。当事者ａが当事者ｂのカメラアイコン４７０９をクリックする。すると、プロセッサー１１は、当事者マスタから当事者ｂのＩＰアドレスを抽出し、当事者ａの端末４３１のテレビ電話通信プログラムを起動させ、パラメータとしてＩＰアドレスを渡して（５４０３）、発信者ＩＤを通知し、宛先ＩＰアドレスへ接続を要求し、即ち、当事者ｂに発信し、着信者ｂのテレビ電話通信プログラムの応答を受け取る（５４０４）。
着信者ｂのテレビ電話通信プログラムは接続要求が着信したら、発信者ＩＤを問合せパラメータとしてプロセッサー１１に問合せし、問合せを受けたプロセッサー１１は発信者ＩＤに基づいてサーバ４３０の待遇関係マスタから待遇情報を抽出し（５４０６）、発信者当事者ａに与えた待遇を問合せの結果としてテレビ電話通信プログラムに返す。
発信者当事者ａに与えた待遇が「自動受信」の場合（５４０７、ＹＥＳ）、電子秘書は発信者が制御権を持つことを着信者側通信装置ＴＶ電話端末に指示し、これを受けて、着信者ｂのテレビ電話通信プログラムはベルを鳴らさなく、入力要求画面の表示及び入力要求を経ずに、通信要求を許可して、接続承認の応答を送出し、自動接続させ、カメラにより取得する画像信号を相手に取得させる、即ち画像信号を送出し、同時に相手が送出した画像信号を受信したら、画面に表示させ、テレビ電話通信中画面（Ｓｂ２：テレビ電話通信中画面、図５６）を表示させる。
一方、発信者当事者ａのテレビ電話通信プログラムが承認応答を受け、５４０４、５４０９ステップを経て、受信した画像信号をテレビ電話通信中画面に表示させ、通信又は監視する（Ｓｂ２）。発信者当事者ａに与えた待遇は「毎回問い合わせ」の場合（図５４、５４０８、ＹＥＳ）、着信者ｂのテレビ電話通信プログラムはベルを鳴らして、入力要求画面（Ｓｂ４：承認問合せ画面：「当事者ａから掛かりました。受話しますか？」を表示する）を表示して、接続するか否か着信者の当事者ｂに問合せる。
【００５１】
同時に発信者のテレビ電話通信プログラムが相手の承認待ち画面を表示させる（Ｓｂ１：承認待ち中画面：「相手の承認を待っています...」を表示する）。着信者ｂが接続を承認したら（図５４、５４１０、ＹＥＳ）、テレビ電話通信プログラムがテレビ電話通信中画面を表示させ、発信者当事者ａのテレビ電話通信プログラムに接続承認したと応答させ、すると、発信者当事者ａの端末で実行しているテレビ電話通信プログラムがこの応答を判断し（５４０９、ＹＥＳ）、テレビ電話通信中画面を表示させ、通信する。
着信者ｂが接続を承認しない場合（図５４、５４１０、ＮＯ）、テレビ電話通信プログラムが接続待機中（状態表示：５５０１）画面を表示させ、発信者当事者ａのテレビ電話通信プログラムに接続拒否したと応答させ、すると、発信者当事者ａの端末で実行しているテレビ電話通信プログラムがこの応答を判断させ（５４０９、ＮＯ）、当事者ａの端末表示部に、「アクセスが拒否されました」（図５５、５５０２，図５４、５４１１）と接続結果を表示してから、接続待機中画面を表示させ、接続待機する（Ｓｂ３：接続待機中画面、図５５）。発信者当事者ａに与えた待遇は「受信自動拒否」の場合（図５４、５４０８、ＮＯ）、前記着信者ｂが接続を承認しない場合と同じ処理をさせる。
３：流れ概要説明
次に、図５７は、公開ＩＤを介して着信者相手と待遇関係を築く流れを示している。当事者ａは本発明の通信サービの提供を受けるために、まず、端末５７０１を使って、インターネットを経由してサーバ５７０２にログインし、相手ｂが公開していた公開ＩＤ：２００を使って、相手ｂに通信を希望する意思を表明する待遇申請を行うこととなる（１）。
待遇申請する当事者ａは着信者相手ｂの公開ＩＤ：２００を入力し（図４８，４８０１）、同時に当事者ａ自分が相手ｂに「毎回問い合わせ」（４８０８）待遇を与える。サーバは当事者ａが指定された相手ｂに与える待遇「毎回問い合わせ」を待遇関係マスタに保存し（５７０３）、当事者ａが当事者ｂの発信者リストに存在しない場合、当事者ｂの初期待遇「受信自動拒否」を当事者ａにあたえ（５７０４）、この状態では当事者ｂが発信し当事者ａと通信できる。逆方向の通信できない。着信者が主導権を握る。サーバが当事者ａに申請を受理したことを当事者ａに伝える（３）、（４）。当事者ｂは端末５７０５を使って、サーバにログインしたら、新規に待遇を申請した相手を待遇関係マスタから抽出し、当事者ｂに知らせ（５）〜（８）、図４７には、当事者ｂの連絡帳に待遇申請を行った当事者ａが緑色と当事者ａの公開名前ｓｏｕｓｓで表示され（４７０５）、他の当事者が当事者ｂに与えた情報開示待遇に従いで、色とアイコンで状態を公開する（４７０６）。
【００５２】
図５２は、当事者ｂに待遇申請を送った当事者ａの詳細情報を表示する。当事者ｂは待遇関係の申請を審査し、相手ａに与える待遇を決める（図５２、５２０１）。相手ａに与えた待遇「毎回問い合わせ」をサーバに記憶した待遇「受信自動拒否」と入れ替える（１０）。これにより、当事者ａ、ｂが相互にテレビ電話の相手に接続要求を発信できる。
この実施例は、任意の一つ又は複数の発信者に制御許可待遇を与えることができ、発信者が直接に受信側設備を制御でき、受信側のＴＶ通信プログラムを起動でき、受信側とデータの送受信ができる。本実施例のＴＶ電話のカメラの制御の代わりに、携帯電話のＧＰＳ受信機の制御に実施する事もできる。制御許可待遇を与えた任意の発信者が直接に受信機の位置情報を取得して表示できる点は、製品の設計段階で、固定された位置情報センターしか位置情報が取得できない特許文献９に示す従来技術とは異なる。第三者の位置情報センター不要ので、ハードウェア設備及び利用者の運用コストを大幅に減少することをもたらす顕著な効果が得られる。携帯電話に自機の位置情報を表示する手段を有る機種は、表示用の元データを相手の携帯から取得して自機の表示手段で表示できる。

【実施例５】
【００５３】
メールサーバシステム
図５８は、本実施例の構成を示すブロック図であり、ＩＳＰ５８１２のメールサーバ側で本発明の電子秘書５８０１を運用することを例示する。電子秘書は既存のメールサーバと独立しており、許可されるメールを受信してから従来のメールサーバ５８０２に転送する。ＩＳＰ５８１２のクライアントからのメールの送信は直接電子秘書を経由して処理される。
電子秘書５８０１は、不特定発信者にサービスを提供する公的な機関、又は商品販売会社の業務連絡アドレスを扱う場合、自分の業務範囲又はサービスに関するキーワード等を案内情報に記載して、あらかじめ通信許可待遇が与えられていないメールの送信要求が着信すると、第２ルールによりメールのヘッダから特定のキーワードが検出されない場合が案内情報を発信者に提示（返信）し、メール受信を拒否する。
例えば日本国特許庁申請人登録関係の問い合わせメールアドレスは PA1670@jpo.go.jp（図５８の"Ｆ"で略称する）であり、このアドレスの案内情報（図６０）は、「このアドレスは特許庁出願支援課申請人等登録担当の問い合わせ先です。ご利用の方は＜申請人登録関係に関する問い合わせ＞をメールの件名に記入して再送信して下さい。」と記載し、第２ルールセット（図６１）に「申請人登録関係に関する問い合わせ」を記載したメールを一時受信し、ただし発信者に待遇を与えない、という設定（ＩＤ＝５、図５９、図６１）を電子秘書に行った場合を考える。
【００５４】
出願人端末５８０４のメールアドレスは fe1@netinfotech.co.jp（図５８の"Ａ"）とする。出願人が特許庁のホームページで問い合わせメールアドレスを入手し、望ましくは案内情報もホームページに掲載する。すると、出願人が件名に文字列”申請人登録関係に関する問い合わせ、登録方法について”を記載し、宛先 PA1670@jpo.go.jp （F）へメール（図５８、 (a1) To:F, 申請人登録関係...）を送信する。電子秘書が第２ルールに従い前記メールの受信を許可され、メールサーバ５８０２へ転送される。前記メールがFのメールボックスに入られる。出願支援課からの返信（a2）は電子秘書を経由して送信する。
出願人が初めてキーワードを知らないままメールを送信する場合、電子秘書が直ぐに自動返信し、案内情報を出願人に知らせる。特許庁の業務時間外でも、出願人が短時間に前記案内情報を受信できる。案内情報の自動返信経路は、出願人→送信サーバ５８０３→受信サーバ５８０１→送信サーバ５８０３→出願人、である。実際のADSL回線、URL:mail.netinfotech.co.jpとmail.yahoo.co.jpサーバの環境で、発信者→送信サーバ→受信サーバ→受信者、の送受信をテストした。掛かった時間は５秒以下であった。だから、出願人に対して、ほぼ時間の遅延無く、案内に従って再送信できる。
ロボットを使って迷惑メールを送信する端末５８０５は、商品販売ため、出願支援課にメール（図５８、（b1）
To:F, oooxxx...）を送信する場合、電子秘書が案内情報を知らせる自動返信（b2）してから受信を拒否する。通常の場合はロボットが案内情報を理解して、案内に従って再送信することがあり得ない。
人間による故意に案内情報に従いメール攻撃が発生する場合、手動で通信拒否を設定可能である。
ロボットを使って頻繁にメールの大量送信によるメール爆弾攻撃者５８０６は、出願支援課にメール（図５８、（c1）
To:F, oooxxx...）を送信する場合、電子秘書が案内情報を知らせる自動返信（c2）してから受信を拒否する。請求項９記載の方法（図１４参照）を利用する電子秘書が自動返信の場合、発信者メールアドレスと受信時刻と所定の受信拒否待遇（ＩＤ＝０）を基にして、第３のルールを作成し、攻撃防止用第３ルールセット（図６３）に加える。本実施例使い定数が図６４で示す。攻撃防止用第３ルール条件部所定の時間が６０分と設定し、所定の待遇が返信なし、受信を拒否する。すると、６０分以内攻撃者第２通のメール（c3）を送信すると、返信なしの受信拒否待遇を与え（図１４、１４０７）、それ以後の攻撃は、メールの封筒を見てすぐに拒否する。
【００５５】
本発明の好ましく変形は第３ルールの条件部に到達するメールの通数を加える。例えば６０分以内攻撃者第５通のメールを到達する場合、待遇に基づいて通信要求を処置する。
電子秘書がメールの封筒或いはヘッダにより発信者を判断する（請求項５）ため、メールの本体を受信する必要がない。公衆網の通信量が大幅に減少できる。
特許文献１３に示す従来技術では、発信者不明の場合、一時的にメールを受信し、発信者にサーバが作成する確認メールを自動返信し、確認されたら受信したメールを着信者に渡す。本発明は前述通りに公衆網に大量の無駄な通信を発生させない、メール攻撃により通信帯域圧迫やサーバ記憶領域がパンクする心配が全くない、攻撃防止用第三ルールセットの仕組みにより、自動返信のメール自体が多数の新たなスパムメールになってしまう可能性がない、個々の着信者個人の主観意思が反映できることが前記従来技術と異なる。また、本発明は携帯電話などクライアント側で運用する場合、迷惑メールにより迷惑を受けた受信者がさらに理不尽な課金をされることがないという特徴を持っている。
以上のように、正常な業務実行を保証しながら、間違いメールや、機械送信の迷惑メールや攻撃メールを完全に拒否できる。
本発明の好ましく変形は異常発信者のＩＰアドレスを記憶し、ＩＰアドレスによるＴＣＰ接続を拒否する。
発信者は従来技術のメール送信サーバ（ＳＭＴＰクライアント）を使用する場合、電子秘書がメールのヘッダにより発信者の身元を判断し、メールの本体（ボディ）を受信せずに、根底にある配送系コネクションを閉じることにより通信を強制中止する（請求項６、図１１）。通信が強制中止された送信サーバは再試行するので、前記強制中止された状態を専用の第３ルールセットを用いて記録し、送信サーバが再試行する時、電子秘書が記録された発信者ＩＤにより相手を判断して通信を正常中止する。図６５が前記専用の第３ルールセット（Ｒ３ＤＢ２）を示す。図６３に示す攻撃防止用第３ルールセット（Ｒ３ＤＢ１）とは別のデータを記録していることを留意して欲しい。
【００５６】
メール送信サーバが前記従来技術を代えて、請求項９９、１００を利用する送信システムを使用する場合、ボディを送信する認可がヘッダに含まれた情報により判定するため、ヘッダに含まれた情報フィールドを送信し（図３１、３１０４）、受信サーバ側の電子秘書が件名が含まれる情報フィールドを受信してから、第２ルールセットを適用する（図１０、１００６，１００７，１００９）ことにより、ボディを送信することを認可するか否かを判定し、認可する、即ち、通信を許可した場合、送信側に伝えて、通信を継続する（図３１、３１０６）。請求項９９、１００の発明と電子秘書を同時に使用することにより更に無駄な通信量が減り、通信を強制中止することの必要がなくなる。通信制御処理が明快に成る。
電子秘書からメールを送信する場合、迷惑通信を発生源から阻止できる（請求項２６、図２０参照）。Ｄ:メール爆弾攻撃者（５８０７）は、Ａ:出願人にメール（図５８、（d1）
To:A, oooxxx...）を送信し、Ａがサーバ側で運用する電子秘書５８０３を利用ているとする。電子秘書５８０３が(d1)を受信して、発信者Ｄが受信許可がないため、出願人の案内情報を知らせる自動返信(d2)を発信者に送って、受信を拒否する。（d1）を送信した電子秘書５８０１が５８０３から受信拒否待遇を受け取って、第５のルールを作成し、第５ルールセットＲ５ＤＢ（図６６）に加え、発信者Ｄの指示ファイルに保存する。第５ルール条件部に設定された時間（一日）以内、Ｄが更に(d3)を送信する場合、電子秘書５８０１が第５のルールを適用するため、送信を拒否する（図２０、２００４）。以上のような迷惑通信が公衆網５８１３に入る前に、最初の送信クライアントに対して拒否される。例えば発信者がMicrosoft Outlookを使う場合、送信ボタンを押すと、Outlookが即時に配信不能と報告する。
【００５７】
システム運行中、作成された時刻から条件部所定の時間を経過した第３、第５のルールを削除される。
特定発信者にサービスを提供する企業や団体は限られる範囲でしか通信しない業務連絡がある。従来技術の公衆電気通信網が安く速やかに通信できる。しかし、公衆向け開放的な性質を持つため、前記業務に適用しない。本発明は公衆電気通信網に専門向け閉鎖的な通信効果が得られる。
例えば特許審査着手状況の問い合わせについて、日本特許庁は今郵便でしか扱っていない。本発明は次の電子メールにより作業を提案する。
前記問い合わせの電子メール宛先が E とする（図５８、５８０８）。E の案内情報に「こちらは特許審査着手状況の問い合わせ先です。初めてご利用の方は”出願番号:整理番号”をメールの件名に記入して再送信して下さい。例：”特願2003-70953:0302-001”」を記載して、メールが着信すると、第２ルールにより、正確に出願番号と整理番号を記載した発信者にメールを受信する通信許可待遇を与え、与えた待遇を第１ルールセットに保存する。
”出願番号:整理番号”が初めて通信の許可を獲得用パスワードの役割である。それを代わって特許庁又は出願人が決めるパスワードも使える。パスワードの知らせが出願送付文書に記載する。
請求項１０１、１０２の所定の記録条件が待遇ＩＤに含む。第２ルールにより決める待遇ＩＤが６の場合、待遇を保存する。即ち発信者２回目以後のメールを前記パスワードをチェックしない。
業務用システムが通信関係者多い且つ動的に変化する場合、人により指示ファイルの維持が大変である。この問題が請求項１３１、１３２記載の指示ファイル入力コンポーネントにより解決する。
【００５８】
図６７は指示ファイル入力コンポーネントのユーザ・インタフェースのレイアウトを例示する。
図６８は前記ユーザ・インタフェースに従い指示ファイル入力コンポーネントに渡すデータを示す。
電子秘書５８０１がMicrosoft Windows（登録商標）ベースコンピュータで動く。(誰が)インターネットを通して、ウェブサーバで定数や案内情報など変動が少ない情報を指示ファイルに入力する。
入力コンポーネントはMicrosoft Windowsベースコンピュータで動き、端末５８１０は特許庁既存の係属中の事件のデータ５８１１から出願番号と整理番号を抽出し、コンポーネントに渡す。或いは出願番号を決める業務データに保存する時点で、業務システムからコンポーネントを呼び出すことにより指示ファイルにデータを入力する。好ましくは入力コンポーネントが許可を与えた発信者ＩＤと第２ルールセットの関連情報を記憶し、出願事件が特許庁に係属しなくなった後に、指示ファイルから関連情報を削除する。
以上のように、関係者多い且つ動的に変化する場合でも、人手により動的維持する事無く、公衆的なインターネット通信網に、関係者限りの安全な専用通信網のような通信環境を作れる。
電子秘書５８０１が直接インターネット５８１３にメールを送信するが、従来のメールサーバ５８０２を経由して、例えば、５８０８〜５８０１〜５８０２〜５８１３のように、自動返信の以外のメールを転送してもいい（図５８に示せず）。そうすると、ＩＳＰ内部のメール転送（５８０１〜５８０２）が早いため、電子秘書に送信メールのキューの管理を省略でき、従来のメールサーバのキュー管理など機能がフルに活用できる。
従来のメールサーバ、例えば、Unix（登録商標）ベースコンピュータに動くSendmailを利用できる。
本発明はメールサーバのコンポーネントとして利用されるかもしれない。

【実施例６】
【００５９】
実施形態、電子決済システム。
図６９は電子決済に関する方法及びシステムを示すブロック図である。
［分野］商取引時のキャッシュレス化を可能とするシステムに関する。特に、携帯電話などの通信端末を利用して即時に決済を行うことができる電子決済サーバ、電子決済システム、電子決済方法及びプログラムに関する。
［背景］クレジットカード、デビットカード（キャッシュカードで買物）決済システムがある。インターネットビジネス（ｅビジネス）、携帯やＰＨＳなどの携帯型通信機器を対象としたサービスも多く存在する。しかしながら、カードデータが簡単に盗まれる。デビットカードで買物時暗証番号の入力が不安全であり、暗証番号が指の動きから容易に盗まれる。端末に細工がなされていた場合や、回線が傍受されていた場合には、口座からお金を引き出すための情報が容易に盗まれる。このため偽造キャッシュカードと盗まれる暗証番号による被害が発生している。特許文献３０、３１は高額被害が発生しない専用口座を開設する技術を開示している。しかしながら普通口座と専用口座の間入出金作業が必要であり、普通口座資金の流動性が損なわれる。
［課題］利便性と高額被害が発生しない安全性、資金の流動性を備えた決済方法・システムである。
【００６０】
［手段］電子決済を促進するために、任意のタイプの金融機関又は決済センター（以下「銀行」ともいう）口座（例えばデビットカード、クレジットカード）所有者（以下「買い手」ともいう）と売り手（図69,6902）の間の商決済を処理する電子決済システムおよび方法において、買い手（図69,6901）は予定する買物を電子決済で支払するために、電子決済を予約する予約情報(図69,A)を、銀行(図69,6903)に送信し、識別ＩＤ(図69,B)を使用して、商品(図69,G)を購入する。
表１は、予約情報及びデータ、操作情報の簡単な実例を示している。
【表１】

【００６１】
この明細書で用いられる用語については、次のように定義する。
「通信ＩＤ」とは、決済要求を買い手に確認する時の通信先を意味する。例えば、携帯電話番号、コンピュータ通信アドレス、等がこれに該当する。
「識別ＩＤ」とは、買い手銀行口座と関連付けられた利用者識別子を意味する。例えば、電話番号、車両識別番号、等がこれに該当する。
「仮想口座」とは、予定する支払先に支払をするため想定の口座を意味する。例えば、鉄道、高速道路、現金自動預入支払機（ＡＴＭ）出金、買物、インターネット商店、等特定売り手、機関、或は売り手グループに支払をするため想定の口座がこれに該当する。
「残高上限額」とは、仮想口座の残高を指定する値を意味する。予約する事により仮想口座の残高を残高上限額にセットする。
「確認不要限度額」とは、確認を省略しても良い支払上限額を意味する。
「確認不要累積限度額」とは、必ず確認を行う基準額を意味する。確認の省略は累積方式であり、確認を省略した支払額の累積額が前記基準額を超える場合（以下「累積超過」という）に、確認を行い、前記累積額をゼロにセットして再び累積をする。
「残高通知額」とは、残高が少なくなり、予約する方が良いと思う額を意味する。
「自動回復日数」とは、自動的に残高を残高上限額まで回復する最短経過日数を意味する。
「決済予約確認要否」とは、識別ＩＤ媒体所持者が有料区域の入場口を通過する時に、退場口で発生する決済請求を利用者に予約するか否かを指定するフラグを意味する。
【００６２】
「確認情報」とは、決済要求の確認ために使用する情報を意味する。仮想口座の暗証番号に相当する。
表１に以上用語で示す情報と残高通知先と暗証番号は予約情報である。
「残高」とは、仮想口座の残高を意味する。
「通信確認」とは、備えられる制御許可待遇の１種類の待遇を意味する。待遇ＩＤは図７０参照。
「操作情報」とは、通信確認待遇により起動される認証プログラムに入力する情報を意味する。
表１に仮想口座に使わない決済予約確認要否フラグを「-」で示す。
売り手は、利用金額の決済を要求する決済要求(図69,C)を生成し、前記決済要求を承認するために、銀行に送信する。銀行は、前記決済要求に含まれる売り手識別子等から仮想口座を特定し、残高及び銀行口座残高（以下「総残高」という）は足りる場合、銀行は、買い手に前記決済要求を確認するために、確認要求(図69,D)を買い手に提示する。買い手は、確認情報(図69,E)を銀行に提示して前記決済要求を確認する。銀行は、買い手によって確認された後にのみ、承認(図69,F)を売り手に送信し、決済を行う。
仮想口座は業種コード、売り手名、商品種類等買い手による指定の方法で特定する。銀行は売り手識別子等入手可能な情報を買い手に提供し、仮想口座との関連付けを選択させる。
本発明の決済処理に関するデータ構造等は、公知技術、例えば、特許文献２７〜２９を参照する。
仮想口座は、従来技術の専用口座、保留預金（口座残高全体から自由に引出できない枠）、及びプリペイドカードと異なり、銀行口座から総残高を自由に引出できる。図７３は、口座所有者が開設している銀行口座と予約している仮想口座の残高を模式的に示している。仮想口座の残高は総残高を越える場合も有りえる。決済可能金額が残高と総残高の両方以下である。仮想口座は決済の安全性を保ちながら、資金の流動性を維持する効果が有る。複数の専用口座に入金し過ぎる場合、他の用途で資金を簡単に使えない不便がない。
【００６３】
前記確認要求は請求原因と金額を含め、決済要求の確認を買い手に求める。
銀行は速やかに処理することが要求される。銀行の役を果たす売り手自前の決済センターを運営しても良い。
任意の情報通信手段を利用できる。電話、メール、インターネット、など本実施形態目的を達成できる手段であれば良い。ネットワークに常時接続する通信手段を利用しても良い。例えば、モバイルインターネットＷｅｂ、又は、チャットライクな双方向通信（chat-like interaction）を通しても良い。
買い手は発信して銀行から確認要求を取得しても良い。電子秘書は内側から到着する通信要求を解析して、決済要求を確認するための通信要求に対して、通信確認待遇を実施する。例えば、銀行の電子決済用電話番号への発信、又はＵＲＬで識別された電子決済のサービスを提供するＷｅｂページへのアクセスが検出される場合は認証プログラムが起動される。
予約情報に、確認基準を含めても良い。銀行は、予約情報に含まれる確認基準が前記決済要求に含まれるデータによって満たされる場合、確認要求と確認情報の送受信を省略して決済要求を承認しても良い。前記確認基準の例は、制限はされないが、売り手識別子、支払限度額、決済日、決済時刻、又はそれらの組み合せ、又は買い手が便利に感じるかもしれない他の基準を含んでいる。
銀行は、売り手通信モジュール、例えば、レジ端末を通じて決済要求を買い手に確認しても良い。確認要求を売買双方の装置に送信することを選択しても良い。又は、メールで確認を要求し、Ｗｅｂで確認をしても良い。
識別ＩＤ記録媒体は、売り手装置に合わせる任意の手段を使用しても良い。例えばバーコードを携帯のディスプレーに表示する。磁気カード、ＩＤタグ、ＩＣカード、赤外線等近距離通信手段を使っても良い。識別ＩＤを売り手装置に手入力しても良い。更に、使用履歴、残高、総残高等を店の装置に表示やレシートに印刷する事を選択しても良い。
【００６４】
識別ＩＤを記録した媒体を複製して家族等に使わせることができる。例えば、子供がコンビニエンでジュースを買い、支払いのために識別ＩＤを記録したバーコードを貼っているカードを店員に提示し、親が自宅で携帯により決済要求を確認する事ができる。前記媒体が意思外に複製されたり落したり場合は、不正使用が容易に発見できるので、それを廃止すれば良い。
利用者の取引銀行口座からすべての出金を確認に利用できる。例えば、ＡＴＭから現金を引出す場合、ＡＴＭを売り手（図69,6902）とみなせばよい。利用者は口座番号又は一意なＩＤを磁気カード等媒体を通じてＡＴＭに入力し、金額を入力し、銀行は利用者（買い手）通信モジュールを通じて引出したことを確認された後にのみ出金する。ＡＴＭで従来キャッシュカードの認証を加えて通信確認を行っても良い。
更に、銀行は取引毎に取引コードを生成して携帯に転送し、近距離通信手段を用いて、前記取引コードをＡＴＭに入力して照合し、指紋で認証プログラムを操作することにより、本人しか取引できないようにすることができる。
残高は仮想口座から電子決済による支払限度額であり、決済は決済金額を残高から引き落とす。残高不足の場合、決済要求を否認する。残高の範囲内金額は暗証番号と異なる確認情報で使える。残高は識別ＩＤと確認情報と買い手通信装置が同時に盗まれる場合の最大損失額である。
確認不要限度額を超える支払いの試みを即座に所有者に通知し確認する。確認不要限度額は、識別ＩＤだけで使える現金感覚の額である。決済要求を拒否する場合は、確認情報を無効にして仮想口座を凍結しても良い。
確認を省略にした支払い金額を累積額に累積し、確認不要累積限度額を超えようとする決済要求が発生する時、必ず確認を行い、その後、累積額をゼロにリセットしてから累積する。まとまった額の支払を確認できる。確認不要累積限度額は、識別ＩＤと確認情報が同時に盗まれる場合の最大損失額である。
【００６５】
残高が残高通知額以下に減少した時、その旨を指定の残高通知先に送信する。更に、一定の条件を満たす時、自動的に残高を残高上限額まで回復する（自動回復）。例えば、前回予約又は自動回復してから、自動回復日数を経過していた条件を満たす場合、自動回復が行われる。
確認情報は、暗証番号等認証情報と性質が異なる。決済の重要度と使用環境に合わせて使用することが可能である。前記仮想口座を公衆環境で支払いに使う場合、暗証番号と異なる確認情報を使う方が良い。ＡＴＭコーナー等安全に入力できる環境用仮想口座の確認情報は暗証番号と同じコードを使っても良い。
用語「通信確認」とは、到着する通信要求に対して、着信音や振動等で所持者の注意を喚起し、情報を受信して視覚又は聴覚的に提示し、認証プログラムを自動的に起動することを含む。前記認証プログラムは入力される操作情報を基に、登録した操作情報と照合し、一致する場合にのみ、予め登録された登録情報を外側（銀行）に送信する処理を含む。前記操作情報は、簡単なボタン操作、承認コード、音声、パスワード、指紋等人間の身体的特徴（生体情報）からなる群から選択されるものを含む。
前記登録情報として確認情報を使用する。
必要に応じ、図７０に示す様な複数の通信確認待遇を備えることができる。
予約は識別ＩＤ又は口座番号と暗証番号に基づいて、インターネット又は電話又は銀行窓口等で行う。窓口しか予約できないようにしても良い。
【００６６】
好ましくは、前記暗証番号（認証情報）は使い捨てパスワード（ＯＴＰ）を使用する。毎回の通信が異なるパスワードを使うので、通信傍受被害が防げる。例えば、認証プログラムにＯＴＰを実現する機能を備える。一時的に公衆電話でも予約が可能であり、回線盗聴被害を予防するために一日あたりの利用限度額を設定しても良い。更に確認情報はＯＴＰを使用しても良い。
好ましくは、本人認証を経て電子決済を有効（決済を承認できる状態）にする。例えば、指示ファイルにアクセスし銀行に通信確認待遇を与える。又は、指示ファイルに電子決済の有効／無効フラグを設置し、フラグが無効にセットされる場合は、通信確認待遇が通信を拒否する。
前記本人認証は、通信装置付属の本人認証手段を利用するものであり、買い手は予め装置に本人識別情報を登録して置き、本人認証手段が起動されると、装置が操作者に前記本人識別情報を入力するように促し、入力した情報と登録した本人識別情報と照合し、照合結果が一致した（認証成功）場合、次の操作を許す。前記本人識別情報は、指紋等生体情報、或いはパスワード等を含む。
好ましくは、電子決済を有効にしてから、所定の時間、例えば、４時間を経過すると電子決済を無効（決済を承認できない状態）にする。
［効果］
最大限の安全度を望む場合、買物に出かける前に、残高を予定使用額に、確認不要限度額をゼロに、通信先を携帯電話番号に予約し、指紋で確認操作する。
通信先を店側に、識別ＩＤ、確認情報を覚えるものに予約し、店で識別ＩＤ、確認情報を手入力することにより記憶だけで支払できる。
【００６７】
日常の支払時には、入力操作及び通信中に暗証番号を使わない。予約する時は暗証番号を安全に使えば良い。日常は暗証番号を全く使わない事もできる。
口座から用途別のお金の流出速度を自在に制御でき、流出速度以上のカード偽造の高額被害の可能性がなく、計画した流出速度範囲内の場合、自動回復により予約する手間もなく、家計の計画性が高まる。
詳細説明
使われる従来技術（通信ソフト、コマンド送信、プログラムの実行、ＩＣカード、ＯＴＰ等）の詳細は省略する。
図７０、図７１は本発明電子決済機能を有する移動電話機一実施例のＴＤＢ、Ｒ１ＤＢを示す。構成を示すブロック図基本的に図２６と同じである。前記Ｒ１ＤＢは図２Ｂに示すものの実施例である。説明しやすいため、発信番号を利用する。実施例４のように、インターネット常時接続、パケッド通信など通信手段を利用することもでき、発信者をメールアドレスなどＩＤによる識別することもできる。
図７４は、図７３に示す仮想口座模式図における取引処理の流れ図である。図７５は、図７４に示す承認処理の流れ図である。
次は仮想口座「買物」の予約を説明する。通信ＩＤ「090-1234-5678、商店」、識別ＩＤ「045-1234-5678」、確認情報「456」、と他の表１に示す予約情報が送信される。表１に示す確認情報及び買い手指紋を指示ファイル記憶する。
通信ＩＤは、確認要求が携帯と商店の端末双方に送信されことを意味する。前記携帯の裏側に、識別ＩＤとして自宅電話番号を記録したバーコードを貼っておく。
【００６８】
売り手は、レジ端末等のバーコードリーダにより識別ＩＤを読み取って、識別ＩＤと売り手口座番号と商店名と請求金額（Ａ）等を銀行に送信して決済を要求する（図74,7401）。買い手が携帯を忘れた場合は自宅番号をレジ端末に手入力する。
銀行は識別ＩＤから口座番号を検索し、例えば最初の支払額Ａは 500 円であり、総残高（Ｂ）は 200,000 円である場合には、Ｂは足りるため処理を続き（7402,YES）、特定の仮想口座を特定できない場合、買物口座を選択する（7403）。Ａは残高 100,000 円を超えない（7404,YES）、承認処理（7405）が行われ、確認不要限度額 1,000 円を超えない（図75,7501）ため、銀行は確認を省略し、直ぐに決済要求を承認し、確認を省略した支払の金額 500 円を累積額（Ｃ）に累積し（図75,7502）、Ｃは 500 円となり、Ａを口座から引落し、売り手の口座に移転することとなり、同時にＡを仮想口座から引落し、新たな総残高は 200,000-500=199,500 円、残高は 100,000-500=99,500 円となる（7407）。
２回目の買物の支払額Ａは 600 円である場合には、Ｃに累積するとＣは 1,100 円となり、確認不要累積限度額を超える（7503,YES）ため、銀行は識別ＩＤから携帯番号を検索し、決済要求を確認するため携帯に発信し、同時に、確認要求をレジ端末にも表示する（7504）。買い手はレジに確認情報「456」を入力して、又は、携帯に起動された認証プログラムに指紋センサーを通して指紋を入力して、決済要求を確認する。確認情報が間違った等決済要求が確認されない場合（7505,NO）、取引を拒否する（7406）。確認された場合、取引を承認し、累積超過の場合、累積額Ｃを 0 円にセットされ（7506）、新たな総残高は 200,000-1,100=198,900 円、残高は 100,000-1,100=98,900 円となる。
【００６９】
図７２は乗車券に関する本発明更に別の形態のブロック図である。
［分野］現金が不要な鉄道やバス、高速道路、都心部、駐車場、イベント会場等有料区域（以下「道路」という）の料金収受システムに関する
［手段］図６９に示す電子決済を利用する。売り手（道路、図72,6902）は、入場口（図72,7204）で利用者識別ＩＤを読み取って（図72,1）、識別ＩＤと原因を含む決済を予約する決済予約（図72,2）情報を、銀行に送信して決済を予約する。銀行は予約を確認する確認要求（図72,3）を利用者に送る。利用者は前記確認要求を確認し、銀行に確認情報（図72,4）を送る。銀行は、利用者によって確認された後にのみ、予約済み（図72,5）情報を売り手に送る。売り手は退場口（図72,7205）で識別ＩＤを読み取って（図72,6）利用料金を精算し、決済要求（図72,7）を銀行に送る。銀行は前記決済要求を確認する確認要求（図72,8）を利用者に送る。利用者は前記確認要求を確認し、銀行に確認情報（図72,8）を送る。銀行は、利用者によって確認された後にのみ、承認(図72,10)を売り手に送信し、決済を行う。
決済予約確認要否フラグを「要」に予約する場合、予約の承認／否認結果により入場制御が可能である。
詳細説明
特定の実施例では、鉄道乗車賃の支払である。識別ＩＤが非接触ＩＣカードに記録される。仮想口座「鉄道会社」の予約に、通信ＩＤ「090-1234-5678」、識別ＩＤ「ＩＣカード番号」、確認情報「456」、決済予約確認要否「不要」、と他の表１に示す予約情報が送信される。
【００７０】
乗車駅改札機（7204）は識別ＩＤを読み取ってサーバ（図72,6902に設置され、図に示せず）に転送する。サーバは識別ＩＤ、乗車駅、時間を記録する入場記録を作成し、識別ＩＤ、乗車駅名を含む決済予約情報（仮想口座予約情報と異なる）を銀行に送り、決済予約確認要否フラグが「不要」である場合、銀行は確認（図72,3,4）を省略し、予約済み情報を改札機に送り、入場が許可される。
降車駅改札機は、読取った識別ＩＤにより識別される乗客の乗車料金を精算し、銀行に決済要求を送信し、承認を受信したら退場を許可する。
確認不要限度額を超えない乗車料金範囲内乗車する場合、銀行は確認（図72,8,9）を省略するため、退場判断処理が速くなる効果がある。
決済予約確認要否フラグが「要」である場合、入場改札機は読み取った識別ＩＤが有効である場合、入場を許可してから銀行に決済予約を送り、降車駅は、予約済み情報を受信した場合、退場を許可してから、銀行に決済要求を送信しても良い。入退場判断処理が速くなる効果がある。
更に高速処理及び決済要求処理にかかる費用を抑えるため、確認を省略した支払の金額をＩＣカード又はサーバに累積しても良い。累積と入退場判断は銀行と通信することなく、オフライン承認できる。オフライン承認するため、売り手は必要な買い手が設定した予約情報を銀行から入手する。
【００７１】
図７６はオフライン承認の流れ図である。売り手端末は識別ＩＤを読み取って、商品価格が確認不要限度額を超えないことと判断（図76,7601）した場合、売り手側が保存した累積額に商品価格を加算する（7602）。累積超過の場合、まとまった累積額を商品価格として決済要求を作成し、図７４に示す手順で銀行に承認を求める（以下「オンライン承認」という）（7605）。取引が承認された場合（7606,YES）、累積額をゼロにリセットする（7607）。累積超過でない場合、銀行と通信することなく、当該売買取引を承認することである。本システムでは、この処理を「オフライン承認」と称する。
識別ＩＤ（ＩＣカード等）を保障額で発売し、決済拒否発生すると、現金で退場精算させる。識別ＩＤの廃止を請求する場合、保障額から使用された額を差引いて返金しても良い。確認不要累積限度額と保障額を同額程度に制限しても良い。代金の回収を保障する効果が有る。例えば、１千円で発売又は有効にした識別ＩＤを使う場合、９９０円までの乗車が許可し、次回の１２０円区間を乗車する場合、退場口で１１１０円を請求する。決済拒否される場合退場清算額は１２０円であり、識別ＩＤの廃止を請求する場合返金額は１０円である。
一つの識別ＩＤに対して、複数の売り手が独自に累積額を保存してオフライン承認する事ができる。例えば、同じ携帯電話番号を識別ＩＤとして使用し、異なる鉄道会社の電車に通用できる効果が有る。
更に、乗客は売り手に位置取得許可待遇を与えて、入退場の高速を図る。乗車改札機は付近の乗客識別ＩＤの有効性を前もって判断できる。退場改札機は利用代金の仮精算（乗客の所在位置から最も近い駅で降車すると仮定して精算する）できる。電話会社のシステムから携帯の位置を取得でき、携帯と直接に接続しなくても良い。
【００７２】
イベント会場等へ入場するためのチケットの処理の場合、顧客は、入場に先立ちチケットをチケットショップ等に発注し、入場管理サーバは銀行に相当し、チケット情報を格納する。チケット情報は、識別ＩＤを始め会場名、イベント名、開催日時、人数、座席位置等のデータを含む。そして、サーバは入場改札機により読取った識別ＩＤと対応する携帯に発信し、本人認証してから入場を許可する。
売り手は自前の決済センターを運営しても良い。公衆通信手段の替わりに、携帯の赤外線、DSRC（Dedicated Short Range Communication）、Bluetoothなど非接触近距離通信手段で改札機と通信し、直接携帯の本人認証プログラムを起動しても良い。
更に別の特定の実施例では、道路の料金徴収である。
［背景］日本の自動料金収受システム（ＥＴＣシステム）は、ＥＴＣ車載器と、個人情報及び契約情報又は電子通貨を保存するＥＴＣカードと、入退場ゲートと、路車間高速通信（ＤＳＲＣ）装置によって構成される。しかし、ゲートを“いつでも停車できる”速度で通行することが要求されている。また費用が高額である。一方、シンガポールではERP用として時速180km以下の通行車のナンバープレートをカメラで撮影し、課金する方式がある。既存技術のカメラ方式課金は、高速通過できるフリーフロー料金所を実現できるが、車の所有者と料金支払者の分離が難しい。
［課題］現金が不要なフリーフロー料金システムを低コストで実現する。
［手段］図６９に示す電子決済を利用する。車両の登録ナンバーを利用者識別ＩＤとして使用する。仮想口座「高速道路」の予約に、通信ＩＤ「090-1234-5678」、識別ＩＤ「ナンバープレート番号」、確認情報「456」、決済予約確認要否「要」、と他の表１に示す予約情報が送信される。
【００７３】
売り手は入口（7204）でデジタルカメラによりナンバープレートを撮影し、画像認識手段により識別ＩＤを読み取って、識別ＩＤ、入口名等を含む決済予約を銀行に送る。予約済み情報を受信した場合、退場を許可してから、入場記録を基に代金を清算し、銀行に決済要求を送信する。
入退場記録に更に料金区分に応じた車種、写真等を含み利用証拠として残す。決済予約或いは決済要求が拒否された、或いは、電子決済を予約しなかった場合、識別ＩＤにより車の使用（保有）者を特定し請求書を送る等の方法で請求する。請求書などで掛かった事務手数料を加算して請求しても良い。
入口ゲートが有る場合、識別ＩＤは仮想口座決済である、又は、予約済み情報を受信した場合、入場を許可する。
出口ゲートが有る場合、識別ＩＤは仮想口座決済である、又は、予約済み情報を受信した、又は、承認を受信した場合、退場を許可する。
好ましくは、判断結果に従い電光信号及び携帯に音声で車両を誘導する。電子決済のノンストップレーンと従来の料金ゲートを併設しても良い。
更に、出入口車線の先着位置にカメラを設置し、或いは携帯の位置情報を取得し、出入口に接近中車の支払方法を判断したり、仮精算したり、入退場ゲートの高速判断を図っても良い。
好ましくは、道路使用予定（期間）を指定し、予定が過ぎたら仮想口座の予約を抹消する。
都心部など有料区域の境界線を通過する度に課金する方式（以下通過課金という）の場合は、境界線で前記出口と同じ様な処理をすれば良い。
【００７４】
走行距離による課金方式（以下距離課金という）が実現できる。利用者はシステムに位置取得待遇を与えて、有料区域を入ると、携帯の位置をほぼ連続的にシステムに把握させる。例えば、サーバから携帯位置情報（所在セル、ＧＰＳ情報等）を取得し追跡しても良い。携帯の移動距離は車の移動距離として課金額を計算する。携帯の電池が切れた場合、位置を特定できない場合、固定課金を適用すれば良い。
車両情報を読取るカメラを他の課金に必要な車両情報取得手段、例えば、通信機能が設けられているナンバープレート等に置き換えてもよい。
［作用］ＥＴＣシステムは、ゲートや境界線を通過する時、高速走行中の車を瞬時に認識し、瞬時に車と双方向通信・電子通貨の移動の処理が必要なため、高速度、高精度、高信頼性が要求され、クレジットカード情報の秘匿性の保持、データ改ざんの防止といったセキュリティー機能が要求されるため、瞬時に大量な処理が必要である。これはETCシステムのコストが高い原因である。本発明は車を撮影しナンバープレートを読み取ることだけが必要でありそのための信号処理技術は成熟している。また、秘匿情報を転送せず、ゲート通過時の瞬時の大量な処理の必要がなく、また車載器並びにＥＴＣカードが必要でないため、道路、車双方のコストが下げられる。またハイウェイカードの偽造のような問題を解消できる。また車の所有者と料金支払者の分離がしやすい。料金所等でのノンストップ化を容易に実現できる。カードを使わないため、カードの偽造、電子通貨の残高不足や増額の繁雑の心配事がない。
【００７５】
図６９は更に別の決済に関する方法及びシステムを示すブロック図である。
銀行と買い手と売り手の間の商決済を処理する電子決済システムおよび方法において、買い手は識別ＩＤ(図69,1)を使用して、売り手から商品(図69,6)を購入する。売り手は、利用金額の決済を要求する決済要求(図69,2)を生成し、前記決済要求を承認するために、前記決済要求を、銀行(図69,6903)に送信する。銀行は、買い手に前記決済要求を確認するために、買い手に確認要求(図69,3)を提示する。買い手は、買い手通信モジュールを通じて、暗証番号等認証情報(図69,4)を銀行に送信して前記決済要求を確認する。銀行は、買い手によって確認された後にのみ、承認(図69,5)を売り手に送信する。
決済要求を確認するための通信要求に対して、通信確認待遇を実施する。前記通信確認待遇で起動される認証プログラムが送信する登録情報には、前記認証情報が含まれる。公衆の場所で前記認証情報の入力を避けられる効果がある。好ましくは、決済要求を確認してから電子決済を無効にする。すると毎回支払う前に、電子決済を有効にするため、必ず本人認証が行われ、携帯電話を紛失しても被害を受ける危険がない。
【実施例７】
【００７６】
携帯電話鍵
［分野］自宅のドア、金庫、自動車、等に携帯電話を鍵として使用する。
［手段］電気錠制御システムは、解錠する場合、通信モジュールを通して利用者に解錠を確認する。利用者によって確認された後にのみ、解錠する。前記確認することは、暗証番号等認証情報を電気錠制御システムへ送ることによって行うことである。
図３２は電気錠制御システムの構成を例示する。実施例１では携帯電話発信で解錠する場合を説明した。この例は、被制御装置の電気錠側が発信である。利用者が解錠操作ボタン等解錠操作手段で解錠操作すると、システムから利用者に発信する。図７０、図７１は解錠確認通信要求に通信確認待遇を与える例を示す。システムは所定の認証情報を受信した後にのみ解錠する。
解錠操作が更にテンキーより入力されるパスワードと照合しても良い。
解錠操作は単にドアホン兼用のコール押ボタンを押しても良い。ドアホンと携帯電話を通話させても良い。遠隔解錠できる。
［効果］鍵、鍵穴がない生体認証等本人認証結果によりセキュリティーが強固なロックを実現できる。
【実施例８】
【００７７】
［分野］本実施例は、交通情報の収集、移動体経路誘導に関する。
本明細書は、移動体通信端末装置として携帯電話機を用いたものを示している。なお、移動体通信端末装置としては、携帯電話機に限ることなく、通信機能を備えた電子情報機器（ノート型ＰＣ、ＰＤＡ，電子手帳、カーナビ等）を用いることもできる。
［背景］車から交通情報を収集する技術は特許文献１４、１５により公知されている。道路利用状況の予測を行う技術が特許文献１７により公知されている。特許文献１６に示す技術は、渋滞の発生を未然に回避するものである。
［課題］移動体通信装置による協調性があり、効率のよい交通情報の収集、渋滞予防及び回避、移動体の動的経路の誘導である。
［手段］交通情報、地図及び施設データなど情報のデータベースおよび車両全体要素を含める最適経路計算機能を交通センターに集約し、通信回線を介して、交通センターは利用者（歩行者、車）から出発時間、発着地を含む旅行計画を収集し、推薦旅行計画、推薦予定経路を利用者に提供する。
利用者の移動体通信装置が現在位置情報を取得し、交通センターが移動体と通信して移動状況を把握し、移動経路の前方渋滞が発生及び予測された時、渋滞が解消できるだけの車を選択して回避経路に転送し、前方の地図が移動体の所持する地図より新しい、又は移動体が前方の地図を所持していない、等必要な時に必要な情報だけを検索し移動機に転送する。
移動機と通信する度に、位置、速度、進行方向等移動情報を収集して、交通実況データベースを更新する。交通センターは移動機と常時に接続、間隔接続、およびイベントを検知した時のみに接続することを含む通信方法を設ける。
移動機が位置、速度、進行方向等を計測し、交通センターに必要な制御待遇、例えば計測データ取得、地図や音声情報転送、注意喚起等を与えて、利用者が運転中ハンドルから手を放さずに交通センターと前記必要な情報のやりとりをする。
【００７８】
移動機が交通センターに通信要求を出す場合には、移動機の位置を含む情報を検知して、経路探索、渋滞情報検索等要求等を交通センターに転送して、交通センターから経路や、コマンドを受信し、コマンドに従い作動したり、受信した経路に利用者を誘導したり、途中において利用者が前記経路を離脱する時再度交通センターに経路探索を要求する。
霧、視界不良時、渋滞発生要因の上り坂等位置で、交差点、車両の速度変化等イベントを検知して、交通センターが車両の位置を連続的に把握し、周辺車両の位置を運転手に知らせ、速度調節を勧告し、安全な車間距離を守り、渋滞予防や安全運転を補助する。
交通センターの仲介によって接近車間での通信により危険防止サービスを提供する。移動中近くの車はグループとして扱い、グループの各メンバーの位置を交通センターが把握し、交通センターの仲介によって、各メンバーの接続番号などを交換し、車両間を直接接続でき、車間の情報通信を行い、グループ内他の車の位置を移動機画面上に表示し、後方、前方等の周辺車両の接近、急ブレーキ、エアバックの作動、事故等危険を検知した場合、関係車に緊急発信し、警告する。接近グループすべての車両位置をリアルタイム的に把握し、車間距離を保持し、各車両搭載の自動運転システムにデータを提供する。
交通センターが、情報が不足する場合、車等移動体に乗っている位置検出装置付きの携帯を移動モニターとして情報を収集し、受信した情報を解析し、情報収集コマンドを作成して、モニターに返送する。
モニターの一つの起動方法は、移動速度が20km/h以上等設定された条件を満たす場合、自動的に情報を交通センターに送信することである。情報を受けた交通センターの一つの応答又はコマンドは、送信間隔ｔを返送する。ｔをモニターの密度ｐと正の相関関係にする。つまりｐが増加するとｔを増大するようにする。密度が増大すると重複する情報発信の可能性が増えるため、発信間隔を増大すれば、むだな情報発信を抑えることができる。例えば、ｔを定数ａ、ｂを用いてｔ＝ａ＊ｐ＋ｂにより求める。具体例は、ｐが半径１０ｋｍ以内、発信時刻の差１０分以内のモニターの台数が１０台、ａ＝５、ｂ=１０とすると、ｔが６０分である。つまり、モニターに６０分以後再度情報を送信することを指示する。
【００７９】
ｐの具体定義（計算）方法、ａ、ｂの値が計測地の重要度により違っても良い。例えば、都心部では郊外よりも計測密度を高める必要がある場合、ａ、ｂの値又はｐのカウント半径を郊外より小さくすれば良い。センターはモニターの現在地により所定の値を選択して使う。
更にコマンドに次の情報発信条件を含めても良い：指定時間帯発信しない。指定移動速度範囲内発信しない。指定地理範囲内発信しない。速度や移動方向が変化したときだけ発信する。
移動モニターの運営は、情報提供者に報酬を与え、又は、自動モニター機能内蔵の携帯電話を発売する。好ましく報酬提供方法は提供した情報量を報酬ポイントに換算して記憶措置に保存する。利用者が貯めたポイントと引き換えに経路誘導などサービスを提供する。
交通流の実況、緊急車両などによる信号制御ができる。例えば、車両の予想位置が交差点に近くになると、交通センターが発信し、リアルタイムに車両位置を把握して、必要ない赤信号を出さない。緊急車両等は自らリアルタイムに位置情報を発信すれば、前方交通信号の最適化制御が可能である。交通センターが、緊急車両の前方経路にある他の車両の位置を調べて、該当車両に退避を指示できる。
交通センターは速度超過や交差点付近車両の挙動に監視でき、衝突する危険性を探知したら、即時関係する運転手や歩行者に警告する。交通センターは移動端末を持つ歩行者等への経路案内サービスを行うことができる。移動計画、通勤経路及び現在地、時刻等により終電や、電車運休の回避経路を案内できる。
【００８０】
［作用、効果］
交通案内を実現しながら、この実現の為の情報を収集できる効果がある。渋滞の増加→サービスの要求の増加→交通センターが収集できる情報量の増加→収集される情報を基に誘導→渋滞の減少というフィードバックが期待できる。
交通センターは動的に推薦経路を案内することにより、従来無次序な交通流を次序整然に変えることにより最適交通システムを実現する事が可能となる。正確に、リアルタイムに、かつ個々の運転手や歩行者個人専用の情報を提供できる。渋滞の発生以前に予測して、且つ個々の車両のルート情報に応じた最適な回避ルートを指示することができ、交通網の輸送能力を特定の道路に集中させることなく、十分に利用することができる。道路上に固定的にセンサーを設置する場合に比較して測定地点が限られず、道路上まんべんなく且つ確率的に均等に又は重要度に応じた交通状態情報を収集することができる。
移動中や運転中交通法で禁じられている携帯を操作する事がなく、車両に対して動的経路誘導、渋滞回避を案内できる。歩行者に対して電車運行中止事故の場合迂回手段を案内できる。
安全運転の支援、交通管理の最適化、道路管理の効率化、歩行者等の支援、緊急車両の運行支援、渋滞の緩和や渋滞発生を未然に防止することが容易になる。
【産業上の利用可能性】
【００８１】
以上のように、本発明は通信網上電子装置を用いた通信方法に適している。
【図面の簡単な説明】
【００８２】
【図１】本発明の基本概略構成例を示す図である。
【図２Ａ】ＴＤＢの内容を示すレコードのレイアウト図である。
【図２Ｂ】Ｒ１ＤＢの内容を示すレコードのレイアウト図である。
【図２Ｃ】ＧＤＢの内容を示すレコードのレイアウト図である。
【図２Ｄ】Ｒ２ＤＢの内容を示すレコードのレイアウト図である。
【図２Ｅ】Ｒ３ＤＢの内容を示すレコードのレイアウト図である。
【図２Ｆ】Ｒ４ＤＢの内容を示すレコードのレイアウト図である。
【図２Ｇ】Ｒ５ＤＢの内容を示すレコードのレイアウト図である。
【図２Ｈ】ＴＲＤＢの内容を示すレコードのレイアウト図である。
【図３Ａ】ＰＤＤＢの内容を示すレコードのレイアウト図である。
【図３Ｂ】ＶＤＢの内容を示すレコードのレイアウト図である。
【図３Ｃ】ＶＲＤＢの内容を示すレコードのレイアウト図である。
【図４】本発明の一実施形態のフローチャートである。
【図５】別の実施形態のフローチャートである。
【図６】別の実施形態のフローチャートである。
【図７】別の実施形態の構成を示す図である。
【図８】別の実施形態のフローチャートである。
【図９】別の実施形態構成例を示す図である。
【図１０】別の実施形態のフローチャートである。
【図１１】別の実施形態の早期決定処理の部分フローチャートである。
【図１２】別の実施形態のフローチャートである。
【図１３】別の実施形態のフローチャートである。
【図１４】別の実施形態のフローチャートである。
【図１５】別の実施形態構成例を示す図である。
【図１６】別の実施形態のフローチャートである。
【図１７】別の実施形態のフローチャートである。
【図１８】別の実施形態の構成を示す図である。
【図１９】別の実施形態の構成を示す図である。
【図２０】発信処理部分フローチャートである。
【図２１】匿名の通信に関するシステム構成を示す図である。
【図２２】第１の当事者の処理の部分フローチャートである。
【図２３】第２の当事者の処理の部分フローチャートである。
【図２４】待遇交換処理部分のフローチャートである。
【図２５】別の実施形態のフローチャートである。
【図２６】一実施形態の構成を示す図である。
【図２７】位置情報システムの構成を示す概念図である。
【図２８】車両用走行誘導機能のフローチャートである。
【図２９】位置情報等に関する本発明別の形態の概念図である。
【図３０】メール送信クライアントの構成を示す図である。
【図３１】メール送信フローチャートである。
【図３２】多機能電話機の構成を示すブロック図である。
【図３３Ａ−Ｄ】前記電話機の指示ファイル内容を示す図である。
【図３４】前記電話機のフローチャートである。
【図３５】自動審査により関係者の電話番号に正常通話できる待遇を自動的に与える例を示す図である。
【図３６】留守番電話機実施例の電話機構成を示す図である。
【図３７Ａ−Ｃ】前記電話機の指示ファイル内容を示す図である。
【図３８】メール受信クライアント実施例の構成を示すブロック図である。
【図３９Ａ−Ｄ】前記実施例の指示ファイル内容を示す図である。
【図４０】受信処理の概略フローチャートである。
【図４１】質問入力画面を示す図である。
【図４２】初期待遇選択画面を示す図である。
【図４３】インターネットテレビ電話及び監視システム構成を示すブロック図である。
【図４４】その実施例の内部構成を示すブロック図である。
【図４５】メインプログラムの動作を示すフローチャートである。
【図４６】メインメニュー画面を示す図である。
【図４７】連絡帳画面を示す図である。
【図４８】メンバー追加画面を示す図である。
【図４９】待遇申請処理を示す図である。
【図５０】個人設定画面を示す図である。
【図５１】ログイン処理動作を示すフローチャートである。
【図５２】友達リスト編集画面を示す図である。
【図５３】待遇申請資格指定画面を示す図である。
【図５４】テレビ電話通信プログラムの動作を示すフローチャートである。
【図５５】接続待機中画面を示す図である。
【図５６】テレビ電話通信中画面を示す図である。
【図５７】待遇関係を築く流れ概要を示す図である。
【図５８】メールサーバシステム実施例の構成を示すブロック図である。
【図５９】待遇情報データ・データベースを示す図である。
【図６０】案内情報データ・データベース（ＧＤＢ）を示すブロック図である。
【図６１】第２ルールセットを示す図である。
【図６２】第１ルールセットを示す図である。
【図６３】攻撃防止用第３ルールセットを示す図である。
【図６４】使い定数を示す図である。
【図６５】中止用第３ルールセットを示す図である。
【図６６】第５ルールセットを示す図である。
【図６７】入力コンポーネントのユーザ・インタフェースを示す図である。
【図６８】入力コンポーネントに渡すデータを示す図である。
【図６９】電子決済に関する方法及びシステムを示すブロック図である。
【図７０】電子決済実施例のＴＤＢを示す図である。
【図７１】電子決済実施例のＲ１ＤＢを示す図である。
【図７２】乗車券に関する別の実施形態のブロック図である。
【図７３】口座と仮想口座を模式的に示す図である。
【図７４】仮想口座模式図における取引処理の流れ図である。
【図７５】承認処理の流れ図である。
【図７６】オフライン承認の流れ図である。
【符号の説明】
【００８３】
１１、１１１、２１１……プロセッサー
１２、１１２、２１２……入出力制御手段
１３、１４、１１４、２１４……記憶装置
１５、１１５、２１５……通信転送装置
１６……キーボード及び表示部。
１７……マイク、スピーカー
１８……カメラ及びキーボード及び表示部。
１９……バイブレーター
２０……指紋センサー

【特許請求の範囲】
【請求項１】
口座を有する顧客の端末から、通信ネットワークを介して、少なくとも一つ承認条件を受信する工程と、
前記承認条件が上限額を含むものであり、
請求金額を前記口座の利用可能金額の残高から減算して残高更新する取引の承認を要求する承認要求のうち、前記請求金額が前記上限額を超える場合には、当該承認要求を無条件に否認し、

前記承認要求を受信する工程と、
前記承認要求は選択情報を含み、
前記選択情報は、特有情報が含まれない情報であり、
前記特有情報は、前記口座に関連付けられた顧客側特有の情報であり、

前記選択情報に基づいて条件の集合から適用条件を選択する工程と、
前記集合は、可変上限額条件が含まれないものであり、
前記可変上限額条件は、前記口座に入金する処理が行われたときに、前記上限額が変更される条件であり、

前記適用条件が満たされるか否かを判断する工程と、

前記請求金額が前記残高以下であるか否かを判断する工程と、

前記請求金額が前記残高以下である場合、前記適用条件が満たされる判断のみに応じて前記取引を承認する工程と、

を含むことを特徴とする取引方法。

【請求項２】
通信ための装置であって、
アドレスのリストのメンバーどれか通信要求に含まれるか否かを決定する第１決定手段、
第１否定決定に応じて条件が満たされるか否かを決定する第２決定手段、
前記条件が満たされる第２肯定決定に応じて制御動作を引起す手段、及び
前記条件が満たされない第２否定決定に応じて限定動作を引起す手段を備え、
前記アドレスのリストは少なくとも一つアドレスを含み、
前記通信要求は前記通信要求の源の目的が達成される前に受入れる情報であり、
前記第１否定決定は前記リストのメンバーどれも前記通信要求に含まれない決定であり、
前記制御動作は前記目的を達成するためにリソースの利用を行う動作であり、
前記限定動作は前記利用を限定する動作であり、及び
前記限定動作は前記目的を達成するために前記源へ戻り情報を送る動作を含んだことを特徴とする装置。

【図１】

【図２Ａ】

【図２Ｂ】

【図２Ｃ】

【図２Ｄ】

【図２Ｅ】

【図２Ｆ】

【図２Ｈ】

【図３Ａ】

【図３Ｂ】

【図３Ｃ】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３Ａ】

【図３３Ｂ】

【図３３Ｃ】

【図３３Ｄ】

【図３４】

【図３５】

【図３６】

【図３７Ａ】

【図３７Ｂ】

【図３７Ｃ】

【図３８】

【図３９Ａ】

【図３９Ｂ】

【図３９Ｃ】

【図３９Ｄ】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４９】

【図５１】

【図５７】

【図５８】

【図５９】

【図６０】

【図６１】

【図６２】

【図６３】

【図６４】

【図６５】

【図６６】

【図６７】

【図６８】

【図６９】

【図７０】

【図７１】

【図７２】

【図７３】

【図７４】

【図７５】

【図７６】

【図２Ｇ】

【図４６】

【図４７】

【図４８】

【図５０】

【図５２】

【図５３】

【図５４】

【図５５】

【図５６】

【公開番号】特開２０１０−１７１９８８（Ｐ２０１０−１７１９８８Ａ）
【公開日】平成２２年８月５日（２０１０．８．５）
【国際特許分類】
【出願番号】特願２０１０−２９９３８（Ｐ２０１０−２９９３８）
【出願日】平成２２年２月１５日（２０１０．２．１５）
【分割の表示】特願２００５−１８１４８５（Ｐ２００５−１８１４８５）の分割
【原出願日】平成１７年６月２２日（２００５．６．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０２２９６８２２）
【Ｆターム（参考）】