AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION Innovation Patent Applicant(s): Enterprise Glue Pty Ltd Invention Title: DATA ACCESS SYSTEM The following statement is a full description of this invention, including the best method for performing it known to me/us: 2 DATA ACCESS SYSTEM Related Application 5 This application is based on and claims the benefit of the filing date of AU patent application no. 2009200895 filed 6 March 2009, the content of which as filed is incorporated herein by reference in its entirety. 10 Field of the Invention The present invention relates to a system for providing data access, and is of particular but by no means exclusive application is providing data access to an external database via a social networking website. 15 Background of the Invention In some existing approaches, a user of mobile telephony services who wishes to view his or her account balance can log on to web site of his or her telephony service provider or carrier, or use 20 a SMS-based application loaded on the telephone handset or a SIM Toolkit application on the telephone handset with the relevant functionality. In other existing approaches, the account balance can be ascertained by calling a call centre maintained by his or her service provider's or telephone an interactive 25 voice response system. Similar steps are commonly required to purchase and redeem mobile telephony credit or to pay bills for mobile telephony services. Commonly, the user is a customer of multiple service providers 30 (such as mobile telephony, fixed telecommunications, banking and utilities), so may wish to access multiple accounts via the aforementioned channels, a separate channel being provided by each service provider and - in some cases - class of service. 35 Consequently, users that wish to view all their service provider bills, view all their respective service account balances or settle these accounts must generally employ multiple channels 3407673.1 (GHMatters) P77111AU.2 31/05/2012 3 (including web sites, interactive voice response systems and call centres) as they have service providers (which in any event is contingent on each service provider's providing such functionality). If online, the user must leave his or her 5 homepage and either use other transaction technologies (e.g. phone, SMS) or visit external (non-homepage) websites to effect the desired transaction. Summary of the Invention 10 According to a first broad aspect of the present invention, therefore, there is provided a data access system for accessing data on an external computing system via a host computing system, comprising: a registrable application, adapted to be registrable 15 with the host computing system as a registered application; a rendering engine for rendering a display of the host computing system in a manner compatible with the host computing system; a controller adapted to retrieve user data pertaining 20 to users of the host computing system from the host computing system (typically via the registrable application), to pass the user data to a user database and to control the rendering engine; and a transaction management layer for mediating data 25 transfer between the controller and one or more external computing systems. In a particular embodiment, the user data is stored on the host computing system in the form of user profiles. 30 In a particular embodiment, the controller constitutes the registrable application, and hence is registrable with the host computing system as a registered application and adapted to retrieve the user data from the host computing system aLnd pass 35 the user data to the user database. It will be appreciated by those skilled in the art that each of 340773_1 (GHMatters) P77111 AU.2 31105/2012 4 the components of the system may be provided as software, hardware or firmware, or as a combination of these. In addition, a component - such as the controller - may itself be provided as a plurality of modules. Furthermore, the system may 5 comprise a hardware system running applications that provide or constitute the features of the system, or as software executed or executable on a computing system. It should also be noted that the various components of the system may be distributed, including by being located in a plurality of countries. 10 The user database may be initially unpopulated. The user database may initially comprise only the software for maintaining the user data that will subsequently populate the user database. 15 The display of the host computing system generally comprises a display of a user computer of a user of the host computing system, such as a personal computer with an internet browser used to access a remote website provide by the host computing 20 system. The host computing system typically has an interface that, in some embodiments, allows users to interact with each other. 25 The controller may initiate data transfer between the controller and one or more external computing systems based on the user data. Also, the user data of the host computing system pertaining to a 30 plurality of users of the host computing system may be linked, such as by including in one or more sets of user data links to one or more other sets of user data. For instance, in an embodiment, the user data is linked so that 35 a user can view user data of another user, or in another embodiment, the user data is linked so that a user can initiate a transaction relating to another user. 3407673.1 (GHMatler) P77111 .AU.2 31/05/2012 5 In one particular embodiment, the system is operable by a user of the host computing system to conduct transactions with the external computing system according to at least some of the user 5 data. The host computing system typically provides the aforementioned functionality in the form of a Web 2.0 Application or a social networking website where the interface is a web based interface 10 which is accessed via the internet, and links are provided between users' profiles, categorised by some predicate (e.g. user A is a "friend of" user B). Examples of host computing systems are the FaceBook (trade mark) and Myspace (trade mark), websites, in which the interface is an HTML based interface 15 accessed via the internet, applications - such as that provided by the system of this aspect of the invention - can be registered with the main site by registering them through the FaceBook or Myspace site and, once registered, can render information to the interface using a custom mark-up language 20 called (in the case of FaceBook) FBML. An application that is registered in, for example, FaceBook is assigned an application key and a secret key that the application can use to access user information, and the location of the application (such as in the form of a URL) is passed to the registering application (in this 25 example, FaceBook) so that the registered application can be found. Hence, applications, such as that according to the present invention, can access information from the user profile using a custom REST based API. 30 According to this invention, therefore, service provider transaction functionality can be provided within a user's chosen social networking site such as FaceBook or Myspace, so that the user can manage their accounts while continuing with their social networking and other activities, without using other 35 transaction technologies or leaving their primary sites. Interest and registered users of social networking websites and 3407673.1 (GHMatters) P77111 .AU.2 31/05/2012 6 other Web 2.0 sites are growing at a rapid rate. These social networking and personal expression websites are particularly popular with youth as a way of expressing themselves, sharing their personal lives in a controlled manner with their friends 5 and family, and making new friends. Many users visit these sites several and in some cases many times a day, and regularly update their content with pictures, videos, blogs, opinions and so forth. Many users actually use these web sites as their homepages and point of presence on the Internet. 10 Though not exclusively, youths are also significant users of mobile phone services, and many of these youths are users of prepaid mobile services, although the proposed invention is equally applicable to postpaid mobile phone subscribers, fixed 15 and mobile broadband subscribers, fixed line subscribers, cable and satellite pay TV subscribers, and subscribers of more than one of these telecommunications services, where they consume these services and either pay for them as they go or pay for them in arrears. This concept can also be extended to financial 20 services and utilities for presenting billing, invoicing and customer alerts directly to the personal online space of their customers. In particular, many youths spend an increasing amount of time on 25 these Web 2.0 or social networking sites; various embodiments of the present invention allow such users to gain access to their mobile phone account balances, to top-up these accounts, to give credit to friends and to purchase credit, without leaving their personal web pages. This is more convenient, more efficient and 30 compatible with the entire concept of having their own personal space on the Internet, and compatible with the types of social interactions which occur on these types of sites - especially sending each other gifts (which in the case of mobile services can be applying credit from your account to that of a friend). 35 According to the present invention, such balance enquiry, balance top-up, bill payment and voucher purchase functionality 3407673.1 (GHMatters) P7711.AU.2 31/05/2012 7 becomes in effect another application that a subscriber on the relevant social network site can add to their profile and can share with friends. 5 For example, in Facebook, a balance enquiry and top-up application is presented - according to one embodiment of the present invention - as a box that is added to a user's profile. According to this embodiment, the user can - in effect *- use the website to tunnel into the relevant service provider's back 10 office (e.g. customer relationship management, billing, payments gateway or network elements) to retrieve the relevant balance information or to apply a payment to a specified account. In this embodiment, giving credit (i.e. by one user to another) essentially comprising a withdrawal from one user's account and 15 a deposit into another user's account. This tunnelling involves traversing the relevant service provider's security infrastructure and connecting to the relevant back-office system or systems. 20 The system can carry out the necessary messaging, protocol conversion, data formatting (bi-directional) and so forth to ensure that the relevant front-end (Web 2.0 application or social networking site) does not have to understand the idiosyncrasies of the specific service provider's back-end 25 systems, or the specifics of the communication mechanism, while still being able to access these back-end systems and to transact with them. According to a second broad aspect of the present invention, 30 there is provided a data access method for accessing data on an external computing system via a host computing system, comprising: registering a registrable application with the host computing system; 35 retrieving user data from the host computing system with a controller; passing user data from the controller to a user 3407673_1 (GHMatters) P77111.AU.2 31/05/2012 8 database; controlling a rendering engine configured to render a display of the host computing system in a manner compatible with the host computing system with the controller; and 5 mediating data transfer between the controller and one or more external computing systems with a transaction management layer. In a particular embodiment, the method can be performed. by a 10 user of the host computing system to conduct transactions with the external computing system according to at least some of the user data. According to a third broad aspect of the present invention, 15 there is provided a computer program product for accessing data on an external computing system via a host computing system, comprising: a registrable application, adapted to be registrable with the host computing system as a registered application; 20 a rendering engine for rendering a display of the host computing system in a manner compatible with the host computing system; a controller adapted to retrieve user data pertaining to users of the host computing system from the host computing 25 system, to pass the user data to a user database and to control the rendering engine; and a transaction management layer for mediating data transfer between the controller and one or more external computing systems. 30 In a particular embodiment, the product can be used by a user of the host computing system to conduct transactions with the external computing system according to at least some of the user data. 35 The present invention provides a data access system for accessing data on an external computing system via a host 3407673_1 (GHMattem) P77111 .AU.2 31/05/2012 9 computing system, comprising: a registrable application, adapted to be registrable with a host computing system as a registered application, the registrable application comprising: 5 a rendering engine for rendering a display of a user computer of a user of the host computing system in a manner compatible with the host computing system such that the registrable application appears to a user as embedded in or integrated into an interface of the host computing system; and 10 a controller adapted to retrieve user data of the user of the host computing system from the host computing system (typically via the registrable application), to pass the user data to a user database and to control the rendering engine; and a transaction management layer for mediating data 15 transfer between the controller and the one or more external computing systems; wherein the controller initiates the data transfer between the controller and the one or more external computing systems based on the user data. 20 In an embodiment, the user data is stored on the host computing system in the form of a user profile. In an embodiment, the data transfer relates to or constitutes a 25 balance enquiry concerning a mobile phone or other account of the user, a top-up of a balance of an account of the user or of another user, a transfer of credit from an account of the user to an account of another user, a bill payment, a purchase of credit, or a voucher purchase. 30 In an embodiment, the system is operable by the user of the host computing system to conduct transactions with the one or more external computing systems according to at least some of the user data. 35 In an embodiment, the host computing system is or provides a social networking website. Brief Description of the Drawing 40 In order that the invention may be more clearly ascertained, embodiments will now be described, by way of example, with reference to the accompanying drawing, in which: Figure 1 is a schematic view of the physical 3723388 1 (GHMatters) P77111.AU.2 31105/2012 10 architecture of a computing system according to an embodiment of the present invention, shown with a user computer and external systems; Figure 2 is a schematic view of the functional 5 architecture of the computing system of figure 1, shown with the user computer and the external systems; Figure 3 is a schematic view of an example of the computing system of figure 1, in which the social networking site comprises FaceBook; 10 Figure 4 tabulates the various functions provided by the controller, transaction management layer, rendering engine and user database of the computing system of figure 1; Figure 5 tabulates the various functions provided by an exemplary mobile telephony application (termed the 'MyMobile 15 Application') and their interaction with the rendering application of the computing system of figure 1; Figures 6 to 9 are screen mockups of the MyMobile Application as hosted by FaceBook. 20 Detailed Description Figure 1 is a schematic view of the physical architecture of a computing system 10 according to an embodiment of the present invention, comprising a host computing system in the form of a website server 12 (providing with a social networking site, 25 discussed below) and a data access and rendering system 14; figure 1 also illustrates a user computer 16 of a user of site 32 and a plurality of external back-end systems 18. A user or users interact with site 32 via a web browser (not shown) running on user computer 16, which downloads and displays the 30 website of site 32. Data access and rendering system 14 includes a server 20 (that includes a controller and rendering engine, discussed below), a user database server 22 (that includes a user database, 35 discussed below), and a transaction management layer server 24 (that includes a transaction management layer, discussed below). Transaction 3407673_1 (GHMatters) P77111 .AU.2 31105/2012 11 management layer server 24 also implements a firewall 26 to provide security between data access and rendering system 14 and external back-end systems 18. 5 External back-end systems 18 are typically systems that, in existing systems, support online billing, account enquiry and the like transactions, via the websites (or call centre operators, etc) of the owners of those back-end systems 18. Briefly, data access and rendering system 14 makes it possible 10 for the user of site 32 to access data on, and conduct transactions with, external back-end systems 18 without using the websites (or call centres, etc) of the owners of those back end systems 18. 15 Figure 2 is a schematic view of the functional architecture 30 of computing system 10, shown with user computer 16 and back-end systems 18. Architecture 30 includes - on website server 12 - a social networking site 32 hosting users via website 34 (for example, users may access site 32 using the website 34). Site 20 32 comprises user data 36 (including user profile data 38, such as the user's name, age and location, and friend data 40 about a user's nominated friends). Site 32 includes a data interface 42 in the form of a language API or web service interface to provide access to user profile data 38 and friend data 40. 25 According to this embodiment, site 32 also includes a visual application interface 44 that enables applications to be embedded in web site 34 using, for example, HTML or a language API. 30 Server 20 of data access and rendering system 14 includes a rendering engine 46 that renders the desired information into site 32, and a controller 48 that drives rendering engine 46 and hence the rendered view. Controller 48 is registrable with site 35 32 and, once so registered, acquires information about the user from site 32 (via data interface 42) and supplies instructions to rendering engine 46 accordingly. User database server 22 of 3407673_1 (GHMattes) P771 I.AU.2 31105/2012 12 data access and rendering system 14 includes a user database 50 of user data that includes system data 52 and access rules 54; access rules 54 specify what kind of information should be displayed to the user. For example, a user may specify that 5 only friends who belong to a specific networking group can view call details (comprising minutes spent talking) to other members of that group. Controller 48 applies access rules 54 to profile data 38 and friend data 40 (received via data interface 42) to ensure that the information acquired from the back-end systems 10 18 via transaction management layer 56, which is to be provided to rendering engine 46, is appropriate to the current view. Transaction management layer server 24 of data access and rendering system 14 includes a transaction management layer 56 15 that incorporates a set of business rules for accessing information in external back-end systems 18 (which are third party systems related to respective services to which access is provided according to this embodiment). Data access and rendering system 14 is configured to receive and capture from 20 external back-end systems 18 information specific to each respective back-end system 18, such as a user's mobile number. Data access and rendering system 14 is configured to store that information in user database 50, and associate it with the user's profile data 38 received from site 32. Transaction 25 management layer 56 provides a consistent interface for performing potentially complex business transactions involving external back-end systems 18. For example, topping up a mobile telephony account may involve validating a credit voucher on one external back-end system 18, adding credit to an account on 30 another external back-end system 18, and activating the phone service on another external back-end system 18. In one specific example of computing system 10, site 32 comprises the FaceBook (trade mark) web site. Figure 3 is thus 35 a schematic view of the architecture 60 of a computing system with an architecture comparable to the architecture 30 of computing system 10 (see figure 2), so like reference numerals 3407873_1 (GHMatters) P7711 1.AU.2 31/0512012 13 have been used to identify like features. FaceBook provides a web site which users can access to share information with their friends. It enables users to embed third 5 party applications. Referring to figure 2, FaceBook site 32 includes a FaceBook API 42 that provides access to a user's profile data 38 and friend's data 24 if the users have added the application. 10 The FaceBook Markup Language (FBML) 44 supported by FaceBook site 32 enables an application to embed its view inside the FaceBook platform. Hence, data access and rendering system 14 in this example - includes a Flex application 46 (comprising a rich internet application created in Flex (trade mark)) that 15 provides users with a highly interactive application that can be used to access data about, in this example, the users' mobile phone account. Data access and rendering system 14 includes a PHP application 20 48 that drives the integration of the Flex application 46 with FaceBook site 32. PHP application 48 acquires the appropriate user information via FaceBook API 42 and provides it to the view layer (i.e. Flex application 46) and transaction management layer 56. Transaction management layer 56, in this example, is 25 implemented using the Business Process Execution Language (BPEL), and BPEL transaction management layer 56 contains a set of processes that wrap a complex set of interactions with various back-end systems 18. In this example, back-end systems 18 include an online billing system 62, an offline billing 30 system 64, a voucher management system 66 and a provisioning system 68. Accordingly, the system structure has a number of advantages including that: a user can access a number of different external 35 systems through a single interface in real-time or near real time such that transactions can be performed on the external systems; the user's details for accessing the external systems 3407673_1 (GHMatlers) P7711 1.AU.2 31/05/2012 14 are kept separate to user details for the host system and the user can selectively allow access to the (or parts of the) external systems to other users without providing the other users with access details for the external systems. 5 Figure 4 tabulates at 70 the various functions provided by controller 48, transaction management layer 56, rendering engine 46 and user database 50 (and hence, in the example of figure 3, PHP controller application 48, BPEL transaction management layer 10 56, Flex application 46 and user database 50. Thus, referring to figure 4, controller 48 function Add Application is used to add an application to the user's profile data 38 (upon the request of the user of site 32), and calls 15 functions Validate Application and Register. Controller 48 function View Profile is triggered when a user views a user's profile data 38 when data access and rendering system 14 has added an application. Controller 48 then 20 determines which view to render based on which profile is being viewed and which user is viewing, employing or calling functions View Own Profile and View Friend's Profile. Controller 48 function View Main is triggered when a user views 25 the main page of an added application. Controller 48 determines which view to render based on the registration status of the user, employing or calling functions Validate Application and View Main of controller 48 and Render Register of rendering engine 46. 30 Controller 48 function Do Action enables a user to perform a system specific action. Such actions depend on the specific application and back-end system(s) 18 being called. 35 Controller 48 function Remove Application allows site 32 (and by extension the user) to remove an application from a user's profile. 3407673_1 (GHMatters) P7711 1.AU.2 31105/2012 15 Controller 48 function Validate Application is adapted to use a site specific mechanism to authenticate with the host site in order to verify the identity of the application. 5 Controller 48 function Register is employed when controller 48 receives information from the rendered register view (with function Render Register of rendering engine 46) and validates the application (with function Validate Application of 10 controller 48); Register then adds system data 52 and access rules 54 to the user database 50. This function optionally includes extended functionality to validate user data 36 in an application specific way (see functional description of MyMobile example below for further details). 15 Controller 48 function View Own Profile prompts controller 48 to validate with site 32 (with function Validate Application) and acquire user data 36 from site 32 before invoking an implementation specific action (with function Invoke Action). A 20 combination of the results and acquired data is then sent to rendering engine 46 via function Render Own Profile (see the functional breakdown of the exemplary MyMobile Application below for an example). 25 Controller 48 function View Friend's Profile is used when controller 48 validates with site 32 (with function Validate Application) and acquires user data 36 and friend data 40 from site 32. View Friend's Profile then acquires access rules 54 (with function Get Access Rule) from user database 50 and 30 applies the access rules 54 (with function Apply Access Rules) before invoking an implementation specific action (with function Invoke Action). A combination of the results and acquired data is then sent to rendering engine 46 with function Render Friends Profile (see the functional breakdown of the exemplary MyMobile 35 Application below). Controller 48 function View Main is used when controller 48 3407673_1 (GHMatters) P771I1.AU.2 31/05/2012 16 validates with site 32 (with function Validate Application) and acquires user data 36 from site 32. One or more implantation specific actions are invoked (with function Invoke Action) and a combination of the results and acquired data is sent to 5 rendering engine 46 with function Render Main. Controller 48 function View All Friends prompts controller 48 to validate with site 32 (with function Validate Application) and acquire user data 36 and friend data 40 from site 32. For each 10 friend who has Data access and rendering system 14, controller 48 acquires (with function Get Access Rule) and applies (with function Apply Access Rules) access rules 54 before invoking an implementation specific action (with function Invoke Action). A combination of the results and acquired data is then sent to 15 rendering engine 46 with function Render All Friends (see the functional breakdown of the exemplary MyMobile Application below). Controller 48 function View Application Specific is used by 20 controller 48 to validate with site 32 (with function Validate Application) and acquires user data from the host site 32 before invoking one or more implementation specific actions (with function Invoke Action). A combination of the results and acquired data is then sent to rendering engine 46 via rendering 25 engine 46 Render Application Specific (see the functional breakdown of the exemplary MyMobile Application below). Controller 48 function Alter Data is employed when controller 48 receives new user details from rendering engine 46 via function 30 Change View. Controller 48 uses this input to alter the system data (with functions Add System Data, Change System Data and Delete System Data) and access rules 54 (with functions Add Access Rule, Change Access Rule and Delete Access Rule). 35 Controller 48 function Apply Access Rule is used when controller 48 finds any access rules 54 that match the user who is requesting the data view and grants or denies access to the data 3407873_1 (GHMatters) P77111 AU.2 31/05/2012 17 based on these rules. Controller 48 function Invoke Action controls controller 48 to acquire system data 52 (with function Get System Data) and then 5 invokes an application specific action via transaction management layer 56 with transaction management layer 56 function Invoke Action. Rendering Engine 46 function Render Main uses a rendering API of 10 site 32, as well as data provided from controller 48, to render a main application view within site 32. Rendering Engine 46 function Render Register is employed when rendering engine 46 uses the rendering API of site 32 to render 15 a view for taking registration information from the user; this information may include authentication information for back-end systems 44 or details about how friends can access their data. It is application specific. 20 Rendering Engine 46 function Render Own Profile is used when rendering engine 46 uses the rendering API of site 32 to render a view displaying a user's own profile information. Rendering Engine 46 function Render Friends Profile uses the 25 rendering API of site 32 to render a view displaying a friend's profile information. Rendering Engine 46 function Render All Friends uses the rendering API of site 32 to render a main view displaying 30 details about a user's friends. Rendering Engine 46 function Render Application Specific* uses the rendering API of site 32 to render a view displaying some application specific information (see functional breakdown of 35 exemplary MyMobile Application for an example). Rendering Engine 46 function Render Change View uses the 3407673_1 (GHMatters) P77111.AU.2 31/0512012 18 rendering API of site 32 to render a view requesting information about access rules 54 and system data 52, and then invokes controller 48 function Alter User Data to set these values. 5 Rendering Engine 46 function Render Logo is an internal function for rendering the logo using the rendering API of site 32. This segregation enables branding to be changed quickly and easily. Rendering Engine 46 function Render Advertising is also an 10 internal function, and rendering advertisements using the rendering API of site 32. This segregation enables advertising to be changed quickly and easily. User Database 50 function Add System Data is used by user 15 database 50 to store a new record linking a user to data about their accounts on back-end system 18. User Database 50 function Change System Data is used by user database 50 to alter a record linking a user to data about their 20 accounts on back-end system 18. User Database 50 function Get System Data is used by user database 50 to retrieve a set of records linking a user to data about their accounts on back-end systems 18. 25 User Database 50 function Delete System Data is used by user database 50 to remove a record linking a user to data about their accounts on back-end systems 18. 30 User Database 50 function Add Access Rule is used by user database 50 to store a new record defining the access allowed for different friends or groups of friends. User Database 50 function Change Access Rule is used by user 35 database 50 to alter a record defining the access allowed for different friends and groups of friends. 34078731 (GHMatters) P77111.AU.2 3110512012 19 User Database 50 function Get Access Rule is used by user database 50 to retrieve a set of records defining the access allowed for different friends or groups of friends. 5 User Database 50 function Delete Access Rule is used by user database 50 to remove a record defining the access allowed for different friends or groups of friends. Transaction management layer 56 function Invoke Action I used by 10 transaction management layer 56 to invoke an application specific action (see functional breakdown of exemplary MyMobile Application for an example). In one example, Data access and rendering system 14 can be used 15 to add an application to site 32 for accessing and modifying a mobile telephony account; this exemplary application is termed the 'MyMobile Application', and is designed to be added to FaceBook (cf. figure 3). Figure 5 tabulates at 80 the various functions provided by the MyMobile Application. 20 Controller 48 function Add application: controller 48 enables FaceBook (and by extension the user) to add the application to a user's profile, by calling functions Validate Application and Render Register. 25 Controller 48 function View Profile: controller 48 is triggered when a user views a user profile with the application added. The controller 48 then determines which view to render: if a user is viewing their own profile the View Own Profile function 30 is called, and if a user is viewing someone another user's profile the View Friends Profile function is called. Controller 48 function View Main: controller 48 is triggered when a user views the applications main page. After validating 35 (with function Validate Application) and acquiring the user ID from FaceBook, controller 48 determines which view to render based on the registration status of the user. If the user is 3407673_1 (GHMatters) P77111.AU.2 31/05/2012 20 registered, the user calls function View Main Page or otherwise function Render Register. Controller 48 function Get Current Balance: controller 48 5 acquires the user's MSISDN and account data (with function Get System Data) and invokes the Get Current Balance function in transaction management layer 56. Controller 48 function Get Current Balance Summary: controller 10 48 acquires the user's MSISDN and account data (with function Get System Data) and invokes the Get Current Balance Summary function in transaction management layer 56. Controller 48 function Top Up: controller 48 acquires the user's 15 MSISDN and account data (with function Get System Data) and invokes the Top Up function in transaction management layer 56. Controller 48 function Gift Credit: controller 48 acquires the initiating and receiving user's MSISDN and account data (with 20 function Get System Data) and invokes the Gift Credit function in the transaction management layer 56. Controller 48 function Get Usage History: controller 48 acquires the user's MSISDN and account data (with function Get System 25 Data) and invokes the Get Usage History function in transaction management layer 56. Controller 48 function Remove Application: controller 48 uses the FaceBook API 42 to remove the application from the user's 30 profile data 38. Controller 48 function Validate Application: controller 48 uses FaceBook's application key and an encrypted application secret key to authenticate with FaceBook in order to verify the 35 identity of the application. Controller 48 function Register: controller 48 receives 3407673_1 (GHMatters) P7711 I.AU.2 31105/2012 21 information from the Render Register function and validates that information either by sending a code via SMS to the user's MSISDN, or be asking the user to enter a validation PIN used to enter the mobile vendors website. In the case of SMS 5 validation, the user is referred back to the register view (with function Render Register) where he or she must enter this code to proceed. Once either code is confirmed controller 48 adds access rules 54 (with function Add Access Rule) and system data 38 (with function Add System Data). 10 Controller 48 function View Own Profile: controller 48 validates with the host site 32 (with function Validate Application) and acquires user data from site 32, which it uses as input to the Get Current Balance function. The user data and the result of 15 the Get Current Balance function are then sent to rendering engine 46 with rendering engine 46 function Render Own Profile. Controller 48 function View Friends Profile: controller 48 validates with site 32 (with function Validate Application) and 20 acquires user data 36 and friend data 34 from site 32. It then applies access rules 54 (with function Apply Access Rule) to determine what information the logged-in user is able to view. The user may be able to view no information, balance summary, or balance details. If the user is authorized to view balance 25 information, controller 48 calls the Get Current Balance function. If the user is authorized to see only a balance summary, controller 48 calls the function Get Current Balance Summary. This data is then sent to rendering engine 46 with function Render Friends Profile. 30 Controller 48 function View Main Page: controller 48 determines which of the main screens the user is viewing (via information passed by the navigation buttons) and invokes the View Front Page, View All Friends, View Top Up, View Gift or View Statement 35 controller functions. Controller 48 function View Front Page: controller 48 validates 3407073_1 (GHMters) P77111 .AU.2 31/05/2012 22 with site 32 (with function Validate Application) and acquires user data 36 from Bite 32. It then invokes the Get Current Balance function. The user data 36 and results of this function are sent to the rendering engine 46 via function Render Main. 5 Controller 48 function View All Friends: controller 48 validates with the host site 32 (with function Validate Application) and acquires user and friend data from the host site. For each friend who has the application added the system applies the 10 access rules 54 (with function Apply Access Rule). For each friend where the user is authorized to see the balance summary the Get Current Balance Summary function is invoked. The results of these queries are then combined with the user data 36 and sent to the rendering engine 46 via function Render All Friends. 15 Controller 48 function View Top Up: controller 48 validates with the host site 32 (with function Validate Application) and acquires user data 36 from the host site 32. It then invokes the Get Current Balance function. The user data 36 and results of 20 this function are sent to the rendering engine 46 via function Render Top Up. Controller 48 function View Gifting: controller 48 validates with the host site 32 (with function Validate Application) and 25 acquires user data 36 from the host site 32. The user data 36 is sent to the rendering engine 46 via function Render Gifting. Controller 48 function View Statement: controller 48 validates with the host site 32 (with function Validate Application) and 30 acquires user data 36 from the host site 32. It then invokes the Get Usage History function. The user data 32 and results of this function are sent to the rendering engine 46 via function Render Statement. 35 Controller 48 function Alter Data: controller 48 receives new user details from the rendering engine 46 via the function Render Change View. It uses this input to alter the system data 3407873_1 (GHMatters) P77111 AU.2 31105/2012 23 52 (via User database 50 function Add System Data, User database 50 function Change System Data, User database 50 function Delete System Data) and access rules 54 (via User database 50 function Add Access Rule, User database 50 function Change Access Rule, 5 User database 50 function Delete Access Rule). Controller 48 function Apply Access Rule: controller 48 finds any access rules 54 (with User database 50 function Get Access Rule) that match the user who is requesting the data view and 10 grants or denies access to the data based on these rules (see MyMobile Access Rules for details). Rendering engine 46 function Render Main: rendering engine 46 uses the host site's rendering API 42 and data provided from the 15 controller 48 to render a main application view which contains a user's balance, advertisements and vendor logos as well as a panel of buttons which provide more options (Add Credit, Statement, My Friends). 20 Rendering engine 46 function Render Register: rendering engine 46 uses the host site's rendering API 42 to render a view for taking registration information (MSISDN and account number) from the user. It also enables users to create specific access rules for their friends or use the default access rules. 25 Rendering engine 46 function Render Own Profile: rendering engine 46 uses the host site's rendering API 42 to render a view displaying a user's own profile information: MSISDN, balance, as well as advertising and the vendors logo. 30 Rendering engine 46 function Render Friends Profile: rendering engine 46 uses FaceBook's rendering API 42 to render a view displaying a friends profile information which contains an indication the user's balance summary (tick for "has credit", 35 cross for "does not have credit"), as well as the option to gift (give) credit to a friend who currently does not have credit. 3407673_1 (GHMatters) P77111 .AU.2 31105/2012 24 Rendering engine 46 function Render All Friends: rendering engine 46 uses FaceBook's rendering API 42 to render a main view displaying details about a user's friends. This contains a list of friends with a balance summary (tick for "has credit", cross 5 for "does not have credit") for each, as well as the option to gift (give) credit to a friend who currently does not have credit. It also includes the same advertising, logos and navigation buttons found on the main page (see Render Main function above). 10 Rendering engine 46 function Render Top Up: rendering engine 46 uses FaceBook's rendering API 42 to render a view displaying the user's current balance and options for topping up a mobile phone account via a pre-purchased voucher or by purchasing credit 15 online. It also includes the same advertising, logos and navigation buttons found on the main page (see Render Main function above). Rendering engine 46 function Render Gifting: rendering engine 46 20 uses FaceBook's rendering API 42 to render a view displaying a friends balance summary (tick or cross) and the ability to gift credit in to various parts of the user's balance (i.e. give them credit for SMS, for calls, or for data). It also includes the same advertising, logos and navigation buttons found on the main 25 page (see Render Main function above). Rendering engine 46 function Render Statement: rendering engine 46 uses FaceBook's rendering API 42 to render a view displaying a list of a user's recent call history. 30 Rendering engine 46 function Render Change View: rendering engine 46 uses FaceBook's rendering API 42 to render a view where user's can enter information about access rules and system data and then invokes function Alter Data to set these values. 35 Rendering engine 46 function Render Logo is an internal function to render the logo using host site's rendering API 42. This 3407873.1 (GHMatters) P77111AU.2 31I0512012 25 segregation enables branding to be changed quickly and easily. Rendering engine 46 function Render Advertising is an internal function to render advertisements using host site's rendering 5 API 42. This segregation enables advertising to be changed quickly and easily. User database 50 function Add System Data: user database 50 stores a new record linking a user to data about their accounts 10 on the back-end system 18. User database 50 function Change System Data: user database 50 alters a record linking a user to data about their accounts on the back-end system 18. 15 User database 50 function Get System Data: user database 50 retrieves a set of records linking a user to data about their accounts on the back-end system 18. 20 User database 50 function Delete System Data: user database 50 removes a record linking a user to data about their accounts on the back-end system 18. User database 50 function Add Access Rule: user database 50 25 stores a new record defining the access allowed for different friends or groups of friends. User database 50 function Change Access Rule: user database 50 alters a record defining the access allowed for different 30 friends and groups of friends. User database 50 function Get Access Rule: user database 50 retrieves a set of records defining the access allowed for different friends or groups of friends. 35 User database 50 function Delete Access Rule: user database 50 removes a record defining the access allowed for different 3407673_1 (GHMatters) P77111.AU.2 31105/2012 26 friends or groups of friends. Transaction management layer 56 function Get Current Balance: transaction management layer 56 calls the online billing system 5 62 to acquire a user's current balance. It returns this balance. Transaction management layer 56 function Get Current Balance Summary: transaction management layer 56 calls the online 10 billing system 62 to acquire a user's current balance. If the value is larger than 0 it returns true otherwise it returns false. Transaction management layer 56 function Top Up - The 15 transaction management layer 56 calls the voucher management system 66 to validate the voucher details entered by the user. If the voucher is valid the system calls the activation system to ensure the user's service is active, it then calls the online billing system 62 to set expiry date for the credit, it then 20 applies the top up to the online and offline billing systems (62, 64). Transaction management layer 56 function Gift Credit: transaction management layer 56 calls the online and offline 25 billing systems (62, 64) to adjust the balance of the user giving the gift by subtracting the gifted amount. The transaction management layer 56 calls the online and offline billing systems (62, 64) to adjust the balance of the user receiving the gift by adding the gifted amount to the 30 appropriate buckets. Transaction management layer 56 function Get Usage History: transaction management layer 56 calls the online billing system 62 to acquire recent usage history. 35 MyMobile access rules are constrained by the information made available to an application by the host site 32. The MyMobile 3407673_1 (GHMalters) P7711 1.AU.2 31/05/2012 27 application used in several examples is hosted by FaceBook and thus the access rules 54 for MyMobile are constrained by the FaceBook API. 5 MyMobile access rules 54 are used to grant access; if no matching rule is found access is denied. Rules 54 are given a type: Group: Either Friends or Anyone; Friends are people added to your FaceBook profile. 10 Individual: A specific FaceBook user can be granted different rights; only applies to individuals who are added as friends. Network: People that belong to a specific network; only applies to people that belong to the network who are also 15 added as friends. Individual rules take precedence over network rules which take precedence over group rules. 20 3407673_1 (GHMalttes) P7711 1AU.2 31/05/2012 28 Example Rules Data: Rules View Type Applies To MSISDN Balance Balance Summary Group Anyone No (cannot No (cannot No be changed) be changed) Group Friends No No Yes Individual JohnDoe Yes Yes Yes Individual JaneDoe Yes Yes Yes Network CompanyNetwork Yes No No Figures 6 to 9 are screen mockups of the operation of the 5 MyMobile Application as hosted by FaceBook. Referring to figure 6, the upper register of the figure comprises the view 90 from the FaceBook profile box showing a user's balance. Clicking the "More" button 92 prompts the opening of the main view 94 (in the lower register of the figure), that is, the view 94 from the 10 MyMobile Application's main page in FaceBook. Navigation buttons in the left hand menu 96 enable users to perform various actions. Referring to figure 7, the upper register of the figure 15 comprises again the view 94 from the main page (see figure 6), from which the user can navigate to various screens. For example, the My Friends view 98 shows a list of friends who have the MyMobile application added; for each friend a summary of their balance is provided (if the access rules allow it). If a 20 friend has no credit they can be given credit (by using the "Give Credit" button 100). Thus, advantageously, a user can allow selected other users to view a status, such as a credit balance and/or modify a balance. The former has a practical advantage to users of prepaid services, for example, in that 25 they can automatically advertise to their friends that they have no credit and hence cannot use the prepaid service. If the "Statement" button 102 is clicked, detailed account 34078731 (GHMattrs) P77111 .AU.2 31/05/2012 29 information 104, showing call history and cost, is displayed; this view also enables a user to pay any outstanding bill, initiated by click on the "Pay Now" button 106. Accordingly, it is possible to envisage a user giving another user (such as a 5 parent) the ability to view and modify an account in a controlled way (e.g. deposits only) without having to provide account details to the other user. In this way, the embodiment provides for controlled account access to other users. 10 Referring to figure 8, clicking the "Give Credit" button 100 when viewing a friend's balance summary prompts view 108, and enables the user to give credit to another user. The gift can be spread across various "buckets" 110a, 110b, 110c corresponding - in this example - to Voice, SMS and Data use. 15 In the illustrated example, the user is shown as being about to give $4 to Voice and $5 to SMS, but nothing to Data use. Figure 9 illustrates the MyMobile Application 112 as hosted on FaceBook 114. As will be seen, the MyMobile Application 112 20 appears to the user as integrated into FaceBook 114. Modifications within the scope of the invention may be readily effected by those skilled in the art. It is to be understood, therefore, that this invention is not limited to the particular 25 embodiments described by way of example hereinabove. In the claims that follow and in the preceding description of the invention, except where the context requires otherwise owing to express language or necessary implication, the word 30 "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, that is, to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention. 35 Further, any reference herein to prior art is not intended to imply that such prior art forms or formed a part of the common general knowledge in Australia or any other country. 3407073.1 (GHMatters) P771 11 AU2 31/05/2012