(57)【要約】【課題】通信装置の所有者の意思通りに安心に通信資源、付属装置を効率的な活用する。迷惑通信を排除し、無駄な通信量を削減し、監護、匿名通信、通信装置の付属装置を活用し効率的な経路誘導サービスシステムを実現する。【解決手段】通信装置の支配者が予め通信装置とネットワークの間に介在する電子秘書に指示を出し、前記電子秘書が前記支配者の指示内容に従って、発信者または通信内容を識別した上で、個々の発信者の通信要求に対して、拒否から制御許可まで複数の処置する方法を備え、内外から到着する通信要求を処理する。【選択図】図１
2006215590.tif 000002
【特許請求の範囲】
【請求項１】
電気通信ネットワークにおけるメール通信装置に、通信を支援する電子秘書プログラムコード手段、
（ａ）指示ファイルにアクセスするアクセス手段と、前記指示ファイルが、
（１）ネットワークからメールの受信を許可する発信者のメールアドレス・リスト（以下「ホワイトリスト」という、ホワイトリストは第１ルールセットの部分セットに属する第１のルールの発信者ＩＤにより構成されるリストであり、前記部分セットは通信許可待遇を有する第１のルールのセットである）と、
（２）メールの件名に受信が許可されるための条件に関する申請内容を記載するように促す提示情報と、
（３）受信許可キーワード・リスト（受信許可キーワード・リストは第２ルールセットの部分セットに属する第２のルールの期待する申請内容により構成されるリストであり、前記部分セットは通信許可待遇を有する第２のルールのセットである）と、を有する、
（ｂ）メールエンベロープ及びヘッダからなる群から選択されるものから発信者のメールアドレスを検出する手段（以下「アドレス検出手段」という）と、
（ｃ）メールヘッダから前記受信許可キーワードを検索するテキスト解析手段と、
（ｄ）前記提示情報を前記発信者に返信する手段と、
を含むことを特徴とするプログラムを記録した記録媒体。
【請求項２】
請求項１に記載の記録媒体において、前記指示ファイルは、さらに、受信が拒否された発信者のメールアドレスと、前記メールアドレスの受信時刻の対を記録する記録リスト（以下「拒否履歴リスト」という、拒否履歴リストは第３ルールセットの部分セットに属する第３のルールの発信者ＩＤと受信時刻により構成されるリストであり、前記部分セットは受信拒否待遇を有する第３のルールのセットである）と、を有する、そして、さらに、メールの受信を拒否するとき、前記拒否履歴リストに拒否履歴情報を記録する記録手段と、前記アドレス検出手段を用いて検出したメールアドレスを前記拒否履歴リストで検索する事によって、前記メールが所定の時間以内で再送信されたメールであるか否かを判断するプログラムコード手段（以下「再送信検出手段」という）と、を含むことを特徴とするプログラムを記録した記録媒体。
【請求項３】
請求項２に記載の記録媒体において、前記電子秘書が受信サーバ側に設置され、前記受信を拒否する事は、メールの送信クライアントにエラー状態を返してから、根底にある配送系コネクションを閉じることにより通信を強制中止する事であり、配送系コネクションを閉じる手段（以下「強制中止手段」という）と、を含むことを特徴とするプログラムを記録した記録媒体。
【請求項４】
請求項３に記載の記録媒体において、メールの通信要求が着信する時、先ずエンベロープを受信し、受信したエンベロープから発信者のメールアドレスを検出し、検出されたメールアドレスが前記ホワイトリストに載っていない場合、前記再送信検出手段を用いて再送信を検出し、前記メールが再送信されるメールでない場合、ヘッダを受信し、受信したヘッダから受信許可キーワードを検索し、前記キーワードが検出されない場合、前記提示情報を前記発信者に返信して、前記強制中止手段を用いて、メールのボディを受信しないで強制終了して受信を拒否し、前記拒否履歴情報を記録し、前記メールが再送信されるメールである場合、メールのコンテントを受信しないで、通常のメール通信手順に従って受信を拒否する手段と、を含むことを特徴とするプログラムを記録した記録媒体。
【請求項５】
請求項２に記載の記録媒体において、前記指示ファイルは、さらに、ネットワークからメールの受信を拒否する発信者のメールアドレス・リスト（以下「ブラックリスト」という、ブラックリストは第１ルールセットの部分セットに属する第１のルールの発信者ＩＤにより構成されるリストであり、前記部分セットは受信拒否待遇を有する第１のルールのセットである）と、を有する、前記電子秘書が、受信クライアント側に設置され、前記受信を拒否する事は、受信サーバへ削除コマンドを送出して該メールを受信サーバから削除させることであり、そして、前記電子秘書が受信サーバにログインし、前記メールのヘッダを受信してから、ヘッダから前記アドレス検出手段を用いて発信者のメールアドレスを検出し、検出されたメールアドレスがホワイトリスト及びブラックリスト共に載っていない場合、ヘッダから受信許可キーワードを検索し、前記キーワードが検出されない場合、前記再送信検出手段を用いて再送信を検出し、前記メールが再送信されるメールでない場合、前記提示情報を前記発信者に返信して、メールのボディを受信しないで受信を拒否し、前記拒否履歴情報を記録し、前記メールが再送信されるメールである場合、受信を拒否し、前記メールに該当する拒否履歴情報を前記拒否履歴リストから削除し、前記メールアドレスをブラックリストに記録する手段と、を含むことを特徴とするプログラムを記録した記録媒体。
【請求項６】
電気通信ネットワークにおけるメール通信システムであって、
（ａ）次のメール送信クライアントと、前記メールは、エンベロープとコンテントによる実体を構成し、前記コンテントはヘッダとボディの２つの部分を持ち、前記エンベロープは伝送や配送をなし遂げるのに必要などんな情報も含んでいて、前記コンテントは受取人へ配達される目的物を含み、前記ヘッダは標準に定められた特殊な構文による文字列のシーケンスであり、前記ボディは前記ヘッダに続く、単なる文字のシーケンスであり、そして、前記メールを前記エンベロープ、前記ヘッダ、前記ボディの順番に受信サーバに送信し、前記ボディの送信を認可するか否か、前記ヘッダに含まれた情報により前記受信サーバが判定し、前記ボディを送信する前に、認可されているかチェックする手段を含む、
（ｂ）次のメール受信サーバと、を含むことを特徴とするシステム。前記受信サーバは次の電子秘書を含む、
（１）指示ファイルにアクセスするアクセス手段と、前記指示ファイルが、
（i） ホワイトリストと、
（ii）メールのヘッダに受信が許可されるための条件に関する申請内容を記載するように促す提示情報と、
（iii）受信許可キーワード・リストと、を有する、
（２）アドレス検出手段と、
（３）メールヘッダから受信許可キーワードを検索するテキスト解析手段と、
（４）前記提示情報を前記発信者に返信する手段と、を備えることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信網上電子装置を用いた通信に関し、特に、通信接続の確立する段階に関し、通信のセキュリティーの確保に関する。通信と遠隔制御機能との一体化に関する。
【背景技術】
【０００２】
電気通信は広範囲に普及した。インターネットを活用したさまざまな情報技術サービスが一般社会に急速に浸透し、高速大容量常時接続通信が一般家庭に普及し、また発信者番号通知も一般化している。現在では発信者が通信の主導権を握っている。
しかしながら、着信者の意思に反する迷惑通信、迷惑メールによる通信インフラの麻痺及び機能の低下、正常通信の溺没、等マイナスの問題も浮上した。従来の迷惑通信防止技術は、指定拒否（ブラックリスト）、指定受信（ホワイトリスト）機能を実現した。特許文献６、１２、１３、１５、１６は、上記リストに登録・解除するときの利便性を高めることができる。受信した迷惑メールに未開封を記録し送信主へ逆課金するという方法もある（例えば、特許文献４参照）。到着した電子メールから発信者の識別情報を抽出するものもある（例えば、特許文献５参照）。
【０００３】
しかし、これらの技術は、（ａ）技術の進歩に伴い、小形携帯通信装置が多機能化している。通信装置の付属カメラ、付属位置情報装置、などの付属機能の活用、子供、ボケ老人、無人でも安全に通信手段としても監護のためにも使える、潜在的なニーズが満足されていない。例えば位置情報の活用について、走行経路を設定する制御手段を備えるものあるが、計算量が大きく、携帯電話など小形装置に向かない（例えば、特許文献７、８参照）。特許文献９に示す携帯電話の移動機の受信したＧＰＳ位置信号により、その移動機の位置を検索するものあるが、電話の通信と位置検索の通信は別々に二つのチャネル（２回線）を必要であり、効率が悪い。（ｂ）迷惑電子メールに対して公衆網の通信量削減と接続メールサーバの処理軽減ができない。（ｃ）特許文献１３、１４に示す様な自動返信する技術では無制限に拒否通知や、確認メールが自動返信されるため、なりすましメールを受信した場合、詐称されたアドレスに大きな被害をきたすことが起こりうる。（ｄ）柔軟な対応できない。例えば、表現の自由や営業の自由を妨げる。迷惑メールの概念として、どの内容のメールが迷惑メールに当たるかは、個別の着信者側の主観的要素を抜きに決定することができない、共通の基準が存在しない。着信者側の主観を反映し、受信者の興味がある商品販売メールが迷惑ではないがホワイトリストに登録する必要がない。又は、受信を許可してもいいですが大量送信が許せない。等細かいニーズが対応できない。（ｅ）一般に、従来の通信システムは、通信当事者が互いのアイデンティティを知っているという概念に前提としている。例えば個人の電話番号が個人のアイデンティティの役割を果たしている。このため安易に電話番号を未知の相手に公表すると、何かの危険が潜むことになる。一方、ネットワーク上一般向けの個人対個人、個人対会社などの取引、交際、求職など活動において、最初又は最後まで匿名通信必要な場合、一旦相手を招待したら、自分のメールアドレスまたは電話番号が相手に開示されるため、身をひきたい時簡単に相手と関係を断ち切れない。特許文献１０では、匿名通信について、２つのステップを要し、専用の匿名通信センターを通して通信内容から双方の身元情報を取り除く通信チャンネルを設立するという方法が示されている。
【０００４】
特許文献１には、通信を許可または禁止する相手局の識別情報リストを編集／登録する技術が記載されており、特許文献２には、到着した電子メールを受信者に転送するか否かを判定する技術が記載されており、特許文献３には、受信した電子メールの本文中の語句と記憶された語句を比較する技術が記載されており、特許文献４には、受信した電子メールのタイトル及び発信者のメールアドレスを不要と判断する技術が記載されており、特許文献５には、到着した電子メールから発信者の識別情報を抽出する技術が記載されており、特許文献６には、着信者が拒否番号を登録したり解除するときの利便性を向上させるする技術が記載されており、特許文献７には、車載用経路探索する技術が記載されており、特許文献８には、車両用走行誘導する技術が記載されており、特許文献９には、移動機の位置情報検索する技術が記載されており、特許文献１０には、匿名通信する技術が記載されており、特許文献１１には、ルールベース技術を用いて、顧客と相互作用ができるソフトウェア・モジュールを提供する技術が記載されており、特許文献１２には、迷惑電話を防ぐ技術が記載されており、特許文献１３、１４には、未許可メール送信者に自動返信する技術が記載されており、特許文献１５には、メールの受信データ容量の累計を上限容量を超えた場合は、受信禁止リストに追加する技術が記載されており、特許文献１６には、電子メール本体の送信前に電子メールの一部を送信して電子メール本体の送信許可を行う技術が記載されており、しかし、該当文献は、具体的に実施可能な技術的な内容を開示されていない。特許文献１７には、電子メールの件名にピン・コードが有るかどうかに応じて電子メールの受信を許可するか否か決定する技術が記載されており、しかし、ピン・コードを事前に相手に通知しなければならないので、真に通信を行いたい相手にも、ピン・コードを知らないと確実な通信ができない。特許文献１８には、サーバが受信したメールから抽出した主要情報を個人端末に送信し、受信諾否を問合せる技術が記載されており、特許文献１９には、ヘッダ情報に基づきメール要求命令を送信する技術が記載されている。
【特許文献１】特開平５−１４４８８号公報（請求項１、第１−４図）
【特許文献２】特開２００２−３４４５２４号公報（請求項１−１５、第１−１９図）
【特許文献３】特開２０００−１０８８０号公報（請求項１−５、第１−１８図）
【特許文献４】日本国特許第３２８３８７３号明細書（請求項１−２、第１−３図）
【特許文献５】日本国特許第３００３６４０号公報（請求項１−２、第１−２図）
【特許文献６】特開２００２−２９０５６６号公報
【特許文献７】特許第３４６００３３号明細書
【特許文献８】特公平６−６０８２１号公報明細書（請求項１−２、第１図）
【特許文献９】日本国特許第３０３９５３６号明細書
【特許文献１０】米国特許第５８８４２７０号明細書
【特許文献１１】米国特許第６０７０１４９号明細書
【特許文献１２】米国特許第６３７０２３５号明細書
【特許文献１３】米国特許第６６９１１５６号明細書
【特許文献１４】特開２００３−１４１０４３号公報
【特許文献１５】特開２００２−３７４３０７号公報
【特許文献１６】特開２００３−３６２３０号公報
【特許文献１７】特開２００１−２１７８６１号公報
【特許文献１８】特開２００３−３３３０９７号公報
【特許文献１９】特開２００３−２１６５４８公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
これらはすべて通信に関する通信機能を備えた電子装置（以下通信装置という）を所有する当事者（支配者）の意思、即ち発信者からの迷惑を防止したい、及び発信者に通信装置の一部の又は全部の制御権をあげてもいいという二つの方向に表現された意思に関するものである。従来技術の問題点はこの意思を満足できないことである。この問題点を解決し、前記支配者の意思を満足させることが本発明の目的である。具体的に、通信機能付き電子装置の支配者の意思通りに安心に通信資源、付属装置を効率的な活用することが本発明の目的である。通信装置をリモードで制御及び使用し、正常的に開放的に従来の通信機能を損なうことなく迷惑通信を排除し、無駄な通信量を削減し、監護、匿名通信、通信装置の付属装置を活用し効率的な経路誘導サービスを実現することも本発明の目的である。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、図１に示すように、本発明は通信装置の支配者が予め通信装置とネットワークの間に介在する電子秘書に指示を出し、前記電子秘書が前記支配者の指示内容に従って、到着する通信要求に対して、複数の処置する方法を備え、通信要求を受けた時、発信者または発信者グループ、及び着信者、を識別した上で、前記複数の処置する方法から一つを選び出して、前記通信要求を処置する；本明細書において、特に明記しない限り、前記処置する方法を「待遇」といい、前記支配者により決める特定の通信要求に対する特定の処置をする方法を意味する。
着信する場合、従来概念の通信は発信者主導が普通であり、例えば相手に電話をかけると相手が受けることが当然と考えられてきた。応答方法も単純であるため、特別な用語で記述する必要がない。本発明は応答方法が多様に成っていて、簡潔に表現する適当な技術用語が存在しない。そのため「待遇」という言葉を使い、通信する当事者双方の関係を表現する。
【０００７】
本発明の基本思想は装置の支配者の意思を発信者に待遇を与える事によって実現する。電子秘書は支配者しか設定できない指示ファイルに従って待遇を実施する。支配者は発着信者のどちらにも成りえる。例えば、本発明を子供用携帯電話（以下、文脈で区別できる場合単に「携帯」という）に応用する場合、支配者が親であり、親が指示ファイルの設定により、子供へ通話できる発信番号を限定できる。
待遇の種類は外側（ネットワーク）から到着する通信要求の発信者に対して、前記通信要求を拒否する待遇は「受信拒否」といい、前記通信要求を着信者に伝達する待遇は「通信許可」という。着信側が電子秘書を使わなくでも基本の通信許可又は受信拒否待遇に相当するものが存在する。内側（通信装置）から発信する場合、着信者により与えられた待遇が受信拒否である時、電子秘書はさらに、着信者ＩＤと与えられた受信拒否待遇を拒否履歴として一時的に記憶し、拒否履歴が新しい時再び同じ着信者へ発信しない。
【０００８】
「制御許可」という種類の待遇を設ける。制御許可とは発信者に通信装置の制御をあげて、一部又は全部機能を利用できるようにする。制御許可は、通信要求を許可して、発信者が制御権を持つことを着信者側通信装置に指示し、前記発信者に着信者の介入なしで通信させることを意味し、ただし、通信回線を使用しなくでもできる操作を単に通信回線を通して行うことを除く。例えば、制御権がある発信者が遠隔から通信装置のカメラを起動し着信側を監視できる。制御レベル又は制御範囲又は制御対象が異なる複数の制御許可が有り得る。例えば、通信装置のマイクを通して傍聴だけを許し、カメラを通して監視を許さない。制御許可は、外出先から留守番電話のセットなど、通信回線を使用しなくでもできる操作を単に通信回線を通して行うことを含まない。
「限定通信許可」という種類の待遇を設ける。限定通信許可は、限定的に通信を許可する。例えば、メールの限定されたサイズの一部の受信を許可するや今回に限りメール受信又は電話通話を許可するなどである。
【０００９】
「申請受理」という種類の待遇を設ける。申請受理は、発信者が着信者に通信の希望を表明する行為を許可することを意味し、前記行為は発信者識別ための情報を含む通信用件を着信者に伝えることが可能であり、且つ、提示情報を発信者に提示されてから、発信者の反応を受け取り、前記反応に基づいて通信要求を許可できると判断される前に、発信者本来の通信目的を達成できない。前記用語「通信用件」は、発信者本来の通信目的を達成する前に、発信者と前記電子秘書の間通信接続を確立して、前記電子秘書に届いた着信者と通信を要求する通信内容を意味する。例えば電話通信の場合、発信者氏名や電話番号、用件を録音して受信者に伝え、且つ、電子秘書が音声案内を送出し、発信者の返事を受け取るが、返事内容が正しいと判断される前に、受信者と会話を許可しない。繰り返しの問答が可能である。すぐに判断と着信者事後の判断が可能である。返事がダイヤル番号、又は音声識別により受け取ることが可能である。電子メール通信の場合、メールアドレス、件名、又はメール全体を受信するが、内容が正しい或いは期待に合うと判断される前に受信者に渡さない、且つ、電子秘書が提示情報を返信して、提示情報に従った発信者の返事内容が正しいと判断される前に受信者に渡さない。この発明の目的を達成するためのものなら、申請受理は、案内メッセージの提示と反応の受け取る進行中のサイクルを促進するどんなやりとりにも言及するものである。
【００１０】
本明細書中に使用された用語、・「通信要求」は、発信者本来の通信目的を達成する前に、電子秘書に届いた通信内容を意味する、例えば、接続要求、又は、着信者が受信する前、電子秘書が受信したメール又はデータ又は承諾要請などが通信要求である、・「ルール」は、処理対象物の検索条件と該検索条件が満たされた時の行動の定義情報の対で表現された、処理の制御に用いられる知識を意味し、・「発信者」は、通信の開始を要求する側当事者及び設備からなる群から選択されるものを意味し、・「待遇情報」は、着信者ＩＤと、第１ルールセットの情報であり、但し前記着信者ＩＤが一つしかない場合、第１ルールセットを意味し、・「ＩＤ」は、通信サービスの提供者により通信サービスを利用する当事者に提供した識別子を意味し、一つの当事者に複数の識別子を提供することが可能である、一つのＩＤ又はＩＤの一部により発信者グループを識別する事が可能である、・「通信許可」は、通信要求を着信者に伝達することを意味し、電子秘書が通信を許可できると判断し、通信要求を着信者に伝達して、従来の通信手段の通信要求を着信する時と同じ状態にし、着信者が通信するか否かの最終判断ができる、・「受信クライアント」は、サーバ上に保存されている着信者のメールを回収できる装置を意味し、例えばメールを受信する携帯電話、及びIAB(Internet Architecture Boad)によって発行された標準勧告文書RFC (Request for Comments)に規定されたPOP3(Post Office Protocol - Version 3)に準拠したサービスを使おうとしているホストがこれに該当し、・「送信クライアント」は、メールを送信する装置を意味し、例えばメールを送信するクライアント端末、メールを送信するＩＳＰサーバが該当し、・「サーバ」は、サービスを提供する側を意味し、電話の交換機がサーバに該当し、・「受信サーバ」は、メールを受信して保存し、着信者がアクセスする場合、保存されたメールを着信者に渡すサービスを提供する装置を意味し、例えば携帯電話会社のメールセンター、及びPOP3サービスを提供しているホストが該当し、・「通信」は、情報及び制御信号を伝達することを意味し、・「メール」は、電子メールを意味し、・「事前申請」は、支配者が自分のＩＤ(識別子）を含む情報を開示して、発信者に通信の許可を申請させ、発信者が通信要求を出す前に、前記支配者に対して通信の許可を申請することを意味し、・「身元登録」は、通信サービスを利用する当事者をＩＤにより特定し、前記通信サービスの提供者は、前記ＩＤを前記当事者に提供し、前記通信サービスの提供者及び第三者からなる群から選択されるものが前記当事者の身元確認情報を登録することを意味し、・「傍聴許可」は、発信者に着信者側通信装置の送話器により取得する音声信号を取得させることを意味し、・「監視許可」は、発信者に着信者側通信装置を通して、着信者側に設置される撮像装置により取得する画像信号を取得させることを意味し、・「位置取得許可」は、発信者に着信者側通信装置を通して、着信者側に設置される位置取得手段により取得する位置情報を取得させることを意味し、・「注意喚起許可」は、発信者に着信者側通信装置を通して情報を出力させ、着信者の注意を喚起させることを意味し、・「情報転送許可」は、発信者に着��者側通信装置へ情報を転送させることを意味し、・「初期待遇」は、電子秘書が設定されたルールセットを適用することにより、待遇が決められない場合に、予め設定された処置をする方法を意味し、・「件名」は、メールヘッダに含まれる人がよめる情報の内容を持つ目的がある情報フィールド（Informational fields）を意味し、・「発信者電子メールアドレス」は、発信者自ら指定した返信用宛先メールアドレスを含み発信者にメールを送信する宛先メールアドレスを意味し、・「待遇申請」は、通信許可を申請することを意味し、従来の発信行為も待遇申請の一形態として考えられ、・「待遇関係」は、当事者双方がお互いに相手に与える待遇によって築く関係であり、・「待遇セット」は、複数の待遇の集合を意味し、・「申請内容」は、通信の許可を申請する内容を意味し、・「期待する申請内容」は、着信側当事者が期待する申請内容を意味し、例えば相手に着信側当事者の名前を尋ねる場合、正確の名前が期待する申請内容であり、即ち質問の正解が期待する申請内容であり、又は興味がある話題や、キーワードや期待する申請内容として指定可能である。
【００１１】
メール関係用語概念説明：メールの送信の流れは、一般に発信者端末（送信クライアント）から送信メールサーバ（受信サーバ）、送信メールサーバ（送信クライアント）から受信サーバ、受信サーバから着信者端末（受信クライアント）までである。送信メールサーバは、受信サーバと、送信クライアントの二つ役割を持つ。以下、本発明の詳細、実施の形態について図面を用いて説明する。
図１は本発明の一実施形態の概略構成例を示す図である。通信装置１０１が電子秘書１０２を介在して網１０４における通信を行い、電子秘書は、通信装置側又は通信サービスを提供するサーバ側に、電話通信の場合は、電話機側又は交換機側に組み込んでも良い。サーバ側に組み込む場合、通信チャンネルを通して通信装置とつなげる。指示ファイル１０３は電子秘書に組み込み又は電子秘書と独立しても良い。支配者が直接に指示ファイルにデータを入力しても良い（図に示さず）。指示ファイルはデータ記憶装置の中に保存される。本発明の目的を達成して得る記憶装置であれば、例えば磁気記憶装置、ＲＡＭ、ＲＯＭなどの電子メモリ回路の他に、光学記憶媒体などを採用することができる。指示ファイルの望ましい実装は、マルチメディア情報を含め、相互に関連するデータを整理・統合し、検索しやすいデータベースである。
【００１２】
図２は本発明の一実施形態のフローチャートである。電子秘書を介在する通信を行う方法であって、支配者は予め電子秘書に指示を出し、前記電子秘書が前記支配者の指示内容に従って、外側からの通信要求を処理し、当該方法は、（ａ）前記電子秘書に業務を指示する指示ファイルを構築するためにデータを入力するステップと、前記指示ファイルが以下を有する、発信者ＩＤに関する適用条件を有する条件部と、待遇に対応させた行動の実施を指示する実行部とを有するルールで記述された第１のルールのセット（以下「第１ルールセット」という）と（前記第１のルールは、「実際に発信者からの前記通信要求を受ける時、もし前記通信要求から検出される前記発信者ＩＤ（以下「事実発信者ＩＤ」という）が条件部の前記発信者ＩＤと一致すれば、前記待遇に基づいて前記通信要求を処置する」という事柄を表している、本明細書において、前記第１のルールを作成し、前記第１ルールセットに加えることは、発信者に待遇を与えるという）、（ｂ）以下の操作が可能な前記電子秘書を用いて通信を行うステップと、を有することを特徴とする方法。（１）発信者からの前記通信要求から前記発信者ＩＤを検出する、（２）前記指示ファイルにアクセスする、（３）前記第１ルールセット内の全てのルールを対象として、適用条件が成立しているルールを見つけ出し、前記ルールの実行部を実行する（以下単に、所定のルールのセットを適用するという）、（４）個々の前記通信要求に対して、前記通信要求を着信者に伝達すること（以下、「通信許可」という）と、を含む複数の処置する方法（以下、「待遇セット」という）を備え、前記通信要求を受けた時、前記複数の処置する方法から一つを選び出して、前記通信要求を処置する。
【００１３】
外側の発信者の通信要求を着信した時、前記通信要求から前記発信者ＩＤ、即ち事実発信者ＩＤを検出し（２０１）、指示ファイルを読み込み（２０２）、次の第１ルールセット適用手順で第１ルールセットを適用する。即ち、発信者ＩＤと待遇に関する第１ルールセット内の全てのルールを対象として、適用条件が成立しているルールを見つけ出し、発信者ＩＤと事実発信者ＩＤが一致する条件で、Ｒ１ＤＢ（図４参照）を検索し（２０３）、見つかったかどうかを判断し（２０４）、当該レコードが検出された場合、即ち適用条件が成立しているルールを見つけた場合、待遇ＩＤのフィールドから前記発信者に与えた待遇ＩＤを抽出できる。そして、待遇ＩＤに対応させた行動、即ち、ルールの実行部を実行する（２０６）。見つからない場合には、予め決めた処置方法、即ち初期待遇に基づいて前記通信要求を処置しても良い（２０５）。
【００１４】
以下、図３の様には指示ファイルをデータベースに具体化するデータ・データベースの内容を示すレコードのレイアウトを記述する。テーブルは、データベースのすべてのデータを含む。テーブルは列（column）の集まりである。データが行と列の形式にまとめられている。各行（rows）はレコードを表し、各列はそのレコードのフィールドを表す。レコードのレイアウトは、「フィールド名」（図に示す表の左側）と「フィールド特徴」（図に示す表の右側）により整理された情報から成る。行は、それぞれのフィールドと一致する。主キーはテーブルの各行を一意に識別する値が入った列であり、複数の主キーがありえる。外部キーは、２つのテーブルのデータ間のリンクを設定するための列である。
【００１５】
図３は待遇セットの一実施例を記録するデータ・データベース（以下ＴＤＢという）の内容を示すレコードのレイアウト図である。各待遇の具体的な実現は通信装置の違いによって違い、実現できる待遇種類の総数は通信装置の違いによって違う。当事者個人の必要に合わせて待遇セットを拡張、簡略化できる。待遇ＩＤがプログラム内部で呼び出す処理方法（機能）を識別に使え、テキストが利用者に機能の内容を表示に使える。
【００１６】
図４は発信者ＩＤと待遇に関する第１ルールセットを記録するデータ・データベース（以下Ｒ１ＤＢという）の内容を示すレコードのレイアウト図である。
ルールセットは、構造を有するデータにより処理の制御の記述である。つまり、ルールセットが一種の「型」であり、同じ型の異なるデータが複数ありえる。異なるデータの同じルールセットが類似する処理の制御に用いられる。本明細書は、異なるデータで記述する同じルールセットの場合、何に用ルールセットという。  
別の観点から見ると、ルールセットは、目的別のリストの集合である。例えば、ホワイトリストは第１ルールセットの部分セットに属する第１のルールの発信者ＩＤにより構成されるリストであり、前記部分セットは通信許可待遇を有する第１のルールのセットである。ブラックリストは第１ルールセットの、受信拒否待遇を有する部分セットの、発信者ＩＤにより構成されるリストである。
【００１７】
図５は本発明の別の実施形態のフローチャートである。前記指示ファイルは、発信者に提示する提示情報を含み、前記電子秘書は、前記提示情報を前記発信者に提示する操作が可能である。前記指示ファイルは、期待する申請内容に関する適用条件を有する条件部と、待遇に対応した行動の実施を指示する実行部とを有するルールで記述された第２のルールのセット（以下「第２ルールセット」という）と（前記第２のルールは、「もし通信要求から前記期待する申請内容が検出されたら、前記待遇に基づいて前記通信要求を処置する」という事柄を表している）、を含み、前記申請受理は、以下の操作を含み、（ａ）前記通信要求から前記期待する申請内容を検出する、（ｂ）前記第２ルールセットを適用する。ＩＤ検出し（５０１）、指示ファイルを読み（５０２）、第１ルールセットを適用し（５０３）、結果を判断し（５０４）、申請受理は、期待する申請内容と待遇に関す第２ルールセット内の全てのルールを対象として、適用条件が成立しているルールを見つけ出し（５０５）、見つかったか否かを判断し（５０６）、見つからない場合には、予め決めた処置方法、即ち初期待遇に基づき処置する。例えば、提示情報を前記発信者に提示してから受信を拒否する。又は案内も提示しないで受信を拒否する。支配者により決めることが望ましい。初期待遇は申請受理待遇を除いて待遇セットから選択させることが望ましい（５０７）、第１ルールセットの適用条件が成立しているルールが見つからない時、申請受理待遇を実行するか否かを利用者に選択させる事ができる。
【００１８】
適用条件が成立しているルールを見つけた場合、与えた待遇、即ちルールの実行部に記載した待遇に基づいて通信要求を処置する（５０８）。前記待遇は通信許可及び受信拒否を含み、通信を一部許可する限定通信許可、発信者の用件を記録するなど、着信側の通信装置の性能により多様な待遇、即ち多様な処置する方法を通信装置の支配者の意思に従って指定することが可能である。例えば、通信装置が基本的な通信機能しかない場合、電子秘書の通信許可待遇の実施が単に邪魔しない様に通信内容を通過させ、通信許可しないは、単に通信内容を全て遮断する。電子秘書の制御許可待遇の実施が通信装置に被制御状態になるように命令してから、発信者の命令を含む通信内容を通過させる。通信装置の一部しか制御を許さない事が可能である。
第２ルールには、通信する当事者の間しか知らない個人情報を含めることができる。例えば着信者の名前を知っていることがルールとして指定されれば、着信者の名前も知らない発信者を拒否することができる。家族や身内の人を合言葉やパスワードで判断することもできる。電話通信の場合音声認識や声紋認識により相手を認識することもできる。
【００１９】
特許文献１２及び１４に示す従来技術は、本発明の通信要求から期待する申請内容又は所定のキーワードが検出されれば、受信を許可する待遇を与える事と相当する。受信許可キーワード・リストは、第２ルールセットの、受信許可待遇を有する部分セットの、期待する申請内容により構成されるリストにすぎない。
本発明はルールベース基本技術を利用し、支配者の意思をルールとして電子秘書に指示し、着信者に代わって発信者と対話するバーチャル秘書を実現し、通信装置の性能に合わせて、変更可能な待遇セットにより細かいニーズの対応と迷惑通信の防止から、その正反対の遠隔制御、等広範囲の支配者意思を満足することができる。
例えば、本発明の申請受理は、興味がある商品名と今回に限り受信する待遇（第１ルールによって記録する受信許可待遇を与えない）を第２ルールに設定すれば、その商品販売メールを今回に限り受信する。発信者側の自由が制限されない。通信双方の利益になる通信が可能である。
【００２０】
図２５は提示情報の一実施例を記録するデータ・データベース（以下ＧＤＢという）の内容を示すレコードのレイアウト図である。前記提示情報は、発信者に提示する質問を含む場合、図３７に示す形式にしてもいい。
図２６は期待する申請内容と待遇に関する第２ルールセットの一実施例を記録するデータ・データベース（以下Ｒ２ＤＢという）の内容を示すレコードのレイアウト図である。
図３６は発信者と受信時刻と待遇に関する第３ルールセットの一実施例を記録するデータ・データベース（以下Ｒ３ＤＢという）の内容を示すレコードのレイアウト図である。
図３７は発信者に提示する質問と、前記質問の正解と、得点に関する第４ルールセットの一実施例を記録するデータ・データベース（以下Ｒ４ＤＢという）の内容を示すレコードのレイアウト図である。前記質問、及びＧＤＢに保存する提示情報は、は、テキスト、音声、及び画像からなる群から選択されるものを含む。
図６９は着信者ＩＤと発信時刻と待遇に関する第５ルールセットの一実施例を記録するデータ・データベース（以下Ｒ５ＤＢという）の内容を示すレコードのレイアウト図である。
図７０は、待遇関係マスタの一実施例を記録するデータ・データベース（以下ＴＲＤＢという）の内容を示すレコードのレイアウト図である。
【００２１】
図６は、本発明の別の実施形態のフローチャートである。通信は電子メール通信であり、発信者ＩＤは発信者電子メールアドレスであり、提示情報は電子メールを受信する条件の説明を含み、通信許可待遇は電子メールを受信させることであり、発信者に返信することによって提示情報を提示する。通信要求が着信する時、電子秘書が、先ず第１ルールセットを適用し、適用条件が成立しているルールが見つからない場合には、申請受理を行い、前記申請受理を行うステップには、第２ルールセットを適用する時、適用条件が成立しているルールが見つからない、即ち待遇が決められない場合には、前記提示情報を前記発信者に提示してから前記通信要求を拒否する。発信者のメールアドレスを検出し（６０１）、指示ファイルを読み（６０２）、第１ルールセットを適用し（６０３）、結果を判断し（６０４）、第２ルールセットを適用し（６０５）、結果を判断し（６０６）、提示情報はメールを受信する条件の説明を含み、通信許可の待遇はメールを受信させることである。即ち電子秘書はメールを通過させ、着信者がメールを受信する。受信拒否待遇はメールを受信しない（６０８）、提示情報を発信者に提示することは、提示情報を発信者に返信する（６０７）ことである。
図７は、本発明の別の実施形態の構成を示す図である。電子秘書及び指示ファイルＲ１ＤＢ，ＧＤＢ，Ｒ２ＤＢが受信クライアント側利用者端末７０１に組み込まれてある。符号７０２はＩＳＰ（インターネット・サービス・プロバイダー）の受信サーバを示す。
【００２２】
図８は、本発明の別の実施形態のフローチャートである。発信者に提示する提示情報は通信の許可を申請させる、前記提示情報は、少なくともメールの件名に申請内容を記載するように促す内容を含み、例えば質問を提示して、その回答を件名に記入する様に促す。電子秘書が、受信クライアント側に設置され、通信要求を拒否することは、受信サーバへ削除コマンドを送出して該メールを受信サーバから削除させることである。そして、前記電子秘書が受信サーバにログインし（８０１）、メールのヘッダから発信者のＩＤ、即ち発信者のメールアドレスを検出する（８０２）。例えば、一般的なメール受信プロトコールであるPOP3に記載したコマンド「TOP 1 0」を送出し、POP3サーバから１番目のメールのヘッダを受信して解析することにより発信者電子メールアドレスを検出できる。そして、指示ファイルを読み（８０３）、第１ルールセット適用手順で第１ルールセットを適用し（８０４，８０５，８０９）、第１ルールセットから適用条件が成立しているルールが見つからない場合、次の例示手順で第２ルールセットを適用する（８０６、８０７）。まず、Ｒ４ＤＢの全てのレコードを対象として、一つずつ正解内容を抽出し（図３７参照）、抽出した内容に基づいて、前記メールのヘッダに含まれる件名から該当する内容を検索し、採点する（実施例２参照）。そして、Ｒ２ＤＢの全てのレコードを対象として、得点数値と一致するレコードを検出し、検出された場合、即ち適用条件が成立しているルールを見つけた場合、待遇ＩＤのフィールドから待遇ＩＤを抽出できる。そして、ルールの実行部を実行する（８０９）。初期待遇を処理する（８０８）。
【００２３】
到着した電子メールから発信者の識別情報を抽出する発明もある（特許文献５）。本発明は到着した電子メールのヘッダから発信者ＩＤを抽出することが異なる。本発明はメールの本体を開封せずに目的を達成できる。そのためメールの本体を開封する前記発明と比べて、特に携帯等、サーバとの通信の課金部分の通信量が大幅に減少できる。
図９は、本発明の別の実施形態の構成を示す図である。電子秘書及び指示ファイルＲ１ＤＢ，ＧＤＢ，Ｒ２ＤＢが受信サーバ９０１側に組み込まれてある。符号９０２が受信クライアントを示す。符号９０３がメールの送信クライアントを示す。
図１０は、本発明の別の実施形態のフローチャートである。発信者に提示する提示情報はメールの件名に通信の許可を申請させる内容を含み、電子秘書が受信サーバ側に設置され、通信要求を拒否することは、メールの送信クライアントにエラー発生を通告してから通信を中止することであり、そして、前記電子秘書は前記通信要求が着信する時、先ず事実発信者ＩＤが含まれたメールのエンベロープ（封筒）まで受信して、第１ルールセットを適用し、適用条件が成立しているルールが見つからない場合には、前記メールの件名を受信して、申請受理を行うことを特徴とする。
【００２４】
エンベロープ（封筒）まで受信して（１００１）、発信者のメールアドレスを検出し、指示ファイルを読み（１００２）、前記第１ルールセット適用手順で第１ルールセットを適用する（１００３、１００４、１００９）。第１ルールセットから適用条件が成立しているルールが見つからない場合、メールの件名を受信するため、前記メールの件名が含まれるヘッダまで受信し（１００５）、そして、前記第２ルールセット適用手順で第２ルールセットを適用する（１００６，１００７，１００９）。初期待遇を処理する（１００８）。
図１１は、図１０の説明に記載の本発明において、別の実施形態の早期決定処理の部分フローチャートである。前記指示ファイルは、さらに、発信者ＩＤと受信時刻に関する適用条件を有する条件部と、待遇に対応させた行動の実施を指示する実行部とを有するルールで記述された第３のルールのセット（以下「第３ルールセット」という）と（前記第３のルールは、「もし通信要求から検出される事実発信者ＩＤが条件部の前記発信者ＩＤと一致し、且つ、前記受信時刻から所定の時間を経過していないとすれば、前記待遇に基づいて前記通信要求を処置する」という事柄を表している）、を含み、前記電子秘書は、さらに、以下の操作が可能であり、（ａ）前記第３のルールを作成し、前記第３ルールセットに加える、（ｂ）前記第３ルールセットを適用する；通信を中止することは、（ａ）まず前記第３ルールセットを適用し、適用条件が成立しているルールが見つからない場合には、事実発信者ＩＤと受信時刻と受信拒否待遇を基にして、前記第３のルールを作成し、前記第３ルールセットに加えて、前記電子メールの送信クライアントに一時的なエラー状態を返してから、根底にある配送系コネクションを閉じることにより通信を強制中止することと、（ｂ）前記適用条件が成立しているルールが見つかった場合には、前記電子メールの送信クライアントに永続的なエラー発生を通告してから通信を正式に中止してから、該当ルールを前記第３ルールセットから削除する。
【００２５】
早期決定とは、メール本体の受信が終わる前に、メールの受信を拒否することを決定し実行することを意味する。本発明はメールの件名内容を判断することによりメール本体の受信を拒否することを決定できる。説明する前に、電子メールの従来技術を説明する。電子メールのＳＭＴＰ準拠は階層化されるプロトコールの上部の層に位置する。通常はＳＭＴＰの根底にある配送系プロトコールはＴＣＰである。電子メール通信においてＴＣＰ接続は欠かせない。ＳＭＴＰは電子メール本体の送信前に電子メールの一部（エンベロープ）を送信して電子メール本体（コンテント）の送信許可を行うステップを備えている。送り手はメールのエンベロープを送った後、コンテントを送る前に、認可されているかチェックするステップはあるが、しかし、一旦メールのコンテントの送信が始まると、ボディを送る前に、認可されているかチェックするステップは無い（RFC2821参照）。コンテントが一つの塊として転送され、途中で転送を中止する事はできないとＳＭＴＰプロトコールで決めている。
【００２６】
エンベロープには送受信者のＩＤ（アドレス）しか含まれない、個々の着信者の主観を正確に反映して送信許可を行う事ができる情報がない。従来の迷惑メール防止技術は、エンベロープから送信許可を判断できない場合、仕方なくコンテントを受信する。そのため、迷惑メールと判断された時点で既に受信が完了し、メール爆弾（短時間に大量送信する行為）の攻撃、公衆網の圧迫あるいは他加入者への悪影響を回避することができない。  ＳＭＴＰはコマンドの発行と応答による会話を通してメールの送受信を遂行する。通常の場合、送り手が常に受け手の応答をチェックし、応答の種類により送り手の動作を決める。受け手がコンテントの受信中、不可抗力によって中断される場合、受け手が応答できない場合でも、所定の遅延間隔で自動的に送信を再試行する。
【００２７】
本発明はコンテントに含まれるヘッダを受信したら、ヘッダから発信者に提示した案内情報に従う質問の正解が検出されない場合に一応迷惑メールであると判断されれば、コンテント転送を中止するＳＭＴＰのコマンドはないが、ＴＣＰプロトコールのソケット切断コマンド（close）によって通信を強制中止する事によるコンテントの転送を強制的に中断する。しかし、この場合、ＳＭＴＰに準拠した送り手は一定時間後再試行手順を開始する。このままではこのメール本体の送信を拒否できない。この望まない再試行を対応するために、まず一つの方法として失敗応答を送り手へ返してから、通信を強制中止する。
【００２８】
インターネットは共通のプロトコールに従う共同体であり、プロトコールに従って製品を作る事を実装という。多くのメーカによる実装される異なるメール送受信製品（例えば、UNIX（登録商標） SendMail、qmail、Microsoft Outlook）が存在する。この実施例に、電子秘書は着信側で動作し、前記製品からメールを受信する。本発明は失敗応答による送り手に送信を断念させる。しかし、ＳＭＴＰがコンテント転送の中断を正常ケースと考えていない。ＴＣＰの切断コマンドを発行する事はＳＭＴＰの標準手法ではないため、強制中断された時、送り手が受け手の応答を受けるか否か、受けた応答を如何に処理するかは、実装によって異なる可能性がある。
失敗応答を無視して、送信を断念しないで再試行する実装による再試行に対応するために、失敗応答を送る事以外、さらに、強制中止する前に、次に説明する中止用第３ルールセットに、送信者ＩＤと一回目の時刻を記憶し、再試行で送信されるメールのエンベロープを受信後、受信したエンベロープに含まれる送信者ＩＤが記憶した送信者ＩＤと一致すれば、ＳＭＴＰの標準手法によってコンテントの送信を拒否する。
【００２９】
以上のように、判明された迷惑メールに対して、転送実装が失敗応答を無視して再試行をする実装の場合でも、再試行送信時に、ヘッダの受信前で中止させる事ができる。失敗応答に従って再試行をしない実装は、本発明に都合の良い送り手であり、使っていない送信者ＩＤと時刻を記憶した古い第３のルールを単純な仕組みで削除できる。送り手の実装がどちらの場合でも、迷惑メールのボディを受信しないで拒否できる。  本発明の電子秘書をメールサーバqmail側に組み込み、送信クライアントとしてOutlookを用いて試験を行った。メールのボディを受信しないで強制終了した場合、Outlookが即時に送信端末で失敗を報告する。Outlookは失敗応答に従って再試行をしない実装である。
図３０、３１に示す実施形態は従来のＳＭＴＰの拡張機能として提案する。この機能を実装した送り手と前記発明を同時に利用する場合、受け手の電子秘書は前記再試行を対応する必要がなく、ＳＭＴＰと別の層に位置するＴＣＰ層のコマンドによる強制中止手段を頼る必要なく、迷惑電子メールに対して公衆網の通信量削減と接続メールサーバの処理がさらに軽減できる。
【００３０】
次は図を用いて、具体的に中止用第３ルールセットによる処理の流れを詳細に説明する。早期決定処理は第１ルールセットを適用するステップ（図１０（１００４））の適用条件が成立しているルールが見つからない時点から始まる。次の中止用第３ルールセットの適用手順で中止用第３ルールセットを適用する。即ち、発信者ＩＤ（メールアドレス）が一致することかつ、受信時刻から検索時刻まで所定の時間を経過していないことの条件に基づいてＲ３ＤＢを検索し（１１０１）、結果を判断し（１１０２）、当該レコードが検出された、即ち適用条件が成立しているルールを見つけた場合、待遇ＩＤのフィールドから待遇を抽出できる。そして、ルールの実行部を実行する（１１１０）。適用条件が成立しているルールが見つからない場合には、メールの件名が含まれるヘッダまで受信し（１１０３）、第２ルールセット適用手順で第２ルールセットを適用し（１１０４、１１０５、１１１２）、初期待遇を処理する（１１０６）。ただし、第２ルールセット実行部の待遇及び初期待遇の中に、受信拒否を含む場合（判定：１１０７）は、事実発信者ＩＤと受信時刻と受信拒否待遇を基にして、第３のルールを作成し、中止用第３ルールセットに加えて（１１０８）、待遇に基づいて通信要求を処置し、受信拒否待遇は失敗応答を送信クライアントへ返してから、通信を強制中止する（close）（１１０９）、そうでない場合は与えた待遇に基づいて通信要求を処置する（１１１２）。第３のルールの実行目的は従来技術のＳＭＴＰ準拠の送り手を従来技術の正式中止できるステップ：ヘッダの受信前で中止させることである。一回実行すれば良いので、第３のルールの実行部が実行されたら、該当ルールを削除する（１１１１）。
【００３１】
「再試行の間隔は少なくとも30分であるべきである、しかし…、可変の戦略は有益である」（RFC2821）。サーバ管理の当業者が分かるように、再試行の間隔を含む各種タイミングのカスタマイズが普通に行っている。第３のルールに所定の時間が再試行の間隔より長く設定すれば、確実に再実行送信を捉え（１１０２のＹＥＳ）、送り手を断念させ、望まない繰り返しの再実行を阻止できる。
別の観点から見ると、ステップ（１１０８）が受信拒否履歴を記録する。以下、受信が拒否された発信者のメールアドレスと、前記メールアドレスの受信時刻の対を記録する記録リストが「拒否履歴リスト」という。拒否履歴リストは第３ルールセットの部分セットに属する第３のルールの発信者ＩＤと受信時刻により構成されるリストであり、前記部分セットは受信拒否待遇を有する第３のルールのセットである。
【００３２】
所定の時間以内で再送信されたメールを検出して拒否する事が、第３ルールセットを適用する事によって実現できる。
更に、第３のルールに再送信回数を記録し、何回目の再送信が検出されたら、再送信を拒否する様にしても良い。第３ルールセットは再送信検出及び再送信拒否する仕組みである。
前記ステップ１１０９の失敗応答は、一時的な又は永続的なエラー状態どちらでも送信クライアントへ返しても良い。強制中断された時、一時的なエラーを対応する送り手の実装は、再送信するので、ステップ１１１１が、ステップ１１０８で作成した第３のルール、即ち拒否履歴をクリアする。再送信しないの送り手の実装から受信する場合、古い拒否履歴をクリアする事が当業者の技術常識である。
ＳＭＴＰコマンドへの応答形式はコードと、それに続きテキストの文字列である。案内情報は応答のテキストの文字列として送信者に送られ、リアルタイムに案内情報を発信者に提示する事ができる。応答のテキストの文字列を表示しない実装にも対応できるため、案内情報を発信者にメールで返信しても良い。
【００３３】
ヘッダの替わりにコンテントの一部、又は全部を受信してから質問の正解、又は、期待するキーワードが検出されない又は検出された場合が迷惑メールであると判断しても良い。
図１２は、本発明の別の実施形態のフローチャートである。発信者に提示する提示情報は通信の許可を申請させる、前記提示情報は、少なくともメールに申請内容を記載するように促す内容を含み、電子秘書が受信サーバ側に設置され、通信要求を拒否することは、前記メールの送信クライアントにエラー発生を通告してから通信を中止することであり、そして、前記電子秘書は前記通信要求が着信する時、先ず事実発信者ＩＤが含まれた前記メールのエンベロープ（封筒）まで受信して、第１ルールセットを適用し、適用条件が成立しているルールが見つからない場合には、前記メールのコンテントを受信して、申請受理を行う。エンベロープ（封筒）まで受信して（１２０１）、発信者のメールアドレスを検出し、指示ファイルを読み（１２０２）、前記第１ルールセットを適用する（１２０３，１２０４，１２０９）。第１ルールセットから適用条件が成立しているルールが見つからない場合、コンテントを受信し（１２０５）、そして、前記第２ルールセット適用手順で第２ルールセットを適用する（１２０６，１２０７，１２０９）。提示情報を返信して拒否する事などを含む初期待遇を処理する（１２０８）。
【００３４】
図１３は、本発明の別の実施形態のフローチャートである。第２ルールセットを適用する時、適用条件が成立している第２のルールを見つけた場合、見つけた前記第２のルールの実行部の待遇を発信者に与える。ＩＤ検出し（１３０１）、指示ファイルを読み（１３０２）、第１ルールセットを適用し（１３０３）、結果を判断し（１３０４）、第２ルールセットを適用し（１３０５）、結果を判断し（１３０６）、初期待遇を処理する（１３０７）。図５に示す実施例との違いは、適用条件が成立している第２のルールを見つけた場合、さらに、保存条件を判定し（１３１０）、条件が満足される場合、電子秘書は見つけた前記第２のルールの実行部の待遇を発信者に与えることである。即ち、前記発信者のＩＤと前記待遇を基にして、第１のルールを作成し、第１ルールセットに加え（１３０９）、待遇に基づいて通信要求を処置する（１３０８）。通常は、見つけた前記第２のルールの実行部の待遇は申請受理でないことが保存条件の一つとする。保存条件が支配者により指定又は変更することが可能である。
【００３５】
この処理を自動審査という。着信者指定の質問を正確に答えた等の場合、この方法利用すれば、受信者に対して一回でも連絡した関係者が全て第１ルールに自動的に記憶され、二度目に同じ質問はされない。申請受理待遇は通常特定の相手に与えない。通信許可待遇を与えた相手にその待遇を降格し、申請受理待遇を与える場合、その相手と通信したこと等の記録として役に立つ。
好ましくは、待遇セットに「常時通信許可」と「臨時通信許可」待遇を設ける。「常時通信許可」は、通信要求を着信者に伝達し、かつ、通信許可待遇を発信者に与える事を意味し、「臨時通信許可」は、通信要求を着信者に伝達するが、通信許可待遇を発信者に与えない（今回に限り受信する）事を意味する。
【００３６】
ステップ１３０７は初期待遇に基づき処置する。この例の初期待遇は、提示情報を前記発信者に提示してから受信を拒否することである。発信者不明の場合、発信者に通信の許可を申請させるために、提示情報を提示することが必要である。申請受理のやりとりで、提示情報を提示しなかった場合、このステップで提示可能である。支配者の意思により提示しないことも可能である。
図１４は、図５の説明に記載の本発明において、別の実施形態のフローチャートである。前記指示ファイルは、さらに、第３ルールセットを含み、前記電子秘書は、さらに、以下の操作が可能であることを特徴とする方法。（ａ）前記第３のルールを作成し、前記第３ルールセットに加える、（ｂ）前記第３のルールのセットを適用する。
【００３７】
この部分の処理は図５に示す実施例の初期待遇の処理ブロック（図５（５０７））に含まれる。即ち第１及び第２のルールにより待遇を決めない場合、攻撃防止用第３ルールセット適用手順で攻撃防止用第３ルールセットを適用する（１４０１、１４０２，１４０５）。適用条件が成立しているルールが見つかった場合には、ルールの実行部を実行したら、該当ルールを前記攻撃防止用第３ルールセットから削除し（１４０６）、発信者ＩＤと所定の待遇を基にして、第１のルールを作成し、第１ルールセットに加える（１４０７）。適用条件が成立しているルールが見つからない場合には、発信者ＩＤと受信時刻と所定の待遇を基にして、第３のルールを作成し、攻撃防止用第３ルールセットに加える（１４０３）。電子秘書が元の初期待遇を実行する（１４０４）。
【００３８】
本発明が電話及びメール通信に利用できる。初期待遇が申請受理に設定すると、電子秘書は発信者不明の場合、発信者に自動返信し、発信者の身元を確認する事ができる。しかし、現在大部分の迷惑メールの返信先アドレスが偽造されている。自動返信のメール自体が新たな迷惑メールになってしまう可能性がある。本発明の電子秘書は前記返信先アドレスから二度目のメールを受信したら、所定の身元を確認できる情報が含まれない場合には、支配者が前記所定の待遇を、例えば無視して受信拒否と指定すると、該当アドレスを無視して受信拒否待遇を与え、それから自動返信なしに受信を拒否し、なりすまされたアドレスに被害を最小限にとどめることができる。
悪質な迷惑メールが送信毎に返信先を変える場合、受信拒否待遇を有する第１のルール（ブラックリスト）の数が膨大になる可能性がある。ブラックリストが無制限に増える事を防ぐため、第３のルールと同様の手法を用いて、第１ルールに作成時刻を記録して、古い受信拒否待遇を有する第１ルールを自動的に削除する。
【００３９】
好ましくは、待遇セットに「常時受信拒否」と「臨時受信拒否」待遇を設ける。「常時受信拒否」は、利用者が手動で削除しない限り指定された発信者の通信要求を拒否する事を意味し、「臨時受信拒否」は、古くなった又は所定の数を超えた時、電子秘書が当該第１ルールを自動的に削除する。
本発明の思想は所定の時間以内で、有限回数の申し込み機会を相手に与え、機械などによる繰り返し申し込み、メール爆弾を対応する。第３のルールに再送信された回数を記録し、回数を実行条件に入れ、又は有限回数の申し込み待遇を与えることにより実現する。
図１５は、本発明の別の実施形態の構成を示す図である。電子秘書及び指示ファイルＲ１ＤＢ，ＧＤＢ，Ｒ２ＤＢが端末１５０１に組み込んでいる。リアルタイム相互作用を通して通信する手段を備える。制御権を持つ端末１５０２は、着信者の介入なしで着信端末１５０１と通信でき、制御コマンド１５１０を端末１５０１に送れる。通信許可待遇を与えた端末１５０３は、端末１５０１と通常の双方向通話１５２０が行える。
【００４０】
図１６は、本発明の別の実施形態のフローチャートである。通信は同時通信であり、提示情報は前記通信を受ける条件の説明を含み、そして、通信要求が着信する時、電子秘書が、先ず第１ルールセットを適用し、適用条件が成立しているルールが見つからない場合には、申請受理を行い、前記申請受理を行うステップには、前記提示情報を発信者に提示して、前記発信者の反応を受け取って、第２ルールセットを適用し、適用条件が成立しているルールも見つからない、即ち待遇が決められない場合には、初期待遇に基づき、前記通信要求を処置する。
ＩＤ検出し（１６０１）、指示ファイルを読み（１６０２）、第１ルールセットの適用し結果を判断し（１６０３、１６０４）、条件が成立しているルールが見つからない場合には、提示情報を発信者に提示してから、前記発信者の反応を受け取り（１６０５）、第２ルールセットを適用し結果を判断し（１６０６、１６０７）、結果によって初期待遇又は与えた待遇に基づいて通信要求を処置する（１６０８、１６０９）。
【００４１】
制御許可は、傍聴許可、監視許可、位置取得許可、注意喚起許可、情報転送許可等が含まれる。
図１７は、本発明の別の実施形態のフローチャートである。提示情報は、発信者に提示する質問を含み、期待する申請内容は、所定の合計の得点を得た前記質問の回答であり、指示ファイルは、前記発信者に提示する前記質問と、前記質問の正解に関する適用条件を有する条件部と、得点に関する行動の実行部とを有するルールで記述された第４のルールのセット（以下「第４ルールセット」という）（前記第４のルールは、「もし前記発信者から前記質問の回答が正解であるならば、前記得点を計上し、合計の得点を集計する」という事柄を表している）を含み、前記電子秘書は、さらに以下の操作が可能であることを特徴とする方法。（ａ）前記質問を前記発信者に提示する、（ｂ）前記質問への前記発信者の回答を受け取る、（ｃ）前記第４のルールのセットを適用する。
【００４２】
この部分の処理は繰り返し案内メッセージの提示と反応の受け取り及び反応の正確さの判断手順を例示する。図１６の「提示情報を前記発信者に提示して、前記発信者の反応を受け取る」の処理ブロック（図１６（１６０５））に相当する。Ｒ４ＤＢからルールのデータ・レコードの処理完了判断し（１７０１）、抽出し（１７０２）、質問を発信者に提示して、前記発信者の回答を受け取る（１７０４）。一つの質問は複数の正解を存在することがある。例えば、識別番号を確認する場合、複数の識別番号が存在する。この実施例は、複数の正解を確認する（１７０５）ための仕組みは、同じ質問をしなくて、前回の質問時受け取った回答を次の正解であるかどうかを照合する。Ｒ４ＤＢに質問の提示不要標識を追加すること、または、質問フィールドを空欄にすることにより判断する（１７０３）。全ての質問を提示することが必要でないケースがある。例えば、相手の身元が最初の質問により判断できるケースがある。この実施例は、合計の得点（１７０６）が所定の点数を超える場合は問答を早期終了する仕組みを持つ（１７０７）。この部分の処理を実施するシステムは、提示情報の種類に応じて、発信者の反応を受け取る手段を備える。例えば、電話のダイヤル番号を押すことにより回答を得る場合、押された番号を認識する手段を備える。
【００４３】
例えば、ダイヤル番号を認識する手段及び音声合成手段及び音声認識手段の具体実現がNTT DATA CORPORATION販売している製品「マルチメディアカード VS-406MC」を利用できる。画像認識手段の具体化例がNHK (Japan Broadcasting Corporation)の顔画像認識技術による映像編集支援システムを挙げられる。
電話の場合、発信者の識別は発信電話番号により行う。この発明は支配者が発行する識別番号またはパスワードにより発信者を識別することが可能である。識別番号を使い、不特定の発信端末から通信が可能である。
図１８は，本発明別の実施形態の構成を示す図である。電子秘書及び指示ファイルは通信サービス提供サーバ１８０１側に組み込む。端末支配者別に指示ファイルを有し、複数の端末支配者が利用可能である。利用権が有る端末支配者は任意の端末１８０３または電話機から自分の指示ファイルを構築するためにデータを入力する（１８２０）。発信者端末１８０２の通信要求または制御コマンドが電子秘書サーバ経由で送られる（１８１０）。
【００４４】
図１９は、本発明別の実施形態の構成を示す図である。電子秘書はネットワークを通して指示ファイルにアクセスする（１９３０）手段を有し、一人の支配者は複数の電子秘書（１９０１、１９０４）を利用する。前記複数の電子秘書は一つの指示ファイル１０３にアクセスする。符号１９４０はサーバ１９０４経由のメールを示す。電子秘書が作成する第５ルールセット（図６９、Ｒ５ＤＢ）も指示ファイル１０３に保存する（図１９に示せず）。
図２０は本発明別の実施形態のフローチャートである。指示ファイルは、着信者ＩＤと発信時刻に関する適用条件を有する条件部と、待遇に対応させた行動の実施を指示する実行部とを有するルールで記述された第５のルールのセット（以下「第５ルールセット」という）と（前記第５のルールは、「もし宛先ＩＤ（着信者のＩＤ）が条件部の前記着信者ＩＤと一致し、且つ、前記発信時刻から所定の時間を経過していないとすれば、前記待遇に基づいて前記発信要求を処置する」という事柄を表している）、を含み、電子秘書は、さらに、以下の操作が可能であることを特徴とする方法。（ａ）前記第５ルールセットを適用する、（ｂ）通信要求を着信者に送り、待遇を受け取る、（ｃ）前記第５のルールを作成し、前記第５ルールセットに加える。
【００４５】
宛先の着信者ＩＤ、発信時刻、待遇に関する第５ルールセット内の全てのルールを対象として、適用条件が成立しているルールを見つけ出し、結果を判断し（２００１、２００２）、適用条件が成立しているルールが見つかった場合、与えられた待遇に基づいて発信要求を処置する（２００４）。前記ルールが見つからない場合、通信要求を着信者に送り、待遇を受け取る（２００３）。着信の相手は本発明の電子秘書の場合、所定の返却コードにより受けた待遇を判別し通信する（２００５、２００６）。着信の相手が従来技術を用いている場合、例えば、従来のメール受信サーバである場合は、永続のエラーコードが受信されたら、受信拒否とみなすことが望ましい。受けた待遇が「直ちに通信できない」待遇の場合、着信者ＩＤ、発信時刻、と待遇を基にして、第５のルールを作成し、第５ルールセットに加える（２００７）。この発明の主な目的は迷惑通信を発生源において阻止することである。好ましくは図１８、１９の様にサーバで運用する。支配者がＲ５ＤＢにデータを入力しない。相手に与えられた待遇が受信拒否である場合、所定の時間内に繰り返しの発信は阻止される。サーバの管理者により前記の所定の時間を設定することが望ましい。例えば、「一時間以後再度掛けてください」等の待遇が与えられれば、送信サーバ側で実施可能である。Ｒ５ＤＢをクリアしない場合、無差別に大量迷惑通信の発信者のＲ５ＤＢレコード数が大きくなる。サーバの管理者がＲ５ＤＢレコード数によって、当該発信者の送信効率を下げるか、警告するなどの管理が可能である。
【００４６】
別の観点から見ると、第５のルールセットは、支配者が管理する通信装置から発信する場合、受信が拒否された受信拒否履歴を記憶し、拒否履歴が新しい時再び同じ着信者へ発信しない仕組みである。
図２１は本発明別の実施形態の構成を示す図である。この形態は、２つ以上の当事者の間で匿名の通信に関する。匿名通信の必要性、通信当事者双方の情報開示、情報検索、情報マッチ等従来技術が特許文献１０に開示されている。この実施形態の課題が簡単に手軽な匿名通信の実現することである。
第１又は２の当事者が共に電子秘書を用いて通信し、各自の指示ファイルがある（図２１に示せず）。最初に何にも関係の無い当事者は通信ができない。通信の必要がある当事者が先ず電子秘書を通してサーバ２１０３と通信関係を築き、希望する通信相手の条件をサーバに登録し、サーバが登録した情報を検索し、双方の条件をマッチした場合、サーバが与えられた制御許可待遇を用いて、当該する当事者の電子秘書と通信し、指示ファイルを書き換える事によって、当事者双方の間に希望通りの通信関係を築く事がこの実施形態の要旨である。
【００４７】
図７１は当事者データに関する一実施例の当事者データ・データベース
（以下ＰＤＤＢという）の内容を示すレコードのレイアウト図である。図７２は確認要請を記録するデータに関する一実施例の確認データ・データベース（以下ＶＤＢという）の内容を示すレコードのレイアウト図である。図７３は立証者情報を記録するデータに関する一実施例の立証者データ・データベース（以下ＶＲＤＢという）の内容を示すレコードのレイアウト図である。
図２２は、図２１に示す実施例の第１の当事者の処理の部分フローチャートである。図２３は、図２１に示す実施例の第２の当事者の処理の部分フローチャートである。図２４は、図２１に示す実施例のサーバの検索、データの送り、待遇交換処理部分のフローチャートである。本発明は二人以上の複数の当事者同時に利用可能である。以下の記述は、第１の当事者がデータ開示相手に与える待遇をＰＤＤＢに入力し、サーバに代行許可待遇を与え（２２０２）、第２の当事者が検索要求を前記サーバに送信する（２３０２）こととする。ＰＤＤＢの他、当事者データに関するもう一つの一実施例は実施例３参照。
【００４８】
当事者２１０１、２１０２が第１、第２のデータと、前記データを開示するための少なくとも１つの当事者ルールと、サーバ２１０３に入力し、前記サーバに通信許可待遇を与える（２１１０，２１１１、２２０１、２３０１）。サーバが当事者データ、当事者ルールを受信し、ＰＤＤＢに保存する（２４０１）。当事者ルールは、情報を開示して、開示しない候補者のプロフィール、情報を開示する前に確認が必要かどうか、また、どんな情報がどんな候補者に開示されるかの情報を含み、ＰＤＤＢの開示認可プロフィールに保存する。第２当事者が検索基準を含んでいる検索要求を送信（２１１２、２３０２）し、サーバがそれを受信し、ＰＤＤＢを検索する（２４０２）。前記基準を満たす記録の数等の検索結果を第２当事者に送る（２３０３、２４０３）。第１のデータが検索基準を満たすかどうかを決定し（２４０４）、前記検索基準を満たす第１のデータがあった場合、第１当事者ルールを満たすかどうかを決定し（２４０５）、満たした場合、第１のデータを第２の当事者に送る（２１１３、２３０３、２４０６）。第１の当事者がサーバに代行許可待遇を与え、第１のデータを開示する対象となる第２の当事者に与える待遇をＰＤＤＢに入力した場合、サーバが第１の当事者の操作を代行して、第２の当事者に、前記第１のデータに含まれた開示する対象に与える待遇を前記第２の当事者を与える（２１１３、２４０７）。第２当事者ルールを満たすかを判断し（２４０８）、満たした場合、第２の当事者の第２のデータを前記第１の当事者に送る（２１１４、２２０３、２４０９）。
【００４９】
ステップ２４０７と同様に、もし開示する対象に与える待遇が前記第２のデータに含まれ、且つ、第２の当事者がサーバに代行許可待遇を与えた場合、ステップ２４０９では、サーバが第２の当事者の操作を代行して、第１の当事者に、前記待遇を与える。これを、双方互いに待遇を交換するという。
通常言葉の待遇の概念は授受関係である。本発明の用語待遇も授受関係であるが、前記待遇交換とは必ずしも同時に交換ではない。本発明は片方だけが受信許可を与え、もう片方だけが通信を発信することができる。
当事者ルールに、情報を開示する前に、本人の確認が必要条件として含めることが可能である。当事者ルールに、当事者に関する情報が確認されたことを条件として指定することが可能である。
当事者に関する情報の確認をサーバに依頼することが可能である。確認に関する情報を確認データベースＶＤＢに保存し、立証者情報を立証者データ・データベースＶＲＤＢに保存する。
【００５０】
当事者の指示ファイルがネットワーク中のサーバに保存する場合、アクセス許可情報（ＩＤ、パスワード）に基づき、サーバにログインして、指示ファイルにデータを入力する。代行許可の実施は依頼者から入力されたアクセス許可情報に基づき、指示ファイルに入力する。
指示ファイルがローカルに保存される場合、代行許可の実施はサーバに情報転送許可待遇を与え、ローカルの指示ファイルに入力することにより実現する。  サーバが検索要求を処理し、第１のデータが検索基準を満たすかどうかを決定する処理、及び、第１（第２）のデータを開示する第１（第２）当事者ルールを満たすかどうかを決定する処理の実施は、特許文献１０による公知である。キーワード、ファジー論理と自然言語検索ツールを含め、使うことができる多くの検索テクニックがある。
【００５１】
本発明によると、着信者が通信成否のかぎを握るため、電話番号等当事者ＩＤとアイデンティティのつながりを切断できる。個人の電話や、メールが容易に信頼できる範囲の相手としか接続しない。公衆網における専用網のような効果が得られる。本発明は相手に知られた、使っていた公衆網通信ＩＤでも、後から相手の通信を拒否できるため、自らアイデンティティを公表しない限り、匿名性が保ちながら、通常の番号を使って、簡単に、全ての通信機能が使える匿名通信を実現できる。たとえば、本発明はアイデンティティを通信内容から取り除く専用の中央コントローラを介在させる必要がない。特別な通信チャンネルを作る必要もない。
本発明は簡単に匿名通信や手軽なデータ交換を実現することである。専用の中央コントローラを介在し、また、当事者の間データ交換のために２つのステップを要求する匿名通信の技術がある（特許文献１０参照）。
【００５２】
通信サービスの提供者は、ＩＤを前記通信サービスの利用する当事者に提供し、前記通信サービスの提供者及び第三者からなる群から選択されるものが前記当事者の身元確認情報を登録する方法を利用して、当事者の身元確認情報がサーバに保存される。サーバを管理する通信サービス提供者又はそれと連携するセキュリティサービス業者などの第三者は法定の情報保護義務が有る。サービス利用者の違法行為による被害の場合は法的手段による相手の身元調査が可能であるので、安心に通信できる。
電話の加入者身元登録手段が当事者の身元確認情報登録手段の実施例である。ＩＤを発行する通信サービスの提供者と連携してセキュリティサービス業者など第三者による身元確認情報を登録することが可能である。
【００５３】
相手の待遇を受信拒否に設定し直せば、通信関係を断ち切れる。必要な場合、追加ＩＤを使い、通常使用の電話番号と別に、匿名通信専用の電話番号を新規契約する。例えば東日本電信電話株式会社(NIPPON TELEGRAPH AND TELEPHONE EAST CORPORATION)は本来の契約者回線番号の他に追加番号サービスを利用でき、追加番号を発信者番号として利用もできる。メールの場合新規アドレスを追加ＩＤとして使える。匿名通信の必要が無くなったら、待遇を受信拒否に設定することが負担と感じる場合、追加ＩＤの契約を廃止すれば良い。
本発明別の実施形態は、当事者が自分のＩＤ(識別子）を含む情報を開示して、発信者に通信の許可を申請させ、前記申請はインターネットを通して行うことを含み、前記発信者が前記通信要求を出す前に、前記当事者に対して通信の許可を申請するステップと、通信サービスを利用する当事者をＩＤにより特定し、前記通信サービスの提供者は、ＩＤを前記通信サービスの利用する当事者に提供し、前記通信サービスの提供者及び第三者からなる群から選択されるものが前記当事者の身元確認情報を登録する。
【００５４】
図２７は本発明別の実施形態の構成を示す図である。図示した手段は必要時に備え、同時に全てを備える意味ではない。移動通信装置（以下、「移動機」という）２７０１の支配者は端末Ａ２７０２の発信者に制御許可待遇の一つである位置取得許可待遇を与えた。端末Ａから位置情報取得コマンド２７１１を発行し、移動機はそのコマンドに従って、設置される位置取得手段により位置情報を取得し、取得した位置情報を端末Ａに転送する（２７１２）。すると、端末Ａが必要な時だけ、移動機から移動情報を取得できる。
前記位置情報は、受信したＧＰＳ（GlobalPositioning System）位置信号、受信したＧＰＳ位置信号から変換された位置情報、ＰＨＳ（Personal handy phone）端末の現在位置情報、及び携帯電話基地局位置情報に基づいて提供された移動端末位置情報からなる群から選択されるもの（以下「具体位置」という）を含む。具体位置は、ＧＰＳ衛星２７０４から受信したＧＰＳ位置信号、受信したＧＰＳ位置信号から変換された位置情報、ＰＨＳ端末の基地局２７０５位置情報に基づいて提供された現在位置情報、及び携帯電話基地局２７０６位置情報に基づいて提供された移動端末位置情報等、移動機の位置を一定の精度で確定できる情報を含む。
【００５５】
移動機は、予め登録されたＩＤを有する端末に通信要求を出す場合には、前記位置情報を検知して前記端末に転送する。例えば、交通情報、地図及び施設データなどのデータベースおよび経路計算機能センター（以下「交通管理センター」という）を設置し、移動機が移動機に予め登録されている交通管理センターの端末ＩＤを有する端末Ａに通信要求を出すとき、前記位置情報を検知して端末Ａに転送する（２７１４）。
参加を希望するグループの種類など目的情報を端末Ａに転送し、端末Ａに、さらに、（ａ）情報転送許可と、（ｂ）注意喚起許可と、の待遇を与え、端末Ａは移動機に前記グループの他のメンバーの情報を転送し、移動機の液晶ディスプレーに情報を出力させ、前記注意を喚起させることは、音声、光、及び振動からなる群から選択されるものを含み、移動機のバイブレーターを振動させて、移動機を所持する人間の注意を喚起させる（２７１５）。例えば、近くにある移動中車両、登山者、等の相互位置通告希望グループが形成できる。
前記目的情報は到着目的地情報を含む場合、例えば、前記目的情報は到着目的地緯度、経度情報を含み、経路誘導サービスを求め、センターが前記移動機に地図情報、推薦ルート、現在ルート、前方渋滞情報、及び迂回路情報、前方路面凍結、気象警報注意報などを転送する。制御待遇が与えられた情報提供側は、前方渋滞が発生する等必要な情報が発生するとき、着信者の手動介入なしに情報を提供できる。一方、移動機普通の通信機能は支障なく、制御待遇なしの端末Ｂ２７０３と移動機は通常の双方向通話を行う（２７１３）。
【００５６】
図２８は動的に経路誘導に関する本発明別の実施形態のフローチャートである（図２７参照）。この例は位置情報取得機能を有する移動端末、例えばGPS搭載の携帯に、効率的に車両用走行誘導機能を提供することを目的とするものである。予め登録されたＩＤを有する固定機のサーバに通信要求を出す場合には、移動機の現在地、目的地情報をサーバに送信し、サーバがそれを受信する（２８０１）。サーバが推薦経路を検索し、移動機に送信してから（２８０２）、所定の間隔で推薦経路の渋滞情報を検索し（２８０３）、渋滞が発生するかを判断し（２８０４）、発生する場合、位置取得許可待遇が与えられたサーバが移動機の現在位置を取得し、進行経路を確認して（２８０５）、進行経路の前に渋滞が発生する場合、迂回路を検索し（２８０６，２８０７）、迂回路存在する場合、情報転送許可と、注意喚起許可待遇を与えられたサーバが、迂回路情報を移動機に転送してから、音声で運転手に知らせる（２８０８）。
車両走行誘導ため、正確な交通情報が必要である。経路探索は多くの計算量と計算速度が必要である。移動機が動的な道路交通情報を検索することは非効率でありコストがかかる。本発明は安価な携帯式移動端末が行うことができない操作をサーバに任せて、巻き込まれる可能性の有る渋滞が発生する時だけ移動機に通信し、迂回路情報を知らせる。サーバに制御許可待遇を与えることにより、着信側運転手が自ら行う操作は必要でない。経路探索、迂回路検索は、特許文献７、８等により公知である。
【００５７】
図２９は位置情報等に関する本発明別の形態の概念図である。移動機２７０１が、位置変化を検知した場合に、前記変化した位置情報を予め登録されたＩＤを有する端末Ａ２７０２に転送する（２９１１）。端末Ａは移動機に情報転送許可、注意喚起許可の待遇を与える。制御許可が傍聴許可と監視許可を含む。移動機の支配者は端末Ａに傍聴許可、監視許可待遇を与えたとする。端末Ａから通信要求、傍聴コマンド、または監視コマンドを発行する（２９２１）。移動機はそのコマンドに従って、設置される送話器により取得する音声信号、または撮像装置により取得する画像信号、を端末Ａに送る（２９２２）。この例は、子供を監護するための移動機に使える。例えば、親は子供の居場所を調べ、子供の公園遊びや、通学など活動環境を傍聴できる。子供が放課時、移動中などに変化した位置情報を親の端末Ａに自動的に転送する。移動機は望ましくＰＨＳを使い、情報の転送はパケット通信であるメールにより行う。端末Ａは望ましくＡＤＳＬ回線などでインターネットに常時接続するパソコンを使い、移動機を携帯する子供の居場所を地図上に実時間表示する。車の防犯にも使える。移動機は車両内部に置かれ、予定外の移動があれば所有者に警告を送り、追跡するように設定する。タクシーや運送業務など高い位置精度が必要な場合は、ＧＰＳ位置取得装置を用いることが望ましい。
【００５８】
地図データに移動機の位置情報を付加して画像に表示する画像表示部が特許文献９により公知である。
本発明の課題の一部の通信機能と関連性がある特許文献１４に示す従来技術は、移動局の電子メールのホワイトリストに載っていない送信元にはメール拒否を通知する際に、上記リストに登録されるための条件に関する登録方法情報を送信元へ送信する迷惑メール通信を防止する技術を開示した。本発明の目的は通信装置の迷惑通信防止だけではなく、本発明は、迷惑通信防止機能と、その反対方向の制御機能を一体に扱える通信機能付き電子装置と、この電子装置の動作方法を提供する。
ＧＰＳ携帯に関する特許文献９に示す従来技術は、本発明課題の通信及び制御の一体化と関連性がある。図２７、２９に示す発明は前記従来技術と同じ課題を解決できる。
【００５９】
前記従来技術は、センターの発信時の、移動機の端末番号の選択により「位置取得」と「位置取得後通話」の選択が可能となる手段を用いて、移動機の状態を決定する。そのため移動機が二つ回線番号を使わなければならない。つまり、一装置に通信と制御を共存させるために、通信と制御別々に二つのチャネル（２回線）が必要である。なおかつ、固定局が携帯の位置情報を取得するため、通常の通話と別の特定のセンター回線を使わなければならない。小規模の会社や家庭の場合、この固定局ため回線を増やす事は効率が悪い。インターネットから専用のセンターを経由して携帯の位置情報を取得する形で、日本KDDI株式会社がGPS MAPという携帯の位置情報サービスを提供している（http://www.kddi.com/business/solution/mobile/gps/index.html  2004.5.29検索）。この方式はセンターの設備、運用管理が必要であり、携帯電話が本来所有する通常の通話回線からの位置情報を取得できず、一方、センターの位置情報取得専用回線の混雑度は、利用者の増加と共に増加する事は避けられない。
【００６０】
本発明は発信者（固定局）が発信する時、移動機の通信端末回線番号を選択する事による移動機の機能を選択するの替わりに、制御待遇を与えなれた固定局が制御コマンドの発行による移動機を制御する。コマンドの種類数に応じる多様な機能が得られる。例えば、前記従来技術と同じ固定局でＧＰＳ位置情報を演算する。
配車センターを利用する場合、前記従来技術はセンターと運転手が通話する場合、運転安全のために、まず「位置取得」、次に「位置取得後通話」の２回の通信をしなければならない。本発明はまず位置を取得し、移動機が運転中ではない事を確認できたら、注意喚起コマンドを発行して運転手を呼び出して通話できる。１回の通信で通話が可能である。  また、本発明は着信側所有者主導の通信ができる。必要な場合のみ、所有者が選択した相手にのみ通信許可や位置取得許可待遇を与えることができる。例えば、子供所持する携帯の位置が親の電話から直接検索できるように設定できる。前記従来技術では特定のセンター経由でしか位置情報の検索できないため、運用コストと安全性等の点で問題がある。
【００６１】
待遇の思想がなければ、通信と制御双方の既存の及び未来の各種機能、各種場面において柔軟に効率的に細かいニーズに対応することが難いことは明らかである。
本発明は前記従来技術と比べ、同じＧＰＳ携帯位置情報サービスの場面で、機能の明らかな増加と同時に、ハードウェアの減少（電話機内部の電話番号数の半減、外部の使用回線数の半減、情報センターの不要）及び利用者の運用コストの減少をもたらす顕著な効果が得られる。
本発明の根本的な意義は、通信機能を有する電子装置の所有者が待遇の指定により意思通りに前記装置を制御できる事である。従来の技術でこの制御ができないために発生する一つの障害として迷惑通信をあげる事ができる。本発明が待遇種類の取捨選択による拡張性と柔軟性を持つ事は明らかである。
【００６２】
テレビ電話と監視カメラは長い歴史を持っている。ほぼ同じハードウェアを持っているのに、実施例３に説明するような簡単に一体化する製品がない。本発明は実施例３のようにハードウェアを増やさないで新機能を実現できる。
外出先から留守番電話のセットなど、リモートで設定する従来技術がある。本発明の制御許可待遇が被監視側の人に気付かずに監視できる点が該技術と異なる。
図３０は本発明別の実施形態の構成を示す図である。この実施形態はメール通信システムである。送信クライアント３００１の記憶装置１３に保存される電子メール３００３を電子秘書を用いるメール受信サーバ３００２に送信する。電子メール３００３の構成は従来技術のＳＭＴＰ(SimpleMail Transfer Protocol)、RFC2821,2822,2045等に規定されたものである。
【００６３】
図３１は図３０に示すメール送信実施形態の送信方法の実施例のフローチャートである。電子メールは、エンベロープとコンテントによる実体を構成し、前記コンテントはヘッダとボディの２つの部分を持ち、前記エンベロープは伝送や配送をなし遂げるのに必要などんな情報も含んでいて、前記コンテントは受取人へ配達される目的物を含み、前記ヘッダは標準に定められた特殊な構文による文字列のシーケンスであり、前記ボディは前記ヘッダに続く、単なる文字のシーケンスであり、そして、前記電子メールを前記エンベロープ、前記ヘッダ、前記ボディの順番に受信サーバに送信し、前記ボディを送信する認可が前記ヘッダに含まれた情報により判定し、前記ボディを送信する前に、認可されているかチェックするステップを含み、以上によって、前記受信サーバは、受信した前記エンベロープと、前記ボディを受信する前に受信した情報に基づいて、前記ボディの送信を認可するか否かを決定する。
【００６４】
ステップ３１０１においてセッションを初期化し、送信クライアントを初期化する。エンベロープ送信は（３１０２）、ＳＭＴＰ準拠コマンド：MAILコマンド、RCPTコマンドを発行することにより行い、発信者及び受信者メールアドレスを受信サーバに伝え、エンベロープが受け入れられたか否かをチェックする（３１０３）。ここまでの処理はＳＭＴＰと同じである。ボディを送信する認可がヘッダに含まれた情報により判定するため、ヘッダに含まれた情報フィールドを送信し（３１０４）、情報フィールドに着信者が指定の受信条件を判断できる情報を含み、認可されているかをチェックする（３１０５）。本発明はこのステップを「INFOコマンド」という。受信サーバは受信した前記エンベロープと、情報フィールドに基づいて、着信者が指定する受信条件と照合し、次のボディの送信を認可するか否かを決定することができる（図１０、１００７参照）。認可された場合、従来のDATAコマンドを発行しコンテントを送信する（３１０６）。認可され受け入れられた場合、送信の正常処理、記憶装置１３から送信済みメールを削除する（３１０７、３１０９）。認可されない場合エラー処理する（３１０８）。
【００６５】
従来技術ＳＭＴＰはエンベロープを認可した後、コンテントが一つのブロックとして送信し、認可チェックをする。メール転送プロトコールの階層のコマンドだけ利用する場合、コンテント全体の受信が終わらないと、コンテントの受信を拒否することができない。そのためコンテントの内容により受信拒否すべきと判断できでも、すでに無駄な通信が発生してしまう。一方、すでに広範囲に使われたコンテント仕様（RFC2822）に、人がよめる情報の内容を持つ目的をもつ件名(Subject)、注釈(Comments)、キーワード(Keywords)という情報フィールドは、着信者が指定の受信条件を判断できる情報を記載できる。既存のメール通信ソフトでも前記フィールドに情報を記載する手段が備えている。発信者が最初に着信者の受信条件が分からない場合、受信サーバ側が自動返信手段により、着信者の受信条件を発信者に伝える。更に、一回だけその受信条件を満足した発信者のメールアドレスが記録され、２回目以後の送信は、エンベロープに含まれる発信者アドレスから判断して、前回受信条件を満足した発信者であった場合、情報フィールドをチェックしないで、コンテントを通過させる。以上によって、受信サーバは、受信したエンベロープと、前記ボディを受信する前に受信した情報に基づいて、前記ボディの送信を認可するか否かを決定できる。
【００６６】
ボディの送り認可基準として、前記情報フィールドをヘッダから切り分け、コンテントの前に送ることが望ましいが、既存の通信ソフトを最大限に利用するため、前記情報フィールドをヘッダから抽出して、先に送り、認可されたら、コンテントを従来から変えずに、即ち従来のコンテントを送信するDATAコマンドで送信しても良い（３１０６）。または、ヘッダを先に送信して、認可されたら、ボディを送信してもいい。
以上のように、個々の着信者の主観的意思によってメールの配信を事前に許可し、未許可発信者のメール本体を受信しないため、無駄な通信量と迷惑メールを発生しない。必要以上の通信量を使わなくて、標準によって定められた、サイズが限定されたヘッダを用いて、着信者に代わって未許可発信者と自動的に対話し、真に通信を行いたい相手が自由に通信できる知能的なメールシステムを実現する。本発明は個々の着信者の主観を反映する点が従来技術のメールシステムと異なる。
【発明の効果】
【００６７】
無駄な通信と迷惑メールを発生しなて、着信者側の主観的意思を反映し、真に通信を行いたい相手が自由に通信できる。細かいニーズに応じることができる。通信装置の通信、通話用チャンネルを被制御用に統一して被制御機能を実現し、通信装置が所有する機能を外部から制御、利用できる様になる。効率的な移動体情報を収集する事及び移動体を誘導する。簡単な匿名通信、片側だけに発信を許す片道通信ができる。交際、求人求職活動などがより安心に、気楽に公衆通信網を介して行える様になる。
【発明を実施するための最良の形態】
【００６８】
図３０、３１記載のメール送信クライアントと図９、１０記載のメール受信サーバにより構成されるメールシステムは本発明のメール通信に関する最良の形態であり、図２７〜２９に示す様な通信と制御を共存する形態は本発明の同時通信に関する最良の形態である。
【実施例１】
【００６９】
自動応答電話機（３２０１）
図３２は、構成を示すブロック図である。符号１７はマイク、スピーカーである。図３３、７４〜７６は、ＴＤＢ、Ｒ１ＤＢ、Ｒ２ＤＢ、Ｒ４ＤＢ（指示ファイル）を示す。提示情報は、発信者に提示する質問である。質問は予め録音された音声ファイルである。この例では、質問フィールドが空欄であることは質問が提示不要であることを示し、問答が早期終了するための所定の合計の得点が３であり（図１７（１７０７）参照）、自動審査の保存条件は合計得点が５であった場合は、自動的に発信者に第２のルール実行部の待遇を与える（図１３（１３１０）参照）。
図３４は処理の概略フローチャートであり、基本部分は図１３と同じである。本実施例の通信装置が電話機であるか、本発明は通信機能付きパソコン、または電話機専用の外付けアダプター等にも組み込める。初めて着信者が知らない電話番号からかかってくる相手に質問のメッセージを流し、相手がダイヤルボタンを押して応答する。応答を判断して待遇を決める。
【００７０】
図３５は自動審査により関係者の電話番号に正常通話できる待遇を自動的に与える一作動例を示す図である。この発明は着信者本人と既存関係を持つ人だけしか分からない情報を電子秘書に指示ファイルで指示する。基本的な迷惑通信防止機能から多彩な機能が設定可能である。この例の指示ファイル設定は次の機能を実現できる。相手の電話番号毎に指定受信（待遇ＩＤ＝４）、指定拒否（待遇ＩＤ＝１）、未知の相手の場合申請受理が必要なので、呼出音を鳴らずに自動的に直ぐに受話するので、相手側は通信料金を課金される。これにより機械からの不完了呼（ワン切り）電話の発信者に経済上の制裁を与えることができ、且つ発信者が正確の返事がないので、合計採点＝０、待遇ＩＤ＝０、拒否し、番号が受信履歴に残ることもない。ただし許可を与えた相手は通常と同じ呼出音を鳴らし、受信者が受話するまで課金されない。この例では最初の質問で着信者の名前を間違えると、ただちに受信を拒否される。他の用件で、４を押すと第２問が送出され、不動産の販売に関するものなら１、英会話なら２、生活用品なら３、スポーツ用品なら４、のダイヤルボタンを押すように促す。各選択がされると得点に応じて自動的に着信音を鳴らしたり、着信音を鳴らさずに録音したり、通話を切断したり、通話しても発信者番号を自動記憶しない、又は自動記憶する。暗証番号５６７８が押されると、呼出音を鳴らさずに自動的に通話接続する。これにより自宅や子供を監視傍聴ができる。例えば子供用の携帯に親が通話するか傍聴するかを選択できる。例えば自宅のベビーシッターを監視し、子供の虐待を抑える効果が期待できる。
【００７１】
この例の最初の質問は簡単であるが、実際の使用状況に合わせて複雑に設定することが可能である。例えば姓と名とを２つの質問に分けて順番に提示し（一つ目に正解してから２つ目が提示される）、それぞれ５つの選択肢を提示する場合、でたらめに回答して正解になる確率は２５分の１に下がる。このようにすると、長い選択肢を列挙する必要がなく、でたらめの回答が正解になる確率を低くすることができる。
正解欄に設定する番号は工夫次第で多彩な機能を持たせることができる。例えば内線番号と名乗って使用可能であり、案内質問を”内線番号を押して下さい”にすると、その番号を知っている相手の電話が発信番号と無関係に受けられる。この番号は着信者発行の通信許可を得るための暗証番号であり、又は、発信者識別番号（ピン・コード）として使える、又は、特定の機能を制御するコマンド・コードとしても使える。
【００７２】
相手の自宅電話機の発信番号に待遇を与えた場合、相手の自宅発信番号を正解欄に設定すれば、同じ相手が公衆電話から発信したら、案内メッセージに身分確認として、相手の自宅番号を入力してもらい、入力した番号と待遇情報とを照合して待遇を確定できる。この方法の長所は発信者が前記暗証番号を覚えなくともよいことである。
待遇申請を審査する具体方法は、当事者の装置の具体構成によって違う。本発明の審査段階の目的を達成して得る方法であれば、多様な方法を採用することができる。例えば音声認識や、画像認識を活用することが考えられる。
銀行等の自動電話取引サービスで使われている既存技術では、発信者に音声案内を流し、発信者がダイヤルボタンを押して操作し、暗証番号による客様本人の確認をするものがある。本発明は発信番号毎に応答方法が違うことと、発信者が事前に該当サービスに申し込むなど、関係を樹立する必要がないことである。
【００７３】
この例は電子秘書が支配者意思をルールと点数によって受け付けるが、自然言語による受付も可能である。例えば”私の名前を知っている人の電話を受ける。”、”私の興味に合う勧誘電話を受ける。”。電子秘書は公知のルールベース技術（例えば、特許文献１１参照）によって、これらの要求を聞き取り、足りない情報をユーザに入力させ、必要なルールを編成することが可能である。
本発明電子秘書は、公知技術（例えば、特許文献６参照）により電話交換機及び関連サービス提供サーバ側に設置することができる。
この実施例は単純な居留守電話機まで簡略できる。待遇セットが通信許可（ID=4）と居留守（申請受理、ID=6）だけで構成する。ホワイトリストに載っていない発信者に居留守をつかい、案内メッセージを流しながら、相手の声をスピーカで聞かせる。声で身分確認できる場合直ぐ通話できる。
誰か判らない場合だけ居留守をつかう点が従来技術の居留守機能と異なる。
【実施例２】
【００７４】
メール受信クライアントソフトウェア用追加ソフトウェア
本実施例は、電子秘書が通信装置側に組み込まれる。ＰＣ（パソコン）アプリケーションとして製品化し（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”」を記載して、メールが着信すると、第２ルールにより、正確に出願番号と整理番号を記載した発信者にメールを受信する通信許可待遇を与え、与えた待遇を第１ルールセットに保存する。
”出願番号:整理番号”が初めて通信の許可を獲得用パスワードの役割である。それを代わって特許庁又は出願人が決めるパスワードも使える。パスワードの知らせが出願送付文書に記載する。
【０１０２】
第２ルールにより決める待遇ＩＤが６の場合、
受信し、発信者に通信許可待遇を与える。即ち、発信者２回目以後のメールの前記パスワードをチェックしない。
業務用システムが通信関係者多い且つ動的に変化する場合、人により指示ファイルの維持が大変である。この問題が指示ファイルを構築するためにデータを入力するコンポーネントにより解決する。前記コンポーネントは、着信側当事者既存のデータから前記指示ファイルを構築するためのデータ形式に編集して、前記指示ファイルに入力する。
図６７は指示ファイル入力コンポーネントのユーザ・インタフェースのレイアウトを例示する。
図６８は前記ユーザ・インタフェースに従い指示ファイル入力コンポーネントに渡すデータを示す。
【０１０３】
電子秘書５８０１がMicrosoftWindows（登録商標）ベースコンピュータで動く。入力コンポーネントがインターネットを通して、ウェブサーバで定数や案内情報など変動が少ない情報を指示ファイルに入力する。
入力コンポーネントはMicrosoftWindows（登録商標）ベースコンピュータで動き、端末５８１０は特許庁既存の係属中の事件のデータ５８１１から出願番号と整理番号を抽出し、コンポーネントに渡す。或いは出願番号を決める業務データに保存する時点で、業務システムからコンポーネントを呼び出すことにより指示ファイルにデータを入力する。好ましくは入力コンポーネントが許可を与えた発信者ＩＤと第２ルールセットの関連情報を記憶し、出願事件が特許庁に係属しなくなった後に、指示ファイルから関連情報を削除する。
以上のように、関係者多い且つ動的に変化する場合でも、人手により動的維持する事無く、公衆的なインターネット通信網に、関係者限りの安全な専用通信網のような通信環境を作れる。
【０１０４】
電子秘書５８０１が直接インターネット５８１３にメールを送信するが、従来のメールサーバ５８０２を経由して、例えば、５８０８〜５８０１〜５８０２〜５８１３のように、自動返信の以外のメールを転送してもいい（図５８に示せず）。そうすると、ＩＳＰ内部のメール転送（５８０１〜５８０２）が早いため、電子秘書に送信メールのキューの管理を省略でき、従来のメールサーバのキュー管理など機能がフルに活用できる。
従来のメールサーバ、例えば、Unix（登録商標）ベースコンピュータに動くSendmailを利用できる。
本発明はメールサーバのコンポーネントとしても使える。
【産業上の利用可能性】
【０１０５】
以上のように、本発明は通信網上電子装置を用いた通信方法に適している。
【図面の簡単な説明】
【０１０６】
【図１】本発明の基本概略構成例を示す図である。
【図２】本発明の一実施例フローチャートである。
【図３】待遇セットをデータベースに具体化するレイアウト図である。
【図４】発信者ＩＤと待遇に関する第１ルールセットを示す図である。
【図５】別の実施形態のフローチャートである。
【図６】別の実施形態のフローチャートである。
【図７】別の実施形態の構成を示す図である。
【図８】別の実施形態のフローチャートである。
【図９】別の実施形態構成例を示す図である。
【図１０】別の実施形態のフローチャートである。
【図１１】別の実施形態の早期決定処理の部分フローチャートである。
【図１２】別の実施形態のフローチャートである。
【図１３】別の実施形態のフローチャートである。
【図１４】別の実施形態のフローチャートである。
【図１５】別の実施形態構成例を示す図である。
【図１６】別の実施形態のフローチャートである。
【図１７】繰り返し案内の提示と反応の受け取り手順を示す図である。
【図１８】電子秘書及び指示ファイルはサーバ側に組み込む例を示す図である。
【図１９】ネットワークを通して指示ファイルにアクセスする例を示す図である。
【図２０】発信処理部分フローチャートである。
【図２１】匿名の通信に関するシステム構成を示す図である。
【図２２】第１の当事者の処理の部分フローチャートである。
【図２３】第２の当事者の処理の部分フローチャートである。
【図２４】待遇交換処理部分のフローチャートである。
【図２５】提示情報のデータレイアウト図である。
【図２６】第２ルールセットを示すレイアウト図である。
【図２７】位置情報システムの構成を示す概念図である。
【図２８】車両用走行誘導機能のフローチャートである。
【図２９】位置変化監視システムの構成を示す概念図である。
【図３０】メール送信クライアントの構成を示す図である。
【図３１】メール送信フローチャートである。
【図３２】自動応答電話機の構成を示すブロック図である。
【図３３】前記電話機の指示ファイル内容を示す図である。
【図３４】前記電話機のフローチャートである。
【図３５】自動審査により関係者の電話番号に正常通話できる待遇を自動的に与える例を示す図である。
【図３６】第３ルールセットを示すレイアウト図である。
【図３７】第４ルールセットを示すレイアウト図である。
【図３８】メール受信クライアント用追加ソフトウェアの構成を示すブロック図である。
【図３９】前記ソフトウェアの指示ファイル内容を示す図である。
【図４０】受信処理の概略フローチャートである。
【図４１】質問入力画面を示す図である。
【図４２】初期待遇選択画面を示す図である。
【図４３】インターネットテレビ電話システム構成を示すブロック図である。
【図４４】内部構成を示すブロック図である。
【図４５】メインプログラムの動作を示すフローチャートである。
【図４６】メインメニュー画面を示す図である。
【図４７】連絡帳画面を示す図である。
【図４８】メンバー追加画面を示す図である。
【図４９】待遇申請処理を示す図である。
【図５０】個人設定画面を示す図である。
【図５１】ログイン処理動作を示すフローチャートである。
【図５２】友達リスト編集画面を示す図である。
【図５３】待遇申請資格指定画面を示す図である。
【図５４】テレビ電話通信プログラムの動作を示すフローチャートである。
【図５５】接続待機中画面を示す図である。
【図５６】テレビ電話通信中画面を示す図である。
【図５７】待遇関係を築く流れ概要を示す図である。
【図５８】メールサーバシステム実施例の構成を示すブロック図である。
【図５９】待遇情報データ・データベースを示す図である。
【図６０】案内情報データ・データベース（ＧＤＢ）を示すブロック図である。
【図６１】第２ルールセットを示す図である。
【図６２】第１ルールセットを示す図である。
【図６３】攻撃防止用第３ルールセットを示す図である。
【図６４】使い定数を示す図である。
【図６５】中止用第３ルールセットを示す図である。
【図６６】第５ルールセットを示す図である。
【図６７】入力コンポーネントのユーザ・インタフェースを示す図である。
【図６８】入力コンポーネントに渡すデータを示す図である。
【図６９】第５ルールセットのレイアウト図である。
【図７０】待遇関係マスタのレイアウト図である。
【図７１】当事者データレイアウト図である。
【図７２】確認要請データレイアウト図である。
【図７３】立証者情報レイアウト図である。
【図７４】第１ルールセットを示す図である。
【図７５】第２ルールセットを示す図である。
【図７６】第４ルールセットを示す図である。
【図７７】第１ルールセットを示す図である。
【図７８】第２ルールセットを示す図である。
【図７９】第４ルールセットを示す図である。
【図８０】提示情報を示す図である。
【符号の説明】
【０１０７】
１１、１１１、２１１……プロセッサー
１３、１４、１１４、２１４……記憶装置
１５、１１５、２１５……通信転送装置
１６……キーボード及び表示部。
１７……マイク、スピーカー
１８……カメラ及びキーボード及び表示部。
【図１】
2006215590.tif 000003
【図２】
2006215590.tif 000004
【図３】
2006215590.tif 000005
【図４】
2006215590.tif 000006
【図５】
2006215590.tif 000007
【図６】
2006215590.tif 000008
【図８】
2006215590.tif 000009
【図１０】
2006215590.tif 000010
【図１１】
2006215590.tif 000011
【図１２】
2006215590.tif 000012
【図１３】
2006215590.tif 000013
【図１４】
2006215590.tif 000014
【図１６】
2006215590.tif 000015
【図１７】
2006215590.tif 000016
【図２０】
2006215590.tif 000017
【図２２】
2006215590.tif 000018
【図２３】
2006215590.tif 000019
【図２４】
2006215590.tif 000020
【図２５】
2006215590.tif 000021
【図２６】
2006215590.tif 000022
【図２８】
2006215590.tif 000023
【図３１】
2006215590.tif 000024
【図３３】
2006215590.tif 000025
【図３４】
2006215590.tif 000026
【図３６】
2006215590.tif 000027
【図３７】
2006215590.tif 000028
【図３９】
2006215590.tif 000029
【図４０】
2006215590.tif 000030
【図４４】
2006215590.tif 000031
【図４５】
2006215590.tif 000032
【図４９】
2006215590.tif 000033
【図５１】
2006215590.tif 000034
【図５４】
2006215590.tif 000035
【図５９】
2006215590.tif 000036
【図６０】
2006215590.tif 000037
【図６１】
2006215590.tif 000038
【図６２】
2006215590.tif 000039
【図６３】
2006215590.tif 000040
【図６４】
2006215590.tif 000041
【図６５】
2006215590.tif 000042
【図６６】
2006215590.tif 000043
【図６７】
2006215590.tif 000044
【図６８】
2006215590.tif 000045
【図６９】
2006215590.tif 000046
【図７０】
2006215590.tif 000047
【図７１】
2006215590.tif 000048
【図７２】
2006215590.tif 000049
【図７３】
2006215590.tif 000050
【図７４】
2006215590.tif 000051
【図７５】
2006215590.tif 000052
【図７６】
2006215590.tif 000053
【図７７】
2006215590.tif 000054
【図７８】
2006215590.tif 000055
【図７９】
2006215590.tif 000056
【図８０】
2006215590.tif 000057
【図７】
2006215590.tif 000058
【図９】
2006215590.tif 000059
【図１５】
2006215590.tif 000060
【図１８】
2006215590.tif 000061
【図１９】
2006215590.tif 000062
【図２１】
2006215590.tif 000063
【図２７】
2006215590.tif 000064
【図２９】
2006215590.tif 000065
【図３０】
2006215590.tif 000066
【図３２】
2006215590.tif 000067
【図３５】
2006215590.tif 000068
【図３８】
2006215590.tif 000069
【図４１】
2006215590.tif 000070
【図４２】
2006215590.tif 000071
【図４３】
2006215590.tif 000072
【図４６】
2006215590.tif 000073
【図４７】
2006215590.tif 000074
【図４８】
2006215590.tif 000075
【図５０】
2006215590.tif 000076
【図５２】
2006215590.tif 000077
【図５３】
2006215590.tif 000078
【図５５】
2006215590.tif 000079
【図５６】
2006215590.tif 000080
【図５７】
2006215590.tif 000081
【図５８】
2006215590.tif 000082
【手続補正書】
【提出日】平成16年8月9日(2004.8.9)
【手続補正１】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006215590.tif 000083
【図２】
2006215590.tif 000084
【図３】
2006215590.tif 000085
【図４】
2006215590.tif 000086
【図５】
2006215590.tif 000087
【図６】
2006215590.tif 000088
【図７】
2006215590.tif 000089
【図８】
2006215590.tif 000090
【図９】
2006215590.tif 000091
【図１０】
2006215590.tif 000092
【図１１】
2006215590.tif 000093
【図１２】
2006215590.tif 000094
【図１３】
2006215590.tif 000095
【図１４】
2006215590.tif 000096
【図１５】
2006215590.tif 000097
【図１６】
2006215590.tif 000098
【図１７】
2006215590.tif 000099
【図１８】
2006215590.tif 000100
【図１９】
2006215590.tif 000101
【図２０】
2006215590.tif 000102
【図２１】
2006215590.tif 000103
【図２２】
2006215590.tif 000104
【図２３】
2006215590.tif 000105
【図２４】
2006215590.tif 000106
【図２５】
2006215590.tif 000107
【図２６】
2006215590.tif 000108
【図２７】
2006215590.tif 000109
【図２８】
2006215590.tif 000110
【図２９】
2006215590.tif 000111
【図３０】
2006215590.tif 000112
【図３１】
2006215590.tif 000113
【図３２】
2006215590.tif 000114
【図３３】
2006215590.tif 000115
【図３４】
2006215590.tif 000116
【図３５】
2006215590.tif 000117
【図３６】
2006215590.tif 000118
【図３７】
2006215590.tif 000119
【図３８】
2006215590.tif 000120
【図３９】
2006215590.tif 000121
【図４０】
2006215590.tif 000122
【図４３】
2006215590.tif 000123
【図４４】
2006215590.tif 000124
【図４５】
2006215590.tif 000125
【図４９】
2006215590.tif 000126
【図５１】
2006215590.tif 000127
【図５４】
2006215590.tif 000128
【図５７】
2006215590.tif 000129
【図５８】
2006215590.tif 000130
【図５９】
2006215590.tif 000131
【図６０】
2006215590.tif 000132
【図６１】
2006215590.tif 000133
【図６２】
2006215590.tif 000134
【図６３】
2006215590.tif 000135
【図６４】
2006215590.tif 000136
【図６５】
2006215590.tif 000137
【図６６】
2006215590.tif 000138
【図６７】
2006215590.tif 000139
【図６８】
2006215590.tif 000140
【図６９】
2006215590.tif 000141
【図７０】
2006215590.tif 000142
【図７１】
2006215590.tif 000143
【図７２】
2006215590.tif 000144
【図７３】
2006215590.tif 000145
【図７４】
2006215590.tif 000146
【図７５】
2006215590.tif 000147
【図７６】
2006215590.tif 000148
【図７７】
2006215590.tif 000149
【図７８】
2006215590.tif 000150
【図７９】
2006215590.tif 000151
【図８０】
2006215590.tif 000152
【図４１】
2006215590.tif 000153
【図４２】
2006215590.tif 000154
【図４６】
2006215590.tif 000155
【図４７】
2006215590.tif 000156
【図４８】
2006215590.tif 000157
【図５０】
2006215590.tif 000158
【図５２】
2006215590.tif 000159
【図５３】
2006215590.tif 000160
【図５５】
2006215590.tif 000161
【図５６】
2006215590.tif 000162