WO2014061220A1 - 端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム - Google Patents

端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム Download PDF

Info

Publication number
WO2014061220A1
WO2014061220A1 PCT/JP2013/005876 JP2013005876W WO2014061220A1 WO 2014061220 A1 WO2014061220 A1 WO 2014061220A1 JP 2013005876 W JP2013005876 W JP 2013005876W WO 2014061220 A1 WO2014061220 A1 WO 2014061220A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
message
distribution device
push
same
Prior art date
Application number
PCT/JP2013/005876
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 EP13846473.0A priority Critical patent/EP2911343B1/en
Priority to JP2014541923A priority patent/JP6241418B2/ja
Priority to US14/432,725 priority patent/US9866644B2/en
Priority to CN201380054088.9A priority patent/CN104737499B/zh
Publication of WO2014061220A1 publication Critical patent/WO2014061220A1/ja

Links

Images

Classifications

    • 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/14—Session management
    • 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/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/668—Internet protocol [IP] address subnets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the present invention relates to a terminal for providing an event notification service to a user, a message delivery system, a message delivery method, and a message reception program.
  • VoIP (Voice over Internet Protocol) incoming notification and SNS (Social Networking Service) update notification such as an VoIP (Voice over Internet Protocol) incoming notification
  • VoIP Voice over Internet Protocol
  • SNS Social Networking Service
  • VoIP Voice over Internet Protocol
  • IP Internet Protocol
  • a server device that transmits a push message (hereinafter referred to as a push server) sends a notification request such as a VoIP incoming notification, an SNS update notification, chat message distribution, or a cloud storage update notification to a service provider server (hereinafter referred to as an application server).
  • the application server is a server device used by a service provider such as an SNS administrator.
  • the service provider uses the application server to request the push server to deliver a message addressed to the application provided by the service provider.
  • the service provider provides an application for using the service to the user in advance. And a user operates the application provided from the service provider on a terminal.
  • the push server transmits a push message to software (hereinafter referred to as a push client) operating on the terminal in accordance with the message delivery request.
  • the push client passes the received message to the destination application.
  • the application performs processing according to the content of the message received from the push client.
  • the push server issues an ID for each combination of terminal and application. For example, the push server issues an ID “xxxA” to the application A of the terminal X, an ID “xxxB” to the application B of the terminal X, and an ID “yyyC” to the application C of the terminal Y. .
  • the push server, push client, and application server share each ID.
  • FIG. 11 is an explanatory diagram showing an overview of the event notification service.
  • the application server makes a message delivery request, it passes an ID indicating the combination of the message delivery destination terminal and the application to the push server together with the message delivery request.
  • FIG. 11 shows an example in which the application server 700-1 of the service provider A passes the ID “xxxA” to the push server 600 together with the message delivery request addressed to the application A of the terminal X.
  • terminal 500-1 and terminal 500-2 correspond to terminal X and terminal Y, respectively.
  • an application provided by the service provider A hereinafter referred to as application A
  • an application provided by the service provider B hereinafter referred to as application B
  • an application hereinafter referred to as application C
  • application C an application provided by the service provider C is stored in the terminal Y.
  • the push server 600 transmits a message to the message delivery destination terminal X based on the ID “xxxA”.
  • the push client 510-1 of the terminal X transmits the received message to the message delivery destination application, that is, the application A, based on the ID “xxxA”.
  • Application A performs processing according to the received message. For example, the application A notifies the user of information or communicates with the content server to acquire updated content from the content server.
  • Patent Document 1 describes a connection-type delivery method that maintains a connection from a terminal to a push server according to the network environment and the push server resource status, or periodically polls the push server from the terminal. A method of selecting a polling type distribution method to be performed is described (for example, see Patent Document 1).
  • the terminal uses various networks such as a 3G (3rd Generation) line and WiFi (Wireless Fidelity) (registered trademark).
  • 3G (3rd Generation) line and WiFi (Wireless Fidelity) (registered trademark).
  • WiFi Wireless Fidelity
  • the connection method between the push server and the terminal may be limited by NAT (Network Address Translation) or FW (Fire Fall). In such a situation, the push message may not reliably reach the terminal.
  • the terminal when the terminal is under the NAT of the push server, that is, a router or the like having a NAT function may be installed between the push server and the terminal.
  • a router or the like having a NAT function may be installed between the push server and the terminal.
  • the IP packet cannot be directly transmitted from the push server to the terminal. Accordingly, a TCP session is established from the terminal side to the push server in advance, and the push server transmits a push message to the terminal using the established TCP session.
  • a router having a NAT function translates a terminal's global address and private address using an IP translation table.
  • the IP conversion table stores information indicating the correspondence between global addresses and private addresses for each TCP session.
  • NAT it is determined that a TCP session without communication for a certain period of time has timed out, and is deleted from the IP conversion table. The TCP session deleted from the IP conversion table becomes impossible to communicate. Then, the push server cannot make the push message reach the terminal.
  • the push server and the terminal regularly communicate to maintain the TCP session even if there is no push message to be distributed. For example, the KeepAlive signal is periodically transmitted and received.
  • the terminal When the terminal uses a mobile network such as a 3G line or LTE (Long Term Evolution), the terminal switches the radio state according to the communication state in order to save power. For example, the terminal sets the wireless state to a standby state or an active state according to the communication state. When switching the radio state, the terminal transmits / receives a control signal for switching the radio state to / from the mobile network.
  • the wireless state of the terminal When an application running on a terminal periodically generates communication, the wireless state of the terminal repeatedly alternates between a standby state and an active state, and a large number of control signals flow through the mobile network. Congestion occurs.
  • the processing load for responding to the control signals in the push server increases. Therefore, periodic communication for maintaining a TCP session causes congestion in the mobile network and increases the processing load on the push server.
  • the push server and the terminal are arranged in the same NAT, that is, when the push server and the terminal are on the same IP address space, the push server can directly send an IP packet to the terminal. . Therefore, if the push server and the terminal are arranged in the same NAT, it is not necessary to always maintain a TCP session, and congestion in the mobile network can be suppressed.
  • a terminal such as a smartphone can easily switch the network used by the terminal. Therefore, it is difficult to always arrange the push server and the terminal in the same NAT. For example, even if the terminal is located in the same NAT as the push server, when the network is switched to WiFi, the terminal may be under NAT.
  • the method described in Patent Document 1 selects a delivery method according to the status of the network being used, for example, the communication speed and the connection continuation time. That is, the method described in Patent Document 1 does not select a distribution method according to the type of network. Therefore, when the method described in Patent Document 1 is used, a connection-type delivery method may be selected in the mobile network, and congestion may occur in the mobile network.
  • the present invention provides a terminal, a message delivery system, a message delivery method, and a message reception capable of reliably delivering a push message from the push server to the terminal regardless of the type of network while reducing the processing load of the push server.
  • the purpose is to provide a program.
  • the terminal includes a network state detection unit that detects a state of a network connecting the terminal and a distribution device that performs message distribution in a push type, and the terminal and the distribution device based on the detection result. It is determined whether or not they are arranged in the same IP address space. If they are not arranged in the same IP address space, the first communication method using a TCP session established in advance is selected, and the same IP address space is selected. If it is located, select the second communication method that uses the TCP session that the distribution device establishes with the terminal itself during message distribution, and receive messages from the distribution device according to the selected communication method And a receiving unit.
  • a message distribution system includes a terminal and a distribution device that performs message distribution to the terminal in a push type, and the terminal detects a network state detecting unit that detects a state of a network connecting the terminal and the distribution device. Based on the detection result, it is determined whether or not the own terminal and the distribution device are arranged in the same IP address space. If they are not arranged in the same IP address space, a pre-established TCP session is used.
  • the terminal detects the state of the network connecting the terminal and the delivery device that performs message delivery in a push type, and the own terminal and the delivery device are the same based on the detection result. It is determined whether or not they are arranged in the IP address space. If they are not arranged in the same IP address space, the first communication method using the TCP session established in advance is selected and arranged in the same IP address space.
  • the distribution apparatus selects a second communication method that uses a TCP session newly established between itself and the terminal, and the distribution apparatus selects the communication method notified from the terminal. It is characterized in that message delivery is performed according to the above.
  • the message receiving program includes a process for detecting a state of a network connecting a terminal and the distribution apparatus to a computer mounted on a terminal capable of communicating with the distribution apparatus that performs message distribution in a push type, and a detection result. First, it is determined whether or not the terminal and the distribution device are arranged in the same IP address space. If the terminal and the distribution device are not arranged in the same IP address space, the first communication using the TCP session established in advance When a method is selected and placed in the same IP address space, a process for selecting a second communication method that uses a TCP session newly established between the distribution device and the own terminal at the time of message distribution, and selection And a process of receiving a message from the distribution apparatus according to the communication method.
  • the present invention it is possible to reliably reach the push message from the push server to the terminal regardless of the network type while reducing the processing load of the push server.
  • Embodiment 1 FIG. A first embodiment of the present invention will be described below with reference to the drawings.
  • FIG. 1 is a block diagram showing a configuration of a first embodiment of a message delivery system according to the present invention.
  • the communication system includes terminals 100-1 to 100-n, a push server 200, and application servers 300-1 to 300-n.
  • a push server 200 As shown in FIG. 1, the communication system includes terminals 100-1 to 100-n, a push server 200, and application servers 300-1 to 300-n.
  • one push server 200 is illustrated in FIG. 1, there may be any number of push servers.
  • the terminals 100-1 to 100-n are communication terminals such as mobile phones.
  • the push server 200 and the application servers 300-1 to 300-n are connected to be communicable.
  • the push server 200 and the terminals 100-1 to 100-n are communicably connected via a mobile network or a wireless LAN and the Internet.
  • the mobile network is, for example, a 3G line or LTE.
  • the wireless LAN is, for example, WiFi.
  • Each terminal includes a push client 110 and applications 120-1 to 120-n.
  • FIG. 2 is a block diagram showing the configuration of the first embodiment of the terminal according to the present invention.
  • the push client 110 of the terminal 100 includes a terminal state notification transmission unit 111, a network (NW) state detection unit 112, a message update notification reception unit 113, A message receiving unit 114 and a message notification unit 115 are included.
  • the terminal status notification transmission unit 111 performs terminal status notification. Specifically, the terminal state notification transmission unit 111 notifies the push server 200 of information indicating the terminal state (hereinafter referred to as terminal state information).
  • the terminal state information is information including the IP address of the terminal 100, for example.
  • the NW state detection unit 112 detects the network state. Specifically, the NW state detection unit 112 detects the type of network to which the terminal 100 and the push server 200 are connected as the network state.
  • the network type is, for example, a wireless LAN or a mobile network.
  • the message update notification receiving unit 113 receives a message update notification transmitted from the push server 200.
  • the message receiving unit 114 receives a message corresponding to the message update notification from the push server 200.
  • the message notification unit 115 passes the message received from the push server 200 to the applications 120-1 to 120-n.
  • Applications 120-1 to 120-n are application programs that run on the terminal 100.
  • the applications 120-1 to 120-n are provided from, for example, a service provider and stored in a storage unit (not shown) included in the terminal.
  • the push client 110 is realized by a CPU or the like included in the terminal 100.
  • the push server 200 is a server device that distributes push messages to terminals.
  • the push server 200 includes a control unit (not shown).
  • the control unit is realized by a CPU or the like included in the push server 200.
  • processing performed by the control unit of the push server 200 is simply expressed as processing performed by the push server 200.
  • Application servers 300-1 to 300-n are server devices used by each service provider.
  • the application servers 300-1 to 300-n transmit a message distribution request to the push server 200 in accordance with, for example, an operation input by the service provider.
  • a push method a method for acquiring a push message
  • the terminal uses the first communication method and the second communication method as the push method.
  • the first communication method is a long polling method (hereinafter simply referred to as long polling).
  • the second communication method is a direct IP method (hereinafter simply referred to as direct IP).
  • Long polling is a method in which a push server blocks a response to an HTTP request (HTTP GET) from a terminal until a push message to be distributed is generated. That is, when there is no push message to be distributed, the push server does not respond to the HTTP request until the message distribution request is received from the application server.
  • HTTP GET HTTP request
  • the push message can reach the terminal even when the terminal is connected to a wireless LAN such as WiFi under NAT. Further, long polling can cause a push message to reach a terminal even in an environment connected to the Internet via a proxy server, such as a corporate intranet.
  • a proxy server such as a corporate intranet.
  • Direct IP is a method in which a push server establishes a TCP session with a terminal at the time of message distribution, and transmits a push message using the established TCP session.
  • the push server cannot make a TCP connection with the terminal because the terminal and the push server exist in different IP address spaces. Therefore, when using the direct IP, it is necessary to place the push server in the same NAT as the terminal.
  • a telecommunications carrier (carrier) that provides a mobile phone service can install a push server in the mobile network. That is, the push server can be installed in the same NAT as the terminal. Therefore, even in an environment in which the mobile network is connected to the Internet via NAT, the carrier can use the direct IP in the mobile network by installing the push server in the mobile network.
  • the TCP session can be established from the push server to the terminal if the terminal is assigned a global IP address. Therefore, direct IP can be used.
  • Direct IP does not need to maintain a TCP session at all times, so congestion does not occur even when used in a mobile network.
  • the terminal 100 uses different push methods depending on the state of the network. Specifically, when the network is a wireless LAN such as WiFi, where the terminal is generally under NAT, the terminal 100 selects long polling. When the network is a mobile network in which the terminal and the push server are included in the same NAT, the terminal 100 selects the direct IP.
  • FIG. 3 is a sequence diagram showing an operation when the terminal 100 selects the long polling as the push method.
  • one application 120 applications 120-1 to 120-n
  • any number of applications may operate on the terminal 100.
  • one terminal 100 is illustrated, but when a plurality of terminals are connected to the push server 200, each terminal operates in the same manner as the terminal 100.
  • the push client 110 of the terminal 100 detects that the state of the network has changed (step S301). Specifically, the NW state detection unit 112 of the push client 110 receives a notification (hereinafter referred to as an NW state change notification) indicating that the network state has changed from an OS (Operating System) operating on the terminal 100. To do.
  • an NW state change notification a notification (hereinafter referred to as an NW state change notification) indicating that the network state has changed from an OS (Operating System) operating on the terminal 100.
  • the NW state detection unit 112 checks the network state based on the NW state change notification (step S302). Specifically, the NW state detection unit 112 checks the type of network that connects the terminal 100 and the push server 200. Here, the NW state detection unit 112 recognizes that the terminal 100 and the push server 200 are connected via a wireless LAN.
  • the message receiving unit 114 selects long polling as the push method. Then, the message receiving unit 114 transmits an inquiry request to the push server 200 in order to make an inquiry about the presence or absence of a push message to be distributed (hereinafter referred to as a push inquiry). Specifically, the message receiving unit 114 transmits an HTTP request (step S303).
  • the push server 200 does not respond immediately to the HTTP request.
  • the push server 200 blocks a response to the HTTP request until a push message to be delivered to the push client 110 of the terminal 100 is generated. If there is a push message to be delivered, a response is returned immediately without blocking.
  • FIG. 4 is a sequence diagram showing an operation when the terminal 100 selects the direct IP as the push method.
  • step S401 and step S402 Since the processing of step S401 and step S402 is the same as the processing of step S301 and step S302, description thereof will be omitted.
  • step S402 the NW state detection unit 112 recognizes that the terminal 100 and the push server 200 are connected via the mobile network.
  • the message receiving unit 114 selects direct IP as the push method.
  • the message update notification receiving unit 113 starts TCP standby (step S403). Specifically, the message update notification receiving unit 113 opens a TCP port so that a message update notification can be received.
  • Terminal status notification transmitter 111 notifies the status of the terminal (step S404). Specifically, the terminal state notification transmission unit 111 transmits terminal state information including the IP address of the terminal and the port number of the TCP port opened by the message update notification reception unit 113 to the push server 200.
  • the push client 110 of the terminal 100 waits for a TCP connection from the push server 200. That is, the push client 110 waits for the push server 200 to establish a TCP session with the terminal 100. At this time, the TCP session between the push client 110 and the push server 200 is not established. Therefore, the push client 110 and the push server 200 do not need to perform regular communication for maintaining the TCP session.
  • the push server 200 determines that the terminal 100 has selected long polling. In addition, when terminal state information is received from the terminal state notification transmission unit 111 in step S404, it is determined that the terminal 100 has selected the direct IP.
  • the push server 200 is notified of the selection result of the push method by the terminal state notification or the push inquiry.
  • the URL path of the terminal status notification and the URL path of the push inquiry are set separately, and the push server 200 may determine which URL has been accessed. .
  • FIG. 5 is a sequence diagram showing push message delivery processing by long polling.
  • the sequence diagram shown in FIG. 5 shows the operation of the message distribution system after the terminal 100 performs the push inquiry.
  • the push server 200 When the push server 200 receives a push inquiry as an HTTP request from the message receiving unit 114 of the push client 110 (step S501), the push server 200 determines that the terminal 100 has selected long polling. At this time, the push server 200 waits for the generation of a push message to be delivered without immediately responding. That is, the push server 200 is in a push wait state.
  • the push server 200 When the push server 200 receives a push message distribution request from the application server 300 (step S502), the push server 200 transmits the push message to the push client 110 together with an HTTP response (HTTP 200 OK) indicating that the HTTP request has been processed normally. (Step S503).
  • HTTP 200 OK HTTP response
  • the message notification unit 115 of the push client 110 passes the message received in step S503 to the corresponding application (step S504).
  • FIG. 6 is a sequence diagram showing push message delivery processing by direct IP.
  • the sequence diagram shown in FIG. 6 shows the operation of the message delivery system after the terminal 100 has notified the terminal state.
  • the push server 200 When the push server 200 receives the terminal status notification from the terminal 100, that is, when receiving the terminal status information from the terminal 100, the push server 200 determines that the terminal 100 has selected the direct IP. Thereafter, when a push message delivery request is received from the application server 300 (step S601), the push server 200 performs a TCP connection to the push client 110 (step S602). In direct IP, this TCP connection becomes a message update notification. That is, the message update notification receiving unit 113 determines that there has been a message update notification by detecting a TCP connection.
  • the message receiving unit 114 starts message acquisition processing using this as a trigger. That is, a message acquisition request is transmitted as an HTTP request to the push server 200 (step S603).
  • the push server 200 transmits a push message to the push client 110 together with an HTTP response indicating that the HTTP request has been processed normally (step S604).
  • the message notification unit 115 of the push client 110 passes the message received in step S604 to the corresponding application (step S605).
  • the terminal determines a push method according to the network state. Therefore, it is possible to reduce the processing load on the push server as compared with the case where only the long polling method is used, and to ensure that the push message reaches the push client in the terminal regardless of the type of network used by the terminal. .
  • the direct IP that does not need to maintain the TCP session at all times is selected as the push method, so that the occurrence of control signal congestion in the mobile network can be suppressed.
  • the push method when the terminal and the push server are in different IP address spaces, long polling that allows communication via NAT or FW and communication via a proxy server is selected as the push method.
  • other methods may be used.
  • WebSocket or TCP unique communication can be used. That is, the first communication method may be WebSocket or TCP original communication.
  • WebSocket is a communication method for bidirectional communication on a TCP between a web server and a browser.
  • WebSocket once a TCP session is established, bidirectional communication between the terminal and the push server becomes possible thereafter.
  • TCP original communication is a communication method on TCP originally developed by a user or the like.
  • a message distribution system that distributes push messages to terminals by long polling and direct IP is taken as an example.
  • push messages may not reach the terminal even by long polling and direct IP.
  • the terminal is in a no-communication (sleep) state for a long time, and the IP address of the terminal is released.
  • the push server 200 distributes the push message using SMS (Short Message Service).
  • SMS Short Message Service
  • FIG. 7 is a sequence diagram showing push message delivery processing by SMS.
  • the push server 200 determines whether the push message can be delivered by the push method selected by the delivery destination terminal. In this embodiment, the push server 200 executes a push message delivery trial and determines whether or not delivery is possible based on the result of the delivery trial (step S702).
  • the push server 200 tries to distribute the push message by the direct IP when the distribution destination terminal selects the direct IP as the push method. In addition, when the delivery destination terminal selects the long polling as the push method, the push server 200 tries to deliver the push message by the long polling.
  • the terminal 100 may be in a sleep state for a long time, and the IP address of the terminal 100 may be released. In that case, the push message is not distributed to the terminal 100.
  • the push server 200 determines that the push message cannot be delivered by the push method selected by the delivery destination terminal. Then, the push server 200 transmits a notification indicating that there is a push message to be distributed to the push client 110 by SMS (step S703). At this time, even if the IP address of the terminal 100 is released, the notification by SMS reaches the terminal 100. In the present embodiment, notification by SMS becomes a message update notification. That is, when receiving the notification by SMS, the message update notification receiving unit 113 determines that there has been a message update notification.
  • the message receiving unit 114 starts message acquisition processing using this as a trigger.
  • the IP address of the terminal 100 is released, but an IP address is assigned to the terminal 100 at a timing when the terminal 100 tries to communicate with the push server 200.
  • a DHCP Dynamic Host Configuration Protocol
  • the push message can be distributed to the terminal 100.
  • the message receiving unit 114 transmits a message acquisition request as an HTTP request to the push server 200 (step S704).
  • the push server 200 transmits a push message to the push client 110 together with an HTTP response indicating that the HTTP request has been processed normally (step S705).
  • the message notification unit 115 of the push client 110 passes the message received in step S705 to the distribution destination application (step S706).
  • the terminal when the terminal receives an SMS notification indicating that there is a push message to be distributed from the push server, the terminal transmits a message acquisition request to the push server. Therefore, even if the push server cannot make the push message reach the terminal even by long polling and direct IP, if the push server sends a notification by SMS to the terminal, the terminal pushes based on the notification. You can get a message. Therefore, for example, even when the IP address of the terminal is open, the push message can be reliably delivered to the terminal.
  • SMS short message
  • a method other than SMS is used. May be used.
  • the configuration of the terminal 100 in the third embodiment is the same as the configuration in the first embodiment and the second embodiment, and a description thereof will be omitted.
  • the terminal state notification transmission unit 111 does not perform terminal state notification when the IP address of the terminal is the same as the IP address when the terminal state notification was made last time.
  • FIG. 8 is a sequence diagram showing the operation of the third embodiment when the terminal 100 selects the direct IP as the push method.
  • steps S801 to S803 Since the processing of steps S801 to S803 is the same as the processing of steps S401 to S403 of the first embodiment, description thereof is omitted.
  • the terminal state notification transmission unit 111 checks whether or not the IP address currently assigned to the terminal is the same as the IP address when the terminal state notification was made last time (step S804).
  • the terminal state notification transmission unit 111 does not perform terminal state notification (step S805). If the IP addresses are not the same, the terminal state notification transmission unit 111 performs a terminal state notification in the same manner as the process in step S404.
  • the terminal when the terminal selects direct IP as the push method, if the IP address of the terminal is the same as the previous terminal state notification, the terminal performs terminal state notification. Absent. Thereby, the processing load of the terminal and the push server can be further reduced. In particular, in an environment where the network state of the terminal is frequently switched, the processing load on the terminal and the push server can be reduced.
  • terminal status information is transmitted from the terminal to the push server every time the network is switched from WiFi to the mobile network. Therefore, the processing load on the terminal and the push server may increase. However, according to the present embodiment, the processing load on the terminal and the push server can be reduced even in such an environment.
  • FIG. 9 is a block diagram showing a minimum configuration of a terminal according to the present invention.
  • FIG. 10 is a block diagram showing the minimum configuration of the message delivery system according to the present invention.
  • the terminals corresponding to the terminals 100-1 to 100-n shown in FIG. 1 and the terminal 100 shown in FIG. 2 and the distribution device (FIG. And a detection result of the network state detection unit 11 (corresponding to the NW state detection unit 112 in the push client 110 of the terminal 100 shown in FIG. 2).
  • a detection result of the network state detection unit 11 corresponding to the NW state detection unit 112 in the push client 110 of the terminal 100 shown in FIG. 2.
  • the reception unit 12 determines that the terminal and the distribution device are not arranged in the same IP address space, and the network is a mobile network If it is, the terminal that determines that its own terminal and the distribution device are arranged in the same IP address space.
  • the receiving unit 12 transmits an inquiry request for inquiring whether there is a message to be distributed to the distribution device, and when the second communication method is selected, the receiving unit 12 A terminal that transmits a message acquisition request to the distribution device when a TCP connection is detected.
  • the receiving unit 12 is a terminal that notifies the distribution device of terminal state information including the IP address of the own terminal when the second communication method is selected.
  • the distribution apparatus can recognize the IP address of the terminal based on the terminal status notification, and can perform TCP connection from the distribution apparatus to the terminal. Further, by notifying the terminal state information, the distribution apparatus can recognize that the terminal has selected the direct IP as the push method.
  • the receiving unit 12 is a terminal that transmits a message acquisition request to the distribution apparatus when detecting notification by SMS indicating that there is a message to be distributed.
  • the terminal can recognize that there is a push message to be delivered by notification by SMS. Therefore, even in such a case, the terminal can reliably acquire the push message.
  • the receiving unit 12 is a terminal that does not notify the distribution device of the terminal state information when the IP address of the own terminal when the previous terminal state information is notified and the current IP address of the own terminal are the same.
  • a message delivery system as shown in FIG. 10 is also disclosed.
  • each of the terminals 10-1 to 10-n includes a network state detection unit 11 that detects a state of a network that connects the terminal 10 and the distribution device 20, and a detection Based on the result, it is determined whether or not the own terminal and the distribution device 20 are arranged in the same IP address space. If they are not arranged in the same IP address space, a pre-established TCP session is used.
  • the second communication method uses a TCP session newly established between the distribution device 20 and the own terminal at the time of message distribution And a receiving unit 12 that receives a message from the distribution device 20 according to the selected communication method, and the distribution device 20 performs message distribution according to the communication method selection result notified from the terminal.
  • a message delivery system comprising a control unit (not shown) in the push server 200 shown in FIG.
  • the push message can surely reach the terminal without increasing the processing load of the distribution device regardless of the type of network used by the terminal.
  • the reception unit 12 determines that the terminal and the distribution device 20 are not arranged in the same IP address space, and the network is In the case of a mobile network, a message distribution system that determines that its own terminal and distribution device 20 are located in the same IP address space.
  • Terminals 10-1 to 10-n are self-terminals
  • the network state detection unit 11 for detecting the state of the network connecting the distribution device 20 and the detection result, it is determined whether the own terminal and the distribution device 20 are arranged in the same IP address space.
  • the distribution device 20 A receiving unit 12 that selects a second communication method using a TCP session newly established with the own terminal and receives a message from the distribution device 20 according to the selected communication method; , Delivery device 20, message delivery system comprising a control unit 21 for performing message delivery in accordance with the selection result of the communication mode notified from the terminal.
  • the receiving unit 12 transmits an inquiry request for inquiring whether there is a message to be distributed to the distribution device 20, and when the second communication method is selected, the reception unit 12 performs distribution.
  • the message delivery system according to appendix 1 or appendix 2, wherein a message acquisition request is transmitted to the delivery device 20 when a TCP connection with the device 20 is detected.
  • the push message can be delivered from the delivery device to the terminal according to the push method selected by the terminal.
  • the receiving unit 12 When the second communication method is selected, the receiving unit 12 notifies the distribution device 20 of terminal status information including the IP address of the own terminal, and the control unit 21 also stores the terminal status information during message distribution. 4.
  • the message delivery system according to any one of supplementary notes 1 to 3, which establishes a TCP session with the terminals 10-1 to 10-n.
  • the distribution apparatus can recognize the IP address of the terminal based on the terminal status notification, and can perform TCP connection from the distribution apparatus to the terminal. Further, by notifying the terminal state information, the distribution apparatus can recognize that the terminal has selected the direct IP as the push method.
  • control unit 21 determines that the message cannot be delivered by the first communication method or the second communication method, the control unit 21 sends a notification by SMS indicating that there is a message to be delivered to the terminals 10-1 to 10-1.
  • the message delivery system according to any one of Supplementary Note 1 to Supplementary Note 4, wherein the reception unit 12 transmits a message acquisition request to the distribution device 20 when detecting a notification by SMS.
  • the distribution device can recognize that there is a push message to be distributed to the terminal by notification by SMS, Push messages can be reliably delivered to terminals.
  • the receiving unit 12 does not notify the distribution device 20 of the terminal state information when the IP address of the own terminal when the previous terminal state information is notified and the current IP address of the own terminal are the same.
  • the message delivery system according to appendix 4 or appendix 5.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephone Function (AREA)

Abstract

　プッシュサーバの処理負荷を削減しつつ、端末が利用するネットワークの種別によらずに、プッシュサーバから端末にプッシュメッセージを確実に到達させることができる端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラムを提供する。自端末と、メッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部１１と、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、配信装置からメッセージを受信する受信部１２とを備える。

Description

端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム
　本発明は、イベント通知サービスをユーザに提供するための端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラムに関する。
　ＶｏＩＰ（Ｖｏｉｃｅ　ｏｖｅｒ　Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）の着信通知やＳＮＳ（Ｓｏｃｉａｌ　Ｎｅｔｗｏｒｋｉｎｇ　Ｓｅｒｖｉｃｅ）の更新通知など、サーバ装置から端末に対してＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）ネットワークを通して能動的にイベントを通知するイベント通知サービスがある。イベント通知サービスにおいてサーバ装置が端末に対してプッシュ型で行う通知は、プッシュ通知（Ｐｕｓｈ　Ｎｏｔｉｆｉｃａｔｉｏｎ）またはプッシュメッセージと呼ばれる。プッシュメッセージを送信するサーバ装置（以下、プッシュサーバという。）は、ＶｏＩＰの着信通知、ＳＮＳの更新通知、チャットメッセージ配信、クラウドストレージの更新通知などの通知要求をサービス事業者サーバ（以下、アプリケーションサーバという。）から受け取る。アプリケーションサーバは、ＳＮＳ管理者等のサービス事業者が使用するサーバ装置である。
　サービス事業者は、アプリケーションサーバを使用して、自身が提供するアプリケーション宛てのメッセージ配信をプッシュサーバに要求する。サービス事業者は、予め、サービスを利用するためのアプリケーションをユーザに提供する。そして、ユーザは、サービス事業者から提供されたアプリケーションを端末上で動作させる。
　プッシュサーバは、メッセージ配信要求に従って端末上で動作するソフトウェア（以下、プッシュクライアントという。）に対してプッシュメッセージを送信する。プッシュクライアントは、受信したメッセージを宛先のアプリケーションに渡す。アプリケーションは、プッシュクライアントから受け取ったメッセージの内容に応じた処理を行う。
　イベント通知サービスでは、プッシュサーバが、端末とアプリケーションとの組み合わせごとに、ＩＤを発行する。例えば、プッシュサーバは、端末ＸのアプリケーションＡに対してはＩＤ「ｘｘｘＡ」、端末ＸのアプリケーションＢに対してはＩＤ「ｘｘｘＢ」、端末ＹのアプリケーションＣに対してはＩＤ「ｙｙｙＣ」を発行する。プッシュサーバ、プッシュクライアント、アプリケーションサーバは、各ＩＤを共有する。
　図１１は、イベント通知サービスの概要を示す説明図である。アプリケーションサーバはメッセージ配信要求をするとき、メッセージ配信要求とともに、メッセージの配信先の端末とアプリケーションとの組み合わせを示すＩＤをプッシュサーバに渡す。図１１は、サービス事業者Ａのアプリケーションサーバ７００－１が、端末ＸのアプリケーションＡ宛てのメッセージ配信要求とともにＩＤ「ｘｘｘＡ」をプッシュサーバ６００に渡した場合の例である。ここで、端末５００－１、端末５００－２がそれぞれ端末Ｘ、端末Ｙに相当するとする。また、端末Ｘに、サービス事業者Ａが提供するアプリケーション（以下、アプリケーションＡという。）とサービス事業者Ｂが提供するアプリケーション（以下、アプリケーションＢという。）とが格納されているとする。また、端末Ｙに、サービス事業者Ｃが提供するアプリケーション（以下、アプリケーションＣという。）が格納されているとする。
　プッシュサーバ６００は、ＩＤ「ｘｘｘＡ」にもとづいて、メッセージ配信先の端末Ｘにメッセージを送信する。端末Ｘのプッシュクライアント５１０－１は、ＩＤ「ｘｘｘＡ」にもとづいて、受信したメッセージをメッセージ配信先のアプリケーション、つまりアプリケーションＡに送信する。
　アプリケーションＡは、受信したメッセージに応じた処理を行う。例えば、アプリケーションＡは、ユーザに情報を通知したり、コンテンツサーバと通信してコンテンツサーバから更新されたコンテンツを取得したりする。
　特許文献１には、ネットワーク環境やプッシュサーバのリソースの状況に応じて、端末からプッシュサーバへのコネクションを維持し続けるコネクション型の配信方法、または、定期的に端末からプッシュサーバに対してポーリングを行うポーリング型の配信方法を選択する方法が記載されている（例えば、特許文献１参照。）。
特開２０１１－１２３８０１号公報
　端末は、３Ｇ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ）回線やＷｉＦｉ（Ｗｉｒｅｌｅｓｓ　Ｆｉｄｅｌｉｔｙ）（登録商標）など様々なネットワークを利用する。端末が利用するネットワークによっては、ＮＡＴ（Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｔｒａｎｓｌａｔｉｏｎ）やＦＷ（ファイヤフォール）などにより、プッシュサーバ・端末間の接続方法が制限されることがある。そのような状況では、プッシュメッセージを端末に確実に到達させることができない場合がある。
　例えば、端末がプッシュサーバのＮＡＴ配下となる場合、つまり、プッシュサーバ・端末間にＮＡＴ機能を備えたルータ等が設置される場合がある。その場合、プッシュサーバと端末とのＩＰアドレス空間が異なるため、プッシュサーバから端末に直接ＩＰパケットを送信することができない。従って、予め端末側からプッシュサーバに対しＴＣＰセッションの確立を実施しておき、プッシュサーバは確立済みのＴＣＰセッションを利用してプッシュメッセージを端末に送信する。
　ＮＡＴ機能を備えたルータは、ＩＰ変換テーブルを用いて端末のグローバルアドレスとプライベートアドレスとを変換する。ＩＰ変換テーブルは、グローバルアドレスとプライベートアドレスとの対応を示す情報を、ＴＣＰセッションごとに記憶する。ＮＡＴでは、一定時間通信のないＴＣＰセッションはタイムアウトしたと判断され、ＩＰ変換テーブルから削除される。ＩＰ変換テーブルから削除されたＴＣＰセッションは、通信不能になる。すると、プッシュサーバは、端末にプッシュメッセージを到達させることができなくなる。
　従って、端末がプッシュサーバのＮＡＴ配下となる環境では、プッシュサーバと端末は、配信すべきプッシュメッセージがない場合であっても、ＴＣＰセッションを維持するために、定期的に通信を行う。例えば、ＫｅｅｐＡｌｉｖｅ信号の送受信を定期的に行う。
　端末は、３Ｇ回線やＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）などのモバイル網を利用するとき、電力を節約するために通信状態に応じて無線状態を切り替える。例えば、端末は、通信状態に応じて、無線状態をスタンバイ状態にしたりアクティブ状態にしたりする。無線状態の切り替えの際、端末は、モバイル網との間で無線状態を切り替えるための制御信号の送受信を行う。端末上で動作するアプリケーションなどが定期的に通信を発生させる場合、端末の無線状態は、スタンバイ状態とアクティブ状態とを交互に繰り返すことになり、モバイル網に多数の制御信号が流れ、モバイル網で輻輳が発生する。また、多数の制御信号が発生することにより、プッシュサーバにおける制御信号に応答するための処理負荷が増大する。従って、ＴＣＰセッションを維持するための定期的な通信は、モバイル網で輻輳を発生させ、プッシュサーバの処理負荷を増大させる。
　プッシュサーバと端末とが同一ＮＡＴ内に配置されている場合、つまり、プッシュサーバと端末とが同じＩＰアドレス空間上に存在する場合には、プッシュサーバから端末に直接ＩＰパケットを送信することができる。従って、プッシュサーバと端末とを同一ＮＡＴ内に配置すれば、常時ＴＣＰセッションを維持する必要がないので、モバイル網における輻輳を抑制することができる。しかし、スマートフォンなどの端末は、自端末が利用するネットワークを容易に切り替えることができる。従って、プッシュサーバと端末とを常に同一ＮＡＴ内に配置させておくことは難しい。例えば、端末がプッシュサーバと同一ＮＡＴ内に配置されていたとしても、ネットワークをＷｉＦｉに切り替えたときに、端末がＮＡＴ配下になってしまう場合がある。
　特許文献１に記載された方法は、利用中のネットワークの状況、例えば、通信速度やコネクションの継続可能時間に応じて配信方法を選択する。つまり、特許文献１に記載された方法は、ネットワークの種別に応じた配信方法の選択を行っていない。そのため、特許文献１に記載された方法を用いた場合、モバイル網においてコネクション型の配信方法が選択される可能性があり、モバイル網で輻輳を発生させる可能性がある。
　そこで、本発明は、プッシュサーバの処理負荷を削減しつつ、ネットワークの種別によらずにプッシュサーバから端末にプッシュメッセージを確実に到達させることができる端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラムを提供することを目的とする。
　本発明による端末は、自端末と、メッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部と、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置からメッセージを受信する受信部とを備えたことを特徴とする。
　本発明によるメッセージ配信システムは、端末と、端末にメッセージの配信をプッシュ型で行う配信装置とを備え、端末は、自端末と配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部と、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置からメッセージを受信する受信部とを備え、配信装置は、端末から通知された通信方式の選択結果に応じたメッセージ配信を行う制御部を備えたことを特徴とする。
　本発明によるメッセージ配信方法は、端末が、自端末とメッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知し、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、配信装置が、端末から通知された通信方式の選択結果に応じたメッセージ配信を行うことを特徴とする。
　本発明によるメッセージ受信プログラムは、メッセージの配信をプッシュ型で行う配信装置と通信可能な端末に搭載されるコンピュータに、端末と配信装置とを接続するネットワークの状態を検知する処理と、検知結果をもとに、端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択する処理と、選択した通信方式に応じて配信装置からメッセージを受信する処理とを実行させることを特徴とする。
　本発明によれば、プッシュサーバの処理負荷を削減しつつ、ネットワークの種別によらずにプッシュサーバから端末にプッシュメッセージを確実に到達させることができる。
本発明によるメッセージ配信システムの第１の実施形態の構成を示すブロック図である。 端末の第１の実施形態の構成を示すブロック図である。 端末がプッシュ方法としてロングポーリングを選択した場合の動作を示すシーケンス図である。 端末がプッシュ方法としてダイレクトＩＰを選択した場合の動作を示すシーケンス図である。 ロングポーリングによるプッシュメッセージの配信処理を示すシーケンス図である。 ダイレクトＩＰによるプッシュメッセージの配信処理を示すシーケンス図である。 ＳＭＳによるプッシュメッセージの配信処理を示すシーケンス図である。 端末がプッシュ方法としてダイレクトＩＰを選択した場合の第３の実施形態の動作を示すシーケンス図である。 本発明による端末の最小構成を示すブロック図である。 本発明によるメッセージ配信システムの最小構成を示すブロック図である。 イベント通知サービスの概要を示す説明図である。
実施形態１．
　以下、本発明の第１の実施形態を図面を参照して説明する。
　図１は、本発明によるメッセージ配信システムの第１の実施形態の構成を示すブロック図である。
　通信システムは、図１に示すように、端末１００－１～１００－ｎと、プッシュサーバ２００と、アプリケーションサーバ３００－１～３００－ｎとを含む。なお、図１には、１つのプッシュサーバ２００が例示されているが、プッシュサーバはいくつあってもよい。
　端末１００－１～１００－ｎは、例えば、携帯電話機等の通信端末である。プッシュサーバ２００とアプリケーションサーバ３００－１～３００－ｎとは、通信可能に接続される。プッシュサーバ２００と端末１００－１～１００－ｎとは、モバイル網または無線ＬＡＮ、およびインターネットを介して通信可能に接続される。モバイル網は、例えば、３Ｇ回線やＬＴＥである。無線ＬＡＮは、例えばＷｉＦｉである。
　各端末は、プッシュクライアント１１０と、アプリケーション１２０－１～１２０－ｎとを含む。
　図２は、本発明による端末の第１の実施形態の構成を示すブロック図である。
　図２に示すように端末１００（端末１００－１～１００－ｎ）のプッシュクライアント１１０は、端末状態通知送信部１１１と、ネットワーク（ＮＷ）状態検知部１１２と、メッセージ更新通知受信部１１３と、メッセージ受信部１１４と、メッセージ通知部１１５とを含む。
　端末状態通知送信部１１１は、端末状態通知を行う。具体的には、端末状態通知送信部１１１は、端末状態を示す情報（以下、端末状態情報という。）をプッシュサーバ２００に通知する。端末状態情報は、例えば、端末１００のＩＰアドレスを含む情報である。
　ＮＷ状態検知部１１２は、ネットワーク状態を検知する。具体的には、ＮＷ状態検知部１１２は、ネットワーク状態として、端末１００とプッシュサーバ２００とが接続されているネットワークの種別を検知する。ネットワークの種別は、例えば、無線ＬＡＮや、モバイル網である。
　メッセージ更新通知受信部１１３は、プッシュサーバ２００から送信されるメッセージ更新通知を受信する。
　メッセージ受信部１１４は、メッセージ更新通知に対応するメッセージをプッシュサーバ２００から受信する。
　メッセージ通知部１１５は、プッシュサーバ２００から受信したメッセージをアプリケーション１２０－１～１２０－ｎに渡す。
　アプリケーション１２０－１～１２０－ｎは、端末１００上で動作するアプリケーションプログラムである。アプリケーション１２０－１～１２０－ｎは、例えばサービス事業者等から提供され、端末が備える記憶部（図示せず）に格納される。
　なお、プッシュクライアント１１０は、端末１００が備えるＣＰＵ等によって実現される。
　プッシュサーバ２００は、プッシュメッセージを端末に配信するサーバ装置である。プッシュサーバ２００は、制御部（図示せず）を備える。なお、制御部は、プッシュサーバ２００が備えるＣＰＵ等によって実現される。以降、プッシュサーバ２００の制御部が処理することを、単にプッシュサーバ２００が処理すると表現する。
　アプリケーションサーバ３００－１～３００－ｎは、各サービス事業者が使用するサーバ装置である。アプリケーションサーバ３００－１～３００－ｎは、例えばサービス事業者が入力した操作に応じて、メッセージ配信要求をプッシュサーバ２００に送信する。
　次に、本実施形態の動作を説明する。
　まず、端末１００が、プッシュメッセージを取得する方法（以下、プッシュ方法という。）を決定する動作を説明する。
　本実施形態では、端末はプッシュ方法として第一の通信方式と第二の通信方式とを用いる。第一の通信方式はロングポーリング方式（以下、単にロングポーリングという。）である。第二の通信方式はダイレクトＩＰ方式（以下、単にダイレクトＩＰという。）である。
　ロングポーリングは、プッシュサーバが、端末からのＨＴＴＰ要求（ＨＴＴＰ　ＧＥＴ）に対して、配信すべきプッシュメッセージが発生するまで、応答をブロックする方法である。つまり、プッシュサーバは、配信すべきプッシュメッセージがない場合には、メッセージ配信要求をアプリケーションサーバから受け付けるまで、ＨＴＴＰ要求に対する応答をしない。
　ロングポーリングは、ＨＴＴＰを利用するため、端末がＮＡＴ配下となるＷｉＦｉなどの無線ＬＡＮに接続している場合においても、プッシュメッセージを端末に到達させることができる。また、ロングポーリングは、企業内イントラネットのようにプロキシサーバを経由してインターネットに接続する環境においても、端末にプッシュメッセージを到達させることができる。
　しかし、ロングポーリングは、ＴＣＰセッションを常時維持しておく必要がある。従って、プッシュサーバおよび端末は、ＴＣＰセッションを維持するために定期的に通信を行う必要がある。そのため、モバイル網においてロングポーリングを行った場合には、輻輳が発生する可能性がある。また、サーバ負荷が増大する可能性がある。
　ダイレクトＩＰは、プッシュサーバが、メッセージ配信時に端末とのＴＣＰセッションを確立させ、確立したＴＣＰセッションを利用してプッシュメッセージを送信する方法である。
　端末がＮＡＴ配下にある場合には、端末とプッシュサーバとが異なるＩＰアドレス空間に存在するため、プッシュサーバは当該端末とのＴＣＰ接続を行うことができない。従って、ダイレクトＩＰを利用する場合には、プッシュサーバを端末と同一ＮＡＴ内に配置する必要がある。
　携帯電話サービスを提供する通信事業者（キャリア）は、モバイル網内にプッシュサーバを設置することができる。つまり、プッシュサーバを端末と同一ＮＡＴ内に設置することができる。よって、モバイル網がＮＡＴ経由でインターネットに繋がっている環境でも、キャリアがプッシュサーバをモバイル網内に設置することにより、当該モバイル網でダイレクトＩＰを利用することが可能となる。
　プッシュサーバと端末とが同一ＮＡＴ内に設置されていない場合であっても、端末にグローバルＩＰアドレスが割り振られている場合には、プッシュサーバから端末に対してＴＣＰセッションの確立を行うことができるので、ダイレクトＩＰを利用することができる。
　ダイレクトＩＰは、ＴＣＰセッションを常時維持させておく必要がないため、モバイル網で利用しても輻輳を発生させない。
　そこで、本実施形態では、端末１００は、ネットワークの状態に応じて、プッシュ方法を使い分ける。具体的には、ネットワークが、一般的に端末がＮＡＴ配下となるＷｉＦｉなどの無線ＬＡＮの場合には、端末１００はロングポーリングを選択する。ネットワークが、端末とプッシュサーバとが同一ＮＡＴ内に含まれるモバイル網の場合には、端末１００はダイレクトＩＰを選択する。
　図３は、端末１００がプッシュ方法としてロングポーリングを選択した場合の動作を示すシーケンス図である。なお、図３では、アプリケーション１２０（アプリケーション１２０－１～１２０－ｎ）が１つ例示されているが、アプリケーションは端末１００上でいくつ動作していてもよい。また、図３では、端末１００が１つ例示されているが、プッシュサーバ２００に複数台の端末が接続される場合には各端末が端末１００と同様の動作をする。
　端末１００とプッシュサーバ２００とを接続するネットワークの状態に変化があった場合、端末１００のプッシュクライアント１１０は、ネットワークの状態が変化したことを検知する（ステップＳ３０１）。具体的には、プッシュクライアント１１０のＮＷ状態検知部１１２が、端末１００上で動作するＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）からネットワークの状態が変化したことを示す通知（以下、ＮＷ状態変更通知という。）を受信する。
　ＮＷ状態検知部１１２は、ＮＷ状態変更通知をもとに、ネットワーク状態を確認する（ステップＳ３０２）。具体的には、ＮＷ状態検知部１１２は、端末１００とプッシュサーバ２００とを接続するネットワークの種別を確認する。ここでは、ＮＷ状態検知部１１２は、端末１００とプッシュサーバ２００とが無線ＬＡＮを介して接続されていることを認識する。
　メッセージ受信部１１４は、ネットワークが無線ＬＡＮであるので、プッシュ方法としてロングポーリングを選択する。そして、メッセージ受信部１１４は、プッシュサーバ２００に対して、配信すべきプッシュメッセージの有無の問い合わせ（以下、プッシュ問い合わせという。）を行うために、問い合わせ要求を送信する。具体的には、メッセージ受信部１１４は、ＨＴＴＰ要求を送信する（ステップＳ３０３）。
　プッシュサーバ２００は、ＨＴＴＰ要求に対して即座に応答しない。プッシュサーバ２００は、端末１００のプッシュクライアント１１０に対して配信すべきプッシュメッセージが発生するまで、ＨＴＴＰ要求に対する応答をブロックする。なお、配信すべきプッシュメッセージがある場合には、ブロックせずに即座に応答を返す。
　図４は、端末１００がプッシュ方法としてダイレクトＩＰを選択した場合の動作を示すシーケンス図である。
　ステップＳ４０１、ステップＳ４０２の処理は、ステップＳ３０１、ステップＳ３０２の処理と同様であるため説明を省略する。
　なお、ステップＳ４０２では、ＮＷ状態検知部１１２は、端末１００とプッシュサーバ２００とがモバイル網を介して接続されていることを認識する。
　メッセージ受信部１１４は、ネットワークがモバイル網であるので、プッシュ方法としてダイレクトＩＰを選択する。
　メッセージ更新通知受信部１１３は、ＴＣＰ待ち受けを開始する（ステップＳ４０３）。具体的には、メッセージ更新通知受信部１１３は、ＴＣＰのポートを開放し、メッセージ更新通知を受信可能な状態にする。
　端末状態通知送信部１１１は、端末の状態を通知する（ステップＳ４０４）。具体的には、端末状態通知送信部１１１は、端末のＩＰアドレスと、メッセージ更新通知受信部１１３が開放したＴＣＰポートのポート番号とを含む端末状態情報をプッシュサーバ２００に送信する。
　ステップＳ４０４の後、端末１００のプッシュクライアント１１０は、プッシュサーバ２００からのＴＣＰ接続を待つ。つまり、プッシュクライアント１１０は、プッシュサーバ２００が端末１００とのＴＣＰセッションを確立するのを待つ。このとき、プッシュクライアント１１０とプッシュサーバ２００間のＴＣＰセッションは確立されていない。従って、プッシュクライアント１１０とプッシュサーバ２００とは、ＴＣＰセッションを維持するための定期的な通信を行う必要がない。
　ここで、プッシュサーバ２００におけるプッシュ方法の判定処理を説明する。
　プッシュサーバ２００は、ステップＳ３０３において、プッシュ問い合わせのＨＴＴＰ要求を受信すると、端末１００がロングポーリングを選択したと判断する。また、ステップＳ４０４において端末状態通知送信部１１１から端末状態情報を受信すると、端末１００がダイレクトＩＰを選択したと判断する。
　このように、端末状態通知またはプッシュ問い合わせによって、プッシュ方法の選択結果がプッシュサーバ２００に通知される。このような形態を実現するには、例えば、端末状態通知のＵＲＬのパスと、プッシュ問い合わせのＵＲＬのパスとを別に設定し、プッシュサーバ２００は、どちらのＵＲＬにアクセスがあったかを判断すればよい。
　次に、端末１００がロングポーリングによりプッシュメッセージを取得する動作を説明する。
　図５は、ロングポーリングによるプッシュメッセージの配信処理を示すシーケンス図である。
　図５に示すシーケンス図においては、端末１００によるプッシュ問い合わせ実施以降のメッセージ配信システムの動作を示す。
　プッシュサーバ２００は、プッシュクライアント１１０のメッセージ受信部１１４からＨＴＴＰ要求としてプッシュ問い合わせを受け付けると（ステップＳ５０１）、端末１００がロングポーリングを選択したと判断する。このとき、プッシュサーバ２００は、即座に応答せずに、配信すべきプッシュメッセージの発生を待つ。つまり、プッシュサーバ２００はプッシュ待ちの状態となる。
　プッシュサーバ２００は、アプリケーションサーバ３００からプッシュメッセージの配信要求を受け付けると（ステップＳ５０２）、ＨＴＴＰ要求が正常に処理されたことを示すＨＴＴＰ応答（ＨＴＴＰ　２００ＯＫ）とともに、プッシュメッセージをプッシュクライアント１１０に送信する（ステップＳ５０３）。
　プッシュクライアント１１０のメッセージ通知部１１５は、ステップＳ５０３で受信したメッセージを対応するアプリケーションに渡す（ステップＳ５０４）。
　次に、端末１００がダイレクトＩＰによりプッシュメッセージを取得する動作を説明する。
　図６は、ダイレクトＩＰによるプッシュメッセージの配信処理を示すシーケンス図である。
　図６に示すシーケンス図においては、端末１００が端末状態通知をした後のメッセージ配信システムの動作を示す。
　プッシュサーバ２００は、端末１００から端末状態通知を受けると、すなわち端末１００から端末状態情報を受信すると、端末１００がダイレクトＩＰを選択したと判断する。その後、アプリケーションサーバ３００からプッシュメッセージの配信要求を受け付けると（ステップＳ６０１）、プッシュサーバ２００は、プッシュクライアント１１０に対してＴＣＰ接続を行う（ステップＳ６０２）。ダイレクトＩＰでは、このＴＣＰ接続がメッセージ更新通知となる。すなわち、メッセージ更新通知受信部１１３は、ＴＣＰ接続を検知することにより、メッセージ更新通知があったと判断する。
　プッシュクライアント１１０のメッセージ更新通知受信部１１３がプッシュサーバ２００とのＴＣＰ接続を検知すると、メッセージ受信部１１４は、これをトリガとしてメッセージ取得処理を開始する。つまり、プッシュサーバ２００に対してＨＴＴＰ要求としてメッセージ取得要求を送信する（ステップＳ６０３）。
　プッシュサーバ２００は、ＨＴＴＰ要求が正常に処理されたことを示すＨＴＴＰ応答とともに、プッシュメッセージをプッシュクライアント１１０に送信する（ステップＳ６０４）。
　プッシュクライアント１１０のメッセージ通知部１１５は、ステップＳ６０４で受信したメッセージを対応するアプリケーションに渡す（ステップＳ６０５）。
　以上に説明したように、本実施形態では、端末がネットワーク状態に応じてプッシュ方法を決定する。従って、ロングポーリング方式のみを利用した場合に比べプッシュサーバの処理負荷を軽減させるとともに、端末が利用するネットワークの種別によらずに、プッシュメッセージを確実に端末内のプッシュクライアントに到達させることができる。
　また、端末がモバイル網を利用しているときには、ＴＣＰセッションを常時維持させておく必要がないダイレクトＩＰをプッシュ方法として選択するので、モバイル網における制御信号の輻輳の発生を抑止することができる。
　なお、本実施形態では、端末とプッシュサーバとが異なるＩＰアドレス空間に存在する場合には、ＮＡＴやＦＷを介した通信およびプロキシサーバを介した通信が可能なロングポーリングをプッシュ方法として選択しているが、その他の方法を利用してもよい。例えば、プロキシサーバを介した通信ができなくてもよい場合には、ＷｅｂＳｏｃｋｅｔやＴＣＰ独自通信を利用することができる。つまり、第一の通信方式はＷｅｂＳｏｃｋｅｔやＴＣＰ独自通信であってもよい。
　ＷｅｂＳｏｃｋｅｔは、ウェブサーバとブラウザ間のＴＣＰ上における双方向通信用の通信方式である。ＷｅｂＳｏｃｋｅｔでは、ＴＣＰセッションを１回確立させると、その後端末とプッシュサーバ間で双方向通信が可能となる。ただし、ＷｅｂＳｏｃｋｅｔでは、ＷｅｂＳｏｃｋｅｔに対応していないプロキシサーバを介した通信を行うことができない。ＴＣＰ独自通信は、ユーザ等が独自に開発したＴＣＰ上における通信方式である。
実施形態２．
　以下、本発明の第２の実施形態を図面を参照して説明する。
　端末１００の第２の実施形態における構成は、第１の実施形態における構成と同様であるため、説明を省略する。
　第１の実施形態では、ロングポーリングおよびダイレクトＩＰによってプッシュメッセージを端末に配信するメッセージ配信システムを例にした。
　しかし、ロングポーリングおよびダイレクトＩＰによってもプッシュメッセージを端末に到達させることができない場合がある。例えば、端末が長時間無通信（スリープ）状態になっていて、端末のＩＰアドレスが開放されている場合である。
　本実施形態では、ロングポーリングおよびダイレクトＩＰによってもプッシュメッセージを端末に到達させることができない場合、プッシュサーバ２００は、ＳＭＳ（Ｓｈｏｒｔ　Ｍｅｓｓａｇｅ　Ｓｅｒｖｉｃｅ）を利用してプッシュメッセージを配信する。
　図７は、ＳＭＳによるプッシュメッセージの配信処理を示すシーケンス図である。
　プッシュサーバ２００は、アプリケーションサーバ３００からプッシュメッセージの配信要求を受け付けたときに（ステップＳ７０１）、配信先の端末が選択したプッシュ方法でプッシュメッセージの配信が可能か否かを判定する。本実施形態では、プッシュサーバ２００は、プッシュメッセージの配信試行を実行し、配信試行の結果をもとに配信可能か否かを判定する（ステップＳ７０２）。
　プッシュサーバ２００は、配信先の端末がプッシュ方法としてダイレクトＩＰを選択している場合は、ダイレクトＩＰによるプッシュメッセージの配信を試行する。また、プッシュサーバ２００は、配信先の端末がプッシュ方法としてロングポーリングを選択している場合は、ロングポーリングによるプッシュメッセージの配信を試行する。
　このとき、端末１００が、長時間スリープ状態になっていて、端末１００のＩＰアドレスが開放されてしまっている場合がある。その場合、プッシュメッセージが端末１００に配信されない。
　プッシュメッセージの配信試行に失敗した場合には、プッシュサーバ２００は、配信先の端末が選択したプッシュ方法ではプッシュメッセージの配信ができないと判断する。そして、プッシュサーバ２００は、プッシュクライアント１１０に対して、配信すべきプッシュメッセージがあることを示す通知をＳＭＳで送信する（ステップＳ７０３）。このとき、端末１００のＩＰアドレスが開放されていたとしても、ＳＭＳによる通知は端末１００に到達する。本実施形態では、ＳＭＳによる通知がメッセージ更新通知となる。すなわち、メッセージ更新通知受信部１１３は、ＳＭＳによる通知を受けると、メッセージ更新通知があったと判断する。
　プッシュクライアント１１０のメッセージ更新通知受信部１１３がＳＭＳによる通知を受けると、メッセージ受信部１１４は、これをトリガとしてメッセージ取得処理を開始する。このとき、端末１００のＩＰアドレスは開放されているが、端末１００がプッシュサーバ２００と通信しようとしたタイミングで、端末１００にＩＰアドレスが割り当てられる。例えば、モバイル網上に設置されたＤＨＣＰ（Ｄｙｎａｍｉｃ　Ｈｏｓｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）サーバが、端末１００にＩＰアドレスを割り当てる。これにより、端末１００に対するプッシュメッセージの配信が可能となる。
　端末１００にＩＰアドレスが割り当てられた後、メッセージ受信部１１４は、プッシュサーバ２００に対してＨＴＴＰ要求としてメッセージ取得要求を送信する（ステップＳ７０４）。
　プッシュサーバ２００は、ＨＴＴＰ要求が正常に処理されたことを示すＨＴＴＰ応答とともに、プッシュメッセージをプッシュクライアント１１０に送信する（ステップＳ７０５）。
　プッシュクライアント１１０のメッセージ通知部１１５は、ステップＳ７０５で受信したメッセージを配信先のアプリケーションに渡す（ステップＳ７０６）。
　以上に説明したように、本実施形態では、端末が、プッシュサーバから配信すべきプッシュメッセージがあることを示すＳＭＳによる通知を受けると、メッセージ取得要求をプッシュサーバに送信する。従って、プッシュサーバがロングポーリングおよびダイレクトＩＰによってもプッシュメッセージを端末に到達させることができない場合であっても、プッシュサーバがＳＭＳによる通知を端末に送信すれば、端末は当該通知をもとにプッシュメッセージを取得することができる。よって、例えば、端末のＩＰアドレスが開放されている場合であっても、確実に端末にプッシュメッセージを配信することができる。
　なお、本実施形態では、ＳＭＳによる通知をトリガとする場合を例にしたが、配信すべきプッシュメッセージがあることをＩＰアドレスが開放されている端末に通知可能であれば、ＳＭＳ以外の方法を利用してもよい。
実施形態３．
　以下、本発明の第３の実施形態を図面を参照して説明する。
　端末１００の第３の実施形態における構成は、第１の実施形態および第２の実施形態における構成と同様であるため、説明を省略する。
　ただし、本実施形態では、端末状態通知送信部１１１は、端末のＩＰアドレスが前回端末状態通知をしたときのＩＰアドレスと同一の場合には、端末状態通知を行わない。
　図８は、端末１００がプッシュ方法としてダイレクトＩＰを選択した場合の第３の実施形態の動作を示すシーケンス図である。
　ステップＳ８０１～Ｓ８０３の処理は、第１の実施形態のステップＳ４０１～Ｓ４０３の処理と同様であるため、説明を省略する。
　ステップＳ８０３の後、端末状態通知送信部１１１は、端末に現在割り当てられているＩＰアドレスが、前回端末状態通知をしたときのＩＰアドレスと同一であるか否かを確認する（ステップＳ８０４）。
　ＩＰアドレスが同一である場合は、端末状態通知送信部１１１は、端末状態通知を行わない（ステップＳ８０５）。なお、ＩＰアドレスが同一でない場合には、端末状態通知送信部１１１は、ステップＳ４０４の処理と同様に端末状態通知を行う。
　以上に説明したように、本実施形態では、端末がプッシュ方法としてダイレクトＩＰを選択した場合に、端末のＩＰアドレスが前回端末状態通知をしたときと同一であるときには、端末は端末状態通知を行わない。これにより、端末およびプッシュサーバの処理負荷をさらに軽減することができる。特に、端末のネットワーク状態が頻繁に切り替わるような環境において、端末およびプッシュサーバの処理負荷を軽減することができる。
　例えば、モバイル網とＷｉＦｉとの切り替えが頻繁に行われる環境では、ネットワークがＷｉＦｉからモバイル網に切り替わる度に、端末から端末状態情報がプッシュサーバに送信される。従って、端末およびプッシュサーバの処理負荷が増大する可能性がある。しかし、本実施形態によれば、そのような環境でも端末およびプッシュサーバの処理負荷を軽減することができる。
　図９は、本発明による端末の最小構成を示すブロック図である。図１０は、本発明によるメッセージ配信システムの最小構成を示すブロック図である。
　図９に示すように、端末（図１に示す端末１００－１～１００－ｎおよび図２に示す端末１００に相当。）は、自端末と、メッセージの配信をプッシュ型で行う配信装置（図１に示すプッシュサーバ２００に相当。）とを接続するネットワークの状態を検知するネットワーク状態検知部１１（図２に示す端末１００のプッシュクライアント１１０におけるＮＷ状態検知部１１２に相当。）と、検知結果をもとに、自端末と配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置からメッセージを受信する受信部１２（図２に示す端末１００のプッシュクライアント１１０における端末状態通知送信部１１１、メッセージ更新通知受信部１１３およびメッセージ受信部１１４に相当。）とを備える。
　そのような構成によれば、配信装置の処理負荷を削減しつつ、端末が利用するネットワークの種別によらずに、プッシュメッセージを確実に端末に到達させることができる。
　上記の実施形態には、以下のような端末も開示されている。
（１）受信部１２は、自端末と配信装置とを接続するネットワークが無線ＬＡＮである場合は、自端末と配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、ネットワークがモバイル網である場合は、自端末と配信装置とが同一ＩＰアドレス空間に配置されていると判断する端末。
　そのような構成によれば、ネットワークの種別をもとに、端末と配信装置とが同一ＩＰアドレス空間内にいるか否かを判定することができる。
（２）受信部１２は、第一の通信方式を選択した場合は、配信装置に配信すべきメッセージの有無を問い合わせる問い合わせ要求を送信し、第二の通信方式を選択した場合は、配信装置とのＴＣＰ接続を検知したときに当該配信装置にメッセージ取得要求を送信する端末。
　そのような構成によれば、選択したプッシュ方法に応じて、配信装置からプッシュメッセージを取得することができる。
（３）受信部１２は、第二の通信方式を選択したときに自端末のＩＰアドレスを含む端末状態情報を配信装置に通知する端末。
　そのような構成によれば、配信装置が端末状態通知をもとに端末のＩＰアドレスなどを認識することができ、配信装置から端末に対してＴＣＰ接続を行うことが可能となる。また、端末状態情報を通知することにより、端末がプッシュ方法としてダイレクトＩＰを選択したことを配信装置が認識することができる。
（４）受信部１２は、配信すべきメッセージがあることを示すＳＭＳによる通知を検知したときに配信装置にメッセージ取得要求を送信する端末。
　そのような構成によれば、例えば、端末のＩＰアドレスが開放されている場合であっても、端末は、ＳＭＳによる通知により配信すべきプッシュメッセージがあることを認識することができる。従って、そのような場合でも、端末は確実にプッシュメッセージを取得することができる。
（５）受信部１２は、前回の端末状態情報を通知したときの自端末のＩＰアドレスと現在の自端末のＩＰアドレスとが同一の場合には、端末状態情報を配信装置に通知しない端末。
　そのような構成によれば、例えば、モバイル網とＷｉＦｉとの切り替えが頻繁に行われる環境において、ネットワークがモバイル網に切り替わる際の端末状態情報の送信を抑止することができる。従って、端末およびプッシュサーバの処理負荷をさらに軽減することができる。
　上記の実施形態には、図１０に示すようなメッセージ配信システムも開示されている。
（６）端末１０－１～１０－ｎ（図１に示す端末１００－１～１００－ｎに相当。）と、端末１０－１～１０－ｎにメッセージの配信をプッシュ型で行う配信装置２０（図１に示すプッシュサーバ２００に相当。）とを備え、端末１０－１～１０－ｎは、自端末と配信装置２０とを接続するネットワークの状態を検知するネットワーク状態検知部１１と、検知結果をもとに、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置２０が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置２０からメッセージを受信する受信部１２とを備え、配信装置２０は、端末から通知された通信方式の選択結果に応じたメッセージ配信を行う制御部２１（図１に示すプッシュサーバ２００における制御部（図示せず）に相当。）を備えるメッセージ配信システム。
　そのような構成によれば、端末が利用するネットワークの種別によらずに、配信装置の処理負荷を増大させることなく、プッシュメッセージを確実に端末に到達させることができる。
（７）受信部１２は、自端末と配信装置２０とを接続するネットワークが無線ＬＡＮである場合は、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されていないと判断し、ネットワークがモバイル網である場合は、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されていると判断するメッセージ配信システム。
　そのような構成によれば、ネットワークの種別をもとに、端末と配信装置とが同一ＩＰアドレス空間内にいるか否かを判定することができる。
　また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下
に限られない。
（付記１）端末１０－１～１０－ｎと、端末１０－１～１０－ｎにメッセージの配信をプッシュ型で行う配信装置２０とを備え、端末１０－１～１０－ｎは、自端末と配信装置２０とを接続するネットワークの状態を検知するネットワーク状態検知部１１と、検知結果をもとに、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に配信装置２０が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて配信装置２０からメッセージを受信する受信部１２とを備え、配信装置２０は、端末から通知された通信方式の選択結果に応じたメッセージ配信を行う制御部２１を備えるメッセージ配信システム。
（付記２）受信部１２は、自端末と配信装置２０とを接続するネットワークが無線ＬＡＮである場合は、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されていないと判断し、ネットワークがモバイル網である場合は、自端末と配信装置２０とが同一ＩＰアドレス空間に配置されていると判断する付記１に記載のメッセージ配信システム。
（付記３）受信部１２は、第一の通信方式を選択した場合は、配信装置２０に配信すべきメッセージの有無を問い合わせる問い合わせ要求を送信し、第二の通信方式を選択した場合は、配信装置２０とのＴＣＰ接続を検知したときに当該配信装置２０にメッセージ取得要求を送信する付記１または付記２に記載のメッセージ配信システム。
　そのような構成によれば、端末が選択したプッシュ方法に応じて、配信装置から端末へプッシュメッセージの配信を行うことができる。
（付記４）受信部１２は、第二の通信方式を選択したときに自端末のＩＰアドレスを含む端末状態情報を配信装置２０に通知し、制御部２１は、メッセージ配信時に端末状態情報をもとに端末１０－１～１０－ｎとのＴＣＰセッションを確立する付記１から付記３のうちのいずれか１つに記載のメッセージ配信システム。
　そのような構成によれば、配信装置が端末状態通知をもとに端末のＩＰアドレスなどを認識することができ、配信装置から端末に対してＴＣＰ接続を行うことが可能となる。また、端末状態情報を通知することにより、端末がプッシュ方法としてダイレクトＩＰを選択したことを配信装置が認識することができる。
（付記５）制御部２１は、第一の通信方式または第二の通信方式によるメッセージ配信ができないと判断した場合には、配信すべきメッセージがあることを示すＳＭＳによる通知を端末１０－１～１０－ｎに送信し、受信部１２は、ＳＭＳによる通知を検知したときに配信装置２０にメッセージ取得要求を送信する付記１から付記４のうちのいずれか１つに記載のメッセージ配信システム。
　そのような構成によれば、例えば、端末のＩＰアドレスが開放されている場合であっても、ＳＭＳによる通知により、配信装置は端末に配信すべきプッシュメッセージがあることを認識させることができ、確実に端末に対してプッシュメッセージを配信することができる。
（付記６）受信部１２は、前回の端末状態情報を通知したときの自端末のＩＰアドレスと現在の自端末のＩＰアドレスとが同一の場合には、端末状態情報を配信装置２０に通知しない付記４または付記５に記載のメッセージ配信システム。
　そのような構成によれば、例えば、モバイル網とＷｉＦｉとの切り替えが頻繁に行われる環境において、ネットワークがモバイル網に切り替わる際の端末状態情報の送信を抑止することができる。従って、端末およびプッシュサーバの処理負荷をさらに軽減することができる。
　この出願は、２０１２年１０月１７日に出願された日本特許出願２０１２－２３０００１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　以上、実施形態を参照して本願発明を説明したが、本願発明は上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
　１０－１～１０－ｎ、１００、１００－１～１００－ｎ、５００－１、５００－２　端末
　１１、１１２　ネットワーク（ＮＷ）状態検知部
　１２　受信部
　２０　配信装置
　２１　制御部
　１１０、５１０－１、５１０－２　プッシュクライアント
　１１１　端末状態通知送信部
　１１３　メッセージ更新通知受信部
　１１４　メッセージ受信部
　１１５　メッセージ通知部
　１２０－１～１２０－ｎ　アプリケーション
　２００、６００　プッシュサーバ
　３００、３００－１～３００－ｎ、７００－１～７００－３　アプリケーションサーバ

Claims (12)

  1. 　自端末と、メッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部と、
    　前記検知結果をもとに、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に前記配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて前記配信装置からメッセージを受信する受信部とを備えた
    　ことを特徴とする端末。
  2. 　受信部は、自端末と配信装置とを接続するネットワークが無線ＬＡＮである場合は、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、前記ネットワークがモバイル網である場合は、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていると判断する
    　請求項１に記載の端末。
  3. 　受信部は、第一の通信方式を選択した場合は、配信装置に配信すべきメッセージの有無を問い合わせる問い合わせ要求を送信し、第二の通信方式を選択した場合は、配信装置とのＴＣＰ接続を検知したときに当該配信装置にメッセージ取得要求を送信する
    　請求項１または請求項２に記載の端末。
  4. 　受信部は、第二の通信方式を選択したときに自端末のＩＰアドレスを含む端末状態情報を配信装置に通知する
    　請求項１から請求項３のうちのいずれか１項に記載の端末。
  5. 　受信部は、配信すべきメッセージがあることを示すＳＭＳによる通知を検知したときに配信装置にメッセージ取得要求を送信する
    　請求項１から請求項４のうちのいずれか１項に記載の端末。
  6. 　受信部は、前回の端末状態情報を通知したときの自端末のＩＰアドレスと現在の自端末のＩＰアドレスとが同一の場合には、端末状態情報を配信装置に通知しない
    　請求項４または請求項５に記載の端末。
  7. 　端末と、前記端末にメッセージの配信をプッシュ型で行う配信装置とを備え、
    　前記端末は、
    　自端末と前記配信装置とを接続するネットワークの状態を検知するネットワーク状態検知部と、
    　前記検知結果をもとに、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に前記配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、選択した通信方式に応じて前記配信装置からメッセージを受信する受信部とを備え、
    　前記配信装置は、前記端末から通知された通信方式の選択結果に応じたメッセージ配信を行う制御部を備えた
    　ことを特徴とするメッセージ配信システム。
  8. 　受信部は、自端末と配信装置とを接続するネットワークが無線ＬＡＮである場合は、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、前記ネットワークがモバイル網である場合は、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていると判断する
    　請求項７に記載のメッセージ配信システム。
  9. 　端末が、自端末とメッセージの配信をプッシュ型で行う配信装置とを接続するネットワークの状態を検知し、前記検知結果をもとに、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に前記配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択し、
    　前記配信装置が、前記端末から通知された通信方式の選択結果に応じたメッセージ配信を行う
    　ことを特徴とするメッセージ配信方法。
  10. 　端末が、自端末と配信装置とを接続するネットワークが無線ＬＡＮである場合は、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、前記ネットワークがモバイル網である場合は、自端末と前記配信装置とが同一ＩＰアドレス空間に配置されていると判断する
    　請求項９に記載のメッセージ配信方法。
  11. 　メッセージの配信をプッシュ型で行う配信装置と通信可能な端末に搭載されるコンピュータに、
    　前記端末と前記配信装置とを接続するネットワークの状態を検知する処理と、
    　前記検知結果をもとに、前記端末と前記配信装置とが同一ＩＰアドレス空間に配置されているか否かを判定し、同一ＩＰアドレス空間に配置されていない場合は、予め確立されたＴＣＰセッションを利用する第一の通信方式を選択し、同一ＩＰアドレス空間に配置されている場合は、メッセージ配信時に前記配信装置が自端末との間に新規に確立するＴＣＰセッションを利用する第二の通信方式を選択する処理と、
    　選択した通信方式に応じて前記配信装置からメッセージを受信する処理とを実行させる
    　ためのメッセージ受信プログラム。
  12. 　コンピュータに、
    　端末と配信装置とを接続するネットワークが無線ＬＡＮである場合は、前記端末と前記配信装置とが同一ＩＰアドレス空間に配置されていないと判断し、前記ネットワークがモバイル網である場合は、前記端末と前記配信装置とが同一ＩＰアドレス空間に配置されていると判断する処理を実行させる
    　請求項１１に記載のメッセージ受信プログラム。
PCT/JP2013/005876 2012-10-17 2013-10-02 端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム WO2014061220A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP13846473.0A EP2911343B1 (en) 2012-10-17 2013-10-02 Terminal, message distribution system, message distribution method, and message reception program
JP2014541923A JP6241418B2 (ja) 2012-10-17 2013-10-02 端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム
US14/432,725 US9866644B2 (en) 2012-10-17 2013-10-02 Terminal, message distribution system, message distribution method, and computer-readable medium
CN201380054088.9A CN104737499B (zh) 2012-10-17 2013-10-02 终端、消息分发系统、消息分发方法、计算机可读介质

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012230001 2012-10-17
JP2012-230001 2012-10-17

Publications (1)

Publication Number Publication Date
WO2014061220A1 true WO2014061220A1 (ja) 2014-04-24

Family

ID=50487800

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/005876 WO2014061220A1 (ja) 2012-10-17 2013-10-02 端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム

Country Status (5)

Country Link
US (1) US9866644B2 (ja)
EP (1) EP2911343B1 (ja)
JP (1) JP6241418B2 (ja)
CN (1) CN104737499B (ja)
WO (1) WO2014061220A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106658480A (zh) * 2016-12-30 2017-05-10 上海顶竹通讯技术有限公司 一种终端互通的方法及系统
CN110290228B (zh) * 2019-06-03 2022-03-11 网宿科技股份有限公司 一种互联网协议ip地址分配方法及装置
CN114244731B (zh) * 2021-12-16 2024-02-27 湖南师范大学 终端屏幕亮屏检测方法及装置、服务器、电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003032750A (ja) * 2001-07-17 2003-01-31 Nec Corp 移動体端末への情報配信システムおよび情報配信方法
JP2005519568A (ja) * 2002-03-04 2005-06-30 クゥアルコム・インコーポレイテッド インターネットプロトコル伝送を処理するための方法および装置
JP2008085470A (ja) * 2006-09-26 2008-04-10 Fujitsu Ltd Ｉｐアプリケーションサービス提供システム
JP2011123801A (ja) 2009-12-14 2011-06-23 Nec Corp プッシュ型サービス実現方法、システム、装置、及びプログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20050067A (fi) 2005-01-20 2006-07-21 Pekka Rehtijaervi Push-viestinnällä ohjattuja menetelmiä ja laitteita
US7617525B1 (en) * 2005-06-21 2009-11-10 Alto Ventures, Inc. System and method for connectionless client-server communications
CN101466092A (zh) * 2007-12-18 2009-06-24 北京华星广视数码技术服务有限公司 一种在移动通信网络中实现推送的方法
KR101637601B1 (ko) * 2010-10-15 2016-07-07 삼성전자주식회사 모바일 메시지 수신 장치 및 방법
JP5248572B2 (ja) 2010-10-22 2013-07-31 株式会社オプティム 通話のためのネットワークを選択するプログラム、携帯端末及び方法
KR101345415B1 (ko) * 2011-01-31 2014-01-29 주식회사 케이티 푸쉬 메시지 전송 방법, 상기 푸쉬 메시지를 수신하는 이동 단말 및 푸쉬 메시지 전송 시스템
CN102388632B (zh) 2011-08-26 2016-11-02 华为技术有限公司 应用信息推送方法、系统和网元
KR101287556B1 (ko) * 2011-09-29 2013-07-23 주식회사 엘지씨엔에스 이동 단말기의 푸시 클라이언트 및 이를 이용한 프로바이더 변경방법
CN102420827B (zh) * 2011-12-13 2014-04-23 南京大学 面向智能移动平台的Web服务推送方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003032750A (ja) * 2001-07-17 2003-01-31 Nec Corp 移動体端末への情報配信システムおよび情報配信方法
JP2005519568A (ja) * 2002-03-04 2005-06-30 クゥアルコム・インコーポレイテッド インターネットプロトコル伝送を処理するための方法および装置
JP2008085470A (ja) * 2006-09-26 2008-04-10 Fujitsu Ltd Ｉｐアプリケーションサービス提供システム
JP2011123801A (ja) 2009-12-14 2011-06-23 Nec Corp プッシュ型サービス実現方法、システム、装置、及びプログラム

Also Published As

Publication number Publication date
US20150256637A1 (en) 2015-09-10
CN104737499B (zh) 2018-05-04
US9866644B2 (en) 2018-01-09
JPWO2014061220A1 (ja) 2016-09-05
EP2911343B1 (en) 2019-04-10
EP2911343A1 (en) 2015-08-26
JP6241418B2 (ja) 2017-12-06
CN104737499A (zh) 2015-06-24
EP2911343A4 (en) 2016-06-29

Similar Documents

Publication Publication Date Title
CN107645529B (zh) 心跳包发送方法及装置
US20130182625A1 (en) Mechanism for connecting a mobile device to a network
US8175091B2 (en) Communication system
CN110838991A (zh) 网关连接方法、装置、存储介质、电子设备及网关设备
US10666769B2 (en) Network system and method for establishing data link by using relay node
US9521059B2 (en) Delivery device, communication system, load balancing method, and load balancing program
TW201006272A (en) Method and apparatus for maintaining communications connections over a distributed wireless network
JP4567745B2 (ja) 通信システムにおける通信の切り替え方法
JP4950589B2 (ja) 接続管理システム、接続管理方法、および管理サーバ
JP6241418B2 (ja) 端末、メッセージ配信システム、メッセージ配信方法およびメッセージ受信プログラム
US10432744B2 (en) Information processing apparatus, information processing system, and information processing method
JPWO2014061314A1 (ja) コンテンツ配信方法
US10044590B2 (en) Method of effective retaining of NAT channel service
JP5880701B2 (ja) 通信システム、通信制御方法、通信中継システム、及び、通信中継制御方法
JP2014146876A (ja) メッセージ配信システムおよびメッセージ配信方法
JP3682439B2 (ja) データ通信システム及び方法、サーバ装置、クライアント装置、並びにプログラム
US10111081B2 (en) Local communication wireless network system and method thereof
JP2013165372A (ja) パケット経路制御装置
EP3295641A1 (en) Aggregating targeted and exploration queries
JP6260324B2 (ja) ネットワークシステムおよびネットワーク管理方法
JP5158149B2 (ja) 負荷分散装置、負荷分散プログラム及び負荷分散システム

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: 13846473

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014541923

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2013846473

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14432725

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE