JP5527214B2 - 代替処理判定方法、代替処理判定装置、プログラム、及び携帯電話端末 - Google Patents

Description

本発明は、代替処理判定方法、代替処理判定装置、プログラム、及び携帯電話端末に係り、特に携帯電話端末に対する通信要求を処理する代替処理判定方法、代替処理判定装置、プログラム、及び携帯電話端末に関するものである。

近年、携帯電話が普及し、顧客との連絡を迅速に取れる等のメリットがあるため、営業活動等の多くのビジネスシーンでも利用されるようになってきている。しかし、携帯電話を自宅等に置いたまま出社してしまった場合等、携帯電話が手元にないときには、顧客等から着信があっても気づかないといった状況が発生しうる。

他方において、携帯電話には公私を問わず機密情報が保持されるようになっている。このような状況において、万が一携帯電話を公共の場等に置き忘れた場合、機密情報が漏洩し悪用される虞がある。

そこで、従来、携帯電話の遠隔ロックや遠隔ワイプといった機能（以下、「セキュリティ機能」という。）が提供されている。遠隔ロックは、遠隔的な操作により、携帯電話を一時的に操作不能とする機能である。また、遠隔ワイプは、遠隔的な操作により、携帯電話内に保持されている情報を消去する機能である。

当該セキュリティ機能によれば、携帯電話が他人の手に渡った場合であっても悪用される可能性を低減することができる。但し、当該セキュリティ機能によっても、携帯電話が手元にないときに着信に気づかないといった状況は発生しうる。

携帯電話が手元にないときの着信に対応するためのサービスとしては、留守番電話サービスや転送電話サービスがある。

留守番電話サービスは、電話に応答できないときに留守番電話センターが応答し、発信者のメッセージを録音しておくといったサービスである。留守番電話サービスの利用者は、録音されたメッセージを携帯電話や他の電話機等で聞くことができる。

転送電話サービスは、該当電話機への全ての着信を他の電話番号へ着信転送するといったサービスである。
特開２００８−１１２１８号公報 特開２００７−６００２３号公報 特開２００７−４７２３号公報

しかしながら、留守番サービスでは、録音メッセージの有無を確認するためには、利用者はその都度所定の操作を行わなければならないとう問題がある。また、全ての発信者がメッセージを残しているとは限らず、斯かる発信者からの着信の有無を知ることができないという問題がある。

一方、転送電話サービスでは、発信者の重要度等を問わず全ての着信が転送されてしまうという問題がある。また、転送電話サービスの設定解除（利用の解除）をし忘れると、携帯電話を取り戻した後も相変わらず着信が転送されてしまい、当該着信に気付かないという問題がある。

本発明は、上記の点に鑑みてなされたものであって、携帯電話端末が所有者の手元にない場合における当該携帯電話端末に対する通信要求に対して適切に対応することのできる代替処理判定方法、代替処理判定装置、プログラム、及び携帯電話端末の提供を目的とする。

上記目的を達成するために、コンピュータが実行する代替処理判定方法であって、発信側端末からの通信要求に応じ、前記通信要求に係る着信側識別情報及び当該発信側端末の発信側識別情報と、着信側識別情報と発信側識別情報との組み合わせごとに前記発信側識別情報に係る発信側端末からの通信要求に応じた処理を示す代替処理情報を管理する代替処理情報管理手段とに基づいて、当該通信要求を前記着信側識別情報に係る携帯電話端末に中継させる代わりに実行する代替処理を判定する代替処理判定手順を有する。

本発明によれば、携帯電話端末が所有者の手元にない場合における当該携帯電話端末に対する通信要求に対して適切に対応することができる。

第一の実施の形態における通信システム構成例を示す図である。 本発明の実施の形態における端末管理サーバのハードウェア構成例を示す図である。 本発明の実施の形態における携帯電話端末のハードウェア構成例を示す図である。 第一の実施の形態における通信システムの処理手順を説明するためのシーケンス図である。 第一の実施の形態における電話帳の構成例を示す図である。 第一の実施の形態における端末情報テーブルの構成例を示す図である。 第一の実施の形態の端末管理サーバによる代替処理の判定処理を説明するためのフローチャートである。 第一の実施の形態における不在モードの設定解除時の処理手順を説明するためのシーケンス図である。 第二の実施の形態における通信システム構成例を示す図である。 第二の実施の形態における通信システムの処理手順を説明するためのシーケンス図である。 第二の実施の形態における電話帳の構成例を示す図である。 第二の実施の形態における端末情報テーブルの構成例を示す図である。 第二の実施の形態の端末管理サーバによる代替処理の判定処理を説明するためのフローチャートである。 第三の実施の形態における通信システム構成例を示す図である。 第三の実施の形態における電話帳の構成例を示す図である。 第三の実施の形態における端末情報テーブルの構成例を示す図である。

符号の説明

１、２、３ 通信システム
１０、１０ａ、１０ｂ 端末管理サーバ
１１ 代替処理情報受信部
１２ 問い合わせ受信部
１３ 代替処理判定部
１４ 問い合わせ応答部
１５ 不在モード遠隔設定部
１６、１６ａ、１６ｂ 端末情報テーブル
１７ 遠隔ロック＆ワイプ要求部
２０、２０ａ、２０ｂ 携帯電話端末
２１ 電話帳編集部
２２ 不在モード設定部
２３ 代替処理情報アップロード部
２４ 着信部
２５ 着信処理判定部
２６ 着信処理実行部
２７、２７ａ、２７ｂ 電話帳
３０ 呼制御装置
３１ 通話要求受信部
３２ 問い合わせ部
３３ 処理実行部
４０ 発信側端末
５０ メールサーバ
５１ メール受信部
５２ 問い合わせ部
５３ 処理実行部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
２０１ ＲＯＭ
２０２ ＲＡＭ
２０３ 不揮発性ＲＡＭ
２０４ ＣＰＵ
２０５ 通信インタフェース装置
２０６ 表示装置
２０７ 入力装置
Ｂ バス

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態における通信システム構成例を示す図である。同図において、通信システム１は、端末管理サーバ１０、携帯電話端末２０、呼制御装置３０、及び発信側端末４０等を含む。

発信側端末４０は、携帯電話端末２０との通信網（電話網又はＩＰ（Internet Protocol）ネットワーク等を含む。）を介した通信（通話）における発信側の端末である。発信側端末４０の具体例としては、携帯電話端末、固定電話機、ＰＣ（Personal Computer）、及びＰＤＡ（Personal Digital Assistance）等が挙げられる。

携帯電話端末２０は、発信側端末４０との通信における着信側の携帯電話端末である。なお、携帯電話端末２０は、本実施の形態において着信側に位置するが、着信専用の端末に限定する趣旨ではない。

呼制御装置３０は、発信側端末４０と携帯電話端末２０との通信における呼制御を行う装置である。呼制御装置３０の具体例としては、交換機若しくはＶｏＩＰ（Voice over Internet Protocol）ゲートウェイ、又はこれらを含む複数の装置より構成されるシステム等が挙げられる。

端末管理サーバ１０は、発信側端末４０からの通話要求（第一の実施の形態における通信要求）に応じた処理を判定するコンピュータである。すなわち、呼制御装置３０は、発信側端末４０からの通話要求を受信すると、当該通話要求に応じた処理を端末管理サーバ１０に問い合わせる。呼制御装置３０は、当該問い合わせに対する端末管理サーバ１０からの応答に従い、通話要求に対する処理を実行する。

引き続き、図１を参照しつつ、各装置の機能構成について説明する。同図において、携帯電話端末２０は、電話帳編集部２１、不在モード設定部２２、代替処理情報アップロード部２３、着信部２４、着信処理判定部２５、及び着信処理実行部２６等を有する。

電話帳編集部２１は、携帯電話端末２０の操作者による指示入力に応じ、電話帳２７の編集を行う。電話帳２７は、一般的に電話帳又はアドレス帳と呼ばれる情報管理手段であり、エントリ（通信相手の候補）ごとに通信相手の名前、通信のための識別情報（電話番号、メールアドレス等）が登録されている。本実施の形態の電話帳２７は、更に、エントリごとに代替処理情報の登録が可能な形式とされている。代替処理情報とは、発信側端末４０からの通信要求に対して、携帯電話端末２０への中継処理の代わりに呼制御装置３０に実行させる処理の内容を示す情報をいう。

不在モード設定部２２は、携帯電話端末２０の「不在モード」の設定（ＯＮ）又は設定解除（ＯＦＦ）を行う。ここで、「不在モード」とは、携帯電話端末２０の所有者が携帯電話端末２０を利用できない状態であるか否かを示す設定情報をいう。不在モード「ＯＮ」は、所有者が携帯電話端末２０を利用できない状態に対応する。不在モード「ＯＦＦ」は、所有者が携帯電話端末２０を利用できる状態に対応する。不在モードの値（ＯＮ又はＯＦＦ）は、ＲＡＭ２０２又は揮発性ＲＡＭ２０３に記録される。

不在モードの設定及び設定解除は、入力装置２０７を構成するボタンの操作によって直接的に行われてもよいし、後述されるように端末管理サーバ１０からの遠隔操作によって行われてもよい。例えば、所有者が意識して携帯電話端末２０を置いていく場合、ボタンの操作によって不在モードに設定するのが便利である。一方、所有者が携帯電話端末２０を自宅等に置き忘れた場合等、所有者の手元に携帯電話端末２０が無い場合、遠隔操作によって不在モードに設定するのが便利である。

代替処理情報アップロード部２３は、携帯電話端末２０の不在モードが設定されると（ＯＮになると）、電話帳２７に含まれている代替処理情報と、携帯電話端末２０の電話番号とを端末管理サーバ１０にアップロード（送信）する。また、不在モードが解除されると（ＯＦＦになると）、アップロードした代替処理情報等の削除を端末管理サーバ１０に要求する。

着信部２４は、呼制御装置３０を介して受信される、発信側端末４０からの通話要求を着信する。着信処理判定部２５は、電話帳２７に含まれている代替処理情報に基づいて、着信部２４によって着信された通話要求に応じて実行すべき処理を判定する。着信処理実行部２６は、着信処理判定部２５によって判定された処理を実行する。

呼制御装置３０は、通話要求受信部３１、問い合わせ部３２、及び処理実行部３３等を有する。通話要求受信部３１は、発信側端末４０より発信される携帯電話端末２０への通話要求を直接的又は間接的に（中継装置を介して）受信する。問い合せ部３２は、通話要求の受信に応じて実行すべき処理を端末管理サーバ１０に問い合わせる。処理実行部３３は、問い合わせに対する判定結果に応じた処理を実行する。

端末管理サーバ１０は、代替処理情報受信部１１、問い合わせ受信部１２、代替処理判定部１３、問い合わせ応答部１４、不在モード遠隔設定部１５、及び端末情報テーブル１６等を有する。

代替処理情報受信部１１は、携帯電話端末２０の代替処理情報アップロード部２３よりアップロードされる代替処理情報等を受信し、端末情報テーブル１６に保存する。問い合わせ受信部１２は、呼制御装置３０の問い合わせ部３２からの問い合わせを受信する。代替処理判定部１３は、問い合わせ受信部１２による問い合わせの受信に応じ、端末情報テーブル１６に基づいて、通話要求に応じて実行すべき処理（代替処理）を判定する。問い合わせ応答部１４は、代替処理判定部１３による判定結果を呼制御装置３０の問い合わせ部３２に送信する。

不在モード遠隔設定部１５は、ユーザからの指示入力に応じ、携帯電話端末２０の不在モード設定部２２に対し不在モードの設定又は設定解除の要求を送信する。不在モード遠隔設定部１５に対する指示は、例えば、プッシュ式の電話機を介して入力される。又は、不在モード遠隔設定部１５は、Ｗｅｂインタフェースによってユーザからの指示入力を受け付けてもよい。この場合、不在モード遠隔設定部１５は、端末管理サーバ１０とネットワークを介して接続する非図示のＰＣ（Personal Computer）等におけるＷｅｂブラウザよりアクセス可能である。不在モード遠隔設定部１５は、Ｗｅｂブラウザに表示される不在モード設定用のＷｅｂページに対する入力に基づいて不在モードの設定又は設定解除の指示入力を受け付ける。

図２は、本発明の実施の形態における端末管理サーバのハードウェア構成例を示す図である。図２の端末管理サーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、ＣＰＵ１０４と、インタフェース装置１０５とを有する。

端末管理サーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。例えば、端末情報テーブル１６は、補助記憶装置１０２に格納される。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って端末管理サーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

図３は、本発明の実施の形態における携帯電話端末のハードウェア構成例を示す図である。同図において携帯電話端末２０は、ＲＯＭ２０１、ＲＡＭ２０２、不揮発性ＲＡＭ２０３、ＣＰＵ２０４、通信インタフェース装置２０５、表示装置２０６、及び入力装置２０７等を有する。

携帯電話端末２０での処理を実現するプログラムは、ＲＯＭ２０１又は不揮発性ＲＡＭ２０３にインストールされる。例えば、当該プログラムが、携帯電話端末２０の出荷時に予めインストールされる場合はＲＯＭ２０１に格納されるのが一般的である。また、当該プログラムがインターネット等を介してダウンロードされて利用される場合は、不揮発性ＲＡＭ２０３に格納される。なお、ＲＯＭ２０１や不揮発性ＲＡＭ２０３には、当該プログラム以外に、当該プログラムが用いる各種データも格納され得る。例えば、電話帳２７は、不揮発性ＲＡＭ２０３に格納される。

ＲＡＭ２０２は、プログラムの起動指示があった場合に、ＲＯＭ２０１又は不揮発性ＲＡＭ２０３からプログラムを読み出して格納する。ＣＰＵ２０４は、ＲＡＭ２０２に格納されたプログラムに従って携帯電話端末２０に係る機能を実行する。通信インタフェース装置２０５は、通話や電子メールの送受信等を行うための部品であり、例えば、アンテナや無線通信モジュール等が含まれる。表示装置２０６は、液晶パネル等の表示用のモニタである。入力装置２０７は、ボタン等で構成され、ユーザからの操作指示を受け付けるために用いられる。

以下、通信システム１の処理手順について説明する。図４は、第一の実施の形態における通信システムの処理手順を説明するためのシーケンス図である。

まず、携帯電話端末２０の所有者による指示入力に応じ、電話帳編集部２１は、電話帳２７に対し、代替処理情報等を登録する（Ｓ１１）。

図５は、第一の実施の形態における電話帳の構成例を示す図である。同図において、電話帳２７は、エントリごとに名前、電話番号、及び代替処理情報等の登録が可能とされている。

代替処理情報としては、例えば、ユーザ定義若しくはシステム固定の音声ガイダンスの再生、特定のメールアドレスへの着信の通知、圏外応答、公共モード応答、特定電話番号への着信転送等の定義が可能である。例えば、同図では「０ＡＡ−ＡＡＡ−ＡＡＡＡ」という電話番号（発信側番号）のＡさんからの着信に関しては、ユーザ設定ガイダンスＡ（ユーザ設定可能な音声ガイダンスのうちの一つ（ガイダンスＡ）の音声ガイダンス）による応答を行った後、所有者の携帯電話端末以外のメールアドレス（例えば、職場のＰＣ（Personal Computer）におけるメールアドレス：ａａａ＠ｘｘｘ．ｘｘｘ．ｘｘｘ）に対して着信があったことを通知するといった代替処理情報が登録されている。また、「０ＢＢ−ＢＢＢ−ＢＢＢＢ」という電話番号（発信側番号）のＢさんからの着信に関しては、ユーザ設定ガイダンスＢ（ユーザ設定可能な音声ガイダンスのうちの一つ（ガイダンスＢ）の音声ガイダンス）による応答を行うといった代替処理情報が登録されている。更に、「０ＣＣ−ＣＣＣ−ＣＣＣＣ」という電話番号（発信側番号）のＢさんからの着信に関しては、システム既定ガイダンス（予めシステムにおいて定められている音声ガイダンス）による応答を行うといった代替処理情報が登録されている。

なお、同図において代替処理情報は、便宜上自然言語によって定義されているが、実際はプログラムによる処理に適した記述形式（例えば、所定の文法のスクリプト言語、処理内容のコード番号等）によって定義するとよい。

その後、携帯電話端末２０のボタン操作により、又は、端末管理サーバ１０の不在モード遠隔設定部１５からの要求に応じ、不在モード設定部２２は、携帯電話端末２０の不在モードをＯＮにする（Ｓ１２）。当該ステップは、ステップＳ１１とは非同期に実行される。なお、端末管理サーバ１０の不在モード遠隔設定部１５からの要求に応じて不在モードに設定される場合の具体例としては次のようなケースが挙げられる。例えば、携帯電話端末２０の所有者が自宅等に携帯電話端末２０を置き忘れ、職場の電話機又はＰＣ等を介して不在モード遠隔設定部１５に対して不在モードの設定指示を入力するといったケースである。

不在モードがＯＮに設定されたことに応じ、代替処理情報アップロード部２３は、電話帳２７の中で代替処理情報が登録されているエントリについて、当該代替処理情報と電話番号とを端末管理サーバ１０にアップロード（送信）する（Ｓ１３）。この際、代替処理情報アップロード部２３は、例えば、ＲＯＭ２０１又は不揮発性ＲＡＭ２０３に記録されている、携帯電話端末２０の電話番号も端末管理サーバ１０にアップロード（送信）する。当該アップロードの手順は、ＯＭＡ（Open Mobile Alliance）において標準化が進んでいるＯＭＡ−ＤＭ（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）のプロトコルを用いてもよい。この場合、端末管理サーバ１０はＯＭＡ−ＤＭサーバを拡張したものとして実現してもよい。

続いて、端末管理サーバ１０の代替処理情報受信部１１は、携帯電話端末２０の電話番号と、電話帳２７のエントリごとの電話番号及び代替処理情報等を受信し、受信された情報とを端末情報テーブル１６に保存する（Ｓ１４）。

図６は、第一の実施の形態における端末情報テーブルの構成例を示す図である。同図に示されるように、端末情報テーブル１６は、着信側番号と発信側番号との組み合わせに応じて代替処理情報を管理するテーブルである。同図では、図５に示される電話帳２７における代替処理情報等が登録された状態が示されている。着信側番号には、携帯電話端末２０の電話番号（０９０−ｘｘｘｘ−ｘｘｘｘ）が登録される。発信側番号には、電話帳２７において代替処理情報が登録されている電話番号が登録される。代替処理情報には、電話帳２７に登録されている代替処理情報が、電話番号（発信側番号）との関連付けが維持された状態で登録される。

続いて、代替処理情報受信部１１は、端末情報テーブル１６に対する代替処理情報等の保存の成否を示す情報（保存結果）を携帯電話端末２０の代替処理情報アップロード部２３に返信する（Ｓ１５）。保存結果において保存の成功が示されている場合、代替処理情報アップロード部２３は、代替処理情報のアップロードに成功したことを不揮発性ＲＡＭ２０３に記録しておく。保存結果において保存の失敗が示されている場合は、代替処理情報アップロード部２３は、適当な時間間隔を置いて、アップロードが成功するまでリトライを行ってもよい。

他方において、以上の処理とは非同期に（無関係に）、携帯電話端末２０に対する通話要求が発信者側端末４０より発信される（Ｓ１６）。当該通話要求は、呼制御装置３０の通話要求受信部３１によって受信される。続いて、問い合わせ部３２は、当該通話要求に対して実行すべき処理の問い合わせを端末管理サーバ１０の問い合わせ受信部１２に送信する（Ｓ１７）。この際、問い合わせ部３２は、通話要求に含まれている着信側番号（携帯電話端末２０の電話番号）と発信側番号（発信側端末４０の電話番号）とを問い合わせのパラメータとして問い合わせ受信部１２に送信する。なお、呼制御装置３０には、予め端末管理サーバ１０の問い合わせ受信部１２と通信するための識別情報（ＩＰアドレス、ＵＲＬ（Uniform Resource Locator）等）が登録されている。

続いて、代替処理判定部１３は、問い合わせのパラメータとして受信された着信側番号及び発信側番号を端末情報テーブル１６に当てはめることにより、当該通話要求に対する代替処理を判定する（Ｓ１８）。続いて、問い合わせ応答部１４は、代替処理判定部１３による判定結果を呼制御装置３０の問い合わせ部３２に返信する（Ｓ１９）。

続いて、呼制御装置３０の処理実行部３３は、問い合わせ部３２によって受信された判定結果に応じた処理を実行する。当該判定結果において代替処理が示されている場合（代替処理有りの場合）、処理実行部３３は、当該代替処理を実行する。したがって、この場合、通話要求が携帯電話端末２０に中継される代わりに呼制御装置３０によって代替処理が実行される。

一方、当該判定結果において代替処理が示されていない場合（代替処理無しの場合）、処理実行部３３は、通話要求を携帯電話端末２０に中継する（Ｓ２１）。携帯電話端末２０の着信部２４は当該通話要求を着信する。続いて、着信処理判定部２５は、不在モードが設定されているか否かと、通話要求に含まれている発信側番号及び電話帳２７とに基づいて、着信に応じて実行すべき処理を判定する（Ｓ２２）。すなわち、不在モードがＯＮである場合、着信処理判定部２５は、当該通話要求に含まれている発信側番号と同一の電話番号に対して登録されている代替処理情報を電話帳２７より取得し、当該代替処理情報に基づいて実行すべき処理を判定する。なお、不在モードがＯＦＦである場合、着信処理判定部２５は、通常の着信処理を実行すべきと判定する。

続いて、着信処理実行部２６は、着信処理判定部２５によって判定された処理を実行する（Ｓ２３）。すなわち、不在モードがＯＮであり、かつ、電話帳２７において発信側番号に対して代替処理情報が登録されていた場合、着信処理実行部２６は、当該代替処理を実行する。一方、不在モードがＯＦＦである場合、又は不在モードはＯＦＦであるが発信側番号に対する代替処理情報が登録されていない場合、着信処理実行部２６は、通常の着信処理の実行を制御する。

なお、端末管理サーバ１０において代替処理が無いと判定されたにも拘わらず、携帯電話端末２０において代替処理が有ると判定されるケースとしては、電話帳２７に登録された代替処理情報が端末管理サーバ１０にアップロードされていない場合が挙げられる。例えば、携帯電話端末２０に対して不在モードの設定指示が行われた後、電話帳２７に登録されている代替処理情報がアップロード中の場合である。

このように、携帯電話端末２０において代替処理を実行することで、代替処理情報のアップロードが完了していない状態においても代替処理を実現することができる。

続いて、ステップＳ１８における代替処理の判定処理について更に詳しく説明する。図７は、第一の実施の形態の端末管理サーバによる代替処理の判定処理を説明するためのフローチャートである。

ステップＳ１０１において、問い合わせ受信部１２は、呼制御装置３０より着信側番号及び発信側番号を含む問い合わせを受信する。続いて、代替処理判定部１３は、着信側番号に対応するエントリ（以下、「カレントエントリ」という。）を端末情報テーブル１６より検索する（Ｓ１０２）。例えば、着信側番号が「０９０−ｘｘｘｘ−ｘｘｘｘ」の場合、図６の端末情報テーブル１６より、当該着信側番号が登録されているエントリが検索される。

カレントエントリが検索された場合（Ｓ１０３でＹｅｓ）、代替処理判定部１３は、カレントエントリより、問い合わせに係る発信側番号と一致する発信側番号を含むサブエントリ（以下、「カレントサブエントリ」という。）を検索する（Ｓ１０４）。例えば、問い合わせに係る発信側番号が「０ＡＡ−ＡＡＡ−ＡＡＡＡ」の場合、当該発信側番号と一致する発信側番号を含むサブエントリが検索される。

カレントサブエントリが検索された場合（Ｓ１０５でＹｅｓ）、代替処理判定部１３は、カレントサブエントリより代替処理情報を取得する（Ｓ１０６）。代替処理情報が取得された場合（カレントサブエントリに代替処理情報が登録されていた場合）（Ｓ１０７でＹｅｓ）、代替処理判定部１３は、取得された代替処理情報によって示される代替処理を実行すべき処理と判定する（Ｓ１０８）。

一方、着信側番号に対応するエントリが無い場合（Ｓ１０３でＮｏ）、発信側番号に対応するサブエントリが無い場合（Ｓ１０５でＮｏ）、又はカレントサブエントリに代替処理情報が登録されていない場合（Ｓ１０７でＮｏ）、代替処理判定部１３は、通話要求の中継を実行すべき処理と判定する（Ｓ１０９）。

ステップＳ１０８又はステップＳ１０９に続き、問い合わせ応答部１４は、代替処理判定部１３により判定された処理を示す情報を呼制御装置３０の問い合わせ部３２に返信する（Ｓ１１０）。

その後、代替処理判定部１３によって判定された処理が、呼制御装置３０の処理実行部３３によって実行される。例えば、着信側番号が「０９０−ＸＸＸ−ＸＸＸＸ」であり、発信側番号が「０ＡＡ−ＡＡＡ−ＡＡＡＡ」の場合、ユーザ設定ガイダンスＡによる音声ガイダンスによる応答が行われた後、メールアドレス（ａａａ＠ｘｘｘ．ｘｘｘ．ｘｘｘ）に対して着信を通知する電子メールが送信される。

続いて、図８は、第一の実施の形態における不在モードの設定解除時の処理手順を説明するためのシーケンス図である。同図の処理手順は、例えば、携帯電話端末２０の所有者が、携帯電話端末２０を手元に取り戻した場合等において実行される。

携帯電話端末２０のボタン操作により、又は、端末管理サーバ１０の不在モード遠隔設定部１５からの要求に応じ、不在モード設定部２２は、携帯電話端末２０の不在モードをＯＦＦにする（Ｓ３１）。不在モードがＯＦＦに設定されたことに応じ、代替処理情報アップロード部２３は、携帯電話端末２０に係る代替処理情報の削除要求を端末管理サーバ１０に送信する（Ｓ３２）。この際、代替処理情報アップロード部２３は、携帯電話端末２０の電話番号を削除要求のパラメータとして端末管理サーバ１０に送信する。

端末管理サーバ１０の代替処理情報受信部１１は、代替処理情報の削除要求を受信すると、当該削除要求に含まれている電話番号を着信側番号とするエントリを端末情報テーブル１６より削除する（Ｓ３３）。これにより、以降における発信側端末４０から携帯電話端末２０に対する通話要求については、代替処理は実行されず携帯電話端末２０に中継される。また、携帯電話端末２０においても、不在モードはＯＦＦとなっているため、当該通話要求に対し通常の着信処理が行われる。

なお、代替処理情報の削除要求に応じ、代替処理情報受信部１１は、当該削除要求に係るエントリを端末情報テーブル１６から完全に削除するのではなく、無効であることを示す情報（フラグ）を当該エントリに記録するようにしてもよい。代替処理判定部１３は、無効とされたエントリは無視して代替処理の判定を行えばよい。

また、この場合、代替処理情報アップロード部２３は、再度、不在モードがＯＮとなったときは必ずしも代替処理情報を再度送信しなくてもよい。すなわち、以前の代替処理情報のアップロードが成功したことが不揮発性ＲＡＭ２０３に記録されているときは、代替処理情報アップロード部２３は、代替処理情報を有効とする要求を端末管理サーバ１０に送信してもよい。代替処理情報受信部１１は、当該要求に応じ、無効とされているエントリを再度有効化すればよい。

上述したように、第一の実施の形態によれば、携帯電話端末２０を不在モードに設定することで、予め電話帳２７において電話番号ごとに登録された代替処理を呼制御装置３０に実行させることができる。したがって、例えば、顧客等、重要な相手の電話番号には着信を通知する電子メールの送信や着信の転送等を代替処理として定義しておくことで、所有者は、携帯電話端末２０を置き忘れてしまった場合であっても重要な連絡があったことを知ることができる。また、重要でない相手については、音声ガイダンスによる応答を代替処理として定義しておくことで、着信を通知する電子メールや着信の転送等が不要に増加するのを防止することができる。

また、不在モードに設定されたタイミングで電話帳２７に登録されている代替処理情報を端末管理サーバ１０にアップロードすることで、予め端末管理サーバ１０に設定しておく場合に比べ、最新のユーザの意向に沿った動作を実現することができる。

なお、本実施の形態では、呼制御装置３０で代替処理が実行される場合、発信側端末２０からの通話要求は、代替処理の内容によっては必ずしも携帯電話端末２０ａに中継されるとは限らない。しかし、代替処理を実行した上で、通話要求を携帯電話端末２０へ常に中継するようにしてもよい。この場合、不要な着信の転送を回避するため、転送電話サービスの利用は解除しておくとよい。

また、本実施の形態では、代替処理情報を登録可能なように電話帳２７を拡張した例を示したが、携帯電話端末２０における代替処理情報の登録先は、電話帳２７とは別の管理手段であってもよい。但し、使い慣れた電話帳２７を利用することで、利用者の操作負担を軽減することができる。

また、不在モードの設定は、例えば、携帯電話端末２０の電源オフの操作時に行われてもよい。又は、携帯電話端末２０が通話圏外であることを示すセンサ（例えば、ＲＦＩＤ（Radio Frequency Identification）等）の存在を検知し、当該検知に応じて不在モードの設定を行ってもよい。

また、端末管理サーバ１０と呼制御装置３０とはそれぞれ別個の装置として記載したが、呼制御装置３０内に端末管理サーバ１０の機能が実装されてもよい。

続いて、第二の実施の形態について説明する。第二の実施の形態では第一の実施の形態と異なる点について説明する。したがって、特に言及しない点については、第一の実施の形態と同様でよい。

図９は、第二の実施の形態における通信システム構成例を示す図である。図９中、図１と同一部分には同一符号を付し、その説明は省略する。

同図において、通信システム２は、端末管理サーバ１０ａ、携帯電話端末２０ａ、呼制御装置３０、及び発信側端末４０等を含む。

端末管理サーバ１０ａは、第一の実施の形態の端末管理サーバ１０とほぼ同様の機能構成を有する。但し、端末管理サーバ１０ａは、不在モード遠隔設定１５の代わりに遠隔ロック＆ワイプ要求部１７を有する。また、端末テーブル１６ａは、端末テーブル１６とは一部異なる構成を有する。

遠隔ロック＆ワイプ要求部１７は、遠隔ロックや遠隔ワイプの実行を携帯電話端末２０ａに要求する。ロックとは、携帯電話端末の操作が制限される状態にすることをいう。したがって、遠隔ロックとは、遠隔から携帯電話端末のロックを行うことをいう。ワイプとは、電話帳等、携帯電話端末に保持されているデータの消去することをいう。したがって、遠隔ワイプとは、遠隔からワイプを行うことをいう。本実施の形態における遠隔ロック及び遠隔ワイプのいずれについても、携帯電話会社によって提供されているサービスと同様のものでよい。

携帯電話端末２０ａは、第一の実施の携帯電話端末２０とほぼ同様の機能構成を有する。但し、携帯電話端末２０ａは、不在モード設定部２２の代わりに遠隔ロック＆ワイプ実行部２８を有する。また、電話帳２７ａは第一の実施の形態の電話帳２７とは一部異なる構成を有する。

遠隔ロック＆ワイプ実行部２８は、遠隔ロック＆ワイプ要求部１７からの要求に応じ、携帯電話端末２０ａに対してロック又はワイプを行う。なお、遠隔ロック＆ワイプ要求部１７と遠隔ロック＆ワイプ実行部２８との間の通信には、ＯＭＡ−ＤＭで標準化の進んでいる遠隔ロック＆ワイプのプロトコルを用いてもよい。

以下、通信システム２の処理手順について説明する。図１０は、第二の実施の形態における通信システムの処理手順を説明するためのシーケンス図である。

まず、携帯電話端末２０ａの所有者による指示入力に応じ、電話帳編集部２１は、電話帳２７ａに対し、代替処理情報等を登録する（Ｓ２１１）。

図１１は、第二の実施の形態における電話帳の構成例を示す図である。同図において、電話帳２７ａは、エントリごとに名前、電話番号、ロック時代替処理情報、及びワイプ時代替処理情報等の登録が可能とされている。ロック時代替処理情報は、携帯電話端末２０ａが遠隔ロックされているときの代替処理情報である。また、ワイプ時代替処理情報は、携帯電話端末２０ａが遠隔ワイプされているときの代替処理情報である。すなわち、第二の実施の形態では、携帯電話端末２０ａが遠隔ロックされている場合と遠隔ワイプされている場合とを区別して代替処理情報を登録することができる。したがって、ステップＳ２１１では、ロック時代替処理情報及びワイプ時代替処理情報のそれぞれが登録されうる。但し、ロック時代替処理情報及びワイプ時代替処理情報のいずれか一方のみが登録されてもよいし、双方が登録されなくてもよい。また、遠隔ロック時と遠隔ワイプ時のそれぞれの代替処理情報は同じものが登録されてもよい。なお、以下において、ロック時代替処理情報及びワイプ時代替処理情報を総称する場合、単に「代替処理情報」という。

例えば、同図では、遠隔ロック時における「０ＡＡ−ＡＡＡ−ＡＡＡＡ」という電話番号（発信側番号）のＡさんからの着信に関しては、ユーザ設定ガイダンスＡ（ユーザ設定可能な音声ガイダンスのうちの一つ（ガイダンスＡ）の音声ガイダンス）による応答を行った後、所有者の携帯電話端末以外のメールアドレス（例えば、職場のＰＣ（Personal Computer）におけるメールアドレス：ａａａ＠ｘｘｘ．ｘｘｘ．ｘｘｘ）に対して着信があったことを通知するといったロック時代替処理情報が登録されている。また、遠隔ワイプ時における「０ＡＡ−ＡＡＡ−ＡＡＡＡ」からの着信に関しては、「０ＸＸ−ＸＸＸＸ−ＸＸＸＸ」という電話番号に転送するといったワイプ時代替処理情報が登録されている。

続いて、携帯電話端末２０ａの所有者等によって端末管理サーバ１０ａの遠隔ロック＆ワイプ要求部１７に対して遠隔ロック又は遠隔ワイプの実行指示が入力される。当該実行指示応じ、遠隔ロック＆ワイプ要求部１７は、遠隔ロック又は遠隔ワイプの実行要求を携帯電話端末２０ａに送信する（Ｓ２１２）。また、遠隔ロック＆ワイプ要求部１７は、当該実行要求の送信前（送信後でもよい）に、遠隔ロック又は遠隔ワイプの対象とされた電話番号のエントリを端末情報テーブル１６ａに作成し、当該エントリにロック状態とを登録する。ここで、ロック状態とは、携帯電話端末２０ａの対する遠隔革的な操作（特に、安全性を確保するための操作）の種別を示す情報の具体例であり、ロック又はワイプがされているか否かを示す情報である。

なお、遠隔ロック＆ワイプ要求部１７に対する遠隔ロック又は遠隔ワイプの実行指示は、第一の実施の形態の不在モード遠隔設定部１５に対する場合と同様に、プッシュ式の電話機やＷｅｂインタフェースを介して入力されてもよい。また、一般的に提供されている遠隔ロックサービス又は遠隔ワイプサービスに従った方法によって行われてもよい。また、携帯電話端末２０ａに対する遠隔ロック又は遠隔ワイプの実行要求は、端末管理サーバ１０ａ以外の他の装置より送信されてもよい。この場合、端末管理サーバ１０ａは、遠隔ロック＆ワイプ要求部１７を有していなくてもよい。

遠隔ロック＆ワイプ実行部２８は、遠隔ロック又は遠隔ワイプの実行要求を受信すると、当該実行要求が受信されたことを代替処理情報アップロード部２３に通知する。当該通知に応じ、代替処理情報アップロード部２３は、電話帳２７ａにおいて代替処理情報が登録されているエントリについて、当該代替処理情報と電話番号とを端末管理サーバ１０ａにアップロード（送信）する（Ｓ２１３）。この際、代替処理情報アップロード部２３は、例えば、ＲＯＭ２０１又は不揮発性ＲＡＭ２０３に記録されている、携帯電話端末２０ａの電話番号も端末管理サーバ１０ａにアップロード（送信）する。

続いて、端末管理サーバ１０ａの代替処理情報受信部１１は、携帯電話端末２０ａの電話番号と、電話帳２７ａのエントリごとの電話番号及び代替処理情報等を受信し、受信された情報を端末情報テーブル１６ａに保存する（Ｓ２１４）。

図１２は、第二の実施の形態における端末情報テーブルの構成例を示す図である。同図に示されるように、端末情報テーブル１６ａは、着信側番号ごとにロック状態を管理し、着信側番号と発信側番号との組み合わせにとごとにロック時代替処理情報及びワイプ時代替処理情報を管理するテーブルである。同図では、図１１に示される電話帳２７ａにおける代替処理情報等が登録された状態が示されている。遠隔ロックが行われている場合、ロック状態には「ロック」が登録される。遠隔ワイプが行われている場合「ワイプ」が登録される。なお、ロック状態は、ステップＳ２１２の段階（遠隔ロック又は遠隔ワイプ時）において、遠隔ロック＆ワイプ要求部１７によって登録される。発信側番号には、電話帳２７ａにおいて代替処理情報が登録されている電話番号が登録される。ロック時代替処理情報には、電話帳２７ａに登録されているロック時代替処理情報が、電話番号（発信側番号）との関連付けが維持された状態で登録される。ワイプ時代替処理情報には、電話帳２７ａに登録されているワイプ時代替処理情報が、電話番号（発信側番号）との関連付けが維持された状態で登録される。

なお、ステップＳ２１３において、代替処理情報アップロード部２３は、代替処理情報と共に携帯電話端末２０ａのロック状態をアップロードするようにしてもよい。そうすることにより、遠隔ロック又は遠隔ワイプの実行要求が端末管理サーバ１０ａ以外の装置より行われる場合であっても、代替処理情報受信部１１は、携帯電話端末２０ａのロック状態を端末管理テーブル１６ａに登録することができる。

続いて、代替処理情報受信部１１は、端末情報テーブル１６ａに対する代替処理情報等の保存の成否を示す情報（保存結果）を携帯電話端末２０ａの代替処理情報アップロード部２３に返信する（Ｓ２１５）。保存結果において保存の成功が示されている場合、代替処理情報アップロード部２３は、代替処理情報のアップロードに成功したことを不揮発性ＲＡＭ２０３に記録しておく。保存結果において保存の失敗が示されている場合は、代替処理情報アップロード部２３は、適当な時間間隔を置いて、アップロードが成功するまでリトライを行ってもよい。但し、リトライ中に、遠隔ロック＆ワイプ要求部１７より遠隔ロック又は遠隔ワイプの停止（解除）要求を受信した場合、代替処理情報アップロード部２３は、当該リトライを中止する。

続いて、携帯電話端末２０ａの遠隔ロック＆ワイプ実行部２８は、携帯電話端末２０ａに対してロック又はワイプを行う（Ｓ２１６）。ワイプの場合は、電話帳２７ａの内容も消去される。また、ワイプが行われる場合、通常、ロックも行われる。なお、遠隔ロック＆ワイプ実行部２８によるロック又はワイプの実行は、ステップＳ２１３において、代替処理情報等のアップロードの完了に応じて実行されてもよい。

続いて、ステップＳ２１７以降は、第一の実施の形態（図４）のステップＳ１６以降と同様である。但し、端末管理サーバ１０ａの代替処理判定部１３は、呼制御装置３０の問い合わせ部３２からの実行すべき処理の問い合わせに応じ（Ｓ２１８）、ロック状態であるのか、ワイプ状態（ロック＆ワイプ状態）であるのかを加味して代替処理を判定する（Ｓ２１９）。

斯かる代替処理の判定処理について詳細に説明する。図１３は、第二の実施の形態の端末管理サーバによる代替処理の判定処理を説明するためのフローチャートである。

ステップＳ３０１からＳ３０５までは、図４のステップＳ１０１からＳ１０５と同様でよいため、ここでの説明は省略する。

ステップＳ３０５に続いてステップＳ３０６に進み、代替処理判定部１３は、カレントエントリに登録されているロック状態の値を判定する。ロック状態が「ロック」の場合、代替処理判定部１３は、カレントサブエントリよりロック時代替処理情報を取得する（Ｓ３０７）。ロック時代替処理情報が取得された場合（カレントサブエントリにロック時代替処理情報が登録されていた場合）（Ｓ３０８でＹｅｓ）、代替処理判定部１３は、取得されたロック時代替処理情報によって示される代替処理を実行すべき処理と判定する（Ｓ３０９）。一方、カレントサブエントリにロック時代替処理情報が登録されていない場合（Ｓ３０８でＮｏ）、代替処理判定部１３は、通話要求の中継を実行すべき処理と判定する（Ｓ３１０）。

また、ロック状態が「ワイプ」の場合、代替処理判定部１３は、カレントサブエントリよりワイプ時代替処理情報を取得する（Ｓ３１１）。ワイプ時代替処理情報が取得された場合（カレントサブエントリにワイプ時代替処理情報が登録されていた場合）（Ｓ３１２でＹｅｓ）、代替処理判定部１３は、取得されたワイプ時代替処理情報によって示される代替処理を実行すべき処理と判定する（Ｓ３１３）。一方、カレントサブエントリにワイプ時代替処理情報が登録されていない場合（Ｓ３１２でＮｏ）、代替処理判定部１３は、予め定められている所定の処理（以下、「システム固定処理」という。）を実行すべき処理と判定する（Ｓ３１４）。システム固定処理は、システム固定の音声ガイダンスの再生、留守番電話サービスへの転送等、少なくとも着信側の端末（携帯電話端末２０ａ）に着信させないような処理が挙げられる。

また、着信側番号に対応するエントリが無い場合（Ｓ３０３でＮｏ）、代替処理判定部１３は、通話要求の中継を実行すべき処理と判定する（Ｓ３１５）。また、発信側番号に対応するサブエントリが無い場合（Ｓ３０５でＮｏ）、代替処理判定部１３は、カレントエントリに登録されているロック状態の値を判定する（Ｓ３１６）。ロック状態が「ロック」の場合、代替処理判定部１３は、通話要求の中継を実行すべき処理と判定する（Ｓ３１７）。一方、ロック状態が「ワイプ」の場合、代替処理判定部１３は、システム固定処理を実行すべき処理と判定する（Ｓ３１８）。

ステップＳ３０９、Ｓ３１０、Ｓ３１３、Ｓ３１４、Ｓ３１５、Ｓ３１７、又はＳ３１８に続き、問い合わせ応答部１４は、代替処理判定部１３により判定された処理を示す情報を呼制御装置３０の問い合わせ部３２に返信する（Ｓ３１９）。

なお、遠隔ロックが解除された場合、不在モードがＯＦＦとされた場合と同様の処理手順（図８参照）が実行される。したがって、遠隔ロックの解除後は、発信側端末４０からの通話要求は、通常通り携帯電話端末２０ａに中継される。

上述したように、第二の実施の形態によれば、遠隔ロック又は遠隔ワイプと連携して代替処理情報等のアップロードを携帯電話端末２０ａに実行させることができる。ここで、遠隔ロックや遠隔ワイプは、携帯電話端末が手元に無い場合に携帯電話端末の安全性を確保するために行われる操作である。したがって、所有者によって明示的に不在モードの設定が行われなくても、携帯電話端末２０ａは所有者の手元に無いことを自動的に検知し代替処理情報等のアップロードを行うことができる。その結果、携帯電話端末２０ａの所有者に対し、重要な通話要求が有ったことを呼制御装置３０に通知させることができる。

また、代替処理情報は、予め端末管理サーバ１０ａに管理されているのではなく、遠隔ロック時等に携帯電話端末２０ａよりアップロードされる。したがって、携帯電話端末２０ａが所有者の手元にないことが検知された時点の代替処理情報に基づいて代替処理の判定を行わせることができる。

更に、ワイプ時にＵＳＩＭ（Universal Subscriber Identity Module）の一時利用停止手続き等を併用することで携帯電話端末２０ａの不正利用をより効果的に防止するようにしてもよい。

なお、ロック状態が「ワイプ」の場合であって、ワイプ時代替処理情報が登録されていない場合にシステム固定処理を実行させるのは、ワイプ後の携帯電話端末２０ａに新たな情報が蓄積されるのを防止するためのである。例えば、ワイプ後において発信側端末４０からの通話要求が携帯電話端末２０ａに中継された場合、携帯電話端末２０ａには、新たな着信履歴が記録されてしまう。そうすると、当該着信履歴に基づいて発信側端末４０の電話番号が盗まれる等、好ましくない状況が発生しうる。斯かる状況の発生を防止するため、本実施の形態ではワイプ後において、携帯電話端末２０ａに影響を与えないような処理を実行するようにしているのである。

続いて、第三の実施の形態について説明する。第三の実施の形態では第一又は第二の実施の形態と異なる点について説明する。したがって、特に言及しない点については、第一又は第二の実施の形態と同様でよい。

図１４は、第三の実施の形態における通信システム構成例を示す図である。図１４中、図１又は図９と同一部分には同一符号を付し、その説明は省略する。

第三の実施の形態において、発信側端末４０と携帯電話端末２０ｂとの間の通信処理の対象は電子メールである。したがって、図１４における通信システム３は、呼制御装置３０の代わりにメールサーバ５０を含む。但し、呼制御装置３０も混在していてもよい。

メールサーバ５０は、ＳＭＴＰ（Simple Mail Transfer Protocol）等のプロトコルに基づいて、電子メールを発信側から着信側に対して中継するコンピュータである。同図においてメールサーバ５０は、メール受信部５１、問い合わせ部５２、及び処理実行部５３等を有する。メール受信部５１は、発信側端末４０より送信される電子メールの中継要求（第三の実施の形態の通信要求）を直接的又は間接的に受信する。問い合せ部５２は、電子メールの受信に応じて実行すべき処理を端末管理サーバ１０ｂに問い合わせる。処理実行部５５は、問い合わせに対する判定結果に応じた処理を実行する。

通信システム３の処理手順は、通信システム２の処理手順（図１０）と同様でよい。但し、電話帳２７ｂには少なくともメールアドレスが登録されている必要がある。

図１５は、第三の実施の形態における電話帳の構成例を示す図である。同図において、電話帳２７ｂは、エントリごとに名前、メールアドレス、ロック時代替処理情報、及びワイプ時代替処理情報等の登録が可能とされている。なお、ロック時代替処理情報又はワイプ時代替処理情報に定義される代替処理の例としては、ユーザ定義若しくはシステム固定の定型応答メールの返信、特定メールアドレスへのメール受信の通知、特定メールアドレスへのメールの着信転送等が挙げられる。

したがって、端末管理サーバ１０ｂの端末情報テーブル１６ｂには、次のような情報が登録される。図１６は、第三の実施の形態における端末情報テーブルの構成例を示す図である。同図に示されるように、端末情報テーブル１６ｂは、着信側アドレスごとにロック状態を管理し、着信側アドレスと発信側アドレスとの組み合わせにとごとにロック時代替処理情報及びワイプ時代替処理情報を管理する。

同図では、図１５に示される電話帳２７ｂにおける代替処理情報等が登録された状態が示されている。すなわち、着信側アドレスには、携帯電話端末２０ｂのメールアドレス（ＸＸＸ＠ｅｘａｍｐｌｅ．ｘｘｘ）が登録されている。また、発信側アドレス、ロック時代替処理情報、ワイプ時代替処理情報には、電話帳２７ｂに登録されている各メールアドレス、ロック時代替処理情報、ワイプ時代替処理情報が登録されている。

代替処理判定部１３は、メールサーバ５０の問い合わせ部５２からの問い合わせに応じ、図１３に示されるような処理を実行することにより代替処理を判定する。すなわち、問い合わせ部５２からの問い合わせには、携帯電話端末２０ｂのメールアドレス（着信側アドレス）と発信側端末４０のメールアドレス（発信側アドレス）とが含まれている。代替処理判定部１３は、当該着信側アドレス及び発信側アドレスを端末情報テーブル１６ｂに当てはめることにより代替処理を判定する。

なお、着信側アドレスのロック状態が「ロック」のときにロック時代替処理情報が登録されていない発信側アドレスからの電子メールについては、着信側アドレスに中継するようにするとよい。そうすることで、メールサーバ５０内で電子メールを保管しておく必要がなくなり、メールサーバ５０のリソース消費量の増加を回避することができる。

また、着信側アドレスのロック状態が「ワイプ」のときにワイプ時代替処理情報が登録されていない発信側アドレスからの電子メールについては、メールサーバ５０で保管するようにするとよい。そうすることで、ワイプ後の携帯電話端末２０ｂに新たに電子メールが受信されることを回避することができる。

その他の点については、第一又は第二の実施の形態より自明であるためここでの説明は省略する。

上述したように、第三の実施の形態によれば、携帯電話端末２０ｂが手元にないときに、電子メールの受信に関しても代替処理を実行させることができる。したがって、重要な電子メールの受信を携帯電話端末２０ｂの所有者に通知したりすることができる。

なお、本実施の形態では、携帯電話端末に対する通信要求の具体例として通話要求及び電子メールの転送要求を挙げて説明した。但し、携帯電話端末による新たな通信手段（通信方法）の増加に応じて、当該通信要求が意味する範囲は拡大しうる。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

Claims (18)

1. コンピュータが実行する代替処理判定方法であって、
   発信側端末からの通信要求に応じ、前記通信要求に係る着信側識別情報及び当該発信側端末の発信側識別情報と、着信側識別情報と発信側識別情報との組み合わせごとに前記発信側識別情報に係る発信側端末からの通信要求に応じた処理を示す代替処理情報を管理する代替処理情報管理手段とに基づいて、当該通信要求を前記着信側識別情報に係る携帯電話端末に中継させる代わりに実行する代替処理を判定する代替処理判定手順を有し、
   前記代替処理情報管理手段は、相互に処理手順の異なる複数の代替処理のうちのいずれかを示す複数の代替処理情報を、着信側識別情報と発信側識別情報との組み合わせごとに管理し、
   前記代替処理判定手順は、前記通信要求に係る着信側識別情報と発信側識別情報との組み合わせに対する複数の代替処理情報の中で、前記携帯電話端末の状態に応じた代替処理情報が示す代替処理を判定する代替処理判定方法。
2. 前記携帯電話端末より前記代替処理情報を受信し、前記代替処理情報管理手段に登録する代替処理情報受信手順を有する請求項１記載の代替処理判定方法。
3. 前記代替処理情報は、前記携帯電話端末に対する遠隔的な操作に応じて前記携帯電話端末より送信される請求項２記載の代替処理判定方法。
4. 前記代替処理情報管理手段は、前記遠隔的な操作の種別に応じて前記代替処理情報を管理し、
   前記代替処理判定手順は、前記携帯電話端末に対して行われた遠隔的な操作の種別に応じて前記代替処理を判定する請求項３記載の代替処理判定方法。
5. 前記着信側識別情報及び前記発信側識別情報は、電話番号又はメールアドレスである請求項１記載の代替処理判定方法。
6. 着信側識別情報と発信側識別情報との組み合わせごとに前記発信側識別情報に係る発信側端末からの通信要求に応じた処理を示す代替処理情報を管理する代替処理情報管理手段と、
   前記発信側端末からの通信要求に応じ、前記通信要求の対象とされている着信側識別情報及び当該発信側端末の発信側識別情報と前記代替処理情報とに基づいて、当該通信要求を前記着信側識別情報に係る携帯電話端末に中継させる代わりに実行する代替処理を判定する代替処理判定手段とを有し、
   前記代替処理情報管理手段は、相互に処理手順の異なる複数の代替処理のうちのいずれかを示す複数の代替処理情報を、着信側識別情報と発信側識別情報との組み合わせごとに管理し、
   前記代替処理判定手段は、前記通信要求に係る着信側識別情報と発信側識別情報との組み合わせに対する複数の代替処理情報の中で、前記携帯電話端末の状態に応じた代替処理情報が示す代替処理を判定する代替処理判定装置。
7. 前記携帯電話端末より前記代替処理情報を受信し、前記代替処理情報管理手段に登録する代替処理情報受信手段を有する請求項６記載の代替処理判定装置。
8. 前記代替処理情報は、前記携帯電話端末に対する遠隔的な操作に応じて前記携帯電話端末より送信される請求項７記載の代替処理判定装置。
9. 前記代替処理情報管理手段は、前記遠隔的な操作の種別に応じて前記代替処理情報を管理し、
   前記代替処理判定手段は、前記携帯電話端末に対して行われた遠隔的な操作の種別に応じて前記代替処理を判定する請求項８記載の代替処理判定装置。
10. 前記着信側識別情報及び前記発信側識別情報は、電話番号又はメールアドレスである請求項６記載の代替処理判定装置。
11. コンピュータに、
    発信側端末からの通信要求に応じ、前記通信要求に係る着信側識別情報及び当該発信側端末の発信側識別情報と、着信側識別情報と発信側識別情報との組み合わせごとに前記発信側識別情報に係る発信側端末からの通信要求に応じた処理を示す代替処理情報を管理する代替処理情報管理手段とに基づいて、当該通信要求を前記着信側識別情報に係る携帯電話端末に中継させる代わりに実行する代替処理を判定する代替処理判定手順を実行させ、
    前記代替処理情報管理手段は、相互に処理手順の異なる複数の代替処理のうちのいずれかを示す複数の代替処理情報を、着信側識別情報と発信側識別情報との組み合わせごとに管理し、
    前記代替処理判定手順は、前記通信要求に係る着信側識別情報と発信側識別情報との組み合わせに対する複数の代替処理情報の中で、前記携帯電話端末の状態に応じた代替処理情報が示す代替処理を判定するプログラム。
12. 前記携帯電話端末より前記代替処理情報を受信し、前記代替処理情報管理手段に登録する代替処理情報受信手順を有する請求項１１記載のプログラム。
13. 前記代替処理情報は、前記携帯電話端末に対する遠隔的な操作に応じて前記携帯電話端末より送信される請求項１２記載のプログラム。
14. 前記代替処理情報管理手段は、前記遠隔的な操作の種別に応じて前記代替処理情報を管理し、
    前記代替処理判定手順は、前記携帯電話端末に対して行われた遠隔的な操作の種別に応じて前記代替処理を判定する請求項１３記載のプログラム。
15. 前記着信側識別情報及び前記発信側識別情報は、電話番号又はメールアドレスである請求項１１記載のプログラム。
16. 通信相手の候補ごとに通信のための識別情報と前記通信相手より通信要求を受信したときに実行する処理を示す情報を管理する処理情報管理手段と、
    請求項６記載の代替処理判定装置に前記処理情報管理手段を前記代替処理情報として送信する代替処理情報送信手段とを有する携帯電話端末。
17. 前記処理情報管理手段は、電話帳の一部として前記実行する処理を示す情報を管理する請求項１６記載の携帯電話端末。
18. 前記通信要求を受信する通信要求受信手段と、
    前記通信要求の受信に応じ、該通信要求に係る発信側端末の識別情報と前記処理情報管理手段とに基づいて実行する処理を判定する第二の判定手段と、
    前記第二の判定手段によって判定された処理を実行する処理実行手段とを有する請求項１６記載の携帯電話端末。

Images