JP2017157010A - 情報処理装置および情報処理方法 - Google Patents

Abstract

【課題】ユーザ認証に伴うユーザの管理負担を軽減する。【解決手段】ユーザ端末４に割り当てられた電話番号の入力を受け付け、その受け付けた電話番号宛てに確認用のＵＲＬを組み込んだ確認メールを送信し、ユーザ端末４で確認用のＵＲＬが選択されることにより発行されるアクセス要求を受け取り、その受け取ったアクセス要求に基づいて、予約処理システム１へのログインをユーザ端末４に許可する。【選択図】図１

Description

本発明は、情報処理装置および情報処理方法に関する。

情報処理システムでは、システムのセキュリティを確保する観点等から利用開始時等にユーザ認証を行う。一般に、ユーザ認証では、ユーザＩＤおよびパスワードの入力をユーザに要求し、入力されたユーザＩＤおよびパスワードが、既に登録されているユーザＩＤおよびパスワードと一致する場合に、システムへのログインを許可する。

下記特許文献１には、インターネットに接続するユーザの最大件数を時間帯ごとに管理し、同じ時刻に多数のユーザがアクセスすることを防止するオンライン予約システムが開示されている。この予約システムでは、ユーザがサーバやルータにアクセスするときに、ユーザＩＤおよびパスワードの入力をユーザに要求し、ユーザ認証を行っている。

特開２００１−３５８７６７号公報

ユーザＩＤおよびパスワードは、一般に、システムごとに異なる内容が設定され、特にパスワードには他人から推測されにくい内容を設定することが求められている。したがって、ユーザは、利用するシステムごとにユーザＩＤおよびパスワードの内容を把握することが必要となるため、利用するシステムが増加する等により、ユーザ認証に伴うユーザの管理負担が増大してしまう。

本発明は、上述した課題を解決するためになされたものであり、ユーザ認証に伴うユーザの管理負担を軽減することができる情報処理装置および情報処理方法を提供することを目的の一つとする。

本発明の一態様である情報処理装置は、モバイル端末に割り当てられた電話番号の入力を受け付ける手段と、前記受け付けた前記電話番号宛てに確認用の情報を伝送する手段と、前記確認用の情報を利用した応答を前記モバイル端末から受け取る手段と、前記受け取った前記応答に基づいて、システムへのログインを前記モバイル端末に許可する手段と、を備える。

前記確認用の情報は、ＵＲＬ（uniform resource locator）であり、前記確認用の情報を利用した応答は、前記ＵＲＬを選択することで前記モバイル端末から送信されるアクセス要求であることとしてもよい。

前記確認用の情報は、番号または文字列であり、前記確認用の情報を利用した応答は、前記番号または文字列を入力することで前記モバイル端末から送信されるメッセージであることとしてもよい。

システムにログインした前記モバイル端末のユーザによる操作指示に従って、予約の申し込み処理、予約の変更処理および／または予約の取り消し処理を実行する手段を、さらに備えることとしてもよい。

前記実行する手段は、前記予約の申し込み処理では、予約に関する情報を前記電話番号に紐付けて記憶させ、前記予約の変更処理および／または前記予約の取り消し処理では、前記電話番号に紐付けて記憶させた予約に関する情報を変更および／または削除する、こととしてもよい。

本発明の一態様である情報処理方法は、サーバ装置が、モバイル端末に割り当てられた電話番号の入力を受け付けるステップと、前記受け付けた前記電話番号宛てに確認用の情報を伝送するステップと、前記確認用の情報を利用した応答を前記モバイル端末から受け取るステップと、前記受け取った前記応答に基づいて、システムへのログインを前記モバイル端末に許可するステップと、を実行する。

本発明によれば、ユーザ認証に伴うユーザの管理負担を軽減することが可能となる。

実施形態における予約処理サーバを含む予約処理システムの構成を例示する図である。 図１に示す予約処理サーバの構成を例示する図である。 ログイン受付画面を例示する図である。 予約処理システムにおいてユーザ認証を行う際の手順を説明するためのシーケンスチャートである。

以下、本発明の実施形態について図面を参照しつつ詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。

図１は、本発明の一実施形態に係る予約処理サーバ（情報処理装置、サーバ装置）を含む予約処理システムの概略構成図である。同図に示すように、本実施形態における予約処理システム１は、予約処理サーバ２と、１台以上の業者端末３と、１台以上のユーザ端末４とを備える。業者端末３およびユーザ端末４はそれぞれ、ネットワークＮを介して予約処理サーバ２と通信できるように構成される。

業者端末３は、サービスを提供する業者が、後述するイベントの予約を受け付ける予約受付者として使用する端末装置である。業者端末３として、例えば、ＰＣ（パーソナルコンピュータ）、ノートＰＣ、タブレット端末、スマートフォン、携帯電話機、携帯情報端末（ＰＤＡ）等を用いることができる。業者は、あらゆる業種・業態の業者が対象となる。

ユーザ端末４は、サービスの提供を受けるユーザが、イベントの予約を申し込む予約申込者として使用する端末装置である。本実施形態では、ユーザ端末４として、スマートフォンを用いて説明するが、これに限定されず、電話番号を割り当て可能なモバイル端末全般をユーザ端末４として用いることができる。

イベントは、予約の対象となり得るものであればよい。例示的に、イベントは、業者等が予約枠を設定することで生成される予約イベント情報により特定することができる。予約イベント情報の詳細については、後述する。予約枠を設定する方法は、例えば、予約受付タイプに応じて定めることができる。予約受付タイプとして、例示的に、後述する事前設定タイプおよび自由受付タイプを採用することができる。なお、予約受付タイプは、他のタイプであってもよく、任意に採用することができる。

事前設定タイプは、業者が事前に設定した予約枠を利用してユーザからの予約を受け付ける方式である。自由受付タイプは、業者が設定したサービス提供時間内に、所望の予約枠をユーザに設定させることでユーザからの予約を受け付ける方式である。

予約枠を設定する前に、業者は、例えば、以下の各項目を登録する。業者が提供するサービスの内容を特定するメニュー項目、サービスを提供する際の資源（例えば、人、設備、備品等）となるリソース項目、リソースが帰属可能なリソースグループ項目、予約定員数項目、予約受付可能日時項目、料金項目。

事前設定タイプでは、例えば、業者が、メニュー項目と、そのメニュー項目に対応するサービスを提供する時間帯とを設定することで予約枠が設定される。

自由受付タイプでは、例えば、業者がサービス提供時間を設定し、ユーザがサービス提供時間内から所望する時間帯を指定することで予約枠が設定される。

予約処理サーバ２は、例えば、比較的演算処理能力の高いコンピュータによって構成され、そのコンピュータにおいて所定のサーバ用プログラムが動作することにより、サーバ機能を実現するものである。ここで、予約処理サーバ２を構成するコンピュータは、必ずしも１台である必要はなく、ネットワークＮ上に分散する複数のコンピュータから構成されてもよい。

ネットワークＮは、予約処理サーバ２と業者端末３とユーザ端末４との間で相互に情報を送受信可能な通信網を含む。ネットワークＮは、例えば、インターネット、ＬＡＮ、専用線、電話回線、企業内ネットワーク、移動体通信網、ブルートゥース、ＷｉＦｉ（Wireless Fidelity）、その他の通信回線、それらの組み合わせ等のいずれであってもよく、有線であるか無線であるかを問わない。

図２に示すように、予約処理サーバ２は、例えば、プロセッサ２０と、通信インタフェース２１と、記憶資源２２とを備える。

プロセッサ２０は、算術演算、論理演算、ビット演算等を処理する算術論理演算ユニットおよび各種レジスタから構成され、記憶資源２２に格納されているコンピュータプログラム２２０を実行することで、後述する各種機能を実現する。各種レジスタは、例えば、プログラムカウンタ、データレジスタ、命令レジスタ、汎用レジスタ等である。

通信インタフェース２１は、ネットワークＮに接続し、ネットワークＮ上の他の端末と通信をするためのハードウェアモジュールである。通信インタフェース２１は、例えば、ＩＳＤＮモデム、ＡＤＳＬモデム、ケーブルモデム、光モデム、ソフトモデム等の変調復調装置である。

記憶資源２２は、例えば、物理デバイスの記憶領域が提供する論理デバイスである。物理デバイスは、例えば、ディスクドライブまたは半導体メモリ等のコンピュータ読み取り可能な記録媒体である。記憶資源２２は、複数の物理デバイスを１つの論理デバイスにマッピングして構築してもよいし、１つの物理デバイスを複数の論理デバイスにマッピングして構築してもよい。記憶資源２２には、コンピュータプログラム２２０が記憶される。

コンピュータプログラム２２０は、所定の処理を行うためのプログラムであり、予約処理サーバ２のメインプログラムの動作中に適宜呼び出されて実行される複数のソフトウェアモジュールを備える。このソフトウェアモジュールは、それぞれ特定の処理を実行するためにモジュール化されたサブプログラムであり、例えば、プロシージャ、サブルーチン、メソッド、関数およびデータ構造等を用いて作成される。

コンピュータプログラム２２０は、例示的に、処理モジュール２２１を有する。処理モジュール２２１を実行することで実現する機能については後述する。

記憶資源２２には、コンピュータプログラム２２０のほか、予約処理サーバ２の処理に用いられるオペレーティングシステムプログラム、ドライバプログラム、各種データ等が格納される。ドライバプログラムとして、例えば、通信インタフェース２１を制御するための通信インタフェースドライバプログラム等がある。

各種データとして、例えば、業者が登録する業者のアカウントおよびユーザが登録するユーザのアカウントに関するアカウント情報２２２、業者が登録する予約の対象となるイベントに関する予約イベント情報２２３、ユーザが登録する予約内容に関する予約情報２２４等がある。

アカウント情報２２２には、業者のアカウント情報とユーザのアカウント情報とが含まれる。業者のアカウント情報は、データ項目として、例えば、業者ＩＤ項目、パスワード項目、メールアドレス項目、氏名項目、業種・業態項目等を有する。業者ＩＤ項目は、業者を特定するための識別情報を格納する。業種・業態項目は、業者の業種・業態を特定する情報を格納する。

ユーザのアカウント情報は、データ項目として、例えば、ユーザ電話番号項目、氏名項目、住所項目、メールアドレス項目、クレジットカード情報項目、配送先情報項目、趣味・嗜好情報項目等を有する。ユーザ電話番号項目は、ユーザを特定するための識別情報として、ユーザが使用するユーザ端末４に割り当てられた電話番号を格納する。ユーザのアカウント情報は、ユーザが最初に予約を申し込むときにユーザが入力する情報に基づいて登録することとしてもよいし、予約処理システムと連携する他のシステムに登録されているユーザのアカウント情報を取り込むことで登録することとしてもよい。

予約イベント情報２２３は、データ項目として、例えば、業者ＩＤ項目、イベントＩＤ項目、ジャンル項目、提供場所項目、提供時間項目、料金項目、担当者項目、補足説明項目等を有する。業者ＩＤ項目は、上記業者のアカウント情報の業者ＩＤ項目と同様の項目であり、この業者ＩＤ項目により業者のアカウント情報と予約イベント情報２２３とを対応付けることができる。

イベントＩＤ項目は、例えばイベント番号やイベント名称等のように、イベントを特定するためのイベント識別情報を格納する。ジャンル項目は、イベントのジャンルを特定するための情報を格納する。イベントのジャンルは、例えば業種・業態ごとや、提供対象の種類ごとに設けることができ、具体的には、飲食店、病院、スクール、フィットネス、美容サロン、飲食店で提供する各料理（例えばそば屋で提供する天ぷらそば、ざるそば）等が該当する。各ジャンルには、それぞれ複数の階層を任意に設けることができる。例えば、ジャンルが飲食店である場合には、飲食店の下位階層として、レストラン、カフェ、居酒屋等を設け、レストランの下位階層として、和食系、中華系、洋食系等を設け、さらに和食系の下位階層として、寿司屋、そば屋、天ぷら屋等を設けることができる。

提供場所項目は、イベントの提供場所を特定するための情報を格納する。提供時間項目は、イベントの提供時間（例えば、提供開始時刻および提供終了時刻）を格納する。料金項目は、イベントの料金を格納する。担当者項目は、イベントを提供する業者側の担当者を特定するための情報を格納する。補足説明項目は、例えばイベントの内容や、ターゲットとなるユーザの嗜好に関する情報等、イベントに関するメモ的な情報を格納する。

予約情報２２４は、データ項目として、例えば、予約ＩＤ項目、イベントＩＤ項目、予約内容項目、ユーザ電話番号項目、メモ項目等を有する。予約ＩＤ項目は、ユーザにより申し込まれた予約を特定するための識別情報を格納する。イベントＩＤ項目は、上記予約イベント情報２２３のイベントＩＤ項目と同様の項目であり、このイベントＩＤ項目により予約イベント情報２２３と予約情報２２４とを対応付けることができる。

予約内容項目は、例えば予約人数、予約コース、予約時間等の予約内容に関する情報を格納する。ユーザ電話番号項目は、上記ユーザのアカウント情報のユーザ電話番号項目と同様の項目であり、このユーザ電話番号項目によりユーザのアカウント情報と予約情報２２４とを対応付けることができる。メモ項目は、例えば口コミ等、ユーザの予約に対する評価や予約に関するメモ的な情報を格納する。

なお、上述したアカウント情報２２２、予約イベント情報２２３および予約情報２２４を格納するデータベースの組み合わせ、ならびに各情報に含まれるデータ項目の組み合わせは例示に過ぎず、データベースやデータ項目の組み合わせについては、運用するシステムに合わせて適宜変更することができる。

次に、図２に示す予約処理サーバ２の処理モジュール２２１を実行することで実現する機能について説明する。

処理モジュール２２１は、予約処理システム１への接続を要求するユーザ端末４に対し、ログイン受付画面を表示させる。

ここで、図３を参照し、ユーザ端末４に表示させるログイン受付画面について説明する。ログイン受付画面４１は、電話番号入力欄４１ａと確定ボタン４１ｂとを有する。電話番号入力欄４１ａは、ユーザ端末４に割り当てられた電話番号を入力するための入力欄である。この電話番号入力欄４１ａには、初期表示として、ユーザ端末４の内部（例えばメモリ等）または外部（例えばサーバ等）に格納されている自端末の電話番号を表示させることとしてもよい。確定ボタン４１ｂは、ユーザが例えばタップ（選択）することで、電話番号入力欄４１ａに入力された電話番号を予約処理サーバ２に送信する処理を開始させるボタンである。

本発明は、ユーザＩＤおよびパスワードの入力を省き、電話番号を入力することでユーザ認証を行えるようにしたことに特徴がある。この特徴は、電話番号が有する以下の機能を活用することで実現可能となる。まず、電話番号は、ユーザ端末４に対して一意に割り当てられる番号であるため、ユーザ端末４を所有するユーザを特定するための識別情報として位置づけることが可能となる。また、電話番号は、ユーザが比較的容易に覚えることができる情報であるため、電話番号の入力を要求することは、ユーザＩＤおよびパスワードの入力を要求することに比べ、ユーザの負担を軽減することが可能となる。

一方、ユーザ認証を電話番号の入力のみで行うこととすると、ユーザの電話番号を他のユーザが別の端末で入力した場合にも認証が成立してしまうこととなる。そこで、本発明は、ユーザにより入力された電話番号が割り当てられているユーザ端末４に対してユニークな確認用の情報を発行し、その確認用の情報を通知するためのメッセージを、入力された電話番号宛てに伝送することに加え、その確認用の情報を利用することで送信される確認用の応答をユーザ端末４から受け取ることにより、ユーザ端末４の正当性を判別することとした。これにより、確認用の応答を受け取った場合に、その応答元の端末が、ユーザにより入力された電話番号に対応する正当なユーザ端末４であると判別することが可能となる。

上記確認用の情報として、例えば、ＵＲＬ、番号、文字列を用いることができる。以下に、ユーザ端末４の正当性を判別する際の具体的な手順について、確認用の情報ごとに例示する。

（１）確認用の情報がＵＲＬである場合：ＵＲＬを通知するためのテキストメッセージを電話番号宛てに送信する。その後、通知したＵＲＬがユーザ端末４で選択されることにより送信されるアクセス要求を、確認用の応答として受け取った場合に、その応答元の端末が正当なユーザ端末４であると判別する。

電話番号宛てにテキストメッセージを送信する方法として、例えば、ショートメッセージサービス（以下、「ＳＭＳ」ともいう。）を利用することができる。

（２）確認用の情報が番号または文字列である場合：番号や文字列を通知するためのテキストメッセージを電話番号宛てに送信する。その後、通知した番号や文字列がユーザ端末４で入力されることにより予約処理サーバ２に送信されるテキストメッセージを、確認用の応答として受け取った場合に、その応答元の端末が正当なユーザ端末４であると判別する。

（３）確認用の情報が番号または文字列である場合：番号や文字列を通知するための音声メッセージを電話番号宛ての電話・通信により伝送する。その後、通知した番号や文字列がユーザ端末４で入力されることにより予約処理サーバ２に送信されるテキストメッセージを、確認用の応答として受け取った場合に、その応答元の端末が正当なユーザ端末４であると判別する。

（４）確認用の情報が番号または文字列である場合：番号や文字列を通知するためのテキストメッセージを電話番号宛てに送信（ユーザ端末４の画面上に番号や文字列を表示させることができればよい）し、別途、確認用の応答方法（例えば、キー入力操作または音声入力操作）を通知するための音声メッセージを電話番号宛ての電話・通信により伝送する。その後、通知した番号や文字列が、通知した応答方法に従ってユーザ端末４で入力されることにより予約処理サーバ２に送信されるテキストメッセージまたは音声メッセージを、確認用の応答として受け取った場合に、その応答元の端末が正当なユーザ端末４であると判別する。

図２に示す処理モジュール２２１を実行することで実現する機能の説明に戻る。処理モジュール２２１は、電話番号入力欄４１ａに入力された電話番号宛てに、上述した確認用の情報を通知するためのメッセージを伝送する。

処理モジュール２２１は、ユーザ端末４において確認用の情報を利用することで送信される確認用の応答をユーザ端末４から受け取った場合に、そのユーザ端末４に対し、予約処理システム１へのログインを許可する。

処理モジュール２２１は、予約処理システム１にログインしたユーザ端末４のユーザによる操作指示に従って、予約処理を実行する。予約処理には、例えば、予約の申し込み処理、予約の変更処理および予約の取り消し処理等が含まれる。

予約の申し込み処理は、例えば、ユーザによる予約申込操作指示に従って、ユーザにより入力された予約に関する情報を、ユーザ端末４の電話番号に紐付けて予約情報２２４に記憶させる処理である。

予約の変更処理は、例えば、ユーザによる予約変更操作指示に従って、ユーザ端末４の電話番号に紐付けて予約情報２２４に記憶させた予約に関する情報を変更する処理である。

予約の取り消し処理は、例えば、ユーザによる予約取消操作指示に従って、ユーザ端末４の電話番号に紐付けて予約情報２２４に記憶させた予約に関する情報を削除する処理である。

図４を参照して、予約処理システムにおいてユーザ認証を行う際の手順について、その一例を説明する。ここでは、確認用の情報がＵＲＬである場合について例示する。確認用の情報が番号または文字列である場合については、後述するステップＳ１０５からステップＳ１１０までの処理内容を、上述したユーザ端末４の正当性を判別する際の手順において説明したそれぞれの処理内容に入れ替えることで、以下に説明するＵＲＬの場合と同様の手順で処理することができる。

最初に、ユーザ端末４は、予約処理システム１への接続を要求する（ステップＳ１０１）。

続いて、予約処理サーバ２の処理モジュール２２１は、ログイン受付画面４１（図３参照）をユーザ端末４のディスプレイに表示させる（ステップＳ１０２）。

続いて、ユーザ端末４のユーザが、ログイン受付画面４１の電話番号入力欄４１ａにユーザ端末４の電話番号を入力し、確定ボタン４１ｂをタップする（ステップＳ１０３）と、ユーザ端末４は、電話番号入力欄４１ａに入力された電話番号を予約処理サーバ２に送信する（ステップＳ１０４）。

続いて、予約処理サーバ２の処理モジュール２２１は、確認用の情報としてＵＲＬを発行し（ステップＳ１０５）、上記ステップＳ１０３で入力された電話番号宛てに、その確認用のＵＲＬを通知するためのテキストメッセージを送信する（ステップＳ１０６）。

続いて、ユーザ端末４のユーザが、テキストメッセージに組み込まれた確認用のＵＲＬを選択する（ステップＳ１０７）と、ユーザ端末４は、確認用の応答として、ＵＲＬに設定された場所へのアクセス要求を送信する（ステップＳ１０８）。

続いて、予約処理サーバ２の処理モジュール２２１は、上記ステップＳ１０８でアクセス要求を送信してきた端末が、上記ステップＳ１０３で入力された電話番号に対応する正当なユーザ端末４であると判別する（ステップＳ１０９）。

続いて、予約処理サーバ２の処理モジュール２２１は、上記ステップＳ１０８でアクセス要求を送信してきたユーザ端末４に対して予約処理システム１へのログインを許可する（ステップＳ１１０）。

続いて、予約処理システム１にログインしたユーザ端末４は、予約処理サーバ２との間で予約処理を実行する（ステップＳ１１１）。

上述したように、実施形態における予約処理システム１によれば、ユーザ端末４に割り当てられた電話番号の入力を受け付け、その受け付けた電話番号宛てに確認用の情報を通知するためのメッセージを伝送し、ユーザ端末４で確認用の情報を利用することで送信される確認用の応答を受け取り、その受け取った確認用の応答に基づいて、予約処理システム１へのログインをユーザ端末４に許可することができる。

したがって、実施形態における予約処理システム１によれば、従来ユーザ認証する際に必要となっていたユーザＩＤおよびパスワードの内容を管理する手間を省くことができるため、ユーザ認証に伴うユーザの管理負担を軽減することが可能となる。

また、実施形態における予約処理システム１によれば、予約処理システム１にログインしたユーザ端末４のユーザによる操作指示に従って、予約の申し込み処理、予約の変更処理および／または予約の取り消し処理を実行することができる。これにより、ユーザ端末４の電話番号による認証に続けて、その認証に用いた電話番号に紐付けられる予約情報２２４およびユーザのアカウント情報２２２を利用しながら予約処理を実行することが可能となる。つまり、認証を伴う予約処理を安全かつ効率よく進めることが可能となる。

[変形例]
なお、本発明は、上述した実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述した各処理（ステップ）は処理内容に矛盾を生じない範囲で任意に順番を変更し、または並列に実行することができる。

また、上述した実施形態では、予約処理システム１にログインする際にユーザ認証を行っているが、ユーザ認証を行うタイミングは、これに限定されない。例えば、予約処理に含まれる各トランザクション処理（予約の申し込み処理、予約の変更処理および予約の取り消し処理）を実行するタイミングでユーザ認証を行うこととしてもよい。つまり、認証を必要とするトランザクション処理全般に本発明を適用することができる。なお、同一のユーザ端末４におけるユーザ認証は、初回のみ行うこととし、２回目以降は省略することとしてもよい。

さらに、上述した実施形態では、予約処理システム１に本発明を適用した場合について説明しているが、本発明は、認証を必要とする情報処理システムまたは情報処理アプリケーション全般に適用することができる。例示的に、電子商取引システムや、自動車、家屋その他の開錠／施錠システム、フリーメールサービス、ＳＮＳ（Social Networking Service）に本発明を適用することができる。また、本発明を適用する際のユーザ端末４のネットワークＮへの接続状態は、オンライン、オフラインのいずれであってもよい。

１…予約処理システム
２…予約処理サーバ（情報処理装置、サーバ装置）
３…業者端末
４…ユーザ端末（モバイル端末）
２０…プロセッサ
２１…通信インタフェース
２２…記憶資源
４１…ログイン受付画面
４１ａ…電話番号入力欄
４１ｂ…確定ボタン
２２０…コンピュータプログラム
２２１…処理モジュール
２２２…アカウント情報
２２３…予約イベント情報
２２４…予約情報
Ｎ…ネットワーク

Claims (6)

1. モバイル端末に割り当てられた電話番号の入力を受け付ける手段と、
   前記受け付けた前記電話番号宛てに確認用の情報を伝送する手段と、
   前記確認用の情報を利用した応答を前記モバイル端末から受け取る手段と、
   前記受け取った前記応答に基づいて、システムへのログインを前記モバイル端末に許可する手段と、
   を備えることを特徴とする情報処理装置。
2. 前記確認用の情報は、ＵＲＬ（uniform resource locator）であり、
   前記確認用の情報を利用した応答は、前記ＵＲＬを選択することで前記モバイル端末から送信されるアクセス要求である、
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記確認用の情報は、番号または文字列であり、
   前記確認用の情報を利用した応答は、前記番号または文字列を入力することで前記モバイル端末から送信されるメッセージである、
   ことを特徴とする請求項１記載の情報処理装置。
4. システムにログインした前記モバイル端末のユーザによる操作指示に従って、予約の申し込み処理、予約の変更処理および／または予約の取り消し処理を実行する手段を、さらに備えることを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記実行する手段は、前記予約の申し込み処理では、予約に関する情報を前記電話番号に紐付けて記憶させ、前記予約の変更処理および／または前記予約の取り消し処理では、前記電話番号に紐付けて記憶させた予約に関する情報を変更および／または削除する、ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
6. サーバ装置が、
   モバイル端末に割り当てられた電話番号の入力を受け付けるステップと、
   前記受け付けた前記電話番号宛てに確認用の情報を伝送するステップと、
   前記確認用の情報を利用した応答を前記モバイル端末から受け取るステップと、
   前記受け取った前記応答に基づいて、システムへのログインを前記モバイル端末に許可するステップと、
   を実行することを特徴とする情報処理方法。

Images