WO2012055349A1 - 一种事件处理方法和装置 - Google Patents

一种事件处理方法和装置 Download PDF

Info

Publication number
WO2012055349A1
WO2012055349A1 PCT/CN2011/081316 CN2011081316W WO2012055349A1 WO 2012055349 A1 WO2012055349 A1 WO 2012055349A1 CN 2011081316 W CN2011081316 W CN 2011081316W WO 2012055349 A1 WO2012055349 A1 WO 2012055349A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
application
state
terminal
server
Prior art date
Application number
PCT/CN2011/081316
Other languages
English (en)
French (fr)
Inventor
李征
Original Assignee
中国移动通信集团公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中国移动通信集团公司 filed Critical 中国移动通信集团公司
Priority to KR1020137013163A priority Critical patent/KR101544289B1/ko
Priority to JP2013535265A priority patent/JP5908916B2/ja
Publication of WO2012055349A1 publication Critical patent/WO2012055349A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/10—Interfaces between hierarchically different network devices between terminal device and access point, i.e. wireless air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to an event processing method and apparatus. Background technique
  • the over-the-air (OTA) application is a data value-added service that enables users to obtain personalized information services based on the short message mechanism and through interaction between the mobile terminal and the server.
  • the OTA application is stored in the mobile terminal, the Subscriber Identity Module (SIM) card, or the Universal Subscriber Identity Module (USIM) card, which can dynamically download, delete, and update the service menu.
  • SIM Subscriber Identity Module
  • USIM Universal Subscriber Identity Module
  • the mobile ticket application on the mobile terminal can use the SMS or General Packet Radio Service (GPRS) to purchase, collect, and return tickets with the server.
  • GPRS General Packet Radio Service
  • a service between a mobile terminal and a server usually needs to undergo thousands of signaling interactions, and the above-mentioned services can be implemented by means of SMS (Mobile Terminated) or SMS Origin (MO, Mobile Originated).
  • SMS Mobile Terminated
  • MO Mobile Originated
  • the system architecture of the mobile terminal and server in the prior art is as shown in FIG.
  • the OTA application in the mobile terminal sends a service request to the server through the MO mode
  • the OTA application After receiving the service response returned by the application processor in the server, the mobile terminal completes the service and enters an idle state.
  • the server can also send a service command to the terminal through the MT mode.
  • the OTA application in the terminal returns a response to the server and enters a state of waiting for the server to respond.
  • the service completes the service and enters the idle state. status.
  • the server cannot receive the short message of the mobile terminal in real time, and the reliability is poor, and the short message is easy to be lost.
  • the service command sent by the server to the mobile terminal through the MT mode interrupts the ongoing MO mode of the mobile terminal.
  • the service reduces the execution success rate of the OTA application.
  • the interruption of the previous service is also caused, which also reduces the execution success rate of the OTA application.
  • An event processing method is applied to a terminal, where the terminal is provided with each state of an application in the terminal and an expected event in each state, and the method includes:
  • the terminal determines, according to the state of the application of the current service of the terminal, whether the downlink event is an expected event in the state, and determines that the downlink event is the When the event is expected in the state, the downlink event is sent to the application, and the state of the application is updated.
  • An event processing method is applied to a server, where the server is provided with each state of an application in the terminal and an expected event in each state, and the method includes:
  • the server determines that the downlink event is an expected event in the state
  • the server sends the downlink event to the terminal.
  • a terminal comprising:
  • a state machine manager configured to store each state of the application in the terminal and an expected event in each state
  • a receiving module configured to receive a downlink event of the server
  • a determining module configured to determine, according to a state in which the application of the current service of the terminal is located, whether the downlink event is an expected event in the state
  • the processing module is configured to: when the determining module determines that the downlink event is an expected event in the state, send the downlink event to the application, and update a state of the application.
  • a server comprising:
  • a generation module is used to generate a downlink event.
  • a state machine manager configured to store each state of the application in the terminal and an expected event in each state
  • the determining module configured to determine, according to a state of the application of the current service of the terminal, a downlink event generated by the generating module Whether it is an expected event in this state
  • the processing module is configured to send the downlink event to the terminal when the determining module determines that the downlink event is an expected event in the state.
  • the downlink event sent to the application is selected according to the state of the application of the current service of the terminal, which can avoid interrupting the current service of the terminal and improve the execution success rate of the terminal service.
  • FIG. 1 is a schematic structural diagram of a terminal and a server in the prior art
  • FIG. 2 is a schematic structural diagram of a terminal and a server according to an embodiment of the present invention
  • 3 is a flowchart of an event processing method according to Embodiment 1 of the present invention
  • FIG. 4 is a schematic diagram of state update of an application in a terminal according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of an event processing method according to Embodiment 2 of the present invention.
  • FIG. 6 is a flowchart of an event processing method in Embodiment 3 of the present invention.
  • FIG. 7 is a schematic structural diagram of a terminal in Embodiment 4 of the present invention.
  • FIG. 8 is a schematic structural diagram of a server in Embodiment 5 of the present invention. detailed description
  • each state of each application in the terminal and an expected event in each state are set on the terminal.
  • the terminal receives the downlink event of the server, the terminal according to the application of the current service of the terminal a state in which the downlink event is determined to be an expected event in the state, and when it is determined that the downlink event is an expected event in the state, the downlink event is sent to the application, and the state of the application is updated;
  • the terminal determines whether the uplink event is an expected event in the state according to the state of the application of the current service of the terminal, and sends the uplink event to the event that the uplink event is an expected event in the state.
  • Server update the status of the above application.
  • the server may also be configured with each state of the application in the terminal and an expected event in each state, and the server determines, according to the state of the application of the current service of the terminal, whether the downlink event generated by the server is an expected event in the state; When it is determined that the downlink event is an expected event in this state, the downlink event is sent to the terminal.
  • the above two schemes can also be combined.
  • FIG. 2 is a schematic structural diagram of a terminal and a server in an embodiment of the present invention.
  • the terminal may set a state machine manager for its own application, and maintain the state of the application in the terminal through the state machine manager, and determine, according to the state of the application, that the received downlink event is an expected event in the state.
  • the downlink event is sent to the application in the terminal, and the uplink event is sent to the server when the generated uplink event is an expected event in the state, so that the execution success rate of the application in the terminal is improved by the processing on the terminal side.
  • the server may also set a state machine manager for the application in the terminal, and the state machine manager records the current state of the application in the terminal, and the generated downlink event is an expected event of the current state of the application of the terminal.
  • the execution success rate of the application in the terminal is improved by the processing on the server side.
  • FIG. 3 it is a flowchart of an event processing method in the first embodiment of the present invention.
  • a state machine manager is set in the terminal, and each state and each state of the application in the terminal are set in the state machine manager. Expectations under the event.
  • the terminal currently opens an application by using the MO mode or the MT mode.
  • the hand ticket application is taken as an example.
  • the process may include the following steps:
  • Step 301 The terminal receives a downlink event of the server.
  • Step 302 The terminal determines, according to the state of the hand ticket application, whether the received downlink event is an expected event in the state; if the determination result is yes, step 303 is performed; otherwise, step 304 is performed.
  • the state machine manager in the terminal may determine an expected event in the state according to the state of the hand ticket application, and determine whether the received downlink event is a desired event.
  • the expected event in the state in which the application of the terminal is located may be one or more downlink events.
  • Step 303 The terminal sends the received downlink event to the hand ticket application, and updates the state of the hand ticket application. Specifically, the terminal may update the state of the hand ticket application after sending the received downlink event to the hand ticket application, or may update the mobile phone after receiving the feedback information returned by the hand ticket application for indicating that the application successfully processes the downlink event. The status of the ticket application.
  • the state machine manager in the terminal receives the feedback information returned by the hand ticket application to indicate that the application is unsuccessful according to the downlink event processing or does not receive the feedback information returned by the hand ticket application within the preset time, the terminal maintains the hand ticket application. status.
  • the state machine manager in the terminal can update the state of the application in the terminal according to the state update diagram shown in FIG.
  • the state machine manager updates the state of the application to the service 1 state; when the application in the terminal is in the state of the service 1, and
  • the state machine manager may first update the state of the application to the service 1 completion state and further update to the idle state.
  • the state of the application does not change.
  • the state of the application is kept unchanged.
  • Step 304 The terminal discards the received downlink event and sends a notification message to the server.
  • the notification message carries state information of the hand ticket application, and the state information may be direct state information (such as a state name or an identifier), that is, explicitly indicating the current state of the ticket application, or may be an indirect state information (such as The identifier or name or event content of the uplink event sent to the server at a time, etc., the server may determine the current state of the ticket application based on the indirect status information.
  • direct state information such as a state name or an identifier
  • an indirect state information such as The identifier or name or event content of the uplink event sent to the server at a time, etc.
  • the terminal may also interact with the server through an alternative manner such as data lines, RFID, Bluetooth, infrared, and WiFi.
  • an alternative manner such as data lines, RFID, Bluetooth, infrared, and WiFi.
  • step 305 in the embodiment of the present invention is a preferred step.
  • the terminal may perform discarding.
  • the downlink event and other operations other than sending the notification message to the server, for example, not responding to the downlink event, and sending the uplink event sent to the server the last time to the server again, can also achieve the purpose of event processing.
  • the terminal may further provide a retry option and an undo option to the user through the application interface. When the user selects the retry option, the terminal sends the uplink event that has been sent to the server to the server again according to the resend command submitted by the user.
  • the terminal retracts the command according to the state submitted by the user, sends a revocation request to the server, returns the hand ticket application to the previous state, or directly returns to the idle state.
  • the terminal may directly return the hand ticket application to the previous state or the idle state after sending the revocation request to the server; or may return the hand ticket application to the previous state or idle after receiving the revocation response returned by the server. status.
  • the terminal can also display the status of the hand ticket application and the content of the uplink event sent by the terminal to the server through the application interface.
  • the status of the hand ticket application may include an idle state, an STK ticketing status, a STK ticketing status, and an STK ticketing status
  • the uplink event sent by the terminal to the server may include a ticketing command, a network ticket confirmation request command, and a ticketing write. Ticket order, ticket cancellation order, etc.
  • the embodiment of the present invention includes the following advantages, because the state in which the application of the current service of the terminal is located selects a downlink event sent to the application, and the downlink event of the server can be prevented from interrupting the current service of the terminal;
  • the status of the terminal is mirrored to the server, which can prevent the server from issuing new MT commands during the current service of the terminal, and improve the execution success rate of the terminal service.
  • implementing any of the products of the embodiments of the present invention does not necessarily require all of the advantages described above to be achieved at the same time.
  • FIG. 5 it is a flowchart of an event processing method according to Embodiment 2 of the present invention.
  • a state machine manager is set on a terminal, and each state and each state of an application in the terminal are set in the state machine manager. Expectations under the event.
  • the terminal currently opens an application by using the MO mode or the MT mode.
  • the hand ticket application is taken as an example, and the following steps are included:
  • Step 501 The terminal generates an uplink event.
  • Step 502 The terminal determines, according to the state of the terminal ticket application, whether the uplink event generated by the application is an expected event in the state; if the determination result is yes, step 504 is performed; otherwise, step 503 is performed.
  • the state machine manager in the terminal can determine the expected event in the state according to the state of the hand ticket application, and determine whether the uplink event generated by the hand ticket application is an expected event.
  • the expected event in the state in which the application of the terminal is located may be one or more uplink events, and the uplink event is allowed to be sent to the server without interrupting the current service.
  • the uplink event generated by the application in the terminal may be a request event, and different request events may be mutually exclusive relationships.
  • the state machine manager in the terminal can set the request event in a mutually exclusive relationship with the request event of the current service as the non-expected event in the state in which the application of the current service is located.
  • the state machine manager will determine that the request event is not an expected event in that state.
  • Step 503 The terminal refuses to send an uplink event.
  • Step 504 The terminal sends an uplink event to the server to update the status of the hand ticket application.
  • the terminal may update the state of the application before the uplink event is sent to the server, or update the state of the application after the uplink event is sent to the server.
  • the state machine manager in the terminal can update the state of the application in the terminal according to the state update diagram shown in FIG.
  • the state machine manager updates the state of the application to the service 1 state; when the application in the terminal is in the state of the service 1, And when the uplink event sent to the server is the revocation request for the service 1, the state machine manager may first update the state of the application to the service 1 termination state, and further update to the idle state.
  • the application in the terminal is in the state of service 1 and the uplink event sent to the server is a MO request for other services, the state information of the application does not change.
  • the terminal when the user operates the application that enters the current service of the terminal, the terminal displays the status of the application of the current service through the application interface, and provides two options of retrying and revoking.
  • the terminal When the user selects retry, the terminal resends the previous service request to the server, and the server receives the resent service request and returns a service response to the terminal.
  • the terminal sends a revocation request for the current service to the server, and returns to the idle state, and may also return to the idle state when receiving the response of the server.
  • the application in the terminal receives the downlink event or the state change after the uplink event is sent, as shown in Table 1, the state change table of the hand ticket application.
  • the first row of Table 1 indicates the state when the hand ticket application receives the downlink event or sends the uplink event.
  • the first column of Table 1 indicates the received downlink event or the sent uplink event, and the other contents of Table 1 indicate the hand ticket application reception.
  • N/A indicates that the downlink event received by the hand ticket application or the sent uplink event is invalid, and the hand ticket application does not execute the corresponding command and does not return a response.
  • the mobile ticket application When the mobile ticket application is in the business progress state, after the user enters the first-level menu "hand ticket coupon", the mobile ticket application displays the current STK service that is waiting to be processed, and the content can be "Your XXXX (Internet ticket purchase, ticket collection or return) Ticket) The service is being processed, you can choose to go back, continue to wait, or choose OK, and resend again.” After the user chooses to resend, the ticket application sends the local service request to the server again and enters after sending the local service request. Secondary menu; After the user chooses to return, the hand ticket application directly performs the secondary menu.
  • step 503 in the embodiment of the present invention is a preferred step.
  • the terminal may perform the rejection.
  • Other operations than sending an uplink event, for example, discarding the downlink event, can also achieve the purpose of event processing.
  • the embodiment of the present invention includes the following advantages, because the state in which the application of the current service of the terminal is located selects an uplink event sent to the server, and the uplink event sent to the server can be avoided to interrupt the current service of the terminal; in addition, the terminal can display the current The state of the application of the service, and the user is provided with the option of resending the MO command and canceling the MO command, which reduces the probability of the user's misoperation and improves the execution success rate of the terminal service.
  • any of the products of the embodiments of the present invention does not necessarily require all of the advantages described above to be achieved at the same time.
  • FIG. 6 it is a flowchart of an event processing method according to Embodiment 3 of the present invention.
  • a state machine manager is set on a server, and each state and each state of an application in the terminal are set in the state machine manager. Expectations under the event.
  • the terminal currently opens an application by using the MO mode or the MT mode.
  • the server After receiving the notification message sent by the terminal or the uplink event of the application of the current service, the server updates the state of the application.
  • the notification message carries the status information of the current service, and the status information may be direct status information (such as a status name or an identifier), that is, an indication of the status of the application of the current service, or an indirect status information (such as The identifier or name or event content of the uplink event sent to the server last time, etc., the server may determine the state of the application of the current service according to the indirect state information.
  • This embodiment includes the following steps:
  • Step 601 The server generates a downlink event.
  • Step 602 The server determines, according to the state of the application of the current service of the terminal, whether the downlink event generated by the server is an expected event in the state; if the determination result is yes, step 604 is performed; otherwise, step 603 is performed.
  • the state machine manager in the server may determine an expected event in the state according to the state of the application, and determine whether the generated downlink event is an expected event.
  • the expected event in the state in which the application of the terminal is located may be one or more downlink events.
  • Step 603 The server refuses to send a downlink event.
  • Step 604 The server sends a downlink event to the terminal.
  • step 603 in the embodiment of the present invention is a preferred step.
  • the server may perform the rejection transmission.
  • Other operations other than the downlink event, for example, discarding the downlink event, can also achieve the purpose of event processing.
  • the embodiment of the present invention includes the following advantages, because the state in which the application of the current service of the terminal is located selects a downlink event sent to the application, which can prevent the downlink event of the server from interrupting the current service of the terminal, and improve the execution success rate of the terminal service. .
  • implementing any of the products of the embodiments of the present invention does not necessarily require that all of the advantages described above be achieved at the same time.
  • the state machine manager is set on one side of the terminal or the server, and the technical solution of the present invention is described.
  • the terminal and the server may simultaneously set the state machine manager to process the downlink event received by the terminal, the uplink event generated by the terminal, and the downlink event generated by the server.
  • the embodiment of the present invention further provides an apparatus for applying the above event processing method.
  • FIG. 7 is a schematic structural diagram of a terminal in Embodiment 4 of the present invention, including:
  • the state machine manager 710 is configured to store each state of the application in the terminal and an expected event in each state.
  • the receiving module 720 is configured to receive a downlink event of the server.
  • the generating module 730 is configured to generate an uplink event.
  • the determining module 740 is configured to determine, according to the state of the application of the current service of the terminal, whether the downlink event received by the receiving module 720 and/or the uplink event generated by the generating module 730 is an expected event in the state.
  • the processing module 750 is configured to: when the determining module 740 determines that the downlink event is an expected event in the state, send the downlink event to the application, update the state of the application; and/or determine, in the determining module 740, that the uplink event is When the event is expected in this state, the uplink event is transmitted to the server to update the state of the application.
  • the processing module 750 may update the status of the application after the downlink event is sent to the application.
  • the status of the application may also be updated after the application returns the feedback information indicating that the application successfully processes the downlink event.
  • the processing module 750 is further configured to discard the downlink event when the determining module 740 determines that the downlink event is not the expected event in the state where the application is located.
  • the processing module 750 is further configured to: when the determining module 740 determines that the downlink event is not the expected event in the state where the application is located, send the notification message to the server, or send the uplink event that was last sent to the server to the server again.
  • the notification message carries the status information of the application, and the status information may be direct status information (such as a status name or an identifier), that is, an indication of the status of the application of the current service, or an indirect status information (such as the latest terminal).
  • the identifier or name or event content of the uplink event sent to the server at a time, etc.) the server can The connection status information determines the status of the application of the current service.
  • the processing module 750 is further configured to refuse to send the uplink event when the determining module 740 determines that the uplink event is not the expected event in the state where the application is located.
  • the processing module 750 is further configured to send a revocation request to the server according to the state revocation command submitted by the user, and return the application of the current service to the previous state.
  • the processing module 750 is further configured to send the uplink event that has been sent to the server to the server again according to the resend command submitted by the user.
  • the embodiment of the present invention includes the following advantages, because the state in which the application of the current service of the terminal is located selects the downlink event sent to the application and the uplink event sent to the server, which can avoid interrupting the current service of the terminal and improve the terminal service.
  • the execution success rate is a parameter that specifies the execution of the products of the embodiments of the present invention.
  • FIG. 8 is a schematic structural diagram of a server according to Embodiment 5 of the present invention, including:
  • the generating module 810 is configured to generate a downlink event.
  • the state machine manager 820 is configured to store various states of the application in the terminal and expected events in each state.
  • the determining module 830 is configured to determine, according to the state of the application of the current service of the terminal, whether the downlink event generated by the generating module 810 is an expected event in the state.
  • the processing module 840 is configured to: when the determining module 820 determines that the downlink event is an expected event in the state, send a downlink event to the terminal, and update the state of the application.
  • the processing module 840 may update the state of the application after sending the downlink event to the terminal.
  • the state of the application may be updated after receiving the feedback information returned by the terminal for indicating that the application of the current service of the terminal is successfully processed according to the downlink event.
  • the processing module 840 is further configured to refuse to send the downlink event when the determining module 830 determines that the downlink event is not an expected event in the state.
  • the above server may further include:
  • the receiving module 850 is configured to: after receiving the notification message sent by the terminal or the uplink event of the application of the current service, where the notification message carries the status information of the application, where the status information may be direct status information (such as a status name or identifier), ie, It clearly indicates the status of the application of the current service, and may also be the indirect status information (such as the identifier or name or event content of the uplink event that the terminal sent to the server last time).
  • the notification message carries the status information of the application, where the status information may be direct status information (such as a status name or identifier), ie, It clearly indicates the status of the application of the current service, and may also be the indirect status information (such as the identifier or name or event content of the uplink event that the terminal sent to the server last time).
  • the update module 860 is configured to update the state of the application of the current service after the receiving module 850 receives the notification message or the uplink event.
  • the embodiment of the present invention includes the following advantages, because the state in which the application of the current service of the terminal is located selects a downlink event sent to the application, which can prevent the downlink event of the server from interrupting the current service of the terminal, and improve the execution of the application in the terminal. Success rate.
  • any product implementing an embodiment of the present invention does not necessarily need to simultaneously achieve the above All the advantages.
  • modules in the apparatus in the embodiments may be distributed in the apparatus of the embodiment according to the embodiment, or may be correspondingly changed in one or more apparatuses different from the embodiment.
  • the modules of the above embodiments may be combined into one module, or may be further split into multiple sub-modules.
  • the present invention can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is a better implementation. the way.
  • the technical solution of the present invention or the part contributing to the prior art can be embodied in the form of a software product stored in a storage medium shield, including
  • the method described in various embodiments of the present invention is performed such that a terminal device (which may be a mobile phone, a personal computer, a server, or a network device, etc.).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Multimedia (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Environmental & Geological Engineering (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

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 )或短信上行 ( MO, Mobile Originated )方 式实现。 现有技术中的手机终端与服务器的系统架构， 如图 1所示。 当手机终端中的 OTA 应用通过 MO方式向服务器发送业务请求后， OTA应用处于等待服务器回应的状态； 当接 收到服务器中的应用处理器返回的业务响应后， 手机终端完成业务， 进入空闲状态。 服务 器也可以通过 MT方式向终端发送业务命令，终端中的 OTA应用接收到业务命令后， 向服 务器返回响应并进入等待服务器回应的状态， 在接收到服务器返回的业务响应后， 完成业 务并进入空闲状态。
在实现本发明的过程中， 发明人发现现有技术至少存在如下问题：
由于现有技术釆用异步通信方式， 无法保证服务器实时收到手机终端的短信， 而且可 靠性差， 短信易丢失， 服务器通过 MT方式向手机终端发送的业务命令会中断手机终端正 在进行的 MO方式的业务， 降低了 OTA应用的执行成功率； 此外， 在手机终端的业务过 程中， 如果通过 MO 的方式发起新的业务， 也会导致前一业务的中断， 同样降低了 OTA 应用的执行成功率。 发明内容 本发明的目的在于提供一种事件处理方法和装置， 用以提高终端中的应用的执行成功 率， 为此， 本发明釆用如下技术方案：
一种事件处理方法， 应用于终端， 所述终端上设置有所述终端中的应用的各状态以及 各状态下的期待事件， 所述方法包括：
当终端接收到服务器的下行事件时， 所述终端根据所述终端当前业务的应用所处的状 态， 判断所述下行事件是否为该状态下的期待事件， 并在判断出所述下行事件为该状态下 的期待事件时， 将所述下行事件发送到所述应用， 更新所述应用的状态。
一种事件处理方法， 应用于服务器， 所述服务器上设置有终端中的应用的各状态以及 各状态下的期待事件， 所述方法包括：
所述服务器根据所述终端当前业务的应用所处的状态， 判断所述服务器生成的下行事 件是否为该状态下的期待事件；
所述服务器判断出所述下行事件为该状态下的期待事件时， 向所述终端发送所述下行 事件。
一种终端， 包括：
状态机管理器， 用于存储所述终端中的应用的各状态以及各状态下的期待事件； 接收模块， 用于接收服务器的下行事件；
判断模块， 用于根据所述终端当前业务的应用所处的状态， 判断所述下行事件是否为 该状态下的期待事件；
处理模块， 用于在所述判断模块判断出所述下行事件为该状态下的期待事件时， 将所 述下行事件发送到所述应用， 更新所述应用的状态。
一种服务器， 包括：
生成模块， 用于生成下行事件。
状态机管理器， 用于存储终端中的应用的各状态以及各状态下的期待事件； 判断模块， 用于根据所述终端当前业务的应用所处的状态， 判断所述生成模块生成的 下行事件是否为该状态下的期待事件；
处理模块， 用于在所述判断模块判断出所述下行事件为该状态下的期待事件时， 向所 述终端发送所述下行事件。
与现有技术相比， 本发明具有以下优点： 根据终端当前业务的应用所处的状态选择发 送给该应用的下行事件， 可以避免打断终端当前业务， 提高了终端业务的执行成功率。 附图说明
图 1为现有技术中的终端与服务器的架构示意图；
图 2为本发明实施例中的终端与服务器的架构示意图; 图 3为本发明实施例一中的事件处理方法流程图；
图 4为本发明实施例中的终端中的应用的状态更新示意图；
图 5为本发明实施例二中的事件处理方法流程图；
图 6为本发明实施例三中的事件处理方法流程图；
图 7为本发明实施例四中的终端的结构示意图；
图 8为本发明实施例五中的服务器的结构示意图。 具体实施方式
本发明实施例提供的技术方案中， 终端上设置有该终端中每一个应用的各状态以及各 状态下的期待事件， 当终端接收到服务器的下行事件时， 终端根据该终端当前业务的应用 所处的状态， 判断下行事件是否为该状态下的期待事件， 并在判断出下行事件为该状态下 的期待事件时， 将该下行事件发送到上述应用， 更新该应用的状态； 当终端生成上行事件 时， 终端根据该终端当前业务的应用所处的状态， 判断上行事件是否为该状态下的期待事 件， 并在判断出该上行事件为该状态下的期待事件时， 将该上行事件发送到服务器， 更新 上述应用的状态。
服务器上也可以设置有终端中的应用的各状态以及各状态下的期待事件， 服务器根据 终端当前业务的应用所处的状态， 判断该服务器生成的下行事件是否为该状态下的期待事 件； 服务器判断出下行事件为该状态下的期待事件时， 向终端发送该下行事件。 上述两种 方案还可以结合使用。
下面将结合本发明中的附图， 对本发明中的技术方案进行清楚、 完整的描述， 显然， 所描述的实施例是本发明的一部分实施例， 而不是全部的实施例。基于本发明中的实施例， 本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例， 都属于本 发明保护的范围。
如图 2所示， 本发明实施例中的终端与服务器的架构示意图。 终端可以针对自身的应 用设置状态机管理器， 通过该状态机管理器维护终端中的应用所处的状态， 并根据应用所 处的状态确定接收到的下行事件是该状态下的期待事件时将该下行事件发送到终端中的 应用， 以及在生成的上行事件是该状态下的期待事件时将该上行事件发送到服务器， 从而 通过终端侧的处理提高终端中的应用的执行成功率。 服务器也可以针对终端中的应用设置 状态机管理器， 通过该状态机管理器记录终端中的应用当前所处的状态， 并在生成的下行 事件是该终端的应用当前所处的状态的期待事件时， 将生成的下行事件发送到终端， 从而 通过服务器侧的处理提高终端中的应用的执行成功率。
如图 3所示， 为本发明实施例一中的事件处理方法流程图， 该流程中， 终端中设置有 状态机管理器， 状态机管理器中设置有终端中的应用的各状态以及各状态下的期待事件。 终端通过 MO方式或 MT方式当前开启了某种应用， 本实施例中以手机票应用为例， 如图 所示， 该流程可包括以下步骤：
步骤 301 , 终端接收服务器的下行事件。
步骤 302, 终端根据手机票应用的所处的状态， 判断接收到的下行事件是否为该状态 下的期待事件； 如果判断结果为是， 则执行步骤 303; 否则， 执行步骤 304。
具体地， 终端中的状态机管理器可以根据手机票应用所处的状态确定该状态下的期待 事件， 并判断接收到的下行事件是否为期待事件。 其中， 终端的应用所处的状态下的期待 事件可以为一种或多种下行事件。
步骤 303 , 终端将接收到的下行事件发送到手机票应用， 更新手机票应用的状态。 具体地， 终端可以在将接收到的下行事件发送到手机票应用之后， 更新手机票应用的 状态， 也可以在接收到手机票应用返回的用于表示应用根据下行事件处理成功的反馈信息 后， 更新手机票应用的状态。 当终端中的状态机管理器接收到手机票应用返回的用于表示 应用根据下行事件处理不成功的反馈信息或者在预设时间内没有接收到手机票应用返回 的反馈信息时， 终端保持手机票应用的状态。
终端中的状态机管理器可以按照如图 4所示的状态更新示意图， 更新终端中的应用的 状态。 当终端中的应用为空闲状态， 且接收到的下行事件为针对业务 1的 MT命令时， 状 态机管理器将应用的状态更新为业务 1状态； 当终端中的应用为业务 1进行状态， 且接收 到的下行事件为针对业务 1的业务应答时， 状态机管理器可以先将应用的状态更新为业务 1 完成状态， 并进一步更新到空闲状态。 当终端中的应用为空闲状态， 且接收到的下行事 件为业务应答时， 该应用的状态不变。 当终端中的应用为业务 1进行状态， 且接收到的下 行事件为针对其他业务的 MT命令时， 保持该应用的状态不变。
步骤 304, 终端丢弃接收到的下行事件， 向服务器发送通知消息。
其中， 通知消息携带有手机票应用的状态信息， 该状态信息可以是直接状态信息 （如 状态名称或标识）， 即明确指示出手机票应用当前所处的状态， 也可以是间接状态信息（如 最近一次发送给服务器的上行事件的标识或名称或事件内容等）， 服务器可根据该间接状 态信息确定出手机票应用当前所处的状态。
本发明实施例中， 针对终端的 OTA功能失效的极端情况， 终端还可以通过数据线、 RFID、 蓝牙、 红外、 WiFi 等备选方式与服务器交互。 终端处于业务进行状态时， 可以通 过上述备选方式将终端的应用的状态信息通知服务器。
需要说明的是，本发明实施例中的步骤 305为优选步骤，在本发明的其他实施方式中， 终端在判断出接收到的下行事件不是终端中的应用的期待事件时， 还可以执行除丢弃该下 行事件和向服务器发送通知消息之外的其他操作， 例如， 不响应该下行事件， 将最近一次 发送给服务器的上行事件再次发送给服务器， 同样可以达到事件处理的目的。 本发明实施例中， 终端还可以通过应用界面向用户提供重试选项和撤销选项。 当用户 选择重试选项时， 终端根据用户提交的重发命令， 将已经发送给服务器的上行事件再次发 送给该服务器。 当用户选择撤销选项时， 终端根据用户提交的状态撤销命令， 向服务器发 送撤销请求， 将手机票应用返回到之前的状态， 或者直接返回到空闲状态。 具体地， 终端 可以在向服务器发送撤销请求之后， 直接将手机票应用返回到之前的状态或者空闲状态； 也可以在接收到服务器返回的撤销响应后， 将手机票应用返回到之前的状态或者空闲状 态。
终端还可以通过应用界面显示手机票应用的状态， 以及终端向服务器发送的上行事件 的内容。 例如， 手机票应用的状态可以包括空闲状态、 STK 购票状态、 STK 回票状态和 STK取票状态，终端向服务器发送的上行事件可以包括写票命令、网络购票确认请求命令、 取票写票命令、 购票取消命令等。
本发明实施例以手机票应用为例对技术方案进行描述， 需要说明的是， 本发明实施例 的技术方案同样适用于终端中的其他应用， 如手机钱包应用等。
本发明的实施例包括以下优点， 因为才 居终端当前业务的应用所处的状态选择发送给 该应用的下行事件， 可以避免服务器的下行事件打断终端当前业务； 通过将终端当前业务 的应用所处的状态镜像到服务器中， 能够避免服务器在终端当前业务的进行过程中下发新 的 MT命令， 提高了终端业务的执行成功率。 当然， 实施本发明的实施例的任一产品并不 一定需要同时达到以上所述的所有优点。
如图 5所示， 为本发明实施例二中的事件处理方法流程图， 该流程中， 终端上设置有 状态机管理器， 状态机管理器中设置有终端中的应用的各状态以及各状态下的期待事件。 终端通过 MO方式或 MT方式当前开启了某种应用， 本实施例中以手机票应用为例， 包括 以下步骤：
步骤 501 , 终端生成上行事件。
步骤 502, 终端根据终端手机票应用所处的状态， 判断该应用生成的上行事件是否为 该状态下的期待事件； 如果判断结果为是， 则执行步骤 504; 否则， 执行步骤 503。
具体地， 终端中的状态机管理器可以根据手机票应用所处的状态确定该状态下的期待 事件， 并判断手机票应用生成的上行事件是否为期待事件。 其中， 终端的应用所处的状态 下的期待事件可以为一种或多种上行事件， 该上行事件允许发送到服务器， 不会中断当前 业务。
其中， 终端中的应用生成的上行事件可以为请求事件， 不同的请求事件之间可以是互 斥关系。 终端在当前业务的执行过程中， 如果向服务器发送与当前业务的请求事件存在互 斥关系的请求事件， 会中断当前业务。 因此， 终端中的状态机管理器可以将与当前业务的 请求事件存在互斥关系的请求事件设置为当前业务的应用所处状态下的非期待事件。 当应 用生成该请求事件时， 状态机应管理器会判断该请求事件不是该状态下的期待事件。
步骤 503 , 终端拒绝发送上行事件。
步骤 504, 终端将上行事件发送到服务器， 更新手机票应用的状态。
具体地， 终端可以在上行事件发送到服务器之前更新应用的状态， 也可以在上行事件 发送到服务器之后更新应用的状态。 终端中的状态机管理器可以按照如图 4所示的状态更 新示意图， 更新终端中的应用的状态。 当终端中的应用为空闲状态， 且向服务器发送的上 行事件为针对业务 1的 MO请求时， 状态机管理器将应用的状态更新为业务 1状态； 当终 端中的应用为业务 1进行状态， 且向服务器发送的上行事件为针对业务 1的撤销请求时， 状态机管理器可以先将应用的状态更新为业务 1终止状态， 并进一步更新到空闲状态。 当 终端中的应用为业务 1进行状态， 且向服务器发送的上行事件为针对其他业务的 MO请求 时， 应用的状态信息不变。
本发明实施例中， 用户操作进入终端当前业务的应用时， 终端通过应用界面显示当前 业务的应用的状态， 并提供重试和撤销两个选项。 当用户选择重试时， 终端向服务器重发 之前的业务请求，服务器接收重发的业务请求， 向终端返回业务响应。 当用户选择撤销时， 终端向服务器发送针对当前业务的撤销请求， 并回到空闲状态， 也可以在接收到服务器的 •ί敦销响应时， 回到空闲状态。
以手机票为例， 终端中的应用接收下行事件或发送上行事件后的状态变化， 如表 1所 表 1 手机票应用的状态变化表
Figure imgf000008_0001
其中， 表 1的第 1行表示手机票应用接收下行事件或发送上行事件时的状态， 表 1的 第 1列表示接收的下行事件或发送的上行事件， 表 1的其他内容表示手机票应用接收下行 事件或发送上行事件后的状态。 N/A表示手机票应用接收的下行事件或发送的上行事件是 无效的， 手机票应用不执行相应的命令， 也不返回响应。
当手机票应用处于业务进行状态时， 用户进入一级菜单 "手机票券" 后， 手机票应用 展示正在等待处理的当前 STK业务， 内容可以为 "您的 XXXX (网络购票、 取票或回票） 业务正在处理中， 您可以选择返回， 继续等待， 或者选择确定， 再次重发。" 用户选择重 发后， 手机票应用将本地业务请求再次发送给服务器， 并在发送本地业务请求后进入二级 菜单； 用户选择返回后， 则手机票应用直接进行二级菜单。
需要说明的是，本发明实施例中的步骤 503为优选步骤，在本发明的其他实施方式中， 终端在判断出不允许将自身的应用生成的上行事件发送到服务器时， 还可以执行除拒绝发 送上行事件之外的其他操作， 例如， 丢弃该下行事件， 也可以达到事件处理的目的。
本发明实施例以手机票应用为例对技术方案进行描述， 需要说明的是， 本发明实施例 的技术方案同样适用于终端中的其他应用， 如手机钱包应用等。
本发明的实施例包括以下优点， 因为才 居终端当前业务的应用所处的状态选择发送给 服务器的上行事件， 可以避免向服务器发送的上行事件打断终端的当前业务； 此外， 终端 可以显示当前业务的应用的状态， 并向用户提供了重发 MO命令和撤销 MO命令的选择， 降低了用户误操作的几率， 提高了终端业务的执行成功率。 当然， 实施本发明的实施例的 任一产品并不一定需要同时达到以上所述的所有优点。
如图 6所示， 为本发明实施例三中的事件处理方法流程图， 该流程中， 服务器上设置 有状态机管理器， 状态机管理器中设置有终端中的应用的各状态以及各状态下的期待事 件。 终端通过 MO方式或 MT方式当前开启了某种应用， 服务器接收终端发送的通知消息 或者当前业务的应用的上行事件后， 更新该应用的状态。 上述通知消息中携带当前业务的 应用的状态信息， 该状态信息可以是直接状态信息 （如状态名称或标识）， 即明确指示出 当前业务的应用所处的状态， 也可以是间接状态信息（如最近一次发送给服务器的上行事 件的标识或名称或事件内容等）， 服务器可根据该间接状态信息确定出当前业务的应用所 处的状态。 本实施例包括以下步骤：
步骤 601 , 服务器生成下行事件。
步骤 602, 服务器根据终端当前业务的应用所处的状态， 判断该服务器生成的下行事 件是否为该状态下的期待事件；如果判断结果为是，则执行步骤 604; 否则，执行步骤 603。
具体地，服务器中的状态机管理器可以根据应用所处的状态确定该状态下的期待事件， 并判断生成的下行事件是否为期待事件。 其中， 终端的应用所处的状态下的期待事件可以 为一种或多种下行事件。 步骤 603 , 服务器拒绝发送下行事件。
步骤 604, 服务器向终端发送下行事件。
需要说明的是，本发明实施例中的步骤 603为优选步骤，在本发明的其他实施方式中， 服务器在判断出生成的下行事件不是终端中的应用的期待事件时， 还可以执行除拒绝发送 下行事件之外的其他操作， 例如， 丢弃该下行事件， 也可以达到事件处理的目的。
本发明的实施例包括以下优点， 因为才 居终端当前业务的应用所处的状态选择发送给 该应用的下行事件， 可以避免服务器的下行事件打断终端当前业务， 提高了终端业务的执 行成功率。 当然， 实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有 优点。
需要说明的是， 本发明的上述实施例均以终端或服务器单侧设置状态机管理器为例， 描述本发明的技术方案。 在本发明的其他实施方式中， 终端和服务器可以同时设置状态机 管理器，以处理终端接收到的下行事件、终端生成的上行事件以及服务器生成的下行事件。
根据上述实施方式中提供的事件处理方法， 本发明实施例还提供了应用上述事件处理 方法的装置。
如图 7所示， 为本发明实施例四中的终端的结构示意图， 包括：
状态机管理器 710, 用于存储终端中的应用的各状态以及各状态下的期待事件。
接收模块 720, 用于接收服务器的下行事件。
生成模块 730, 用于生成上行事件。
判断模块 740, 用于根据终端当前业务的应用所处的状态， 判断接收模块 720接收到 的下行事件和 /或生成模块 730生成的上行事件是否为该状态下的期待事件。
处理模块 750, 用于在判断模块 740判断出下行事件为该状态下的期待事件时， 将该 下行事件发送到该应用， 更新该应用的状态； 和 /或在判断模块 740判断出上行事件为该状 态下的期待事件时， 将该上行事件发送到服务器， 更新应用的状态。
具体地， 上述处理模块 750可以在将下行事件发送到应用之后， 更新应用的状态； 也 可以接收应用返回的用于表示应用根据下行事件处理成功的反馈信息后， 更新应用的状 态。
上述处理模块 750, 还用于在判断模块 740判断出下行事件不是应用所处的状态下的 期待事件时， 丢弃该下行事件。
上述处理模块 750, 还用于在判断模块 740判断出下行事件不是应用所处的状态下的 期待事件时， 向服务器发送通知消息， 或者将最近一次发送给服务器的上行事件再次给该 服务器。 上述通知消息中携带有应用的状态信息， 该状态信息可以是直接状态信息 （如状 态名称或标识）， 即明确指示出当前业务的应用所处的状态， 也可以是间接状态信息 （如 终端最近一次发送给服务器的上行事件的标识或名称或事件内容等）， 服务器可根据该间 接状态信息确定出当前业务的应用所处的状态。
上述处理模块 750, 还用于在判断模块 740判断出上行事件不是应用所处的状态下的 期待事件时， 拒绝发送该上行事件。
上述处理模块 750, 还用于根据用户提交的状态撤销命令， 向服务器发送撤销请求， 将当前业务的应用返回到之前的状态。
上述处理模块 750, 还用于根据用户提交的重发命令， 将已经发送给服务器的上行事 件再次发送给该服务器。
本发明的实施例包括以下优点， 因为才 居终端当前业务的应用所处的状态选择发送给 该应用的下行事件和发送给服务器的上行事件， 可以避免打断终端的当前业务， 提高了终 端业务的执行成功率。 当然， 实施本发明的实施例的任一产品并不一定需要同时达到以上 所述的所有优点。
如图 8所示， 为本发明实施例五中的服务器的结构示意图， 包括：
生成模块 810, 用于生成下行事件。
状态机管理器 820, 用于存储终端中的应用的各状态以及各状态下的期待事件。 判断模块 830, 用于根据终端当前业务的应用所处的状态， 判断生成模块 810生成的 下行事件是否为该状态下的期待事件。
处理模块 840, 用于在判断模块 820判断出下行事件为该状态下的期待事件时， 向终 端发送下行事件， 并更新应用的状态。
具体地， 上述处理模块 840可以在向终端发送下行事件之后， 更新应用的状态； 也可 以接收终端返回的用于表示终端当前业务的应用根据下行事件处理成功的反馈信息后， 更 新应用的状态。
上述处理模块 840, 还用于在判断模块 830判断出下行事件不是该状态下的期待事件 时， 拒绝发送该下行事件。
上述服务器可以进一步包括：
接收模块 850, 用于接收终端发送的通知消息或者当前业务的应用的上行事件后， 其 中， 通知消息中携带应用的状态信息， 该状态信息可以是直接状态信息 （如状态名称或标 识）， 即明确指示出当前业务的应用所处的状态， 也可以是间接状态信息 （如终端最近一 次发送给服务器的上行事件的标识或名称或事件内容等）。
更新模块 860 , 用于在接收模块 850接收到通知消息或上行事件后， 更新当前业务的 应用的状态。
本发明的实施例包括以下优点， 因为才 居终端当前业务的应用所处的状态选择发送给 该应用的下行事件， 可以避免服务器的下行事件打断终端当前业务， 提高了终端中的应用 的执行成功率。 当然， 实施本发明的实施例的任一产品并不一定需要同时达到以上所述的 所有优点。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实 施例的装置中， 也可以进行相应变化位于不同于本实施例的一个或多个装置中。 上述实施 例的模块可以合并为一个模块， 也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述， 不代表实施例的优劣。
通过以上的实施方式的描述， 本领域的技术人员可以清楚地了解到本发明可借助软件 加必需的通用硬件平台的方式来实现， 当然也可以通过硬件， 但很多情况下前者是更佳的 实施方式。 基于这样的理解， 本发明的技术方案本盾上或者说对现有技术做出贡献的部分 可以以软件产品的形式体现出来， 该计算机软件产品存储在一个存储介盾中， 包括若千指 令用以使得一台终端设备（可以是手机， 个人计算机， 服务器， 或者网络设备等）执行本 发明各个实施例所述的方法。
以上所述仅是本发明的优选实施方式， 应当指出， 对于本技术领域的普通技术人员来 说， 在不脱离本发明原理的前提下， 还可以做出若千改进和润饰， 这些改进和润饰也应视 本发明的保护范围。

Claims

权 利 要 求
1、 一种事件处理方法， 其特征在于， 包括：
终端接收到服务器的下行事件时， 终端根据所述终端当前业务的应用所处的状态， 判 断所述下行事件是否为该状态下的期待事件； 并
在判断出所述下行事件为该状态下的期待事件时， 将所述下行事件发送到所述应用， 更新所述应用的状态。
2、 如权利要求 1所述的方法， 其特征在于， 所述终端更新所述应用的状态， 包括： 所述终端在将所述下行事件发送到所述应用之后， 更新所述应用的状态； 或者 所述终端接收所述应用返回的用于表示所述应用根据所述下行事件处理成功的反馈信 息后， 更新所述应用的状态。
3、 如权利要求 1所述的方法， 其特征在于， 还包括：
所述终端判断出所述下行事件不是所述应用所处的状态下的期待事件时， 丢弃所述下 行事件。
4、 如权利要求 1所述的方法， 其特征在于， 还包括：
所述终端判断出所述下行事件不是所述应用的期待事件时， 向所述服务器发送通知消 息， 或者将最近一次发送给所述服务器的上行事件再次给所述服务器， 所述通知消息中携 带有所述应用的状态信息或者所述终端最近一次发送给所述服务器的上行事件的信息， 用 于将所述应用所处的状态通知所述服务器。
5、 如权利要求 1所述的方法， 其特征在于， 还包括：
终端生成上行事件时， 根据当前业务的应用所处的状态， 判断所述上行事件是否为该 状态下的期待事件， 并在判断出所述上行事件为该状态下的期待事件时， 将所述上行事件 发送到所述服务器， 更新所述应用的状态。
6、 如权利要求 5所述的方法， 其特征在于， 还包括：
所述终端判断出所述上行事件不是所述应用所处的状态下的期待事件时， 拒绝发送所 述上行事件。
7、 如权利要求 1所述的方法， 其特征在于， 还包括：
所述终端根据用户提交的状态撤销命令， 向所述服务器发送撤销请求， 将所述应用返 回到之前的状态； 和 /或
所述终端根据用户提交的重发命令， 将已经发送给所述服务器的上行事件再次发送给 所述服务器。
8、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括：
所述服务器根据所述终端当前业务的应用所处的状态， 判断所述服务器生成的下行事 件是否为该状态下的期待事件； 所述服务器判断出所述下行事件为该状态下的期待事件时， 向所述终端发送所述下行 事件。
9、 一种事件处理方法， 其特征在于， 包括：
所述服务器根据所述终端当前业务的应用所处的状态， 判断生成的下行事件是否为该 状态下的期待事件；
所述服务器判断出所述下行事件为该状态下的期待事件时， 向所述终端发送所述下行 事件。
10、 如权利要求 9所述的方法， 其特征在于， 还包括：
所述服务器判断出所述下行事件不是所述应用所处的状态下的期待事件时， 拒绝发送 所述下行事件。
11、 如权利要求 9所述的方法， 其特征在于， 还包括：
所述服务器接收所述终端发送的通知消息或者当前业务的应用的上行事件后， 更新所 述应用的状态， 所述通知消息中携带所述应用的状态信息或者所述终端最近一次发送给所 述服务器的上行事件的信息。
12、 一种终端， 其特征在于， 包括：
状态机管理器， 用于存储所述终端中的应用的各状态以及各状态下的期待事件； 接收模块， 用于接收服务器的下行事件；
判断模块， 用于根据所述终端当前业务的应用所处的状态， 判断所述下行事件是否为 该状态下的期待事件；
处理模块， 用于在所述判断模块判断出所述下行事件为该状态下的期待事件时， 将所 述下行事件发送到所述应用， 更新所述应用的状态。
13、 如权利要求 12所述的终端， 其特征在于，
所述处理模块， 具体用于在将所述下行事件发送到所述应用之后， 更新所述应用的状 态； 或者
接收所述应用返回的用于表示所述应用根据所述下行事件处理成功的反馈信息后， 更 新所述应用的状态。
14、 如权利要求 12所述的终端， 其特征在于，
所述处理模块， 还用于在所述判断模块判断出所述下行事件不是所述应用所处的状态 下的期待事件时， 丢弃所述下行事件。
15、 如权利要求 12所述的终端， 其特征在于，
所述处理模块， 还用于在所述判断模块判断出所述下行事件不是所述应用所处的状态 下的期待事件时， 向所述服务器发送通知消息， 或者将最近一次发送给所述服务器的上行 事件再次给所述服务器， 所述通知消息中携带有所述应用的状态信息或者所述终端最近一 次发送给所述服务器的上行事件的信息， 用于将所述应用所处的状态通知所述服务器。
16、 如权利要求 12所述的终端， 其特征在于， 还包括：
生成模块， 用于生成上行事件；
所述判断模块， 还用于根据当前业务的应用所处的状态， 判断所述上行事件是否为该 状态下的期待事件；
所述处理模块， 还用于在判断出所述上行事件为该状态下的期待事件时， 将所述上行 事件发送到所述服务器， 更新所述应用的状态。
17、 如权利要求 16所述的终端， 其特征在于，
所述处理模块， 还用于在所述判断模块判断出所述上行事件不是所述应用所处的状态 下的期待事件时， 拒绝发送所述上行事件。
18、 如权利要求 12所述的终端， 其特征在于，
所述处理模块， 还用于根据用户提交的状态撤销命令， 向所述服务器发送撤销请求， 将所述应用返回到之前的状态。
19、 如权利要求 12所述的终端， 其特征在于，
所述处理模块， 还用于根据用户提交的重发命令， 将已经发送给所述服务器的上行事 件再次发送给所述服务器。
20、 一种服务器， 其特征在于， 包括：
生成模块， 用于生成下行事件。
状态机管理器， 用于存储终端中的应用的各状态以及各状态下的期待事件； 判断模块， 用于根据所述终端当前业务的应用所处的状态， 判断所述生成模块生成的 下行事件是否为该状态下的期待事件；
处理模块， 用于在所述判断模块判断出所述下行事件为该状态下的期待事件时， 向所 述终端发送所述下行事件。
21、 如权利要求 20所述的服务器， 其特征在于，
所述处理模块， 还用于在所述判断模块判断出所述下行事件不是该状态下的期待事件 时， 拒绝发送所述下行事件。
22、 如权利要求 20所述的服务器， 其特征在于， 还包括：
接收模块， 用于接收所述终端发送的通知消息或者当前业务的应用的上行事件， 所述 通知消息中携带所述应用的状态信息或者所述终端最近一次发送给所述服务器的上行事 件的信息；
更新模块， 用于更新所述应用的状态。
PCT/CN2011/081316 2010-10-26 2011-10-26 一种事件处理方法和装置 WO2012055349A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020137013163A KR101544289B1 (ko) 2010-10-26 2011-10-26 이벤트 처리 방법 및 장치
JP2013535265A JP5908916B2 (ja) 2010-10-26 2011-10-26 イベント処理方法及び装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010527311.5A CN102457824B (zh) 2010-10-26 2010-10-26 一种事件处理方法和装置
CN201010527311.5 2010-10-26

Publications (1)

Publication Number Publication Date
WO2012055349A1 true WO2012055349A1 (zh) 2012-05-03

Family

ID=45993167

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/081316 WO2012055349A1 (zh) 2010-10-26 2011-10-26 一种事件处理方法和装置

Country Status (4)

Country Link
JP (1) JP5908916B2 (zh)
KR (1) KR101544289B1 (zh)
CN (1) CN102457824B (zh)
WO (1) WO2012055349A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140128017A (ko) * 2013-04-26 2014-11-05 삼성전자주식회사 정보처리장치 및 그 제어방법

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2812541T3 (es) 2013-12-30 2021-03-17 Onespan Int Gmbh Aparato de autenticación con interfaz Bluetooth
CN111800882B (zh) * 2020-06-18 2023-12-05 武汉慧联无限科技有限公司 一种下行数据发送的方法、装置、服务器及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101083615A (zh) * 2006-05-29 2007-12-05 华为技术有限公司 一种跨域接收业务的方法、装置及系统
CN101262646A (zh) * 2007-12-27 2008-09-10 华为技术有限公司 控制发送多媒体消息的方法和多媒体消息业务中心
CN101668266A (zh) * 2008-09-02 2010-03-10 中国电信股份有限公司 一种主叫漏话消息提示方法和系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000278743A (ja) * 1999-03-24 2000-10-06 Kokusai Electric Co Ltd 無線端末
JP3901060B2 (ja) * 2002-08-28 2007-04-04 日本電気株式会社 アプリケーションの更新処理方法、更新処理システム及び更新処理プログラム
KR100787013B1 (ko) * 2003-05-28 2007-12-18 닛본 덴끼 가부시끼가이샤 이동 통신 시스템, 서버, 휴대 단말기, 및 그 데이터 전송방법
JP4608964B2 (ja) * 2004-06-25 2011-01-12 富士通株式会社 モジュール更新プログラム
WO2007051281A1 (en) * 2005-11-01 2007-05-10 Research In Motion Limited Method for receiving and managing a downlink radio link control data block in an egprs mobile electronic communication device
JP4922620B2 (ja) * 2006-02-15 2012-04-25 パナソニック株式会社 ネットワークシステム
KR101426710B1 (ko) * 2006-07-14 2014-09-23 삼성전자주식회사 휴대단말기의 버전정보 갱신 장치 및 방법
JP2009211260A (ja) * 2008-03-03 2009-09-17 Hitachi Ltd 情報通信システム
JP2009245397A (ja) * 2008-03-31 2009-10-22 Nippon Telegr & Teleph Corp <Ntt> サーバ補助装置とそのプログラム
CN101765100B (zh) * 2009-08-14 2012-08-22 北京握奇数据系统有限公司 一种实现移动办公的方法、系统及装置
CN102740511B (zh) * 2011-04-12 2016-01-20 深圳市中兴微电子技术有限公司 一种基于软件无线电的基带射频接口及其应用方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101083615A (zh) * 2006-05-29 2007-12-05 华为技术有限公司 一种跨域接收业务的方法、装置及系统
CN101262646A (zh) * 2007-12-27 2008-09-10 华为技术有限公司 控制发送多媒体消息的方法和多媒体消息业务中心
CN101668266A (zh) * 2008-09-02 2010-03-10 中国电信股份有限公司 一种主叫漏话消息提示方法和系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140128017A (ko) * 2013-04-26 2014-11-05 삼성전자주식회사 정보처리장치 및 그 제어방법
KR102099680B1 (ko) * 2013-04-26 2020-05-15 삼성전자주식회사 정보처리장치 및 그 제어방법

Also Published As

Publication number Publication date
CN102457824B (zh) 2015-05-27
KR101544289B1 (ko) 2015-08-12
KR20130108605A (ko) 2013-10-04
CN102457824A (zh) 2012-05-16
JP5908916B2 (ja) 2016-04-26
JP2013544461A (ja) 2013-12-12

Similar Documents

Publication Publication Date Title
CN1767508B (zh) 即时消息传送服务中的文件传输方法以及用于支持该方法的移动通信终端
US7200390B1 (en) Device software update transport and download
KR101038534B1 (ko) 확인된 ｏｔａ 단말기 구성을 제공하는 방법, 장치 및 컴퓨터 프로그램 생성물
EP1566042B1 (en) Method and system for session management wherein a client session identifier is used
EP2203006A1 (en) Device-based Network Service Provisioning
US20070178895A1 (en) Method, network entity, system, mobile device and computer program product for automatic provisioning of a service
JP2006311581A5 (zh)
JP4940304B2 (ja) 無線通信システムにおけるデータベース管理
KR20080012375A (ko) 호출 리마인더 제공 방법 및 장치
US20110016190A1 (en) Method and apparatus for realizing message service
EP4057586A1 (en) Multicast service session operation method and apparatus, and communication device
KR20210002544A (ko) 짧은 메시지 서비스 능력을 업데이트하기 위한 방법, 장비 및 장치
WO2011026281A1 (zh) 短消息重发的方法及短消息中心
CN105165035B (zh) 兼具文本消息传输的多媒体消息传输
EP1909511A1 (en) Application activation method
WO2012055349A1 (zh) 一种事件处理方法和装置
TWI357748B (en) System and method for correlating messages within
US20050181766A1 (en) Method and device for delivering messages to mobile terminal devices in accordance with a user selectable attainability status
WO2013091316A1 (zh) 一种基于ussd的软件更新方法和系统
US12101851B2 (en) Methods, network function nodes and computer readable media for contents communication management
WO2021237927A1 (zh) 一种一号双终端的实现方法及系统
WO2010045799A1 (zh) 发送消息的方法、装置和系统
WO2012022074A1 (zh) 用户信息的查询方法及多媒体消息中心
WO2023109344A1 (zh) 策略更新方法、设备及存储介质
WO2012106955A1 (zh) Widget信息处理方法、装置、服务器及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11835622

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013535265

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20137013163

Country of ref document: KR

Kind code of ref document: A

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 19/08/2013)

122 Ep: pct application non-entry in european phase

Ref document number: 11835622

Country of ref document: EP

Kind code of ref document: A1