JP5201373B2 - 情報処理システム、連携サーバ、情報処理方法及び情報処理プログラム - Google Patents

Description

本発明は、情報を収集して業務を行なうための情報処理技術に関する。

携帯端末を用いて情報を収集し、サーバと通信しながら業務を進める技術が特許文献１に開示されている。特に、特許文献１では、列車内で販売員が操作端末を操作して、無線ＬＡＮ中継器を介してサーバにアクセスし、商品に関する情報をやり取りする技術が開示されている。

特開2004-64493号公報

しかしながら、上述の特許文献１に記載の技術では、業務を行なうための操作端末を用いて簡便にメッセージ送信を行なうことができなかった。業務上の問題があって担当者との間でテキストメッセージのやりとりを行ないたい場合には、その問題の所在を調べ、連絡先を調べ、携帯電話やコンピュータを用いてメッセージを打ち込む必要があり、非常に手間がかかっていた。

本発明は、上記従来技術の課題を解決することを目的とする。

上記目的を達成するため、本発明に係る情報処理システムは、
携帯端末から入力された業務用ユーザＩＤを使用して、前記携帯端末からのリクエストに応じて、業務情報を取得する取得手段と、
複数の定型メッセージを記憶する記憶手段と、
前記複数の定型メッセージから、前記取得手段を用いて取得された前記業務情報に含まれる業務内容に対応する定型メッセージを選択する選択手段と、
前記携帯端末の前記業務用ユーザＩＤを前記携帯端末のメッセージ送信元ユーザＩＤに変換すると共に、前記取得手段を用いて取得された前記業務情報に含まれる問合せ先に対応するメッセージ送信先ユーザＩＤを決定する決定手段と、
前記選択手段よって選択された定型メッセージを、前記決定手段によって決定された前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して、送信する送信手段と、
を備えたことを特徴とする。

上記目的を達成するため、本発明に係る連携サーバは、
携帯端末から入力された業務用ユーザＩＤおよび業務情報を取得し、予め記憶された複数の定型メッセージから、取得された前記業務情報に含まれる業務内容に対応する定型メッセージを選択する選択手段と、
前記携帯端末の業務用ユーザＩＤを前記携帯端末のメッセージ送信元ユーザＩＤに変換すると共に、前記業務情報に含まれる問合せ先に対応するメッセージ送信先ユーザＩＤを決定する決定手段と、
前記選択手段よって選択された定型メッセージを、前記決定手段によって決定された前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して送信するための、メッセージ送信画面を生成する生成手段と、
を備えたことを特徴とする。

上記目的を達成するため、本発明に係る情報処理方法は、
業務サーバにおいて、携帯端末から入力された業務用ユーザＩＤを使用して業務情報を取得する業務情報取得ステップと、
選択手段が、予め記憶された複数の定型メッセージから、取得された前記業務情報に含まれる業務内容に対応する定型メッセージを選択する選択ステップと、
決定手段が、前記携帯端末の業務用ユーザＩＤを前記携帯端末のメッセージ送信元ユーザＩＤに変換すると共に、前記業務情報取得ステップで取得した業務情報に含まれる問合せ先を用いて、メッセージのメッセージ送信先ユーザＩＤを決定する決定ステップと、
前記決定ステップにおいて決定した、前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して、選択した前記定型メッセージを送信する送信ステップと、
を含むことを特徴とする。

上記目的を達成するため、本発明に係る情報処理プログラムは、
業務サーバにおいて、携帯端末から入力された業務用ユーザＩＤを使用して業務情報を取得する業務情報取得ステップと、
選択手段が、予め記憶された複数の定型メッセージから、取得された前記業務情報に含まれる業務内容に対応する定型メッセージを選択する選択ステップと、
決定手段が、前記携帯端末の業務用ユーザＩＤを前記携帯端末のメッセージ送信元ユーザＩＤに変換すると共に、前記業務情報取得ステップで取得した業務情報に含まれる問合せ先を用いて、メッセージのメッセージ送信先ユーザＩＤを決定する決定ステップと、
前記決定ステップにおいて決定した、前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して、選択した前記定型メッセージを送信する送信ステップと、
をコンピュータに実行させることを特徴とする。

本発明によれば、業務作業を行ないつつ、必要な相手とのテキストメッセージのやりとりを迅速かつ効果的に行なうことが可能となる。

本発明の第１実施形態としての情報処理システムの概要を示す図である。 本発明の第２実施形態としての情報処理システムの概要を示す図である。 本発明の第２実施形態に係る携帯端末のハードウェア構成を示す図である。 本発明の第２実施形態としての情報処理システムの機能構成を示す図である。 本発明の第２実施形態としての情報処理システムの、ログイン時の処理の流れを示す図である。 本発明の第２実施形態としての情報処理システムの、連携サーバ内のユーザ情報部に登録された情報を示す図である。 本発明の第２実施形態としての情報処理システムの、通話開始時の処理の流れを示す図である。 本発明の第２実施形態としての情報処理システムの、メッセージ送信時の処理の流れを示す図である。 本発明の第１適用例における画面遷移例を示す図である。 本発明の第１適用例における画面遷移例を示す図である。 本発明の第２実施形態としての情報処理システムの、テキストメッセージサーバ内の定型テキストメッセージデータを示す図である。 本発明の第２適用例における画面遷移例を示す図である。 本発明の第３実施形態としての情報処理システムの、メッセージ送信処理の流れを示す図である。 本発明の実施形態としての情報処理システムの、メッセージ送信処理の流れを示す概略図である。 本発明の第２実施形態としての情報処理システムの、表示画面の一例を示す図である。 本発明の第２実施形態としての情報処理システムの、表示画面の一例を示す図である。 本発明の第２実施形態としての情報処理システムの、表示画面の一例を示す図である。 本発明の第２実施形態としての情報処理システムの、表示画面の一例を示す図である。

以下に、図面を参照して、本発明の実施の形態について例示的に詳しく説明する。ただし、以下の実施の形態に記載されている構成要素はあくまで例示であり、本発明の技術範囲をそれらのみに限定する趣旨のものではない。

(第１実施形態)
図１は、本発明の第１実施形態としての情報処理システム１の概要を示す図である。図１において、情報処理システム１は、携帯端末１０からのリクエストに応じて業務情報を取得する業務情報取得部２０と、複数の定型テキストメッセージを記憶する記憶部３０と、を備えている。またさらに、記憶部３０に記憶された複数の定型テキストメッセージから、業務情報に対応する定型テキストメッセージを選択する選択部４０と、取得された業務情報に対応するメッセージ送信先を決定する送信先決定部５０とを備える。そしてまた情報処理システム１は、選択部４０によって選択された定型テキストメッセージを、送信先決定部５０によって決定されたメッセージ送信先に対し送信する送信部６０を備えている。

このように、定型テキストメッセージを業務情報に基づいて読み出して利用する構成によれば、業務上のテキストメッセージのやりとりを簡易化することができ、ひいては業務効率を向上させることが可能となる。

なお、点線で示すように、業務情報取得部２０は、携帯端末１０を介して選択部４０や送信先決定部５０に業務情報を送信してもよい。

（第２実施形態）
図２は、本発明の第２実施形態としての情報処理システム２の概要を示す図である。図２に示す情報処理システム２は、複数の携帯端末１００がネットワーク３００を介して業務サーバ２１０、連携サーバ２２０、テキストメッセージサーバ２３０、及び音声サーバ２４０に接続された構成となっている。携帯端末１００は物品７０に付されたバーコードやＲＦＩＤなどのタグ７１を読みとる機能を備えており、収集した情報を用いて、業務サーバ２１０にアクセスし、必要な情報を取得する。

図３は、携帯端末１００の内部構成を示す図である。携帯端末１００は、ＣＰＵ１０１、ＲＯＭ１０２、通信制御部１０３、ＲＡＭ１０４、記憶部１０５、出力インタフェース１０６、表示部１０７、スピーカ１０８、及び入力部１１０を備えている。ＣＰＵ１０１は中央処理部であって、様々なプログラムを実行することにより携帯端末１００全体を制御する。

ＲＯＭ１０２は、リードオンリメモリであり、ＣＰＵ１０１が最初に実行すべきブートプログラムの他、各種パラメータ等を記憶している。また、通信制御部１０３は、ネットワークを介した各種サーバとの通信を制御する。ＲＡＭ１０４は、ランダムアクセスメモリであり、プログラムロード領域１４１、画面情報記憶領域１４２、各種データ記憶領域１４３等を有している。また、記憶部１０５には、業務クライアント（アプリケーション）１２０及びコミュニケーションクライアント（アプリケーション）１３０が格納されている。

一方、ＣＰＵ１０１が実行したプログラムに関する画像及び音声は、出力インタフェース１０６を介して表示部１０７に表示され、スピーカ１０８から出力される。

また、入力部１１０は、リーダ１１１、キーパッド１１２、タッチパネル１１３、マイク１１４及びこれらからの入力をＣＰＵ１０１に渡す入力インタフェース１１５を含む。ここではリーダ１１１は、一例としてバーコードリーダとするが、ＲＦＩＤタグリーダなどでもよい。

図４は、本実施形態に係る情報処理システム２の機能構成を示す図である。図４に示すように、携帯端末１００は、入力部１１０の他、業務クライアント１２０とコミュニケーションクライアント１３０とを含んでいる。

更に、業務クライアント１２０は、業務画面中にコミュニケーション情報（例えば着信履歴の有無を示す情報やテキストメッセージを受信した旨の情報）を表示するためのコミュニケーション情報表示部１２１を備えている。また、業務クライアント１２０は、業務サーバ２１０との間で業務処理を行なう業務処理部１２２と、コミュニケーションクライアント１３０内の機能を呼び出すコミュニケーション機能呼出部１２３とを備えている。

またコミュニケーションクライアント１３０は、各種コミュニケーション機能部１３１と、コミュニケーション画面表示部１３２とを備えている。コミュニケーション機能部１３１は、電話制御機能、電話機能、新着表示制御機能、着信表示制御機能、メッセージ表示制御機能、電話設定制御機能などを含む。

以上のような構成の携帯端末１００に対して、業務サーバ２１０は、業務処理部２１１、ユーザデータベース２１２、コミュニケーション機能呼出部２１３を含み業務情報取得部として機能する。ここでユーザデータベース２１２は、業務サーバ２１０にログインして業務作業用のサービスを受けることのできるユーザを登録するためのものである。具体的には、ユーザＩＤとパスワードが登録されている。

また、連携サーバ２２０は、表示画面生成部２２１とユーザ情報部２２２とを有する。表示画面生成部２２１は、携帯端末１００の表示部１０７に対して表示すべき画面を生成し、携帯端末１００に送信する。その際、業務システム（業務クライアント１２０と業務サーバ２１０）とコミュニケーションシステム（コミュニケーションクライアント１３０とテキストメッセージサーバ２３０及び音声サーバ２４０）とが連携して動作する画面を生成する。

一方、テキストメッセージサーバ２３０は、ユーザデータベース２３１、テキストメッセージデータベース２３２、メッセージ引用部２３３、メッセージ生成部２３４を含む。ここでユーザデータベース２３１は、テキストメッセージサーバ２３０にログインして業務作業用のサービスを受けることのできるユーザを登録するためのものである。具体的には、ユーザＩＤとパスワードが登録されている。メッセージ引用部２３３は、業務内容に応じた定型テキストメッセージなどを記憶している。

表示画面生成部２２１は、例えば、業務処理用の画面に重ねて表示するための、テキストメッセージ生成画面を、ユーザ情報部２２２から読出したユーザ情報やメッセージ引用部２３３から受け取った定型テキストメッセージなどを用いて生成する。

音声サーバ２４０は例えば、ＳＩＰサーバであって発信機能や、ログインして音声コミュニケーションサービスの提供を受けることのできるユーザを登録するユーザデータベース２４１を含む。

図５は、本実施形態に係る情報処理システム２のログイン時の処理の流れを示す図である。ログイン時には、まず携帯端末１００の業務クライアント１２０を起動し、ユーザＩＤとパスワードを入力する。これらの情報は業務処理部１２２から業務サーバ２１０内の業務処理部２１１に渡され、業務処理部２１１がユーザデータベース２１２を参照することにより認証を行なう。認証の結果、予め登録されたユーザであることが確認できれば、業務処理部２１１は、業務処理部１２２にその旨を通知する（Ｓ５１）。

業務処理部１２２は、次に、コミュニケーション機能呼出部１２３に他のサーバにもログインすべき旨を伝える（Ｓ５２）。コミュニケーション機能呼出部１２３は、コミュニケーションクライアント１３０内の各種コミュニケーション機能部１３１に対し、テキストメッセージサーバ２３０及び音声サーバ２４０にログインすべき旨を伝える。各種コミュニケーション機能部１３１は、元々連携サーバ２２０、テキストメッセージサーバ２３０、音声サーバ２４０のアドレスを保有しており、まず、連携サーバ２２０にアクセスして、業務サーバ用ユーザＩＤからの変換を行なう。具体的には、連携サーバ２２０に保存されているテーブル６００（図６）を用いて、業務サーバ用ユーザＩＤを、テキストメッセージサーバ用ユーザＩＤ及び音声サーバ用ユーザＩＤに変換する（Ｓ５４）。各種コミュニケーション機能部１３１は、変換して得たユーザＩＤを用いて、テキストメッセージサーバ２３０及び音声サーバ２４０にログインする（Ｓ５５）。

図６に示すテーブル６００は、業務サーバ２１０を利用するユーザを新規に登録する際に更新される。つまり、業務サーバ２１０に対してユーザを新規登録する際に、テキストメッセージサーバ２３０及び音声サーバ２４０のそれぞれに対するユーザＩＤを同時に登録することが望ましい。また更に、テーブル６００に示すように、その登録ユーザが携帯端末１００を使用する場合には、その携帯端末１００を特定する情報を、テーブル６００に加えることが望ましい。図６では、携帯端末情報をＩＰアドレスで示しているが、本発明はこれに限定されるものではなく、端末を識別するための特別な識別情報でもよい。また更に、携帯端末１００ではない通信端末を用いて業務サーバ２１０にログイン中のユーザについて、その通信端末の識別情報を登録してもよい。なお、図６では、ユーザＩＤとして、数字と英文字からなる文字列を使用しているが、本発明はこれに限定されるものではなく、ユーザの氏名でもよい。特に音声サーバ用ユーザＩＤとしてＳＩＰ−ＵＲＩが登録される例を示しているが、これも電話番号のような数字のみからなる文字列でもよい。また、ユーザＩＤに紐付けて、ユーザの個人情報（氏名や電話番号や住所など）を別途登録してもよい。

［通話開始時の処理の流れ及び第１適用例］
図７は、本実施形態に係る情報処理システム２の通話開始時の処理の流れを示す図である。まず、携帯端末１００の業務クライアント１２０を起動し、図５で説明したログイン処理を行なった後、入力部１１０を用いて、外部から情報を収集する（Ｓ７１）。例えば、第１適用例として在庫検索業務を例に取ると、図９の画面９０１を表示する。これに対してユーザは、バーコードリーダ１１１を用いて、在庫確認を行ないたい製品に付されたバーコードを読みとる。収集された情報（例えば製品番号）は、業務クライアント１２０から業務サーバ２１０の業務処理部２１１に送られる（Ｓ７２）。業務処理部２１１は、受け取った情報をもとに、不図示のデータベースなどを検索して、業務情報（例えばその製品の仕様）を導き、業務クライアント１２０に送り返す。その結果、例えば、図９の画面９０２に示すように携帯端末１００の表示部１０７に表示される。更に、この画面で検索したい仕様が選択され、「検索」ボタンが押されると、業務サーバ２１０は、その旨を受け取って、不図示のデータベースなどを参照し、具体的な在庫検索処理を行なう。つまり、どの店舗にどのような在庫が存在するかを示した在庫データベースを検索して、求める仕様の製品がどの店舗にどれだけ存在するかを導き出す。その結果は再度携帯端末１００に送られ、図９の画面９０３に示すように携帯端末１００の表示部１０７に表示される。

業務サーバ２１０が導き出した業務情報に、通話による問い合わせ先が紐付けられている場合には、その問い合わせ先を表わす文字又は画像を、業務情報と共に、業務処理部１２２に返す。図９の例では、画面９０３における「渋谷店」「池袋店」「新宿店」「渋谷店」のボタンが、問い合わせ先を表わしており、それらの店舗名が、問い合わせ可能先として携帯端末１００に送られる。ここでそれぞれのボタンに紐付けて各店舗の連絡先情報（電話番号など）を携帯端末１００に送ってもよいが、本実施形態では、そのような連絡先情報は送らずに単にボタンを識別する情報のみ（例えばボタン１は渋谷店、ボタン２は池袋店など）を送る。このように、携帯端末１００に、電話番号などの具体的な連絡先情報を送らないことにより、情報漏洩などの問題を回避できる。

図７に戻り、画面９０３のような業務情報表示画面に対し、通話による問い合わせのトリガーとなる操作を受け付けると、業務処理部１２２は、コミュニケーション機能呼出部１２３にその旨を通知する（Ｓ７３）。次に、コミュニケーション機能呼出部１２３は、コミュニケーションクライアント１３０の各種コミュニケーション機能部１３１を呼び出す（Ｓ７４）。図９の例で言えば、「渋谷店」のボタンが選択されると、「渋谷店」への通話開始を要求する旨が各種コミュニケーション機能部１３１に渡される。この時、同時に、「サイズ２３、白の製品ＡＡＡＡ」といった業務情報（製品情報）が業務処理部１２２からコミュニケーション機能呼出部１２３を介して各種コミュニケーション機能部１３１に渡される。

各種コミュニケーション機能部１３１は、相手先を指定した通話開始要求（及び必要であればその通話の目的となる業務情報）と、携帯端末１００自体を識別する情報（例えば業務サーバ用ユーザＩＤなど）とを、連携サーバ２２０に送信する（Ｓ７５）。

連携サーバ２２０は、送られてきた通話相手先（例えば渋谷店）を用いて、ユーザ情報部２２２を参照し、その通話相手先に紐付けられた音声サーバ用ユーザＩＤを導き出す。例えば、図６のテーブル６００に示したようなＳＩＰアドレスを導き出す。同様に、携帯端末１００自体を識別する情報を用いて、携帯端末１００の音声サーバ用ユーザＩＤ（例えばＳＩＰアドレス）を導き出す。

導き出された２つの音声サーバ用ユーザＩＤ（及び必要であれば業務情報）は、音声サーバ２４０に渡される（Ｓ７６）。そして、音声サーバ２４０は、それらの音声サーバ用ユーザＩＤが、ログイン中のユーザのユーザＩＤであることをユーザデータベース２４１を確認した上で、相手側に発呼し、通話を開始する。

図９の例では、発呼側の携帯端末１００において画面９０４を表示し、業務情報についての問い合わせのための発呼を行なうか、テキストメッセージを生成するかユーザに問い合わせる。この時、「Ｃａｌｌ」ボタン９４１が選択されると、発呼を開始する。「戻る」ボタン９４２が選択されると、、コミュニケーションクライアント１３０の処理を中止して、業務クライアント１２０と業務サーバ２１０との間の処理（Ｓ７２）に戻る。

一方、渋谷店の携帯端末１００では、銀座店の携帯端末１００から着信があると、画面９０５に示すように、問い合わせ内容を明確にした着信メッセージを表示する。ここで、「Ａｎｓｗｅｒ」ボタン９５１を選択すると、返答を行ない、音声通話が開始される。一方、返答を行なわなかった場合には、画面９０６のように、どのような内容の着信があったかを、表示する。ここで「Ｃａｌｌ」ボタン９６１を選択すると、発信元としての銀座店への発呼を開始する。

以上のように、携帯端末１００のユーザは、非常に容易に業務上の問い合わせ先に対して通話を開始することができる。その場合、電話番号を調べる必要も無く、業務情報として表示された相手先を指定するのみで足りる。また、本実施形態では連携サーバ２２０が全ての個人情報を管理するため、携帯端末１００には電話番号やＳＩＰアドレスなどの重要情報が送られることはなく、情報漏洩の危険を無くすことができる。

以上のように、業務クライアント１２０は、携帯端末１００の表示部１０７に対して、業務情報と共に通話開始のトリガーとなる情報を表示して、ユーザの操作を受け付け可能とする。これにより、業務システムとコミュニケーションシステムとが適切に連携し、ユーザの操作負担を格段に軽減することが可能となる。

［テキストメッセージ送信時の処理の流れ及び第１適用例］
次に、図８を参照してテキストメッセージ送信時の処理の流れについて説明する。まず、携帯端末１００の業務クライアント１２０を起動し、図５で説明したログイン処理を行なった後、入力部１１０を用いて、外部から情報を収集する（Ｓ８１）。例えば、在庫検索を例に取ると、通話開始時と同様に図９の画面９０１を表示する。これに対してユーザは、バーコードリーダ１１１を用いて、在庫確認を行ないたい製品に付されたバーコードを読みとる。収集された情報（例えば製品番号）は、業務クライアント１２０から業務サーバ２１０の業務処理部２１１に送られる（Ｓ８２）。業務処理部２１１は、受け取った情報をもとに、不図示のデータベースなどを検索して、業務情報（例えばその製品の仕様）を導き、業務クライアント１２０に送り返す。

その結果、例えば、図９の画面９０２に示すように携帯端末１００の表示部１０７に表示される。更に、この画面で検索したい仕様が選択され、「検索」ボタンが押されると、業務サーバ２１０は、その旨を受け取って、不図示のデータベースなどを参照し、具体的な在庫検索処理を行なう。その結果は再び、携帯端末１００に送られ、図９の画面９０３が携帯端末１００の表示部１０７に表示される。

ここで、問い合わせ対象又は問い合わせ相手を指定して、テキストメッセージの送信を選択すると、業務処理部１２２は、コミュニケーション機能呼出部１２３にその旨を通知する。コミュニケーション機能呼出部１２３は、コミュニケーションクライアント１３０の各種コミュニケーション機能部１３１を呼び出す。

図９の例で言えば、「渋谷店」のボタンが選択されると、「渋谷店」へのテキストメッセージ送信を要求する旨が各種コミュニケーション機能部１３１に渡される。この時、同時に、「サイズ２３、白の製品ＡＡＡＡ」といった業務情報（製品情報）が業務処理部１２２からコミュニケーション機能呼出部１２３を介して各種コミュニケーション機能部１３１に渡される。

各種コミュニケーション機能部１３１は、送信先を指定したメッセージ送信要求、業務情報、及び、携帯端末１００自体を識別する情報（例えば業務サーバ用ユーザＩＤなど）を、連携サーバ２２０に送信する（Ｓ８５）。

連携サーバ２２０は、送信先（例えば渋谷店）を指定したメッセージ送信要求を受け取り、ユーザ情報部２２２を参照し、その送信先に紐付けられたメッセージサーバ用ユーザＩＤを導き出す。同様に、携帯端末１００自体を識別する情報を用いて、携帯端末１００のメッセージサーバ用ユーザＩＤを導き出す。導き出された情報は、表示画面生成部２２１に渡される。表示画面生成部２２１は、それらの情報を用いて、テキストメッセージサーバ２３０から、定型テキストメッセージを読み出し（Ｓ８７）、業務情報と組み合わせて、メッセージを生成し、コミュニケーション画面表示部１３２に返す（Ｓ８８）。テキストメッセージサーバ２３０には、図１１に示すようなテーブル１４０１が元々用意されている。業務サーバ２１０、連携サーバ２２０またはテキストメッセージサーバ２３０は、業務情報や送信元ユーザ情報や送信元又は送信先となる情報端末の位置情報などを元に、どの定型テキストメッセージを用いるべきか判断する。具体的には、業務情報に含まれる、問合せ元端末ＩＤ、問合せ元端末位置、問合せ内容ＩＤ、問合せ先端末ＩＤ、問合せ先端末位置、問合せ商品情報などの情報の少なくとも何れかを用いて、定型テキストメッセージを選択する。定型テキストメッセージには、状態フラグが付加されており、例えば、「緊急」、「回答要」、「回答不要」などメッセージの属性が紐付けられている。これらの属性を付加した定型テキストメッセージを送信先に送ることにより、送信先では、そのメッセージがどのような属性を持つものなのか容易に判断可能となる。定型テキストメッセージは図１１に挙げられたものに限定されるものではなく、例えば、在庫の有無を問い合わせる「Ｙｅｓ」「Ｎｏ」のチェックボックスや、図１８に示すような業務の進行具合を問い合わせるためのスライドバー１８０１を含んでもよい。このような定型テキストメッセージは送信が容易なだけでなく、受信した端末側で返信メッセージの生成を容易に行なうことができるという効果がある。

図１０を用いて具体的に説明すると、画面９０３に示したような在庫検索結果を表示する画面で送信先を指定すると、携帯端末１００において例えば画面１００１が表示され、この時点でテキストメッセージボタン１０１１が選択可能となる。テキストメッセージボタン１０１１が選択されると、連携サーバ２２０及びテキストメッセージサーバ２３０を介して、画面１００２に示すメッセージ文が生成され、携帯端末１００において表示される。送信元、送信先は、携帯端末１００において指定されたものであり、「題名、製品名、仕様（ここではサイズ及び色）」は業務情報から導き出されたものである。また、本文「在庫ありますか？Ｙｅｓ Ｎｏ 在庫が少ない場合 在庫数：」については、テキストメッセージサーバ２３０において予め用意されたものである。後は、ユーザが送信ボタン１０２１を選択するだけで、在庫確認のメッセージを送信する（Ｓ８９、Ｓ９０、Ｓ９１）。送信後は、テキストメッセージ生成前の在庫検索結果の画面１００３に戻る。このように、業務サーバ２１０及びテキストメッセージサーバ２３０が連動することにより、メッセージ送信時の作業負担を極めて小さくすることができる。

一方、メッセージを受信した端末では、業務システムを実行したまま、メッセージを受信できる。例えば、図１０の例では、画面１００４のように業務作業画面の一部にメッセージ受信アイコン１０４１を表示するように連携サーバ２２０及びコミュニケーション情報表示部１２１が処理を行なう。メッセージの属性（緊急か否か、返答が必要か否か）によってメッセージ受信アイコン１０４１の表示態様を変えてもよい。例えば、通常はメッセージ受信アイコン１０４１を黒色で表示し、緊急メッセージを受信した場合にはメッセージ受信アイコン１０４１を赤色で表示するなどの方法がある。業務作業が一段落してメッセージ確認をする際には、ユーザは、メッセージ受信アイコン１０４１をクリックする。

コミュニケーション画像表示部１３２が表示する画面の他の例を図１５に示す。図１５に示すテキストメッセージ一覧画面１５０１は、業務処理部１２２が表示する画面上での操作によって呼び出されるものである。携帯端末１００は、テキストメッセージ一覧画面１５０１を表示しつつも、裏で業務処理を行なうことができる。従って、テキストメッセージ一覧画面１５０１を閉じればすぐに業務処理に戻ることができる。テキストメッセージ一覧画面１５０１では、受信したメッセージの一覧を、受信日及び送信者と共に複数のボタンとして表示しているが、ここで、メッセージの属性に応じてそのボタンの表示態様を変更する。つまり、図１５のテキストメッセージ一覧画面１５０１では、重要（対応が必要）なメッセージは黒色のボタン１５１１で表示され、参考（情報提供）などのメッセージは灰色のボタン１５１２で表示され、その他（対応済みなど）は白色のボタン１５１３で表示される。このテキストメッセージ一覧画面１５０１は、また、複数の一覧間で表示を変えるための、「前へ」ボタン１５１４及び「次へ」ボタン１５１６の他、新規にメッセージを作成するための新規ボタン１５１５が用意されている。更に、メッセージ作成送信処理を終了する終了ボタン１５１７も用意されている。

テキストメッセージ一覧画面１５０１で、メッセージボタンをクリックすることによりユーザが何れかの受信メッセージを選択すると、その受信メッセージに対する返信メッセージ１５０２を開く。返信メッセージ１５０２は、Ｂさんに対する返信用のメッセージであるため、宛先欄に「B-san」が含まれている。メッセージ欄１５２１に記載されているのは、ＢさんがＡさんに伝えたい内容である。これに対し、その下方には、返答用定型メッセージ欄１５２２が用意されている。具体的には、「了解です。対応します。」「対応できません。」「コメント」という３つのチェックボックスが用意されており、Ａさんは基本的に上２つのチェックボックスの何れかをチェックして返信ボタン１５２３をクリックするだけで返信が完了する。

図１６に、「了解です。対応します。」のチェックボックス１６１１をチェックした場合の画面１６０１を示す。この状態で返信ボタン１６１２を選択すれば、返信が完了する。このように、Ａさんは、Ｂさんからの問い合わせに対し、チェックボックスのチェックのみの作業で非常に簡単に返信作業を行なうことができる。この返信が届けられたＢさんの携帯端末のテキストメッセージ一覧画面１６０２においては、メッセージ着信日時及び送信者を記載したボタン１６２１が新たに表示される。ここでは、ＢさんからＡさんへの「対応できますか」の問い合わせに対し、Ａさんから「対応します」とのポジティブな返答があった場合なので、返答メッセージ自体に重要性、緊急性はなく、ボタン１６２１は白色で表示される。

一方、図１７に、「対応できません」のチェックボックス１７１１ををチェックした場合の画面１６０１を示す。この状態で返信ボタン１７１２を選択すれば、返信が完了する。この返信が届けられたＢさんの携帯端末のテキストメッセージ一覧画面１７０２においては、メッセージ着信日時及び送信者（Ａ−ｓａｎ）を記載したボタン１７２１が新たに表示される。ここでは、ＢさんからＡさんへの「対応できますか」の問い合わせに対し、Ａさんから「対応できません」とのネガティブな返答があった場合なので、返答メッセージに重要性があるため、ボタン１７２１は黒色で表示される。

以上のように、定型テキストメッセージは、メッセージ送信先によってチェックされるべきチェックボックスを含む。そして、メッセージ表示手段としての表示画面生成部２２１またはコミュニケーション画面表示部１３２は、返信されてきた定型テキストメッセージに含まれるチェックボックスのチェック内容に応じて、受信した定型テキストメッセージの表示態様を変更する。表示態様の変更方法としては、図１６、図１７で説明したようにリスト内で色を変える方法の他、特別なマーク（例えば「！」「？」など）をメッセージに付して、そのメッセージの性質を表現してもよい。

携帯端末１００においてメッセージオープン操作が行なわれると、着信メッセージを表示する。本実施形態では、受信した定型テキストメッセージがそのまま返答用メッセージになっているため、「はい」、「いいえ」及び数値など、必要な事項を記入して返信すれば、応答作業を格段に軽減することができる。

例えば図１０では、画面１００４のメッセージ受信アイコン１０４１のクリックにより、画面１００５が表示される。この時点で、在庫確認対象及び送信先を指定した返答用メッセージが表示される。ここで、在庫の有無（Ｙｅｓ，Ｎｏ）と、必要ならば在庫数（ここでは３）を記入すれば返信可能となる。返信後は、元の業務画面１００５（メッセージ受信アイコン１０４１はなくなる）に戻る。

なお、本実施形態では業務情報を、携帯端末１００経由でテキストメッセージサーバ２３０に送っているが、本発明はこれに限定されるものではなく、業務サーバ２１０が携帯端末１００を特定した業務情報をテキストメッセージサーバ２３０に送ってもよい。その場合、テキストメッセージサーバ２３０は、業務サーバ２１０からの業務情報に基づいて定型テキストメッセージを選択し、連携サーバ２２０の表示画面生成部２２１に送信すればよい。

以上のように本実施形態では、音声サーバやテキストメッセージサーバへのアクセスを開始するトリガーとなる機能を業務クライアントに埋め込んだ。より具体的には、業務クライアントが携帯端末に表示するＧＵＩにおいて、「通話」や「メッセージ作成」ボタンなどを表示し、業務作業中に、具体的に相手を認識したり指定したりしなくても必要な相手とコミュニケーションを行なうことができる。

［第２適用例］
図１２を用いて、本実施形態に係る情報処理システムを医療現場に適用した場合の具体例について説明する。

まず、薬剤師の携帯端末にて処方箋の確認を行なった場合、画面１２０１が薬剤師携帯端末に表示される。ここで、投薬履歴ボタンを選択すると、画面１２０２に移り、過去に投薬された内容が表示される。画面１２０１又は画面１２０２で投薬処理ボタンが選択されると、画面１２０３が表示され、投薬処理に移る。具体的には、処方箋に記載された各薬剤について、薬剤に付されたバーコードを読み取ることにより、患者に出したこと（処理済み）を入力する。

このような投薬処理の段階で、出された薬剤について疑問がある場合には、照会ボタンを選択して、画面１２０４に移る。この時点で、照会を行ないたい薬剤を指定して、音声発信を選択すると、発呼が行なわれ、担当医師が所持する携帯端末に画面１２０５が表示される。このとき、業務情報も同時に送信することにより、医師は、どのような問い合わせが来ているのか、一目で把握できるようになる。医師は、応答できる状況であれば応答して、適切なアドバイスを薬剤師に送る。この具体例の場合であれば、ＤＥＦ剤の量が５錠から１０錠に増えていることについて、説明を行なうことができる。

一方、メール送信の場合には、医師の携帯端末に画面１２０６が表示される。この時、送信元、送信先については連携サーバ２２０が業務情報に基づいて読出す。更に、業務クライアント１２０又は業務サーバ２１０からの情報に基づいて、連携サーバ２２０がテキストメッセージサーバ２３０から読出した定型テキストメッセージを加工してメッセージ本文を生成する。このメッセージ本文は、項目の選択又は数値の入力のみで返信可能な構成となっている。本適用例の場合、ＤＥＦ剤の量が５錠から１０錠に増えていることについて確認して問題なしと返答することができる。薬剤師側では医師からの返答を受けて安心して投薬処理を行なうことができる。

以上のように本実施形態を医療現場に適用し、投薬処理や検査結果などをチェックすることで医療過誤防止と処置迅速化とを実現することができる。例えば、患者と、投与する薬双方をスキャンし、ケアレスミスによる医療ミスを防止することができる。患者の検査結果、投与記録を携帯端末で入力し、サーバにアップロードすることで、リアルタイムに情報を伝達し、現場で共有することができる。また、携帯端末に位置特定機能を付加すれば、医療スタッフの所在地をナースステーション等で確認でき、これによりスタッフの効率配置、呼び出しの効率化を実現できる。さらに、データを活用して、医療スタッフ間でのコミュニケーションの向上を図ることもできる。上述したように、携帯端末でスキャンしたデータ（検査結果、投薬結果）をもとに医療スタッフ間で相談することで、対応時間の削減、医療ミスの低減を図ることができる。さらには、医療スタッフへの全員周知事項をテキストメッセージの一斉同報で展開することもできる。

［その他の具体的適用例］
（店舗業務）
店舗業務においては業務システムを応用することで以下の用途に利用できる。
（１）商品の在庫数や在庫位置などを携帯端末によりサーバから取得。
（２）作業指示情報などをサーバから取得。
（３）発注処理情報をサーバに送信。
（４）発注状況情報をサーバから取得。
（５）常に携帯端末（従業員）の現在位置をサーバに通知
更に、店舗業務において業務システムと連携したコミュニケーションシステムを以下の用途に利用できる。
（１）本日の注意事項などをテキストメッセージで一斉通知。
（２）商品検索などでの商品情報をバーコードで読み取りテキストメッセージで送信。
（３）他店舗に在庫が存在する場合、他店舗の担当者へ在庫商品の状況確認を電話で実施。その際、商品情報を相手に知らせるために、品番をバーコード等で取得しテキストメッセージ送信。在庫商品の確保と納期確認を電話や携帯端末によるシステムへのアクセスで実施。
（４）システムだけでは理解できない不明点や現場でのアクシデント発生時に音声で連絡。
（５）商品知識の乏しいアルバイトが陳列場所や在庫有無について、バックヤードの有識者に電話にて確認。商品情報や関連URLをアルバイトの携帯端末にテキスト送信。
（６）迷子情報や関連URL情報をテキストメッセージにて一斉同報送信
（７）迷子らしき人を発見した際、電話やテキストにて管理者に連絡。同時に管理者に現在位置を通知。その人が目的の迷子かを電話やカメラにて本人確認を実施。
（８）現在混雑していない売り場従業員に対し、特売により混雑が予想されるある売り場に対するヘルプ要請を電話やテキストメッセージにて通知。OK/NGの返答を電話やテキストメッセージにて通知。

以上のような利用シーンによれば、店舗において、適切ですばやいお客様対応による顧客満足度向上及び在庫確認や発注等の業務連携による業務効率向上を図ることができる。また、能力に差がある従業員をサポートすることで等価的に全従業員の質を高め、顧客満足度を向上させることができる。

（倉庫業務）
倉庫業務においては業務システムを応用することで以下の用途に利用できる。
（１）スキャナ機能を使って入荷物品と伝票とを確認し、検品作業。
（２）他倉庫の在庫をリアルタイムに現場で確認。
（３）出庫する物品のバーコードを読み取り、出庫情報の取得、出荷管理。
（４）倉庫内の格納場所にバーコードをつけておき、バーコードを読むことで入庫物品と格納場所を対応付けて管理。

更に、倉庫業務において業務システムと連携したコミュニケーションシステムを以下の用途に利用できる。
（１）入庫作業時や検品時、数量不足や破損などを発見したとき即座に音声で管理者へ連絡。スキャナで読み込んだ物品の情報をテキストメッセージで付加。
（２）現場作業者への音声指示。
（３）在庫不足時に発注は音声、さらにデータで物品情報を付加して送信。

以上のような利用シーンによれば、格納管理や在庫管理、ピッキングの容易性向上、発注ミスの低減を図ることができる。

（フィットネスセンター）
フィットネスセンターにおいて業務システムを応用することで以下の用途に利用できる。
（１）インストラクターが携帯端末を携帯して、利用者はバーコードが付されたリストバンドを身につける。携帯端末でバーコードを読み込み、習熟度や健康状態をサーバから入手。機器の使用方法や負荷について、適切なアドバイスを行う。
（２）施設予約、予約確認をサーバに問い合わせて、利用情報を利用者に提供する。

更に、フィットネスセンターにおいて業務システムと連携したコミュニケーションシステムを以下の用途に利用できる。
（１）未熟なインストラクターは、熟練インストラクターに通話し、適切なアドバイスをしてもらう。

また、機器に携帯端末を接続して、利用者が自ら携帯端末を使用できるようにしてもよい。以上のような利用シーンによれば、フィットネスセンターは、きめ細かいサービスを利用者に提供することが可能となる。

（第３実施形態）
図１３を用いて、本発明の第３実施形態としての情報処理システムについて説明する。情報処理システム自体の構成については、第２実施形態とほぼ同様であるため、同じ構成には同じ符号を付して説明を省略する。

本実施形態では第２実施形態と異なり、コミュニケーション機能呼出部１２３は、業務サーバ２１０のコミュニケーション機能呼出部２１３にコミュニケーションの開始要求を通知する。具体的な処理の流れについて以下に説明する。

まず、図９の画面９０３、画面９０４のような業務情報表示画面に対し、テキストメッセージによる問い合わせのトリガーとなる操作を受け付けると、業務処理部１２２は、コミュニケーション機能呼出部１２３にその旨を通知する（Ｓ７３）。次に、コミュニケーション機能呼出部１２３は、コミュニケーションクライアント１３０ではなく、業務サーバ２１０のコミュニケーション機能呼出部２１３にコミュニケーションの開始要求を通知する（Ｓ１３３）。

コミュニケーション機能呼出部２１３は、この要求を受けて、業務情報と発信元情報と発信先情報と（例えば銀座店と渋谷店といった情報）をテキストメッセージサーバ２３０に送信する（Ｓ１３４）。テキストメッセージサーバ２３０は、これらの情報を連携サーバ２２０に送信して、図６に示したユーザ情報部２２２内のテーブル６００を参照して、送信元と送信先のテキストメッセージサーバ用ユーザＩＤを求める（Ｓ１３５）。それらのユーザＩＤは、表示画面生成部２２１に渡される（Ｓ１３６）。また、同時にテキストメッセージサーバ２３０は、携帯端末１００がテキストメッセージを送信するための表示画面の生成を要求する（Ｓ１３７）。

テキストメッセージサーバ２３０に用意された図１１に示すようなテーブル１４０１に含まれる複数の定型テキストメッセージから、連携サーバ２２０が最適な定型テキストメッセージを選択する。具体的には、業務情報に含まれる、問合せ元端末ＩＤ、問合せ元端末位置、問合せ内容ＩＤ、問合せ先端末ＩＤ、問合せ先端末位置、問合せ商品情報などの情報の少なくとも何れかを用いて、定型テキストメッセージを選択する。定型テキストメッセージには、状態フラグが付加されており、例えば、「緊急」、「回答要」、「回答不要」などメッセージの属性が紐付けられている。これらの属性を付加した定型テキストメッセージを送信先に送ることにより、送信先では、そのメッセージがどのような属性を持つものなのか容易に判断可能となる。

表示画面生成部２２１は、選択された定型テキストメッセージと送信元と送信先の情報とを組み合わせて、携帯端末１００のメール作成画面に表示する表示画面を生成して、携帯端末１００に送信する（Ｓ１３８）。携帯端末１００では、表示されたメッセージを確認して、必要に応じて内容を追加し、送信指示をテキストメッセージサーバ２３０に送る。テキストメッセージサーバ２３０は、その送信指示に答えて、指定された送信先に対して、テキストメッセージを送信する（Ｓ１４０）。

図１４は、メッセージの送信処理の流れを説明するために簡略化した図である。図１４に示すように、業務サーバ２１０では、業務情報として、送信元端末ＩＤ、送信元端末位置、送信先端末ＩＤ、送信先端末位置、送信するテキストメッセージに関する業務内容などの少なくとも何れかを連携サーバ２２０に送る。この時、業務情報として、同報送信用に複数の送信先をまとめたグループを特定してもよい。そして、そのような業務情報を用いて、定型テキストメッセージデータベース１４０１から最適なテキストメッセージを選択させる。この選択処理は連携サーバ２２０に限定されず、業務サーバ２１０またはテキストメッセージサーバ２３０が行なってもよい。連携サーバ２２０は、また、送信元と送信先のテキストメッセージ送受信用アドレスを特定し、選択された定型テキストメッセージを用いて、携帯端末１００に表示するメッセージ送信送信用画面を生成する。

携帯端末１１０は、連携サーバ２２０が生成したメッセージ送信送信用画面を表示して適宜内容を補充した上で、送信依頼を行なう。テキストメッセージサーバ２３０は、携帯端末１１０から受け取った送信依頼に基づいて、テキストメッセージを送信する。

以上の通り、本実施形態によれば、携帯端末が「この業務に関連するテキストメッセージを送りたい」とリクエストするだけで、「相手先の特定」及び「定型テキストメッセージの選択」を全てサーバ側で行なう。そのため、メッセージの送信作業を非常に迅速に行なうことが可能となる。また更に、定型テキストメッセージ自体に返信のための選択肢が含まれているため、受信した端末が非常に容易に返信メッセージを送信できるという効果もある。

（他の実施形態）
以上、本発明の実施形態について詳述したが、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステム又は装置も、本発明の範疇に含まれる。

また、本発明は、複数の機器から構成されるシステムに適用しても良いし、単体の装置に適用しても良い。さらに、本発明は、上記実施形態の機能を実現する情報処理プログラムが、システム或いは装置に直接或いは遠隔から供給される場合にも適用可能である。したがって、本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、或いはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるＷＷＷサーバも、本発明の範疇に含まれる。

［実施形態の他の表現］
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
携帯端末からのリクエストに応じて、業務情報を取得する取得手段と、
複数の定型テキストメッセージを記憶する記憶手段と、
前記複数の定型テキストメッセージから、前記取得手段を用いて取得された前記業務情報に対応する定型テキストメッセージを選択する選択手段と、
前記取得手段を用いて取得された前記業務情報に対応するメッセージ送信先を決定する決定手段と、
前記選択手段よって選択された定型テキストメッセージを、前記決定手段によって決定されたメッセージ送信先に対して、送信する送信手段と、
を備えたことを特徴とする情報処理システム。
（付記２）
前記取得手段を含む業務サーバと、
前記記憶手段を含むテキストメッセージサーバと、
前記決定手段を含む連携サーバと、
を備えたことを特徴とする付記１に記載の情報処理システム。
（付記３）
前記テキストメッセージサーバがさらに前記選択手段を有することを特徴とする付記２に記載の情報処理システム。
（付記４）
前記業務サーバがさらに前記選択手段を有することを特徴とする付記２に記載の情報処理システム。
（付記５）
前記連携サーバがさらに前記選択手段を有することを特徴とする付記２に記載の情報処理システム。
（付記６）
前記定型テキストメッセージは、前記メッセージ送信先によって選択されるべき選択肢を含むことを特徴とする付記１乃至５のいずれか１項に記載の情報処理システム。
（付記７）
前記定型テキストメッセージは、前記メッセージ送信先によってチェックされるべきチェックボックスを含むことを特徴とする付記１乃至６のいずれか１項に記載の情報処理システム。
（付記８）
前記定型テキストメッセージは、前記メッセージ送信先によって操作されるべきスライドバーを含むことを特徴とする付記１乃至７のいずれか１項に記載の情報処理システム。
（付記９）
前記定型テキストメッセージの状態に応じて、前記メッセージ送信先が受信した前記定型テキストメッセージの表示方法を変更するメッセージ表示手段を更に備えたことを特徴とする付記１乃至８のいずれか１項に記載の情報処理システム。
（付記１０）
前記定型テキストメッセージの状態とは前記定型テキストメッセージの重要度であることを特徴とする付記９に記載の情報処理システム。
（付記１１）
前記定型テキストメッセージは、前記メッセージ送信先によってチェックされるべきチェックボックスを含み、
前記メッセージ表示手段は、返信された前記定型テキストメッセージに含まれるチェックボックスのチェック内容に応じて、受信した前記定型テキストメッセージの表示態様を変更することを特徴とする付記９または１０に記載の情報処理システム。
（付記１２）
業務情報を取得し、予め記憶された複数の定型テキストメッセージから、取得された前記業務情報に対応する定型テキストメッセージを選択する選択手段と、
前記業務情報に対応するメッセージ送信先を決定する決定手段と、
前記選択手段よって選択された定型テキストメッセージを、前記決定手段によって決定されたメッセージ送信先に対して、送信するためのメッセージ送信画面を生成する生成手段と、
を備えたことを特徴とする連携サーバ。
（付記１３）
前記定型テキストメッセージの状態に応じて、前記メッセージ送信先が受信した前記定型テキストメッセージの表示方法を変更するメッセージ表示手段を更に備えたことを特徴とする付記１２に記載の連携サーバ。
（付記１４）
業務サーバにおいて業務情報を取得する業務情報取得ステップと、
選択手段が、予め記憶された複数の定型テキストメッセージから、取得された前記業務情報に対応する定型テキストメッセージを選択する選択ステップと、
決定手段が、前記業務情報取得ステップで取得した業務情報の少なくとも一部を用いて、テキストメッセージの送信先を決定する決定ステップと、
決定した前記送信先に対して、選択した前記定型テキストメッセージを送信する送信ステップと、
を含むことを特徴とする情報処理方法。
（付記１５）
業務サーバにおいて業務情報を取得する業務情報取得ステップと、
選択手段が、予め記憶された複数の定型テキストメッセージから、取得された前記業務情報に対応する定型テキストメッセージを選択する選択ステップと、
決定手段が、前記業務情報取得ステップで取得した業務情報の少なくとも一部を用いて、テキストメッセージの送信先を決定する決定ステップと、
決定した前記送信先に対して、選択した前記定型テキストメッセージを送信する送信ステップと、
をコンピュータに実行させることを特徴とする情報処理プログラム。

Claims (15)

1. 携帯端末から入力された業務用ユーザＩＤを使用して、前記携帯端末からのリクエストに応じて、業務情報を取得する取得手段と、
   複数の定型メッセージを記憶する記憶手段と、
   前記複数の定型メッセージから、前記取得手段を用いて取得された前記業務情報に含まれる業務内容に対応する定型メッセージを選択する選択手段と、
   前記携帯端末の前記業務用ユーザＩＤを前記携帯端末のメッセージ送信元ユーザＩＤに変換すると共に、前記取得手段を用いて取得された前記業務情報に含まれる問合せ先に対応するメッセージ送信先ユーザＩＤを決定する決定手段と、
   前記選択手段よって選択された定型メッセージを、前記決定手段によって決定された前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して、送信する送信手段と、
   を備えたことを特徴とする情報処理システム。
2. 取得した前記業務情報と選択した前記定型メッセージとを組み合わせて、メッセージ送信画面を生成する生成手段を更に備え、
   前記送信手段は、生成された前記メッセージ送信画面を、前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して、送信することを特徴とする請求項１に記載の情報処理システム。
3. 前記取得手段を含む業務サーバと、
   前記記憶手段を含むテキストメッセージサーバと、
   前記決定手段を含む連携サーバと、
   を備えたことを特徴とする請求項１または２に記載の情報処理システム。
4. 前記定型メッセージは、前記問合せ先によって選択されるべき選択肢を含むことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記定型メッセージは、前記問合せ先によってチェックされるべきチェックボックスを含むことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
6. 前記定型メッセージは、前記問合せ先によって操作されるべきスライドバーを含むことを特徴とする請求項１乃至５のいずれか１項に記載の情報処理システム。
7. 前記定型メッセージの状態に応じて、前記問合せ先が受信した前記定型メッセージの表示方法を変更するメッセージ表示手段を更に備えたことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
8. 前記定型メッセージの状態とは前記定型メッセージの重要度であることを特徴とする請求項７に記載の情報処理システム。
9. 前記定型メッセージは、前記問合せ先によってチェックされるべきチェックボックスを含み、
   前記メッセージ表示手段は、返信された前記定型メッセージに含まれるチェックボックスのチェック内容に応じて、受信した前記定型メッセージの表示態様を変更することを特徴とする請求項７または８に記載の情報処理システム。
10. 携帯端末から入力された業務用ユーザＩＤおよび業務情報を取得し、予め記憶された複数の定型メッセージから、取得された前記業務情報に含まれる業務内容に対応する定型メッセージを選択する選択手段と、
    前記携帯端末の業務用ユーザＩＤを前記携帯端末のメッセージ送信元ユーザＩＤに変換すると共に、前記業務情報に含まれる問合せ先に対応するメッセージ送信先ユーザＩＤを決定する決定手段と、
    前記選択手段よって選択された定型メッセージを、前記決定手段によって決定された前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して送信するための、メッセージ送信画面を生成する生成手段と、
    を備えたことを特徴とする連携サーバ。
11. 前記生成手段は、取得した前記業務情報と選択した前記定型メッセージとを組み合わせて、前記メッセージ送信画面を生成することを特徴とする請求項１０に記載の連携サーバ。
12. 前記定型メッセージの状態に応じて、前記問合せ先が受信した前記定型メッセージの表示方法を変更するメッセージ表示手段を更に備えたことを特徴とする請求項１０または１１に記載の連携サーバ。
13. 前記定型メッセージは、前記問合せ先によってチェックされるべきチェックボックスを含み、
    前記メッセージ表示手段は、返信された前記定型メッセージに含まれるチェックボックスのチェック内容に応じて、受信した前記定型メッセージの表示態様を変更することを特徴とする請求項１２に記載の連携サーバ。
14. 業務サーバにおいて、携帯端末から入力された業務用ユーザＩＤを使用して業務情報を取得する業務情報取得ステップと、
    選択手段が、予め記憶された複数の定型メッセージから、取得された前記業務情報に含まれる業務内容に対応する定型メッセージを選択する選択ステップと、
    決定手段が、前記携帯端末の業務用ユーザＩＤを前記携帯端末のメッセージ送信元ユーザＩＤに変換すると共に、前記業務情報取得ステップで取得した業務情報に含まれる問合せ先を用いて、メッセージのメッセージ送信先ユーザＩＤを決定する決定ステップと、
    前記決定ステップにおいて決定した、前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して、選択した前記定型メッセージを送信する送信ステップと、
    を含むことを特徴とする情報処理方法。
15. 業務サーバにおいて、携帯端末から入力された業務用ユーザＩＤを使用して業務情報を取得する業務情報取得ステップと、
    選択手段が、予め記憶された複数の定型メッセージから、取得された前記業務情報に含まれる業務内容に対応する定型メッセージを選択する選択ステップと、
    決定手段が、前記携帯端末の業務用ユーザＩＤを前記携帯端末のメッセージ送信元ユーザＩＤに変換すると共に、前記業務情報取得ステップで取得した業務情報に含まれる問合せ先を用いて、メッセージのメッセージ送信先ユーザＩＤを決定する決定ステップと、
    前記決定ステップにおいて決定した、前記メッセージ送信元ユーザＩＤを有する前記携帯端末から前記メッセージ送信先ユーザＩＤを有する前記問合せ先に対して、選択した前記定型メッセージを送信する送信ステップと、
    をコンピュータに実行させることを特徴とする情報処理プログラム。

Images