Patent Application
20110167476
The present invention relates to message delivery technologies and, more particularly, to a message delivery system in which a message is delivered to a user subscribing to a plurality of carriers, as well as to a delivery method and a program for delivery.
Conventionally, a service provider builds up a service by utilizing the functions of a carrier and provides the service such as, for example, sending a message to a user by utilizing a mail address of the user provided by the carrier as a user ID for the user to use the service. On the other hand, an increased number of users subscribe to a plurality of carriers and have a plurality of mail addresses, as in a case where a user uses a carrier employing a fixed network when the user is at home and uses a carrier employing a mobile network while the user is on the move.
Under such a situation, when a service provider delivers a message to a user subscribing to a carrier, the service provider requests the carrier to deliver the message, and the requested carrier delivers the message to the designated user.
Moreover, when a user receives services from a plurality of service providers, the problem arises that it is bothersome to perform user authentication for each individual service if the user is managed with different user IDs for the individual services. To solve such a problem, for example, single sign-on technology is used that utilizes ID federation information in which user IDs for individual services are federated with each other (see NPL 1, for example).
For technologies related to such ID federation, for example, described in PTL 1 is a technology in which user IDs registered with a plurality of sites are linked with each other, information regarding the user is collected, and the collected result is delivered.
Moreover, for example, described in PTL 2 is a technology in which information about users for a variety of service providers is collected, a user conforming to a condition is extracted based on the collected information, and a message is delivered to the user.
However, the above-described message delivery method has the problem that if a user subscribes to a plurality of carriers, the user may receive the same message from each of the carriers.
The technology described in PTL 1 is a technology for generating ID federation information, not going as far as to consider utilizing it for allocation of a message delivery request. Moreover, the technology described in PTL 2 aims to make it possible to deliver information that is more preferable to each individual user by collecting users' attributes and characteristics from a plurality of service providers, not making it possible to efficiently deliver a message to a user subscribing to a plurality of carriers.
The present invention is made in the light of the foregoing, and an object thereof is to provide a message delivery system, a delivery method, an ID management device, and a program for delivery that enable efficient message delivery to a user subscribing to a plurality of carriers.
A message delivery system according to the present invention is a message delivery system for delivering a message to a user, characterized by: a plurality of delivery means which are run by a plurality of carriers respectively and deliver information to subscribers to the respective carriers; and an ID management means which can communicate with the plurality of delivery means, wherein when a delivery means receives a request to deliver a message, the delivery means transmits to the ID management means a request for user identifier resolution to deliver the message, upon receiving the request for user identifier resolution from the delivery means, the ID management means resolves a user identifier to which a carrier running the delivery means can deliver and to which a delivery of the message has not been allocated, and returns the user identifier as a user identifier candidate to the delivery means, and the delivery means delivers the message to a user identified by the user identifier included in the user identifier candidate.
A message delivery method according to the present invention is a message delivery method in a communication system for delivering a message to a user, wherein the communication system includes: a plurality of delivery means which are run by a plurality of carriers respectively and deliver information to subscribers to the respective carriers; and an ID management means which can communicate with the plurality of delivery means, the method characterized by comprising: by a delivery means, upon receiving a request to deliver a message, transmitting to the ID management means a request for user identifier resolution to deliver the message; by the ID management means, upon receiving the request for user identifier resolution from the delivery means, resolving a user identifier to which a carrier running the delivery means can deliver and to which a delivery of the message has not been allocated, and returning the user identifier as a user identifier candidate to the delivery means; and by the delivery means, delivering the message to a user identified by the user identifier included in the user identifier candidate.
An ID management device according to the present invention is an ID management device which can communicate with a plurality of delivery means run by a plurality of carriers respectively and delivering information to subscribers to the respective carriers in a message delivery system for delivering a message to a user, characterized by comprising: a user identifier resolution means which, upon receiving a request for user identifier resolution from a delivery means, resolves a user identifier to which a carrier running the delivery means can deliver and to which a delivery of the message has not been allocated; and a transmission means which transmits a deliveree candidate list including the resolved user identifier to the delivery means.
A program according to the present invention is a program causing a computer to function as an ID management device which can communicate with a plurality of delivery means run by a plurality of carriers respectively and delivering information to subscribers to the respective carriers in a communication system for delivering a message to a user, the program characterized by causing the computer to execute the functions of: receiving a request for user identifier resolution to deliver the message from a delivery means; and upon receiving the request for user identifier resolution from the delivery means, resolving a user identifier to which a carrier running the delivery means can deliver and to which a delivery of the message has not been allocated and returning the user identifier as a user identifier candidate to the delivery means.
According to the present invention, even when a user subscribes to a plurality of carriers, it is possible to efficiently deliver a message, preventing the user from receiving the same message multiple times.
Next, exemplary embodiments of the present invention will be described in detail individually with reference to the drawings. First, a description will be given of terms used in the exemplary embodiments of the present invention.
Hereinafter, a first exemplary embodiment of the present invention will be described in detail with reference to the drawings.
Referring to
In the present exemplary embodiment, it is assumed that a service provider, carriers A and B, and an ID management provider are present as business entities and users 1, 2, and 3 are present as users, and that the user 1 is on contracts with both of the carriers A and B, the user 2 is on a contract with only the carrier A, and the user 3 is on a contract with only the carrier B. Moreover, in the following description, the carrier IDs of the carriers A and B will be abbreviated to “ccID-A” and “ccID-B”, respectively, and an ID management provider user ID will be abbreviated to “userIDidp”, where appropriate.
Further, in the present exemplary embodiment, it is assumed that the carrier user IDs of the user 1 on the carriers A and B are “user1@a.com” and “user1@b.com”, respectively, the carrier user ID of the user 2 on the carrier A is “user2@a.com”, and the carrier user ID of the user 3 on the carrier B is “user3@b.com”.
The ID management system 100 is run by the ID management provider. The service providing system manager terminal 250 and service providing system 200 are run by the service provider. The delivery systems 300A and 300B are delivery systems having the same functionality. The delivery system 300A is run by the carrier A, and the delivery system 300B is run by the carrier B. The user 1 owns the user terminals 401A and 401B. The user 2 owns the user terminal 402A. The user 3 owns the user terminal 403B.
Each of these systems (100, 200, 300A, and 300B) and user terminals (401A, 401B, 402A, and 403B) are operated by controlling, through programs, a computer (any one of a central processing unit, processor, and data processing unit) mounted on each of them. Next, a description will be given of the functions of each system and terminal.
The ID management system 100 includes a delivery request ID supply section 101, a delivery request ID information storage section 102, a deliveree user ID resolution section 103, an allocated-user information storage section 104, and an ID federation information storage section 105.
The delivery request ID supply section 101 has a function of referring to the delivery request ID information storage section 102, generating a delivery request ID that can uniquely identifying a delivery request, and storing the delivery request ID in the delivery request ID information storage section 102. The delivery request ID supply section 101 also has a function of returning the generated delivery request ID to a delivery request ID acquisition section 202.
The deliveree user ID resolution section 103 has a function of receiving a delivery request ID and a carrier ID. Moreover, the deliveree user ID resolution section 103 has a function of referring to the ID federation information storage section 105 and acquiring information on a user to whom the carrier identified by the carrier ID can deliver. Further, the deliveree user ID resolution section 103 has a function of referring to the allocated-user information storage section 104 and acquiring information on a user to whom a delivery is already allocated with respect to the delivery request identified by the delivery request ID. Furthermore, the deliveree user ID resolution section 103 has a function of resolving a user to whom the carrier can deliver and a delivery has not been allocated and returning a list of user IDs of such users to any one of deliveree user ID acquisition sections 302A and 302B.
The allocated-user information storage section 104 has a function of storing information on a user to whom a delivery is already allocated with respect to a delivery request and also storing a generated delivery request ID. Specifically, the allocated-user information storage section 104 has a function of storing a delivery request ID and a delivery-allocated ID management provider user ID, associating them with each other.
The ID federation information storage section 105 has a function of storing an ID management provider user ID, a carrier ID, and a carrier user ID, linking them with each other.
The service providing system 200 includes a message contents reception section 201, the delivery request ID acquisition section 202, and a delivery request section 203. The message contents reception section 201 has a function of receiving message contents from the service providing system manager terminal 250 and transmitting the message contents to the delivery request ID acquisition section 202.
The delivery request ID acquisition section 202 has a function of receiving message contents from the message contents reception section 201. Moreover, the delivery request ID acquisition section 202 has a function of requesting the delivery request ID supply section 101 to issue a delivery request ID, which will be described later, and receiving the delivery request ID from the delivery request ID supply section 101. Further, the delivery request ID acquisition section 202 has a function of transmitting the message contents and delivery request ID to the delivery request section 203.
The delivery request section 203 has a function of receiving message contents and a delivery request ID from the delivery request ID acquisition section 202 and transmitting the message contents and delivery request ID to a delivery reception section 301 of the delivery system 300A.
The delivery systems 300A and 300B have the delivery reception sections 301A and 301B, the deliveree user ID acquisition sections 302A and 302B, delivery sections 303A and 303B, and delivery reference transfer sections 304A and 304B, respectively. Note that the delivery reference transfer section 304B is not required when transfer operation, which will be described later, is not performed.
The delivery reception sections 301A and 301B each have a function of receiving a delivery request ID and message contents and transmitting the delivery request ID and message contents to the deliveree user ID acquisition sections 302A and 302B, respectively. The deliveree user ID acquisition sections 302A and 302B each have a function of receiving a delivery request ID and message contents, transmitting the delivery request ID and its own preset carrier ID to the deliveree user ID resolution section 103 of the ID management system 100, and acquiring a list of carrier user IDs of those users to whom a delivery should be made. The deliveree user ID acquisition sections 302A and 302B also have a function of transmitting the list of carrier user IDs thus acquired, message contents, and delivery request ID to the delivery sections 303A and 303B, respectively.
The delivery sections 303A and 303B each have a function of receiving a list of carrier user IDs, message contents, and a delivery request ID and sending the message contents to the user terminals identified by the carrier user IDs. The delivery sections 303A and 303B also have a function of transmitting the delivery request ID, message contents, and a carrier ID running a delivery system to be a transfer destination to the delivery reference transfer sections 304A and 304B, respectively.
The delivery reference transfer sections 304A and 304B each receive a delivery request ID, message contents, and a transfer-destination carrier ID and transmit the delivery request ID and message contents to the delivery reception section 301B of the delivery system run by the transfer-destination carrier. Note that the delivery reference transfer section 304B does not perform transmission operation in the present exemplary embodiment.
The user terminals 401A and 401B owned by the user 1, the user terminal 402A owned by the user 2, and the user terminal 403B owned by the user 3 each have a function of receiving message contents from any one of the delivery sections 303A and 303B through a network.
Next, operation according to the present exemplary embodiment will be described. To avoid complicating a description of the operation, assumptions are made as follows.
In the present exemplary embodiment, the delivery request ID information storage section 102 keeps “D001” as delivery request ID information as shown in
The ID federation information storage section 105 keeps ID federation information as shown in
The allocated-user information storage section 104 keeps, as allocated-user information, information in which ID management provider user IDs (“user1@idp”, “user2@idp”, and “user3@idp”) are associated with the delivery request ID “D001” as shown in
Next, operation according to the present exemplary embodiment will be described with reference to the operation sequence diagram of
The service providing system manager terminal 250 transmits message contents entered by a system manager in the service provider to the message contents reception section 201 of the service providing system 200 (
The delivery request ID acquisition section 202, upon receiving the message contents as an input, requests the delivery request ID supply section 101 of the ID management system 100 to issue a delivery request ID (
Subsequently, the delivery request ID supply section 101 returns the generated delivery request ID information “D002” to the delivery request ID acquisition section 202 (
Hereinafter, for convenience, a processing step related to the delivery system 300A (carrier A) and a processing step related to the delivery system 300B (carrier B) will be denoted by “Step S1-A-n” and “Step S1-B-n” (n=1, 2, . . . ), respectively, and operation of the ID management system 100 and delivery systems 300A and 300B will be described in detail with reference to
The delivery reception section 301A of the delivery system 300A, upon receiving the delivery request ID information and message contents from the delivery request section 203 (Step S1-A-1), passes the delivery request ID information and message contents to the deliveree user ID acquisition section 302A (Step S1-A-2). The deliveree user ID acquisition section 302A, upon receiving the delivery request ID information and message contents, passes the delivery request ID information and its own preset carrier ID to the deliveree user ID resolution section 103 of the ID management system 100 and requests user ID resolution (
Referring to
However, delivery targets do not necessarily have to be the terminals of all users. For example, if the ID management system 100 manages location information on user terminals and user information such as age and gender, it is also possible to limit delivery targets to those user terminals according to the location information, age, and/or gender. Specifically, it is assumed that the ID management system 100 has “Tamachi” as location information on the user terminal 401A, “Shinagawa” as location information on the user terminal 402A, and “Tamachi” as location information on the user terminal 403A, for example. In this case, if delivery targets are those user terminals whose present location is “Tamachi”, delivery targets are limited to the user terminals 401A and 403B, and the userIDidp list 502 is {“user1@idp”, “user3@idp”}.
Next, the deliveree user ID resolution section 103 performs processing of Steps S1-F2-5, S1-F2-6, and S1-F2-7 on each of “user1@idp”, “user2@idp”, and “user3@idp” in the userIDidp list 502 (
First, the deliveree user ID resolution section 103 refers to the ID federation information storage section 105 and checks whether or not an ID management provider user ID (userIDidp) sequentially selected from the userIDidp list 502 is ID-federated with the carrier ID of the requester of user ID resolution (
To be more specific with reference to
In the processing of Step S1-F2-6, when it is found by referring to the allocated-user information storage section 104 shown in
That is, since it is found upon referring to the allocated-user information storage section 104 shown in
In the processing of Step S1-F2-7 in
Next, the deliveree user ID resolution section 103 registers the ID management provider user IDs included in the deliveree candidate list 503 generated in Step S1-F2-7 with the allocated-user information storage section 104 (
Next, the deliveree user ID resolution section 103 refers to the ID federation information storage section 105, translates each ID management provider user ID included in the deliveree candidate list 503 into a carrier user ID (
The deliveree user ID acquisition section 302A receives the deliveree candidate list 504, {“user1@a.com”, “user2@a.com”}, from the deliveree user ID resolution section 103 and passes this list of user IDs, the message contents, and delivery request ID to the delivery section 303A (Step S1-A-10).
The delivery section 303A, upon receiving the deliveree candidate list 504, message contents, and delivery request ID from the deliveree user ID acquisition section 302A, delivers the message contents to the user terminal identified by each user ID included in the deliveree candidate list 504 (
Subsequently, the delivery section 303A passes the delivery request ID and message contents to the delivery reference transfer section 304A (Step S1-A-12), and the delivery reference transfer section 304A transmits the delivery request ID and message contents to the delivery reception section of a carrier preset as a transfer destination. Here, it is assumed that “ccID-B” is designated as a transfer-destination carrier ID. Therefore, the delivery reference transfer section 304A transmits the delivery request ID “D002” and message contents to the delivery reception section 301B of the delivery system 300B (
Subsequently, processing in the delivery system 300B will be described. The delivery reception section 301B of the delivery system 300B, upon receiving the delivery request ID “D002” and message contents from the delivery reference transfer section 304A (Step S1-B-1), transfers them to the deliveree user ID acquisition section 302B (Step S1-B-2). The deliveree user ID acquisition section 302B, upon receiving the delivery request ID “D002” and message contents, passes the delivery request ID “D002” and the carrier ID of its own delivery system to the deliveree user ID resolution section 103 (
Subsequently, the deliveree user ID resolution section 103 performs the operation of Step S1-F2-2 and the subsequent steps in
Next, the deliveree user ID resolution section 103 refers to the allocated-user information storage section 104 updated as shown in
Next, the deliveree user ID resolution section 103 generates a deliveree candidate list {“user3@idp”} of a user to whom the carrier can deliver and a delivery has not been allocated (
The deliveree user ID acquisition section 302B, upon receiving the deliveree candidate list {“user3@b.com”} from the deliveree user ID resolution section 103 (Step S1-B-9), passes the received deliveree candidate list and message contents to the delivery section 303B (Step S1-B-10). The delivery section 3038 delivers the message contents to the user terminal registered in the deliveree candidate list {“user3@b.com”} (
Next, effects of the first exemplary embodiment of the present invention will be described.
A first effect of the present exemplary embodiment is that a user is prevented from receiving the same message multiple times even if the user subscribes to a plurality of carriers (here, in the case where the user 1 subscribes to each of the carriers A and B). The reason is that a user ID of a delivery-allocated user is stored with respect to a delivery request ID so that a delivery will not be made to the delivery-allocated user.
Moreover, a second effect of the present exemplary embodiment is that if a carrier cannot deliver a message to some of users to whom a service provider desires to deliver the message because they do not subscribe to the carrier, the carrier can accomplish delivery of the message by requesting another carrier to deliver the message, in which case information that the carrier does not want the requested another carrier to know is not disclosed. Further, there is also another effect that a transfer-source carrier can freely choose a transfer-destination carrier.
The reason is that the ID management system 100 issues a delivery request ID as an identifier for uniquely identifying a message delivery request from a service provider, a carrier only passes the delivery request ID and a message to a transfer-destination carrier, and the transfer-destination carrier acquires a user ID of a user to whom the transfer-destination carrier can deliver based on the delivery request ID and its own carrier ID, thereby delivering the message.
Note that although carrier user IDs are different from ID management provider user IDs in the ID federation information stored in the ID federation information storage section 105 in the present exemplary embodiment as shown in
Next, a second exemplary embodiment of the present invention will be described in detail with reference to the drawings.
In
Compared with the first exemplary embodiment shown in
The delivery reference transfer list determination sections 305A and 305B each have a function of receiving a delivery request ID from the delivery reference transfer sections 304A and 304B, respectively. Moreover, the delivery reference transfer list determination sections 305A and 305B each have a function of transmitting the received delivery request ID and the carrier ID of the carrier running the delivery system in question to the delivery reference list transmission section 106 and receiving a list including a candidate or candidates for a delivery-destination carrier. Further, the delivery reference transfer list determination sections 305A and 305B each have a function of randomly selecting a carrier ID from the received list of carrier IDs and transmitting the selected carrier ID and message contents to the delivery reference transfer sections 304A and 304B, respectively.
The delivery reference list transmission section 106 has a function of receiving a delivery request ID and a carrier ID from the delivery reference transfer list determination section 305A or 305B. Moreover, the delivery reference list transmission section 106 has a function of referring to the allocated-user information storage section 104, selecting a user who has not been allocated a delivery, further referring to the ID federation information storage section 105, and retrieving a carrier that is ID-federated with the ID management provider user ID of the user who has not been allocated a delivery. Further, the delivery reference list transmission section 106 has a function of returning a list of the carrier IDs of such carriers retrieved to the delivery reference transfer list determination section 305A or 305B.
Next, operation according to the present exemplary embodiment will be described. Referring to
First, the delivery reference transfer section 304A of the delivery system 320A, upon receiving a delivery request ID and message contents from the delivery section 303A, passes the delivery request ID to the delivery reference transfer list determination section 305A (Step S2-A-1). Thereby, the delivery reference transfer list determination section 305A transmits the received delivery request ID and the carrier ID of the carrier running this delivery system to the delivery reference list transmission section 106 (
Next, the delivery reference list transmission section 106, upon receiving the delivery request ID and requester's carrier ID (here, “ccID-A”) from the delivery reference transfer list determination section 305A (
Next, the delivery reference list transmission section 106 sequentially performs processing of Steps S2-F2-5, S2-F2-6, and S2-F2-7 on each of “user1@idp”, “user2@idp”, and “user3@idp” in the userIDidp list 602 (
Specifically, the delivery reference list transmission section 106 refers to the allocated-user information storage section 104 and checks whether or not a userIDidp sequentially selected from the userIDidp list 602 is associated with the delivery request ID (
Here, since a delivery is already allocated to the user terminals 401A and 401B of the user 1 and to the user terminal 402A of the user 2, “user3@idp” is an ID management provider user ID to which a delivery has not been allocated, as shown in
Next, the delivery reference list transmission section 106 refers to the ID federation information storage section 105, acquires a carrier ID that is ID-federated with the ID management provider user ID (userIDidp) that is not associated with the delivery request ID (
Next, the delivery reference list transmission section 106 returns the delivery-capable ccID set 603 to the delivery reference transfer list determination section 305A (
Note that since operation related to the delivery system 320B is basically similar to that of the delivery system 320A as described above, a description thereof will be omitted.
Next, effects of the present exemplary embodiment will be described. In the present exemplary embodiment, the delivery reference list transmission section 106 of the ID management system 120 has a function of generating, as candidates for a transfer-destination carrier, a list of carriers that are ID-federated with an ID management provider user ID that is not associated with a delivery request ID and returning that list of candidates to the ID delivery system 320A or 320B. Therefore, according to the present exemplary embodiment, when the delivery system 320A or 320B transfers a delivery request to another carrier, the delivery system 320A or 320B can choose a transfer-destination carrier by using as reference the acquired list of carrier IDs when selecting a transfer-destination carrier.
Note that although a carrier ID is randomly selected from a list of carrier IDs in the present exemplary embodiment, a carrier at the top of the list may be selected, or a carrier may be selected in descending order, rather than selected at random.
Next, a third exemplary embodiment of the present invention will be described with reference to the drawings. In the above-described second exemplary embodiment, the delivery-capable ccID set 603 including a transfer-destination carrier ID is returned to a delivery system as a delivery reference list. It is possible to add selection criterion information to each carrier ID in this delivery-capable ccID set 603. Hereinafter, in the third exemplary embodiment of the present invention, the number of potential deliverees is added as the selection criterion information.
In a message delivery system according to the third exemplary embodiment shown in
Compared with the second exemplary embodiment shown in
Next, operation according to the present exemplary embodiment will be described. Referring to
A detailed description will be given below with reference to
First, referring to
Subsequently, the number-of-potential-deliverees calculation section 107 refers to the allocated-user information storage section 104 and counts the number of ID management provider user IDs of those users who have not been allocated a delivery with respect to the delivery request ID (
Subsequently, the number-of-potential-deliverees calculation section 107 refers to the ID federation information storage section 105 and, for each of the carrier IDs, increases the number of potential deliverees to whom the carrier ID in question can deliver if the carrier ID can deliver to the users who have not been allocated a delivery (
Here, it is checked whether or not the ID management provider user ID “user3@idp” is ID-federated with the carrier ID “ccID-B”, and it is found that “user3@idp” is ID-federated with “ccID-B”. That is, “ccID-B” can deliver to “user3@idp”. Accordingly, the number of potential deliverees to whom “ccID-B” can deliver is increased by one to obtain, as a result, a number-of-potential-deliverees list (“ccID-B”, 1), including a set of a carrier, which is “ccID-B”, and the number of potential deliverees, which is 1. Thus, the number-of-potential-deliverees list, which includes a carrier ID that can deliver to a user who has not been allocated a delivery and the number of such users to whom the carrier can deliver, is generated.
Lastly, the number-of-potential-deliverees calculation section 107 passes the number-of-potential-deliverees list generated for each carrier to the delivery reference list transmission section 106 (Step S3-A-4). Here, (“ccID-B”, 1) is transmitted.
The delivery reference list transmission section 106 transmits to the delivery reference transfer list determination section 305A the number-of-potential-deliverees lists each indicating a delivery-capable carrier ID and the number of potential deliverees to whom the corresponding carrier can deliver (
The delivery reference transfer list determination section 305A receives the above-described number-of-potential-deliverees lists, each including a set of a delivery-capable carrier ID and the number of potential deliverees, from the delivery reference list transmission section 106 as a list of delivery reference transfer destinations and selects a carrier ID having the largest number of potential deliverees (
Note that although a carrier ID having the largest number of potential deliverees is selected in the present exemplary embodiment, it is also possible to select, conversely, a carrier ID having the smallest number of potential deliverees. Additionally, since operation related to the delivery system 320B is basically similar to that of the delivery system 320A as described above, a description thereof will be omitted.
Next, effects of the present exemplary embodiment will be described. In the present exemplary embodiment, the number-of-potential-deliverees calculation section 107 of the ID management system 130 has a function of returning the number of potential deliverees. Therefore, according to the present exemplary embodiment, when a delivery system selects a transfer-destination carrier, it is possible to select a transfer-destination carrier depending on the number of potential deliverees.
Next, a fourth exemplary embodiment of the present invention will be described with reference to the drawings. In the fourth exemplary embodiment of the present invention, a user sharing ratio is added as selection criterion information to each carrier ID in the delivery-capable ccID set 603.
In a massage delivery system according to the fourth exemplary embodiment shown in
Compared with the second exemplary embodiment shown in
Next, operation according to the present exemplary embodiment will be described. Referring to
First, referring to
The user sharing ratio calculation section 108, upon receiving the transfer-source carrier ID and transfer-destination delivery-capable ccID set (Step S4-A-2), performs following processing on each carrier ID included in the delivery-capable ccID set (Step S4-A-3).
First, the user sharing ratio calculation section 108 acquires an IL) management provider user ID ID-federated with a carrier user ID on the transfer source and also acquires an ID management provider user ID ID-federated with a carrier user ID on the transfer destination. Hereinafter, a set of ID management provider user IDs ID-federated with carrier user IDs on the transfer source will be referred to as “transfer-source carrier user set”, and a set of ID management provider user IDs ID-federated with carrier user IDs on the transfer destination will be referred to as “transfer-destination carrier user set”.
The user sharing ratio calculation section 108 calculates the intersection of the transfer-source carrier user set and transfer-destination carrier user set (see
The user sharing ratio calculation section 108 transmits a user sharing ratio list with respect to each carrier to the delivery reference list transmission section 106 (Step S4-A-4), and the delivery reference list transmission section 106 transmits the lists to the delivery reference transfer list determination section 305A (
Next, effects of the present exemplary embodiment will be described. In the present exemplary embodiment, the user sharing ratio calculation section 108 of the ID management system 140 has a function of returning the user sharing ratio. For example, considering a case of sending an advertisement message, it is assumed as shown in
Here, if the carriers B and C are transfer-destination-candidate carriers, it can be determined that the carrier having the lower user sharing ratio has the potential for more new customers because more of the subscribers to this carrier are different from the subscribers to the transfer-source carrier. Therefore, the delivery reference transfer list determination section 305A selects the carrier C having the lower user sharing ratio as a transfer-destination carrier.
Next, a fifth exemplary embodiment of the present invention will be described with reference to the drawings. In the fifth exemplary embodiment of the present invention, the number of users with effective authentication is added as selection criterion information to each carrier ID in the delivery-capable ccID set 603.
In a message delivery system according to the fifth exemplary embodiment shown in
Compared with the third exemplary embodiment shown in
The authentication history information storage section 110 has a function of storing information that the authentication execution section 111 performed authentication. For example, the authentication history information storage section 110 stores the ID management provider user ID of an authenticated user and the date and time of authentication, associating them with each other, as shown in
The authentication execution section 111 has a function of receiving a request for authentication from any of the user terminals 401A, 401B, 402A, and 403B, performing authentication on their respective carrier user IDs, and storing the result of authentication in the authentication history information storage section 110. Moreover, the authentication execution section 111 has a function of receiving a request for authentication confirmation from any of the respective user authentication sections 307A and 307B of the delivery systems 330A and 330B and determining whether or not a user identified by a carrier user ID contained in the request for authentication confirmation is an authenticated user. More specifically, based on a carrier user ID contained in a request for authentication confirmation, the authentication execution section 111 refers to the ID federation information in the ID federation information storage section 105, translates the carrier user ID into an ID management provider user ID, and refers to the authentication history information storage section 110 to check whether or not the ID management provider user ID is authenticated, thus determining whether or not the user in question is an authenticated user.
Note that in the present exemplary embodiment, the authentication execution section 111, upon accepting a request for authentication from any of the user terminals 401A, 401B, 402A, and 403B, receives an ID management provider user ID and a password entered by a user from any of the user terminals 401A, 401B, 402A, and 403B, checks whether or not the password entered matches a password preset for the ID management provider user ID, and, when they match, determines that the user is authenticated.
The service providing sections 306A and 306B each have a function of providing a service to any of the user terminals 401A, 401B, 402A, and 403B. Moreover, the service providing sections 306A and 306B each have a function of, before providing a service, to authenticate a user requesting access, transmitting a carrier user ID to the user authentication sections 307A and 307B, respectively, and requesting to authenticate the user. In the present exemplary embodiment, it is assumed that the service providing sections 306A and 306B provide a service of providing news information to user terminals.
The user authentication sections 307A and 307B each have a function of receiving a carrier user ID from the service providing sections 306A and 306B, respectively, transmitting the carrier user ID to the authentication execution section 111 of the ID management system 150, and checking whether or not the user in question is authenticated.
Next, operation according to the present exemplary embodiment will be described.
First, authentication registration processing as shown in
For example, it is assumed that the user 3 transmits his/her ID management provider user ID (user3@idp) and a password to the authentication execution section 111 by using the user terminal 403B (Step S5-S-1). The authentication execution section 111, upon receiving the above-mentioned ID management provider user ID (user3@idp) and password transmitted from the user terminal 403B, checks whether or not the password matches a registered password that is preset for the ID management provider user ID in question. If the received password matches the registered password, the authentication execution section 111 determines that authentication has succeeded and stores the received ID management provider user ID and the date and time of authentication in the authentication history information storage section 110, associating them with each other (Step S5-S-2). Here, information that “user3@dip” is authenticated at “2006/06/10 9:03” is assumed to be stored in the authentication history information storage section 110.
By storing authentication history as described above, it is possible for the user 3 to request by using the user terminal 403B to obtain, for example, news information from the service providing section 306B of the communication system 330B run by the carrier B. Specifically, the user terminal 403B transmits a request for information, containing a carrier user ID, to the service providing section 306B (Step S5-S-3). Here, it is assumed that the carrier user ID (user3@b.com) of the user 3 on the carrier B is transmitted from the user terminal 403B to the service providing section 306B.
The service providing section 306B, to authenticate the user requesting access, transmits the carrier user ID (user3@b.com) to the user authentication section 307B. Upon receiving the carrier user ID, the user authentication section 307B, to perform authentication, transmits the received carrier user ID to the authentication execution section 111 of the ID management system 150 (Step S5-S-4). Here, the carrier user ID (user3@b.com) is transmitted from the user authentication section 307B to the authentication execution section 111.
The authentication execution section 111, upon receiving the carrier user ID, refers to the ID federation information in the ID federation information storage section 105 based on the carrier user ID and acquires an ID management provider user ID that is ID-federated with the received carrier user ID. The authentication execution section 111 then determines, by referring to the authentication history information storage section 110, whether or not the ID management provider user ID has been authenticated, thereby determining whether or not the user identified by the ID management provider user ID has been authenticated (Step S5-S-5).
For example, when the ID federation information is stored in the ID federation information storage section 105 as shown in
The user authentication section 307B receives the information on whether or not the user has been authenticated from the authentication execution section 111 and returns that information to the service providing section 306B. Here, the user authentication section 307B returns to the service providing section 306B the information that the carrier user ID (user3@b.com) has been authenticated.
The service providing section 306B provides news information to the authenticated user terminal. Here, since the carrier user ID (user3@b.com) has been authenticated, the service providing section 306B provides news information to the user terminal 403B (Step S5-S-7).
Steps S5-S-8 to S5-S-10, which are processing characterizing the present exemplary embodiment, are performed in a state where the authentication registration processing (Steps S5-S-1 and S5-S-2) is completed, as shown in
First, referring to
Subsequently, the number-of-potential-deliverees calculation section 107 refers to the ID federation information storage section 104 and specifies a user who is federated with a delivery-capable carrier included in the delivery-capable ccID set and has not been allocated a delivery (Step S5-A-1). For example, the number-of-potential-deliverees calculation section 107 finds by referring to the ID federation information storage section 105 that “user3@idp” is ID-federated with the carrier B. That is, it is found that the carrier B is capable of delivering to “user3@idp”.
Next, the number-of-potential-deliverees calculation section 107, to further check whether or not the potential-deliveree user is still authenticated, transmits the ID management provider user ID (userIDidp) of the potential-deliveree user to the authentication effectiveness calculation section 109 (Step S5-A-2). Here, “user3@idp” is transmitted to the authentication effectiveness calculation section 109 as a userIDidp.
The authentication effectiveness calculation section 109, upon receiving this userIDidp, refers to the authentication history information storage section 110 and acquires information on the latest date and time this userIDidp was authenticated (Step S5-A-3). Here, it is assumed to acquire, for example, the information that “user3@idp” was authenticated at “2006/06/10 9:03” from
Next, the authentication effectiveness calculation section 109 determines whether or not more time than a preset value has elapsed since the date and time of the authentication, thereby determining whether the user has been authenticated (Step S5-A-4). Here, for example, assuming that the effectiveness of authentication lasts for only one day after authentication is performed and that the present date and time is “2006/06/13 9:03”, then the time of the authentication, “2006/06/10 9:03”, is more than one day before the present time. Therefore, it is determined that “user3@idp” is not authenticated.
Next, the authentication effectiveness calculation section 109 returns information on whether or not the user has been authenticated to the number-of-potential-deliverees calculation section 107 (Step S5-A-5). Here, information that “user3@idp” is “not authenticated” is returned from the authentication effectiveness calculation section 109 to the number-of-potential-deliverees calculation section 107. Upon acquiring the information on whether or not the user has been authenticated from the authentication effectiveness calculation section 109, the number-of-potential-deliverees calculation section 107, based on that information, increases the number of potential-deliveree users with effective authentication by “1” in case of “authenticated” but does not increase the number of potential-deliveree users with effective authentication in case of “not authenticated” (Step S5-A-6). Here, since “user3@idp” is not authenticated, the number-of-potential-deliverees calculation section 107 does not increase the number of potential-deliveree users with effective authentication, resulting in the number of potential-deliveree users with effective authentication remaining “0”. Therefore, since the number of potential-deliveree users with effective authentication is “0” with respect to the carrier B, the number-of-potential-deliverees calculation section 107 performs calculation to obtain information that (ID of carrier B, the number of potential-deliveree users with effective authentication)=(“ccID-B”, 0).
In such a manner, by referring to the authentication history information storage section 110, a number-of-potential-deliverees-with-effective-authentication list (ID of the carrier B, the number of potential-deliveree users with effective authentication) is generated (
Next, effects of the present exemplary embodiment will be described. In the present exemplary embodiment, the number-of-potential-deliverees calculation section 107 has a function of returning the number of potential-deliveree users still authenticated. Therefore, according to the present exemplary embodiment, when any of the delivery systems 330A and 3308 selects a transfer-destination carrier, it is possible to select a transfer-destination carrier not only depending on the number of potential-deliveree users but also depending on the number of potential-deliveree users still authenticated. Since an authenticated user is likely to read a message sooner, the present exemplary embodiment is effective in a case of desiring to send a message demanding immediacy, and others.
Next, a sixth exemplary embodiment of the present invention will be described with reference to the drawings. In the sixth exemplary embodiment of the present invention, the number of authentications is added as selection criterion information to each carrier ID in the delivery-capable ccID set 603.
In a message delivery system according to the sixth exemplary embodiment shown in
Compared with the fifth exemplary embodiment shown in
Next, operation according to the present exemplary embodiment will be described. In the present exemplary embodiment, processing described below is performed instead of Step S5-S-8 in
To check whether or not a user has been authenticated frequently, the number-of-potential-deliverees calculation section 107 transmits the ID management provider user ID of a potential-deliveree user to the authentication frequency calculation section 112 (Step S6-A-1). Here, the number-of-potential-deliverees calculation section 107 transmits “user3@dip”, which is the ID management provider user ID of a potential-deliveree user, to the authentication frequency calculation section 112.
The authentication frequency calculation section 112, upon receiving the ID management provider user ID, refers to the authentication history information storage section 111 and acquires the number of authentications performed on this ID management provider user ID (Step S6-A-2). Here, for example, it is assumed to acquire information that “user3@idp” was authenticated at “2006/06/13 9:03”.
Next, the authentication frequency calculation section 112 determines whether or not the number of authentications is larger than a preset value, thereby determining whether or not the ID management provider user ID has been authenticated frequently (Step S6-A-3). Here, a description will be continued assuming that, for example, if the number of authentications is five or larger, it is determined that an ID of interest has been authenticated frequently. In the present case, since the number of authentications is one, the authentication frequency calculation section 112 determines that the number of authentications is not large. Subsequently, the authentication frequency calculation section 112 returns to the number-of-potential-deliverees calculation section 107 information on whether or not the number of authentications is large (Step S6-A-4). Here, the authentication frequency calculation section 112 returns information of “not large” to the number-of-potential-deliverees calculation section 107.
The number-of-potential-deliverees calculation section 107, upon acquiring the information on whether or not the number of authentications is large from the authentication frequency calculation section 112, increases the number of potential-deliveree users frequently authenticated by “1” when the number of authentications is large but does not increase the number of potential-deliveree users frequently authenticated when the number of authentications is not large (Step S6-A-5). Here, since the number of authentications performed on “user3@idp” is “not large”, the number-of-potential-deliverees calculation section 107 does not increase the number of potential-deliveree users frequently authenticated, resulting in the number of potential-deliveree users frequently authenticated remaining an initial value of “0”. Therefore, since the number of potential-deliveree users frequently authenticated is “0” with respect to the carrier B, the number-of-potential-deliverees calculation section 107 generates a number-of-potential-deliveree-users-frequently-authenticated list (ID of the carrier B, the number of potential-deliveree users frequently authenticated)=(“ccID-B”, 0).
In such a manner, by referring to the authentication history information storage section 110, the number-of-potential-deliveree-users-frequently-authenticated list (ID of the carrier B, the number of potential-deliveree users frequently authenticated) is generated, and the number-of-potential-deliveree-users-frequently-authenticated list is transmitted to the delivery system A. Upon receiving the number-of-potential-deliveree-users-frequently-authenticated list, the delivery reference transfer list determination section 305A can select a transfer-destination carrier depending on the number of authentications.
Next, effects of the present exemplary embodiment will be descried. In the present. exemplary embodiment, the number-of-potential-deliverees calculation section 107 of the ID management system 160 has a function of returning the number of potential-deliveree users frequently authenticated. Therefore, according to the present exemplary embodiment, when any of the delivery systems 330A and 330B selects a transfer-destination carrier, it is possible to select a transfer-destination carrier depending on the number of potential-deliveree users frequently authenticated. Since a user frequently authenticated is likely to read a message sooner, the present exemplary embodiment is effective in a case of desiring to send a message demanding immediacy, and others.
Next, a seventh exemplary embodiment of the present invention will be described with reference to the drawings. According to the seventh exemplary embodiment of the present invention, a carrier ID to be registered in the delivery-capable ccID set 603 is filtered in accordance with a predetermined policy before it is transmitted to a delivery system.
In a message delivery system according to the seventh exemplary embodiment shown in
Compared with the second exemplary embodiment shown in
The delivery reference policy storage section 114 has a function of storing rule information on whether or not a carrier may be included in a delivery reference list. Specifically, information on whether a carrier “may” or “may not” be included in a delivery reference list is stored, associated with its carrier ID. In the present exemplary embodiment, it is assumed that rule information that “the carrier B ‘may’ be included in a delivery reference list” is stored, for example.
The delivery reference policy evaluation section 113 has a function of acquiring from the delivery reference policy storage section 114 rule information on whether a carrier “may” or “may not” be included in a delivery reference list, associated with its carrier ID. Moreover, the delivery reference policy evaluation section 113 has a function of transmitting the rule information on whether the carrier “may” or “may not” be included in a delivery reference list to the delivery reference list transmission section 106.
The delivery reference policy transmission sections 308A and 308B each have a function of transmitting rule information on whether a carrier “may” or “may not” be included in a delivery reference list to the delivery reference policy setting section 115.
The delivery reference policy setting section 115 has a function of receiving a carrier ID and rule information regarding the carrier from any of the delivery reference policy transmission sections 308A and 308B and storing in the delivery reference policy storage section 114 the rule information on whether the carrier “may” or “may not” be included in a reference list, associating it with the carrier ID.
Next, operation according to the present exemplary embodiment will be described. The delivery reference transfer list determination sections 305A and 305B each perform processing as described below on the carrier ID of each carrier in a delivery-capable ccID set. Hereinafter, a processing step related to the delivery system 340A (carrier A) in the present exemplary embodiment will be denoted by “Step S7-A-n” (n=1, 2, . . . ).
First, the delivery reference list transmission section 106 transmits the carrier ID of each carrier in a delivery-capable ccID set to the delivery reference policy evaluation section 113 (Step S7-A-1). The delivery reference policy evaluation section 113, upon receiving the above-mentioned carrier ID, refers to the delivery reference policy storage section 114 and acquires rule information, associated with the carrier ID, on whether the carrier “may” or “may not” be included in a reference list (Step S7-A-2).
The delivery reference policy evaluation section 113 evaluates the acquired rule information, determines whether the carrier ID “may” or “may not” be included in a reference list, and transmits the result of determination to the delivery reference list transmission section 106. Here, the delivery reference policy evaluation section 113 to acquires the rule information that “the carrier B ‘may’ be included in a delivery reference list” from the delivery reference policy storage section 114. Therefore, the delivery reference policy evaluation section 113 evaluates this rule information, determines that the carrier B “may” be included in a delivery reference list, and transmits that result of determination to the delivery reference list transmission section 106 (Step S7-A-3).
Based on the result of determination from the delivery reference policy evaluation section 113, the delivery reference list transmission section 106 adds the corresponding carrier ID to the delivery-capable carrier set when the carrier “may” be included in a delivery reference list but does not add the corresponding carrier ID to the delivery-capable carrier set when the carrier “may not” be included in a delivery reference list (Step S7-A-4). Here, since the carrier B may be included in a delivery reference list, its carrier ID is added to the delivery-capable carrier set. The delivery reference list transmission section 106 transmits the generated delivery reference list (delivery-capable carrier set) to any one of the delivery reference transfer list determination sections 305A and 305B (Step S7-A-5).
Next, effects of the present exemplary embodiment will be described. In the present exemplary embodiment, the delivery reference policy evaluation section 113 has a function of determining whether or not a carrier “may” be included in a delivery reference list, and based on the result of determination, the delivery reference list transmission section 106 can control whether or not to include the carrier ID in a delivery reference list to output. Thereby, according to the present exemplary embodiment, if a carrier does not desire to be transferred to, control can be made such that a transfer will not be made to the carrier, by setting such a rule that the carrier “may not” be included in a delivery reference list.
Next, an eighth exemplary embodiment of the present invention will be described with reference to the drawings. In the eighth exemplary embodiment of the present invention, when actually selecting a transfer destination from the delivery-capable ccID set 603, a transfer destination is selected after cost is calculated.
In a message delivery system according to the eighth exemplary embodiment shown in
Compared with the third exemplary embodiment shown in
The delivery reference cost information storage sections 309A and 309B each store a carrier ID and calculation rule information regarding communication cost, reference fee, and the like incurred when a transfer is made to the carrier ID as a transfer destination, associating them with each other. In the present exemplary embodiment, it is assumed that first calculation rule information and second calculation rule information are stored in the delivery reference cost information storage section 309A. For example, for the first calculation rule information, the carrier ID of the carrier B is associated with information that “as to communication cost, the transfer-source carrier pays the transfer-destination carrier 10 yen (¥) per person to whom a delivery is made; as to reference fee, the transfer-source carrier pays a commission of 100 yen to the transfer-destination carrier”. For the second calculation rule information, a carrier ID of a carrier C, which runs a third delivery system (not shown), is associated with information that “as to communication cost, the transfer-source carrier pays the transfer-destination carrier 10 yen per person to whom a delivery is made; as to reference fee, the transfer-source carrier pays a commission of 200 yen to the transfer-destination carrier”.
Next, operation according to the present exemplary embodiment will be described. Hereinafter, a processing step related to the delivery system 350A (carrier A) in the present exemplary embodiment will be denoted by “Step S8-A-n” (n=1, 2, . . . ).
First, the delivery reference transfer cost determination section 310A of the delivery system 350A having received a request to deliver a message receives a list including a set of a delivery-capable carrier ID and the number of potential deliverees from the delivery reference list transmission section 106 (Step S8-A-1). Here, it is assumed that (“ccID-B”, 1) is received.
Upon this receipt, the delivery reference transfer cost determination section 310A refers to the delivery reference cost information storage section 309A and acquires calculation rule information associated with the carrier ID (Step S8-A-2). Thus, the delivery reference transfer cost determination section 310A acquires the first and second calculation rule information associated with the carrier ID “ccID-B”.
Subsequently, the delivery reference transfer cost determination section 310A evaluates the acquired calculation rule information and calculates a total cost incurred when making a transfer (Step S8-A-3). Here, since the number of deliverees is one, the delivery reference transfer cost determination section 310A calculates that a total cost of 110 yen a transfer cost of 10 yen+a reference commission of 100 yen) is incurred when requesting a transfer of the carrier B and that a total cost of 210 yen (=a transfer cost of 10 yen+a reference commission of 200 yen) is incurred when requesting a transfer of the carrier C.
Subsequently, the delivery reference transfer cost determination section 310A compares the total costs calculated for all the carrier IDs and determines that a carrier of the lowest total cost should be transfer-requested (Step S8-A-4). Here, the delivery reference transfer cost determination section 310A determines that the carrier B is a transfer-request-destination carrier.
Based on the above-described result of determination made by the delivery reference transfer cost determination section 310A, the delivery reference transfer section 304A transmits information requesting to transfer the message to the delivery reception section of the delivery system run by the transfer-request-destination carrier (Step S8-A-5). Here, since the transfer-request-destination carrier is the carrier B, the delivery reference transfer cost determination section 310A requests the delivery reception section 301B of the delivery system B to transfer the message.
Next, effects of the present exemplary embodiment will be described. In the present exemplary embodiment, the delivery reference transfer cost determination sections 310A and 310B each have a function of calculating a total cost when transferring a message and can determine a transfer destination depending on the total cost. Thereby, according to the present exemplary embodiment, it is possible to select a carrier so that a request to transfer a message is made to a carrier of the lowest total cost.
Note that the present invention is not limited to the above-described exemplary embodiments. For example, the present invention embraces programs for message delivery causing a computer to execute the functions of the individual components of the first to eighth exemplary embodiments as described above.
The present invention is applicable to various uses, such as a case where, when a service provider providing delivery of contents and the like delivers a message to a user, the service provider requests delivery of the message from a carrier such as an ISP, a mobile-telecommunication carrier, or a fix-telecommunication carrier to which the user subscribes.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2008-234297 | Sep 2008 | JP | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/JP2009/004500 | 9/10/2009 | WO | 00 | 2/7/2011 |
