JP2013544461A - イベント処理方法及び装置 - Google Patents

Abstract

本発明は、端末に適用するイベント処理方法と装置を開示している。前記端末に、前記端末におけるアプリケーションの各状態および各状態での所望イベントを設置しており、前記方法において、端末はサーバの下りイベントを受信すると、前記端末の現在業務のアプリケーションの状態に基づいて、前記下りイベントがこの状態での所望イベントであるかどうかを判断し、前記下りイベントがこの状態での所望イベントであると判断された場合に、前記下りイベントを前記アプリケーションへ送信して、前記アプリケーションの状態を更新することを含む。本発明によれば、端末の業務の実行成功率を向上させることができる。

Description

本願は、2010年10月26日に中国知識産権局へ提出した出願番号201010527311.5、発明の名称「イベント処理方法及び装置」の中国出願に基づく優先権を主張しており、その全ての内容を引用することにより、本願に組み込まれる。

本発明は、通信技術分野に関し、特にイベント処理方法及び装置に関する。

オーバーザエアダウンロード（OTA：Over The Air）のアプリケーションとは、ショートメッセージメカニズムに基づき、携帯電話端末とサーバとの間のやり取りにより、ユーザにカスタマイズ化情報サービスを取得させるデータ付加価値な業務である。OTAアプリケーションが携帯電話端末、加入者識別モジュール（SIM：Subscriber Identity Module）カード、或いは汎用加入者識別モジュール（USIM：Universal Subscriber Identity Module）カードに記憶され、業務メニューの動的なダウンロード、削除或いは更新を実現できる。例えば、携帯電話端末における携帯電話チケットアプリケーションは、ショートメッセージ或いは汎用パケット無線サービス（GPRS: General Packet Radio Service)方式により、サーバとのチケットの注文と、チケットの取りと、チケットの返しなどの業務を行う。

携帯電話端末とサーバとの間の一次業務は、通常いくつかのシグナルのやり取りによって完成しかできない、そして、上記業務は、ショートメッセージ下り（MT, Mobile Terminated）、或いは、ショートメッセージ上り（Mobile Originated）方式により実現される。図1に従来技術における携帯電話端末とサーバとのシステム構造を示す。携帯電話端末におけるOTAアプリケーションがMO方式によりサーバへ業務要求を送信した後、OTAアプリケーションがサーバの応答を待つ状態となり、サーバにおけるアプリケーションプロセッサからの業務応答を受信した後、携帯電話端末が業務を終了し、アイドル状態となる。サーバは、MT方式により端末へ業務指令を送信して、端末におけるOTAアプリケーションが業務指令を受信した後、サーバへ応答を返信してサーバからの応答を待つ状態となり、サーバからの業務応答を受信した後、業務を終了し、アイドル状態となるようにしてもよい。

本発明を実現する段階において、従来技術に、非同期な通信方式を用いるため、サーバは、リアルタイムに携帯電話端末からのショートメッセージを受信することを確保できない、更に、信頼度も低く、ショートメッセージを無くしやすい、サーバは、MT方式により携帯電話端末へ送信した業務指令が携帯電話端末で実行中のMO方式の業務を中断させるため、OTAアプリケーションの実行成功率を低減させる。また、携帯電話端末における業務プロセスにおいて、MO方式により新たな業務を起こすと、一つ前の業務を中断させるため、同様に、OTAアプリケーションの実行成功率を低減させる。

本発明は、端末におけるアプリケーションの実行成功率を上げるためのイベント処理方法及び装置を提供することを目的とする。この目的を実現するために、本発明は、以下のように構成される。

端末におけるアプリケーションの各状態及び各状態での所望イベントが設置される前記端末に適用するためのイベント処理方法において、
端末は、サーバの下りイベントを受信すると、前記端末の現在業務のアプリケーションの状態に基づき、前記下りイベントがこの状態での所望イベントであるかどうかを判断し、前記下りイベントがこの状態での所望イベントであると判断された場合に、前記下りイベントを前記アプリケーションへ送信して、前記アプリケーションの状態を更新することを含む。

端末におけるアプリケーションの各状態及び各状態での所望イベントが設置されるサーバに適用するためのイベント処理方法において、
前記サーバは、前記端末の現在業務のアプリケーションの状態に基づいて、前記サーバにより生成された下りイベントがこの状態での所望イベントであるかどうかを判断することと、前記サーバは、前記下りイベントがこの状態での所望イベントであると判断された場合に、前記端末に前記下りイベントを送信することとを含む。

端末において、
前記端末におけるアプリケーションの各状態及び各状態での所望イベントを記憶する状態機コントローラと、
サーバの下りイベントを受信する受信モジュールと、
前記端末の現在業務のアプリケーションの状態に基づいて、前記下りイベントがこの状態での所望イベントであるかどうかを判断する判断モジュールと、
前記判断モジュールにより前記下りイベントがこの状態での所望イベントであると判断された場合に、前記下りイベントを前記アプリケーションへ送信して、前記アプリケーションを更新する処理モジュールとを含む。

サーバにおいて、
下りイベントを生成する生成モジュールと、
端末におけるアプリケーションの各状態及び各状態での所望イベントを記憶する状態機コントローラと、
前記端末の現在業務のアプリケーションの状態に基づいて、前記生成モジュールにより生成された下りイベントがこの状態での所望イベントであるかどうかを判断する判断モジュールと、
前記判断モジュールにより前記下りイベントがこの状態での所望イベントであると判断された場合に、前記下りイベントを前記端末へ送信する処理モジュールとを含む。

従来技術に比べて、本発明は、端末の現在業務のアプリケーションの状態に基づいて、このアプリケーションへ送信する下りイベントを選択することによって、端末の現在業務を中断させることを避けることができ、端末の業務の実行成功率を向上できるという利点がある。

従来技術における端末とサーバとの構造図である。 本発明の実施形態における端末とサーバとの構造図である。 本発明の実施形態1におけるイベント処理方法のフローチャートである。 本発明の実施形態の端末におけるアプリケーションの状態の更新を示す模式図。 本発明の実施形態2におけるイベント処理方法のフローチャートである。 本発明の実施形態3におけるイベント処理方法のフローチャートである。 本発明の実施形態4における端末の構成図である。 本発明の実施形態5におけるサーバの構成図である。

本発明の実施形態により提供される技術案において、端末に、この端末のアプリケーション毎の各状態及び各状態での所望イベントが設置され、端末はサーバの下りイベントを受信すると、この端末の現在業務のアプリケーションの状態に基づいて、下りイベントがこの状態での所望イベントであるかどうかを判断し、下りイベントがこの状態での所望イベントであると判断された場合に、この下りイベントを前記アプリケーションへ送信して、このアプリケーションの状態を更新する。端末は、上りイベントを生成すると、この端末の現在業務のアプリケーションの状態に基づいて、上りイベントがこの状態での所望イベントであるかどうかを判断し、この上りイベントがこの状態での所望イベントであると判断された場合に、この上りイベントをサーバへ送信して、前記アプリケーションの状態を更新する。

サーバに端末のアプリケーションの各状態及び各状態での所望イベントを設置し、サーバは、端末の現在業務のアプリケーションの状態に基づいて、このサーバにより生成された下りイベントがこの状態での所望イベントであるかどうかを判断し、サーバは下りイベントがこの状態での所望イベントであると判断された場合に、この下りイベントを端末へ送信するようにしてもよい。この二つの技術案を組み合わせて使用しても良い。

以下、本発明の図面に従って、本発明の技術案を詳しく説明する。説明する実施形態は、あくまでも本発明の実施形態の一部であり、全ての実施形態ではないことが言うまでもない。当業者は本発明の実施形態に基づいて、創造的な労働なしで生み出したその他の実施形態は、全て本発明に請求された範囲に属する。

図２に本発明の実施形態における端末とサーバとの構造図を示す。端末は、自身のアプリケーションに対して状態機コントローラを設置して、この状態機コントローラにより端末におけるアプリケーションの状態を保守し、アプリケーションの状態に基づいて、受信した下りイベントがこの状態での所望イベントであると特定した場合に、この下りイベントを端末におけるアプリケーションへ送信することと、生成された上りイベントがこの状態での所望イベントである場合に、この上りイベントをサーバへ送信することによって、端末側における処理によって、端末におけるアプリケーションの実行成功率を向上できる。サーバは、端末におけるアプリケーションに対して状態機コントローラを設置して、この状態機コントローラにより端末のアプリケーションの現在の状態を記録し、生成された下りイベントがこの端末のアプリケーションの現在の状態での所望イベントである場合に、生成された下りイベントを端末へ送信することにより、サーバ側における処理によって、端末におけるアプリケーションの実行成功率を向上できる。

図３に本発明の実施形態1におけるイベント処理方法のフローチャートを示す。このフローチャートにおいて、端末に状態機コントローラが設置され、状態機コントローラに端末におけるアプリケーションの各状態及び各状態での所望イベントが設置されている。端末は、MO方式或いはMT方式により現在あるアプリケーションを起動した。本実施形態において、携帯電話チケットアプリケーションを例にして、図に示すように、このフローにおいて、以下のステップを含む。

ステップ301において、端末はサーバの下りイベントを受信する。

ステップ302において、端末は、携帯電話チケットアプリケーションの状態に基づいて、受信した下りイベントがこの状態での所望イベントであるかどうかを判断する、判断の結果、所望イベントである場合に、ステップ303へ移行し、所望イベントではない場合に、ステップ304へ移行する。

具体的に、端末における状態機コントローラは、携帯電話チケットアプリケーションの状態に基づいてこの状態での所望イベントを特定できる、そして、受信した下りイベントが所望イベントであるかどうかを判断する。端末のアプリケーションの状態での所望イベントは一種の下りイベントであってもよいし、多種の下りイベントであってもよい。

ステップ303において、端末は、受信した下りイベントを携帯電話チケットアプリケーションへ送信して、携帯電話チケットアプリケーションの状態を更新する。

具体的に、端末は、受信した下りイベントを携帯電話チケットアプリケーションへ送信した後、携帯電話チケットアプリケーションの状態を更新しても良いし、携帯電話チケットアプリケーションから返答される、アプリケーションが下りイベントに基づく処理に成功したことを示す応答情報を受信した後、携帯電話チケットアプリケーションの状態を更新しても良い。端末における状態機コントローラは、携帯電話チケットアプリケーションから返答される、アプリケーションが下りイベントに基づく処理に失敗したことを示す応答情報を受信した、或いは、予定の時間に携帯電話チケットアプリケーションからの応答情報を受信していない場合に、端末は、携帯電話チケットアプリケーションの状態を維持する。

端末における状態機コントローラは、図４に示す状態更新模式図にしたがって、端末におけるアプリケーションの状態を更新できる。端末におけるアプリケーションがアイドル状態であり、且つ受信した下りイベントが業務1に対するMT指令であるとき、状態機コントローラは、アプリケーションの状態を業務1状態に更新し、端末におけるアプリケーションが業務1進行中状態であり、且つ受信した下りイベントが業務1に対する業務応答であるとき、状態機コントローラは、まずアプリケーションの状態を業務1完了状態に更新してから、更にアイドル状態に更新できる。端末におけるアプリケーションがアイドル状態であり、且つ受信した下りイベントが業務応答であるとき、このアプリケーションの状態を維持する。端末におけるアプリケーションは、業務1進行中状態であり、且つ受信した下りイベントがその他の業務に対するMT指令であるとき、このアプリケーションの状態を維持する。

ステップ304において、端末は、受信した下りイベントを放棄して、サーバへ携帯電話チケットアプリケーションの、明確には携帯電話チケットアプリケーションの現在の状態を示す直接状態情報（例えば、状態名称や識別子）、或いはサーバにより基づかれ携帯電話チケットアプリケーションの現在の状態を特定できる間接状態情報（例えば、最後にサーバへ送信した上りイベントの識別子や名称、或いはイベント内容など）である状態情報が付された通知メッセージを送信する。

本発明の実施形態において、端末のOTA機能が無効になることに対して、端末は、データライン、RFID、BLUETOOTH（登録商標）、赤外線、WiFiなどの候補方式によりサーバとのやり取りをおこなうことができる。端末は、業務進行中状態にある場合に、上記候補方式により、端末のアプリケーションの状態情報をサーバへ通知できる。

説明する必要があるのは、本発明の実施形態におけるステップ305は望ましいステップであり、本発明の他の実施形態において、端末は、受信した下りイベントが端末におけるアプリケーションの所望イベントではないと判断された場合に、この下りイベントを放棄することとサーバへ通知メッセージを送信することとの以外の操作を実行できる。例えば、この下りイベントに応答せず、前回にサーバへ送信した上りイベントを再度サーバへ送信することにより、同様にイベント処理の目的を達成できる。

本発明の実施形態において、端末は、アプリケーションインタフェースによりユーザにリトライオプションと取消オプションを提供できる。ユーザは、リトライオプションを選択すると、端末は、ユーザにより提出された再送指令に従い、既にサーバへ送信した上りイベントを再度このサーバへ送信する。ユーザは取消オプションを選択すると、端末は、ユーザにより提出された状態取消指令に従い、サーバへ取消要求を送信し、携帯電話チケットアプリケーションを前の状態へ戻させる、或いは、直ちにアイドル状態へ戻させる。具体的に、端末は、サーバへ取消要求を送信した後、直ちに携帯電話チケットアプリケーションを前の状態或いはアイドル状態へ戻させても良いし、サーバから返答される取消応答を受信した後、携帯電話チケットアプリケーションを前の状態或いはアイドル状態へ戻させてもよい。

また、端末は、アプリケーションインタフェースにより携帯電話チケットアプリケーションの状態と端末からサーバへ送信した上りイベントの内容を表示できる。例えば、携帯電話チケットアプリケーションの状態に、アイドル状態、STKチケット注文状態、STKチケット返し状態とSTKチケット取り状態が含まれる。端末からサーバへ送信した上りイベントは、チケット書き指令、ネットワークチケット注文の確認要求指令、チケット取り・チケット書き指令、チケット取消指令などが含まれる。

本発明の実施形態は、携帯電話チケットアプリケーションを例にして本発明の技術案を説明したが、説明する必要があるのは、本発明の実施形態の技術案が端末の他のアプリケーション、例えば、携帯電話財布アプリケーションなどにも同様に適用できる。

本発明の実施形態において、端末の現在業務のアプリケーションの状態に基づいて、このアプリケーションに送信する下りイベントを選択することにより、端末の現在業務をサーバの下りイベントに中断されることを避けられ、端末の現在業務のアプリケーションの状態をサーバへミラーリングすることにより、端末の現在業務の実行中に、サーバにより新たなMT指令を配布することを避けられ、端末の業務の実行成功率を向上できると言う利点がある。本発明の実施形態を実施するいずれもの製品が必ずしも上記のすべての利点を達成する必要がないことはいうまでもない。

図５に本発明の実施形態２におけるイベント処理方法のフローチャートを示す。このフローにおいて、端末に状態機コントローラが設置され、状態機コントローラに端末に置けるアプリケーションの各状態および各状態での所望イベントが設置されている。端末は、MO方式あるいはMT方式により、現在あるアプリケーションを起動した。本実施形態に、携帯電話チケットアプリケーションを例として、以下のステップが含まれる。

ステップ５０１において、端末は、上りイベントを生成する。

ステップ５０２において、端末は、端末の携帯電話チケットアプリケーションの状態に基づいて、このアプリケーションにより生成された上りイベントは、この状態での所望イベントであるかどうかを判断する。判断の結果は、所望イベントである場合に、ステップ５０４へ移行する。所望イベントではない場合に、ステップ５０３に移行する。

具体的に、端末における状態機コントローラは、携帯電話チケットアプリケーションの状態に基づいて、この状態での所望イベントを特定し、携帯電話チケットアプリケーションにより生成された上りイベントは所望イベントであるかどうかを判断できる。また、端末のアプリケーションの状態での所望イベントは一種あるいは多種の上りイベントであっても良い、この上りイベントはサーバへ送信しても、現在業務を中断させない。

端末におけるアプリケーションにより生成された上りイベントは要求イベントであってもよい。異なる要求イベントの間には排他的な関係があってもよい。端末は、現在業務の実行中に、サーバへ現在業務の要求イベントとの関係が排他的な関係である要求イベントを送信すると、現在業務を中断する。したがって、端末における状態機コントローラは、現在業務との関係が排他的な関係である要求イベントを現在業務のアプリケーションの状態での非所望イベントに設置する。アプリケーションがこの要求イベントを生成すると、状態機コントローラはこの要求イベントがこの状態での所望イベントではないと判断する。

ステップ５０３において、端末は、上りイベントの送信を拒否する。

ステップ５０４において、端末は、上りイベントをサーバへ送信して、携帯電話チケットアプリケーションの状態を更新する。

具体的に、端末は、上りイベントをサーバへ送信する前に、アプリケーションの状態を更新してもよく、上りイベントをサーバへ送信する後に、アプリケーションの状態を更新してもよい。端末における状態機コントローラは、図４に示す状態更新模式図にしたがって端末におけるアプリケーションの状態を更新できる。端末におけるアプリケーションはアイドルであり、且つサーバへ送信した上りイベントは業務１に対するMO要求である場合に、状態機コントローラは、アプリケーションの状態を業務１の状態に更新する、端末におけるアプリケーションは、業務１進行中状態であり、かつサーバへ送信した上りイベントは業務１に対する取消要求である場合に、状態機コントローラは、まず、アプリケーションの状態を業務１終了状態に更新して、さらにアイドル状態に更新する。端末におけるアプリケーションは業務１進行中状態であり、且つサーバへ送信した上りイベントはその他の業務に対するMO要求である場合に、アプリケーションの情報が変化しない。

本発明の実施形態において、ユーザの操作により端末の現在業務のアプリケーションに入る際に、端末は、アプリケーションインタフェースにより現在業務のアプリケーションの状態を表示し、リトライと取消の二つのオプションを提供する。ユーザはリトライを選択すると、端末は、サーバへ前の業務要求を再送信し、サーバは再送信された業務要求を受信すると、端末へ業務応答を送信する。ユーザは、取消を選択すると、端末は、サーバへ現在業務に対する取消要求を送信して、アイドル状態へ戻ってもよい、サーバからの取消応答を受信した際に、アイドル状態へ戻っても良い。

携帯電話チケットを例として、端末におけるアプリケーションが、下りイベントを受信するあるいは上りイベントを送信した後の状態変化を表１に示す。

携帯電話チケットアプリケーションの状態変化表

ただし、表１の１行目に、携帯電話チケットアプリケーションは下りイベントを受信する、あるいは上りイベントを送信するときの状態を表し、表１の１列目に受信した下りイベントあるいは送信した上りイベントを表し、表１の他の内容は、携帯電話チケットアプリケーションが下りイベントを受信する、あるいは上りイベントを送信した後の状態を表す。N/Aは、携帯電話チケットアプリケーションが受信した下りイベント、あるいは送信した上りイベントが無効であることを表し、携帯電話アプリケーションが該当する指令を実行しないし、応答も返答しない。

携帯電話アプリケーションが業務進行中状態であるとき、ユーザは、一段目のメニュー「携帯電話チケット券」に入り、携帯電話アプリケーションが待ち中の処理の現在のSTK業務を表示し、内容は、「ただいま、XXXX（ネットワークチケット注文、チケット取り、或いは、チケット返し）業務が処理中です。戻り、待ち続きを選択できる、或いは、確認、再送を選択できます」。ユーザは再送を選択すると、携帯電話チケットアプリケーションは、ローカル業務要求をサーバへ再度送信し、ローカル業務要求を送信した後、２段目のメニューへ入る。ユーザが戻りを選択すると、携帯電話チケットアプリケーションは、２段目のメニューを直ちに行う。

また、本発明の実施形態におけるステップ５０３は望ましいステップであり、本発明のその他の実施形態において、端末は自身のアプリケーションにより生成された上りイベントをサーバへ送信することが許可されないと判断される場合に、上りイベントの送信の拒否を除く他の操作を施行してもよい、例えば、この下りイベントを放棄することにより、イベント処理の目的にも達成できる。

本発明の実施形態は携帯電話チケットアプリケーションを例にして、本発明の技術案を記述したが、本発明の実施形態の技術案は、端末における他のアプリケーションにも同様に適用でき、例えば、携帯電話財布アプリケーションなどにも適用できる。

本発明は、端末の現在業務のアプリケーションの状態に基づいて、サーバへ送信する上りイベントを選択するため、サーバへ送信する上りイベントにより端末の現在業務を中断させることを避けられ、また、端末は、現在業務のアプリケーションの状態を表示でき、そして、ユーザに再送MO指令と取消MO指令の選択を提供するため、ユーザの操作の誤りを低減させ、端末の業務の実行成功率を向上させるという利点がある。本発明の実施形態を実施するいずれかの製品は、同時に上記のすべての利点を有する必要がないことはいうまでもない。

図６に本発明の実施形態３におけるイベント処理方法のフローチャートを示す。このフローチャートにおいて、サーバに状態機コントローラが設置され、状態機コントローラに、端末におけるアプリケーションの各状態および各状態での所望イベントが設置されている。端末は、MO方式或いはMT方式により現在あるアプリケーションを起動した。サーバは、端末により送信した現在業務のアプリケーションの、現在業務のアプリケーションの状態を明確に示す直接状態情報（例えば状態名称や識別子）、或いはサーバにより基づかれ現在業務のアプリケーションの状態を特定できる間接な状態情報（例えば、前回にサーバへ送信した上りイベントの識別子や名称或いはイベント内容等）である状態情報が付された通知メッセージ、或いは現在業務のアプリケーションの上りイベントを受信すると、このアプリケーションの状態を更新する。本実施形態において、以下のステップを含む。

ステップ６０１において、サーバは下りイベントを生成する、

ステップ６０２において、サーバは端末の現在業務のアプリケーションの状態に基づいて、このサーバにより生成された下りイベントがこの状態での所望イベントであるかどうかを判断し、判断の結果が所望のイベントである場合にステップ６０４へ移行する、そうでなければ、ステップ６０３へ移行する。

具体的に、サーバにおける状態機コントローラは、アプリケーションの状態に基づいてこの状態での所望イベントを特定し、生成された下りイベントが所望イベントであるかどうかを判断することができる。なお、端末のアプリケーションの状態での所望イベントは一種の下りイベントでもよい、多種の下りイベントであってもよい。

ステップ６０３において、サーバは、下りイベントの送信を拒否する。

ステップ６０４において、サーバは、端末へ下りイベントを送信する。

なお、本発明の実施形態のステップ６０３が、望ましいステップであり、本発明の他の実施形態において、サーバは、生成された下りイベントが端末におけるアプリケーションの所望イベントではないと判断された場合に、下りイベントの送信の拒否を除く他の操作を実行できる。例えばこの下りイベントを放棄することによっても、イベント処理の目的にも達成できる。

本発明の実施形態の利点は、端末の現在業務のアプリケーションの状態に基づいて、このアプリケーションへ送信する下りイベントを選択するため、サーバの下りイベントにより端末の現在業務を中断させることを避けられ、端末業務の実行成功率を向上させることにある。本発明の実施形態を実施するいずれかの製品は、同時に上記のすべての利点を有する必要がないことはいうまでもない。

本発明の上記の実施形態はいずれも端末とサーバのいずれかに状態機コントローラを設置することを例にして、本発明の技術案を記述した。本発明の他の実施形態において、端末が受信した下りイベントと、端末により生成された上りイベントおよびサーバにより生成された下りイベントを処理するために、端末とサーバにとともに状態機コントローラを設置してもよい。

上記の実施形態に提供されたイベント処理方法により、本発明の実施形態において、上記イベント処理方法を適用する装置も提供される。

図７に示す本発明の実施形態４における端末の構成模式図において、
端末におけるアプリケーションの各状態および各状態での所望イベントを記憶する状態機コントローラ７１０と、
サーバの下りイベントを受信する受信モジュール７２０と、
上りイベントを生成する生成モジュール７３０と、
端末の現在業務のアプリケーションの状態に基づいて、受信モジュール７２０により受信した下りイベントおよび／或いは生成モジュール７３０により生成された上りイベントがこの状態での所望イベントであるかどうかを判断する判断モジュール７４０と、
判断モジュール７４０により下りイベントがこの状態での所望イベントであると判断された場合に、この下りイベントをこのアプリケーションへ送信し、このアプリケーションの状態を更新する、および／或いは判断モジュール７４０により上りイベントがこの状態での所望イベントであると判断された場合に、この上りイベントをサーバへ送信し、アプリケーションの状態を更新する処理モジュール７５０とを含む。

具体的に、上記処理モジュール７５０は、下りイベントをアプリケーションへ送信した後、アプリケーションの状態を更新してもよい、アプリケーションから返答される、アプリケーションが下りイベントに基づく処理に成功したことを表す応答情報を受信した後、アプリケーションの状態を更新してもよい。

上記処理モジュール７５０は、更に、判断モジュール７４０により下りイベントがアプリケーションの状態での所望イベントではないと判断された場合に、この下りイベントを放棄する。

上記処理モジュール７５０は、さらに、判断モジュール７４０により下りイベントがアプリケーションの状態での所望イベントではないと判断された場合に、現在業務のアプリケーションの状態を明確に示す直接状態情報（例えば、状態名称或いは識別子）、或いはサーバにより基づかれ現在業務のアプリケーションの状態を特定できる間接状態情報（例えば、端末が前回にサーバへ送信した上りイベントの識別子或いは、名称或いはイベント内容など）である状態情報が付された通知メッセージを送信する、或いは、前回にサーバへ送信した上りイベントを再度サーバへ送信する。

上記処理モジュール７５０は、さらに判断モジュール７４０により上りイベントがアプリケーションの状態での所望イベントではないと判断された場合に、この上りイベントの送信を拒否する。

上記処理モジュール７５０は、さらにユーザにより提出した状態取消指令に従い、サーバへ取消要求を送信し、現在業務のアプリケーションを前の状態へ戻させる。

上記処理モジュール７５０は、さらにユーザにより提出した再送指令に従い、すでにサーバへ送信した上りイベントを再度サーバへ送信する。

本発明の実施形態の利点は、端末の現在業務のアプリケーションの状態に基づいて、このアプリケーションへ送信する下りイベントとサーバへ送信する上りイベントを選択するため、端末の現在業務を中断させることを避けられ、端末の業務の実行成功率を向上させることにある。本発明の実施形態を実施するいずれかの製品は、必ずしも同時に上記の利点を有する必要がないことは言うまでもない。

図８に示す本発明の実施形態５におけるサーバの構成模式図において、
下りイベントを生成する生成モジュール８１０と、
端末におけるアプリケーションの各状態と各状態での所望イベントを記憶する状態機コントローラ８２０と、
端末の現在業務のアプリケーションの状態に基づいて、生成モジュール８１０により生成された下りイベントがこの状態での所望イベントであるかどうかを判断する判断モジュール８３０と、
判断モジュール８３０により下りイベントがこの状態での所望イベントであると判断された場合に、端末へ下りイベントを送信し、アプリケーションの状態を更新する処理モジュール８４０とを含む。
具体的に、上記処理モジュール８４０は、端末へ下りイベントを送信した後、アプリケーションの状態を更新してもよい、端末から返答される、端末の現在業務のアプリケーションが下りイベントに基づく処理に成功したことを示す応答情報を受信した後、アプリケーションの状態を更新してもよい。
上記処理モジュール８４０は、さらに、判断モジュール８３０により下りイベントがこの状態での所望イベントではないと判断された場合に、この下りイベントの送信を拒否する。

上記サーバは、さらに、
端末により送信された、現在業務のアプリケーションの状態を明確に示す直接状態情報（例えば状態名称や識別子）、或いは間接状態情報（例えは、前回に端末によりサーバへ送信した上りイベントの識別子、名称、イベント内容など）である状態情報が付された通知メッセージ或いは現在業務のアプリケーションの上りイベントを受信する受信モジュール８５０と、
受信モジュール８５０により通知メッセージ或いは上りイベントを受信すると、現在業務のアプリケーションの状態を更新する更新モジュール８６０とを含む。

本発明の実施形態の利点は、端末の現在業務のアプリケーションの状態に基づいて、このアプリケーションへ送信する下りイベントを選択するため、サーバの下りイベントにより端末の現在業務を中断させることを避けられ、端末におけるアプリケーションの実行成功率を向上できることにある。本発明の実施形態を実施するいずれかの製品は必ずしも上記のすべての利点を有する必要がないというまでもない。

当業者は、実施形態の装置におけるモジュールが、実施形態の記載にしたがって実施形態の装置に分布してもよい、変形して本実施形態と異なるひとつ或いは複数の装置に位置してもよいことを理解でき、上記実施形態のモジュールが一つのモジュールにしてもよい、さらに複数のモジュールに分離してもよい。

上記本発明の実施形態番号は、説明するためのものであり、本実施形態の良し悪しを表さない。

上記の実施形態の説明により、当業者は本発明がソフトウェアと必要となる汎用なハードウェアプラットフォームとの結合により実現してもよい、ハードウェアにより実現してもよいが、前者の方がよい場合が多い。このような理解の上で、本発明の技術案が本質的に、言い換えれば従来技術に貢献する部分が、一台の端末設備（携帯電話、パソコン、サーバ、或いはネットワーク設備など）に本発明の各実施形態の方法を実施させるいくつかの指令を含む、ひとつの記憶媒体に記憶されるコンピュータソフトウェア製品で表現できる。

以上、本発明の望ましい実施形態のみを説明したが、当業者には、本発明の旨を超えない上で、いくつかの改良或いは変更することができる。これらの改良或いは変更も本発明の保護範囲に含まれる。

７１０ 状態機コントローラ
７２０ 受信モジュール
７３０ 生成モジュール
７４０ 判断モジュール
７５０ 処理モジュール
８１０ 生成モジュール
８２０ 状態機コントローラ
８３０ 判断モジュール
８４０ 処理モジュール
８５０ 受信モジュール
８６０ 更新モジュール

Claims (22)

1. 端末が、サーバの下りイベントを受信すると、前記端末の現在業務のアプリケーションの状態に基づいて、前記下りイベントがこの状態での所望イベントであるかどうかを判断することと、
   前記下りイベントがこの状態での所望イベントであると判断された場合に、前記下りイベントを前記アプリケーションへ送信して、前記アプリケーションの状態を更新することと、を含むことを特徴とするイベント処理方法。
2. 請求項１に記載のイベント処理方法において、
   前記端末が前記アプリケーションの状態を更新することは、
   前記端末が、前記下りイベントを前記アプリケーションへ送信した後、前記アプリケーションの状態を更新すること、或いは
   前記端末が、前記アプリケーションから返答される、前記アプリケーションが前記下りイベントに基づいて処理に成功したことを示す応答情報を受信した後、前記アプリケーションの状態を更新することを含むことを特徴とするイベント処理方法。
3. 請求項１に記載のイベント処理方法において、
   前記端末は、前記下りイベントが前記アプリケーションの状態での所望イベントではないと判断された場合に、前記下りイベントを放棄することを更に含むことを特徴とするイベント処理方法。
4. 請求項１に記載のイベント処理方法において、
   前記端末は、前記下りイベントが前記アプリケーションの所望イベントではないと判断された場合に、前記アプリケーションの状態を前記サーバに通知するための、前記アプリケーションの状態情報又は前記端末により前回に前記サーバへ送信した上りイベントの情報が付された通知メッセージを前記サーバに送信するか、或いは前回に前記サーバへ送信した上りイベントを前記サーバに再送することを更に含むことを特徴とするイベント処理方法。
5. 請求項１に記載のイベント処理方法において、
   端末は、上りイベントを生成する際に、現在業務のアプリケーションの状態に基づいて、前記上りイベントがこの状態での所望イベントであるかどうかを判断し、前記上りイベントがこの状態での所望イベントであると判断された場合に、前記上りイベントを前記サーバに送信して、前記アプリケーションの状態を更新することを更に含むことを特徴とするイベント処理方法。
6. 請求項５に記載のイベント処理方法において、
   前記端末は、前記上りイベントが前記アプリケーションの状態での所望イベントではないと判断された場合に、前記上りイベントの送信を拒否することを更に含むことを特徴とするイベント処理方法。
7. 請求項１に記載のイベント処理方法において、
   前記端末が、ユーザが提出した状態取消指令に従い、前記サーバに取消要求を送信して、前記アプリケーションを前の状態へ戻すこと、及び／又は、
   前記端末が、ユーザが提出した再送指令に従い、既に前記サーバに送信した上りイベントを前記サーバに再送することを更に含むことを特徴とするイベント処理方法。
8. 請求項１に記載のイベント処理方法において、
   前記サーバが、前記端末の現在業務のアプリケーションの状態に基づいて、前記サーバにより生成された下りイベントがこの状態での所望イベントであるかどうかを判断することと、
   前記サーバが、前記下りイベントがこの状態での所望イベントであると判断された場合に、前記端末に前記下りイベントを送信することと、を更に含むことを特徴とするイベント処理方法。
9. サーバが、端末の現在業務のアプリケーションの状態に基づいて、生成された下りイベントがこの状態での所望イベントであるかどうかを判断することと、
   前記サーバが、前記下りイベントがこの状態での所望イベントであると判断した場合に、前記端末に前記下りイベントを送信することと、を含むことを特徴とするイベント処理方法。
10. 請求項９に記載のイベント処理方法において、
    前記サーバが、前記下りイベントが前記アプリケーションの状態での所望イベントではないと判断した場合に、前記下りイベントの送信を拒否することを更に含むことを特徴とするイベント処理方法。
11. 請求項９に記載のイベント処理方法において、
    前記サーバが、前記端末により送信された、前記アプリケーションの状態情報又は前記端末により前回に前記サーバに送信した上りイベントの情報が付された通知メッセージ、或いは現在業務のアプリケーションの前記上りイベントを受信した後に、前記アプリケーションの状態を更新することを更に含むことを特徴とするイベント処理方法。
12. 端末におけるアプリケーションの各状態及び各状態での所望イベントを記憶する状態機コントローラと、
    サーバの下りイベントを受信する受信モジュールと、
    前記端末の現在業務のアプリケーションの状態に基づいて、前記下りイベントがこの状態での所望イベントであるかどうかを判断する判断モジュールと、
    前記判断モジュールにより前記下りイベントがこの状態での所望イベントであると判断された場合に、前記下りイベントを前記アプリケーションへ送信して、前記アプリケーションの状態を更新する処理モジュールと、を含むことを特徴とする端末。
13. 請求項１２に記載の端末において、
    前記処理モジュールは、前記下りイベントを前記アプリケーションへ送信した後、前記アプリケーションを更新する、或いは、
    前記アプリケーションから返答される、前記アプリケーションが前記下りイベントに基づいて処理に成功したことを表す応答情報を受信した後、前記アプリケーションの状態を更新することを特徴とする端末。
14. 請求項１２に記載の端末において、
    前記処理モジュールは、更に、前記判断モジュールにより前記下りイベントが前記アプリケーションの状態での所望イベントではないと判断された場合に、前記下りイベントを放棄することを特徴とする端末。
15. 請求項１２に記載の端末において、
    前記処理モジュールは、更に、前記判断モジュールにより前記下りイベントが前記アプリケーションの状態での所望イベントではないと判断された場合に、前記アプリケーションの状態を前記サーバに通知するための、前記アプリケーションの状態情報或いは前記端末により前回に前記サーバに送信した上りイベントの情報が付された通知メッセージを前記サーバに送信するか、或いは前回に前記サーバに送信した前記上りイベントを前記サーバに再送することを特徴とする端末。
16. 請求項１２に記載の端末において、
    上りイベントを生成する生成モジュールを更に含み、
    前記判断モジュールは、更に、現在業務のアプリケーションの状態に基づいて、前記上りイベントがこの状態での所望イベントであるかどうかを判断し、
    前記処理モジュールは、更に、前記上りイベントがこの状態での所望イベントであると判断された場合に、前記上りイベントを前記サーバに送信して、前記アプリケーションの状態を更新することを特徴とする端末。
17. 請求項１６に記載の端末において、
    前記処理モジュールは、更に、前記判断モジュールにより前記上りイベントが前記アプリケーションの状態での所望イベントではないと判断された場合に、前記上りイベントの送信を拒否することを特徴とする端末。
18. 請求項１２に記載の端末において、
    前記処理モジュールは、更に、ユーザにより提出された状態取消指令に従い、前記サーバに取消要求を送信して、前記アプリケーションを前の状態へ戻すことを特徴とする端末。
19. 請求項１２に記載の端末において、
    前記処理モジュールは、更に、ユーザにより提出された再送指令に従い、既に前記サーバに送信した上りイベントを前記サーバに再送することを特徴とする端末。
20. 下りイベントを生成する生成モジュールと、
    端末におけるアプリケーションの各状態及び各状態での所望イベントを記憶する状態機コントローラと、
    前記端末の現在業務のアプリケーションの状態に基づいて、前記生成モジュールにより生成された下りイベントがこの状態での所望イベントであるかどうかを判断する判断モジュールと、
    前記判断モジュールにより前記下りイベントがこの状態での所望イベントであると判断された場合に、前記下りイベントを前記端末へ送信する処理モジュールとを含むことを特徴とするサーバ。
21. 請求項２０に記載のサーバにおいて、
    前記処理モジュールは、更に、前記判断モジュールにより前記下りイベントがこの状態での所望イベントではないと判断された場合に、前記下りイベントの送信を拒否することを特徴とするサーバ。
22. 請求項２０に記載のサーバにおいて、更に、
    前記端末により送信された、前記アプリケーションの状態情報或いは前記端末により前回に前記サーバに送信した上りイベントが付された通知メッセージ、或いは現在業務のアプリケーションの上りイベントを受信する受信モジュールと、
    前記アプリケーションの状態を更新する更新モジュールと、を含むことを特徴とするサーバ。

Images