(57)【要約】  本発明は着信呼の処理方法を開示している。当該方法では、まず被呼端末にアクセス呼識別子を設定し、被呼端末は発呼側によって開始された呼を受信する際に、当該呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断して、含まれていれば、当該呼を接続し、そうでなければ、当該呼に対して中止処理を行う。本発明方案によっては、加入者が電話の邪魔を防ぐために採用している従来の種々の方法によって引き起こされる問題、即ち、重要な電話を接続できない問題、処理費用が追加される問題、電話の邪魔を防ぐことが部分的にしかできない問題などを解決できる。本発明方案は、被呼加入者が邪魔されたくないときに、重要ではない電話または迷惑電話に邪魔されないように保証していると共に、被呼加入者が重要な電話を受けそこなわないように保証している。
2008502236.tif 000002
【特許請求の範囲】
【請求項１】
着信呼の処理方法であって、被呼端末にアクセス呼識別子を設定し、
被呼端末は発呼側によって開始された呼を受信する際に、当該呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断して、含まれていれば、当該呼を接続し、そうでなければ、当該呼に対して中止処理を行う、
ことを含むことを特徴とする方法。
【請求項２】
前記被呼端末に設定したアクセス呼識別子は発呼番号であり、
前記被呼端末にはアクセスコード及び発呼番号登録テーブルが設定されており、発呼番号を登録するための登録要求を識別する機能が設定され、
前記呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断する前に、
a．当該呼が登録要求であるかどうかを判断して、登録要求であれば、予め設定されたアクセスコードが当該登録要求に含まれているかどうかを更に判断して、含まれていれば、当該呼から登録する必要のある発呼番号を取得し、当該発呼番号を発呼番号登録テーブルに格納し、含まれていなければ、登録を拒否した後で終了し、登録要求ではなければ、当該呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断するステップを実行し、
前記呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断することは、
b.被呼端末は当該呼に対応する発呼番号が発呼番号登録テーブルに格納されているかどうかを判断して、格納されていれば、当該呼に本被呼端末のアクセス呼識別子が含まれていると判定し、そうではなければ、当該呼に本被呼端末のアクセス呼識別子が含まれていないと判定することである、
ことを特徴とする請求項1記載の方法。
【請求項３】
発呼番号を格納するホワイトリストを被呼端末に設定し、
ステップaにおいて、前記予め設定されたアクセスコードが登録要求に含まれているかどうかを被呼端末が判断する前に、
当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断して、格納されていれば、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行せず、そうではなければ、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行することを更に含む、
ことを特徴とする請求項2記載の方法。
【請求項４】
発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記被呼端末が当該呼が登録要求であるかどうかを判断する前に、
当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、終了し、そうではなければ、当該呼が登録要求であるかどうかを判断するステップを実行することを更に含む、
ことを特徴とする請求項2記載の方法。
【請求項５】
発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記予め設定されたアクセスコードが当該登録要求に含まれているかどうかを被呼端末が判断する前に、
当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、登録を拒否した後、終了し、そうではなければ、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行することを更に含む、
ことを特徴とする請求項2記載の方法。
【請求項６】
発呼番号を格納するホワイトリスト及び発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記被呼端末が当該呼が登録要求であるかどうかを判断する前に、
被呼端末は当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、終了し、そうではなければ、ステップa2に進むステップa1と、
被呼端末は当該発呼番号がホワイトリストに格納されているかどうかを更に判断して、格納されていれば、ステップa3に進み、そうではなければ、直接にステップaにおける当該呼が登録要求であるかどうかを判断するステップ及び後続のステップを実行するステップa2と、
当該呼が登録要求であるかどうかを判断して、登録要求であれば、予め設定されたアクセスコードが当該登録要求に含まれているかどうかを判断するという後続のステップを実行せず、そうではなければ、当該呼を接続するステップa3とを更に含む、
ことを特徴とする請求項2記載の方法。
【請求項７】
発呼番号を格納するホワイトリスト及び発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記被呼端末が当該呼が登録要求であるかどうかを判断する前に、
被呼端末は当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、終了し、そうではなければ、当該呼が登録要求であるかどうかを判断するステップを実行することを更に含み、
ステップaにおいて、前記予め設定されたアクセスコードが当該登録要求に含まれているかどうかを被呼端末が判断する前に、
当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断して、格納されていれば、当該判断するステップを実行せず、そうではなければ、当該判断するステップを実行することを更に含む、
ことを特徴とする請求項2記載の方法。
【請求項８】
発呼番号を格納するホワイトリスト及び発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記予め設定されたアクセスコードが登録要求に含まれているかどうかを被呼端末が判断する前に、
当該呼に対応する発呼番号がホワイトリスト又はブラックリストに格納されているかどうかを判断して、ホワイトリストに格納されていれば、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行せず、ブラックリストに格納されていれば、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行することを更に含む、
ことを特徴とする請求項2記載の方法。
【請求項９】
ホワイトリストを設定した後、被呼端末は自体の発呼番号登録テーブルの中にホワイトリストに格納された発呼番号があるかどうかを判断して、あれば、発呼番号登録テーブルの中の当該発呼番号を削除し、そうではなければ、処理をしない、
ことを特徴とする請求項3、6、7又は8記載の方法。
【請求項１０】
ブラックリストを設定した後、被呼端末は自体の発呼番号登録テーブルの中ホワイトリストに格納された発呼番号があるかどうかを判断して、あれば、発呼番号登録テーブルの中の当該発呼番号を削除し、そうではなければ、処理をしない、
ことを特徴とする請求項4、5、6、7又は8記載の方法。
【請求項１１】
前記登録要求はショートメッセージであり、
ステップaにおいて、前記呼が登録要求であるかどうかを判断することは、現在受信した呼がショートメッセージであるかどうかを判断して、ショートメッセージであれば、現在の呼が登録要求であると確定し、そうではなければ、現在の呼が登録要求ではないと確定することであり、
前記被呼端末によって登録を拒否した後、終了する前に、ショートメッセージの正常なプロセスに従って処理することを更に含む、
ことを特徴とする請求項2記載の方法。
【請求項１２】
前記登録要求は登録要求識別子が設定されているショートメッセージであり、
ステップaにおいて、前記被呼端末が当該呼が登録要求であるかどうかを判断することは、現在受信した呼がショートメッセージであるかどうかを判断して、ショートメッセージであれば、当該ショートメッセージに登録要求識別子があるかどうかを更に判断して、ショートメッセージに登録要求識別子があれば、当該呼が登録要求であると確定し、ショートメッセージに登録要求識別子がなければ、当該呼が登録要求ではないと確定することである、
ことを特徴とする請求項2記載の方法。
【請求項１３】
発呼番号を格納するホワイトリストを被呼端末に設定し、
前記被呼端末が呼に対して中止処理を行う前に、当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断して、格納されていれば、当該呼を接続し、そうではなければ、当該呼に対して中止処理を行うステップを実行することを更に含む、
ことを特徴とする請求項1記載の方法。
【請求項１４】
前記被呼端末にアクセス呼識別子を設定することはアクセスコードを設定することであり、
前記被呼端末が本被呼端末のアクセス呼識別子が呼に含まれているかどうかを判断することは、当該呼に自体のアクセスコードが含まれているかどうかを判断することである、
ことを特徴とする請求項1記載の方法。
【請求項１５】
前記呼はショートメッセージ、又はマルチメディアショートメッセージ、又はユーザツーユーザシグナリング（UUS）であり、
前記発呼側によって開始された呼にアクセスコードが含まれていることは、呼情報の内容にアクセスコードが含まれていることである、
ことを特徴とする請求項14記載の方法。
【請求項１６】
前記呼は音声呼であり、
前記被呼端末が自体のアクセスコードが呼に含まれているかどうかを判断することは、被呼端末は当該呼を接続し、アクセスコードを入力するように発呼側に指示し、設定された時間内に発呼側によって入力されるアクセスコードを受信しなかったら、今回の呼にアクセスコードが含まれていないと確定し、そうでなければ、当該アクセスコードを取得し、当該アクセスコードが自体によって設定されたアクセスコードであるかどうかを判断することを含む、
ことを特徴とする請求項14記載の方法。
【請求項１７】
前記発呼側はデュアルトーンマルチ周波数信号、又は周波数偏移変調（FSK）信号、又はシグナリング、又は音声を通じてアクセスコードを送信し、
前記被呼端末はデュアルトーンマルチ周波数信号、又は周波数偏移変調（FSK）信号、又はシグナリング、又は音声を通じてアクセスコードを受信する、
ことを特徴とする請求項16記載の方法。
【請求項１８】
発呼番号を格納するホワイトリストを被呼端末に設定し、
前記被呼端末が当該呼に自体のアクセスコードが含まれているかどうかを判断する前に、
当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断して、格納されていれば、当該呼を接続し、そうでなければ、当該呼に自体のアクセスコードが含まれているかどうかを判断するステップを実行することを含む、
ことを特徴とする請求項14記載の方法。
【請求項１９】
発呼番号を格納するブラックリストを被呼端末に設定し、
前記被呼端末が当該呼に自体のアクセスコードが含まれているかどうかを判断する前に、
当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、当該呼に対して中止処理を行い、そうでなければ、当該呼に自体のアクセスコードが含まれているかどうかを判断するステップを実行することを含む、
ことを特徴とする請求項14記載の方法。
【請求項２０】
発呼番号を格納するホワイトリスト及び発呼番号を格納するブラックリストを被呼端末に設定し、
前記被呼端末が当該呼に自体のアクセスコードが含まれているかどうかを判断する前に、
当該呼に対応する発呼番号がホワイトリスト又はブラックリストに格納されているかどうかを判断して、ホワイトリストに格納されていれば、当該呼を接続し、ブラックリストに格納されていれば、直接に当該呼に対して中止処理を行い、ホワイトリストとブラックリストのいずれかにも格納されていなければ、自体のアクセスコードが当該呼に含まれているかどうかを判断するステップを実行することを含む、
ことを特徴とする請求項14記載の方法。
【請求項２１】
前記発呼側によって開始された呼がショートメッセージ、又はマルチメディアショートメッセージ、又はユーザツーユーザシグナリング（UUS）である際に、
前記被呼端末が現在の呼に対して中止処理を行うことは、現在受信された呼情報を削除することであり、
呼が音声呼である際に、前記呼に対して中止処理を行うことは、当該呼の接続を拒否し、又は当該呼を終了することである、
ことを特徴とする請求項1記載の方法。
【請求項２２】
前記端末は移動端末、又は固定端末、又は携帯情報端末（ＰＤＡ）、又は携帯型パーソナルコンピュータである、
ことを特徴とする請求項1記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信技術における呼処理技術に関し、特に着信呼（incoming call）の処理方法に関する。
【背景技術】
【０００２】
固定電話、携帯電話など端末装置の普及に伴って、端末装置は人々の仕事と生活に極大な便利を与えている。人々はこれらの端末装置を用いて外部といつでも通信することができる。ところが、これらの端末装置は加入者に迷惑を与えることもある。例えば、加入者は、夜又は他の休憩時間内で重要ではない電話に邪魔されないと共に、重要な電話を受けそこなわないことを希望している。しかし、実際に、この時間帯では、重要ではない電話がしばしばあり、ひいては迷惑電話もある。
【０００３】
電話に邪魔されることを避けるためには、加入者が端末装置をオフにして、使用しようとする際に端末装置を再度オンにすることができる。端末装置には固定端末と移動端末が含まれる。端末装置をオフにする方案で、移動端末をオフにするのは容易である。固定電話をオフにするためには、現在では電話線を切断するほかに方法がないが、これは加入者にとってとても不便になることである。そして、移動端末であろうと固定端末であろうと、端末装置をオフにすることでは他の問題が出てくる。即ち、端末装置をオフにすると、加入者がどんな電話でも受けることができない状況になる。こうして、他の人は非常に重要なことがあっても当該端末装置を通じては加入者と連絡できなくなってしまう。なお、当該方案では、加入者が、使用しようとする際に端末装置を再度オンにする必要がある。身に付けて携帯する移動端末に対して、オン又はオフにするのは便利であるが、固定端末に対しては、加入者がオンにすることを忘れるのがよくある。端末装置をオフにした後、オンにすることを加入者が忘れると、当該端末装置を通じて他の加入者の電話を受けることが加入者にとってできなくなる。
【０００４】
加入者は現在の移動通信システムに提供される秘書システムサービスを用いることもできるが、このサービスは、現在では、移動端末に限っている。秘書システムサービスについて、移動端末を用いる加入者は、秘書システムを通じてサービス内容を設けることができる。例えば、現在、電話に邪魔されたくないとき、加入者は秘書システムに、現在着信の発呼加入者によるメッセージを残し、当該メッセージを自分に送信するように要請することができる。こうして、秘書システムは当該加入者に対する着信を受け取った際に、メッセージを残すことを当該発呼加入者に要請し、次いでショートメッセージなど方式を通じて被呼加入者に知らせ、被呼加入者は秘書システムの電話をダイヤルすることを通じて当該発呼加入者のメッセージを得る。当該被呼加入者は発呼加入者のメッセージに基づいて電話を掛けるかどうかを決める。このようにして、被呼加入者は電話に邪魔されないように保証されている。
【０００５】
しかし、秘書システムサービスが課金サービスであるため、当該サービスを用いる加入者は費用を支払わなければならない。そして秘書システムが着信呼をショートメッセージ又は他の方式に換えて被呼加入者に知らせるので、加入者は電話は受けないが、ショートメッセージ又は他の情報を受信するようになる。従って、この方案は、加入者が邪魔される問題を根本的に解決した方案ではない。しかも、秘書システムによって被呼加入者に送信されるショートメッセージなどが遅延され、ひいては無くされ、又は加入者に適時に読まれていない可能性がある。例えば、ショートメッセージの非適時性と、一般的に加入者がショートメッセージの通知音を静かな音や弱音に設定し、ひいては設定しないなど原因で、加入者がショートメッセージを適時に処理できないことがよくあり、従って、緊急なことを適時に処理できないことになる。
【０００６】
また、着信呼のフィルタリングする方案がある。例えば、発呼ブラックリストとホワイトリスト（好ましいもののリスト）の方案は、加入者に対して、重要ではない電話に邪魔されないと共に、重要な電話を受けそこなわないようにする。具体的に、ホワイトリスト方案ではホワイトリストに予め被呼端末にアクセスできる発呼番号を設定する。被呼端末がホワイトリスト機能をスタートしたとき、ホワイトリストにおけるこれらの発呼番号だけが被呼端末にアクセスできる。当該方案によっては、上記問題を大幅に解決することができるが、アクセスできる発呼番号が限定されているため、ある加入者Aは急用で加入者Cと通話しようとするが、ホワイトリストに設定された番号を発呼番号として用いて被呼加入者Cを呼び出すことができないとき、例えば、加入者Aが、携帯電話の電源が切れていて加入者Bの携帯電話を通じて被呼加入者Cと連絡しようとするとき、ホワイトリストに加入者Aの携帯番号があっても、加入者Bの携帯電話番号がホワイトリストにないため、このとき、加入者Aは当該被呼加入者Cと連絡することができなくなる。ブラックリスト方案では、ブラックリストに予め被呼端末にアクセスできない発呼番号を設定する。被呼端末はブラックリスト機能をスタートして、呼を接続する際に、発呼番号がブラックリストにあると判定したら、呼の接続を拒否する。しかし、当該方案によっては、他の人がブラックリスト以外の電話で被呼加入者を呼び出すことは防止できない。例えば、ある迷惑なユーザが公衆電話を用いてある被呼加入者に迷惑をかけるなどの状況はブラックリスト方式を通じては避けることができない。また、ブラックリストとホワイトリストはそのメンテナンスが煩雑である。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は上記に鑑みてなされたものであって、加入者が自体の端末にアクセスする着信呼を必要に応じて制御することができる、着信呼の処理方法を提供することを主たる目的とする。
【課題を解決するための手段】
【０００８】
上記の目的を達するために、本発明の技術方案は下記のように実現されている。
【０００９】
着信呼の処理方法であって、被呼端末にアクセス呼識別子を設定し、
被呼端末は発呼側によって開始された呼を受信する際に、当該呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断して、含まれていれば、当該呼を接続し、そうでなければ、当該呼に対して中止処理を行うことを含む。
【００１０】
前記被呼端末に設定したアクセス呼識別子は発呼番号であり、
前記被呼端末にはアクセスコード及び発呼番号登録テーブルが設定されており、発呼番号を登録するための登録要求を識別する機能が設定され、
前記呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断する前に、
a．当該呼が登録要求であるかどうかを判断して、登録要求であれば、予め設定されたアクセスコードが当該登録要求に含まれているかどうかを更に判断して、含まれていれば、当該呼から登録する必要のある発呼番号を取得し、当該発呼番号を発呼番号登録テーブルに格納し、含まれていなければ、登録を拒否した後で終了し、登録要求ではなければ、当該呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断するステップを実行し、
前記呼に本被呼端末のアクセス呼識別子が含まれているかどうかを判断することは、
b.被呼端末は当該呼に対応する発呼番号が発呼番号登録テーブルに格納されているかどうかを判断して、格納されていれば、当該呼に本被呼端末のアクセス呼識別子が含まれていると判定し、そうではなければ、当該呼に本被呼端末のアクセス呼識別子が含まれていないと判定することであることを含む。
【００１１】
発呼番号を格納するホワイトリストを被呼端末に設定し、
ステップaにおいて、前記予め設定されたアクセスコードが登録要求に含まれているかどうかを被呼端末が判断する前に、
当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断して、格納されていれば、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行せず、そうではなければ、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行することを更に含む。
【００１２】
発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記被呼端末が当該呼が登録要求であるかどうかを判断する前に、
当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、終了し、そうではなければ、当該呼が登録要求であるかどうかを判断するステップを実行することを更に含む。
【００１３】
発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記予め設定されたアクセスコードが当該登録要求に含まれているかどうかを被呼端末が判断する前に、
当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、登録を拒否した後、終了し、そうではなければ、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行することを更に含む。
【００１４】
発呼番号を格納するホワイトリスト及び発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記被呼端末が当該呼が登録要求であるかどうかを判断する前に、
被呼端末は当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、終了し、そうではなければ、ステップa2に進むステップa1と、
被呼端末は当該発呼番号がホワイトリストに格納されているかどうかを更に判断して、格納されていれば、ステップa3に進み、そうではなければ、直接にステップaにおける当該呼が登録要求であるかどうかを判断するステップ及び後続のステップを実行するステップa2と、
当該呼が登録要求であるかどうかを判断して、登録要求であれば、予め設定されたアクセスコードが当該登録要求に含まれているかどうかを判断するという後続のステップを実行せず、そうではなければ、当該呼を接続するステップa3とを更に含む。
【００１５】
発呼番号を格納するホワイトリスト及び発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記被呼端末が当該呼が登録要求であるかどうかを判断する前に、
被呼端末は当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、終了し、そうではなければ、当該呼が登録要求であるかどうかを判断するステップを実行することを更に含み、
ステップaにおいて、前記予め設定されたアクセスコードが当該登録要求に含まれているかどうかを被呼端末が判断する前に、
当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断して、格納されていれば、当該判断するステップを実行せず、そうではなければ、当該判断するステップを実行することを更に含む。
【００１６】
発呼番号を格納するホワイトリスト及び発呼番号を格納するブラックリストを被呼端末に設定し、
ステップaにおいて、前記予め設定されたアクセスコードが登録要求に含まれているかどうかを被呼端末が判断する前に、
当該呼に対応する発呼番号がホワイトリスト又はブラックリストに格納されているかどうかを判断して、ホワイトリストに格納されていれば、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行せず、ブラックリストに格納されていれば、予め設定されたアクセスコードが登録要求に含まれているかどうかを判断するステップを実行することを更に含む。
【００１７】
ホワイトリストを設定した後、被呼端末は自体の発呼番号登録テーブルの中にホワイトリストに格納された発呼番号があるかどうかを判断して、あれば、発呼番号登録テーブルの中の当該発呼番号を削除し、そうではなければ、処理をしない。
【００１８】
ブラックリストを設定した後、被呼端末は自体の発呼番号登録テーブルの中にホワイトリストに格納された発呼番号があるかどうかを判断して、あれば、発呼番号登録テーブルの中の当該発呼番号を削除し、そうではなければ、処理をしない。
【００１９】
前記登録要求はショートメッセージであり、
ステップaにおいて、前記呼が登録要求であるかどうかを判断することは、現在受信した呼がショートメッセージであるかどうかを判断して、ショートメッセージであれば、現在の呼が登録要求であると確定し、そうではなければ、現在の呼が登録要求ではないと確定することであり、
前記被呼端末によって登録を拒否した後、終了する前に、ショートメッセージの正常なプロセスに従って処理することを更に含む。
【００２０】
前記登録要求は登録要求識別子が設定されているショートメッセージであり、
ステップaにおいて、前記被呼端末が当該呼が登録要求であるかどうかを判断することは、現在受信した呼がショートメッセージであるかどうかを判断して、ショートメッセージであれば、当該ショートメッセージに登録要求識別子があるかどうかを更に判断して、ショートメッセージに登録要求識別子があれば、当該呼が登録要求であると確定し、ショートメッセージに登録要求識別子がなければ、当該呼が登録要求ではないと確定することである。
【００２１】
発呼番号を格納するホワイトリストを被呼端末に設定し、
前記被呼端末が呼に対して中止処理を行う前に、当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断して、格納されていれば、当該呼を接続し、そうではなければ、当該呼に対して中止処理を行うステップを実行することを更に含む。
【００２２】
前記被呼端末にアクセス呼識別子を設定することはアクセスコードを設定することであり、
前記被呼端末が本被呼端末のアクセス呼識別子が呼に含まれているかどうかを判断することは、当該呼に自体のアクセスコードが含まれているかどうかを判断することである。
【００２３】
前記呼はショートメッセージ、又はマルチメディアショートメッセージ、又はユーザツーユーザシグナリング（UUS）であり、
前記発呼側によって開始された呼にアクセスコードが含まれていることは、呼情報の内容にアクセスコードが含まれていることである。
【００２４】
前記呼は音声呼であり、
前記被呼端末が自体のアクセスコードが呼に含まれているかどうかを判断することは、被呼端末は当該呼を接続し、アクセスコードを入力するように発呼側に指示し、設定された時間内に発呼側によって入力されるアクセスコードを受信しなかったら、今回の呼にアクセスコードが含まれていないと確定し、そうでなければ、当該アクセスコードを取得し、当該アクセスコードが自体によって設定されたアクセスコードであるかどうかを判断することを含む。
【００２５】
前記発呼側はデュアルトーンマルチ周波数信号、又は周波数偏移変調（FSK）信号、又はシグナリング、又は音声を通じてアクセスコードを送信し、
前記被呼端末はデュアルトーンマルチ周波数信号、又は周波数偏移変調（FSK）信号、又はシグナリング、又は音声を通じてアクセスコードを受信する。
【００２６】
発呼番号を格納するホワイトリストを被呼端末に設定し、
前記被呼端末が当該呼に自体のアクセスコードが含まれているかどうかを判断する前に、
当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断して、格納されていれば、当該呼を接続し、そうでなければ、当該呼に自体のアクセスコードが含まれているかどうかを判断するステップを実行することを含む。
【００２７】
発呼番号を格納するブラックリストを被呼端末に設定し、
前記被呼端末が当該呼に自体のアクセスコードが含まれているかどうかを判断する前に、
当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、当該呼に対して中止処理を行い、そうでなければ、当該呼に自体のアクセスコードが含まれているかどうかを判断するステップを実行することを含む。
【００２８】
発呼番号を格納するホワイトリスト及び発呼番号を格納するブラックリストを被呼端末に設定し、
前記被呼端末が当該呼に自体のアクセスコードが含まれているかどうかを判断する前に、
当該呼に対応する発呼番号がホワイトリスト又はブラックリストに格納されているかどうかを判断して、ホワイトリストに格納されていれば、当該呼を接続し、ブラックリストに格納されていれば、直接に当該呼に対して中止処理を行い、ホワイトリストとブラックリストのいずれかにも格納されていなければ、自体のアクセスコードが当該呼に含まれているかどうかを判断するステップを実行することを含む。
【００２９】
前記発呼側によって開始された呼がショートメッセージ、又はマルチメディアショートメッセージ、又はユーザツーユーザシグナリング（UUS）である際に、
前記被呼端末が現在の呼に対して中止処理を行うことは、現在受信された呼情報を削除することであり、
呼が音声呼である際に、前記呼に対して中止処理を行うことは、当該呼の接続を拒否し、又は当該呼を終了することである。
【００３０】
前記端末は移動端末、又は固定端末、又は携帯情報端末（ＰＤＡ）、又は携帯型パーソナルコンピュータである。
【発明の効果】
【００３１】
本発明方案において、被呼端末にアクセス呼識別子を設定することにより、発呼加入者がある発呼番号を通じて被呼端末を呼び出すとき、被呼端末は、本被呼端末のアクセス呼識別子が当該呼に格納されているかどうかを判断することで、現在の呼を正常なプロセスに従って処理するかどうかを確定することができる。また、本発明方案において、被呼端末にホワイトリスト及びブラックリストを設定することで、被呼端末に、ホワイトリスト及びブラックリストを通じて発呼番号登録テーブルに格納されている発呼番号を限定することを可能にし、それによって被呼端末に、着信呼を更にフレキシブルかつ便利に制御できるようにする。
【発明を実施するための最良の形態】
【００３２】
本発明方案は、主に被呼端末にアクセス呼識別子を設定し、被呼端末は発呼側によって開始された呼を受信する際に、当該呼に自体のアクセス呼識別子が含まれているかどうかを判断して、含まれていれば、当該呼の正常的なプロセスに従って処理し、そうでなければ、当該呼に対して中止処理を行うことである。本発明で、前記呼の正常的なプロセスに従って処理することは、従来技術を用いて当該呼を接続し、被呼端末を用いる加入者に当該呼を受信するように例えば鳴動などで知らせることである。
【００３３】
本発明方案は、具体的に、アクセス呼識別子の設定で二つの方式があり、それに相応して、被呼端末で二つの処理方式がある。一つの方式は、発呼番号をアクセス呼識別子とすることであり、もう一つの方式は、アクセスコードを設定し、当該アクセスコードをアクセス呼識別子とすることである。一つ目の処理方式について、当該方式では、主に被呼端末に登録要求の識別機能、アクセスコード及び発呼番号登録テーブルを設定することで、発呼加入者に、アクセスコードを備える登録要求を通じて自体の発呼番号を発呼番号登録テーブルに格納することを可能にすることにより、当該発呼番号をアクセス呼識別子としている。その後で、発呼加入者が当該発呼番号を通じて被呼端末を呼び出すとき、被呼端末は、発呼番号登録テーブルに当該発呼番号即ちアクセス呼識別子が格納されているかどうかを判断することで、現在の呼を正常なプロセスに従って処理するかどうかを確定することができる。二つ目の処理方式に対して、当該方式では、主に被呼端末にアクセスコードを設定することで、当該アクセスコードをアクセス呼識別子としている。発呼加入者が被呼端末を呼び出す際に、被呼端末は発呼番号登録テーブルにアクセスコードが格納されているかどうかを判断することで、現在の呼を正常なプロセスに従って処理するかどうかを確定することができる。
【００３４】
次に、図面を参照してこの二つの方式を説明する。
【００３５】
一つ目の方式にとって、アクセス呼識別子の設定は主に、登録要求の識別機能を設定し、被呼加入者によって被呼端末にアクセスコード及び発呼番号登録テーブルが設定され、被呼端末は発呼側によって開始される呼を受信する際に、当該呼が登録要求であれば、登録を必要とする発呼番号を当該呼から取得し、設定された発呼番号登録テーブルに当該発呼番号を格納することにより、被呼加入者によってアクセスが許容された発呼番号を被呼端末に格納し、即ち、被呼端末にアクセス呼識別子を格納している。このように設定してから、当該呼が登録要求ではないとき、被呼端末は自体の発呼番号登録テーブルに当該呼に対応する発呼番号が含まれている、即ち相応のアクセス呼識別子が含まれていると確定する際に、当該呼の正常なプロセスに従って当該呼を処理する。
【００３６】
一つ目の方式の実現手順は図１を参照し、具体的には、下記のステップで実現することができる。
【００３７】
ステップ101で、予め発呼番号を登録するための登録要求を識別する機能を被呼端末に設定する。
【００３８】
当該登録要求は、ショートメッセージ、マルチメディアショートメッセージ、ユーザツーユーザシグナリング（UUS，User-to-User Signaling）又は音声呼として設定されることができる。
【００３９】
登録要求を識別する機能、即ち登録要求の識別機能は、被呼端末によって受信される呼がショートメッセージ又はマルチメディアショートメッセージであれば、当該呼を登録要求として識別し、或いは、被呼端末によって受信される呼に登録要求識別子が添付されていれば、当該呼を登録要求として識別するように設定されることができる。
【００４０】
ステップ102で、被呼端末にアクセスコード及び発呼番号登録テーブルを設定する。
【００４１】
常に、アクセスコードは被呼加入者によって設定される。自分の親戚や友達が当該アクセスコードに基づいて自分といつでも連絡できるように、被呼加入者はアクセスコードを設定した後、当該アクセスコードを自分の親戚や友達に通知することができる。設定される発呼番号登録テーブルは発呼番号を格納するものである。
【００４２】
ステップ103で、発呼加入者は被呼端末に対して呼を開始する。
【００４３】
ステップ104で、被呼端末は呼を受信したとき、まず、当該呼が登録要求であるかどうかを判断して、登録要求であれば、ステップ105に進み、そうでなければ、ステップ108に進む。
【００４４】
本発明において、ステップ101で登録要求の識別機能が設定されたため、受信された呼の類型に基づいて当該呼が登録要求であるかどうかを判断することができる。
【００４５】
ステップ105で、被呼端末は被呼端末によって設定されたアクセスコードが当該登録要求に含まれているかどうかを判断して、あれば、ステップ106に進み、そうでなければ、ステップ107に進む。
【００４６】
登録要求がショートメッセージであれば、アクセスコードと発呼番号はショートメッセージの内容に含まれることができる。もちろん、登録しようとする発呼番号が現在の呼の発呼番号であれば、当該発呼番号は発呼番号識別方式によって被呼端末に伝送されることもでき、このとき、登録要求のショートメッセージにはアクセスコードが含まれることだけが必要である。
【００４７】
ステップ106で、被呼端末は呼から発呼番号を抽出し、当該発呼番号を発呼番号登録テーブルに格納する。
【００４８】
ステップ107で、被呼端末は登録を拒否し、本処理プロセスを終了する。
【００４９】
ステップ108で、被呼端末は当該呼に対応する発呼番号が自体の発呼番号登録テーブルに格納されているかどうかを判断して、格納されていれば、ステップ109に進み、そうでなければ、ステップ110に進む。
【００５０】
ステップ109で、被呼端末は当該呼の正常なプロセスに従って処理する。
【００５１】
ステップ110で、被呼端末は当該呼に対して中止処理を行い、本処理プロセスを終了する。
【００５２】
発呼側によって開始された呼がショートメッセージ、マルチメディアショートメッセージ、UUS又は音声呼であり得るため、被呼端末が現在の呼に対して中止処理を行うことは、ショートメッセージ、マルチメディアショートメッセージ、UUSに対しては、現在受信された情報を削除することであり、音声呼に対しては、現在の呼の接続を拒否することである。
【００５３】
また、登録要求がショートメッセージである場合に対して、具体的には、ショートメッセージに特殊な識別子を設定することができ、当該識別子は登録要求識別子と称される。こうして、被呼端末は呼を受信したとき、まず、当該呼がショートメッセージであるかどうかを判断して、ショートメッセージであれば、当該ショートメッセージに当該登録要求識別子があるかどうかを更に判断して、あれば、当該ショートメッセージを登録要求であると確定し、そうでなければ、当該ショートメッセージを登録要求ではないと確定する。もちろん、登録要求がショートメッセージである場合に対して、被呼端末を以下のように設定していい。即ち、現在の呼をショートメッセージであると確定した後、直ちに当該呼を登録要求として認める。こうして、前記ステップ105を実行する際に、被呼側によって設定されたアクセスコードが当該登録要求の中になければ、被呼端末は登録を拒否した後、ステップ108〜ステップ110における方法に従って処理することができる。
【００５４】
登録要求が音声呼であれば、デュアルトーンマルチ周波数（Dual Tone Multiple Frequency）をデジタル信号に変換することにより、登録メッセージの伝送を実現することができる。
【００５５】
どんな登録要求方式が採用されるかにかかわらず、登録しようとする発呼番号が現在の発呼側の番号であれば、全部発呼番号識別方式を通じて当該登録する必要のある発呼番号を被呼端末に伝送することができる。登録しようとする発呼番号が現在の呼の発呼番号ではない場合にとって、登録要求がショートメッセージであれば、固定端末がショートメッセージを送信できない場合、発呼側がショートメッセージを送信できる移動端末を用いて固定端末の番号を被呼端末の発呼番号登録テーブルに登録することにより、当該固定端末によって開始された呼を被呼端末にアクセスすることができる。
【００５６】
上記ステップを通じて、本発明の目的が実現できる。
【００５７】
また、本発明方案では、更に、呼を開始できる発呼番号情報を格納するホワイトリストを本被呼端末に設定することができる。つまり、被呼加入者は自体の端末にホワイトリストを設定することができ、他の加入者によって開始される当該ホワイトリスト内の番号を発呼番号とした呼は、当該被呼端末にアクセスされることができる。このような設定を通じて、上記ステップ104で、被呼端末は当該呼が登録要求であるかどうかを判断する前に、まず、当該呼に対応する発呼番号が既にホワイトリストに格納されているかどうかを判断して、既に格納されていれば、ホワイトリストを検索することによって現在の呼を接続できると確定することができる。つまり、当該発呼番号をまた発呼番号登録テーブルに格納する必要がない。従って、当該呼を登録要求であると確定した際に、当該発呼番号を発呼番号登録テーブルに格納することを拒否することができ、例えば、直接に当該呼に対する処理を中止することができる。もちろん、被呼端末は当該呼が登録要求であることを確定した後、且つ被呼側によって設定されたアクセスコードが当該登録要求に含まれているかどうかを判断する前に、即ちステップ104と105の間に、現在の呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断することができ、格納されていれば、直接に登録を拒否し、現在の処理プロセスを終了する。
【００５８】
だから、ホワイトリストが設定された場合に、ホワイトリスト内の発呼番号は全部発呼番号登録テーブルに格納しない。上記ステップ108で、被呼端末は発呼番号登録テーブルを検索した後、当該登録テーブルに現在の呼に対応する発呼番号がなければ、当該呼に対して中止処理を行う。従って、ホワイトリストを設定した後、被呼端末は現在の呼に対応する発呼番号が発呼番号登録テーブルに格納されているかどうかを検索する必要だけではなく、ホワイトリストに当該発呼番号が格納されているかどうかも検索しなければならない。発呼番号登録テーブルとホワイトリストとのいずれかに当該発呼番号が格納されていれば、当該発呼番号に対応する呼を接続することができる。もちろん、実際では、ホワイトリストと発呼番号登録テーブルを一つのテーブルに合併して使用することもできる。
【００５９】
本発明方案では、更に本被呼端末に呼を開始できない発呼番号情報を格納するブラックリストを設定することもできる。つまり、被呼加入者は自体の端末にブラックリストを設定することができる。こうして、他の加入者が当該ブラックリスト内の番号を発呼番号として被呼端末に対して呼を開始する際に、被呼端末は当該呼のアクセスを拒否する。このような設定を通じて、被呼端末は呼を受信したとき、まず、当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断することができ、格納されていれば、後続の処理をする必要はなく、直接に現在の処理を終了してよい。つまり、前記ステップ104で、被呼端末は、当該呼が登録要求であるかどうかを判断する前に、まず、当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断すべきであり、既に格納されていれば、直接に現在の呼に対して中止処理を行うステップを実行し、格納されていなければ、判断することなど後続のステップを実行する。
【００６０】
ブラックリストが設定された場合に対して、また、他の処理方法がある。即ち、被呼端末は、予め設定したアクセスコードが当該登録要求に含まれているかどうかを判断する前に、即ちステップ105の前に、まず、当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、格納されていれば、当該発呼番号を発呼番号登録テーブルに格納せず、そうでなければ、後続の処理を実行する。
【００６１】
実際に、本発明方案では、被呼端末にホワイトリストとブラックリストを同時に設定することもできる。こうして、ある発呼番号がホワイトリストに既に格納されていれば、被呼端末は当該発呼番号に対応する呼を直接に接続することができ、ある発呼番号がブラックリストに既に格納されているとき、被呼端末は当該発呼番号を自体の発呼番号登録テーブルに格納してはいけない。
【００６２】
上記のように、上記ステップを実行する際に、またブラックリストとホワイトリストに基づいて相応の判断をすべきである。具体的には、まずブラックリストに対して判断していいし、まずホワイトリストに対して判断してもいい。以下、まずブラックリストに対して判断することを例として説明する。
【００６３】
ブラックリストが設定された場合に、被呼端末は呼を受信した後、即ちステップ104の前に、当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断して、ブラックリストに格納されていれば、直接に現在の処理プロセスを終了し、ブラックリストに格納されていなければ、更にホワイトリストに格納されているかどうかを判断する。ホワイトリストに基づいて判断する際に、被呼端末は、当該呼が登録要求であるかどうかを判断する前に、当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断することができ、既に格納されていれば、当該呼が登録要求であると確定したとき、当該発呼番号を発呼番号登録テーブルに格納することを拒否し、格納されていなければ、図1に示したプロセスに従って後続の処理を実行する。もちろん、ホワイトリストに基づいて判断する際に、被呼端末は、現在の呼を登録要求であると確定した後、且つ被呼側によって設定されたアクセスコードが当該登録要求に含まれているかどうかを判断する前に、即ちステップ104と105の間に、現在の呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断することもでき、格納されていれば、直接に登録を拒否し、現在の処理プロセスを終了し、格納されていなければ、同様に図1に示したプロセスに従って後続の処理を実行する。
【００６４】
もちろん、被呼端末は、現在の呼を登録要求であると確定した後、且つ被呼側によって設定されたアクセスコードが当該登録要求に含まれているかどうかを判断する前に、即ちステップ104と105の間に、更に当該呼に対応する発呼番号がホワイトリスト又はブラックリストに格納されているかどうかを判断してもよく、格納されていれば、直接に現在の処理プロセスを終了することができ、被呼端末はホワイトリストとブラックリストとのいずれかにも当該アクセスコードがないと確定したら、続いて後続の処理を実行する。
【００６５】
ホワイトリストとブラックリストが同時に設定された場合に対して、現在の呼が登録要求ではなければ、上記ステップ110で、現在の呼に対して中止処理を行う前に、被呼端末は当該呼に対応する発呼番号がホワイトリストに格納されているかどうかも判断すべきであり、ホワイトリストに格納されていれば、当該呼の正常なプロセスに従って処理し、そうでなければ、現在の呼に対して中止処理を行う。
【００６６】
本発明方案では、発呼番号情報を被呼端末の発呼番号登録テーブル、ホワイトリスト又はブラックリストの任意一つのテーブルだけに格納することができる。具体的には、被呼端末にホワイトリスト及び/又はブラックリストが設定されていると、この場合、被呼加入者がある発呼番号を被呼端末のホワイトリスト又はブラックリストに設定した後、被呼端末は当該発呼番号が当該発呼番号登録テーブルに格納されているかどうかを判断すべきであり、格納されていれば、当該発呼番号登録テーブルから当該発呼番号を削除する。被呼加入者がブラックリストに一つの発呼番号を設定したら、被呼端末はホワイトリストに当該発呼番号が格納されているかどうかをチェックするべきであり、格納されていれば、ホワイトリスト内の当該発呼番号を削除する。被呼加入者がホワイトリストに一つの発呼番号を設定したら、被呼端末はブラックリストに当該発呼番号が格納されているかどうかをチェックするべきであり、格納されていれば、ブラックリスト内の当該発呼番号を削除する。
【００６７】
以上、一つ目の方式、即ち発呼番号がアクセス呼識別子として設定される場合を説明した。以下、二つ目の方式を詳細に説明する。
【００６８】
二つ目の方式の実現手順は図2を参照し、具体的に下記のステップによって実現される。
【００６９】
ステップ201で、予め被呼端末にアクセスコードを設定する。
【００７０】
実際で、アクセスコードは被呼加入者によって設定される。自分の親戚や友達などが当該アクセスコードに基づいて自分といつでも連絡できるように、被呼加入者はアクセスコードを設定した後、当該アクセスコードを自分の親戚や友達などに通知することができる。
【００７１】
ステップ202で、発呼加入者は被呼端末に呼を開始する。
【００７２】
発呼側によって開始された呼はショートメッセージ、マルチメディアショートメッセージ、UUS又は音声呼などであり得る。発呼側によって開始された呼がショートメッセージ、マルチメディアショートメッセージ又はUUSであれば、これらの情報の内容にアクセスコードを書き込んでいい。例えば、「*#」をアクセスコードのスタート識別子として設定したら、その後の情報がアクセスコードである。
【００７３】
ステップ203〜205で、被呼端末は、呼を受信する際に、当該呼に自体のアクセスコードが含まれているかどうかを判断して、含まれていれば、当該呼の正常なプロセスに従って処理し、そうでなければ、当該呼に対して中止処理を行い、本処理プロセスを終了する。
【００７４】
発呼側によって開始された呼がショートメッセージ、マルチメディアショートメッセージ、UUS又は音声呼であり得るため、被呼端末が現在の呼に対して中止処理を行うことは、上記一つ目の方式と同じように、ショートメッセージ、マルチメディアショートメッセージ及びUUSに対しては、現在受信された情報を削除することであり、音声呼に対しては、現在の呼の接続を拒否し又は現在の呼を終了することである。
【００７５】
当該呼がショートメッセージ、マルチメディアショートメッセージ、UUSであれば、被呼端末は前の設定された識別子「*#」に基づいて現在の呼にアクセスコードがあるかどうかを判断することができる。
【００７６】
当該呼が音声呼であれば、被呼端末は当該呼を受信した後、まず、当該呼を接続し、又はつないで、アクセスコードを入力するように発呼側に指示する通知音を自動的に再生する。もちろん、ここで、予め被呼端末に再生音を設定する必要である。被呼側は設定した時間内に発呼側によって入力されたアクセスコードを受信しなかったら、当該呼にアクセスコードが含まれていないと認め、そうでなければ、今回の呼にアクセスコードが含まれていると確定する。ここで、当該呼の正常なプロセスに従って処理するとは、被呼端末が着信呼があると被呼側に通知することであり、具体的には、簡単な鳴動などで通知することができる。当該呼に対して中止処理を行うとは、今回の呼又は通話を直接に終了することである。
【００７７】
アクセスコードが他の呼情報によって伝送されると、被呼端末は直接に、呼に添付されている情報を通じて自体のアクセスコードが含まれているかどうかを判断することができ、判断された結果に基づいて呼を接続するか、それとも呼の接続を拒否するかを決める。それに相応して、当該呼の正常なプロセスに従って処理するとは、被呼端末が呼を接続し、着信呼があることを被呼側に通知することであり、具体的には、同様に簡単な鳴動で通知することができる。当該呼に対して中止処理を行うとは、今回の呼の接続を直接に拒否することを指している。
【００７８】
実際に、当該呼が音声呼である場合、被呼端末がアクセスコードの入力を発呼側に指示するとき、発呼側はデュアルトーンマルチ周波数（DTMF）信号、又は周波数偏移変調（FSK）信号、シグナリング又は音声を通じてアクセスコードを通信ネットワークに送信することができる。被呼端末にとっても上記四種の方式を通じて通信ネットワークからアクセスコードを受信することができる。被呼端末が発呼側によって送信される音声呼の受信機能を有すれば、被呼端末は直接に受信することができ、そうでなければ、当該発呼側によって送信される音声呼を通信ネットワークが被呼端末に受信され得るモードに変換する必要があり、また変換した後の呼情報を被呼端末に送信する。
【００７９】
以下、発呼側がDTMF信号を通じてアクセスコードを送信することを例として、その伝送手順を詳細に説明する。具体的に、発呼側はアクセスコードをDTMF信号を通じて、通信ネットワークを介して伝送することができる。通信ネットワークでの被呼交換機は当該DTMF信号を受信した後、DTMF信号をデジタル信号に変換する機能が当該被呼端末にあるかどうかを判断して、あれば、直接に当該DTMF信号を被呼端末に送信し、受信されたDTMF信号は被呼端末によってデジタル信号のアクセスコードに変換される。DTMF信号をデジタル信号に変換する機能が当該被呼端末になければ、当該被呼交換機は当該DTMF信号を被呼端末に識別され得るモードに変換し、次いで変換後の情報を被呼端末に送信する。被呼端末は当該モードに基づいてデジタル信号の変換を行う。
【００８０】
ここで、当該DTMF信号を被呼端末に識別され得るモードに変換する処理は、被呼交換機によって行われたが、実際では、発呼交換機によって完了されることもできる。例えば、固定端末がDTMF信号を通じて移動端末に送信するアクセスコードは、直接に発呼交換機によってデジタル信号に変換されることができる。次いで、通信ネットワークはアクセスコードを当該デジタル信号を通じて被呼端末に伝送することができる。
【００８１】
音声方式を通じてアクセスコードを伝送する場合に対して、被呼端末に音声識別機能があれば、被呼端末は発呼側に、音声方式を通じてアクセスコードを入力するように指示することができ、音声情報を受信した後で、被呼端末は発呼側によって入力されたアクセスコードを音声識別を通じて取得することができる。
【００８２】
他のいくつかの方式に対して、その処理手順が上記と類似しているため、ここでは、省略する。
【００８３】
もちろん、アクセスコードを取得した後、被呼端末は当該アクセスコードが自体のアクセスコードであるかどうかを更に判断する必要がある。
【００８４】
また、上記一つ目の方式と類似しているように、被呼端末にホワイトリスト又はブラックリストを設定することができ、ホワイトリストとブラックリストを同時に設定することもできる。
【００８５】
ホワイトリストが設定された場合に対して、被呼端末は発呼側によって開始された呼を受信する際に、まず、当該呼に対応する発呼番号がホワイトリストに格納されているかどうかを判断すべきであり、格納されていれば、正常なプロセスに従って当該呼を処理し、そうでなければ、また上記ステップ203における判断の手順を実行する。
【００８６】
ブラックリストが設定された場合に対して、被呼端末は発呼側によって開始された呼を受信する際に、まず、当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断すべきであり、格納されていれば、直接に当該呼に対して中止処理を行い、そうでなければ、また上記ステップ203における判断の手順を実行する。
【００８７】
ホワイトリストとブラックリストが同時に設定された場合に対して、被呼端末は、まず、当該呼に対応する発呼番号がブラックリストに格納されているかどうかを判断することができ、ブラックリストに当該発呼番号が格納されていれば、直接に当該呼に対して中止処理を行い、そうでなければ、また当該発呼番号がホワイトリストに格納されているかどうかを判断して、ホワイトリストに当該発呼番号が格納されていれば、直接に正常なプロセスに従って当該呼を処理し、ブラックリストとホワイトリストのいずれかにも格納されていなければ、上記ステップ203における判断の手順を実行する。
【００８８】
もちろん、ホワイトリストとブラックリストが同時に設定された場合に対して、被呼端末は、まず、ホワイトリストに基づいて判断することもでき、ホワイトリストに当該呼に対応する発呼番号が格納されていれば、直接に正常なプロセスに従って当該呼を処理し、そうでなければ、当該発呼番号がブラックリストに格納されているかどうかを判断して、ブラックリストに当該発呼番号が格納されていれば、直接に当該呼に対して中止処理を行い、ブラックリストとホワイトリストのいずれかにも格納されていなければ、前記ステップ203における判断の手順を実行する。
【００８９】
ホワイトリストとブラックリストが同時に設定された場合に対して、被呼加入者がブラックリストに一つの発呼番号を設定したら、被呼端末はホワイトリストに当該発呼番号が格納されているかどうかをチェックするべきであり、格納されていれば、ホワイトリスト内の当該発呼番号を削除する。被呼加入者がホワイトリストに一つの発呼番号を設定したら、被呼端末はブラックリストに当該発呼番号が格納されているかどうかをチェックするべきであり、格納されていれば、ブラックリスト内の当該発呼番号を削除する。
【産業上の利用可能性】
【００９０】
本発明に係る発呼及び被呼端末は移動端末、固定端末、携帯情報端末（ＰＤＡ）及び携帯型パーソナルコンピュータであっていいし、他の通信機能を有する端末であってもいいことが明らかである。
【００９１】
以上は、本発明方案の好ましい実施例に過ぎず、本発明の保護を限定するものではない。
【図面の簡単な説明】
【００９２】
【図１】本発明の一実施形態を実現したフローチャートである。
【図２】本発明のもう１つの実施形態を実現したフローチャートである。
【図１】
2008502236.tif 000003
【図２】
2008502236.tif 000004
【国際調査報告】
2008502236.tif 000005
2008502236.tif 000006
2008502236.tif 000007
2008502236.tif 000008