System for authentication of network usage

Abstract

Apparatus for collecting subscription data for subscribers in a telecommunications system for use in metering usage of network resources includes a data storage device operatively arranged to store subscriber records, and a data processor. The subscriber records include a plurality of fields including a group field for storing data indicative of group membership of a subscriber. The data processor is operatively arranged to request access to a remotely accessible information source on the basis of identification data. Responsive to receipt of a response from the remotely accessible information source, the data processor performs a first storage action in respect of a response of a first type and performs a second storage action in respect of a response of a second type. Responsive to receipt of group membership data from the subscriber, the data processor is operatively arranged to identify a remotely accessible information source corresponding to the group and to request access thereto on the basis of identification data associated with the received group membership data. Also, responsive to a response of the first type received from the remotely accessible information source, the data processor is operatively arranged to update the group field in the subscriber record so as to indicate authenticated membership of the group identified in the received group membership data.

Description

FIELD OF THE INVENTION

The present invention relates to a method of, and system for, authenticating group membership in relation to a subscriber of a communications network, and to a method of, and system for, allocating network usage on the basis of group membership. The present invention is particularly, but not exclusively, suited to arrangements in which the provision of network services is sponsored by a party other than the group or parties involved in a given network event.

BACKGROUND INFORMATION

As is well known, communications networks provide a means for users to communicate with one or more other users. Users of a communication system are typically provided with numerous services, such as calls, data communication such as messaging and/or multimedia services, or simply provide users with a gateway to another network, such as the Internet. In relation to any one service, various communication systems, such as public switched telephone networks (PSTN), wireless communication systems, e.g. global system for mobile communications (GSM), general packet radio service (GPRS), universal mobile telecommunications system (UMTS), wireless local area network (WLAN) and so on, and/or other communication networks, such as an Internet Protocol (IP) network, may simultaneously be concerned in providing a connection. In addition communications systems can include broadcast networks such as Digital Video Broadcasting for Handheld (DVB-H), Digital Audio Broadcasting (DAB), and Digitam Multimedia Broadcast (DMB). An end-user may access a communication network by means of any appropriate communication device, such as user equipment (UE), a mobile station (MS), a cellular phone, a personal digital assistant (PDA), a personal computer (PC), or any other equipment operable according to a suitable network protocol, such as a Session Initiation Protocol (SIP) or a wireless applications protocol (WAP) or a hypertext transfer protocol (HTTP). The user equipment may support, in addition to call and network access functions, other services, such as short message service (SMS), multimedia message service (MMS), electronic mail (email), Web service interface (WSI) messaging and voice mail and one-way messages such as WAP PUSH messages.

Communications sessions involving more than two users are commonly referred to as virtual, online or group communications, and can be facilitated by services including the “push-to-talk over cellular” (PoC) service also known as the PTT (push-to-talk service), the instant messaging (IM) service, IRC (“Internet Relay Chat”), and the ICQ (“I Seek You”) service. In the case of the IM service, users are allowed to send messages to one or more in a list of predetermined users (a so-called “private list”) in a conversational mode, and because they are transmitted “instantly”, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The IRC service is a system for chatting that involves a set of rules and conventions and is implemented via client/server software. An IRC client can be downloaded to a user's computer, and the client is then used to connect to an IRC server in an IRC network to start or join an IRC chat group. The fourth group messaging application, ICQ (“I Seek You”), is a client application that provides information as to which “friends” and “contacts” are also online on the Internet, pages them, and operates so as to coordinate a “chat” session with them. The IM system is similarly arranged to generate alerts whenever a member of a given private list is online.

These virtual communities are becoming increasingly important vehicles of communication and dissemination of new ideas in the online world; such communities are used not only to develop and discuss ideas voluntarily within specific interest groups but they also are of increasing value for a advertisers: in essence they are word-of-mouth marketing and endorsement networks from one member to another member, and are increasingly perceived as the strongest method of marketing. Most online applications also utilize, consciously or unconsciously, the viral effects generated within these social networks and between the networks in their marketing.

In addition to virtual communities, real communities such as educational clubs, book clubs, music clubs, sports clubs, professional communities etc. provide a forum for discussion and interaction. Many such real communities have web pages to share information within their community, and access to these data is often controlled by means of membership criteria (user ID and password) for privacy reasons. Thus virtual and real communities are interrelated in so far as both require some sort of web authentication method in order to authenticate members.

Advertisers can be attracted by the ready-made and apparently auto-profiled set of recipients offered by groups, so as to share, at least in part, the costs associated with communications between the group members; however the advertisers require a degree of comfort that their targeted messages (i.e. messages containing information that matches the characteristics of the group) are reaching persons who are indeed members of a given group—essentially to ensure that the recipients match the characteristics of the targeted messages.

SUMMARY OF THE INVENTION

In embodiments of the invention, membership of a given subscriber in relation to a particular group is verified subsequent to the subscriber providing details of a given group of which they purport to be a member, and the subscriber record is updated to reflect the verification, or otherwise, of the asserted membership.

In preferred arrangements the remotely accessible information source is associated with the group, meaning that usage of communications-based group services is dependent on verification, by a party corresponding to the group, of the subscriber's credentials. In one arrangement, the party might be a web server hosting group-related information that is only accessible on the basis of a bonefide password and login. Standard web login and password procedures are therefore conveniently used as a verification process in embodiments of the invention rather than (as is usual) as a process for accessing information associated with the group.

In such an arrangement the data processor can be arranged to look for cookies (a packet of data for use in sending to the web server), a web page of a predetermined format, or similar, within the response received from the web server and update the subscriber record accordingly.

Embodiments of another aspect of the invention provide message modification on the basis of group membership, and essentially provide a means of selecting tags to add to a message on the basis of identified group membership. Conveniently the apparatus can comprise a storage system arranged to store a plurality of tags and index data corresponding thereto, each index data item comprising data indicative of a group membership configuration corresponding to the sending party of a message and the recipient of a message. For example: a first tag might be associated with a configuration in which the sending party and recipient are members of the same group; a second tag might be associated with a configuration in which the sending party is a member of a group but the recipient is not a member of any group; a third tag might be associated with a configuration in which the recipient is a member of a group but the sending party is not a member of any group; and a fourth tag might be associated with a configuration in which the recipient is a member of a group and the sending party is a member of a different group. In at least some arrangements the data processor can be arranged to send a message containing the selected tag to the sending party.

Most preferably the tag includes a field in which the name of an entity, such as a sponsor of a group, is inserted once the or each group membership corresponding to the sending party/recipient has been identified. In the case of the sending party and recipient each being members of different groups, messages can be modified on the basis of a set of precedence rules which specify which of the groups should form the basis for the tag selection and message modification.

In preferred arrangements the communications network includes data storage means arranged to hold group records, each group record being indicative of network usage relating to members of the group. The data processing means can be arranged to determine whether said message falls within predetermined message transmission criteria, and to modify a group record corresponding to the group when said criteria are met. The group record can hold data indicative of an allocation of usage associated with the group, in which case the data processor is arranged to reduce allocation associated with the group. Alternatively the data processor is arranged to store data indicative of a charge for transmission of the message in the group record.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic illustration of a mobile network arranged in accordance with an embodiment of the invention;

FIG. 2 is a schematic illustration of data exchanges between components of the system illustrated in FIG. 1;

FIG. 3 a is a block diagram showing components of the registration server shown in FIGS. 1 and 2;

FIG. 3 b is a schematic timing diagram showing messages passed between various components of the system illustrated in FIG. 1; and

FIG. 4 is a schematic block diagram showing components of the message modification server shown in FIGS. 1 and 2.

DETAILED DESCRIPTION

Embodiments of the invention are concerned with modification of data messages based on group, or community, membership of the sender and receiver of the data message. The nature of this modification, and the criteria relating thereto, is described in detail later, but first a description of the infrastructure needed to support the modification will be presented.

FIGS. 1 and 2 show an example of a data messaging system 1 within which embodiments of the invention operate. In FIG. 2, the arrows indicate data flows within the data messaging system 1 and the blocks indicate components of the data messaging system 1. Embodiments, described herein as a message modification service, are concerned with modifications to short message service messages (SMS), but it will be appreciated that other message types, such as multimedia message service (MMS), email messages, bespoke messages in the form of GPRS data and/or streamed data and voice messages can alternatively be modified according to embodiments of the invention, and that the specific arrangement of the data messaging system 1 is dependent on the type of message being transmitted.

In the arrangement shown in FIGS. 1 and 2, a terminal 2 communicates with various network devices within the data messaging system 1 via network 6. The terminal 2 may be a wireless terminal such as a mobile phone or a PDA. The data messaging system 1 comprises a WAP gateway 8, which is typically a network operator's WAP gateway and a registration services server S1, with which the terminal 2 communicates. In addition the data messaging system 1 comprises a message modification server S2, a store-and-forward message server SMSC 16 configured to store and forward messages in accordance with conventional methods, and a database DB1, arranged to store data in respect of subscribers, terminals such as 2, and content data. The database DB1 can either be provided by two separate databases 20, 24, as shown in FIG. 1, or by a single database, as shown in FIG. 2.

In embodiments of the invention it is assumed that the user of the terminal 2 is a subscriber of the network, and that network usage is allocated, at least in part, in dependence on subscribers accepting delivery of a predetermined number and/or type of promotional messages; subscription is contingent on the subscriber entering data indicative of their demographic data and interests, this subsequently being used, e.g. by the message modification server S2 to tailor selection of the promotional messages.

The registration server S1 can be accessed by a user of the terminal 2 or via a terminal T1 typically connected to the Internet 10 (the terminal T1 can be e.g. a laptop computer or a personal computer fixedly attached to a network) by actuating a URL corresponding to the server S1 when entering such details; referring to FIG. 3a, in addition to standard CPU, memory, data bus, Input/Output ports, data storage, and operating system programs, the server S1 comprises registration software 301, which receives identification, group membership, demographic and preference data from the subscriber; and authentication software 303, which, as will be described in detail later, authenticates the received group membership data. Once these data have been received and, where appropriate, authenticated, a subscriber record is completed and/or updated for the subscriber and stored in the database DB1, for subsequent access by the SMSC 16 and the message modification server S2 (among other network components). The database DB1 thus holds subscriber data for each subscriber, the data identifying: the billing account to which the subscriber belongs; interests and preference data relating to the subscriber; and if the subscriber has been authenticated as belonging to a group, data identifying the group to which the subscriber belongs. In preferred embodiments of the invention the group records are initially empty, and are populated once membership of a given group has been confirmed so as to include data indicative of the type of subscription held for the group. The database DB1 is configured so that any details relating to a billing account held in the database may be retrieved by selecting the appropriate billing account, any details relating to a group held on the database may be retrieved by selecting the appropriate group, and any details relating to a particular subscriber held in the database may be retrieved by selecting the appropriate subscriber.

Broadly speaking, embodiments of the invention comprise two processes, each of which can operate independently of the other, but for illustrative purposes will herein be described together. The first process is a registration process, effected by the authentication software component 303, and which operates so as to verify group membership details entered by subscribers when providing their demographic details. The second process is a message modification process, executed by the message modification server S2, wherein messages are modified based on sender and recipient identities and their respective membership or otherwise in a given group. In a preferred arrangement the two processes are linked by the involvement of a so-called sponsor, which pays for the transmission of messages between parties contingent on their respective—and authenticated—group membership. Successful authentication according to the first (registration) process, which is itself designed to verify group membership, therefore confirms to the sponsor that discounts (by way of free or discounted messaging) are being applied correctly.

Each of these processes and the functional parts required to implement the processes will now be described, starting with the authentication process, for the case where the subscriber completes the registration process using terminal T1. Referring back to FIG. 2, at step 201 the user enters the URL corresponding to the registration server S1, which causes the registration software 301 to send a Web page from the server S1, via an Internet gateway 12, where it is modified, using conventional techniques, into a format suitable for display on the user's terminal T1, and sent to the terminal T1. The user then enters various registration details into the web page and the terminal T1 sends the details to the registration services server S1, via the WAP gateway 8. As part of the registration process, the user enters personal information details, such as name, address, terminal details (including capabilities), sex, occupation, interests, etc. group memberships, and these details are stored, at step 202b, in the database DB1. The group membership data in respect of each group are stored in association with a respective group flag indicating authentication status thereof: the registration software 301 passes initially entered such group data to the authentication software 303 component, and in the first instance sets the status of each group flag to “unknown”. The authentication software component 303 is then triggered to perform a group membership authentication process, this involving an exchange of data with the terminal T1 and the output of which results in a change to the status of the group flag (either “authenticated” or “bogus” or “undetermined”).

In one embodiment the authentication process involves the authentication software component 303 capturing respective user login details corresponding to a web-based service for the (or each) group, using these captured details to simulate a login process, and using the results thereof as the basis for updating the group flag status. Referring also to FIG. 3b, in one arrangement the authentication component 303 sends a pop-up, a frame or a bespoke login sheet to the terminal T1 (step S3.1), inviting the subscriber to enter his user ID and password; assuming these details to be duly entered, the authentication component 303 receives the entered data (step S3.3) and replicates the normal login process with a web server S3 corresponding to the group identified by the subscriber (step S3.5). As per a conventional login procedure, the group web server S3 returns data indicative either of a successful login process—in the form of a cookie, predetermined application programming interface data or a predetermined web page containing a predetermined layout or confirmation message—or of an unsuccessful login process (step S3.7). Examples of successful and unsuccessful login procedures are shown in the scripts below:

Successful
==========
Request
------
POST /config/login? HTTP/1.1
Host: login.yahoo.com
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.3) Gecko/20040910
Accept: text/xml,application/xml,application/xhtml+xml,text/
html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://login.yahoo.com/config/login?
Cookie: B=33f4nh50i49&b=3&s=2a
Content-Type: application/x-www-form-urlencoded
Content-Length: 279
.tries=3&.src=my&.md5=&.hash=&.js=&.last=&promo=&.intl=us&.bypass=&.pa
rtner=&.u=25ub0qluk6q&.v=0&.challenge=rIt9CsSjzavp3MwrRduDZy&.yplus=
&.emailCode=&pkg=&stepid=&.ev=&hasMsgr=0&.chkP=Y&.done=http%3A%2F%
2Fmy.yahoo.com&.pd=my_ver%23d0&login=XXXXXX&passwd=XXXXXXX
Answer
-------
HTTP/1.x 200 OK
Date: Fri, 13 Oct 2006 08:43:19 GMT
P3P: policyref=“http://p3p.yahoo.com/w3c/p3p.xml”, CP=“CAO DSP COR
CUR ADM DEV TAI PSA PS IVDi CONi TELo OTP DELi SAMi OTRi UNRi PUBi
IND PHY ONL UNI FIN COM NAV INT DEM CNT STA POL HEA PRE GOV”
Cache-Control: private
Pragma: no-cache
Expires: Thu, 05 Jan 1995 22:00:00 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
Set-Cookie:
F=a=SrNlnuQsvfC8VdCWs4SKlvdGqB17owTNi8TC4cs2qNo_EhUT.JexzZ&b=afek;
expires=Thu, 15 Apr 2010 20:00:00 GMT; path=/; domain=.yahoo.com
Set-Cookie: Y=v=1&n=51on1c961sa&l=90dd4.0jed4d/
o&p=m25kd4012000000&jb=34|26|&r=ge&lg=us&intl=us&np=1; path=/;
domain=.yahoo.com
Set-Cookie: PH=fn=xBi7MUz4jIYIJyBmw-; path=/; domain=.yahoo.com
Set-Cookie: T=z=nG1LFBnMFBGgWHDicYK5A2BjUyNTE1TzU3NTc-
&a=YAE&sk=DAAbx4xUSO.Lm&d=c2wBTlRjeESTFN0RJd01qQS0BYQFZQUUBb2sBWlcw
LQF0aXABVEZKMHlCAXp6AW5UxGQmdXQQ--; path=/; domain=.yahoo.com
Failed login:
=============
Request:
------
POST /config/login? HTTP/1.1
Host: login.yahoo.com
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.3) Gecko/20040910
Accept: text/xml,application/xml,application/xhtml+xml,text/
html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://login.yahoo.com/config/
login_verify2?.page=p1&.partner=&.intl=us&.src=my&.done=http://
my.yahoo.com
Cookie: B=33f4nh52h0i49&b=3&s=2a
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 264
.tries=l&.src=my&.md5=&.hash=&.js=&.last=&promo=&.intl=us&.bypass=&.pa
rtner=&.u=25ub0q12iuk6q&.v=0&.challenge=MklbieR_zKyeimTiryyrId_3Po&.yp
lus=&.emailCode=&pkg=&stepid=&.ev=&hasMsgr=0&.chkP=Y&.done=http%3A%
2F%2Fmy.yahoo.com&.pd=my_ver%253d0&login=foo&passwd=foo
Answer
-------
HTTP/1.x 200 OK
Date: Fri, 13 Oct 2006 08:40:37 GMT
P3P: policyref=“http://p3p.yahoo.com/w3c/p3p.xml”, CP=“CAO DSP COR
CUR ADM DEV PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi
PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV”
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

On the basis of the response from the server S2, the authentication component 303 updates the group flag status (step S3.9); this group flag status is then subsequently used by the data message modification service according to the second aspect of the invention.

Turning now to aspects of the message modification process, in one arrangement the message modification server S2 is arranged to selectively modify messages based on respective group membership of the sender and recipient; for example, assuming a group to be tagged as sponsored by a particular third party, messages transmitted between group members are modified to include a first type of information, whereas messages transmitted from a group member to a non-group member are modified to include a second type of information. The content of the first and second types of information can be controlled by the sponsor and are related in some way: for example, the first type of information could be a message stating “this message has been sponsored by XYZ”, whereas the second type of information could be a message stating “this message could have been delivered free to you by XYZ if you were a member of group G1”.

Referring to FIG. 4, the message modification server S2 comprises standard processing components together with various bespoke message modifying components; these message modifying components include selecting software 401 and a repository of rules R, each rule specifying a set of group membership conditions and data to select for use in modifying a given message in dependence on the conditions being satisfied (whilst shown as being stored local to the server S2, the rules could be stored in the database DB1 and accessed therefrom by the selecting software 401). The server S2 also includes message modifying software 403 for modifying the incoming message so as to include the selected data, thereafter forwarding the modified messages to the SMSC 16 in accordance with standard methods.

The rules are preferably specified by the group, or by the sponsor of the group, and in one arrangement specify particular tags to apply to a message in the event that the conditions are satisfied. Examples of the conditions include:

Rule Condition(s)
R1   Sender & Recipient both members of same group
R2   Sender & Recipient both members of a group, but the groups
     are different
R3   Sender is a member of a group (& recipient is not)
R4   Recipient is a member of a group (& sender is not)
R5   Neither Recipient nor Sender is member of a group
R6   If Sender &/or Recipient are members of more than one
     group, apply inter-Group precedence rules (previously agreed
     between groups and managed by the data messaging server S2) to
     decide which of rules R particular to each of the groups should
     be applied.

The actions associated with these rules are specified in the form of a billing action and a message modification action. Preferably the message modification actions in respect of at least two of the rules are related: in one embodiment the action (message modification) is identical, but the content of the tags applied to modify the message are different, but related; and in another embodiment the actual actions taken in respect of different rules are different, but related. The actions are stored in the database DB1, in association with a given rule and thus a given group.

For example, the message modification actions applicable in respect of Rules R1 . . . R4 for group G1 could be as follows:

TABLE
Actions for Group G1
		Message Modification
Rule	Action(s)	Tag
R1	Billing Action:	A1
	Do not debit accounts of sender or	This message was
	recipient	sponsored by “Sponsor”
	Message modification actions:	for the community G1
	Concatenate Tag A1 with name of	members
	sponsor & add to message received
	from sender (to be sent to recipient
	only)
	Add/Send sponsor-selected message
	for G1 (to be added to message to be
	sent to recipient; to be sent cold to
	sender) [optional]
R2,	Billing Action:	A2
R3	Debit account of recipient	If you joined group G1
	Message modification actions:	you could benefit from
	Concatenate Tag A2 with name of	free text messaging
	sponsor & add concatenated tag to	thanks to “Sponsor”
	message received from sender and
	send to recipient
	Add/Send sponsor-selected message
	for G1 (to be added to message to be
	sent to recipient; to be sent cold to
	sender)
R4	Billing Action:	A2 (As above)
	Debit account of sender
	Message modification actions:
	Concatenate Tag A2 with name of
	sponsor & send concatenated tag to
	sender
	Add/Send sponsor-selected message
	for G1 (to be added to message to be
	sent to sender; to be added to message
	to be sent to recipient) [optional]
R5	Billing Action:	A2 (As above)
	Debit account of sender &/recipient
	Message modification actions:
	Concatenate Tag A2 with name of
	sponsor, add concatenated tag to
	message received from sender and
	send to recipient; send concatenated
	tag as cold message for sender
	Add sponsor-selected message for G1
	(to be added to message to be sent to
	sender; to be added to message to be
	sent to recipient) [optional]

Turning back to FIG. 2, upon receipt of an SMS from a sender (step S203), the selecting software 401 identifies sender and/or recipient information from an incoming message and selects, by accessing the database DB1, the respective group membership(s), together with all associated message modification actions associated therewith (step 204). On the basis of the group memberships, the selecting software 401 identifies and processes one or more applicable rules R1 . . . Rn (step 205) in order to identify billing arrangements for the message and to determine how to modify the incoming message (step 206). After the message has been modified, the modified message is transmitted to the SMSC 16 of the licensed operator (step 207a); thereafter billing instructions are transmitted to the database DB1 for storage therein in respect of the sender/recipient/sponsor (step 207b), consistent with the billing action identified at step 205.

The foregoing can conveniently be explained by way of a couple of examples, firstly for the case where a message M1 is sent from subscriber A to subscriber B, and both A and B are determined to be members of community G1, and for which the sponsor of community G1 is Coke™. In this example the selecting software component 401 selects rule R1, particular to Group G1, which has the following output actions:

• 1. All text communication between community members of G1 are free;
• 2. Text messages should be tagged with tag A1, concatenated with the name of the sponsor (Coke™); thus in this example, the tag reads: “this message was sponsored by Coke™ for the members of community G1”.

This then causes the message M1 to be modified so as to include the branded tag and is sent onto the recipient; since both A and B are members of group G1, neither of their accounts is debited for the message transmission and receipt.

In a second example, message M1 is sent from subscriber A to subscriber B; subscriber A is not a member of any community, but subscriber B is a member of group G1. Assuming for illustrative purposes the sponsor of group G1 again to be Coke™, the following output actions are generated at step 205:

• 1. Bill the sender of the message for the transmission to the recipient;
• 2. Create a message to send to the sender based on tag A2 and concatenated with the name of the sponsor (Coke™); thus in this example, the message reads: “If you joined group G1 you could benefit from free text messaging thanks to Coke™”.
• 3. Do not bill the sender for the transmission of the tagged promotional messageIt will be appreciated that the content of the messages sent to the respective parties A and B is related by virtue of the identity of the group sponsor, and that the tagging and/or creation of respective messages, by the message modification server S2, is dependent on which of the sender or recipient is, or is not, a group member.

In a third example, message M1 is sent from subscriber Áto subscriber B; subscriber A is a member of Group G1, but subscriber B is not a member of the same group G1. Assuming for illustrative purposes the sponsor of group G1 again to be Coke™, the following output actions are generated at step 205:

• 1. Do not bill the sender of the message for the transmission to the recipient;
• 2. Create a message to send to the recipient based on tag A2 and concatenated with the name of the sponsor (Coke™); thus in this example, the message reads: “If you joined group G1 you could also benefit from free text messaging thanks to Coke™”.

In the event that both the sender and recipient are members of different groups (e.g. sender is a member of group G1 and recipient is a member of group G2), the inter-group precedence rules mentioned above in relation to rule R6 could include the following conditions:

• • Review sponsor data in respect of G1 & G2 to see whether they include any prestored (or shared) precedence specifications;
  • Review temporal data in respect of G1 & G2 to see whether they include any prestored precedence specifications;
  • If there are no prestored precedence specifications, prioritise the group associated with the sender over that associated with the recipient, and debit the account of the group sponsor corresponding to the sender;

Shared precedence specifications might include agreed sharing of messaging costs between sponsors of particular groups, so that, in the event that the sponsors of groups G1 and G2 have an inter-group agreement, the costs of transmitting messages are shared between sponsors. In this case, the tag A2 added to messages would alert each party to the existence of the group of which the other party is a member (e.g. if sender A is a member of G1 and recipient B is a member of G2, the tag A2 added to the message sent to A would read “If you joined group G2 you could benefit from free text messaging thanks to “Sponsor2” and the tag added to the message sent to B would read “If you joined group G1 you could benefit from free text messaging thanks to “Sponsor1”).

Implementation Details & Alternatives

The registration software 301, category selection software 303, authentication software 305, selecting software 401 and modifying software 403 are preferably written in the Java programming language. The server S1 could, for example, be an Apache HTTP server, and the proxy message server SMSC_1 could be a J2EE JMS Server (see http://openjms.sourceforge.net/). The registration software 301, category selection software 303 and authentication software 305 could be Java™ servlet containers configured to run within a Java platform such as Java 2 Platform Standard Edition v1.4.1 (for further information see resources available from Sun Microsystems™ e.g. at http://java.sun.com/j2se/1.4.1/and http://java.sun.com/products/servlet/index.html). The skilled person will appreciate that the software could be written in any suitable language.

As an alternative to the registration software component 301 sending a web page to the terminal T1, the terminal T1 could have, stored thereon, an application arranged to capture such demographic data (not shown in the Figures). In the case where the subscriber uses his mobile terminal 2 to communicate with the registration server S1, such an application could be stored on a SIM card, which, as is known in the art, is used for the storage and retrieval of data items by the terminal T1. The command set, data file structure and data coding format for data communicated via the interface between the terminal T1 and the SIM processor are all specified, in GSM technical specification 11.11. Alternatively the application could be transmitted to the terminal T1 (or mobile 2) (e.g. via GPRS or Bluetooth) in response to a request received by the server S1 from the terminal T1 and would be of a format suitable for cooperating with the operating system in use on the terminal T1.

Whilst authentication of a given group membership is described as being performed via login-simulation, it will be appreciated that such a method is only possible in relation to groups that are web-based; for other groups (e.g. retail establishments using loyalty cards and the like, where membership of a group can be defined on the basis of subscribers being in possession of a loyalty card and account, neither or which are managed by a user-accessible web service), membership of a given group could be established by sending of an authentication request message by the authentication software component 303 to a service associated with the retail establishment, or on the basis of previously determined authentication data that is retrievable from a third party.

In the above embodiments, message modification is performed by the message modification server S2; however, message modification could instead be performed by a proxy store and forward node (not shown), which is logically distinct from the network operator's SMSC 16. In order to ensure that messages are sent to this proxy SMSC in the first instance (and not to the network operator's SMSC) the mobile terminal 2 would require configuring with details of this proxy e.g. via an Over-The-Air (OTA) SMS settings message. In response, the operating system programs on the terminal 2 automatically configure the default SMSC settings to the network address of the proxy message server. This therefore means that any SMS messages subsequently sent from the terminal 2 will be sent to the proxy message server in the first instance. For further information regarding use of OTA protocol for the delivery of data to a WAP client from a WAP server, the reader is referred to literature available from the WAP Forum Ltd., in particular “Wireless Application Protocol, PUSH OTA Protocol Specification”, published 16 Aug. 1999, available from http://www.wapforum.org/what/technical/PROP-PushOTA-19990816.pdf.

As a further alternative, the message modification process could be performed by the network operator's SMSC 16.

The above embodiments are to be understood as illustrative examples of the invention. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

1. A non-transitory computer-readable medium comprising a computer program for collecting subscription data for subscribers in a telecommunications system for use in metering usage of network resources, the computer program being arranged to: store subscriber records, said subscriber records including a plurality of fields including a group field for storing data indicative of group membership of a subscriber, said group field being initially empty; andrequest access to a remotely accessible information source on the basis of identification data, and, responsive to receipt of a response from the remotely accessible information source, perform a first storage action in respect of a response of a first type and performing a second storage action in respect of a response of a second type,wherein, responsive to receipt of group membership data from the subscriber, to identify a remotely accessible information source corresponding to the group and to request access thereto on the basis of identification data associated with the received group membership data, andwherein, responsive to a response of the first type received from the remotely accessible information source, to update the group field in the subscriber record so as to indicate authenticated membership of the group identified in the received group membership data.

2. The computer-readable medium according to claim 1, wherein, responsive to a response of the second type received from the remotely accessible information source, the computer program is further arranged to update the group field in the subscriber record so as to indicate unauthenticated membership of the group identified in the received group membership data.

3. The computer-readable medium according to claim 1, wherein the computer program is further arranged to process the response received from the remotely accessible information source so as to derive therefrom a packet of data for use in sending to the remotely accessible information source.

4. The computer-readable medium according to claim 1, wherein the computer program is further arranged to: store group, records, each group record being indicative of network usage relating to members of the group; andanalyze data indicating that a subscriber authenticated in respect of a group has sent a message, to determine whether said message falls within predetermined message transmission criteria, and to modify a group record corresponding to the group when said criteria are met.

5. The computer-readable medium according to claim 4, wherein the group record includes data indicative of an allocation of usage associated with the group, and wherein the computer program is further arranged to reduce allocation associated with the group, whereby to modify the group record.

6. The computer-readable medium according to claim 4, wherein the computer program is further arranged to store data indicative of a charge for transmission of the message in the group record, whereby to modify the group record.