WO2011082467A1

WO2011082467A1 - Systems and methods for online commerce

Info

Publication number: WO2011082467A1
Application number: PCT/CA2010/000751
Authority: WO
Inventors: Tet Hin Yeap; Thomas Anton Goeller
Original assignee: Toposis Corporation
Priority date: 2010-01-11
Filing date: 2010-05-14
Publication date: 2011-07-14

Abstract

A method for execution by a network entity, comprising: receiving a message identifying an item selected online; formulating a payable item request identifying the item; and sending the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter-organizational billing arrangement. The entity authenticates the received payable item request, accesses the item from a payable item source, sends content pertaining to the item to the requesting network entity and causes the operator of the network entity to be charged by the terminating network under the inter-organizational billing arrangement. The operator of the network entity thus agrees to be charged by the terminating network for items requested by its customers and assumes the risk of collecting from its customers. This allows customers to purchase items online without a separate credit card or subscription.

Description

SYSTEMS AND METHODS FOR ONLINE COMMERCE

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit under 35 USC § 1 19(e) of the following United States Provisional Patent Applications, all of which are hereby incorporated by reference herein:

Serial No. 61/293,901, filed January 11, 2010;

Serial No. 61/293,924, filed January 11 , 2010;

Serial No. 61/307,652, filed February 24, 2010; and

Serial No. 61/314,844, filed March 17, 2010. Also, the present application is a continuation-in-part (CIP) of PCT Patent Application PCT/CA2008/001946, filed 7 November 2008, entitled "Systems and Methods for Multiparty Billing of Network Services", designating the United States and hereby incorporated by reference herein.

FIELD OF THE INVENTION

The present invention relates to the field of online commerce and, in particular to methods and systems for enabling access to payable items online and facilitating payment therefor.

BACKGROUND

Various Internet sites have attempted to provide content to the public for free, with advertising as the only source of revenue. However, many of these sites have thereafter suffered losses from operational costs that are disproportionately high compared to available advertising revenue. The reason for these losses is that, unlike the case with broadcast programs, online content cannot be provided at a fixed cost, because each additional person who accesses a particular web site imposes more bandwidth cost on the web site operator. Therefore, as more people access the content hosted by the web site, but never respond to the advertising banners/pop ups, the site loses money. Many sites have failed for this reason.

Where bandwidth costs are low, i.e. in textual content, there are usually higher costs for professional authoring and editing, resulting in a similar discrepancy between cost of operation and advertising revenue.

One solution to make up for the shortfall is to increase the amount of advertising present on a website. However, this is an unsatisfactory solution as it reduces the site's attractiveness. Alternatively, some sites have resorted (or returned) to charging subscription fees. This is also an unsatisfactory solution, since customers will be reluctant to have more than a small number of online subscriptions for fear of losing control over expenses and also because a larger number of subscriptions becomes cumbersome to manage. Faced with the reality that on the Internet, most customers seek low-cost offers with no strings attached, online content providers eagerly await a solution that allows them to charge for content.

SUMMARY

A first broad aspect of the present invention seeks to provide a method for execution by a network entity, comprising: receiving a message identifying an item selected online; formulating a payable item request identifying the item; and sending the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter- organizational billing arrangement. A second broad aspect of the present invention seeks to provide a network entity, comprising: at least one component configured for receiving a message identifying an item selected online; at least one component configured for formulating a payable item request identifying the item; and at least one component configured for sending the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter-organizational billing arrangement.

A third broad aspect of the present invention seeks to provide a network entity, comprising means for receiving a message identifying an item selected online; means for formulating a payable item request identifying the item; and means for sending the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter- organizational billing arrangement.

A fourth broad aspect of the present invention seeks to provide computer-readable storage media comprising computer-readable instructions for instructing a network entity to: receive a message identifying an item selected online; formulate a payable item request identifying the item; and send the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter-organizational billing arrangement.

A fifth broad aspect of the present invention seeks to provide a method for execution by a network entity in a terminating network, comprising: receiving from a requesting organization a payable item request that identifies an item selected online and comprises putative authentication data pertaining to the requesting organization; carrying out an attempt to authenticate the putative authentication data; and responsive to the attempt being successful, accessing the item from a payable item source, sending content pertaining to the item to the requesting organization and causing the requesting organization to be charged by the terminating network under an inter-organizational billing arrangement.

A sixth broad aspect of the present invention seeks to provide a network entity in a terminating network, comprising: at least one component configured for receiving from a requesting organization a payable item request that identifies an item selected online and comprises putative authentication data pertaining to the requesting organization; at least one component configured for carrying out an attempt to authenticate the putative authentication data; and at least one component configured for responding to the attempt being successful by accessing the item from a payable item source, sending content pertaining to the item to the requesting organization and causing the requesting organization to be charged by the terminating network under an inter-organizational billing arrangement. A seventh broad aspect of the present invention seeks to provide a network entity in a terminating network, comprising: means for receiving from a requesting organization a payable item request that identifies an item selected online and comprises putative authentication data pertaining to the requesting organization; means for carrying out an attempt to authenticate the putative authentication data; and means for responding to the attempt being successful by accessing the item from a payable item source, sending content pertaining to the item to the requesting organization and causing the requesting organization to be charged by the terminating network under an inter- organizational billing arrangement. An eighth broad aspect of the present invention seeks to provide computer-readable storage media comprising computer-readable instructions for instructing a network entity in a terminating network to: detect receipt from a requesting organization a payable item request that identifies an item selected online and comprises putative authentication data pertaining to the requesting organization; carry out an attempt to authenticate the putative authentication data; and responsive to the attempt being successful: accessing the item from a payable item source; send content pertaining to the item to the requesting organization; and cause the requesting organization to be charged by the terminating network under an inter-organizational billing arrangement. A ninth broad aspect of the present invention seeks to provide a system, comprising: a first subsystem accessible over a data network, the first subsystem configured for interacting over the data network with a member of a portal to allow the member to upload payable content and to customize a label associated with the payable content; a second subsystem storing the payable content uploaded by the member via the first subsystem, the second subsystem configured for communicating with a payable item gateway that controls visitor access to the payable content; the first subsystem storing a target in association with the label, the target identifying the payable content stored by the second subsystem; the first subsystem configured for detecting selection of the label by a visitor to the portal and, in response, sending the target to the visitor over the data network.

A tenth broad aspect of the present invention seeks to provide a system, comprising: first means accessible over a data network, for interacting over the data network with a member of a portal to allow the member to upload payable content and to customize a label associated with the payable content; second means for communicating with a payable item gateway that controls visitor access to the payable content, the second means being means for storing the payable content uploaded by the member via the first means; the first means being means for storing a target in association with the label, the target identifying the payable content stored by the second means; the first means being means configured for detecting selection of the label by a visitor to the portal and, in response, sending the target to the visitor over the data network.

An eleventh broad aspect of the present invention seeks to provide a method, comprising: receiving a message identifying a domain name associated with an item selected online; identifying a numerical address of a destination to which to send at least a portion of the message, based on at least a portion of the domain name; routing at least a portion of the message to the destination; wherein when the item is payable, the numerical address of the destination is the numerical address of a designated network entity capable of issuing a payable item request to a second entity that controls access to the item, the second entity being part of a terminating network with which an operator of the designated network entity has an inter-organizational billing arrangement. A twelfth broad aspect of the present invention seeks to provide an apparatus, comprising: at least one component configured for receiving a message identifying a domain name associated with an item selected online; at least one component configured for identifying a numerical address of a destination to which to send at least a portion of the message, based on at least a portion of the domain name; at least one component configured for routing at least a portion of the message to the destination; wherein when the item is payable, the numerical address of the destination is the numerical address of a designated network entity capable of issuing a payable item request to a second entity that controls access to the item, the second entity being part of a terminating network with which an operator of the designated network entity has an inter-organizational billing arrangement.

A thirteenth broad aspect of the present invention seeks to provide an apparatus, comprising: means for receiving a message identifying a domain name associated with an item selected online; means for identifying a numerical address of a destination to which to send at least a portion of the message, based on at least a portion of the domain name; means for routing at least a portion of the message to the destination; wherein when the item is payable, the numerical address of the destination is the numerical address of a designated network entity capable of issuing a payable item request to a second entity that controls access to the item, the second entity being part of a terminating network with which an operator of the designated network entity has an inter-organizational billing arrangement.

A fourteenth broad aspect of the present invention seeks to provide computer-readable storage media comprising computer-readable instructions for instructing a network entity to: detect receipt of a message identifying a domain name associated with an item selected online; identify a numerical address of a destination to which to send at least a portion of the message, based on at least a portion of the domain name; route at least a portion of the message to the destination; wherein when the item is payable, the numerical address of the destination is the numerical address of a designated network entity capable of issuing a payable item request to a second entity that controls access to the item, the second entity being part of a terminating network with which an operator of the designated network entity has an inter-organizational billing arrangement.

A fifteenth broad aspect of the present invention seeks to provide a method for execution by a network entity, comprising: receiving a request for an item selected by a visitor to a website; determining whether the request is a request for a payable item; responsive to determining that the request is a request for a payable item, processing the request in an attempt to identify an organization that agrees to be charged in relation to the item on behalf of the visitor; and responsive to the attempt being unsuccessful, directing the visitor to a web page that permits selection of an organization that agrees to be charged in relation to the item on behalf of the visitor.

A sixteenth broad aspect of the present invention seeks to provide a network entity, comprising: at least one component configured for receiving a request for an item selected by a visitor to a website; at least one component configured for determining whether the request is a request for a payable item; at least one component configured for responding to determining that the request is a request for a payable item by processing the request in an attempt to identify an organization that agrees to be charged in relation to the item on behalf of the visitor; and at least one component configured for responding to the attempt being unsuccessful by directing the visitor to a web page that permits selection of an organization that agrees to be charged in relation to the item on behalf of the visitor.

A seventeenth broad aspect of the present invention seeks to provide a network entity, comprising: means for receiving a request for an item selected by a visitor to a website; means for determining whether the request is a request for a payable item; means for responding to determining that the request is a request for a payable item by processing the request in an attempt to identify an organization that agrees to be charged in relation to the item on behalf of the visitor; and means for responding to the attempt being unsuccessful by directing the visitor to a web page that permits selection of an organization that agrees to be charged in relation to the item on behalf of the visitor.

An eighteenth broad aspect of the present invention seeks to provide computer- readable storage media comprising computer-readable instructions for instructing a network entity to: detect receipt of a request for an item selected by a visitor to a website; determine whether the request is a request for a payable item; respond to determining that the request is a request for a payable item by processing the request in an attempt to identify an organization that agrees to be charged in relation to the item on behalf of the visitor; and respond to the attempt being unsuccessful by directing the visitor to a web page that permits selection of an organization that agrees to be charged in relation to the item on behalf of the visitor.

A nineteenth broad aspect of the present invention seeks to provide a website accessible over a data network, comprising: a memory storing data; and a network interface for communicating over the data network; wherein when the data is accessed by a browser over the data network, the data allows rendering of a web page on the browser, the web page displaying labels in association with items that can be selected by selection of the labels through interaction with the browser; wherein responsive to receipt of a request for a payable item selected by a user of the browser, the website directs the browser to a second web page that permits selection of an organization that agrees to be charged in relation to the payable item on behalf of the user.

A twentieth broad aspect of the present invention seeks to provide a website accessible over a data network, comprising: memory means for storing data; and network interface means for communicating over the data network; wherein when the data is accessed by a browser over the data network, the data allows rendering of a web page on the browser, the web page displaying labels in association with items that can be selected by selection of the labels through interaction with the browser; wherein responsive to receipt of a request for a payable item selected by a user of the browser, the website directs the browser to a second web page that permits selection of an organization that agrees to be charged in relation to the payable item on behalf of the user. A twenty-first broad aspect of the present invention seeks to provide a method, comprising: using a browser to visit a web page that displays labels in association with items that can be selected by selection of the labels through interaction with the browser; selecting a payable item from the web page; selecting an organization that maintains an account for a user of the browser; accessing the payable item, wherein access to the payable item is controlled by an entity in a terminating network; wherein the terminating network issues a first charge to the organization under an inter- organizational billing arrangement between the terminating network and the organization, the first charge being in relation to the payable item; wherein the organization issues a second charge to the account, the second charge being in relation to the payable item.

A twenty-second broad aspect of the present invention seeks to provide a method, comprising: accessing a data network by supplying credentials associated with a user account maintained by an operator of an access network; using a browser to visit a web page that displays labels in association with items that can be selected by selection of the labels through interaction with the browser; selecting a payable item from the web page; selecting an organization that has (i) a first inter-organizational billing arrangement with a terminating network comprising an entity that controls access to the payable item and (ii) a second inter-organizational billing arrangement with the operator of the access network; accessing the payable item via the terminating network; wherein the terminating network issues a first charge to the organization under the first inter-organizational billing arrangement, the first charge being in relation to the payable item; wherein the organization issues a second charge to the operator of the access network under the second inter-organizational billing arrangement, the first charge being in relation to the payable item; wherein the organization issues a third charge to the account, the third charge being in relation to the payable item.

A twenty-third broad aspect of the present invention seeks to provide a method, comprising: accessing a data network using a device; providing credentials pertaining to an account established for a given customer with a first organization; accessing a payable item over a data network using the device, wherein content pertaining to the item is delivered by a second organization; wherein said accessing generates at least two charges, including a first charge from the second organization to the first organization and a second charge from the first organization to the account established for the given customer.

These and other aspects and features of the present invention will now become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS In the accompanying drawings:

Fig. 1 is a block diagram of a general network architecture that supports internet commerce, in accordance with various non-limiting embodiments of the present invention.

Fig. 2A is a block diagram of a specific network architecture that supports internet commerce, in accordance with a non-limiting embodiment of the present invention.

Figs. 2B and 2C are block diagrams illustrating variants of Fig. 2 A.

Fig. 3 is a message flow diagram applicable to the specific network architecture of Fig. 2A, in the context of a device visiting a website and making a request for a payable item represented on a web page of the website. Fig. 4 shows an example web page on which is represented a payable item that can be requested by a device in the architecture of Fig. 2 A.

Fig. 5 represents a billing flow resulting from the message flow in Fig. 3. Fig. 6 is a block diagram of a specific network architecture that supports internet commerce, in accordance with another non-limiting embodiment of the present invention.

Fig. 7 is a message flow diagram applicable to the specific network architecture of Fig. 6, in the context of a device visiting a website and making a request for a payable item represented on a web page of the website.

Fig. 8 shows an example web page on which is represented a payable item that can be requested by a device in the architecture of Fig. 6. Fig. 9 represents a billing flow resulting from the message flow in Fig. 7.

Fig. 10 is a block diagram of a specific network architecture that supports internet commerce, in accordance with yet another non-limiting embodiment of the present invention.

Fig. 11 is a message flow diagram applicable to the specific network architecture of Fig. 10, in the context of a device visiting a website and making a request for a payable item represented on a web page of the website.

Fig. 12 shows an example web page on which is represented a payable item that can be requested by a device in the architecture of Fig. 10. Fig. 13 represents a billing flow resulting from the message flow in Fig. 1 1.

Fig. 14 is a block diagram of a specific network architecture that supports internet commerce, in accordance with still another non-limiting embodiment of the present invention.

Fig. 15 is a message flow diagram applicable to the specific network architecture of Fig. 14, in the context of a device visiting a website and making a request for a payable item represented on a web page of the website. Fig. 16 shows an example web page on which is represented a payable item that can be requested by a device in the architecture of Fig. 15.

Fig. 17 represents a billing flow resulting from the message flow in Fig. 15. Fig. 18 is a block diagram of a specific network architecture that supports internet commerce, in accordance with a further non-limiting embodiment of the present invention. Fig. 19 is a message flow diagram applicable to the specific network architecture of Fig. 18, in the context of a device visiting a website and making a request for a payable item represented on a web page of the website. Fig. 20 shows an example web page on which is represented a payable item that can be requested by a device in the architecture of Fig. 18.

Fig. 21 represents a billing flow resulting from the message flow in Fig. 19. Fig. 22 is a block diagram of a specific network architecture that supports internet commerce, in accordance with an additional non-limiting embodiment of the present invention.

Fig. 23 is a message flow diagram applicable to the specific network architecture of Fig. 22, in the context of a device visiting a website and making a request for a payable item represented on a web page of the website.

Fig. 24 shows an example web page on which is represented a payable item that can be requested by a device in the architecture of Fig. 22.

Fig. 25 represents a billing flow resulting from the message flow in Fig. 23.

Fig. 26 is a message flow diagram that is a variant of the message flow diagram of Fig. 11.

Fig. 27 shows an example web page that presents a set of payment options, including at least one home network payment option, for settling payment for a payable item.

Fig. 28 is a combined block diagram and message flow diagram that supports internet commerce, in accordance with yet a further non-limiting embodiment of the present invention.

Fig. 29 represents a billing flow resulting from the message flow in Fig. 28. Fig. 30 is a combined block diagram and message flow diagram that supports internet commerce, in accordance with still a further non-limiting embodiment of the present invention. Fig. 31 is a combined block diagram and message flow diagram that supports internet commerce, in accordance with another non-limiting embodiment of the present invention.

Fig. 32 shows an example web page that presents a set of payment options, including an intermediary payment vehicle option, for settling payment for a payable item.

Fig. 33 represents a billing flow resulting from the message flow in Fig. 21.

Fig. 34 is a combined block diagram and message flow diagram that supports internet commerce, in accordance with yet another non-limiting embodiment of the present invention.

Fig. 35 shows an example of a web page including links of a first type associated with free items and links of a second type associate with payable items.

Fig. 36 shows an example of a confirmation page that is presented to a user in order to confirm an imminent purchase of a payable item.

It is to be expressly understood that the description and drawings are only for the purpose of illustration of certain embodiments of the invention and are an aid for understanding. They are not intended to be a definition of the limits of the invention.

DETAILED DESCRIPTION

A simplified general network architecture representing a system according to some non-limiting embodiments of the present invention is shown schematically in Fig. 1. A client device (or simply "device") 125 such as a computer, mobile phone, internet stick, residential gateway, set top box, etc. is connected to an originating network 110, which is "online", i.e., connected to a data network 105 such as the Internet or other public data network. It should be appreciated that the data network 105 may be a single network or an agglomeration of several interconnected networks. The originating network 110 can be a mobile network, a last-mile residential access network or a Wi-Fi network, to name a few non-limiting possibilities.

An access server 12 in the originating network 110 receives a request to access the data network 105 (i.e., an access request) from the device 125. In accordance with any of a number of protocols, the access server 12 in the originating network 1 10 determines whether the device 125 is authorized to access the data network 105. This can be done by attempting to identify a valid customer account maintained by the originating network 1 10, based on access credentials supplied by the device 125 in the access request. If a valid customer account maintained by the originating network 110 is identified, say a customer account 182, a connection is established with the device 125 through the originating network 1 10 so that the device 125 (and/or other end user equipment residing behind the device 125) can carry out various tasks over the data network 105, such as, for example, exchanging data with various websites 14 in the data network 105. The originating network 110 collects "usage data" that pertains to the connection established in association with the customer account 182, and which can include one or more of an IP address assigned to the device 125, a time at which the connection was established, the number of bytes exchanged, the URLs of visited websites, etc. The usage data collected in this manner can be used for billing the entity (e.g., person or company) for which the customer account 182 has been established.

A given one of the websites 14 includes a memory, a network interface and a processing entity. The network interface connects to the data network 105, either directly (when the website has a fixed IP address, for example) or indirectly via an optional proxy server 102. The proxy server 102, which is optional, may be used for reducing Internet traffic, surveillance of Internet traffic, etc. The memory stores data corresponding to a collection of web pages. The processing entity is configured for making the web pages available to a requestor via the network interface. The processing entity is responsive to a request identifying one of the web pages by retrieving the data corresponding to the identified web page and transferring the retrieved data to the requestor. To facilitate communication exchange with the websites 14 over the data network 105, a browser (e.g., Internet Explorer, Firefox, Chrome, etc.) may be installed on the device 125. With reference to Fig. 35, the data corresponding to at least one of the web pages includes a set of links associated with items. A link may be of a first type (when it is associated with free item) or of a second type (when it is associated with a payable item). Text and/or graphics can also be used to represent a particular item by placing the text and/or graphics in the vicinity of the corresponding link. The text and/or graphics used to represent a free item may also be descriptive of the fact that the item is available for free. The text and/or graphics used to represent a payable item may also be descriptive of the fact that the payable item is available for instant purchase (e.g., by specifying the price of the payable item). Examples of payable items include media content (e.g., news, videos, recipes, ringtones, greeting cards, etc.) and software (e.g., for mobile, laptop and/or desktop devices), to name a few non-limiting possibilities. Other possibilities exist and will occur to those of skill in the art.

The links each include a label and a target. The label of a particular link can include text and/or graphics that is capable of being displayed by the browser and selected by a user (or website visitor) through interaction with the browser. Specifically, the label 3510 of a particular link of the first type can include information specific to the free item with which it is associated and/or it can include generic language indicating that the item is free. Specifically, the label 3520 of a particular link of the second type can include information specific to the payable item with which it is associated and/or it can include generic language inviting a user to request the payable item, such as

"click here to buy for cents", "pay for this item via your data bill", "now" or any conceivable variation thereof.

The target of a particular link can include an address, such as a uniform resource locator, uniform resource identifier, etc. (hereinafter referred to as "URL" for simplicity but without limitation) that is maintained by the memory of the website in association with the label and is returned by the processing entity to the device 125 when a user of the browser running on the device 125 clicks on, rolls over or otherwise selects the label. The URL specified by the target of a particular link of the first type can point to a location in the memory of the website where data that is available for free is stored. Examples of data that is available for free include text, images, audio, video, freeware as well as other web pages, any of which can be delivered to the device 125 via a connection established over the data network 105.

The URL specified by the target of a particular link of the second type can include a portion allowing the URL to be recognized by an external entity as a URL associated with a payable item (as opposed to freely available content). To this end, the URL may be given a domain name that appears on a special list of domain names held by the external entity; alternatively, the URL may be given a domain name such that the numerical (e.g., IP) address corresponding to the domain name (as returned by a domain name server) appears in a pool (or reserved set) of IP addresses held by the external entity.

In accordance with a non-limiting embodiment of the present invention, the architecture of Fig. 1 also provides a terminating network 16, which is connected to the data network 105. The terminating network 16 facilitates e-commerce in order to enable a user of the device 125, when visiting certain websites 14 in the data network 105, to access "payable items" offered or advertised by those websites 14. Non- limiting examples of payable items include media content (news, videos, recipes, ringtones, greeting cards, etc.) and software (e.g., for mobile, laptop and/or desktop devices) that is capable of being delivered to the device 125 over a data connection traversing the data network 105. Other types of payable items are contemplated, some of which are described later in this specification.

The terminating network 16 includes a request handling entity 18, which acts as a gateway to a payable item source 20. The request handling entity 18 (also referred to as a "payable item gateway") can be implemented as a server including hardware and software, as a software program running on a computer, as a distributed computing system, or as a system on a chip, to name a few non-limiting possibilities. The payable item source 20 stores or has access to payable items that can be retrieved by the request handling entity 18 in response to receipt of a payable item request 22. Thus, the request handling entity 18 controls access to the payable items. The payable item request 22 is received from and formulated by a designated network entity 24 operated by a "participating organization" 26, with which the terminating network 16 has an inter-organizational billing arrangement.

Generally speaking, an inter-organizational billing arrangement that exists between a first organization and a second organization is a contract under which the first organization agrees to be billed/charged by the second network when presented with a service record from the second organization. The service record can specify a fee as well as information to allow the first organization to recover the fee from entities with which the first organization has contractual relationships of its own. Thus, for example, when a customer of the first organization requests a payable item that is accessed via the second organization, an inter-organizational billing arrangement between the first and second organizations eliminates the risk of second organization not being paid by the customer, since the second organization actually seeks payment from the first organization, which is more trustworthy (from the second organization's point of view) than the customer. The risk of non-payment is transferred to the first organization, but this risk is small because of the credit relationship that exists between the first organization and the customer.

Further information regarding the creation and management of inter-organizational billing arrangements in the non-limiting case where the first and second organizations are telecommunications carriers can be found in the following references, incorporated by reference herein:

• Lacroix, Didier (2001, April) How to Optimize Inter Carrier Settlements.

Document presented at the Seminar on Costs & Tariffs for the TAF Group Member Countries, Niamey, Niger;

• Lacroix, Didier (2001, September) Traffic Reconciliation Between Operators - Issues and Techniques. Document presented at the Regional Seminar on

New Trends in Tariff Policies for ECE Countries & CIS, Bratislava, Slovakia; • Lacroix, Didier (2001 , April) The Evolution of Inter Carrier Settlements. Document presented at the Seminar on Costs & Tariffs for the TAF Group Member Countries, Niamey, Niger;

• Ofrane, Avi & Harte, L. (2003). Introduction to Telecom Billing: Usage Events, Call Detail Records, and Billing Cycles. Althos Publishing

(http ://w ww . althosbooks . com) ; and

• Telecommunications Engineering Centres, NGN Interconnect Exchange Release 1, Telecommunication Engineering Centres (http://www.tec.gov.in). Those skilled in the art will appreciate how principles similar to those described in the aforementioned references can be applied in order to create and manage an inter- organizational billing arrangement when one or both of the first and second organizations may not be a telecommunications carrier, for example in the case where one of the organizations is an internet service provider, a utility, a bank, a credit card facility or a prepaid credit facility.

With continued reference to the architecture of Fig. 1, and within the above context of an inter-organizational billing arrangement, the "first organization" corresponds to the participating organization 26, while and the "second organization" corresponds to the terminating network 16. Specifically, in this embodiment, the participating organization 26 maintains customer accounts for various ones of its customers who subscribe to an online payment service. In particular, the participating organization 26 maintains a customer account 145. The customer account 145 is associated with credentials which can include one or more of an account name, a username, a password, a SIM card number, a telephone or DSL line used by the device 125 to access the data network 105, a serial number or MAC address of an authorized device, to name a few non-limiting possibilities. The customer account 145 represents a billing relationship between the participating organization 26 and a customer (e.g., a person or company), by virtue of which the customer pays in advance, or agrees to be billed, for certain activities. Such activities involve accessing payable items held by the payable item source 20 while the customer is using a device (such as, but not limited to, the device 125) to access the websites 14. It should be appreciated that the payable item source 20 can be a third party source that has a supplier relationship with the terminating network 16, i.e., in exchange for honoring a request for a payable item for which it is responsible, the payable item source 20 issues a charge (i.e., a request for payment) to the terminating network 16 for a certain sum of money. The terminating network 16 can settle the charge in part or in full in any suitable manner, including pre-payment, post-payment, credit note, etc. In other embodiments, the payable item source 20 is under the control of the terminating network 16 itself, and therefore this does not explicitly resulting a charge being issued to the terminating network 16.

Moreover, by virtue of the inter-organizational billing arrangement that exists between the terminating network 16 and the participating organization 26, the terminating network 16 can issue a charge (i.e., a request for payment) to the participating organization 26 by sending a service record that specifies a certain sum of money as well as certain usage details (timestamp, source IP address, number of bytes delivered, etc.). Where the payable item source 20 is a third party source, the terminating network 16 will have been charged a certain amount by the payable item source 20 (see preceding paragraph), and this charge can be transferred to the participating organization 26.

In response to being charged by the terminating network 16, the participating organization 26 proceeds to transfer this charge to an entity with which it has a financial relationship and that is identified as being responsible for this charge. This entity is identified by correlating the information in the service record received from the terminating network 16 with usage information the participating organization has logged for various ones of its customers. For example, it may turn out that this entity is the person or company responsible for the customer account 145.

It is envisaged that the terminating network 16 and/or the participating organization 26 may collect a per-transaction fee for their respective roles in facilitating access to payable items, whereby for a given transaction, the net amount credited to other entities, from each organization's own perspective, will be less than the net amount collected. As fees accumulate, they are ultimately borne by the customer account identified as being the requestor of a given payable item. In order for the request handling entity 18 to effectively respond to the payable item request 22 received from the designated network entity 24 in the participating organization 26, it may be beneficial for the payable item request 22 to include information that identifies the payable item being requested as well as the payable item source from which it is to be retrieved (in this case, the payable item source 20). In addition, it is within the scope of the present invention for the payable item request 22 to identify the participating organization 26, which has the purpose of informing the terminating network 16 of the entity that has agreed to billed for with the current transaction. In the present embodiment, this can be done by embedding an identifier 30 of the participating organization 26 in the payable item request 22.

In order to protect against fraudulent or stray payable item requests, or generally in the interest of greater security, a process may optionally be followed whereby the designated network entity 24 in the participating organization 26, in addition to embedding the identifier 30 of the participating organization 26 in the payable item request 22, also embeds in the payable item request 22 an encrypted identifier 32. The encrypted identifier 32 can be the result of having encrypted the identifier 30 of the participating organization 26 with a private key 40-PR. The private key 40-PR, which is kept secret by the participating organization 26, has a matching public key 40-PU that can be used to decrypt the encrypted identifier 32, thereby to reveal the identifier 30 of the participating organization 26. The public key 40-PU associated with the participating organization 26 is held in a key server 50 that holds other public keys associated with other participating organizations. The key server 50 can be located in a protected network. The key server 50 is reachable by the request handling entity 18 of the terminating network 16 via a communication link 52, which can be kept secure by providing a direct connection or as a virtual private network (VPN) over the data network 105. Thus, in response to a message from the request handling entity 18 including the identifier of a participating organization and a putative encrypted identifier (both obtained from the received payable item request 22), the key server 50 can return the public key associated with the participating organization, which is then used by the request handling entity 18 in an attempt to decrypt the putative encrypted identifier. If the result of the decryption attempt yields the identifier of the participating organization, then it can be concluded that the encrypted identifier was encrypted by an entity that had access to the private key associated with the participating organization. Since each private key is held secret by the participating organization with which it is associated, a match subsequent to decryption would indicate that the putative encrypted identifier was indeed legitimate, thereby authenticating the payable item request 22. If the payable item was media content or software, then the media content or software would be obtained from the payable item source 20 and released to the designated network entity 24 (ultimately being destined for the device 125). On the other hand, a mismatch would result in the request being denied and could be indicative of fraudulent activity.

In an alternative scenario, the request handling entity 18 need not carry out a decryption attempt. Rather, in response to receipt of the payable item request 22 including the identifier of a participating organization and a putative encrypted identifier, the request handling entity 18 could supply the key server 50 with the identifier of the participating organization and the putative encrypted identifier. The key server 50 then performs the attempted decryption mentioned above and provides the request handling entity 18 with an indication of whether there was a match or a mismatch, allowing the request handling entity 18 to draw the same conclusions as those mentioned above.

As an alternative to encryption, the keys 40-PR and 40-PU can also be used for signing and verifying the identifier of the participating organization, respectively.

In one embodiment, the payable item request 22 can be based on the Session Initiation Protocol (SIP), in which case two additional Attribute Value Pairs (AVPs) can be defined (e.g., Originating-Network and Originating-Network-Info) for carrying the identifier 30 and the encrypted identifier 32, respectively. In an alternative embodiment, the payable item request can be based on the HyperText Transport Protocol (HTTP), in which the identifier 30 and the encrypted identifier 32 can be transported via CGI parameters. It is envisaged that generation of corresponding private and public keys for a given participating organization can by carried out by an entity in the given participating organization or by the key server 50 (with the private key then securely distributed to the designated network entity in the given participating organization). Further details regarding secure key distribution and key management involving the key server 50 can be found in PCT Patent Application PCT/CA2008/001946, filed 7 November 2008, entitled "Systems and Methods for Multiparty Billing of Network Services", hereby incorporated by reference herein. Three (3) non-limiting sets of use cases are now described. It will be appreciated that further use cases will become apparent to those of skill in the art.

FIRST SET OF USE CASES In the first set of use cases below (1.1 through 1.6), the originating network 110 is also the participating organization 26. That is to say, customers of the originating network 1 10 who wish to access the data network 105 (e.g., by virtue of the customer account 182) also subscribe to an online payment service offered by the originating network 110 (e.g., by virtue of the customer account 145). Thus, in the first set of use cases to follow, the customer account 182 is the same as the customer account 145 and, for consistency, will be referred to as the customer account 145, 182.

USE CASE 1.1 Reference is made to Fig. 2A, which shows a simplified network architecture according to a specific non-limiting embodiment of the present invention. The network architecture of Fig. 2A is based on the network architecture of Fig. 1. Specifically, a terminating network 215 includes a request handling entity 240 that acts as a gateway to a payable item source 235 from which payable items can be accessed. Also, the terminating network 215 optionally includes a proxy server 202 that acts as a gateway to a website 230. In this embodiment, the payable item source 235 and the website 230 are both under the control of the terminating network 215. In fact, it is envisaged that the payable item source 235 and the website 230 may be implemented by the same computer, although this is neither a limitation nor a requirement of the present invention.

The originating network 1 10 comprises a designated network entity 220 as well as a domain name server (DNS) 250 that handles queries issued by the device 125 whenever a new domain name is to be accessed. In one embodiment, the DNS 250 keeps a special list of domain names which, if present in a requested URL, are considered to pertain to requests for payable items and are therefore to be handled in a different way from other domain names. Thus, if the device 125 were to consult the DNS 250 for the IP address corresponding to a given URL, the DNS 250 would check the domain name of this URL against the list. If it is on the list, the DNS 250 would return the IP address of the designated network entity 220 in the originating network 110. Accordingly, the device 125 would send a message, comprising at least part of the originally requested URL, to the designated network entity 220. In contrast, if the domain name of the requested URL is not on the list, then the query from the device 125 would be handled as a standard DNS query, which would be resolved into an IP address other than that of the designated network entity 220.

Consider that a user of the device 125 has established a connection over the originating network 110, the data network 105 and the optional proxy server 202 in order to reach the website 230. For illustrative purposes, the website 230 is located at the URL www.deviceapps.com. In this embodiment, the website 230 is maintained by the terminating network 215 and presents a web page which, when displayed by a browser running on the device 125, may resemble what is shown in Fig. 4 by way of non-limiting example. The web page 400 can be one of several web pages stored in the memory of the website 230.

In this example, the terminating network 215, which operates the website 230, has developed a variety of software applications (apps) for a variety of devices, which are made available for download and are represented on the web page. The web page 400 includes an address bar 410 that indicates the URL of the web page. The web page also includes at least one link of the second type 440A, 440B, 440C and, possibly, one or more links of the first type 430A, 430B, 430C. Also provided is a window 420 that generally advertises the availability of apps for download, some of which are free and others of which are payable.

In addition, various graphics and associated text portions are provided, which are indicative of corresponding apps. Specifically, each graphic and associated text portion is a label corresponding to a respective link, which is either a link of the first type (if the app is free) or a link of the second type (if the app is payable).

In this example, link 430C whose label appears as "Application #1" is a link of the first type (i.e., corresponding to a free app). This app may be stored on a subsystem (e.g., a public directory) of the www.deviceapps.com website. The target associated with the free app is a URL pointing to the location from which the free app can be downloaded to the device 125 over the data network 105. In contrast, links 440 A, 440B, 440C whose labels appear as "Application #2", "Application #3" and "Application #4" are links of the second type (i.e., corresponding to payable apps). These payable apps may be stored by the payable item source 235, which can be another subsystem (such as a secure portion/directory) of the www.deviceapps.com website. The targets associated with the payable apps are also URLs. However, to prevent these apps from being indiscriminately accessed over the data network 105, the domain names of the targets are modified. For example, the string "pay" could form part of the domain name, e.g., as a prefix. Alternatively, a code could appear either contiguously or scattered within the domain name. These modified domain names (or unique portions of domain names) corresponding to payable apps appear on a list held by the DNS 250 in the originating network 110. As will be seen below, the use of a modified domain name as part of the target of a link associated with a payable app forces the requestor of that link to pass through the request handling entity 240 in order to access the payable app. Nevertheless, the same entity can operate both the subsystem that provides access to free apps via the data network 105 and the subsystem that provides access to payable apps via the request handling entity 240.

With reference to Fig. 3, consider now that the user of the device 125 selects the link whose label appears as "Application #2". The website 230 returns the corresponding target with the modified domain name, e.g., the URL pay.deviceapps.com/app-2, to the device 125 over the previously established connection (©). The device 125 issues a DNS query to the DNS 250 based on the URL pay.deviceapps.com/app-2 (©). The DNS 250 recognizes that the domain name of the received URL is a listed domain name, e.g., due to the fact that the domain name of the received URL is prefixed by the string "pay". The DNS 250 thus returns the IP address of the designated network entity 220 in the originating network 110 (⁽D). The device 125 thus directs a message (e.g., an HTTP call), including at least part of the originally requested URL pay.deviceapps.com/app-2, to the designated network entity 220 (©).

The designated network entity 220 recognizes that the message received from the device 125 is a request for a payable item for the customer account 145, 182. The designated network entity 220 decides whether to accept to be charged on behalf of the customer account 145, 182. For example, the designated network entity 220 can verify (e.g., by consulting a database) whether the customer account 145, 182 subscribes to an online payment service.

Assuming that the customer account 145, 182 was indeed found to subscribe to an online payment service, the identity of the customer account 145, 182, the contents of the message, the time and any other relevant information can be collected by the designated network entity 220 as usage data. Based on the usage data for the present request and other requests made for other customer accounts, the designated network entity 220 will at some later time be able to reconcile the usage data with the information contained in service records received from the terminating network 215 in order to charge the appropriate customer account, in this case the customer account 145, 182.

The designated network entity 220 then formulates a payable item request for transmission to an appropriate request handling entity. In order to identify the IP address of the appropriate request handling entity to which it is to forward the payable item request, the designated network entity 220 consults a database (not shown) or other resource based on the domain name of the originally requested URL. The database or other resource maintains information regarding which request handling entities in which terminating networks act as the gateways to the domain names where various payable items are stored. In this example, the appropriate request handling entity is found to be the request handling entity 240 in the terminating network 215. This aforementioned database can be implemented by the Domain Name System without modifications specific to the originating network 1 10, where an (unmodified) domain name server directs the payable item request processed by the designated network entity 220 to the request handling entity 240. Optionally, the designated network entity 220 may modify the domain name in the originally requested URL, if the actual domain of the request handling entity 240 is not one that is on the list stored in the DNS 250.

The payable item request includes at least part of the originally requested URL (in this case, pay.deviceapps.com/app-2). In a non-limiting embodiment, the payable item request can be an HTTP call. If, in addition, the customer account 145, 182 was found to subscribe to an online payment service, the designated network entity 220 inserts authentication data into the payable item request. By way of non- limiting example, the authentication data can include an identifier of the originating network 110. For enhanced security, the authentication data can also include a version of this same identifier but encrypted with a private key of the originating network 110. The designated network entity 220 thus sends the payable item request to the request handling entity 240, e.g., over the data network 105 (©).

Since the request handling entity 240 may be the gateway to multiple payable item sources, upon receipt of the payable item request from the designated network entity 220, the request handling entity 240 identifies the correct payable item source from which to retrieve the requested payable item. The correct payable item source can be identified based on part of the originally requested URL contained in the payable item request. In this example, the requested payable item is held by the payable item source 235. If authentication data was supplied as part of the payable item request, the request handling entity 240 verifies the information (e.g., by a decryption technique as has been previously described). If the authentication data is successfully verified, this will reveal the identity of the entity to be charged for the requested payable item (in this case, it is the originating network 1 10). Also, the request handling entity 240 determines the price of the requested payable item. The price can be obtained by consulting a pricing database or by querying the payable item source 235 directly. The request handling entity 240 then sends a message back to the designated network entity 220. The message causes a confirmation page to be rendered by the browser installed on the device 125. In addition, the message may also include a request for credit clearance destined for the designated network entity 220, to ensure that the originating network 110 will agree to be billed for the price of the requested payable item (plus a commission).

The price of the requested payable item may be modified by adding commissions as the confirmation passes through the terminating and the originating networks. Alternatively, the price given in the pricing database may already include commissions, in which case the price confirmation will not be altered, but the specified price can be divided between the originating network, the terminating network, and the payable item source, according to predefined rules.

In an embodiment, when the price confirmation request is received by the originating network 110, the originating network 1 10 can determine whether the customer account 145, 182 has sufficient credit to pay for the requested payable item. Alternatively, the originating network 110 can determine whether the customer account 145, 182 has credit within a credit limit. It is noted that the credit limit may be adjusted as needed by the originating network 1 10, depending on various parameters such as a service class. It is also noted that the originating network 110 may authorize the customer holding the account 145, 182 to further decrease its own credit limit in general or for specific services, to a value below the credit limit set by the originating network 1 10.

Fig. 36 shows an example of a confirmation page 3610 that may be presented for the user via the browser. The confirmation page 3610 can include one or more of: an area 3620 indicative of the identity of the requested payable item, an area 3630 indicative of the price of the item and an area 3640 indicative of the name of the network that has successfully provided the authentication data (in this case, it is the originating network 1 10, which is represented in the area 3640 under the fictitious name "TY Telecom"). Other information may also be provided on the confirmation page. The user is prompted to confirm the information through interaction with the browser, e.g., by selecting either a confirm button 3650 or a cancel button 3660. Upon receiving confirmation from the user, the request handling entity 240 contacts the payable item source 235 (©),supplying it with at least part of the originally requested URL. In response, the payable item source 235 returns the requested payable item, in this case an app entitled "Application #2", to the request handling entity 240 (©). The request handling entity 240 forwards the app to the designated network entity 220 (®), which then forwards the app to the device 125 (⁽D) for usage and enjoyment by the user.

The billing flow is now described with reference to Fig. 5. Specifically, the terminating network 215 sends a service record indicative of a charge 5-A to the originating network 1 10 via an inter-organizational billing arrangement. As such, the originating network 110 will be informed that it owes the terminating network 215 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 5-A can be the price of the payable item plus a commission for the terminating network 215 plus a commission for the originating network 1 10, plus other commission, if the charging and payment collection happens through additional intermediaries. Alternatively, since the terminating network 215 determines the price of the payable item, the price of the payable item can already include a portion that constitutes a commission for the terminating network 215 and/or the originating network 1 10. This latter possibility is assumed here, along with a price of $4.95 for the payable item, thus making charge 5- A amount to $4.95.

It should be noted that in the following, a convention has been adopted whereby an arrow flowing from entity A to entity B and accompanied by a minus sign in front of a dollar amount represents entity B being charged the dollar amount by entity A.

The originating network 1 10 can then reconcile the service record received from the terminating network 215 with collected usage data and can transfer at least a portion of charge 5-A to the customer account 145, 182. This can be achieved by issuing a charge 5-B to the customer account 145, 182. As such, the entity responsible for the customer account 145, 182 will be informed that it owes the originating network 1 10 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 5-B can be the amount of charge 5-A plus a commission for the originating network 110. By way of non-limiting example, let the commission be $0.10, thus making charge 5-B amount to $4.95 + $0.10 = $5.05. Thus, the absolute value of charge 5-B can be greater than the absolute value of charge 5-A. Alternatively, the price indication given in the price confirmation request 3610 may already contain all the commissions due to the involved parties, so that charge 5-B will be equal to charge 5-A.

Reference is now made to Fig. 2B, which shows a simplified network architecture according to an alternative non-limiting embodiment of the present invention. The network architecture of Fig. 2B is similar to the network architecture of Fig. 2A, except that in this embodiment, the originating network 1 10 comprises a domain name server (DNS) 250* that handles queries issued by the device 125 whenever a new domain name is to be accessed, as well as a routing entity 255 that applies special routing to IP addresses in a designated pool. Specifically, when a message is to be routed to an IP address in the pool, it is known that such a message pertains to a request for a payable item, and therefore such a message is to be handled differently from messages destined for IP addresses that are not in the pool. Thus, when routing a message from the device 125 to a particular IP address (which would be obtained from the DNS 250*), the routing entity 255 checks to see if the IP address is in the designated pool. If it is in the pool, the routing entity 255 reroutes the message to the designated network entity 220 in the originating network 1 10. In contrast, if the IP address is not in the pool, then the routing entity 255 need not modify the destination of the message issued by the device 125.

Reference is now made to Fig. 2C which, to enhance security, introduces a network element 256 in the originating network 1 10 that is tasked with intercepting all requests sent to the designated network entity 220 and performing intrusion detection filtering and blocking on such requests. The network element 256 can be a standalone entity or it can be integrated with the designated network entity 220. If the result of intrusion detection filtering is that the request is considered as a true URL request and not as malicious (e.g., an attack), the request will be forwarded to / processed by the designated network entity 220 in the manner described above. Otherwise, the request can be blocked by the network element 256 and additional security measures could be instigated, such as deep packet inspection, launching an investigation, etc. In this way, suspicious user behavior with regard to payable services can be detected and blocked, possibly according to time-variant rules. In particular, too many requests for payable items from one IP address within a defined period of time or too many rejections of requested payable items at the price confirmation request can be used for blocking. USE CASE 1.2

Reference is made to Fig. 6, which shows a simplified network architecture according to a specific non-limiting embodiment of the present invention. Specifically, a terminating network 615 includes a request handling entity 640 that acts as a gateway to a payable item source 635 from which payable items can be accessed. Also, the data network 105 includes an optional proxy server 602 that acts as a gateway to a website 630. Other websites 690, 695 are similarly provided. In this embodiment, the payable item source 635 is under the control of the terminating network 615, but the website 630 is not. Thus, it can be said that the website 630 is independent of the terminating network 615, although it is not excluded that the website 630 could be under control of the terminating network 615 and/or implemented by the same computer as the payable item source 635.

Consider now that a user of the device 125 has established a connection over the originating network 1 10, the data network 105 and optionally the proxy server 602 in order to reach the website 630. For illustrative purposes, the website 630 is located at the URL www.arbitrary-website.com. In this embodiment, the website 630, which is maintained independently of the terminating network 615, presents a web page which, when displayed by a browser running on the device 125, may resemble what is shown in Fig. 8 by way of non-limiting example. The web page 800 can be one of several web pages stored in the memory of the website 630.

In this example, the terminating network 615, although it does not operate the website 630, has nonetheless developed a variety of software applications (apps) for a variety of devices, which are made available for download and are represented on the web page. The web page 800 includes an address bar 810 that indicates the URL of the web page. The web page also includes an advertisement window 820 containing at least one link of the second type 840 and, possibly, one or more links of the first type 830A, 830B. The advertisement window 820 may also include static content 820S that generally advertises the availability of apps for download.

In this example, link 830B whose label appears as "Calorie Counter" is a link of the first type (i.e., corresponding to a free app). This app may be stored on any given website (e.g., hosted by website 630, 690 or 695). The target associated with the free app is a URL pointing to the location from which the free app can be downloaded to the device 125 over the data network 105.

In contrast, link 840 whose label appears as "Friend Alert", is a link of the second type (i.e., corresponding to a payable app). This payable app may be stored by the payable item source 635. The targets associated with the payable apps are also URLs. However, to prevent these apps from being indiscriminately accessed over the data network 105, the domain names of the targets are modified. For example, the string "pay" could form part of the domain name, e.g., as a prefix. Alternatively, a code could appear either contiguously or scattered within the domain name. These modified domain names (or unique portions of domain names) corresponding to payable apps appear on a list held by the DNS 250 in the originating network 110. As will be seen below, the use of a modified domain name as part of the target of a link associated with a payable app forces the requestor of that link to pass through the request handling entity 640 in order to access the payable app.

With reference to Fig. 7, consider now that the user of the device 125 selects the link whose label appears as "Friend Alert". The website 630 returns the corresponding target with the modified domain name, e.g., the URL pay.deviceapps.com/friend-alert, to the device 125 over the previously established connection (©). The device 125 issues a DNS query to the DNS 250 based on the URL pay.deviceapps.com/app-2 (©). The DNS 250 recognizes that the domain name of the received URL is a listed domain name, e.g., due to the fact that the domain name of the received URL is prefixed by the string "pay". The DNS 250 thus returns the IP address of the designated network entity 220 in the originating network 1 10 (⁽D). The device 125 thus directs a message (e.g., an HTTP call), including at least part of the originally requested URL pay.deviceapps.com/friend-alert, to the designated network entity 220

(©)·

Assuming that the customer account 145, 182 was indeed found to subscribe to an online payment service, the identity of the customer account 145, 182, the contents of the message, the time and any other relevant information is collected by the designated network entity 220 as usage data. Based on the usage data for the present request and other requests made for other customer accounts, the designated network entity 220 will at some later time be able to reconcile charges received from the terminating network 615 in order to charge the appropriate customer account, in this case the customer account 145, 182.

The designated network entity 220 then formulates a payable item request for transmission to an appropriate request handling entity. In order to identify the IP address of the appropriate request handling entity to which it is to forward the payable item request, the designated network entity 220 consults a database or other resource based on the domain name of the originally requested URL. The database or other resource maintains information regarding which request handling entities in which terminating networks act as the gateways to the domain names where various payable items are stored. In this example, the appropriate request handling entity is found to be the request handling entity 640 in the terminating network 615.

The payable item request includes at least part of the originally requested URL (in this case, pay.deviceapps.com/friend-alert). In a non-limiting embodiment, the payable item request can be an HTTP call. If, in addition, the customer account 145, 182 was found to subscribe to an online payment service, the designated network entity 220 inserts authentication data into the payable item request. By way of non-limiting example, the authentication data can include an identifier of the originating network 1 10. For enhanced security, the authentication data can also include a version of this same identifier but encrypted with a private key of the originating network 1 10. The designated network entity 220 thus sends the payable item request to the request handling entity 640, e.g., over the data network 105 (©). Since the request handling entity 640 may be the gateway to multiple payable item sources, upon receipt of the payable item request from the designated network entity 220, the request handling entity 640 identifies the correct payable item source from which to retrieve the requested payable item. The correct payable item source can be identified based on part of the originally requested URL contained in the payable item request. In this example, the requested payable item is held by the payable item source 635.

If authentication data was supplied as part of the payable item request, the request handling entity 640 verifies the information (e.g., by a decryption technique as has been previously described). If the authentication data is successfully verified, this will reveal the identity of the entity to be charged for the requested payable item (in this case, it is the originating network 1 10).

Also, the request handling entity 640 determines the price of the requested payable item. The price can be obtained by consulting a pricing database or by querying the payable item source 635 directly. The request handling entity 640 then sends a message back to the designated network entity 220. The message causes a confirmation page to be rendered by the browser installed on the device 125. A non- limiting example of a confirmation page was described earlier with reference to Fig. 36. In addition, the message may also include a request for credit clearance destined for the designated network entity 220, to ensure that the originating network 110 will agree to be billed for the price of the requested payable item (plus a commission). Upon receiving confirmation from the user, the request handling entity 640 contacts the payable item source 635 (©), supplying it with at least part of the originally requested URL. In response, the payable item source 635 returns the requested payable item, in this case an app entitled "Friend Alert", to the request handling entity 640 (©). The request handling entity 640 forwards the app to the designated network entity 220 (®), which then forwards the app to the device 125 (®) for usage and enjoyment by the user.

The billing flow is now described with reference to Fig. 9. Specifically, the terminating network 615 sends a service record indicative of a charge 9-A to the originating network 1 10 via an inter-organizational billing arrangement. As such, the originating network 1 10 will be informed that it owes the terminating network 615 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 9-A can be the price of the payable item plus a commission for the terminating network 615. Alternatively, since the terminating network 215 determines the price of the payable item, the price of the payable item can already include a portion that constitutes a commission for the terminating network 615. This latter possibility is assumed here, along with a price of $0.75 for the payable item, thus making charge 9-A amount to $0.75. In addition, the service record contains data that allows the originating network 110 to reconcile the service record with previously collected usage data and thus transfer at least a portion of charge 9-A to the customer account 145, 182. This can be achieved by issuing a charge 9-B to the customer account 145, 182. As such, the entity responsible for the customer account 145, 182 will be informed that it owes the originating network 110 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 9-B can be the amount of charge 9-A plus a commission for the originating network 110. By way of non-limiting example, let the commission be $0.05, thus making charge 9-B amount to $0.75 + $0.05 = $0.80. USE CASE 1.3

Reference is made to Fig. 10, which shows a simplified network architecture according to a specific non-limiting embodiment of the present invention. Specifically, a terminating network 1015 includes a request handling entity 1040 that acts as a gateway to a payable item source 1035 from which payable items can be accessed. The payable item source 1035 is a third party source that has a supplier relationship with the terminating network 1015, i.e., in exchange for honoring a request for a payable item for which it is responsible, the payable item source 1035 (i.e., the third party) issues a charge to the terminating network 1015 for a certain sum. Also, the data network 105 includes an optional proxy server 1002 that acts as a gateway to a website 1030.

In this embodiment, neither the payable item source 1035 nor the website 1030 is under the control of the terminating network 1015; rather, they are both controlled by an entity 1045 that is independent of the terminating network 1015. For example, such an entity could be a news organization (hereinafter given the fictional name "Supreme News"), which offers free and payable news articles to devices connected to the data network 105.

In this embodiment, free news articles are accessed via the website 1030. For their part, payable news articles are only accessible via the payable item source 1035, which could be a secure portion/directory of the website 1030 that can only be accessed via the terminating network 1015.

Consider now that a user of the device 125 has established a connection over the originating network 1 10, the data network 105 and the optional proxy server 1002 in order to reach the website 1030. For illustrative purposes, the website 1030 is located at the URL www.supreme-news.com. In this embodiment, the website 1030, which is maintained independently of the terminating network 1015, presents a web page which, when displayed by a browser running on the device 125, may resemble what is shown in Fig. 12 by way of non-limiting example. The web page 1200 can be one of several web pages stored in the memory of the website 1030. In this example, Supreme News, the operator of the website www.supreme-news.com, has developed both free and payable news articles that are likely to be of interest to visitors of the www.supreme-news.com website. These articles are made available for download and thus are represented on the web page. The web page 1200 includes an address bar 1210 that indicates the URL of the web page. The web page also includes at least one link of the second type 1240A, 1240B and, possibly, one or more links of the first type 1230A, 1230B. Also provided is a window 1220 that generally advertises the availability of news articles for download, some of which are free and others of which are payable.

In addition, various graphics and associated text portions are provided, which are indicative of corresponding news articles. Specifically, each graphic and associated text portion is a label corresponding to a respective link, which is either a link of the first type (if the news article is free) or a link of the second type (if the news article is payable).

In this example, links 1230A and 1230B, whose labels appear as "Stocks Turn Cautious" and "Greek Rescue Deal Only Buys Time", respectively, are links of the first type (i.e., corresponding to free news articles). These news articles may be stored on the website 1030. The targets associated with the free news articles are URLs pointing to the locations from which the free news articles can be downloaded to the device 125 over the data network 105.

In contrast, links 1240 A, 1240B, whose labels appear as "Myrtle Clears Another Hurdle" and "Banks Are Open For Real-Estate Pain", respectively, are links of the second type (i.e., corresponding to payable news articles). This payable news articles may be stored by the payable item source 1035. The targets associated with the payable news articles are also URLs. However, to prevent these news articles from being indiscriminately accessed over the data network 105, the domain names of the targets are modified. For example, the string "pay" could form part of the domain name, e.g., as a prefix. Alternatively, a code could appear either contiguously or scattered within the domain name. These modified domain names (or unique portions of domain names) corresponding to payable news articles appear on a list held by the DNS 250 in the originating network 1 10. As will be seen below, the use of a modified domain name as part of the target of a link associated with a payable news article forces the requestor of that link to pass through the request handling entity 1040 in order to access the payable news article. With reference to Fig. 1 1 , consider now that the user of the device 125 selects the link 1240A whose label appears as "Myrtle Clears Another Hurdle". The website 1030 returns the corresponding target with the modified domain name, e.g., the URL pay.supreme-news.com/myrtle-clears-another-hurdle.html, to the device 125 over the previously established connection (©). The device 125 issues a DNS query to the DNS 250 based on the URL pay.supreme-news.com/myrfle-clears-anofher- hurdle.html (©). The DNS 250 recognizes that the domain name of the received URL is a listed domain name, e.g., due to the fact that the domain name of the received URL is prefixed by the string "pay". The DNS 250 thus returns the IP address of the designated network entity 220 in the originating network 1 10 (⁽D). The device 125 thus directs a message (e.g., an HTTP call), including at least part of the originally requested URL pay.supreme-news.com/myrtle-clears-another-hurdle.html, to the designated network entity 220 (©).

Assuming that the customer account 145, 182 was indeed found to subscribe to an online payment service, the identity of the customer account 145, 182, the contents of the message, the time and any other relevant information is collected by the designated network entity 220 as usage data. Based on the usage data for the present request and other requests made for other customer accounts, the designated network entity 220 will at some later time be able to reconcile charges received from the terminating network 1015 in order to charge the appropriate customer account, in this case the customer account 145, 182. The designated network entity 220 then formulates a payable item request for transmission to an appropriate request handling entity. In order to identify the IP address of the appropriate request handling entity to which it is to forward the payable item request, the designated network entity 220 consults a database or other resource based on the domain name of the originally requested URL. The database or other resource maintains information regarding which request handling entities in which terminating networks act as the gateways to the domain names where various payable items are stored. In this example, the appropriate request handling entity is found to be the request handling entity 1040 in the terminating network 1015.

The payable item request includes at least part of the originally requested URL (in this case, pay.supreme-news.com/myrtle-clears-another-hurdle.html). In a non-limiting embodiment, the payable item request can be an HTTP call. If, in addition, the customer account 145, 182 was found to subscribe to an online payment service, the designated network entity 220 inserts authentication data into the payable item request. By way of non-limiting example, the authentication data can include an identifier of the originating network 110. For enhanced security, the authentication data can also include a version of this same identifier but encrypted with a private key of the originating network 110. The designated network entity 220 thus sends the payable item request to the request handling entity 1040, e.g., over the data network 105 (⁽D).

Since the request handling entity 1040 may be the gateway to multiple payable item sources, upon receipt of the payable item request from the designated network entity 220, the request handling entity 1040 identifies the correct payable item source from which to retrieve the requested payable item. The correct payable item source can be identified based on part of the originally requested URL contained in the payable item request. In this example, the requested payable item is held by the payable item source 1035.

If authentication data was supplied as part of the payable item request, the request handling entity 1040 verifies the information (e.g., by a decryption technique as has been previously described). If the authentication data is successfully verified, this will reveal the identity of the entity to be charged for the requested payable item (in this case, it is the originating network 1 10).

Also, the request handling entity 1040 determines the price of the requested payable item. The price can be obtained by consulting a pricing database or by querying the payable item source 035 directly. The request handling entity 1040 then sends a message back to the designated network entity 220. The message causes a confirmation page to be rendered by the browser installed on the device 125. A non- limiting example of a confirmation page was described earlier with reference to Fig. 36. In addition, the message may also include a request for credit clearance destined for the designated network entity 220, to ensure that the originating network 1 10 will agree to be billed for the price of the requested payable item (plus a commission).

Upon receiving confirmation from the user, the request handling entity 1040 contacts the payable item source 1035 (©), supplying it with at least part of the originally requested URL. In response, the payable item source 1035 returns the requested payable item, in this case a news article entitled "Myrtle Clears Another Hurdle", to the request handling entity 1040 (©). Communication between the request handling entity 1040 and the payable item source 1035 may be encrypted for added security, and may traverse the data network 105. The request handling entity 1040 forwards the news article to the designated network entity 220 (®), which then forwards the news article to the device 125 (©) for usage and enjoyment by the user.

The billing flow is now described with reference to Fig. 13. Specifically, the payable item source 1035 (i.e., the entity 1045 with the name Supreme News) can send a service record indicative of a charge 13- A to the terminating network 1015. Charge 13-A reflects the price of the payable item. By way of non-limiting example, let charge 13-A be in the amount of $0.20. In an alternative embodiment, account consolidation between the entity 1045 and the request handling entity 1040 may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis).

The terminating network 1015 then sends a service record indicative of a charge 13-B to the originating network 1 10 via an inter-organizational billing arrangement. As such, the originating network 1 10 will be informed that it owes the terminating network 1015 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 13-B can be the amount of charge 13-A plus a commission for the terminating network 1015. By way of non-limiting example, let the commission be $0.01, which makes charge 13-B amount to $0.20 + $0.01 = $0.21.

In addition, the originating network 1 10 can then reconcile the service record with collected usage data and can transfer at least a portion of charge 13-B to the customer account 145, 182. This can be achieved by issuing a charge 13-C to the customer account 145, 182. As such, the entity responsible for the customer account 145, 182 will be informed that it owes the originating network 1 10 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 13-C can be the amount of charge 13-B plus a commission for the originating network 110. By way of non-limiting example, let the commission be $0.01, thus making charge 13-C amount to $0.21 + $0.01 = $0.22.

USE CASE 1.4 Reference is made to Fig. 14, which shows a simplified network architecture according to a specific non-limiting embodiment of the present invention. In this embodiment, there is provided a website 1430 capable of being accessed over the data network 105 via an optional proxy server 1402. Visitors to the website 1430 can create accounts and become members of portal, in this case a social network (in a style similar to Facebook, MySpace, etc.). In particular, members 1499 create their own pages on the website 1430 ("member pages") on which they can post information about themselves and via which they can be reached by other members. Visitors to the website 1430 can also browse existing members' pages. The website 1430 is controlled by a social network operator 1445, which allows

In addition, there is provided a terminating network 1415, which includes a request handling entity 1440 that acts as a gateway to a payable item source 1435 from which payable items can be accessed. The payable item source 1435 is controlled by the social network operator 1445. The payable item source 1435 has a supplier relationship with the terminating network 1415, i.e., in exchange for honoring a request for a payable item for which it is responsible, the payable item source 1435 (i.e., the social network operator 1445) issues a charge to the terminating network 1415 for a certain sum.

In this embodiment, the members 1499 of the social network interact with the website 1430 to modify the data corresponding to their member pages by posting thereto links to content that is freely available to other members, as well as links to items for purchase by other members. Interaction with the website 1499 can take place over the data network 105. It will be appreciated that the labels corresponding to the links to free content (i.e., links of the first type) and the labels corresponding to the links to payable items (i.e., links of the second type) may be specified/customized by the members themselves. This can include the use of text, graphics, etc. to make certain items appear attractive on a given member's page. Also, members provide the social network operator 1445 with the actual content that is to be freely available and that which is to be payable (e.g., by uploading this content over the data network 105). The payable content can then be transferred to the payable item source 1435 (e.g., stored in a secure directory or sent to a different server altogether) by the website 1430. Thus, it is to be understood that the social network operator 1445 controls where the content is to be stored and also controls the URLs that will be returned to a requestor who accesses a particular link via its user-defined label. To this end, the social network operator 1445 may provide a software tool or utility to assist members in the customization (i.e., customized creation) of the labels and in the entry/uploading of the content to be stored in association with those labels, while letting the social network operator 1445 formulate/determine the URLs to be associated with those labels.

The social network operator 1445 has a financial relationship with its members 1499, whereby the social network operator 1445 remunerates members who are successful at selling the content posted to their member pages to other members. The details of the remuneration scheme are immaterial; one suitable example among many other possibilities is for members to be rewarded by a monthly cheque, credit or bank transfer issued by the social network operator 1445. Consider now that a user of the device 125 has established a connection over the originating network 1 10, the data network 105 and the optional proxy server 1402 in order to reach the website 1430. For illustrative purposes, the website 1430 is located at the URL www.social-network.com. In this embodiment, the user, who may but need not be a member of the social network, enters the social network and accesses a page belonging to a member whom the user is interested in, say John Smith. John Smith's page, referred to as a member page, is displayed by the user's browser and may resemble what is shown in Fig. 16 by way of non-limiting example. John Smith's page 1600 includes an address bar 1610 that indicates the URL of the page.

In this example, John Smith has developed both free and payable content that is likely to be of interest to visitors of John Smith's page 1600. This content is represented on John Smith's page 1600 by a set of links. For the purposes of the present example, let the content include recipes amassed by John Smith, some of which he wishes to render available for free (i.e., free recipes) and others of which he wishes to charge for (i.e., payable recipes). The link representing each recipe can include a title, a photograph and a rating by other users. The link representing each recipe may also include an icon to indicate whether the recipe is free or payable. For example, a link of the second type (i.e., representing a payable recipe) may include a dollar sign or the actual price, while a link of the first type (i.e., representing a free recipe) may include the word "free". The manner in which the recipes are represented on John Smith's page using text, graphics, photographs, etc. can be personalized to a certain degree by John Smith, while respecting certain criteria imposed by the social network operator. John Smith's page 1600 may also include static content 1620 that generally advertises the availability of recipes for download.

In this example, link 1630, whose label appears as "Quick And Easy Mac & Cheese" is a link of the first type (i.e., corresponding to a free recipe). This recipe may be stored on the website 1430 in a directory dedicated to John Smith's free items. The target associated with this free recipe is a URL pointing to the location from which the free recipe can be downloaded to the device 125 over the data network 105. For example, the target could be www.social-network.com/John-Smith/free/quick-and- easy-mac-and-cheese.html. In contrast, link 1640, whose label appears as "John's Special Creme Brulee", is a link of the second type (i.e., corresponding to a payable recipe). This payable recipe may be stored by the payable item source 1435. The target associated with the payable recipe is also a URL. However, to prevent this recipe from being indiscriminately accessed over the data network 105, the domain name of the target is modified. For example, the string "pay" could form part of the domain name, e.g., as the top-level domain. This modified domain name (or unique portion of a domain name) corresponding to the payable recipe appears on a list held by the DNS 250 in the originating network 1 10. As will be seen below, the use of a modified domain name as part of the target of a link associated with a payable recipe forces the requestor of that link to pass through the request handling entity 1440 in order to access the payable recipe.

With reference to Fig. 15, consider now that the user of the device 125 selects the link 1630 whose label appears as "John's Special Creme Brulee". The website 1430 returns the corresponding target with the modified domain name, e.g., the URL www.social-network.pay/Jorm-Smith/johns-special-creme-brulee.html, to the device 125 over the previously established connection (CD). The device 125 issues a DNS query to the DNS 250 based on the URL www.social-network.pay/John-Smith/johns- special-creme-brulee.html (©). The DNS 250 recognizes that the domain name of the received URL is a listed domain name, e.g., due to the fact that the top-level domain of the received URL includes the string "pay". The DNS 250 thus returns the IP address of the designated network entity 220 in the originating network 1 10 (®). The device 125 thus directs a message (e.g., an HTTP call), including at least part of the originally requested URL www.social-network.pay/John-Smith/johns-special-creme- brulee.html, to the designated network entity 220 (©).

The designated network entity 220 recognizes that the message received from the device 125 is a request for a payable item for the customer account 145, 182. The designated network entity 220 decides whether to accept to be charged on behalf of the customer account 145, 182. For example, the designated network entity 220 can verify (e.g., by consulting a database) whether the customer account 145, 182 subscribes to an online payment service. Assuming that the customer account 145, 182 was indeed found to subscribe to an online payment service, the identity of the customer account 145, 182, the contents of the message, the time and any other relevant information is collected by the designated network entity 220 as usage data. Based on the usage data for the present request and other requests made for other customer accounts, the designated network entity 220 will at some later time be able to reconcile charges received from the terminating network 1415 in order to charge the appropriate customer account, in this case the customer account 145, 182. The designated network entity 220 then formulates a payable item request for transmission to an appropriate request handling entity. In order to identify the IP address of the appropriate request handling entity to which it is to forward the payable item request, the designated network entity 220 consults a database or other resource based on the domain name of the originally requested URL. The database or other resource maintains information regarding which request handling entities in which terminating networks act as the gateways to the domain names where various payable items are stored. In this example, the appropriate request handling entity is found to be the request handling entity 1440 in the terminating network 1415. The payable item request includes at least part of the originally requested URL (in this case, www.social-network.pay/John-Smith/johns-special-creme-brulee.html). In a non-limiting embodiment, the payable item request can be an HTTP call. If, in addition, the customer account 145, 182 was found to subscribe to an online payment service, the designated network entity 220 inserts authentication data into the payable item request. By way of non-limiting example, the authentication data can include an identifier of the originating network 1 10. For enhanced security, the authentication data can also include a version of this same identifier but encrypted with a private key of the originating network 1 10. The designated network entity 220 thus sends the payable item request to the request handling entity 1440, e.g., over the data network 105 (CD).

Since the request handling entity 1440 may be the gateway to multiple payable item sources, upon receipt of the payable item request from the designated network entity 220, the request handling entity 1440 identifies the correct payable item source from which to retrieve the requested payable item. The correct payable item source can be identified based on part of the originally requested URL contained in the payable item request. In this example, the requested payable item is held by the payable item source 1435.

If authentication data was supplied as part of the payable item request, the request handling entity 1440 verifies the information (e.g., by a decryption technique as has been previously described). If the authentication data is successfully verified, this will reveal the identity of the entity to be charged for the requested payable item (in this case, it is the originating network 1 10).

Also, the request handling entity 1440 determines the price of the requested payable item. The price can be obtained by consulting a pricing database or by querying the payable item source 1435 directly. The request handling entity 1440 then sends a message back to the designated network entity 220. The message causes a confirmation page to be rendered by the browser installed on the device 125. A non- limiting example of a confirmation page was described earlier with reference to Fig. 36. In addition, the message may also include a request for credit clearance destined for the designated network entity 220, to ensure that the originating network 110 will agree to be billed for the price of the requested payable item (plus a commission).

Upon receiving confirmation from the user, the request handling entity 1440 contacts the payable item source 1435 (©), supplying it with at least part of the originally requested URL. In response, the payable item source 1435 returns the requested payable item, in this case a recipe entitled "John's Special Creme Brulee", to the request handling entity 1440 (©). Communication between the request handling entity 1440 and the payable item source 1435 may be encrypted for added security, and may traverse the data network 105. The request handling entity 1440 forwards the recipe to the designated network entity 220 (⁽D), which then forwards the recipe to the device 125 (⁽D) for usage and enjoyment by the user.

The billing flow is now described with reference to Fig. 17. Specifically, the payable item source 1435 (i.e., the social network operator 1445) can send a service record indicative of a charge 17- A to the terminating network 1415. Charge 17- A reflects the price of the payable item. By way of non-limiting example, let charge 17-A be in the amount of $0.20. In an alternative embodiment, account consolidation between the social network operator 1445 and the request handling entity 1440 may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis).

The terminating network 1415 then sends a service record indicative of a charge 17-B to the originating network 110 via an inter-organizational billing arrangement. As such, the originating network 110 will be informed that it owes the terminating network 1415 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 17-B can be the amount of charge 17-A plus a commission for the terminating network 1415. By way of non-limiting example, let the commission be $0.01, which makes charge 17-B amount to $0.20 + $0.01 = $0.21. In addition, the originating network 1 10 can then reconcile the service record with collected usage data and can transfer at least a portion of charge 17-B to the customer account 145, 182. This can be achieved by issuing a charge 17-C to the customer account 145, 182. As such, the entity responsible for the customer account 145, 182 will be informed that it owes the originating network 1 10 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 17-C can be the amount of charge 17-B plus a commission for the originating network 1 10. By way of non-limiting example, let the commission be $0.01, thus making charge 17-C amount to $0.21 + $0.01 = $0.22. Finally, the social network operator 1445, which is being paid $0.20 by the terminating network 1415 in exchange for John's special creme brulee recipe, will remunerate John Smith for the successful sale of his recipe. This can result in a payment 17-D of $0.20 to John Smith (or his member account with the social network operator 1445) in the form of a cheque, credit or bank transfer. In some embodiments, the social network operator 1445 can keep a commission for itself, in which case for the purposes of the present non-limiting example the payment 17-D to John Smith may be somewhat less than $0.20. This payment may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis), rather than each time one of John Smith's payable recipes is downloaded by a user. USE CASE 1.5

Reference is made to Fig. 18, which shows a simplified network architecture according to a specific non-limiting embodiment of the present invention. In this embodiment, there is provided a website 1830 capable of being accessed over the data network 105 via an optional proxy server 1802. The website 1830 is controlled by a digital mall operator 1845 that serves as a portal for members (in the following, specifically referred to as "merchants"). Specifically, merchants 1899 create their own virtual stores on the website 1830, through which they offer items for sale, such as greeting cards, recipes, etc.

In addition, there is provided a terminating network 1815, which includes a request handling entity 1840 that acts as a gateway to a payable item source 1835 from which payable items can be accessed. The payable item source 1835 is controlled by the digital mall operator 1845. The payable item source 1835 has a supplier relationship with the terminating network 1815, i.e., in exchange for honoring a request for a payable item for which it is responsible, the payable item source 1835 (i.e., the digital mall operator 1845) issues a charge to the terminating network 1815 for a certain sum.

In this embodiment, the merchants 1899 interact with the website 1830 to modify the data for their virtual stores by posting thereto links to content that is freely available to internet shoppers, as well as links to items for purchase. It will be appreciated that the labels corresponding to the links to free content (i.e., links of the first type) and the labels corresponding to the links to payable items (i.e., links of the second type) may be specified by the merchants. This can include the use of text, graphics, etc. to make certain items appear attractive in a given merchant's store. Also, merchants provide the digital mall operator 1845 with the actual content that is to be freely available and that which is to be payable (e.g., by uploading this content over the data network 105). However, it is the digital mall operator 1845 that controls where the content is to be stored and also controls the URLs that will be returned to a requestor who accesses a particular link via its user-defined label. To this end, the digital mall operator 1845 may provide a software tool or utility to assist merchants in the creation of the labels and in the entry of the content to be stored in association with those labels, while letting the digital mall operator 1845 determine the URLs to be associated with those labels.

The digital mall operator 1845 has a financial relationship with its merchants 1899, whereby the digital mall operator 1845 remunerates merchants who are successful at selling the content through their virtual stores to internet shoppers. The details of the remuneration scheme are immaterial; one suitable example among many other possibilities is for merchants to be rewarded by a monthly cheque, credit or bank transfer issued by the digital mall operator 1845.

Consider now that a user of the device 125 has established a connection over the originating network 1 10, the data network 105 and the optional proxy server 1802 in order to reach the website 1830. For illustrative purposes, the website 1830 is located at the URL www.digital-mall.com. In this embodiment, the user enters the digital mall and accesses a store belonging to a particular merchant, say E-Cards, which sells electronic greeting cards. The E-Cards page, referred to as a merchant page, is displayed by the user's browser and may resemble what is shown in Fig. 20 by way of non-limiting example. The E-Cards page 2000 includes an address bar 2010 that indicates the URL of the page.

In this example, E-Cards has developed both free and payable electronic greeting cards that are likely to be of interest to visitors of the E-Cards page 2000. These greeting cards are represented on the E-Cards page 2000 by a set of links. For the purposes of the present example, some of the greeting cards offered by E-Cards are available for free (i.e., free greeting cards) and others are available for a fee (i.e., payable greeting cards). The link representing each greeting card can include a title, a photograph and a price if applicable. The manner in which the greeting cards are represented on the E-Cards page using text, graphics, photographs, etc. can be personalized to a certain degree by E-Cards, while respecting certain criteria imposed by the digital mall operator. The E-Cards page 2000 may also include static content 2020 that generally advertises the availability of greeting cards.

In this example, link 2030, whose label appears as "Thinking Of You" (and may include a flower graphic) is a link of the first type (i.e., corresponding to a free greeting card). This greeting card may be stored on the website 1830 in a directory dedicated to E-Cards' free items. The target associated with this free greeting card is a URL pointing to the location from which the free greeting card can be downloaded to the device 125 over the data network 105. For example, the target could be www.digital-mall.com/E-Cards/free/thinking-of-you.html.

In contrast, link 2040, whose label appears as "Rocky Mountain Hi!" (and may include a mountain graphic) is a link of the second type (i.e., corresponding to a payable greeting card). This payable greeting card may be stored by the payable item source 1835. The target associated with the payable recipe is also a URL. However, to prevent this payable greeting from being indiscriminately accessed over the data network 105, the domain name of the target is modified. For example, the string "pay" could form part of the domain name, e.g., as a prefix. Alternatively, a code could appear either contiguously or scattered within the domain name. This modified domain name (or unique portion of a domain name) corresponding to the payable greeting card appears on a list held by the DNS 250 in the originating network 1 10. As will be seen below, the use of a modified domain name as part of the target of a link associated with a payable greeting card forces the requestor of that link to pass through the request handling entity 1840 in order to access the payable greeting card.

With reference to Fig. 19, consider now that the user of the device 125 selects the link 2030 whose label appears as "Rocky Mountain Hi!". The website 1830 returns the corresponding target with the modified domain name, e.g., the URL pay.digital- mall.com/E-Cards/Rocky-Mountain-Hi, to the device 125 over the previously established connection (©). The device 125 issues a DNS query to the DNS 250 based on the URL pay.digital-mall.com/E-Cards/Rocky-Mountain-Hi (©). The DNS 250 recognizes that the domain name of the received URL is a listed domain name, e.g., due to the fact that the domain name of the received URL is prefixed by the string "pay". The DNS 250 thus returns the IP address of the designated network entity 220 in the originating network 1 10 (⁽D). The device 125 thus directs a message (e.g., an HTTP call), including at least part of the originally requested URL pay.digital-mall.com/E-Cards/Rocky-Mountain-Hi, to the designated network entity 220 (©). The designated network entity 220 recognizes that the message received from the device 125 is a request for a payable item for the customer account 145, 182. The designated network entity 220 decides whether to accept to be charged on behalf of the customer account 145, 182. For example, the designated network entity 220 can verify (e.g., by consulting a database) whether the customer account 145, 182 subscribes to an online payment service.

Assuming that the customer account 145, 182 was indeed found to subscribe to an online payment service, the identity of the customer account 145, 182, the contents of the message, the time and any other relevant information is collected by the designated network entity 220 as usage data. Based on the usage data for the present request and other requests made for other customer accounts, the designated network entity 220 will at some later time be able to reconcile charges received from the terminating network 1815 in order to charge the appropriate customer account, in this case the customer account 145, 182.

The designated network entity 220 then formulates a payable item request for transmission to an appropriate request handling entity. In order to identify the IP address of the appropriate request handling entity to which it is to forward the payable item request, the designated network entity 220 consults a database or other resource based on the domain name of the originally requested URL. The database or other resource maintains information regarding which request handling entities in which terminating networks act as the gateways to the domain names where various payable items are stored. In this example, the appropriate request handling entity is found to be the request handling entity 1840 in the terminating network 1815.

The payable item request includes at least part of the originally requested URL (in this case, pay.digital-mall.com/E-Cards/Rocky-Mountain-Hi). In a non-limiting embodiment, the payable item request can be an HTTP call. If, in addition, the customer account 145, 182 was found to subscribe to an online payment service, the designated network entity 220 inserts authentication data into the payable item request. By way of non-limiting example, the authentication data can include an identifier of the originating network 110. For enhanced security, the authentication data can also include a version of this same identifier but encrypted with a private key of the originating network 1 10. The designated network entity 220 thus sends the payable item request to the request handling entity 1840, e.g., over the data network 105 (⁽D). Since the request handling entity 1840 may be the gateway to multiple payable item sources, upon receipt of the payable item request from the designated network entity 220, the request handling entity 1840 identifies the correct payable item source from which to retrieve the requested payable item. The correct payable item source can be identified based on part of the originally requested URL contained in the payable item request. In this example, the requested payable item is held by the payable item source 1835.

If authentication data was supplied as part of the payable item request, the request handling entity 1840 verifies the information (e.g., by a decryption technique as has been previously described). If the authentication data is successfully verified, this will reveal the identity of the entity to be charged for the requested payable item (in this case, it is the originating network 1 10).

Also, the request handling entity 1840 determines the price of the requested payable item. The price can be obtained by consulting a pricing database or by querying the payable item source 1835 directly. The request handling entity 1840 then sends a message back to the designated network entity 220. The message causes a confirmation page to be rendered by the browser installed on the device 125. A non- limiting example of a confirmation page was described earlier with reference to Fig. 36. In addition, the message may also include a request for credit clearance destined for the designated network entity 220, to ensure that the originating network 110 will agree to be billed for the price of the requested payable item (plus a commission).

Upon receiving confirmation from the user, the request handling entity 1840 contacts the payable item source 1835 (©), supplying it with at least part of the originally requested URL. In response, the payable item source 1835 returns the requested payable item, in this case an electronic greeting card entitled "Rocky Mountain Hi!", to the request handling entity 1840 (©). Communication between the request handling entity 1840 and the payable item source 1835 may be encrypted for added security, and may traverse the data network 105. The request handling entity 1840 forwards the greeting card to the designated network entity 220 (⁽D), which then forwards the greeting card to the device 125 (©) for usage and enjoyment by the user. This may involve further interaction between the device 125 and the website 1830 in order to ultimately trigger transmission of the greeting card to a desired recipient.

The billing flow is now described with reference to Fig. 21. Specifically, the payable item source 1835 (i.e., the digital mall operator 1845) can send a service record indicative of a charge 21 -A to the terminating network 1815. Charge 21 -A reflects the price of the payable item. By way of non-limiting example, let charge 21 -A be in the amount of $0.20. In an alternative embodiment, account consolidation between the digital mall operator 1845 and the request handling entity 1840 may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis). The terminating network 1815 then sends a service record indicative of a charge 21-B to the originating network 1 10 via an inter-organizational billing arrangement. As such, the originating network 1 10 will be informed that it owes the terminating network 1815 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 21-B can be the amount of charge 21 -A plus a commission for the terminating network 1815. By way of non-limiting example, let the commission be $0.01, which makes charge 21-B amount to $0.20 + $0.01 = $0.21.

In addition, the originating network 1 10 can then reconcile the service record with collected usage data and can transfer at least a portion of charge 21-B to the customer account 145, 182. This can be achieved by issuing a charge 21-C to the customer account 145, 182. As such, the entity responsible for the customer account 145, 182 will be informed that it owes the originating network 1 10 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 21-C can be the amount of charge 21 -B plus a commission for the originating network 1 10. By way of non-limiting example, let the commission be $0.01, thus making charge 21 -C amount to $0.21 + $0.01 = $0.22. Finally, the digital mall operator 1845, which is being paid $0.20 by the terminating network 1815 in exchange for the Rocky Mountain Hi! Greeting card, will remunerate E-Cards for the successful sale of its electronic greeting card. This can result in a payment 21-D of $0.20 to E-Cards in the form of a cheque, credit or bank transfer. In some embodiments, the digital mall operator 1845 can keep a commission for itself, in which case for the purposes of the present non-limiting example the payment 21-D to E-Cards may be somewhat less than $0.20. This payment may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis), rather than each time one of E-Cards' payable greeting cards is downloaded by a user.

USE CASE 1.6

Reference is made to Fig. 22, which shows a simplified network architecture according to a specific non-limiting embodiment of the present invention. Specifically, a terminating network 2215 includes a request handling entity 2240 that acts as a gateway to a payable item source 2235 from which payable items can be accessed. Also, the data network 105 optionally includes a proxy server 2202 that acts as a gateway to a website 2230. Other websites 2290, 2295 are similarly provided.

In this embodiment, the payable item source 2235 is part of an e-commerce portal, which can be independent of the terminating network 2215. The e-commerce portal serves as an e-commerce platform for hosting payable items on behalf of various registered members (e.g., merchants), while allowing those merchants to post links to these payable items wherever it may please them on the internet, such as on the websites 2230, 2290, 2295. In such a scenario, the e-commerce portal has a supplier relationship with the terminating network 2215, i.e., in exchange for honoring a request for a payable item for which it is responsible, the payable item source 2235 (i.e., the e-commerce portal) issues a charge to the terminating network 2215 for a certain sum.

In this embodiment, merchants interact with the website 2230 to post advertisements consisting of links to content that is freely available, as well as links to items that can be purchased. It will be appreciated that the labels corresponding to the links to free content (i.e., links of the first type) and the labels corresponding to the links to payable items (i.e., links of the second type) may be specified by the merchants themselves. This can include the use of text, graphics, etc. to make certain items appear attractive on the website 2230. Also, merchants have the freedom to host the free content anywhere they choose. However, the payable content is hosted by the payable item source 2235. Moreover, it is the e-commerce portal that instructs the merchant what URL to use as the target for the link to a given payable item that is being hosted by the payable item source 2235. To this end, the e-commerce portal may provide a software tool or utility to assist merchants in the creation of the labels and in the entry of the content to be stored in association with those labels, while letting the e-commerce portal determine the URLs to be associated with those labels.

The e-commerce portal has a financial relationship with the registered merchants, whereby the e-commerce portal remunerates merchants who are successful at selling the payable items hosted by the payable item source 2235. The details of the remuneration scheme are immaterial; one suitable example among many other possibilities is for merchants to be rewarded by a monthly cheque, credit or bank transfer issued by the e-commerce portal. Consider now that a user of the device 125 has established a connection over the originating network 1 0, the data network 105 and the optional proxy server 2202 in order to reach the website 2230. For illustrative purposes, the website 2230 is located at the URL www.arbitrary-website.com. In this embodiment, the website 2230 presents a web page which, when displayed by a browser running on the device 125, may resemble what is shown in Fig. 24 by way of non-limiting example. The web page 2400 can be one of several web pages stored in the memory of the website 2230.

In this example, a given registered merchant (hereinafter given the fictional name "Supreme Sports") sells video compilations of recent sports highlights that are deemed to be of potential interest to visitors of the website 2230. These video compilations are made available for download and are represented on the web page. Accordingly, the web page 2400 includes an address bar 2410 that indicates the URL of the web page. The web page also includes an advertisement window 2420 containing one or more links of the second type 2440A, 2440B and, possibly, one or more links of the first type 2430. The advertisement window 2420 may also include static content 2420S that generally advertises the availability of video compilations for download. In addition, various graphics and associated text portions are provided, which are indicative of corresponding apps. Specifically, each graphic and associated text portion is a label corresponding to a respective link, which is either a link of the first type (if the video compilation is free) or a link of the second type (if the video compilation is payable).

In this example, link 2430 whose label appears as "NFL" is a link of the first type (i.e., corresponding to a free video compilation). This video compilation may be stored on any given website (e.g., hosted by website 2230, 2290 or 2295). The target associated with the free video compilation is a URL pointing to the location from which the free video compilation can be downloaded to the device 125 over the data network 105.

In contrast, links 2440A, 2440B whose labels appear as "NHL" and "NCAA", respectively, are links of the second type (i.e., corresponding to payable video compilations). These payable video compilations may be stored by the payable item source 2235. The targets associated with the payable video compilations are also URLs. However, to prevent these video compilations from being indiscriminately accessed over the data network 105, the domain names of the targets are modified. For example, the string "pay" could form part of the domain name, e.g., as a prefix. Alternatively, a code could appear either contiguously or scattered within the domain name. These modified domain names (or unique portions of domain names) corresponding to payable video compilations appear on a list held by the DNS 250 in the originating network 1 10. As will be seen below, the use of a modified domain name as part of the target of a link associated with a payable video compilation forces the requestor of that link to pass through the request handling entity 2240 in order to access the payable video compilation.

With reference to Fig. 23, consider now that the user of the device 125 selects the link whose label appears as "NHL". The website 2230 returns the corresponding target with the modified domain name, e.g., the URL pay.portal.com/supreme- sports NHL.html, to the device 125 over the previously established connection (©). The device 125 issues a DNS query to the DNS 250 based on the URL pay.portal.com/supreme-sports/NHL.html (©). The DNS 250 recognizes that the domain name of the received URL is a listed domain name, e.g., due to the fact that the domain name of the received URL is prefixed by the string "pay". The DNS 250 thus returns the IP address of the designated network entity 220 in the originating network 1 10 ((D). The device 125 thus directs a message (e.g., an HTTP call), including at least part of the originally requested URL pay.portal.com/supreme- sports/NHL.html, to the designated network entity 220 (©).

Assuming that the customer account 145, 182 was indeed found to subscribe to an online payment service, the identity of the customer account 145, 182, the contents of the message, the time and any other relevant information is collected by the designated network entity 220 as usage data. Based on the usage data for the present request and other requests made for other customer accounts, the designated network entity 220 will at some later time be able to reconcile charges received from the terminating network 2215 in order to charge the appropriate customer account, in this case the customer account 145, 182.

The designated network entity 220 then formulates a payable item request for transmission to an appropriate request handling entity. In order to identify the IP address of the appropriate request handling entity to which it is to forward the payable item request, the designated network entity 220 consults a database or other resource based on the domain name of the originally requested URL. The database or other resource maintains information regarding which request handling entities in which terminating networks act as the gateways to the domain names where various payable items are stored. In this example, the appropriate request handling entity is found to be the request handling entity 2240 in the terminating network 2215.

The payable item request includes at least part of the originally requested URL (in this case, pay.portal.com/supreme-sports/NHL.html). In a non-limiting embodiment, the payable item request can be an HTTP call. If, in addition, the customer account 145, 182 was found to subscribe to an online payment service, the designated network entity 220 inserts authentication data into the payable item request. By way of non- limiting example, the authentication data can include an identifier of the originating network 1 10. For enhanced security, the authentication data can also include a version of this same identifier but encrypted with a private key of the originating network 1 10. The designated network entity 220 thus sends the payable item request to the request handling entity 2240, e.g., over the data network 105 (⁽D). Since the request handling entity 2240 may be the gateway to multiple payable item sources, upon receipt of the payable item request from the designated network entity 220, the request handling entity 2240 identifies the correct payable item source from which to retrieve the requested payable item. The correct payable item source can be identified based on part of the originally requested URL contained in the payable item request. In this example, the requested payable item is held by the payable item source 2235.

If authentication data was supplied as part of the payable item request, the request handling entity 2240 verifies the information (e.g., by a decryption technique as has been previously described). If the authentication data is successfully verified, this will reveal the identity of the entity to be charged for the requested payable item (in this case, it is the originating network 1 10).

Also, the request handling entity 2240 determines the price of the requested payable item. The price can be obtained by consulting a pricing database or by querying the payable item source 2235 directly. The request handling entity 2240 then sends a message back to the designated network entity 220. The message causes a confirmation page to be rendered by the browser installed on the device 125. A non- limiting example of a confirmation page was described earlier with reference to Fig. 36. In addition, the message may also include a request for credit clearance destined for the designated network entity 220, to ensure that the originating network 1 10 will agree to be billed for the price of the requested payable item (plus a commission). Upon receiving confirmation from the user, the request handling entity 2240 contacts the payable item source 2235 (©), supplying it with at least part of the originally requested URL. In response, the payable item source 2235 returns the requested payable item, in this case a video compilation of NHL highlights, to the request handling entity 2240 (©). Communication between the request handling entity 2240 and the payable item source 2235 may be encrypted for added security, and may traverse the data network 105. The request handling entity 2240 forwards the video compilation to the designated network entity 220 (®), which then forwards the video compilation to the device 125 (⁽D) for usage and enjoyment by the user. The billing flow is now described with reference to Fig. 25. Specifically, the payable item source 2235 (i.e., the e-commerce portal) can send a service record indicative of a charge 25-A to the terminating network 2215. Charge 25-A reflects the price of the payable item. By way of non-limiting example, let charge 25-A be in the amount of $0.25. In an alternative embodiment, account consolidation between the e-commerce portal and the request handling entity 2240 may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis).

The terminating network 2215 then sends a service record indicative of a charge 25-B to the originating network 110 via an inter-organizational billing arrangement. As such, the originating network 1 10 will be informed that it owes the terminating network 2215 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 25-B can be the amount of charge 25-A plus a commission for the terminating network 2215. By way of non-limiting example, let the commission be $0.01 , which makes charge 25-B amount to $0.25 + $0.01 = $0.26.

In addition, the originating network 110 can then reconcile the service record with collected usage data and can transfer at least a portion of charge 25-B to the customer account 145, 182. This can be achieved by issuing a charge 25-C to the customer account 145, 182. As such, the entity responsible for the customer account 145, 182 will be informed that it owes the originating network 1 10 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 25-C can be the amount of charge 25-B plus a commission for the originating network 110. By way of non-limiting example, let the commission be $0.01 , thus making charge 25-C amount to $0.26 + $0.01 = $0.27.

Finally, the e-commerce portal, which is being paid $0.25 by the terminating network 2215 in exchange for the NHL video compilation, will remunerate Supreme Sports for the successful sale of its video compilation. This can result in a payment 25-D of $0.25 to Supreme Sports in the form of a cheque, credit or bank transfer. In some embodiments, the e-commerce portal can keep a commission for itself, in which case for the purposes of the present non-limiting example the payment 25-D to Supreme Sports may be somewhat less than $0.25. This payment may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis), rather than each time one of Supreme Sports' video compilations is downloaded by a user.

VARIANT In a variant of the above use cases, consider the situation where the DNS 250 is not aware of any special domain names that correspond to requests for payable items. In such a situation, and with reference again to Fig. 10, it is contemplated that the website 1030 may have the responsibility for detecting when a request for a payable item is being made. To this end, it is assumed that the website 1030 knows, from among the links that it renders available over the data network 105, which are associated with free news articles and which are associated with payable news articles. Moreover, the website 1030 is configured for detecting when a link associated with a payable news article has been selected by a requestor and, in response, for presenting the requestor with an opportunity to identify an organization that is to agree to be billed on behalf of the requestor.

More particularly, reference is made to Fig. 26, which is based on the architecture of Fig. 10. Consider that a user of the device 125 has established a connection over the originating network 110 and the data network 105 in order to reach the website 1030 via the optional proxy server 1002 (©). It is recalled that in the non-limiting example of Fig. 10, the website 1030 was located at the URL www.supreme-news.com. Also, it is recalled that in the non-limiting example of Fig. 10, the website 1030 presented a web page which, when displayed by a browser, may resemble what was shown in Fig. 12.

Consider now that the user of the device 125 selects the link 1240A whose label appears as "Myrtle Clears Another Hurdle". It is recalled that the corresponding target is the URL pay.supreme-news.com/myrtle-clears-another-hurdle.html. However, before returning this URL to the device 125, the website 1030 detects (e.g., on the basis of the URL) that the requested news article is a payable news article (©). Accordingly, the website 1030 redirects the device 125 to a "payment options web page" that presents a set of payment options. It should be appreciated that redirection can be accomplished in the form of an HTTP call that preserves, at least in part, the originally requested URL (namely, pay.supreme-news.com/myrtle-clears-another- hurdle.html).

The payment options web page to which the device 125 is redirected can be part of the website 1030 (©A) or it can be located on a separate payment locator website 2600 (®B).

Fig. 27 shows a non-limiting example of a payment options web page 2700 as it could be rendered by a browser. The payment options web page 2700 presents a region 2740 that indicates to the user of the browser that a selection of a payment option is being sought. The payment options web page 2700 also presents a region 2720 that presents at least one home organization payment option 2720 and, possibly, a region 2730 that presents one or more other payment options, such as conventional payment options including credit card, Google Checkout™, PayPal™, etc. A home organization payment option is a payment option that identifies a selectable participating organization whose financial relationship with the terminating network 1015 (through which the requested payable item is accessed) and with its own customers can be leveraged to settle payment for the payable item being requested. The organizations identified by the at least one home organization payment option presented in region 2720 can be determined in advance and kept updated by the website 1030 and/or the payment locator website 2600. In the present example, the at least one home organization payment option presented in region 2720 is assumed to identify, among other organizations, the originating network 1 10 which maintains the customer account 145, 182.

Returning to Fig. 26, by interacting with the browser, the user of the device 125 can select one of the payment options presented by the payment options web page 2700. In the present example, it is assumed that the user has elected to pay using the originating network 1 10 by selecting from the at least one home organization payment option presented in region 2720. The entity running the payment options web page 2700 (namely, the website 1030 or the payment locator website 2600) then redirects the device 125 to the designated network entity 220 in the originating network 1 10. This can be accomplished by way of an HTTP call that preserves, at least in part, the originally requested URL (namely, pay.supreme-news.com/myrtle-clears-another- hurdle.html) (®). The remainder of the description is the same as was described above in items (⁽D) through (®) in connection with Fig. 1 1.

SECOND SET OF USE CASES

In the second set of use cases below (2.1 through 2.2), the originating network 110 is considered to be separate from the participating organization 26. That is to say, the originating network 110 simply serves as a conduit to allow the device 125 to access the data network 105. As such, the originating network 1 10 may be any configuration that allows the device 125 to access the data network 105 by virtue of the customer account 182, e.g., from a residential access point, a mobile network, a public access point (e.g., wirelessly or non-wirelessly, at a hotel or restaurant, etc.), and so on. For its part, the participating organization 26 agrees to be billed for payable items requested by the user of the device 125. As such, the participating organization 26 can be a telecommunications carrier (mobile or landline), an internet service provider, a utility (electric, phone, cable, gas, etc.), a bank, a credit card facility, or another institution with which the user of the device has set up the customer account 145. In the second set of use cases to follow, therefore, the customer account 182 (maintained by the originating network 1 10) and the customer account 145 (maintained by the participating organization 26) are completely separate customer accounts.

USE CASE 2.1

Reference is now made to Fig. 28, which shows a simplified network architecture according to a specific non-limiting embodiment of the present invention. Specifically, a terminating network 2815 includes a request handling entity 2840 that acts as a gateway to a payable item source 2835 from which payable items can be accessed. The payable item source 2835 is a third party source that has a supplier relationship with the terminating network 2815, i.e., in exchange for honoring a request for a payable item for which it is responsible, the payable item source 2835 (i.e., the third party) issues a charge to the terminating network 2815 for a certain sum. Also, the data network 105 includes an optional proxy server 2802 that acts as a gateway to a website 2830.

In this embodiment, neither the payable item source 2835 nor the website 2830 is under the control of the terminating network 2815; rather, they are both controlled by an entity 2845 that is independent of the terminating network 2815. For example, such an entity could be a news organization (hereinafter given the fictional name "Supreme News"), which offers free and payable news articles to devices connected to the data network 105.

In this embodiment, free news articles are accessed via the website 2830. For their part, payable news articles are only accessible via the payable item source 2835, which could be a secure portion/directory of the website 2830 that can only be accessed via the terminating network 2815.

Also in this embodiment, the participating organization 26 comprises a designated network entity 2820, which is reachable over the data network 105 at an IP address.

Consider now that a user of the device 125 has established a connection over the originating network 1 10, the data network 105 and the optional proxy server 2802 in order to reach the website 2830. For illustrative purposes, the website 2830 is located at the URL www.supreme-news.com. In this embodiment, the website 2830, which is maintained independently of the terminating network 2815, presents a web page which, when displayed by a browser running on the device 125, may resemble what is shown in Fig. 12 by way of non-limiting example. The web page 1200 can be one of several web pages stored in the memory of the website 2830.

In this example, Supreme News, the operator of the website www.supreme-news.com, has developed both free and payable news articles that are likely to be of interest to visitors of the www.supreme-news.com website. These articles are made available for download and thus are represented on the web page. The web page 1200 includes an address bar 1210 that indicates the URL of the web page. The web page also includes at least one link of the second type 1240A, 1240B and, possibly, one or more links of the first type 1230A, 1230B. Also provided is a window 1220 that generally advertises the availability of news articles for download, some of which are free and others of which are payable.

In this example, links 1230A and 1230B, whose labels appear as "Stocks Turn Cautious" and "Greek Rescue Deal Only Buys Time", respectively, are links of the first type (i.e., corresponding to free news articles). These news articles may be stored on the website 2830. The targets associated with the free news articles are URLs pointing to the locations from which the free news articles can be downloaded to the device 125 over the data network 105. In contrast, links 1240A, 1240B, whose labels appear as "Myrtle Clears Another Hurdle" and "Banks Are Open For Real-Estate Pain", respectively, are links of the second type (i.e., corresponding to payable news articles). This payable news articles may be stored by the payable item source 2835. The targets associated with the payable news articles are also URLs. In this embodiment, the website 2830 intervenes when an attempt is made to access any of these payable news articles over the data network 105. As will be seen below, intervention of the website 2830 when the link corresponding to a payable news article is requested forces the requestor to pass through the request handling entity 2840 in order to access the payable news article.

With continued reference to Fig. 28, consider now that the user of the device 125 selects the link 1240A whose label appears as "Myrtle Clears Another Hurdle". The website 2830 detects, from the corresponding URL, that the requested news article is a payable news article (©). Accordingly, the website 2830 redirects the device 125 to a "payment options web page" that presents a set of payment options. It should be appreciated that the redirection can be accomplished in the form of an HTTP call that preserves, at least in part, the originally requested URL (e.g., www.supreme- news.com/myrtle-clears-another-hurdle.html). It is noted that in this embodiment, there is no need for the URL corresponding to a payable item to include a special string.

The payment options web page to which the device 125 is redirected can be part of the website 2830 (©A) or it can be located on a separate payment locator website 2600 (@B).

It is recalled that Fig. 27 shows a non-limiting example of a payment options web page 2700 as it could be rendered by a browser. The payment options web page 2700 presents a region 2740 that indicates to the user of the browser that a selection of a payment option is being sought. The payment options web page 2700 also presents a region 2720 that presents at least one home organization payment option 2720 and, possibly, a region 2730 that presents one or more other payment options, such as conventional payment options including credit card, Google Checkout™, PayPal™, etc.

It will be recalled that an home organization payment option is a payment option that identifies a selectable participating organization whose financial relationship with the terminating network 2815 (through which the requested payable item is accessed) and with its own customers can be leveraged to settle payment for the payable item being requested. The organizations identified by the at least one home organization payment option presented in region 2720 can be determined in advance and kept updated by the website 2830 and/or the payment locator website 2600. In the present example, the at least one home organization payment option presented in region 2720 is assumed to identify, among other organizations, the participating organization 26 which maintains the customer account 145.

By interacting with the browser, the user of the device 125 can select one of the payment options presented by the payment options web page 2700 ((D). In the present example, it is assumed that the user has elected to pay using the participating organization 26 by selecting from the at least one home organization payment option presented in region 2720. The entity running the payment options web page 2700 (namely, the website 2830 or the payment locator website 2600) then redirects the device 125 to the IP address of the designated network entity 2820 of the participating organization 26. This can be accomplished by way of an HTTP call that preserves, at least in part, the originally requested URL (namely, www.supreme-news.com/myrtle- clears-another-hurdle.html) (0).

The designated network entity 2820 now has to map the message received from the device 125 with a given customer account. This can be done by asking the user of the device 125 to enter the credentials associated with his or her customer account (e.g., account number and password). In the case where the participating organization 26 is an electric utility, the account number could be the user's electric utility account number and the password could be a password established with the electric utility during a prior registration phase. It is assumed that the user of the device 125 enters the credentials of the customer account 145 and that the customer account 145 has been correctly identified by the designated network entity 2830. The designated network entity 2820 then decides whether to accept to be charged on behalf of the customer account 145. For example, the designated network entity 2820 can verify (e.g., by consulting a database) whether the customer account 145 subscribes to an online payment service.

If the designated network entity 2820 determines that the customer account 145 does not subscribe to an online payment service, the designated network entity 2820 can initiate a subscription process, whereby the user of the device 125 is asked whether he or she wishes to subscribe. This process can also allow the customer account 145 to be associated with a credit limit. Assuming that the customer account 145 was indeed found to subscribe (or led to subscribe) to an online payment service, the identity of the customer account 145, the contents of the message, the time and any other relevant information is collected by the designated network entity 2820 as usage data. Based on the usage data for the present request and other requests made for other customer accounts, the designated network entity 2820 will at some later time be able to reconcile charges received from the terminating network 2815 in order to charge the appropriate customer account, in this case the customer account 145.

The designated network entity 2820 then formulates a payable item request for transmission to an appropriate request handling entity. In order to identify the IP address of the appropriate request handling entity to which it is to forward the payable item request, the designated network entity 2820 consults a database or other resource based on the domain name of the originally requested URL. The database or other resource maintains information regarding which request handling entities in which terminating networks act as the gateways to the domain names where various payable items are stored. In this example, the appropriate request handling entity is found to be the request handling entity 2840 in the terminating network 2815.

The payable item request includes at least part of the originally requested URL (in this case, www.supreme-news.com/myrtle-clears-another-hurdle.html). In a non-limiting embodiment, the payable item request can be an HTTP call. If, in addition, the customer account 145 was found to subscribe to an online payment service, the designated network entity 2820 inserts authentication data into the payable item request. By way of non-limiting example, the authentication data can include an identifier of the participating organization 26. For enhanced security, the authentication data can also include a version of this same identifier but encrypted with a private key of the participating organization 26. The designated network entity 2820 thus sends the payable item request to the request handling entity 2840, e.g., over the data network 105 (©). Since the request handling entity 2840 may be the gateway to multiple payable item sources, upon receipt of the payable item request from the designated network entity 2820, the request handling entity 2840 identifies the correct payable item source from which to retrieve the requested payable item. The correct payable item source can be identified based on part of the originally requested URL contained in the payable item request. In this example, the requested payable item is held by the payable item source 2835. If authentication data was supplied as part of the payable item request, the request handling entity 2840 verifies the information (e.g., by a decryption technique as has been previously described). If the authentication data is successfully verified, this will reveal the identity of the entity to be charged for the requested payable item (in this case, it is the participating organization 26).

Also, the request handling entity 2840 determines the price of the requested payable item. The price can be obtained by consulting a pricing database or by querying the payable item source 2835 directly. The request handling entity 2840 then sends a message back to the designated network entity 2820. The message causes a confirmation page to be rendered by the browser installed on the device 125. A non- limiting example of a confirmation page was described earlier with reference to Fig. 36. In addition, the message may also include a request for credit clearance destined for the designated network entity 2820, to ensure that the participating organization will agree to be billed for the price of the requested payable item (plus a commission).

Upon receiving confirmation from the user, the request handling entity 2840 contacts the payable item source 2835 (©), supplying it with at least part of the originally requested URL. In response, the payable item source 2835 returns the requested payable item, in this case a news article entitled "Myrtle Clears Another Hurdle", to the request handling entity 2840 (©). Communication between the request handling entity 2840 and the payable item source 2835 may be encrypted for added security, and may traverse the data network 105. The request handling entity 2840 forwards the news article to the designated network entity 2820 (®), which then forwards the news article to the device 125 (⁽D) for usage and enjoyment by the user. The billing flow is now described with reference to Fig. 29. Specifically, the payable item source 2835 (i.e., the entity 2845 with the name Supreme News) can send a service record indicative of a charge 29-A to the terminating network 2815. Charge 29-A reflects the price of the payable item. By way of non-limiting example, let charge 29-A be in the amount of $0.20. In an alternative embodiment, account consolidation between the payable item source 2835 and the request handling entity 2840 may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis).

The terminating network 2815 then sends a service record indicative of a charge 29-B to the participating organization 26 via an inter-organizational billing arrangement. As such, the participating organization 26 will be informed that it owes the terminating network 2815 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 29-B can be the amount of charge 29-A plus a commission for the terminating network 2815. By way of non-limiting example, let the commission be $0.01, which makes charge 29-B amount to $0.20 + $0.01 = $0.21. In addition, the participating organization 26 can then reconcile the service record with collected usage data and can transfer at least a portion of charge 29-B to the customer account 145. This can be achieved by issuing a charge 29-C to the customer account 145. As such, the entity responsible for the customer account 145 will be informed that it owes the participating organization 26 (e.g., electric utility) a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 29-C can be the amount of charge 29-B plus a commission for the participating organization 26. By way of non- limiting example, let the commission be $0.01 , thus making charge 29-C amount to $0.21 + $0.01 = $0.22.

USE CASE 2.2

Reference is now made to Fig. 30, which shows a simplified network architecture according to a specific non-limiting embodiment of the present invention. Specifically, a terminating network 3015 includes a request handling entity 3040 that acts as a gateway to a payable item source 3035 from which payable items can be accessed. The payable item source 3035 is a third party source that has a supplier relationship with the terminating network 3015, i.e., in exchange for honoring a request for a payable item for which it is responsible, the payable item source 3035 (i.e., the third party) issues a charge to the terminating network 3015 for a certain sum. Also, the data network 105 includes an optional proxy server 3002 that acts as a gateway to a website 3030. In this embodiment, neither the payable item source 3035 nor the website 3030 is under the control of the terminating network 3015; rather, they are both controlled by an entity 3045 that is independent of the terminating network 3015. For example, such an entity could be a news organization (hereinafter given the fictional name "Supreme News"), which offers free and payable news articles to devices connected to the data network 105.

In this embodiment, free news articles are accessed via the website 3030. For their part, payable news articles are only accessible via the payable item source 3035, which could be a secure portion/directory of the website 3030 that can only be accessed via the terminating network 3015.

Also in this embodiment, the participating organization 26 comprises a designated network entity 3020, which is reachable over the data network 105 at an IP address. Consider now that a user of the device 125 has established a connection over the originating network 1 10, the data network 105 and the optional proxy server 3002 in order to reach the website 3030. For illustrative purposes, the website 3030 is located at the URL www.supreme-news.com. In this embodiment, the website 3030, which is maintained independently of the terminating network 3015, presents a web page which, when displayed by a browser running on the device 125, may resemble what is shown in Fig. 12 by way of non-limiting example. The web page 1200 can be one of several web pages stored in the memory of the website 3030. In this example, Supreme News, the operator of the website www.supreme-news.com, has developed both free and payable news articles that are likely to be of interest to visitors of the www.supreme-news.com website. These articles are made available for download and thus are represented on the web page. The web page 1200 includes an address bar 1210 that indicates the URL of the web page. The web page also includes at least one link of the second type 1240 A, 1240B and, possibly, one or more links of the first type 1230A, 1230B. Also provided is a window 1220 that generally advertises the availability of news articles for download, some of which are free and others of which are payable.

In this example, links 1230A and 1230B, whose labels appear as "Stocks Turn Cautious" and "Greek Rescue Deal Only Buys Time", respectively, are links of the first type (i.e., corresponding to free news articles). These news articles may be stored on the website 3030. The targets associated with the free news articles are URLs pointing to the locations from which the free news articles can be downloaded to the device 125 over the data network 105.

In contrast, links 1240 A, 1240B, whose labels appear as "Myrtle Clears Another Hurdle" and "Banks Are Open For Real-Estate Pain", respectively, are links of the second type (i.e., corresponding to payable news articles). This payable news articles may be stored by the payable item source 3035. The targets associated with the payable news articles are also URLs. However, these URLs are extensions of the URL of the request handling entity 3040 in the terminating network 3015 (e.g., www.request-handling-entity.com). Thus, when a request for a payable news article is made by accessing its corresponding link, the requestor will be forced to pass through the request handling entity 3040 in order to access the payable news article. With reference to Fig. 36, consider now that the user of the device 125 selects the link 1240A whose label appears as "Myrtle Clears Another Hurdle". The website 3030 returns the corresponding target with the extended domain name (e.g., the URL www.request-handling-entity.com/supreme-news/myrtle-clears-another-hurdle.html) to the device 125 over the previously established connection (Φ). Following standard routing protocols, the device 125 will make an HTTP call (©) to the request handling entity 3040 by supplying the URL www.request-handling-entity.com/supreme- news/myrtle-clears-another-hurdle.html. The request handling entity 3040 detects that the requested URL is a request for a payable item and that this request has not been received from a participating organization. The request handling entity 3040 redirects the device 125 to a "payment options web page" that presents a set of payment options. It should be appreciated that the redirection can be accomplished in the form of an HTTP call that preserves, at least in part, the originally requested URL (e.g., www.request-handling- entity.com/supreme-news/myrtle-clears-another-hurdle.html).

The payment options web page to which the device 125 is redirected can be part of the request handling entity 3040 (® A) or it can be located on a separate payment locator website 2600 (⁽DB).

It will be recalled that an home organization payment option is a payment option that identifies a selectable participating organization whose financial relationship with the terminating network 3015 (through which the requested payable item is accessed) and with its own customers can be leveraged to settle payment for the payable item being requested. The organizations identified by the at least one home organization payment option presented in region 2720 can be determined in advance and kept updated by the website 3030 and/or the payment locator website 2600. In the present example, the at least one home organization payment option presented in region 2720 is assumed to identify, among other organizations, the participating organization 26 which maintains the customer account 145.

By interacting with the browser, the user of the device 125 can select one of the payment options presented by the payment options web page 2700 (0). In the present example, it is assumed that the user has elected to pay using the participating organization 26 by selecting from the at least one home organization payment option presented in region 2720. The entity running the payment options web page 2700 (namely, the website 3030 or the payment locator website 2600) then redirects the device 125 to the IP address of the designated network entity 3020 of the participating organization 26. This can be accomplished by way of an HTTP call that preserves, at least in part, the originally requested URL (namely, www.request-handling- entity. com/ supreme-news/myrtle-cl ears-another-hurdle.html) (© ) .

The designated network entity 3020 now has to map the message received from the device 125 with a given customer account. This can be done by asking the user of the device 125 to enter the credentials associated with his or her customer account (e.g., account number and password). In the case where the participating organization 26 is an electric utility, the account number could be the user's electric utility account number and the password could be a password established with the electric utility during a prior registration phase. It is assumed that the user of the device 125 enters the credentials of the customer account 145 and that the customer account 145 has been correctly identified by the designated network entity 3030. The designated network entity 3020 then decides whether to accept to be charged on behalf of the customer account 145. For example, the designated network entity 3020 can verify (e.g., by consulting a database) whether the customer account 145 subscribes to an online payment service.

If the designated network entity 3020 determines that the customer account 145 does not subscribe to an online payment service, the designated network entity 3020 can initiate a subscription process, whereby the user of the device 125 is asked whether he or she wishes to subscribe. This process can also allow the customer account 145 to be associated with a credit limit. Assuming that the customer account 145 was indeed found to subscribe (or led to subscribe) to an online payment service, the identity of the customer account 145, the contents of the message, the time and any other relevant information is collected by the designated network entity 3020 as usage data. Based on the usage data for the present request and other requests made for other customer accounts, the designated network entity 3020 will at some later time be able to reconcile charges received from the terminating network 3015 in order to charge the appropriate customer account, in this case the customer account 145.

The designated network entity 3020 then formulates a payable item request for transmission to an appropriate request handling entity. In order to identify the IP address of the appropriate request handling entity to which it is to forward the payable item request, the designated network entity 3020 consults a database or other resource based on the domain name of the originally requested URL. The database or other resource maintains information regarding which request handling entities in which terminating networks act as the gateways to the domain names where various payable items are stored. In this example, the appropriate request handling entity is found to be the request handling entity 3040 in the terminating network 3015.

The payable item request includes at least part of the originally requested URL (in this case, www.request-handling-entity.com/supreme-news/myrtle-clears-another- hurdle.html). In a non-limiting embodiment, the payable item request can be an HTTP call. If, in addition, the customer account 145 was found to subscribe to an online payment service, the designated network entity 3020 inserts authentication data into the payable item request. By way of non-limiting example, the authentication data can include an identifier of the participating organization 26. For enhanced security, the authentication data can also include a version of this same identifier but encrypted with a private key of the participating organization 26. The designated network entity 3020 thus sends the payable item request to the request handling entity 3040, e.g., over the data network 105 (©). Since the request handling entity 3040 may be the gateway to multiple payable item sources, upon receipt of the payable item request from the designated network entity 3020, the request handling entity 3040 identifies the correct payable item source from which to retrieve the requested payable item. The correct payable item source can be identified based on part of the originally requested URL contained in the payable item request. In this example, the requested payable item is held by the payable item source 3035. If authentication data was supplied as part of the payable item request, the request handling entity 3040 verifies the information (e.g., by a decryption technique as has been previously described). If the authentication data is successfully verified, this will reveal the identity of the entity to be charged for the requested payable item (in this case, it is the participating organization 26).

Also, the request handling entity 3040 determines the price of the requested payable item. The price can be obtained by consulting a pricing database or by querying the payable item source 3035 directly. The request handling entity 3040 then sends a message back to the designated network entity 3020. The message causes a confirmation page to be rendered by the browser installed on the device 125. A non- limiting example of a confirmation page was described earlier with reference to Fig. 36. In addition, the message may also include a request for credit clearance destined for the designated network entity 3020, to ensure that the participating organization will agree to be billed for the price of the requested payable item (plus a commission).

Upon receiving confirmation from the user, the request handling entity 3040 contacts the payable item source 3035 (©), supplying it with at least part of the originally requested URL. In response, the payable item source 3035 returns the requested payable item, in this case a news article entitled "Myrtle Clears Another Hurdle", to the request handling entity 3040 (⁽D). Communication between the request handling entity 3040 and the payable item source 3035 may be encrypted for added security, and may traverse the data network 105. The request handling entity 3040 forwards the news article to the designated network entity 3020 ((D), which then forwards the news article to the device 125 (®) for usage and enjoyment by the user. The billing flow is the same as was shown with reference to Fig. 29, except that the entity with the name Supreme News is now numbered 3045, the payable item source is now numbered 3035 and the designated network entity is now numbered 3020.

THIRD SET OF USE CASES

In the third set of use cases below (3.1 through 3.2), the originating network 1 10 is considered to be separate from the participating organization 26. That is to say, the originating network 110 again serves simply as a conduit to allow the device 125 to access the data network 105. As such, the originating network 1 10 may be any configuration that allows the device 125 to access the data network 105 by virtue of the customer account 182, e.g., from a residential access point, a mobile network, a public access point (e.g., wirelessly or non-wirelessly, at a hotel or restaurant, etc.), and so on. However, in the use cases to follow, the aforementioned customer account 145 does not need to exist. That is to say, the participating organization 26 does not need to maintain an account for the potential user of the device 125. Instead, the participating organization 26 is an intermediary payment vehicle which, by virtue of a first inter-organizational billing agreement, agrees to be billed by a given terminating network for charges initiated by users of the originating network 110. In return, the intermediary payment vehicle charges the originating network by virtue of a second inter-organizational billing agreement. For example, the participating organization 26 can be any company with an internet presence (e.g., a website) that agrees to assume the credit risk arising from charges flowing from the terminating network and to the originating network 110.

USE CASE 3.1

Reference is made to Fig. 31 , which utilizes a simplified network architecture similar to that of Fig. 28, with the exception that there is no customer account 145 maintained by the participating organization 26. Consider that a user of the device 125 has established a connection over the originating network 1 10, the data network 105 and the optional proxy server 2802 in order to reach the website 2830. For illustrative purposes, the website 2830 is located at the URL www.supreme-news.com. In this embodiment, the website 2830, which is maintained independently of the terminating network 2815, presents a web page which, when displayed by a browser running on the device 125, may resemble what is shown in Fig. 12 by way of non-limiting example. Consider now that the user of the device 125 selects the link 1240A whose label appears as "Myrtle Clears Another Hurdle". The website 2830 detects, from the corresponding URL, that the requested news article is a payable news article (CD). Accordingly, the website 2830 redirects the device 125 to a "payment options web page" that presents a set of payment options. It should be appreciated that the redirection can be accomplished in the form of an HTTP call that preserves, at least in part, the originally requested URL (e.g., www.supreme-news.com/myrtle-clears- another-hurdle.html). It is noted that in this embodiment, there is no need for the URL corresponding to a payable item to include a special string.

Reference is now made to Fig. 32, which shows a non-limiting example of a payment options web page 3200 as it could be rendered by a browser. The payment options web page 3200 presents a region 3240 that indicates to the user of the browser that a selection of a payment option is being sought. The payment options web page 3200 also presents a region 3210 that presents at least one intermediary payment vehicle option, as well as possibly a region 3220 that presents one or more home organization payment options and a region 3230 that presents one or more other payment options, such as conventional payment options including credit card, Google Checkout™, PayPal™, etc.

It will be recalled that a home organization payment option is a payment option that identifies a selectable participating organization whose financial relationship with the terminating network 2815 (through which the requested payable item is accessed) and its own customers can be leveraged to settle payment for the payable item being requested. For its part, an intermediary payment vehicle option is a payment option that identifies a selectable participating organization whose financial relationship with the terminating network 2815 and with the originating network 1 10 can be leveraged to settle payment for the payable item being requested. The organizations identified by the at least one intermediary payment vehicle option presented in region 3210 and/or the at least one home organization payment option presented in region 3220 can be determined in advance and kept updated by the website 2830 and/or the payment locator website 2600. In the present example, the intermediary payment vehicle option presented in region 3210 is assumed to identify, among other organizations, the participating organization 26, which need not maintain a customer account for the user of the device 125. Thus, the intermediary payment vehicle option can be referred to as a "3^rd party" payment option.

By interacting with the browser, the user of the device 125 can select one of the payment options presented by the payment options web page 3200 (⁽D). In the present example, it is assumed that the user has elected to pay using the participating organization 26 by selecting from the at least one intermediate payment vehicle option presented in region 3210. The entity running the payment options web page 3200 (namely, the website 2830 or the payment locator website 2600) then redirects the device 125 to the IP address of the designated network entity 2820 of the participating organization 26. This can be accomplished by way of an HTTP call that preserves, at least in part, the originally requested URL (namely, www.supreme-news.com/myrtle- clears-another-hurdle.html) (©).

The designated network entity 2820 recognizes that the message received from the device originates from the originating network 1 10. If this is an organization with which the participating organization 26 has an inter-organizational billing arrangement, then the designated network entity 2820 proceeds with the following. Otherwise, the participating organization 26 cannot act as an intermediary payment vehicle. Assuming that the participating organization 26 does indeed have a first inter-organizational billing arrangement with the originating network 110, the IP address of the device 125, the contents of the message, the time and any other relevant information is collected by the designated network entity 2820 as usage data. Based on the usage data, the designated network entity 2820 will at some later time be able to reconcile charges received from the terminating network 2815 in order to charge the originating network 1 10 under the first inter-organizational billing arrangement. The designated network entity 2820 then formulates a payable item request for transmission to an appropriate request handling entity. The remainder of the process is similar to that which was described with reference to items (⁽D) through (⁽D) in connection with Fig. 28.

The billing flow is now described with reference to Fig. 33. Specifically, the payable item source 2835 (i.e., the entity 2845 with the name Supreme News) can send a service record indicative of a charge 33-A to the terminating network 2815. Charge 33-A reflects the price of the payable item. By way of non-limiting example, let charge 33-A be in the amount of $0.20. In an alternative embodiment, account consolidation between the payable item source 2835 and the request handling entity 2840 may be carried out in an aggregate and/or off-line fashion (e.g., on a daily, weekly or monthly basis). The terminating network 2815 then sends a first service record indicative of a charge 33-B to the participating organization 26 via a second inter-organizational billing arrangement. As such, the participating organization 26 will be informed that it owes the terminating network 2815 a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 33-B can be the amount of charge 33-A plus a commission for the terminating network 2815. By way of non-limiting example, let the commission be $0.01, which makes charge 33-B amount to $0.20 + $0.01 = $0.21.

It is recalled that the participating organization 26 is an intermediary payment vehicle. Thus, the participating organization can reconcile the first service record with collected usage data and can transfer at least a portion of charge 33-B to the originating network 110. This can be achieved by sending a second service record indicative of a charge 33-C to the originating network 110. As such, the originating network 1 10 will be informed that it owes the participating organization 26 (the intermediary payment vehicle) a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 33-C can be the amount of charge 33-B plus a commission for the participating organization 26. By way of non-limiting example, let the commission be $0.01, thus making charge 33-C amount to $0.21 + $0.01 = $0.22. Finally, the originating network 1 10 can then reconcile the second service record with collected usage data and can transfer at least a portion of charge 33-C to the customer account 182, which permits the device 125 to access the data network 105. This can be achieved by issuing a charge 33-D to the customer account 182. As such, the entity responsible for the customer account 182 (i.e., the user of the device 125) will be informed that HE OR she owes the originating network 1 10 (e.g., an Internet service provider) a certain amount of money or, in the case of a prepaid account, that its prepaid balance has been debited by a certain amount. The amount of charge 33-D can be the amount of charge 33-C plus a commission for the originating network 1 10. By way of non-limiting example, let the commission be $0.01 , thus making charge 33-D amount to $0.22 + $0.01 = $0.23.

USE CASE 3.2

Reference is made to Fig. 34, which utilizes a simplified network architecture similar to that of Fig. 30, with the exception that there is no customer account 145 maintained by the participating organization 26. Consider now that a user of the device 125 has established a connection over the originating network 1 10, the data network 105 and the optional proxy server 3002 in order to reach the website 3030. For illustrative purposes, the website 3030 is located at the URL www.supreme-news.com. In this embodiment, the website 3030, which is maintained independently of the terminating network 3015, presents a web page which, when displayed by a browser running on the device 125, may resemble what is shown in Fig. 12 by way of non-limiting example. Consider now that the user of the device 125 selects the link 1240A whose label appears as "Myrtle Clears Another Hurdle". The website 3030 returns the corresponding target with the extended domain name (e.g., the URL www.request- handling-entity.com/supreme-news/myrtle-clears-another-hurdle.html) to the device 125 over the previously established connection (Φ). Following standard routing protocols, the device 125 will make an HTTP call (©) to the request handling entity 3040 by supplying the URL www.request-handling-entity.com/supreme- news/myrtle-clears-another-hurdle.html. The request handling entity 3040 detects that the requested URL is a request for a payable item and that this request has not been received from a participating organization. The request handling entity 3040 redirects the device 125 to a "payment options web page" that presents a set of payment options (®). It should be appreciated that the redirection can be accomplished in the form of an HTTP call that preserves, at least in part, the originally requested URL (e.g., www.request-handling- entity.com/supreme-news/myrtle-clears-another-hurdle.html).

The payment options web page to which the device 125 is redirected can be part of the website 3030 or it can be located on a separate payment locator website 2600. Reference can be now made to Fig. 32 which, as was described above, shows a non- limiting example of a payment options web page 3200 as it could be rendered by a browser. By interacting with the browser, the user of the device 125 can select one of the payment options presented by the payment options web page 3200 (⁽D). In the present example, it is assumed that the user has elected to pay using the participating organization 26 by selecting from the at least one intermediate payment vehicle option 3210. The entity running the payment options web page 3200 (namely, the website 3030 or the payment locator website 2600) then redirects the device 125 to the IP address of the designated network entity 3020 of the participating organization 26. This can be accomplished by way of an HTTP call that preserves, at least in part, the originally requested URL (namely, www.supreme-news.com/myrtle-clears-another- hurdle.html) (®).

The designated network entity 3020 recognizes that the message received from the device originates from the originating network 1 10. If this is an organization with which the participating organization 26 has an inter-organizational billing arrangement, then the designated network entity 3020 proceeds with the following. Otherwise, the participating organization 26 cannot act as an intermediary payment vehicle. Assuming that the participating organization 26 does indeed have a first inter-organizational billing arrangement with the originating network 1 10, the IP address of the device 125, the contents of the message, the time and any other relevant information is collected by the designated network entity 3020 as usage data. Based on the usage data, the designated network entity 3020 will at some later time be able to reconcile charges received from the terminating network 3015 in order to charge the originating network 1 10 under the first inter-organizational billing arrangement. The designated network entity 3020 then formulates a payable item request for transmission to an appropriate request handling entity. The remainder of the process is similar to that which was described with reference to items (©) through (®) in connection with Fig. 30. The billing flow is the same as was shown with reference to Fig. 33, except that the entity with the name Supreme News is now numbered 3045, the payable item source is now numbered 3035 and the designated network entity is now numbered 3020.

Thus, it will be appreciated that the above embodiments can support an ecosystem in which users of the Internet are empowered to purchase payable items that are offered for sale on various websites. Credit is extended to such users by virtue of their own internet or mobile data account, or by virtue of an alternate facility such as a utility or other establishment with which the user has established a financial relationship. Thus, users can purchase payable items online without a subscription and even without a credit card. This extends purchasing power to a wide cross-section of internet users who have heretofore been limited in their ability to purchase items online, either through a reluctance to give credit card information or by virtue of the simple fact that they do not have a credit card. Moreover, purchases can be done in virtual anonymity, since the entity that will be deemed to have purchased a payable item from a payable item source will be an organization rather than an individual customer, with the organization assuming the risk of collecting payment from the customer.

Moreover, the above embodiments can support differentiated service offerings where items are made available for a variety of prices, depending on a given factor. In one example, news stories can be priced in a manner inversely proportional to their age and/or proportional to their depth of coverage. In another example, photos or videos can be priced in a manner proportional to their resolution, quality or duration. In another example, a certain item can be priced in a manner proportional or inversely proportional with the demand for that item (i.e., how often they have been purchased in the recent past). Clearly, there are numerous variations and possibilities that will now become apparent to a person of skill in the art.

In addition, it should be appreciated that links associated with payable items can be shared over the Internet using a variety of available tools. This allows users to share their discovery of a payable item with multiple ones of their contacts. Meanwhile, further sales of the payable item are encouraged, as they can be triggered merely by a recipient of the link clicking thereon in his or her own browser. In the above examples, the payable items have tended to include media content (news, videos, recipes, ringtones, greeting cards, etc.) and software (e.g., for mobile, laptop and/or desktop devices), both of which are capable of being delivered to a device over a data connection. However, it should be appreciated that other classes of payable items are within the scope of the present invention.

For example, the present invention is also applicable to the case where a payable item includes a reservation (travel, hotel, restaurant, parking, etc.), a financial contribution (tax, fine, donation, etc.) and tangible merchandise (e.g., a computer, sofa, car, etc.), to name a few non-limiting possibilities. Those skilled in the art will appreciate that the aforementioned use cases and scenarios are applicable with certain minor modifications, such as the provision of additional information from the user (e.g., a name, shipping address, account number, etc.) Also, stronger authentication may be needed in order to prevent mistakes or fraud. Also, the data delivered to the device 125 is not the payable item itself, but rather takes the form of confirmatory data associated with the payable item (e.g., an electronic confirmation of a reservation, an electronic receipt for payment when the payable item is a contribution or merchandise, etc.).

Moreover, it will be appreciated that the data corresponding to a requested payable item need not be delivered over the same data connection as was used to request the payable item. In fact, the user of the device 125 may specify a different delivery mechanism for the data, such as an email address or postal address. While this may require greater effort on the part of the user, it comes with various benefits, such as allowing users to better manage their purchases and/or pay for items that are intended for other users, as in the case of greeting cards.

In addition, it should be appreciated that in certain embodiments, the originating network 1 10 may comprise a clearing house acting on behalf of one or more access networks. Under such an arrangement, the access networks rely on the clearing house to interface with the data network 105. Thus, a customer account (to which the device 125 is registered) is actually created in the access network, which pays the clearing house a fee to interface with data network 105.

In addition, it should be appreciated that in certain embodiments, the terminating network may comprise a clearing house acting on behalf of one or more end networks. Under such an arrangement, the end networks rely on the clearing house to interface with the data network 105. Thus, a given payable item source is actually accessed via the request handling entity in a given end network, which pays the clearing house a fee to interface with the data network 105.

In addition, it will be recalled that in some of the above examples, the target of a particular link of the second type included a portion causing it to be recognizable as a URL associated with a payable item (as contrasted with a URL associated with freely available content). It should be appreciated that to discriminate between URLs associated with payable items and URLs associated with freely available content, the entity performing the discriminating (e.g., DNS, routing entity, website, etc.) can look for the presence of a string (such as "pay", in a non-limiting example) anywhere in the URL, including in the top-level domain, the second-level domain and the third-level domain. Alternatively, the entity performing the discriminating can maintain a specific list of URLs against which each accessed URL is compared. Alternatively, the entity performing the discriminating can look for specific ports in the URL. Other possibilities within the scope of the present invention will now become apparent to those of skill in the art.

In addition, it will be appreciated that the various examples of URLs, web page content, directory structures, prices, commissions, and the like are merely for illustrative purposes in order to facilitate an understanding of certain aspects of the present invention. They are not to be taken as requirements or limits of the present invention.

In addition, the term "service record" referred to in the above description is not to be construed as limited to any particular protocol or format. Rather, it is to be interpreted as any kind of message or signaling transmitted between networks that contains the requisite information relevant to usage and/or billing and/or authentication. Billing can be implemented in non-real-time (postpaid) mode, in which case the service records are produced and issued some time after a payable item request has been satisfied, or in real-time mode, where the entities to be charged are identified, reserved and charged in the course of signalling interactions.

In addition, when an element forming part of a network or system is illustrated as being "within" the network or system, this is done for simplicity and ease of understanding. This is not intended to convey a requirement for physical or geographic proximity. For example, an element forming part of a given network may in fact be located remotely from other components and accessed over the data network 105 using a virtual private network or other type of secure connection. In addition, when a designated network entity is requested to carry out a credit clearance in respect of a requested payable item, this can involve comparing the price of the payable item to an amount of available credit associated with the customer account responsible for the request. The amount of available credit can be different for different customer accounts, depending on usage patterns. For example, it can be increased if the customer account is typically settled in a timely fashion. Also, it can be increased if the customer account is topped up with funds.

In addition, those skilled in the art will appreciate that all communications between entities can take place using appropriate protocols, which can include SIP, HTTP, FTP (File Transfer Protocol), SSL (Secure Sockets Layer), SOAP (Simple Object Access Protocol), SMTP (Simple Mail Transfer Protocol), RTSP (Real Time Streaming Protocol) or any other protocol that may become apparent to those of skill in the art. It should also be appreciated that there may be more than one designated network entity in the participating organization and/or more than one request handling entity in the terminating network, and that the choice of which designated network entity or request handling entity to communicate with can be made based on load balancing, availability or other considerations.

Those skilled in the art will also appreciate that in some embodiments, the various network entities described above may be implemented using one or more computing apparatuses that have access to a code memory (not shown) which stores computer- readable program code (instructions) for operation of the one or more computing apparatuses. The computer-readable program code could be stored on a medium which is fixed, tangible and readable directly by the one or more computing apparatuses, (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB drive), or the computer-readable program code could be stored remotely but transmittable to the one or more computing apparatuses via a modem or other interface device (e.g., a communications adapter) connected to a network (including, without limitation, the Internet) over a transmission medium, which may be either a non-wireless medium (e.g., optical or analog communications lines) or a wireless medium (e.g., microwave, infrared or other transmission schemes) or a combination thereof. In other embodiments, the various network entities described above may be implemented using pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), flash memory, etc.), or other related components. In the examples described above, elements are connected to each other as shown in the figures for the sake of simplicity. In practical applications of the present invention, elements may be connected directly to each other or indirectly to each other through other elements necessary for their operation. Certain adaptations and modifications of the described embodiments can be made. Therefore, the above discussed embodiments are to be considered illustrative and not restrictive. Also it should be appreciated that additional elements that may be needed for operation of certain embodiments of the present invention have not been described or illustrated as they are assumed to be within the purview of the person of ordinary skill in the art. Moreover, certain embodiments of the present invention may be free of, may lack and/or may function without any element that is not specifically disclosed herein.

Claims

WHAT IS CLAIMED IS:

1. A method for execution by a network entity, comprising: receiving a message identifying an item selected online; formulating a payable item request identifying the item; and

sending the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter-organizational billing arrangement.

2. The method defined in claim 1, wherein formulating the payable item request comprises including an identifier of the operator of the network entity in the payable item request.

3. The method defined in claim 2, wherein formulating the payable item request further comprises including an encrypted identifier in the payable item request.

4. The method defined in claim 3, further comprising encrypting the identifier of the operator of the network entity with a private key in order to obtain the encrypted identifier.

5. The method defined in claim 4, wherein the private key is complementary to a public key that is accessible to the terminating network, such that decryption of the encrypted identifier using the public key yields the identifier of the operator.

6. The method defined in claim 1 , the method further comprising: determining whether the customer account has credit within a credit limit;

carrying out the sending only if the customer account was determined to have credit above the credit limit.

7. The method defined in claim 1, the method further comprising: identifying a customer account to be charged by the operator of the network entity in relation to the item; receiving a second message from the entity that controls access to the item, the second message including a price of the item and requesting a confirmation of the payable item request; determining whether the customer account has sufficient credit to pay for the item; sending a response message to the entity that controls access to the item, the response message indicative of a positive or negative confirmation of the payable item request, depending on whether the customer account was determined to have sufficient credit to pay for the item.

8. The method defined in claim 1, further comprising receiving a service record from the terminating network under the inter-organizational billing arrangement, the service record indicative of an amount charged by the terminating network in relation to the item.

9. The method defined in claim 8, the method further comprising: identifying a customer account to be charged by the operator in relation to the item; and causing the customer account to be charged an amount in relation to the item that is at least part of the amount charged by the terminating network in relation to the item.

10. The method defined in claim 9, wherein identifying a customer account to be charged by the operator in relation to the item comprises: reconciling the service record with previously collected data pertaining to the message.

11. The method defined in claim 9, wherein the amount charged to the customer account in relation to the item is greater than the amount charged by the terminating network in relation to the item.

12. The method defined in claim 9, wherein the message is received from a device that was used to select the item over a data network, wherein identifying the customer account is carried out on a basis of credentials used to gain access to the data network.

13. The method defined in claim 12, wherein the operator of the network entity is one of a telecommunications carrier and an internet service provider.

14. The method defined in claim 9, wherein the message is received from a device that was used to select the item over a data network, wherein identifying the customer account is carried out on a basis of credentials supplied by at least one of the device and a user of the device.

15. The method defined in claim 14, wherein the operator of the network entity is one of a utility, a bank, a credit card facility and a prepaid credit facility.

16. The method defined in claim 9, further comprising:

consulting a database to determine whether the customer account subscribes to an online payment service; and carrying out the sending and the formulating only if it is determined that the customer account subscribes to the online payment service.

17. The method defined in claim 8, the method further comprising: identifying an organization to be charged by the operator in relation to the item; and causing the organization to be charged an amount in relation to the item.

18. The method defined in claim 17, wherein causing the organization to be charged an amount in relation to the item comprises causing issuance of a service record to the organization under a second inter-organizational billing arrangement, the service record indicative of the amount charged to the organization in relation to the item.

19. The method defined in claim 18, wherein the amount charged to the organization in relation to the item is at least part of the amount charged by the terminating network in relation to the item.

20. The method defined in claim 19, wherein the amount charged to the organization in relation to the item is greater than the amount charged by the terminating network in relation to the item.

21. The method defined in claim 1, further comprising: determining whether the item is payable; and carrying out the formulating and the sending only if the item is determined to be payable.

22. The method defined in claim 21, wherein the message includes an address returned by a website where the selected item is represented and wherein determining whether the item is payable comprises comparing a domain name of the address to a set of domain names known to be associated with payable items.

23. The method defined in claim 21, wherein the message includes an address returned by a website where the selected item is represented, wherein the address comprises a domain name and wherein determining whether the item is payable comprises: consulting a domain name server to obtain a numerical address corresponding to the domain name; and

comparing the numerical address to a set of numerical addresses known to be associated with payable items.

24. The method defined in claim 1 , further comprising receiving content pertaining to the item from the terminating network, responsive to sending the payable item request.

25. The method defined in claim 24, wherein the network entity is connected to a data network and wherein the message is received over the data network from a device that was used to select the item over the data network, the method further comprising sending the content pertaining to the item to the device over the data network.

26. The method defined in claim 24, wherein the content pertaining to the item comprises at least one of media content and software.

27. The method defined in claim 24, wherein the content pertaining to the item comprises at least one of a news article, a video, a recipe, a ringtone, a greeting card and an app.

28. The method defined in claim 24, wherein the item comprises at least one of a reservation, a financial contribution and tangible merchandise.

29. The method defined in claim 28, wherein the content pertaining to the item comprises at least one of an electronic confirmation of a reservation and an electronic receipt for payment.

30. A network entity, comprising: at least one component configured for receiving a message identifying an item selected online;

at least one component configured for formulating a payable item request identifying the item; and at least one component configured for sending the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter- organizational billing arrangement.

31. A network entity, comprising: means for receiving a message identifying an item selected online; means for formulating a payable item request identifying the item; and means for sending the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter-organizational billing arrangement.

32. Computer-readable storage media comprising computer-readable instructions for instructing a network entity to: receive a message identifying an item selected online; formulate a payable item request identifying the item; and send the payable item request to an entity that controls access to the item, the entity being part of a terminating network with which an operator of the network entity has an inter-organizational billing arrangement.

33. A method for execution by a network entity in a terminating network, comprising: receiving from a requesting organization a payable item request that identifies an item selected online and comprises putative authentication data pertaining to the requesting organization; carrying out an attempt to authenticate the putative authentication data; and responsive to the attempt being successful, accessing the item from a payable item source, sending content pertaining to the item to the requesting organization and causing the requesting organization to be charged by the terminating network under an inter-organizational billing arrangement.

34. The method defined in claim 33, wherein the putative authentication data comprises an unencrypted portion and an encrypted portion, wherein carrying out the attempt to authenticate the putative authentication data comprises: decrypting the encrypted portion; comparing the result to the unencrypted portion; and concluding that the attempt is successful if there is a match and unsuccessful otherwise.

35. The method defined in claim 34, wherein the unencrypted portion represents an identifier of the requesting organization, wherein decrypting the encrypted portion is carried out using a public key associated with the requesting organization.

36. The method defined in claim 35, further comprising: obtaining the public key associated with the requesting organization from a key server.

37. The method defined in claim 36, wherein obtaining the public key associated with the requesting organization from a key server comprises supplying the identifier of the requesting organization to the key server.

38. The method defined in claim 33, wherein the putative authentication data comprises an unencrypted portion and an encrypted portion, wherein the unencrypted portion represents an identifier of the requesting organization, and wherein carrying out the attempt to authenticate the putative authentication data comprises: sending the identifier of the requesting organization and the encrypted portion to a key server; obtaining from the key server an indication of whether the attempt is successful.

39. The method defined in claim 33, further comprising, responsive to the attempt being successful and prior to sending the content pertaining to the item to the requestor: sending a message to the requesting organization requesting confirmation of the payable item request.

40. The method defined in claim 39, further comprising:

carrying out the sending only if a confirmation of the payable item request is received from the requesting organization in response to sending of the message requesting confirmation of the payable item request.

41. The method defined in claim 39, further comprising, responsive to the attempt being successful and prior to sending the content pertaining to the item to the requestor: obtaining a price of the item; and incorporating the price into the message sent to the requesting organization requesting confirmation of the payable item request.

42. The method defined in claim 41, wherein obtaining the price of the item comprises querying the payable item source.

43. The method defined in claim 41 , wherein obtaining the price of the online comprises consulting a pricing database.

44. The method defined in claim 33, wherein causing the requesting organization to be charged under an inter-organizational billing arrangement comprises: sending a service record to the requesting organization, the service record indicating a charge in relation to handling the payable item request.

45. The method defined in claim 44, further comprising:

receiving the content pertaining to the item from the payable item source; and receiving a charge from the payable item source in relation to transmission of the content pertaining to the item.

46. The method defined in claim 45, wherein the charge indicated in the service record is the sum of the charge from the payable item source and a commission retained for the terminating network.

47. The method defined in claim 44, wherein the requesting organization is one of a telecommunications carrier and an internet service provider.

48. The method defined in claim 44, wherein the requesting organization is one of a utility a bank, a credit card facility and a prepaid credit facility.

49. The method defined in claim 33, wherein the item is identified by an address embedded in the payable item request.

50. The method defined in claim 49, wherein the address comprises a URL.

51. The method defined in claim 33, wherein the payable item request is received over a data network.

52. The method defined in claim 33, wherein the payable item source is hosted by the terminating network.

53. The method defined in claim 33, wherein the content pertaining to the item comprises at least one of media content and software.

54. The method defined in claim 33, wherein the content pertaining to the item comprises at least one of a news article, a video, a recipe, a ringtone, a greeting card and an app.

55. The method defined in claim 33, wherein the item comprises at least one of a reservation, a financial contribution and tangible merchandise.

56. The method defined in claim 55, wherein the content pertaining to the item comprises at least one of an electronic confirmation of a reservation and an electronic receipt for payment.

57. A payable item gateway in a terminating network, comprising: at least one component configured for receiving from a requesting organization a payable item request that identifies an item selected online and comprises putative authentication data pertaining to the requesting organization;

at least one component configured for carrying out an attempt to authenticate the putative authentication data; and at least one component configured for responding to the attempt being successful by accessing the item from a payable item source, sending content pertaining to the item to the requesting organization and causing the requesting organization to be charged by the terminating network under an inter- organizational billing arrangement.

58. A payable item gateway in a terminating network, comprising:

means for receiving from a requesting organization a payable item request that identifies an item selected online and comprises putative authentication data pertaining to the requesting organization; means for carrying out an attempt to authenticate the putative authentication data; and

means for responding to the attempt being successful by accessing the item from a payable item source, sending content pertaining to the item to the requesting organization and causing the requesting organization to be charged by the terminating network under an inter-organizational billing arrangement.

59. Computer-readable storage media comprising computer-readable instructions for instructing a network entity in a terminating network to: detect receipt from a requesting organization a payable item request that identifies an item selected online and comprises putative authentication data pertaining to the requesting organization; carry out an attempt to authenticate the putative authentication data; and responsive to the attempt being successful: accessing the item from a payable item source; send content pertaining to the item to the requesting organization; and cause the requesting organization to be charged by the terminating network under an inter-organizational billing arrangement.

60. A system, comprising: a first subsystem accessible over a data network, the first subsystem configured for interacting over the data network with a member of a portal to allow the member to upload payable content and to customize a label associated with the payable content; a second subsystem storing the payable content uploaded by the member via the first subsystem, the second subsystem configured for communicating with a payable item gateway that controls visitor access to the payable content; the first subsystem storing a target in association with the label, the target identifying the payable content stored by the second subsystem;

the first subsystem configured for detecting selection of the label by a visitor to the portal and, in response, sending the target to the visitor over the data network.

61. The system defined in claim 61, wherein the first subsystem is further configured for interacting over the data network with the member to allow the member to upload free content and to customize a second label associated with the free content, the first subsystem storing the free content uploaded by the member and storing a second target in association with the second label, the first subsystem configured for detecting selection of the second label by a visitor to the portal and, in response, sending the second target to the visitor over the data network.

62. The system defined in claim 61 , wherein the target identifies the payable content by identifying the payable item gateway and the second subsystem.

63. The system defined in claim 61, wherein the target comprises an address of the payable item gateway.

64. The system defined in claim 61 , wherein the target comprises an address of a designated network entity operated by an organization with which an operator of the payable item gateway has an inter-organizational billing arrangement.

65. The system defined in claim 61, wherein the target comprises a URL with a domain name that is routed by a domain name server to a designated network entity operated by an organization with which an operator of the payable item gateway has an inter-organizational billing arrangement.

66. The system defined in claim 61, wherein the target comprises an address at which the payable item gateway can be reached via the data network.

67. The system defined in claim 61 , wherein the target comprises a URL with a domain name which, when resolved into a numeric address, yields an IP address of the payable item gateway.

68. The system defined in claim 61, wherein the portal is a social network.

69. The system defined in claim 68, wherein the visitor is also a member of the social network.

70. The system defined in claim 61, wherein the portal is a digital mall and wherein the member is a merchant registered with the digital mall.

71. The system defined in claim 61, wherein the first subsystem and the second subsystem occupy respective sets of directories of a common server.

72. The system defined in claim 61 , wherein the second subsystem causes the payable content to be released to the payable item gateway.

73. The system defined in claim 72, wherein the portal charges a terminating network that operates the payable item gateway for release of the selected payable content.

74. The system defined in claim 73, wherein the portal remunerates the member further to release of the payable content to the payable item gateway.

75. The system defined in claim 74, wherein the amount by which the portal remunerates the member corresponds to at least a portion of the amount by which the portal charges the terminating network.

76. The system defined in claim 74, wherein the amount by which the portal remunerates the member corresponds the amount by which the portal charges the terminating network less a commission retained for the portal.

77. The system defined in claim 74, wherein to remunerate the member, the portal issues a cheque, credit or bank transfer to the member.

78. The method defined in claim 76, wherein the payable content comprises at least one of media content and software.

79. The method defined in claim 76, wherein the payable content comprises at least one of a news article, a video, a recipe, a ringtone, a greeting card and an app.

80. A system, comprising: first means accessible over a data network, for interacting over the data network with a member of a portal to allow the member to upload payable content and to customize a label associated with the payable content; second means for communicating with a payable item gateway that controls visitor access to the payable content, the second means being means for storing the payable content uploaded by the member via the first means; the first means being means for storing a target in association with the label, the target identifying the payable content stored by the second means;

the first means being means configured for detecting selection of the label by a visitor to the portal and, in response, sending the target to the visitor over the data network.

81. A method, comprising:

receiving a message identifying a domain name associated with an item selected online;

identifying a numerical address of a destination to which to send at least a portion of the message, based on at least a portion of the domain name; routing at least a portion of the message to the destination;

wherein when the item is payable, the numerical address of the destination is the numerical address of a designated network entity capable of issuing a payable item request to a second entity that controls access to the item, the second entity being part of a terminating network with which an operator of the designated network entity has an inter-organizational billing arrangement.

82. The method defined in claim 81, wherein identifying the numerical address of the destination comprises: consulting a domain name server based on the domain name in order to obtain an IP address associated with the domain name; and setting as the numerical address of the destination the IP address obtained from the domain name server.

83. The method defined in claim 81, wherein identifying the numerical address of the destination comprises:

comparing at least a portion of the domain name to a list; and

if the at least a portion of the domain name is on the list, setting as the numerical address of the destination an IP address of the designated network entity; otherwise, consulting a domain name server based on the domain name in order to obtain an IP address associated with the domain name, and setting as the numerical address of the destination the IP address obtained from the domain name server.

84. The method defined in claim 83, wherein the at least a portion of the domain comprises at least one of a top-level domain, a second-level domain and a third- level domain.

85. The method defined in claim 84, wherein the at least a portion of the domain comprises the whole domain name.

86. The method defined in claim 81 , wherein identifying the numerical address of the destination comprises: determining whether a portion of the domain name comprises a pre-determined string indicative of a payable item; and

if the portion of the domain name comprises the pre-determined string indicative of a payable item, setting as the numerical address of the destination an IP address of the designated network entity.

87. The method defined in claim 81 , wherein identifying the numerical address of the destination comprises: consulting a domain name server based on the domain name in order to obtain an IP address associated with the domain name; and if the IP address obtained from the domain name server is in a reserved set of IP addresses, setting as the numerical address of the destination an IP address of the designated network entity. otherwise, setting as the numerical address of the destination the IP address obtained from the domain name server;

88. The method defined in claim 81 , further comprising:

performing intrusion detection filtering and blocking on the message in order to assess whether the message is malicious.

89. Apparatus, comprising: at least one component configured for receiving a message identifying a domain name associated with an item selected online; at least one component configured for identifying a numerical address of a destination to which to send at least a portion of the message, based on at least a portion of the domain name;

at least one component configured for routing at least a portion of the message to the destination; wherein when the item is payable, the numerical address of the destination is the numerical address of a designated network entity capable of issuing a payable item request to a second entity that controls access to the item, the second entity being part of a terminating network with which an operator of the designated network entity has an inter-organizational billing arrangement.

90. Apparatus, comprising:

means for receiving a message identifying a domain name associated with an item selected online; means for identifying a numerical address of a destination to which to send at least a portion of the message, based on at least a portion of the domain name; means for routing at least a portion of the message to the destination; wherein when the item is payable, the numerical address of the destination is the numerical address of a designated network entity capable of issuing a payable item request to a second entity that controls access to the item, the second entity being part of a terminating network with which an operator of the designated network entity has an inter-organizational billing arrangement.

91. Computer-readable storage media comprising computer-readable instructions for instructing a network entity to: detect receipt of a message identifying a domain name associated with an item selected online; identify a numerical address of a destination to which to send at least a portion of the message, based on at least a portion of the domain name; route at least a portion of the message to the destination; wherein when the item is payable, the numerical address of the destination is the numerical address of a designated network entity capable of issuing a payable item request to a second entity that controls access to the item, the second entity being part of a terminating network with which an operator of the designated network entity has an inter-organizational billing arrangement.

92. A method for execution by a network entity, comprising: receiving a request for an item selected by a visitor to a website; determining whether the request is a request for a payable item; responsive to determining that the request is a request for a payable item, processing the request in an attempt to identify an organization that agrees to be charged in relation to the item on behalf of the visitor; and responsive to the attempt being unsuccessful, directing the visitor to a web page that permits selection of an organization that agrees to be charged in relation to the item on behalf of the visitor.

93. The method defined in claim 92, wherein processing the request comprises:

determining whether the request comprises authentication data pertaining to an organization with which an operator of the network entity has an inter- organizational billing arrangement; wherein the attempt is considered unsuccessful if it is determined that the request does not comprise authentication data pertaining to an organization with which an operator of the network entity has an inter-organizational billing arrangement.

94. The method defined in claim 92, wherein the request comprises putative authentication data pertaining to a requesting organization, wherein processing the request comprises:

wherein the attempt is considered unsuccessful if the putative authentication data cannot be authenticated.

95. The method defined in claim 92, wherein directing the visitor to the web page comprises carrying out an HTTP call with an address of the web page.

96. The method defined in claim 92, wherein the web page is hosted by the network entity.

97. The method defined in claim 92, wherein the web page is hosted by a payment locator website reachable from the network entity over the data network.

98. The method defined in claim 92, wherein the web page presents a list of payment options including at least one organization with which an operator of the network entity has an inter-organizational billing relationship.

99. The method defined in claim 92, wherein the web page presents a list of payment options including at least one organization maintaining an account for the visitor.

100. A network entity, comprising: at least one component configured for receiving a request for an item selected by a visitor to a website; at least one component configured for determining whether the request is a request for a payable item; at least one component configured for responding to determining that the request is a request for a payable item by processing the request in an attempt to identify an organization that agrees to be charged in relation to the item on behalf of the visitor; and at least one component configured for responding to the attempt being unsuccessful by directing the visitor to a web page that permits selection of an organization that agrees to be charged in relation to the item on behalf of the visitor.

101. A network entity, comprising: means for receiving a request for an item selected by a visitor to a website;

means for determining whether the request is a request for a payable item;

means for responding to determining that the request is a request for a payable item by processing the request in an attempt to identify an organization that agrees to be charged in relation to the item on behalf of the visitor; and means for responding to the attempt being unsuccessful by directing the visitor to a web page that permits selection of an organization that agrees to be charged in relation to the item on behalf of the visitor.

102. Computer-readable storage media comprising computer-readable instructions for instructing a network entity to:

detect receipt of a request for an item selected by a visitor to a website; determine whether the request is a request for a payable item; respond to determining that the request is a request for a payable item by processing the request in an attempt to identify an organization that agrees to be charged in relation to the item on behalf of the visitor; and respond to the attempt being unsuccessful by directing the visitor to a web page that permits selection of an organization that agrees to be charged in relation to the item on behalf of the visitor.

103. A website accessible over a data network, comprising: a memory storing data; and a network interface for communicating over the data network; wherein when the data is accessed by a browser over the data network, the data allows rendering of a web page on the browser, the web page displaying labels in association with items that can be selected by selection of the labels through interaction with the browser; wherein responsive to receipt of a request for a payable item selected by a user of the browser, the website directs the browser to a second web page that permits selection of an organization that agrees to be charged in relation to the payable item on behalf of the user.

104. The website defined in claim 103, wherein the website directs the browser to the second web page by carrying out an HTTP call with an address of the second web page.

105. The website defined in claim 103, wherein the second web page is hosted by the website.

106. The website defined in claim 103, wherein the web page is hosted by a payment locator website reachable from the website over the data network.

107. The website defined in claim 103, wherein the second web page presents a list of payment options including at least one organization with which an operator of the network entity has an inter-organizational billing relationship.

108. The website defined in claim 103, wherein the web page presents a list of payment options including at least one organization maintaining an account for the user.

109. A website accessible over a data network, comprising: memory means for storing data; and network interface means for communicating over the data network; wherein when the data is accessed by a browser over the data network, the data allows rendering of a web page on the browser, the web page displaying labels in association with items that can be selected by selection of the labels through interaction with the browser; wherein responsive to receipt of a request for a payable item selected by a user of the browser, the website directs the browser to a second web page that permits selection of an organization that agrees to be charged in relation to the payable item on behalf of the user.

110. A method, comprising: using a browser to visit a web page that displays labels in association with items that can be selected by selection of the labels through interaction with the browser; selecting a payable item from the web page;

selecting an organization that maintains an account for a user of the browser; accessing the payable item, wherein access to the payable item is controlled by an entity in a terminating network; wherein the terminating network issues a first charge to the organization under an inter-organizational billing arrangement between the terminating network and the organization, the first charge being in relation to the payable item; wherein the organization issues a second charge to the account, the second charge being in relation to the payable item.

1 11. The method defined in claim 1 10, wherein an absolute value of the second charge is at least as great as an absolute value of the first charge.

112. The method defined in claim 1 10, wherein the browser is implemented by a computing device that accesses the web page over an access network.

113. The method defined in claim 112, wherein the originating network is the access network.

1 14. The method defined in claim 112, wherein the originating network is not the access network, wherein the account is associated with credentials maintained by the organization, the method further comprising entering the credentials after selecting the organization.

115. The method defined in claim 1 10, wherein the payable item comprises at least one of media content, software, a reservation, a financial contribution and tangible merchandise.

1 16. A method, comprising: accessing a data network by supplying credentials associated with a user account maintained by an operator of an access network; using a browser to visit a web page that displays labels in association with items that can be selected by selection of the labels through interaction with the browser; selecting a payable item from the web page; selecting an organization that has (i) a first inter-organizational billing arrangement with a terminating network comprising an entity that controls access to the payable item and (ii) a second inter-organizational billing arrangement with the operator of the access network;

accessing the payable item via the terminating network; wherein the terminating network issues a first charge to the organization under the first inter-organizational billing arrangement, the first charge being in relation to the payable item; wherein the organization issues a second charge to the operator of the access network under the second inter-organizational billing arrangement, the first charge being in relation to the payable item;

wherein the organization issues a third charge to the account, the third charge being in relation to the payable item.

1 17. The method defined in claim 1 16, wherein an absolute value of the second charge is at least as great as an absolute value of the first charge.

118. The method defined in claim 1 16, wherein an absolute value of the third charge is at least as great as an absolute value of the second charge.

1 19. The method defined in claim 116, wherein the browser is implemented by a computing device that accesses the web page over an access network.

120. The method defined in claim 119, wherein the originating network is the access network.

121. The method defined in claim 119, wherein the originating network is not the access network, wherein the account is associated with credentials maintained by the organization, the method further comprising entering the credentials after selecting the organization.

122. The method defined in claim 116, wherein the payable item comprises at least one of media content, software, a reservation, a financial contribution and tangible merchandise.

123. A method, comprising: accessing a data network using a device;

providing credentials pertaining to an account established for a given customer with a first organization; accessing a payable item over a data network using the device, wherein content pertaining to the item is delivered by a second organization; wherein said accessing generates at least two charges, including a first charge from the second organization to the first organization and a second charge from the first organization to the account established for the given customer.

124. The method defined in claim 123, wherein the content pertaining to the item comprises at least one of media content and software.

125. The method defined in claim 123, wherein the content pertaining to the item comprises at least one of a news article, a video, a recipe, a ringtone, a greeting card and an app.

126. The method defined in claim 123, wherein the item comprises at least one of a reservation, a financial contribution and tangible merchandise.

127. The method defined in claim 126, wherein the content pertaining to the item comprises at least one of an electronic confirmation of a reservation and an electronic receipt for payment.

128. The method defined in claim 1 , further comprising: determining an identity of the entity that controls access to the item.

129. The method defined in claim 128, wherein the message includes an address returned by a website where the selected item is represented, and wherein determining the identity of the entity that controls access to the item comprises consulting a database on a basis of the address to obtain a numerical address of the entity that controls access to the item.