GB2450385A - Telephony services for community users - Google Patents

Abstract

A system for providing telephony services for members of a community via a mobile communication network. The system provides an intermediate identifier assigned to each telephony service by a connectivity domain. This identifier is capable of being dialled and is associated with the telephone numbers of one or more members, thereby allowing the telephony service without disclosing real world contact details of the members.

Description

TELEPHONY SERVICES FOR COMMUNITY USERS

FIELD OF TIlE INVENTION

This invention relates to a system for enabling communication between users of online communities without disclosing the users' real-world identities and without disclosing of their real-world contact details to unknown members of the community. The solution according to the invention is implemented by a logical and connectivity architecture (LC).

BACKGROUND OF THE INVENTION

Recent years have seen a rise in online communities where members interact and express themselves. The interactions take many forms ranging from publishing articles and journals (e.g. blogs, discussion boards), peer-to-peer messaging (e.g. instant messaging, email), social networking (e.g. MySpace, Bebo) to online virtual worlds (e.g. Second Life).

One key aspect of many online communities is the ability of the users to remain anonymous thereby separating their real and online personas. This is usually achieved during the registration process when a user enrols as a member of their chosen online community -at which point they may choose a pseudonym and login password. Users that join multiple online communities may further choose to maintain separate online pseudonyms in each community.

They may also choose to reveal only some personal details to other members of the community (e.g. gender, age, home town). However problems arise when disclosing contact information such as email addresses, phone numbers, instant messaging ids, etc in the community -including, Disclosing such information may inadvertently disclose the members' real identity (e.g. email address containing their name).

Even where the contact information (such as an email address) doesn't actually disclose the user's real identity -it might cause other users to match two online pseudonyms as being one and the same person.

I a

It becomes difficult to withdraw consent from other members or specific members to contact you directly -as they now know your real- world contact details.

It causes significant disruption to a user to change real-world contact details such as phone number as these details are often relatively long-term static contact details and known to many other contacts e.g. all their friends, business contacts, banks/utilities etc may need to be informed of their new number and/or email address.

Therefore many community members often deliberately choose to compartmentalise their (multiple) online personas and their real-life identity. By comparison, it is easier to change online pseudonym within one community in case of problems as there a fewer knock-on effects on their other identities in other communities and in the real-world.

A number of solutions already exist to maintain the privacy of anonymous users. One of the oldest most well known is the use of box numbers in personal adverts in newspapers and magazines. The advertiser can receive mail from correspondents without disclosing his or her address entrusting the publisher to forward any received correspondence and similarly forward replies. A more modem version of this solution is to assign users voicemail boxes which other users can dial in to and leave messages.

Most online communities have applied similar principles to anonymous online communication between their members. The community software solution knows the real email addresses of their membership and acts as the middleman forwarding emails between members. The sender's real email address in the email headers is substituted with their community identity or a specific message tracking id before forwarding the message and the reply-to' email header address is altered to direct the reply back to the community email platform so that anonymity can be maintained in each direction.

The middleman email address solutions can offer some further advantages to its users by helping to prevent abuse. For instance, the solution can check for viruses distributed by email, can scan email for offensive or inappropriate language and can take heed of membership complaints (e.g. a user could ask not to receive further communication from specific pseudonyms). Many communities also support online "chat-rooms" for real-time textual communication where users can engage in either group chats with everybody seeing what other are writing and can break-out in to private chats.

Whilst email and chat room solutions may provide adequate communication for online communities when accessed via PCs, their use does not easily map to mobile devices such as mobile phones. Communications are normally only possible when the user is next to their PC and logged in to either the community or their email. However email and web chat-rooms are often not the users' first choice of communication means from a mobile phone due to the relatively small screen and limited text entry capability.

Some communities also make use of telephony voice-based chat rooms -where members call a (jremium rate) number and are connected via a conference bridge switch in to a common call. It is also possible to break out in to private chats. However such services differ from the invention in that they only enable communication between customers that have dialled in (or when online have logged in); the aim of this invention is to allow specific direct contact between the membership even at times when the user isn't actively connected to the community website or telephony bridge.

Another problem in enabling telephony services for an online community is that unlike PC communication methods (email, web chat), telephony services are traditionally charged for on a per-event basis and usually paid for on the basis of calling-party pays. Therefore it may not be economic for customers to remain connected for long periods or for the online community to absorb the costs if they have to trigger outgoing calls. One commonly user solution for this is to use a technique known as reverse SMS billing. The user sends an SMS text to the online community system shortcode, which in turn replies with an SMS containing another shortcode or IJRL from which they can initiate the communication with another member. The customer is billed by the online community submitting a charge to their operator along with the reply SMS text; the operator infers from the fact their customer initiated a SMS text out to the community that they gave their permission. However the solution is not ideal; firstly reverse SMS only caters for single event billing events (i.e. no

A

per-second billing or repeated use), SMS text is not necessarily real-time delivery, and it breaks the user experience as the user has to suspend their handset browser experience (on the community website) whilst they complete sending an SMS and receive the reply.

One aspect of mobile phones is that the owner is effectively online at all times whenever/wherever they carry their phone thereby increasing their availability for real-time communications with other members of communities. Whilst it is expected that users will want to manage their availability and who is allowed to contact them via their membership of each online community, it is also expected that users may call up their operator to manage their availability centrally (for instance to block call from another abusive member) or to set availability rules that apply to all online communities. In these cases, the operator call centre agent is unlikely to have direct access to each online communities administration functions and so this invention also anticipates that the LC architecture can impose its own rules on blacklisting and availability.

On the other hand, it can be appreciated that if the community is made up of a pre-defined user group, the question of maintaining anonymity does not arise. Therefore the LC architecture of the invention also allows voice conferences between such groups of buddies or family members without requiring registration to the community.

SUMMARY OF THE INVENTION

it is an aim of this invention to enable communication between members of online communities via mobile networks and in particular to enable the use of mobile-centric communication modes such phone calls, video calls, and texting other members without disclosing the users' phone numbers.

It is a further aim of one embodiment of this invention to enable mobile-centric communication without tight integration to the mobile operator's billing platform for end-user billing. The proposed architecture maintains the concept that calling-party pays (for services where charges are applicable) by causing the user to initiate the call. This is done by assigning a temporary number to the call and include a click to call' link in the webpage shown on the mobile phone It is a further aim of this invention also to prevent the accidental unintended disclosure of personal details. One example of this is that if calls were directed to the user's real-world voicemail box, it is likely the greeting message could reveal the called party's real identity.

Therefore this invention proposes particular procedures for establishing communication to prevent specific service interactions (such as forwarding an incoming online community call to voicemail).

It is a further aim of this invention to provide an operator-administered control point between the online communities and the operator's communications network domain. This would allow the operator to block or enable use to or from particular MSISDN, scan messages based on the operator's usage policies and criteria and to protect against fraud.

It is also preferred that the invention can allow conferences between a predefined and known group of user, without requiring such pre-defined user to register with a community.

However, prior group management will be necessary for such conference to be allowed by the invention.

Accordingly the present invention relates to a system for providing telephony services for members of a community via a mobile communication network, the system comprising a community domain (CW) provided for storing and managing details of community members, a connectivity domain (LC) for providing functionality for implementing the telephony services between a plurality of members of the community, and a network domain for providing a network to route said telephony services implemented by the connectivity domain (CW) between said plurality of members, wherein an intermediate identifier capable of being dialled is assigned to each telephony service by the system, said identifier being associated with one or more of said plurality of members via the network provided by the network domain.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 describes the overall logical and connectivity (LC) architecture which provide the functionality of the present invention.

Figure 2 describes the information flow for one-to-one voice/video calls according to the present invention.

Figure 3 describes the information flow for one-to-one SMS/MMS according to the present invention.

Figure 4 describes the information flow for one-to-many call conference.

Figure 5 describes information flow during a conference call between a pre-defined group of known users.

DETAILED EXPLANATION OF TILE EMBODIMENTS OF TILE INVENTION

The present invention enables community website service providers the capability for members within that community to initiate anonymous voice calls, video calls, and SMSfMv1S communications to other members within the same community. Furthermore for video calling it is desirable that the solution should also support a one to many call model where a single member of the community may opt to provide a "show" that multiple participants can dial in and view. The invention may be best implemented as an end-to-end service design, identifying the impacted systems and interfaces. The implementation of the LC architecture of the present invention does not require a tight integration with an operators charging platform and also ensures that the call costs are charged to a CW user that initiated the call.

Architecture: The invention is implemented using a logical and a connectivity (LC) architecture as seen in figure 1. This LC architecture impacts and hence requires work within several different domains. The functionality of the LC architecture is supported on hardware instances such as server system supporting non-supplier specific Operating systems. In the current invention three domains of the architecture are discussed. However the invention is not to be considered as restricted to the described domains.

In the following description, the LC is described in terms of implementing it on an audio or video conferencing bridge platform which connects users to each other by trombone-ing the two call legs (incoming call with the outgoing call). However it will be appreciated by those skilled in the art that it would also be possible to implement LC connectivity directly in the communication networks via intelligent network (IN) signalling or implement the LC for voice-over-IP network by integration the LC functionality with a SlIP gateway.

We will now describe the LC in terms of using a commercially available audio or video conferencing platform or soft-switch modified to include the additional software needed to manage the logic described. The modified platform is also likely to include additional functionality such as text-to-speech and text-to-video engines that would be needed to inform the recipient on the pseudonym identity of the incoming caller via voice anc video calls and a text-based scanning engines to vet messages for inappropriate languages, spamming, etc. At a high level, three domains may exist in the LC architecture. They may be identified as a logical connectivity domain (LC domain), a community website domain (CW domain) and a communication network domain. The LC forms an important aspect of the working of the present invention. The architecture should be made capable of scaling to support the requirements of each community website.

The LC domain is most likely connected to the communication domain via El's carrying SS7 traffic. However for more advanced interactions with the communication network domain it may be desirable also to establish a packet-based IP connection too (not shown) using either the same El connection or an independent Internet connection. This connection may for instance be needed to seek additional information associated with a MSISDN such as age-verification status, geographic location information, etc. Also many communication domains networks accept SMS text via IP-based interfaces.

One of the concepts maintained in this architecture is the calling party pays principle of telephony-based services as it is still the calling party that initiates the communications.

However as described below the LC still triggers a second voice or video call (to the called party) before connecting the two calls together and this would normally incur telephony charges. Therefore this invention would typically be implemented by the LC owner purchasing El connectivity with the communication network domain(s) as a Leased Line' for which the commercial terms usually incur a fixed yearly rental fee rather than charges based on the number or duration of calls.

The LC domain is a logical node that enabled the high level functionality as given below: -Enables the functionality associated with the connection and conferencing of voice/video calls, and forwarding and delivering of anonymous messaging.

-Defines and develops an application programming interface-API that the third party community websites can use in order to utilise the anonymous voice/video/SMSIMMS functionality associated with this solution. The API could be proprietary to the LC or could for the most make use of industry-standard APIs such as those defined by The Parlay Group (www.parlay.org).

-Provide a generic API that allows a CW to send SMS messages to a group of subscribers identified by their MSISDN. This API should allow for sending of generic text SMS messages in addition to "address book" messages that shall be correctly formatted by the LC architecture solution based on the handset ID provided by the CW. This functionality is seen as desirable in order to avoid each CW having the capability to send SMS.

-Optionally provide detailed reporting on all calls & messages with the appropriate status.

The reporting should be in sufficient detail to allow for revenue sharing between community domain, the LC domain and 3 Domain if desired. This would include at a minimum the following statistics; -Inbound messages, split by short code, network, and community -Outbound messages, split by SMS account and by community -Inbound calls, split by short code, network, and community -Outbound calls, split by network and by community -Provide appropriate SMSIMTMS moderation based on editorial guidelines provided by 3 on non Adult-Verified (AV) customers.

-Block specified MSISDN from using the system according to rules specified by the owner or operator (blacklisting, time of day rules, age verification etc.). It is likely that this will also require a user interface to allow the LC owner or operator administer the rules manually.

-Perform media conversion to convert the textual pseudonym provided by the CW to a voice prompt for audio call, and voice andlor video prompts for video calls.

Alternatively the CW would provide audio and video clips to the LC. Some CW websites make use of a thumbnail image for each community member, in which case the image could be passed to LC for inclusion in the video call prompt or in MIMS / email messaging.

-Optionally perform further queries with the communication network domain's systems. For example, the LC could administer time of day rules based on the actual location and hence time zone of where the user is instead of just relying of inferring the time zone from the home country code part of the user's MSISDN.

The implementation of the community Website Domain node as a website server or website provider is required to be modified according to the specification of the LC domain in order to participate in the present invention. Existing or start-up community websites that wish to take advantage of the new capability need to introduce the following functionality: -Update the website that they host to hold individual user preferences for contact using new functionality. This will typically be based on initiating user, time of day and type of call. (e.g. Only users in my Buddy list can contact between 5PM -> 10PM on voice call only)

I

-Define and develop to the API outlined by the LC domain according to the present invention.

-Provide detailed reporting on all calls and messages initiated with appropriate status.

-Conform to the Adult Verification guidelines. This requires that non age verified callers can NOT initiate anonymous voice call service nor book as a host of or a participant of a one to many video call.

-Upgrade or Introduction of a revenue sharing system based on the number of voice/video/SMSTMIvIS minutes/messages sent through the CW. Such a settlement system will depend on information sent by the LC system and may be used for sharing revenue between the CW and the network domain as a result of voice/video/SMS/MMS generated through the CW. Where applicable, the system must be able to support imbursement of individual CW members based on information supplied by LC domain (e.g. for receiving calls or hosting shows) -Upgrade/Introduction of the CW user profile management system to allow for setting up of an individual user contact preferences with respect to voice/video/SMS/MMS contact settings. In such a requirement it is inferred that any preference there-within expressed by an individual CW user should also be adhered to. i.e. if user has stated that he wishes not be contact by X at time Y, then the CW should police this.

-Where applicable to the CW, the introduction of product pages pertaining to setting up of point to multipoint shows, capturing details of the users expressing an interest in the "show" and alerting them once the host of show is online, along with conformance to the relevant point to multipoint API related to this capability.

The third domain is the communication network domain. This may be a telephone network service provider's server such as a mobile telecommunication service provider. For implementing the invention the following capability will need to be introduced to take advantage of the new functionality; -Creation of a new proposition to for subscribers wishing to have "in bundle" LC voice/video minutes or inclusive LC SMSIMMS messages.

-Optionally record appropriate reporting for settlement purposes with LC domain and CW domain for revenue share purposes. For purposes of this design all charging shall be done by the communication network provided based on individual short-codes for each community. It is for future specification as to whether different shortcodes shall be used per service (i.e. voice/video/SMSfMMS).

-Drop charging shortcodes and first x seconds free shortcodes shall be made available for use within this project.

-Creation of dedicated voice/video connectivity towards LC domain.

User Experience The user experience of the functionality implemented by the above-described domain can be described as follows: Service Registration:CW may wish to send members of their community who use LC a welcome text. Ideally CW also sends a message to the members' mobile phones containing the CW's contact details of such as the CW caller line identity (CLI) and email address.

Modem implementations of SMS (see 3GPP document 23.040) allow vCards (defined the Internet mail consortium -see http://www.imc.org/pdi/) to be received by the mobile phone such that the user can easily add the entry to their phone's contact list. The advantages is that once CW's contact detail are added to the mobile phone address book, all future incoming messages and calls from CW membership will be displayed to the recipient as incoming communications from members of that community without the recipient needing to recognise the incoming number as CW's.

I

Placing a call: User B may previously setup her video call options with CW to allow for user A to make a Video call to her. A video call client will open and User A is connected to User B in due course if User B agrees to accept the incoming call.

If call is accepted by User B, the video conferencing begins. If User B does not accept the call, User A is diverted to a message displayed in the video client telling them that User B cannot take the call at the moment. Once the video call is finished, User A's handset display will revert back to show either the handset standby screen or the webpage they last visited (and initiated the call from) depending on the specific handset model's behaviour. In the preferred behaviour where the browser is still open in the handset, the webpage may be updated by CW to reflect new information (e.g. how long the call last, what charges where incurred etc). Webpages can automatically update by a number of means known to those skilled in art including use of page scripting, use of the HTML Refresh mechanism or the use of the Open Mobile Alliance IP-Push notifications.

Receiving a call: User B s handset displays in incoming call from the community website. If User B declines the call at this point, she is sent an SMS, email or MMS with a link to User A s CW profile so she contact him if she chooses to do so later. If User B answers the call the LC domain displays a message asking whether she wants to accept or reject a call from User A. If no response is received the call may implicitly assumed to be rejected. If User B accepts the call the video-conference with User B commences.

One of the benefits of demanding an explicit agreement from the User B is that should the call from LC have been redirected to Voicemail or Video mail in the case of a video call, then whilst the Voice/Video-mail platform will accept the call, it will not respond to the cue from LC for a positive response. This prevent User B's privacy being accidentally compromised by User A hearing her real-world greeting message.

ImpJementation of information flow: The information flow for the LC architecture according to the invention shows the interactions between the various components/domains of the architecture and gives details of an example implementation's expected responses to the situations.

The service design provides a cost effective implementation of the end-to-end service requirements by minimising the necessary changes to the affected systems.

It is assumed that User A and User B have previously registered profiles with the CW. The CW has the capability to retrieve and store a verified MSISDN for users. The CW has the capability to retrieve and store the adult verification status for any user and for registering on CW for Anonymous Voice/Video/SMS/MMS calling. Furthermore, if desired LC can query the communication network domain for age-verification status if known. In many cases, the age-verification data from telephony operators may be more reliable than the online community's data given that telephony contracts are often tied to real addresses and banking details for the purposes of the contract and billing.

A CW must add to their user profile management system pages to allow for setting up of an individual's user contact preferences with respect to voice/video/SMSIMMS contact settings.

One to One Voice/Video Call: Figure 2 illustrates the high-level flow for one to one voice/video calls.

Figure 2 assumes a context wherein user A is browsing through profile of user B and sees that User B allows voice/video contact. There will be URLs encoded on this page that will trigger the relevant form of communications e.g. voice call, video call etc. Dependent on the model adopted by CW, if user B has setup his "contact me" profile not to allow user A to contact her, then the User A may not actually see the contact me options at this point. Furthermore, if either user is NOT age verified the option the age verification rules outlined within this document must be adhered to, meaning that certain types of calls will NOT be offered.

Clicking on the contact voice/video call URL shall cause the CW to initiate the API described below towards the LC platform to "reserve a call". This API call shall at a minimum contain the following parameters -Transaction ID (Will be used as unique identifier for all transactions related to this API call)

-CWID

-Type of call being requested (voice / video) -MSISDN User A -MSISDN User B -CW Username A & URI to CW profile -CW Username B -Charge per minute or Short-Code ID.

-Maximum call duration -Optionally media files such as an image of User B, voice and video recordings.

The LC architecture should implement an LC solution that checks the MSISDN A /CW Username A against the operator definable blacklist and reject the call with an appropriate error code (user barred) if a match is found. If no shortcode has been provided, the LC solution should identify an appropriate shortcode for the charge per minute rate requested and return the appropriate shortcode to CW so that it can embed it in the "click to call" link.

The LC solution shall wait for an operator configurable amount of time for an incoming call from MSISDN A. If this process times out, an error identifying a time out should be returned via the defined API back to the CW and the reservation for this call cleared.

The LC may additional impose additional rules for blacklisting calls -for example if LC is also aware of the age of MSISDN owners from the age-verification information held within an operator, it is may choose to blacklist some CW services from customers that do not qualify. If may also choose to block calls based on predetermined rules User B has requested are enforced by the LC owner or operator including specific blocking ofnuisance members' MSISDNs (in this case MSISDN A), time of day rules, rules based on geographic location, etc. Once the LC solution indicates that the call has been successfully reserved (and if appropriate a shortcode has been passed back), the CW will display a page with a "click to call URL" that will initiate a voice/video call to the shortcode number indicated as mentioned above.

Many mobile phones support a common syntax for including a clickable link in a web page that triggers a voice or video call. For example including many 3G mobile phones support To include a clickable voice call link with assigned short-code 12345 <a href="tel:12345">Click here to call User B</a> To include a clickable video call link link with assigned short-code 12345 <a href"tel: 12345;call-type=video">Click here to video call User B</a> Once the user A clicks on this URL, it will trigger the phone to make a call to the LC shortcode number and the LC solution will receive a call from MSISDN User A. It should answer the call and play a configurable message indicating the call to CW username B is being connected and out dial the appropriate type of call (voice/video) to MSISDN B. Upon receiving an answer message from MSISDN B, The LC solution should play a configurable message to user B, identifying the CW and CW username A, and wait for active indication that party B is happy to accept the call. This will be in the form of a key press. The length of time to wait for this should be configurable by the operator. LC may invoke a text-to-speech for convert the name of CW and CW username A in to audio for playback to user B. For video calls additional the name of CW and usemame A and optional images may be included in the video presentation to user B. The LC solution implemented by the invention should send a configurable message to user A if no key press is received indicating user B is currently not willing to accept the call, end the call and return appropriate indication of this to the CW via the defined API. The LC solution shall additionally send an SMS, email or MIvIS to User B containing the URI to the CW profile of User A and configurable operator text Upon user B accepting to take the call, the LC solution should conference user A and user B up to the maximum length permitted either via the maximum call duration in the initial API call request, or any ICSTIS requirements (www.icstis.org.uk).

Upon user B accepting to take the call, the LC solution shall additionally send an SMS to user B containing the URI to CW profile of User A and configurable operator text (e.g. you have just taken a call from user A. For ways to contact him/her click here..). This SMS should also contain information on how to blacklist user A. On termination of the call LC solution should pass back to the CW via the defined API, the call status (not answered, successful, not accepted, other error) and the duration of call. At no point in the above transactions should the calling party ID (MSISDN) of either party A or B be presented to either party One to One SMSIMMS Figure 3 illustrates the high-level flow for one to one SMS/MMS interaction Figure 3 assumes a context wherein user A is browsing through profile of user B and sees that User B allows SMS/MMS contact. Note that dependent on the model adopted by CW, if user B has setup her "contact me" profile not to allow user A to contact her, then the User A may not actually see the contact me options at this point.

Once the CW has checked that, as per user B contact preferences, user A is allowed to contact her, CW shall initiate an API call towards the LC platform to "reserve the SMSIMMS communication".

This API call shall at a minimum contain the following parameters; -Transaction ID (Will be used as unique identifier for all transactions related to this API call) 5-CWID -Type of messaging being requested (SMSIMMS) -MSISDN User A -Adult Verification Status of User A -MSISDNUserB -Adult Verification Status of User B -CW Username A & URI to CW profile -CWUsernameB -Charge required or Short-Code ID.

The LC architecture of the invention implements a solution wherein this LC solution should check the MSISDN A /CW Username A against the operator definable blacklist and reject the call with an appropriate error code (user barred) if a match is found.

If no shortcode has been provided, the LC solution should identify an appropriate shortcode for the charge requested, make an internal reservation of this request and pass back the shortcode via the API back to the CW.

If MSISDN A has an existing SMSIMIMS reservation request, the LC solution will overwrite the previous pending request with this request. The LC solution shall wait for an operator configurable amount of time for an incoming SMS/MMS from MSISDN A. If this process times out, an error identifying a time out should be returned via the defined API back to the CW and the internal reservation cleared.

Furthermore if either party is NOT age verified then the guidelines relating to moderation of the SMSIMIMS shall be adhered to.

Once the LC solution indicates back to the CW that the reservation has been successfully reserved (and if appropriate, a shortcode has been passed back), the CW will display a page with a "click to SMSIMMS URL" that will initiate an SMSTMMS to the shortcode number indicated as described previously (along with various other fields pre-populated).

Once the user A click on the URL, he will have the opportunity to create the SMSIMIMS on the phone and send to the shortcode that has been pre-populated.

The LC system will then receive an SMS/MIvIS from MSISDN User A, the LC solution should send out an SMS/MMS to MSISDN B changing the From Field to be the User-A CW ID adding the CW UIRI profile of User A to the message. Furthermore moderation appropriate to the AV status of the users shall be carried out. This may involve passing out to a third party for manual inspection. If any rules are deemed to have been broken the message shall be discarded and an appropriate error passed back to the CW.

As with the previous one to one voice/video call example further rules for blocking communication may be invoked by LC on behalf of user B -for instance based on barred communication from specified members, time of day rules and geographic location. The LC may also choose to delay the delivery of messages -for instance to a more sociable time of day or in the case of MIMS to reduce User B charges for receiving data whilst roaming abroad.

On successful delivery of the SMStMIv1S to user B, the LC solution should pass back to the CW via the defined API indication of this delivery and delete this "reservation reference".

One-to-Many Voice/Video Call Figure 4 described the information flow for a One-to-Many Call Conference. This could be voice calls or video calls.

Figure 4 assumes a context wherein user A wishes to provide a presentation or a "show" and browses the relevant section of the CW to setup such a show. Once the CW has checked that all required fields have been completed correctly, the CW will check to see if the user A is not on "barred list" and is appropriately age verified. If all checks are completed successfully the CW shall initiate an API call towards the LC domain to "reserve the show".

This API call shall at a minimum contain the following parameters: -Transaction ID (Will be used as unique identifier for all transactions related to this API call)

-CWID

-Type of conference being requested (voice/video) -MSISDN A of hosting user -CW Username A of hosting user -Scheduled time of call (Absolute or Relative) -Charge per minute / Shortcode -Maximum call duration If the Scheduled time is greater than an operator configurable time, outside of the current time, LC architecture implements a solution to reject this call with appropriate cause. If MISDN A has currently booked greater than an operator configurable number of shows, the LC solution should reject the call booking.

If checks are completed successfully LC should store the details of the requested call and pass back to the CW a unique call booking reference number confirming that the reservation request for the call has succeeded. This call booking reference will be used for all future communications related to this call booking, including the adding of users wishing participating in this call.

The CW can now start to advertise the time and description (as input by user) of this show, allowing other CW members to register interest in this show. If another CW user B registers interest in this call, the CW should store the MSISDN B of CW user B against this show and inform the user that they will receive reminder of the details of the call, and when the host is ready to host the show.

At an operator configurable time, Y minutes, before the scheduled time of the call LC shall send an SMS to host user A indicating that they need to dial into a predefined shortcode to setup their show. The shortcode for the host should have a "one off' drop charge. The LC solution should wait for an operator configurable time for the host user A to dial in. If the host does not dial in the LC solution should allow the option to resend the SMS an operator configurable number of times before the show time starts. If the host user A does not dial into the LC platform, after an operator configurable number of minutes after the scheduled call time, the LC solution should pass back to the CW an indication that the show has been cancelled due to non show of participant. LC shall send an SMS to the host user A with operator configurable text indicating this failure to show.

The CW should update the show details page to indicate that the show has been cancelled or the CW can just remove it and delete the associated list of users who have registered an interest. The CW should also store the fact that the user has booked a call and failed to show hence allowing if required punitive action to be taken, or placing user A on a "barred list" for X days hence stopping CW user A from booking shows.

Once the host user A dials into the predefined shortcode, the LC solution should play out a message indicating that they will be informed when users dial into the show. At the same time, the LC platform shall pass back to the CW indication that the host of the show is now online, and pass back the unique call reference ID to the CW.

The CW should update the show details page to indicate that the show is "now showing" and update the show details page with a link where users can opt in to view the show. The CW should now utilise the LC API defined below to inform all users who have registered an interest in the show that the host is online and ready to accept the call.

For such a purposes, the LC solution should provide an API towards the CW that allows at a minimum the following parameters to be passed: -Transaction ID (Will be used as unique identifier for all transactions related to this API call) -Call booking reference number -Free Text (e.g. Show details, URI to CW User A home/show page) -MSISDNs of interested parties (MSISDN-B, MSISDN-C etc) The LC domain shall log the number of SMS being sent against the call booking reference for possible charging reconsolidation and send out the free text field in an SMS to the MSISDN list. If the call booking reference is not valid an appropriate error shall be returned.

The LC solution should now be in a position to add "viewers" to this call.

Upon receiving the SMS informing her of the start of the show, user B may opt to click on the link in the SMS. This will send her to the show page for user A with the detail of the shown with a URL for joining the call. On joining, if the user is not age verified access to the show shall be denied by the CW (if the show is deemed as requiring age-verification).

The final user experience is documented in reference [1]. For every one to many call reservation, the LC solution should provide an API towards the CW that allows at a minimum the following parameters to be passed in order to allow users to be added to this one to many call reservation;(note that user B generically refers to any additional user being added to call) -Transaction ID (Will be used as unique identifier for all transactions related to this API call)

-CWID

-Type of call being requested (voice/video) -Call booking reference number -MSISDN User B -CW Username B & URI to CW profile -Charge per minute or Short-Code The LC solution should check the MSISDN B /CW Username B against the operator definable blacklist and reject the call with an appropriate error code (user barred) if a match is found. If no shortcode has been provided, the LC solution should identif' an appropriate shortcode for the charge per minute rate requested.

It may also be the case the show organiser user A wishes to prevent specific user B's from watching the show -for instance if they have been abusive or heckled excessively on previous shows. By administering the barred user list at LC in addition to checks performed by CW, the solution will also detect barred users that have registered multiple pseudonyms with CW or even at multiple CW as they can still be identified as having the same MSISDN.

CW and User A may also wish to bar user dialling in from specific geographic locations -for instance where the show's content is known to be offensive in certain cultures or countries or where user A does not own the content distribution rights. If the communication network can determine the position of user B's with greater granularity, it would also be possible to bar user dialling in from inappropriate premises (for instance from a school).

Once the LC solution indicates that the call has been successfully reserved (and if appropriate a shortcode has been passed back), the CW will display a page with a "click to call URL" that will initiate a voice/video call to the shortcode number passed back. Once the user B clicks on this URL, it will trigger the phone to make a call to the LC shortcode number and the LC solution will receives a call from MSISDN User B. It should answer the call and play a configurable message indicating the call to CW username B is being connected and out dial the appropriate type of call (voice/video) to MSISDN B If the LC solution does not receive an incoming call from MSISDN B for an operator configurable amount of time, an error identifying a time out should be returned via the defined API back to the CW and the reservation for this call cleared.

Upon receiving a call from MSISDN B, the LC solution should multiparty conference call in user B for this "show". A configurable message should be played out to user B indicating the CW and user who is hosting the "show". Once the user has successfully joined the show an indication should be shown to host user A of the fact that a new user B has joined -only the CW user ID of user B should be indicated. Since multiple people could be joining at the same time, this update may be in the form of updates every X seconds. Within this same update any users who have left the "show" since the last update should also be shown. This update page may be in the form of a rolling multi-page update if all the users who have joined/left the call cannot be displayed on one page.

On termination of the call for any reason (max time reached, host MSISDN A hung up etc.) the LC solution should pass back at a minimum the following information Transaction ID which will be used as unique identifier for all API transactions related to this multicall and but does not have to be unique between CW): -MSISDN A of hosting user -List of MSISDNs that dialled into the "show" with length of time on call.

This information may be stored by the CW in order to allow for revenue sharing purposes with the host of the show. At no point in the above transactions should the calling party ID (MSISDN) of party A or any participant in the show be presented to one another Conference calls within a non-anonymous user community Figure 5 describes information flow when calls are initiated by and for members of a non-anonymous community.

A similar Logical Connectivity architecture as detailed in the above instances can be used, however with no user registration requirements. This type of call initialisation is not used unless the conference calls within are to be implemented within a community of already known users (eg a community of a group of friends, family members). In such cases there is no need to maintain the anonymity of the users.

Therefore an alternate embodiment of the present invention could be a service provided by a network operator to allow conference without the requirement of registering with a community. However, prior group management is required. The buddies, friends and family may be on-net' i.e. having accessibility to the communication network from their terminals in an active mode or even off-net' customers i.e. having no active connectivity to the communication network from their terminals.

The implementation on non-anonymous conference calling is similar to the joining of show group call (one-to many conference as disclosed above), using the LC architecture of the present invention. However in this case in this case rather than the conference being among members of an online community, the participants of the conference are known to each other in the real world. Therefore they do not require alternate id's using a community.

The calling party manages the group allowed for the conference by selecting a group of members to participate in the call. This id's that can be used for selecting or pre-defining the group can be the MSISDN's or e-mail id's etc. of the parties. The managed group can be identified by a group id, which may be either allocated by the network or selected by the calling party.

Once the group is defined, the calling party send a message to the parties network operator that stores these details on the networks LC platform.

When the calling party or initiator wants to initiate a call with this predefined group, the calling party indicates via a message to the LC that a conference is to be initiated. The LC solution implemented by the invention then sends an indication in the form of an intermediate sort code that can be dialled from a mobile terminal to invite other members of the predefined group to a conference voice or video call implemented at the LC architecture.

Security features in the form of PIN numbers etc may be used for each party to be able to identify that it is that know person who attends the call On dialling the Id, the calling parties triggers the LC solution to send a message to the group members, indicating the initiators name and the id or sort code that can be dialled to join the conference.

The group conversation ends with all the parties hanging up or disconnecting the conference call. In future, if a calling party within the group wishes to dial the same group, the group id can be sent to the LC architecture.

This embodiment is suited for conversations between closed user groups of friends and family, wherein it is not necessary for the members to be of the same network or registered with any particular online community.

Reporting capability function of LC architecture The following set of reports are configured to be available from the LC solution implemented by the invention: -Daily reporting shall be available on time of day, calls made, length of calls, calls failed, calls blocked.

-Weekly reporting shall be available on time of day, calls made, calls failed, calls blocked.

-Monthly reporting shall be available on time of day, calls made, calls failed, calls blocked.

Graphs may also be provided to track all the key indicators outlined above.

Interface Dependencies The LC architecture implementation according to the preset invention is associated with communication across many interfaces. The interface for the API shall be secured either via use of HTTPS or VPN links. The interface dependencies for the working of the invention are the LC -SMSC (SMS centre) interface foe sending! receiving all SMS/MMS, the LC- MSC (message service centre) interface that may be a dedicated interconnect and the LC -CW interface which may have a secure API specification.

Claims (14)

1. Claims: 1. A system for providing telephony services for members of a

   community via a mobile communication network, the system comprising a community domain (CW) provided for storing and managing details of community members, a connectivity domain (LC) for providing functionality for implementing the telephony services between a plurality of members of the community, and a network domain for providing a network to route said telephony services implemented by the connectivity domain (CW) between said plurality of members, wherein an intermediate identifier capable of being dialled is assigned to each telephony service by the system, said identifier being associated with one or more of said plurality of members via the network provided by the network domain.
2. 2. The system as claimed in claim 1 wherein the community is an online website community and said plurality of members are registered with the community website and wherein said telephony services are requested and accessed by registered members on a mobile terminal connected to the network provided by the network domain.
3. 3. The system as claimed in claims 1 and 2 wherein the community domain (CW) is arranged to store real world details and pseudo community profile details each community member and to mange association of both details such that only the pseudo details are disclosed to other members of the community.
4. 4. The system as claimed in claim 1 to 3 wherein said intermediate identifier is assigned by the connectivity domain for each telephony service request by the members, said identifier associated with the real world telephone number of one or more members
5. 5. The system as claimed in claims 1 to 4 wherein said identifier is implemented using a shortcode provided by the network domain for routing the telephony service to and from the associated members telephone, thereby not disclosing the real world telephone number of the members.
6. 6. The system as claimed in claim I wherein said community is a pre-defined group of users whose real world identities are known to each other.
7. 7. The system as claimed in claim 7 wherein the telephone numbers of said users are known to the user initiating the telephony service, and wherein the intermediate identifier is associated to said telephone numbers.
8. 8. The system as claimed in any preceding claim wherein the telephony service is a voice call
9. 9. The system as claimed in any preceding claim wherein the telephony service is a video call.
10. 10. The system as claimed in any preceding claim wherein the telephony service is an SMS message
11. 11. The system as claimed in any preceding claim wherein the telephony service is an MMS message.
12. 12. The system as claimed in claims 8 and 9 wherein the telephony service is a conference call.
13. 13. The system as claimed in claims 10 and 11 wherein the telephony service is a conference chat
14. 14. The system as claimed in claim I wherein security preferences are implemented in the community to avoid telephony services with certain members.