CA2239408A1 - Method of accessing service resource items that are for use in a telecommunications system - Google Patents

Abstract

Service resource items (49) for use in call setup in a telephone system are held on servers (58) that are connected to a computer network which is logically distinct from the telephone system infrastructure; this computer network may, for example, make use of the Internet. Each service resource item (49) is locatable on the network at a corresponding URI and is associated with a particular telephone number. A mapping is provided between telephone numbers and the URIs of associated service resource items. When it is desired to access a service resource item (49) associated with a particular telephone number, this mapping is used to retrieve the corresponding URI (step 55) which is then used to access the desired service resource item (56, 57, 59).

Description

METHOD OF AC(~ G SERVICE RESOURCE ITEMS THAT ARE FOR
USE IN A TELECOMMUNICATIONS SY~

s Field of the Invention The present invention relates to a mPthn-l of Acc~c~ service l~s~j.ulce items that are intPnriP~ to be used in setting up bearer rllAnnPl.~ through a ~wi~ ed telec~ ;on~ systcm.
As used herein, the term "switched telecc.. ,.,~.. ;rAtion system" means a system co~ isillg a bearer ll~Lwolh with :jwiLcl~es for setting up a bearer chAnnPl through the WO1k. The term '~wil~hed tclecn.~ ..;r~ion system" is to be taken to include notonly the c~isLillg public and private tcl~hr~ systems (whL~,r using analogue phones 15 or ISDN-based), but also broA~lhAnrl (ATM) and other switch-based bearer llt:LW ~
that are ~;ullcll~ly being impl~ -IPC~ or may emerge in the funlre. For con~ re,the tenn "~wiL~;hed t~lecol~ rAt;on~-systemll is somPtimPS shortened herein to telecol.. ~.-i~Afion system.

20 Ref~ lce to a "call" in the COllLt ~L of a switched teleco---~ --;r~tit)n system is to be nnriprstood as mP~ning a colllllllll~ir~tion through a bearer channel set up across the bearer l~wc.lk, whilst l~ ces to call setup, m~ ,.re and takedown are to be taken to mean the processes of setting up, m~int~ining and taking down a bearer channel through the bearer l~W- tlL Terms such as "call proceS~ing" and "call 25 h~nrlling" are to be similarly hlL~ ,~d.

The term '~cG.,lll.~..irAtion system" when used herein should be understood as having-a broader rnPAnin~ than switched teleco.. -mirAti~ n system, and is intPn~ to include data~çram-based col~ll lll l l li~tion ~y~ lls where each data paclcet is inriPpe~ tly routed 30 through a bearer l~,wu.k without following a prerlPr~ P~ bearer channel.

R~rk~.ou~ of the Invention Telecol...... -.. lic~t;on crlmr~ni~os running PSTNs (Public Switched Telephone Networks) and PLMNs ~Public Land Mobile Networks) are in the busilless of providing comnm-ni-~tion services and in doing so are providing increasing built-in int~ enre 5 in the form of "IN services" such as 800 number services and call forwarding. In contrast, the World Wide Web ~WW~, which has seen explosive growth in recent times, is an example of an Tnt~rn~t-based global 1l ;lwulh providing complex Lnforrnation services. These two worlds, that of the large co.l.. n~ ions lltiliti~s and that of the highly dynamic, pioneer-spirit WWVV inform~tion culture, are uneasy 10 companions and each plans to encroach on the domain previously occupied by the others; thus telephony services will be offered over the WWW and information services over the public c(Jlllllllll~ir~tion i~ Llucture.

The ~lese.lL invention proposes technologies for a more ~yllel~eLic relationship between 15 these two worlds than is cullellLly envisaged and in order to place the present invention in context, a review will first be given of each of these two worlds.

Telephone N~LWOrh~ with IN Services The Basic PSTN. The basic service provided by a PSTN (Public Switched Telephone Network) is the interconnection of two telephones (that is, setting up a bearer channel between the telephones) according to a called-party telephone number input at the calling-party telephone. Figure 1 is a simplified l~ ese~ .lion of a PSTN providing 25 such a service. In particular, c~-~tomrr pl~nlises eqllipm~t CPE, 10 (such as standard analogue telephones, but also more ,~cenLly ISDN t~ ) are connrcted through an access network 11 to ~wik;h~lg points, SPs 12. The SPs 12 form nodes in an inter-exch~nge l~eL~olh 13 made up of illlelco".~ i"2~ trunks 14 and SPs that are controlled by control entities 15 in the SPs. The control effected by the control entities 15 is 30 ~lel~ ed by ~i~n~llin~ inputs received from the CPEs and other SPs, and involves call setup, m~int~n~nre and clearance to provide the desired bearer channel between calling CPE and called CPE. Collceplually, the PSTN may be tnought of as a bearer lletwolh and a control (si~n~llin~ Lwolh, the function of the latter being to effect call control through the bearer network, namely the control of setup, m~ re and take down of bearer channels through the bearer neLw~ ; in practice, the bearer and ci~n~llin~ networks may use the same physical c}rcuits and even the same logical5 ch~nnPl.c.

Thus, where the CPE is a traditional dumb telephone, control cignzllling between the CPE and its local SP is in-band cign~llin~, that is, the sipn~lling is carried on the same ch~nnPl as used for voice; this si~n~liin~ is illL~l~lcLed and converted at the SPs 12 into 10 .ci~n~llin~ between SPs that uses a ~ ir~t~(l common-channel ~i~n~llin~ lk 16 (implelnPnt~l nowadays using the SS7 protocol suite~. Where the CPE is an ISDN
terminal, .si~n~llin~ is carried in a separate ch~nnPl directly from the CPE on an end-to-end. Modern SPs use the lSUP (ISDN User Part) SS7 protocol for inter-exchangecall control ci~n~ll;n~ whether the CPE is a standard telephone or an ISDN terminal.
Telephone Numbering Plans - As certain aspects of the present invention are in~llPnrecl by the structuAng of telephone numbers, a brief description will now be given of the structuring of such numbers. Telephone numbers form an inten~tional, hierarchical addressing scheme based on groups of decimal digits. The top level of the 20 hierarchy is ~ ,d by the ITU-T, which has allocated single-digit numeric codes to the major geographic zones (for example "1" for North America, "2" for Africa, "3" for Europe, "4" ~or Europe, "5" for South America and Cuba, etc.). Within each zone cou~ ies are ~csi~nP(l 2 or 3 digit codes, so that within zone 3 France is "33", and within zone 4 the UK is "44". ~minictration of the numbering plan within a 25 country is delegated to a national body, such as the Office of Telecolllll~ lic~tions ("Oftel") in the UK. The following further description is based on the UK numbering plan, but the sçhPmP described will be recognised as having widespread applicability.

In the UK all national numbers are prefixed by a code from 01 to 09 (the '0' prefix is 30 dropped in inl~l.laLional ~ lin~. The currently ~cci~npd codes are "01" for Geographic Area Codes, "02" for Additional Geographic Area Codes, "04" for Mobile Services, "07" for Personal Numbers, and "08" for Special Service (freephone, , illÇol~ Lion). Normal wireline PSTN subscriber telephone numbers are allocated from the Geographic Area Code codes, and ~ c~llly only codes prefixed by 01 are allocated. Geographic area codes are ~lcse.ltly 3 or 4 digits (Pxclll-ling the lp~ n~ '0') and there are cull~,.llly 638 geographic areas each with its own code. A full n~ti~n~l S UK dialled number takes two forms:

area code local number (7 digit) area code local number (6 digit) lO The first case has the ~0' prefix, a 3 digit area code and a 7 digit local n--m~ler, and the second case has the '0' pre~lx, a 4 digit area code, and a 6 digit local nurnber.
Further i~L~ ,L~Lion of the local number will take place within the area exchange, as even a 6 digit address space is too large for a single switch, and for a typical local area several switches may be needed to host the required number of sul)sclibel lines. Ihis 15 inte~ Lation is opaque and is a matter for the area service provider.

In the current PSTN the inlle.~llLly hierarchical and geographic inL~ L~tion of telephone numbers is mirrored by the physical ar~ r.;~ of the network. A telephone number is structured in a way that makes it easy to route a call through the network.
20 At each step, the prefix of the number provides information about the current routing step, and the suffix (perhaps opaquely) provides i~ ation about sllhse~ tont routing steps; as long as a switch knows how to parse a prefix and carry out a routing step, it does not need to understand the content of the suff~, which is left for sn~seqll~nt routing steps. For this reason the hlLt;~lldLional and national :~wiL~ h~g fabric is also 25 org~"i~ecl hierarchically.

~nt~lligent N~lW~fhs. R~tllrn;n~ now to a consideration of the current telephonenetwork infra~LlLILul~,, in addition to ~asic call h~nAling, an SP may also serve to provide what are called IN (Intelligent Network) services; in this case the SP is terrned 30 a service ~wiL~ lg point~ SSP. An SSP 25 is arranged to suspend call proceccing at defined points-in-call upon particular criteria being met, and to delegate the co~timl~tinn of call procescing to a service control sul~y~L~,ll providing a service W O 97~2212 PCT/GB96/03055 s control function (SCF~ either in the form of a service control point, SCP 17 (see Pigure 2) or an Ad3unct 18. The Adjunct 18 is dileL~ associated with an SSP 25 whilst the SCP 17 and SSP 25 c~ ic~te with each other via an ~tPnrlPd common ~h~nnPl ~ si~n~lling (CCS) ll~Lwolk 16 that may include signal Ll~,~r~. points (STP) 19. The SCP
5 17 may be associated with more than one SSP 25. Both the SCP 17 and Adjunct 18provide a service logic t-~Pc~ltion envho.~ll,e"L (ST EE) 20 in which in.ct~nres of one or more service logic programs (SLP) 21 can e~r~Clltt~. The SLEE 20 and ST P 21 together provide service control functionality for providing services to the SSP 25.

10 Service logic running in an SCP or Adjunct will generally make use of subscriber inforrnation stored in a service data function (SDF) 22 that may be integral with the SCP/Adjunct or partially or wholly separate tl~ic~fiunl. The service data function (SDF), like the service control function (SCF) forms part of the service controlsubsystem of the PSTN. It may be noted that some or all of the service control filn~tion 15 may be built into the PSTN switches th~m~lves.

In addition to the SCP 17 and Adjunct 18, the Figure 2 n~Lv~ k includes an intelligent peripheral (IP) 23. The IP 23 provides resources to the SSP 25 such as voice all,lu...~ ent~ and DTMF digit collection capabilities. The network will also include 20 an operation system (not shown) that has a general view of the neLwo.h and its services and ~e~rol.lls functions such as netw~,lh monitoring and control.

In operation, when the SSP 25 receives a call, it ex~min~s internal trigger con-liti~ ns and, possibly, user information (eg dialled digits) to ascertain if the call requires a 25 service to be provided by the service control subsystem 17, 18; the ~-hl-cking of trigger conditions may be carried out at several dirre~ lL points in call procec~ing. Where ~e SSP 25 determines that a service is required it messages the service control subsystem (either SCP 17 or Adjunct 18) requesting the desired service and s~nrlin~ it a logic .c~se~ lion of the call in terms of its connectivity and call processing status. The 30 service control sul~ telll then provides the reqllest~rl service and this may involve either a single interaction between the SSP and service control su~system or a session of interactions. A typical service is call ful~-dil-g which is a called-party service giving expression to an end-user requirement as simple as "if you call me on number X and it rings ten times, try calling number Y". In this case, it is the SSP local to the called end-user that triggers its associated SCP (or Adjunct) to provide this service; it will, of course, be ~lcciated that the SSP must be primed to know that the service 5 is to be provided for a called number X.

The above-described model for the provision of IN services in a PSTN can also bemapped onto PLMNs (Public Land Mobile N~lwulh~) such as GSM and other mobile lletwolhs. Control sign~tlin~ in the case of a mobile subscriber is more complex10 because in addition to all the usual sign~lling re~luil~nlc.lL~, there is also a need to establish where a call to a mobile s~lbscriher should be routed; however, this is not a very dirfcl~llL problem from a number of called-party IN services in the PSTN. Thus in GSM, the service data function (SDF) is largely located in a system named a Home Location Register (HLR) and the service control function in a system named a Visitor 15 Location Register (~7LR) that is generally associated on a one-to-one basis with each SSP (which in GSM termin~logy is called a Mobile Switching Centre, MSC).

~ec~n~e subsc,ibe,~ are mobile, the ~ubs~;liber profile is transported from the HLR to whichever VLR h~ e,ls to be functionally closest to be mobile subscriber, and from 20 there the VLR operates the (fixed) service using the subscriber profile and interacts with the SSP. The HLR and VLR thus eo,~ ule a service control sub:~y~elll sirnilar to an SCP or Adjunct with their ~csoci~terl ri~t~h~ses.

It is, of course, also possible to provide IN services in private telephone systems and~
25 in this case, the service control function and service data function are generally either i"legldl~d into a PABX (Private ~ntom~tic Branch F.xch~nge) or provided by a local colll~ulel. The service control subsys~ , whi~st present, may thus not be a physically t;nrt from the PABX.

30 The above-described general archit~octnral rl~ e~1volh for providing IN services has both ~Ll~;n~ s and flaws. Its main ~Lrell~Lh is that it worlcs and many services have been s~lcces~fully deployed, such as 800 number services, credit card calling, voic~m~il, and various caU waiting and .~ clion services. However, despite years of stand~~ n, services are still impl~ ~ one-at-a-time on ~l~)pli~t~y ~I~IÇ(~.,.~ and do not scale well. The approach has been based on large, fault-tolerant ~y~klllS which provide services for hundreds of thousands or even millions of subscribers and take S years to deploy. Furthe~more, since the ~ wo-l~ used to support these services also co.lsLiLule the basic telephone infrastructure, anything ~tt~rh~d to these n~;~w~l~ must be rigorously vetted. Additionally, each country and ~u~lalor tends to have local variations of the so called standards m~kin~ it ~liffirl11t to supply standard products and Lll~rel,y braking the dynamics of co~eLiLic,ll.
Recendy, there have been proposals for i~.~ing the fl~ihili1y of public ~ s ystems. The following clo~ ; desenhe a num r of such ~u~o~dls;

"Method and system ~or co~ u!~ the operaffon of a t~lep~- ~ e~r~ ge from a 15 sulr_.il,cr cc; - _ " WO/9423523 Nokia 13.10.94 This document describes how an SCP can be provisioned with col-n-,and macros over a subscriber connection.

" ~e~ of Open Advanced InteUigent Network Interface for Public ~. ' ' e~l 20 TelephoneNeh.~.k" US5,438,568 BellsouthCo~poration 1.8.95 A mediation SCP monitors all m~C~gt~S to and from third-party service logic programs lUlllliny" for example, on a third-party SCP.

"Customers in Driver's Seat: Private Intelligent Network Control Point"
25 M. Sevcik; RLueder(Siemens~23.4.95 ISS Sy~ o~
This document describes a private SCP (PSCP) com~e~;t~,d to a rlclwu~k SCP (NSCP) via a TCP/IP co~ ioll The NSCP r~,l w~ds ~n~1qt~sd INAP messages directly to the PSCP. The PSCP is shown CUl.~le~,ltCl as a l~,soul~;e on a private TCP/IP LAN for ~cces~;..g ~l~t~b~e information.
"Distributed intelligence and data in public and private nel~.~.l~"
R.P. Swale & D.R Chesterton BT Technology Journal, 13 (l995)April No.2 AMENDED SHEET

, This document ~lis~;usses first and third-party CTI, the latter being termed "private ~'. A
co.~ on is then made b~ L~c" private and public IN, it being noted that they are often colllyl~ . Finally, possibilities for interconnection of private and public ~N are discussed including the accessh~g of a private d~tAb~e by a public IlGLwv~ SCP.
S

The World Wide Web I~ couLl~L to the slow delil~.at~ progress of the tel~)h- n~ i~L~u~;Lul~, the WWW has grown explosively from its inception in 1989 to become the ~ el~;LIollic 10 i~ol~Lion di~LlibuLion service in terms of spread, availability and richness of i. rol~ion content. Anyone can, for a modest outlay, become an i~Ço~ aLion provider with a world-wide ~A~ nre in a highly hlL~ ru~ ~IIAI ion archil~ e.

The WWW is a client-server appli~Ation nmning over the T..~".~ot and using a client-15 server protocol which l~AI~Al~ s only the sirnplest of e~ehAnges b~eell client andserver. This protocol is HTTP (Hyper Text Transfer Protocol) which is u~ti-~lised for use over TCP/IP llt~W~l~ such as the Tn~ ; the HTTP protocol can, however, also be used over n~w~l~ using dirr~ lL COIIIIII~ 'AI;OI) protocol stacks.

20 Since the availability of li~tl~Lul~ col-re...i.~g-the WWW h~ seen the sarne sort of growth ~ the WWW itself, a ~le~Atle~l description of the WWW, HTTP and the Tnter~i~t will ~t be given herein. An outline description will, however, be given with attention being paid to certain features of relevance to the present invention.

25 The WWW uses the TntPrniot for interc~nnPctivity. Tnte~nPt is a system that co~ec~
together nt;lwo,l~ on a worldwide basis. Internet is based on the TCP/IP protocol suite and provides connectivity to nc~Lw~ ~ that also use TCP/IP. For an entity to have a presence on the T-.~ t, it needs both access to a neLw(,ll~ collllp~(~ to the TntP~nPt AME~DED SHEE~

W O 97~2212 PCT/GB96/03055 and an IP address. IP addresses are hierarchically structured. Generally an entity will be identifiPfl at the user level by a name that can be resolved into the corresponding IP address by the Domain Name System (DNS) of the T~ l Rec~lce the DNS or adaptions of it are fim~ 1 to at least certain embo-lim~ntc of the inventionS described h~lc~rl~, a description will next be given of the general form and operation of the DNS.

The Domain Name System - The DNS is a global, di~Llil,u~ed, (l~t~h~e, and without its pe~rol ...~ e, recili~nre and scalability much of the Tnte~nPt would not exist in its current form. The DNS, in response to a client request, serves to associate an Jnt~rn.Qt host domain name with one or more Registration Records (RR) of ~lirr~ types, themost common being an address (A) record ~such as 15.144.8.69) and mail exeh~n~er~MX) records (used to identify a domain host configured to accept electronic mail for a domain). The RRs are di~Llil,u~ed across DNS name servers world-wide, these servers coupeldLillg to provide the (lnm~in name translation service; no single DNS
server contains more than a small part of the global ~t~b~e, but each server knows how to locate DNS servers which are "closer" to the data than it is. For presentpurposes, the main characteristics of the DNS of interest are:
-- The host name space is or~ni~erl as a tree-structured hi~_ldl~;hy of nodes with each host having a corresponding leaf node; each node has a label (except the root node) and each label begins with an alphabetic e~ er and is followed by a sequence of alphabetic characters or digits. The full, or "fully q~-~lifi~
name of a host is the string of node labels, each separated by a ". ", from the corresponding leaf node to the root node of the hie~a~ y, this latter being represellt~l by a termin~tin~ "." in the narne. Thus a host m~rllin~ "fred" of Hewlett-Packard LabolaLolies in Bristol, F.n~l~nt1 will have a fully qrl~lifitoddomain name of "fred.hpl.hp.com. " (note that if a host name does not have a ~e. n.i~ l. l' it is hlL~ L~d relative to the current node of the ~ ing hiel;~;lly).
30 -- Each host has one or more associated Registration Records ~RRs).
-- There are a plurality of DNS servers each with responsibility for a subtree of the name space. A DNS server will hold RRs for all or part of its subtree - in " . . , ,, t ~ i .. . ..

_ the latter case it rlel~t~s le;,~onsibility for the rem~in-lPr of the subtree to one or more further DNS servers. A DNS server knows the address of any server to which it has delegated ~c~o~lsil)ility and also the address of the server which has given it the responsibility for the subtree it m~n~s The DNS servers thus point to each other in a structuring refl~Pctin~ that of the ~ hit;lal-;hy.
-- An application wishing to make use of the DNS does so through an associated "resolver" that knows the address of at least one DNS server. When a DNS
server is asked by this resolver for an RR of a specified host, it will return either the reql1este(l RR or the address of a DNS server closer to the server holding the RR in terms of traversal of the n~ming hierarchy. In effect, the hierarchy of the servers is ~ccentlt~d until a server is reached that also has responsibility for the dom~in name to be resolved; thelearl~,., the DNS server hierarchy is descended down to the server holding the RR for the dom~in name to be resoived.
15 -- The DNS uses a predet~ message format (in fact, it is the same for query and response) and uses the IP protocols.
These characteristics of the DNS may be considered as defining a "DNS-type" system always allowing for minor variations such as in labe~ syntax, how the labels arecombined (ordering, separators3, the message format details, evolutions of the IP
20 protocols etc.

Due to the hierarchical n~ming structure, it is possible to ~PhPg~P responsibility for mini~terin~ ~om~in~ (~ubLl~,cs) of the name space recursively. Thus, the top-level domains are ~-lmini~tPred by InterNic (these top-level domains include the f~mil;~r 25 'com', 'edu', 'org', 'int', 'net', 'mil' domains as well as top-level country domains specified by standard two-letter codes such as 'us', 'uk', 'fr' etc.). At the next level, by way of example Hewlett-Packard Company is respon,sible for all names ending in 'hp.com' and British Uni~ i1ies are collectively responsible for all names ending in 'ac.uk'. DPs~Pn~1in~ ~urther, and again by way of example, ~flmini~tration of the 30 domain 'hpl.hp.com' is the responsibility of Hewlett-Paclcard Laboratories and ~imi~ ,dlion of the subtree (domain) 'newcastle.ac.uk' is the responsibility of the University of Newcastle-upon-Tyne.

W O 97/~2212 PCT/GB96/03055 Figure 3 illll~trAt~s the progress of an example query made from within Hewlett-Packard Laboratories. The host domain name to be resolved is 'xy.newcastle.ac.uk', a hypoth~ticAl mAt~llin~ at the University of Newcastle, United Kingdom. The query is ~l~s~ el1 to the DNS server responsible for the "hpl.hp.com" subtree. This server S does not hold the reql~rste-l RR and so ~ ollds with the address of the "hp.com" DNS
server; this server is then queried and lcs~ollds with the address of the 'com' DNS
server which in turn responds with the address of the '.' (root) DNS server. The query then proceeds iL~ldlively down the 'uk' branch until the 'newcastle.ac.uk' server responds with the RR record for the name 'xy' in its subtree.
This looks extremely inefficient, but DNS servers are ~1r~i~n~od to build a dynamic cache, and are ;nitiAli~erl with the addresses of several root servers, so in practice most of the iterative queries never take place. In this case the 'hpl.hp.com' DNS server will know the addresses of several root servers, and will likely have the addresses of 'uk' 15 and 'ac.uk' servers in its cache. The first query to the 'hpl.hp.com' server will return the address of the 'ac.uk' server. The second query to the 'ac.uk' server will return the address of the 'newcastle.ac.uk' server, and the third query will return the RR in question. Any future queries with a 'newcastle.ac.uk' prefix will go direct to the newcastle DNS server as that address will be retained in the "hpl.hp.com" DNS server 20 cache. In practice names within a local subtree are resolved in a single query, and names outside the local subtree are resolved in two or three queries.

Rather than a resolver being lei,~ollsible for carrying out the series of query iterations required to resolve a dom~in name, the resolver may specify its first query to be 2~ recursive in which case the receiving DNS server is l~ oilsible for resolving the query (if it cannot directly return the requested RR, it will itself issue a recursive query to a 'closer' DNS server, and so on).

It should also be noted that in practice each DNS server will be replir~t~l7 that is, 30 o~ e(1 as a ~ laly and one or more secondaries. A primary DNS n~mrserver initi~ es itself from a database m~int~in~tl on a local file system, while a secondary initi~ es itself by trall~rc~ g information from a plhllaly. A subtree will normally have one p~ ~ly n~Tmpserver and ~l~yLllill~ up to ten secondaries - the limit~tion tends to be the time required by the secondaries to update their ~1~t~b~es from the ~ llal.y.
The ~ llal y ~l~t~b~ce is the master source of subtree infollllation and is m,Tint~inP(l by the domain DNS ~lTni"i~ Jr. The secondaries are not simply standby secondaries but 5 each actively ~alLici~aLes in the DNS with ~1~pPnr~e~t servers that point to it rather than to the corresponding ~lilll~ly.

DNS irnplemtont~ti~ns7 such as BIND, are widely available as a standard part of most UNIX systems, and can claim to be among the most robust and widely used distributed 10 applir~tion~ in ~ re Operation of the WWW Referring now to Figure 4 of the acconlpallyillg drawingst access to the Internet 30 may be by direct comle.:~ion to a lleLwolh that is itself ~ Lly or hldil~ ly connrcte~l to the Internet; such an arrangement is repre~rnt~-l by terminal 15 31 in Figure 4 (this ~e...,;~l may, for example, be a Unix wo-k~ tion or a PC).
Having a connection to the Internet of this form is lcnown as having 'llcLwc"h access'.
Any entity that has network access to the Internet may act as a server on the TntrTnPt provided it has s Tffic~irnt associated functionality; in Fi~ure 4, entity 32 with file store 37 acts as a server.
Many users of the WWW do not have network access to the Internet but instead access the Tnternet via an Tnterrrt service provider, ISP, 33 that does have network access.
In this case, the user L~ h~al 34 will generally co,.l",~l"ir~te with the ISP 33 over the public telephone system using a modem and employing either SLIP (Serial Line 25 Interface Protocol) or PPP (Point-to-Point Protocol). These protocols allow Internet packets to traverse ordinary telephone lines. Access to the Internet of this form is known as "dialup IP" access. With this access method, the user terminal 34 is - temporarily allocated an IP address during each user session; however, since this IP
address may differ between sessions, it is not practical for the entity 34 to act as a 30 server.

A cornerstone of the WWW is its ability to address particular i~ alion resourcesby means of an Uniform Resource T11entifiPr (URI) that will generally be either a Uniform Resource Locator (URL) that ~ ntifies a resource by location, or a Uniform Resource Name (U~N) that can be resolved into an URL. By way of example, a full S or "absolute" URL will cu,llL,lise the following e~ .onte sr~nne - this is the access scheme to be used to access the resource of illL~ L;
host - the Internet host domain name or IP address;
port - the host port for the (TCP) conn~ct;on;
abs-path - the absolute path of the resource on the host.
In fact, the 'port' may be omitt~l in which case port 80 is ~eellm~-l Figure S of the accompanying drawings shows an example URL for the Hewlett-Packard products welcome page. In this case, the el~m.orlte are:
scheme - http host - www.hp.com port - omitt~-(l (port 80 ~e~nm~
abs-path - Products.html 20 The HTTP protocol is based on a request/response paradigm. Referring again to Figure 4 of the drawings, given a particular URI idellLifyillg a resource 30 to be ~rcee.eed, a client establishes a connection with the server 31 eGl~ onding to the "host" element of the URI and sends a request to the server. This request inr~ .os a request method, and the "Request-URI" (which is generally just the absolute path of the les~ulce on the 25 server as ifl~ntifi-?fl by the "abs-path" elennr-nt of the URI); the request may include additional data elem~nt~. The server 31 then ~rcç~ses the resource 36 (here held on storage 37) and responds and this response may inc}ude an entity of a type i~l~ntifi~i by a MIME (Multipurpose Tnt~rn~t Mail F~rt~n~i~ns) type also inehl~lerl in the response.

30 The two main request methods are:
GET - Ihis method results in the retrieval of wh~Lt:vel- information (in the forrn of an entity) is i~lentifito~l by the Request-~l. It is irnportant to note that if the Request-URI refers to a data-producing process, it is the produced data which is retnrnP~l as the entity in the response and not the source text of the process.
POST - This method is used to request that the ll~pstin~ti~n server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI. The POST method can be used for annotation of P~ictin~ resources, providing a mec.c~e to a bulletin board, providing data to a data-h~nrlling process (for example. data produced as the result of submitting a form), and ~x~ i"~ a ~t~bace through an append operation.
In ~ -y, the GLT method can be used to di~c;cLly retrieve data, or to trigger any process that will return an entity ( which may either be data or a sirnply an indication of the result of lul.lPi~ the process). The POST method is used for regi:jL~lhlg data and specifying this mPth-)~l is also effective to trigger a process in the server to handle the 15 posted data a~lu~ ly.

The p~.ccing of information to a process triggered to run on a server using either the GET or POST method is ~;u~ ly done according to an interface called the Common Gateway Interface (CGI). The receiving process is often written in a seli~Lil~g language 20 though this is not eccerlti~l~ Typically, the triggered server script is used for interfacing to a database to service a query included in a GET request. Another use, alreadyed to, is to append data associated with a POST request to a c~t~h~ce.

Other illl~olL~ factors in the success of the WWW is the use of the HyperText 25 M~rkl-p T.~n~l~ge (HTML) for representing the m~kP~lp of docnmPntc Lld~ ed over the W~WV, and the availability of powerful graphical Web l~lVW'7el~7, such as Netscape and Mosaic, for hl~ leLillg such docnmPntc in a client terrnin~l to present them to a user. R~cir~11y, HT ML iS used to identify each part of a ~locnmPnt, such as a title, or a graphic, and it is then up to the b1OW~eL running in the client tPrmin~l to decide how 30 to display each document part. However, HTML is more than this - it also enables a URI and a request method to be associated with any element of a docllmPnt (such as a particular word or an image) so that when a user points to and clicks on that element, _ CA 02239408 l998-06-03 W O 97~2212 PCT/GB9GI-~3055 the resource itlPntifi~A by the URI is acces~e-l according to the sçh~m~ (protocol) and request method specified. This a~ V~ provides a hyperlink from one docllmpnt to another. Using such hyperlinks, a user at a client 1~ can skip effortlessly from one doctlmPnt downloaded from a server on one side of the world, to another doc~mPnt 5 }ocated on a server on the other side of the world. Since a doclTmPnt created by one author may include a hyye~ k to a cioc~lmPnt created by another, an extremely powerful docl-ment cross-referring system results with no central bureaucratic control.

Hyperlinks are not the only intelti~enre that can be built into an HTML docllm~nt 10 Another powerful feature is the ability to fill in a downloaded "Form" docllm~nt on screen and then activate a 'commit' gr~phir~l button in order to have the entered information passed to a resource (such as a ~l~t~b~e) t1eei~n~rl to collect suchinformation. This is achieved by associating the POST request method with the 'cornmit' button together with the URI of the tl~t~h~e resource; activating the 15 'commit' button results in the entered il~~ ation being posted to the i-l.ontifi~d resource where it is a~~ iately h~n~llP~, Another powerful possibility is the association of program code (generally scripts to be hllel~l~Led) with particular do~ elçmPntc, such as graphical buttons, this code 20 being ex~c~ltt~l upon the button being activated. This opens up the possibility of users downloading program code from a resource and then running the code.

It will be appreciated by persons skilled in the art that HTML is only one of several ~;ullc.lLly available scli~Lillg l~n~l~ges delivering the functionali~ty o~ltlint~(l above and 25 it may be expected that any serious Web bl~1w~er will have built-in :ju~polL for multiple scli~lillg languages; For example, Netscape 2.0 supports HTML 3.0, Java and LiveScript (the latter being Netscape proprietary scli~Lillg Language).

The illlpo.L~llce of the role of the graphical Web browser itself should not be 30 overlooked. As well as the ability to supporL multiple ~Cli~Lil~g languages, a Web browser should provide built-in support for standard media types, and the ability to -load and execute programs in the client, amongst other f~aL~ s~ These brow~e~ may be viewed as operating systems for WWW interaction.

WWW and the Telephone Network S It is possible to provide a telephony service over the TntPrnPt between connPcte(l telTnin~lc by t1jgiti.cinp voice input and .senriing it over the Tnt~rnPt in disc.~.~ packets for reassembly at the receiving te-rmin~l. This is an example of a co~ r~tion service on the TntrrnPt Conversely, it is possible to point to a variety of hlro~ ation services provided over the telephone system, such as the Minitel system widely 10 available in France. However, these encro~chmçntc into each anothers traditional territories pose no real threat to either the Internet or the public telephone system.

Of more ill~e,~sL are areas of coo~elaLiv-e use of the Internet and the telephone system.
In fact, one such area has existed for some concid~r~hle time and has been outlined 15 above with ,~relc;"ce to Figure 4, namely the use of a modem link over the PSTN from a user co~ ,, 34 to an Tnt~rnPt service provider 33 in order to obtain dialup IPaccess to the Internet. This cooperative use is of a very simple nature, namely the setting up of a bearer charmel over the PSTN for subse~uently ~el,.,.ated Tntern.ot traffic; there is no true interaction between the TnternPt and the PSTN.
Another known example of the cooperative use of the Tnt~rnPt and PSTN is a recently l~llnrhP~ service by which an Internet user with a sound card in his/her terminal col,l~uLel- can make a voice call to a standard telephone allywhelc: in the world. This is achieved by ~ ling ~igitice~l voice over the Tnt~ornPt to a service provider near 25 the ~lrstin~tiQn telephone; this service provider then connects into the local PSTN to access the desired phone and t.~L~ across into the local PSTN the voice traffic received over the Internet. Voice input from the called telephone is h~nrlkofl in the reverse manner. Key to this service is the ability to identify the service provider local (in telephony cha~ , terms) to the ~lestin~tion phone. This arrangement, whilst 30 offering the prospect of competition for the telecom opel~tol~ for long fiict~nre calls, is again a simple rh~ining together of the Internet and PSTN. It may, ho~ev~l, be noted that in this case it is nPcesc~ry to provide at least a l.,illi,.,,l,,- of feedback to the Internet calling party on the progress of call set to the ~k~stin~tic~n telephone over the PSTN local to that telephone; this feeflh~rk need only be in terms of whether or not the call has sneceerlerl.
.

S From the foregoing it can be seen that the current cooperative use of the Internet and telephone system is at a very simple level.

It is an object of the ~l-,S~ invention to provide a method of af~Cf~ g a service resource item over a cc{,.",ll.lir~tions llelwolh that facilitates the illLe~ldLion of the PSTN and the WWW.

S~ of the Invention According to the present invention, there is provided a mf thf fl Of ~rcessing service resource items for use in respect of setting up bearer ch~nnf-l~ through a switched telec~""~,."-ic~ ions system, the method including the steps of:
(a) -- provisioning at least one server col~llfc~fl to a crJl~ el lleLwolk with a plurality of service resource items that are thereafter locatable on said cO~ uler e~wolh by corresponding known URIs, said c~ ,u~ woll~ being logically tinrt from the teleco~ r~tions system, and said service resource items relating to setup control for bearer rll~nnfls through said teleco,,,,l~ ir~tions system with each said service resource item being associated with a respective pref~lf tf rminf-fl code, said prefiPl~"~ f~fl codes being distinct from said URIs and identifying end-point entities for said bearer ~ nn~
(b) -- providing a lll~pillg between each said pre~lel~ " ~ rl code and the said known URI of the service resource item associated with that prerleterrninpfl code; and(c) -- lltili.cing a said pred~t~r~ninPcl code to access a corresponding said service resource item by using said lllappiilg to cle~r., 1 l li~lP the URI corresponding to that resource item and then using this URI to access the service resource item over said con~ Lel network.
In one emborlimPnt at least some of the URIs are derivable from their corresponding said preflPtPrrninPtl codes by manipulation according to a function specified by said ma~pillg. In another embo~lim~nt, at least some of the URIs are derivable from their corresponding said pre-lrl~ in~d codes by look up in an association table acsociating said prede~e.,-~ P(l codes and URIs according to said mapping. This association table can advantageously be held on at least one database server cn...~ e~l to the co~ L~l S lle~wolh, step (c) involving ~Ccçccin~ the fi~t~h~ce server over the colrl~uLer n~lw~lk to ~ the URI corresponding to the said pre~el~.--.i--Pcl code. Pre~erably, the said at least one fi~t~h~ce server is provided by a DNS-type di~ uled ~t~h~ce system in which the URIs are held in records associated with lt:*,e~;Live names, herein referred to as dom~in names, by which the records can be lcLIi~v~d. In this case, step (c) 10 involves tr~ncl~tinE~ said pre~lele~ od code into a corresponding domain name and using this ~lom~in name to retrieve the URI of the re~uired service resource item from the DNS-type di~libult;d database system.

More than one service lesvul-;e item can be located at the same URI; in this case, the 15 precletermine~l codes of these service resource items will include l~ CCLi~ relative-resource-i~lenti~ler values that can be used at the server holding the service lesuulce items to identify the required l~o~ ;e item amongst the service resource items at the same URI.

20 The teleco..~ tinns system may be a telephone system with each said predetermined code being either the telephone number of the calling party or thetelephone number of the called party (these numbers may either be the numbers ofspeci~lc telephones, or personal numbers). Tn one preferred embo~lim~nt where at least some of said predelc~ ined codes are called-party telephone numbers, the 25 corresponding service resource items are the current telephone numbers of the called parties.

Generally as regards the nature of the service resources, these may be of the following type:
30 -- service logic int~n-lef~ to be e~cl-te~l by the corresponding server upon being ~ ces~e-l with the result of this execution being returned to the ~ecesstn~ entity;

_ -- downloadable service data which upon being ~rces~ecl is intrrl~le~l to be downloaded to the accessing entity;
-- downloadable service logic which upon being 7~cc~c~e~1 is inten-1P-l to be downloaded to the ~L~c~ entity for ~eClltion thereby.
Preferably, where URIs are referred to in the foregoing, these URIs are URLs and/or URNs. Fu~ .more, the servers referred to are preferably HTTP servers.

It is to be understood that 1~ r~ ,~.lce in the foregoing to the colll~ulel network being 10 logically ~ t;nrt from the te1Pcol~ lllir~tions system is not to be taken to imply that there is physical ~al~lion of the two - indeed, there will frequently be joint use of the same physical infrastructure. Purthermc re, not only may bearer çh~nnrl.c set up in the teleco","-----ir~tions system share the same tr~n~mi~c~ion metlillm as the colll~ULc;~-networL, but such a bearer channel may act as a pipe for traffic across the c~ uL~r 15 lletwo,L. ~e~intention of requiring the com~uLellletwolh to be logically ~ tinrt from the telec~-"",-"-i~rions system is to e~rlu~le CO~ JUI~ W~lh~ that are (lprlir~trrl to the management or molli~olhlg of the bearer l~Lwolh and effectively form part of the teleco"~-",..ir~tions system itself.

20 Preferably, the colll~u~ u~l~vork is generally ;Iccecsihle to users of the telecc",l""-"ir~tions system as this provides a number of benefits to users that will become a~alelll hereinafter. The phrase "generally ~ccecsihle" should not be construed as mr~ning that all users of the telec~n",~ ir~tions system have such access to the coll~ulel network or can get such access but, rather, it should be understood as25 mr~ning that a si~nifir~nt proportion of these users have or can obtain access to the com~ulel l~elwolh.

By way of example, in one preferred embodiment of the invention, the c~ ulel-ll~lwolh generally ~rce~ible to users of the teleco~-""~ ir~tions system but logically 30 tii~tinrt from it, is the Internet and the telec~,."llllllir~l;ons system is a public telephone system. In another embo~iim~nt~ the telec~".""l"~ir~tiQn system is a private system including a PABX, and the colll~uL~l ne~wolh is a LAN.

Brief DeS~L~ GI~ ofthe D~wi-.ci ~ nbo-lim~nt~ of the ~l~esellL invention will now be described, by way of non-limiting S example, with ~ ce to the accompanying diagr~mm~tir drawings, in which:
.Figure 1 is a simplified diagram of a standard PSTN;
.Figure 2 is a simplified diagram of a known PSTN with ~N service capability;
.Figure 3 is a diagram ill~ t;ng host tlom~ name resolution by the DNS of the Internet;
10 .Figure 4 is a ~i~gr~m illU~llatill~ the functioning of the World Wide Web;.Figure 5 is a diagram illustrating the format of a ~L~lldal~l U3~L;
.Figure 6 is a diagram of a first allall~,elllent in which service resource items are held on HTTP servers ~rces~ible both by the service control sub~y~
of a PSTN and by Web users;
15 .Figure 7 is a diagram illustrating the proce~.cing of a service request by the SCP
of Figure 6;
.Figure 8 is a diagram illu~Ll~lhlg the format of a resource code used by the Figure 6 SCP when ~ce~in~ a service resource item;
.Figure 9 is a diagram illustrating the process of ~ccessing a service resource in the case where the service code does not include an RRI part;
.Figure 10 is a diagram illu~ldLhlg the process of ~'~CÇSSing a service resource in the case where the service code includes an RRI part;
.Figure 11 is a diagram illustrating the derivation of the URI of a service resource by pal~ an input telephone number in accordance with the present invetion;
.Figure 12A is a ~ gr~m depicting a name space (the "tçln~mP space") con~titl~tP~I
by the domain names derived by a parsing of a preflpt~orrnint~ set of telephone mlmhers, .Figure 12B is a diagram depicting the incorporation of the telname space without fragrnentation into the DNS;
.Figure 12 C is a diagram depicting tbe incorporation of the telname space in fr~gm~tP~l form into the DNS;

.Figure ~3 is a diagram illlr.~ the overall operation of the Pigure 6 arrangement in providing a roaming number service in response to a telephone number being dialled at a standard phone;
.Figure 14 is a ~ gr~m illustrating the overall operation of the Pigure 6 a~ llent when utilised by a Web user in setting up a call through a telephone inteT f~re integrated into the user's Web ~ illal;
.Figure 15 is a diagrarn ill~ g the overall operation of an ~ ,e~ nt in which an interface is provided between the PSTN and the Internet for telephone traffic;
10 .Figure 16 is a ~ r~m illustrating the overall operation of an ~ g~:~"~nt in which a call setup ga~e~ay is provided between the Tnt~rn~t and the PSTN;
.Figure 17 is a diagram illusLlatillg the overall operation of an arrangement inwhich a freephone service is implemented for Web users; and 15 .Figure 18 is a diagram similar to Figure 6 illustrating the provision of a distributed proces.sing ~llvir~ lent for interco"-,~.;ti-\g ~lPm~ont.c of the service control subsy~ l of the PSTN.

Best Mode of Ca,,v;~ Out the Invention Figure 6 illustrates an arr~ngem~nt for the provision of services in a PSTN
conventionally comprising an inter-~oych~nge network 13 (including trunks and switches at least some of which are SSPs 41 with associated IPs), an access network 11 CO..~ ;.-g customer permise equipment (here shown as telephones 40) to the network 2~ 13, and a service control sub~y~Lelll 42 including at least one SCP for providing services to the SSPs 41 upon request. It will be appreciated that the Figure 6 se..l;~lion of a PSTN is highly dia~ .r.

The SCP 43 may operate in a conventional ~ responding to service requests from 30 SSPs 41 to run specific service logic on particular data according to illrullnation cont~ine-l in the service request, and to send back to the requesting SSP a~ o~liate instructions for effecting call set up. A service request is gen~ated by the SSP in CA 02239408 l998-06-03 W O 97/22212 PCT/GB96/030~5 response to precleterrnin~l trigger conditions being met at a trigger check point, there being one or more such check points in the course of h~nrlling a call (it may be noted that where the trigger conditions have been downlo~lP~I to the SSP from the SCP then it could be said that the SSP is responding to an inform~ti~n request by the SCP when S cont?~cting the SCP upon the trigger conditions being met - however, in the present specifîcation, this initial co".,~ ir~tion from the SSP to the SCP will be referred to as a "service request").

The SCP 43 is also provided with a l~Lwolh access inter~ace 44 to the Internet S0 in 10 order to make use of certain service resource items 49 (also referred to below simply as "service lcsou,-;es") during the course of procecsing at least certain service requests from the SSPs 41. These service resources 49 are held as WWVV pa~es on HTTP
servers 51 (more particularly, on service resource tl~t~ es 52 of these servers 51).
The WWW pages cont~ininEg these service resources are referred to below as "phone"
15 pages. The servers 51 are connPctP~l to the Internet and the phone pages are read ~rce~ible using l~e~;Live URLs or U}~Ns (for convenienre, the more general term URI will be used h~r~ drLer to mean the TnternPt-resolvable inrlir~tor of the location of a phone page).

20 The service resources may be service logic or service data and may be used by an olhe~wise ~lalldald service logic program running on the SCP, by ~rcecsin~ the phone page of the required resource using the d~lU~ t~ URI. In certain cases, the service ~ ,soulees 49 may provide subs~ y all of the service control and data associatedwith a particular service. In this case, the service logic program ~ , in the SCP
25 43 is of skeleton form, being in~f~nti~tf-1 on receipt of a service request and then serving to initiate service resources access and to return the results of this access to the entity that made the service request. In fact, according to this approach, the SCP could be implr~nrntr-l simply as a platform for fetching and ~o~rPClltinp~ phone-page service logic and would not need to have the complex provisioning and management systems30 for such logic as is required by standard SCP platforms; SCPs could then become more ubiquitous, possibly being associated with every SSP.

Figure 7 is a flow chart illustrating the progress of events in the case where the SCP
43 h~n(11es a service request by ~rcpe~in~ a phone-page service resource. Upon receipt of a service request in an INAP m~ ge (step 100), SCP 43 decodes the TCAP/INAP
message ~llu-;Lulc~ in standard ~A~ (steps 101 and 102) well lm-l~rst~)od by pclsOlLs slcilled in the art. Next, SCP 43 in~t~nti~t~s a service logic program, SLP, to handle the request (step 103). This SLP is then responsible for looking up the URL of the required service resource as ~ e.",~ (l from information cont~inrd in the service request (steps 104, 105). For example, if the service request relates to a called-party service, then the required resource will be in~lic~te~l by the dialled number and the 10 latter will be used to derive the URL of the resource. Once the URL of the desired service resource has been ascertained, a l~s~ul~;e request (for example, in the form of an HTTP request message) is sent over the Internet to the corresponding server holding the desired service r~suulee (step 1063; a correlation ID is also passed with the resource request to enable a response from the latter to be linked with the ~lu~liale 15 S~P instance. A timer is also started (step 107).

If a response is received from the ~rce~e(l resource before the expiration of a time-out period (tested in step 108), then the response, which is usually in the form of a ~lestin~tion mllnbçr, is supplied to the a~ropliate SLP as j~1'ontifi~d using the 20 correlation IO passed with the ,~,~L,ol~e (step 109). An INAP/TCAP response mrc~ge is then ~lel.al~d and sent to the entity that made the original service request (steps 110 and 111) after which the SLP in~t~nre is terrnin~t~l (113).

If in step 108, a time-out occurs before a response is received, then a default response 25 value (generally a default destin~tion number) may be looked up in the customer record and put in an INAP/TCAP message and sent back to the requesting entity (steps 114 to 116). The SLP in~t~nre is then termin~tr~l (113).

Locatin~ & Accessin~ Service Resources 30 The functionality associated with ~cce~in~ a phone-page resource is sch~m~tir~lly s~ r~l in Figure 6 by resource access block 46. Block 46 includes URI
f1~otrrmin~tiQn block 47 for determining the URI of the phone page cont~ining the W O 97/22212 PCT/GB96/03~55 desired resource on the basis of parameters passed to block 46. Using the URI re~lrnPcl by block 47, the resource access block 46 then ~c~ o.s the phone page of the required service resource 49 over the Tnt~m~t through interface 44.

S Resource Codes - It is possible that more than one service resource is associated with a particular telephone number; in this case the resource access block 46 will need to know additional information (such as current point-in-call, pic) to enable the a~.u~liate service resource to be i~entified. If the service resources associated with a number are located on ~:lirr~ lL phone pages, then the additional illro~lnation is also 10 passed to the URI ~k~ on block 47 to enable it to return the URI of the opliate phone page. It is also possible for all the service resources associated with a number to be iocated on the same phone page. In this case, the resource access b}ock 46 uses the additional information to pass a resource-idel.liryillg parameter with its access request to the phone page conce-llcd; it is then up to the functionality associated 15 with the phone page to access the correct service lcs~ul~e.

Thus, each service resource can be considered as being i~ntifierl by a respective resûurce code 54 (see Figure 8) made up ûf a first part UI ("URI Id~ntifier") used to identify the URI at which the resource is located on the Internet, and a second part RRI
20 ("Relative Resource Identifier~) used to identify the resource arnongst plural resources at the same URI.

Resolllce Access - Where only one service resource 49 is located on a phone page 58 identified by a unique URI, then the resource code 54 sirnply comprises the UI, 25 generally either a telephone number alone or a telephone number plus a pic parameter (see Figure 9). In this case, ~rcessin~ a resource simply involves mapping the whole resource code 54 into the corresponding URI (process 55) and then senfling a request ~ 57 to the corresponding phone page 58, this latter itself CO~ ;L.. l;.,g the desired service r~suul~;e 49. The result of ~rces~in~ resource 49 is then retllrnPd in response message 30 Sg.

In contrast, where multiple service resources 49 are located on ~he sarne phone page 58 (Figure 10), the resource code 54 comprises both a UI and RRI, tne UI generally being a telephone number and the RRI a pic or other pararneter for ~ictin~.1iching between the co-located resources. In this case, al~cP~si~.g a resource involves ~ lg the UI part of the l~sou~;e code 54 into tbe corresponding URI (process 55) and then sending a request 57 to the corresponding phone page (process 56~, the request including the RRI of the resource code. The phone page 58 inr~ s functionality 64 for accessing the required resource on the basis of tne RRI in the request mPs~ge. The result of ~rcPe,cin~ the required resource 49 is then returned in response mPss,.~ge S9.
An allelllaLi~e to the Pigure 10 method of ~ccPc,cing a service resouce that is co-located with other resources on a phone page, would be to retrieve the whole page across tne Internet simply using the URI derived from the UI part of the resource code, and then to extract the desired resource on the basis of the RRI.
IJRI Del~ ;on from Resoul ce Code - The imphPmPnt~tion of the URI
dete. min~tion block 47 that performs process 55 will next be considered. Block 47 may be implemented in a variety of ways, four of which are described below:

Direct Input It would be possible, though not n~cec.s~rily convenient, to arrange for the calling party to input dil~clly the required URI. The calling party may thus input the host id component of the URI required {either in the form of a host domain name or host IP address) plus the path component of the URI. For example, in the case where the phone page of a called party is to be S~cceccecl~the calling party may input the URI of the called party and, inflçço~, this input may substitute for the normal input of a telephone number. A leading input string (for example "999") may be used tO identify the input as an URI. As regards the input means, where a user oniy has a standard 12 key telephone, input of host domain names and other URI elem~ntc requiring alpha characters, will need to be done using one of the standard techniques for alpha input from a phonepad (such techniques are already used, for example, to enable a calling , party to "spell" out the name of the called party). It would also be possible to provide users with a full alph~n--mPric keypad to facilitate URI input.

Com~uL~lion S Service resource access over the Internet could be ~ ,Ll;cLed to a set of dialled numbers from which it was possible to compute a collcsL,ollding URI; in this case, this collly-lLiilion would be the responsibility of block 47.

Association Table Lookup Probably the simplest implem.ont~tion for the block 47 is as an association table (either in memory or held on fl~t~h~ce disc store 48) associating a URI with theUI part of each resource code. A potential problem with this approach is that a service resource may be required for a called party number on the other side of the world which implies a rigorous update regime between PSTN operators worldwide in order to keep the association table up-to-date. (Note that the sameimplication is not n~fçes~rily applicable in respect of ...~-ki.~g the called-party number as one required to trigger a service request, since the number may be alTanged to be one of a group of numbers all triYgering an a~lopliate service request, in a llla~ similar to 800 numbers).
DNS-Type Lookup An ~llr.l".~i~re lookup solution is to use a hierarchically-structured distributed rl~t~h~ce system, similar to (or even part ofl the Domain Name System ~DNS) of the Internet, in order to resolve the UI part of a resource code to a corresponding URI. This approach, which will be described in more detail below, would typically involve databases m~int~inP-l by each PSTN operator for its numbers with which URIs are associated. These ~i~t~h~ces would be ~ccescihle by all PSTNs through a network such as the Tnt~rnPt with resolution requests being pointed to the a~lo~ Le ~l~t~h~ce in a manner similar to the Domain Name System. In this case, the block 47 is co~ iL~I~e~l by an a~ ial~ resolution program arranged to request UI resolution over the Internet through interface 44.

Before describing a DNS-type lookup implementation for tne URI determin~tion block 47, some further general comm~nt~ are ay~lo~liate~ Whatever method is used to de~e"~ P the URI, certain simplifir~tion~ are possible if limited eo,.~ are placed on the URIs ~",-illP~l, In particular, it is not nPcesC~ry to ~lete~ninP all components of an URI in the following cases:
(i) A part of the URI path component can be made :j~ld~-l for all serviceresources, this standard part being simply added by the block 47 once the rest of the URI has been ~le~ "" j"Prl For example, where a roaming number is to be looked up, it may by collvelllion always be held in a file "roam" in a sub~ LcLol~ "tel" of asubscriber'sdirectoryonaparticularserver. Inthiscase the URI host component and the subscriber-unique part of the path component are first det~llllhled and then the rem~;nin~ path part "/tel/roam" is added.
(ii) The URI path component can be a~lallged to be the same as a pre~ptp7~ninp~
part of the l~suulce code, the block 47 nPe~lin~ only to determinP the host component and then add the path. For example, it may be agreed that the path must always end with the telPphonP nUlll~e~ col~re~--P~, or suf~lcient o~ the terrnin~tin~ digits to have a high probability of uniqueness on the host m~rhin~.
The path may also include standard CU~ O1~C11l~. to be added by block 47.
(iii) Blocks of telephone numbers may have their collc:~o.lding service resources located on the same host server so that it is only npce~s~ry to use a part of the telephone number to d~Lti- ~ P the host component of the URI; in this case, the path component can conveniently include all or part of each telephone number.
This situation implies a tight degree of control by the telephone operators and does not offer the telephone user the freedom to choose the host server on w'nich user places their phone pa~e.

Another general point worthy of nûte is that however the URI is ~ietPrminP~l~ the host component of the URI may be provided either in the form of a host ~lom~in name or a host IP address. Where the host is i-lPntifilpd by a domain name, then a further 30 resolution of URI host name to IP address wiIl subse(luer~tly be carried out in standard by interface 44 using the Domain Name System of the Tntern~t This further resolution can be avoided if the host identity is directly provided as an IP address.

Where a ~l~t~k~ce lookup is used to provide the number to URI translation, this tl~t~h~e may be independent of, or combined with, a customer rl~t~h~e cont~iningother ~;u~.lomer-related information. Factors affecting this choice include, on the one hand, the possible desirability of having the number-to-URI tr;tn~l~tion i~lrv~ tion widely available, and on the other hand, the possible desirability of restricting access to other c~l~tom~or-related info~nation.

DNS-Type IJRI LOOKUP
A DNS-type lookup implementation for the URI ~letermin,.tinn block 47 will now be described in some detail for the case where the UI part of the l~s~ ce code is atelephone number and there are no con~tr~int~ on the URI, thereby requiring both the full host and path components of the URI to be retllrn.o~i by the lookup. A key part of the overall process is the formation of the equivalent of a host domain name from the telephone number-of interest; this ~iom~in-name equivalent is then resolved into a corresponding URI by a lookup mPr~h~ ,., which in the present example is irl~ntir~l to that employed by the DNS (indeed, the lookup m~eh~ni~m may be incorporated into the DNS though it can also be independently implemented).

The nature of the DNS has already been described above with reference to Figure 3 when the terrn "DNS-type" system was also introduced. For coll\/e~,ie"~e in the following a DNS-type system or~ni~e-1 to provide a telephone number to URI
translation facility will be referred to as a "Duris" system (5t~n~1ing for "DNS-type URI
Server" system).

The basic principles surrounding operation of a Duris system are:
- every telephone mlmher can be turned into a host ~lom~in name (tne name space cont~ining such host domain names for the telephone numbers of interest is referred to below as the "telname space"); and - for every host domain name in the host ~lQIn~in space there is a Rt?gi~tr~7tion Record held by the Duris system cont~intn~ the corresponding URI.
Thus, an input te~ephone number forming, in the present case, the UI part of a resource code 54 (see Figure 11), is first parsed to form a ~om,.in name (step 120) and , W O 97/22212 PCT/GB96/~3055 28 then passed to the Duris system (illu~.LIalt;d in~Figure 11 as formed by the DNS itsel~
to retrieve the RR with the corresponding URI (step 121). Following on from the URI
lookup, if the URI ret1~rn~d has its host co~ o~ L as a domain name, the DNS is next used to derive the host IP address (step 122); this step is, of course not needed if the 5 host component is stored as an IP address in the l~R. The URI is then used to make a resource request to the a~lupliate server, passing any RRI part of the resource code 54 (step 123).

There are a number of possibilities at the top level as to how a Duris system could be 10 implem~ntlocl (a) Independent of the DNS. In this option, the telname space co..~ s the entirename space to be managed with the root of the telname space being the name space root (see Figure 12A where the telname space is shown h~t~h~
In this case, the Duris system is independent of the DNS itself. The Duris system could, of course, use the same basic infrastructure as the DNS (that is, the Internet) or an entirely sepa~ dte ~Lwolk. Where the telname space conlplises all the domain names colle-.~ollding to all public telephone numbers worldwide, pal..illg a full hlL~ inn~l telephone number would give a fully ifie~l domain name. Of course, the teln~me space could be a much smaller set of names such as those derived from int~rn~l extension numbers within a company having worldwide operations.
(b) Unfr~r.~P~IPd Telname Space withinthe DNS. Inthis option, the telname space is a domain of the DNS name space and the Duris system is provided by the DNS itself. Thus, where tne te}name space cc,mplises all domain names derived 2~ from public telephone numbers worldwide, the teln~mlo space could be placed within the dom~in of the ITU, in a special subdomain "tel", the root of the teln~mP space then being "tel.itu.int. " (see Figure 12B where again, the h~teh.o(l area ~lesellls the telname space). The responsability for ~rlmini~tl~ring the in ~tel.itu.int." would then lie with the ITU. With this latter example, to form a fully qll~lified domain name from an input telephone number, after the number has been parsed to form the part of the domain name corresponding to the structuring within the telname space, the tail "tel.itu.int." is added. The fully ~l~lifi~ domain name is then applied to the DNS and the corresponding RR record, holding the required URI, is retrieved. As a further example, the telname space could be all ~me derived from int~ i ç~ten~inn numbers within Hewlett-Packard in which case the root of the teln~me space would be "tel.hp.com. " and Hewlett-Packard would be entirely responsible for m~n~ging this domain.
(c) Fragmented Telname Space within the DNS. In this option, the t~ln~m~ space is split between multiple domains of the DNS name space and the Duris system is provided by the DNS itself. Thus where the telname space colllplises all ~lom~in narnes derived from public telephone numbers worldwide, the telname space could be split between respective "tel" subdomains of each country domain; thus, as illustrated in Figure 12C, the part of the telname space corresponding to French telephone numbers would have a root of "tel.fr. " and the part of the te1n~m~ space corresponding to UK telephone numbers would have a root of "tel.uk. ". The responsability for ~lmini~tering each "tel"
subrlom~in would then lie with each country. W;th this latter example, to form a fully qu~lifi~tl domain name from an input telephone number, the part of the telephone number following the cou~ y code is parsed to form the part of the domain name within a country 'tel' subdomain and then a host domain name tail is added a~p~ iate for the country concerned. Thus for a French telephone number, the "33" country code is stripped from the number prior to parsing and used to add a tail of "tel.fr. ". The tail ap~ liate to each country can be stored in a local lookup table. As a further example, two commercial org~ni~tions ~X
coln~ally and Y co~ ally) with respective DNS domains of "xco.com." and "yco.com. " may agree to operate a common Duris system with a telnarne space split between "tel.xco.com. " and "tel.yco.com" . In this case, any Y company telephone number input from X eolllpally will be parsed to a fully q~l~lified ~ domain name terrnin~t;ng "tel.yco.com." and vice versa.

30 Consideration will next be given to the parsing of a telephone number into a domain name - in other words, where to insert the " . " characters into the number to provide the structuring of a domain name. Of course, as already explained, telephone numbers are hierarchically structured according to each country's numbering plan. Thus one approach would be to follow this m~mhering plan structuring in dividing up a telephone number to form a domain name. By way of exarnple, the telephone number "441447456987" which is a UK lw~nl)el (country code "44"~ with a four digit areaS code ("1447") and six digit local nnmher ("456987") could be divided to form adomain name of 456987.1447.44 (note that the reversal of label order occ~sioned by the fact that the DNS labels are ~ ngPd least signific~nt first). If the t~ln~mr space is a subdomain of the DNS with a pl~Pm~nt as illustrated in Figure 12B, the fully q~ ifie-l domain name derived from the telephone llulllber would be:
4~6987.1447.44.tel.itu.int.

There are however, ~iifflcl-lti~os inherent with trying to match the numbering plan hierarchy when parsing a telephone number into a host name. Firstly, in order to parse an international number correctly, it would be . ,Pce,ss~ for each entity tasked with this 15 operation to know the structuring of each country's numbering plan and where, as in the UK, area codes may be of differing length the required knowledge may need totake the form of a lookup table. Whilst this is not a complicated computational task, it is a major ~minietrative nllie~nre as it means tnat each country will need to inform all others about its numbering plan and any updates. The second problem is that a six 20 or seven digit local number is a very large ~ln/m~in; it would be preferable to create subdomains for ~e.rOl ~ nre and scaling reasons but there is no ohvious way of doing this.

These problems can be overcome by giving up the lcs~ ;Lion that the parsing of 25 telephone number into a domain name should match the structuring of national numbering plans. In fact, there is no strong reason to follow such a srhrme as DNS
servers know nothing about the mr~ning of the narne space. It is therefore possible to parse telephone numbers using a deLel.. i~tic algoli~ l taking, for example, 4 digits at a tirne to lirnit the size of each subdomain and m~king it possible to 'insert the dots' 30 without knowing the numbering plan conrern~ So long as the DNS domains arld zones served by the DNS servers are created correctly it will all work.

CA 02239408 l998-06-03 For intt?m~tinnal numbers it would still seem a~lo~,iate to separate off the country codes and so a hybrid parsing scheme would be to parse the initial part of a dialled number according to known country codes and thereafter use a ~et~rlT ini.ctir scheme (for example 3,7 or 4,6 or 3,3,4) to se~al~Le the digits. Of course, if a fr~mPnt.o~
5 telname space is being used as illustra~ed in Figure UC then the country code is used to look up the host name tail and it is only the national part of the number which would be parsed.

Finally, as regards the details of how a DNS server can be set up to hold RR records 10 with URIs, reference can be made, for example, to "DNS and BIND", Paul Albitz and Criket Liu, O'Reilly & Associates, 1992 which describes how to set up a DNS server using the Unix BIND implem~nt~tion. The type of the RR records is, for example, text.

15 It should be noted that DNS labels should not in theory start with a digit. If this convention is ret~in~d, then it is of course a trivial exercise when parsing a telephone mlTnher to insert a standard character as the filrst character of each label. Thus, a 4 digit label of 2826 would become "t2826" where "t" is used as the standard starting character.
It will be ~ple.,iated that as with domain names, where an input telephone number is not the full number (for example, a local call does not require any international or area code prefix), it would be parsed into a ~loln~in name in the local domain.

25 The foregoing ~ clls~ion of Duris system implementation, has been in terms oftr~ncl~tin~ a telephone number into an URI where the telephone number forms the full UI of a resource code and the Duris system returns a full URI. It will be appreciated ~ that the described Duris implementation can be readily adapted to accommodate the various mo~lifi~tion ~ c~ efl above regarding the form of the UI and what parts of 30 the IJRI need to be looked up. For example, where there are a number of dirrele~
service resources associated with a subscriber each in its own ~lle and the required source is i~l~ntifiecl by a pic part of the resource code, then the input telephone number will be used to look up, not the full URI, but the host co~ 3oll~nL and that part of the path component up to the relevant subdilc~-Loly~ the pic part of the UI then being appended to identify the required resource file.

S For small local Duris implem~Jlt~tions, it may be possible to have a single server; the implemeIlt~tion should still, however, be considered as of a DNS type provided the otner relevant feaLul~3 are present.

lO Nature of Service Resources Turning now to a consideration of t'ne service lc;soull;es 49, how these serviceresources can be provisioned onto tne servers 51 will be described more fully below but, by way of present example, the service resource or resources associated with a particular PSTN user (individual or org~ni~tion, whether a calling or called party) can 15 be placed on a server 51 over the I"Lc:ll,et from a user L~ al 53 in one or more WWW pages.

Consider the simple case where the service resource is a service data item such as a telephone number (for example, an alt~rn~tive number to be tried if the user's 20 telephone corresponding to the number dialled by a calling party is busy). This diversion number could be made the sole service resource of a phone page of the user.
The phone page URI could be a URL with scheme set to HTTP in which case the GET
method could be used to retrieve the diversion number. Such an d~ e",ent is suitable if the phone page is only to be used for funrtion~l retrieval of the diversion number.
25 However, if the diversion number is to be visually pre~ontPcl at a user ~ 53, then it may be desirable to accoln~dlly the number with explanaLoly lllal~lial (this will often not be n~ceSs~ry as t'ne diversion number can be arranged to be returned into ane~tin~ displayed page that already provides context information). However, where tne phone page does include explanatory material as well as the diversion number, an30 entity only wisl~ to make functional use of the phone page, could be alldn~ed to retrieve the phone page and then extract the diversion number (this would, of course, W O 97/22212 PCT/GB9~ WC55 require a standard way of idellLiryhlg the il~O~ tion to be P~rtr~r~1 from the phone page).

An ~lt~rn~tive and ~lcrt:lled arrangement for providing for both viewing and functional 5 access to a resource req~iring explanatoly material for viewing, is to use an object-oriented approach to resource design. In this case, the l~i,oul.;e object would have two different access methods associated with it, one for purely fimctional use of t~he resource and the other enabling viewing of associated explandLoly material. It would then be up to the ~rceC~ entity to access the resource object using the ~p 10 object method.

Yet another arrangement for providing for both viewing and functional use of thediversion number, would be to provide s-,~al~Le resources a~ro~liately con~lgured for each use, each resource having its own resource code (generally, both such resources 15 would be placed on the same phone page and in this case the UI part of each resource code would be the sarne).

Retrieval of a phone page for use by a human user will generally not be as time critical as retrieval for operational use by a PSTN. Thus, while for human use the scheme20 specified in the URL of a service resource could be HTTP, it may be advantageous for operational use tO define a special "phone" scheme (access protocol) which wouldresult in the server 51 using an optimised access routine to access the required resource (diversion number, in the current example) and respond to the ~rce~in~ entity in the lilllllln possible time.
Resi-lPs data items, other possible types of service resource include service logic for execution in place (at the server) with the result of this execution being ret lrnP~I to the entity ~ccessing the resource; service logic downloadable from the server to theaccessing entity for execution at that entity; and a logging resource for loggirlg 30 information passed to it by the ~rce~in~ entity (or simply for logging the fact that is has been ~rcesse~). It will be appreciated that the logging resource is really just a particular case of service logic executable in place.

_ By way of example, a service lcsoul-;e co..~ l by execute-in-place service logic can be arranged to irnplement time-of-day routing, the result of exec~ltin~ the senice logic being the telephone number to which a call should be routed taking account of the time of day at the called party's location. An example of a service l~suùl~;e co-,~ d by 5 downloadable service logic is service logic for controlling calling-party option interrogation using the facilities provided by an IP. As regards the logging l~s~ul~;e, this can be used for recording the number of calls placed to a particular ~ lbel.

Where each resource has its own phone page and the resource is ~l~,S~ L only in its 10 unembellished filnrtion~l forrn, then the HTTP scheme can be employed for access using the GET method for both the downloadable service logic and the execution-in-place service logic, and the POST method for the logging l~:suul-;e. If it is desired to provide an explanaLoly material with each service resource, then any of the solutions tli~Cll~Sefl above in relation to data items, can be used.
Where more than one service resource is to be associated with a number, then each such lcsuulce can be placed on a respective phone page with its own URI. However, the ~c~l~cd approach is to place all such service resources on the sarne page and use the RRI part of the corresponding lcs~ul~;e codes to enable access to the ~pl~liate 20 l~,soul~;e. The arcec~ed les~,ulce is then treated according to its form (executed if execute-in-place service logic, leiul~led if downloadable service data or logic).

Thus if both a diversion-number service-data resource and a time-of-day execution-in-place service-logic resource are placed on the same phone page, the diversion-number 25 resource code might have an RRI of "1" whilst the time-of day resource code might have an RRI value of "2".

Where calling/called party options are to be included in a service resource for ~lese~ iQn to such party, then as already in~lir~t~ this can conveniently be done by 30 Cn~ the service resource as downloadable service logic with the chosen option possibly initi~ting request for a follow-up service ~c;s~u-~;e.

W O 97/22212 PCT/~k5G~30~5 It will be ap~.~iaLed that a service resource will often be of a complex type, COll~b~l~ , service data and/or downloadable service logic and/or eYecute- in place service logic. A particularly pow~.rul combination is the con,binaLion of the two types of service logic where the downlo~ hl~ service logic is ~P~ignPA to inter~t with~ S eYe~ute-in-place service logic; using this arr~ngç~nent the user can be presented with complex client-server type appli~tion~

)le U~e of Service Resou-~e Figure 13 il11-~t~t~.s the operation of a service making use of a l~so~ e on a server 51. This service is equivalent to a "~ onal number" service by which a user can be a~c~eA Il~ ugh a single, Im~h~nging n~ htor even when moving between telephones having different real numbers. To achieve this, the user requiring this service (user B
in the current exarnple~ is ~llo~t~ a unique lJtl~Onal number (here referred to as the "Webtel" number of B) from a set of numbers all of which have the same leading number string to enable an SSP to readily identify a dialled number as a Webtel .,-...lbel. User B has a service ~soulce 49 on a derlic~t~ci phone page on ~TrP server 51, this phone page being located at a URL here i(içntifi~d as "URL (B phone page)".
B's phone page when ~rcç~sP~ returns the current roaming number (" B-telNb") where B can be re~'n~o~i. In the simplest case, B's phone page is just a single number that can 20 be motlifie~ by B (for example, from a terminal 53) as B moves to a different phone.
More likely is that B's phone page is an execute-in-place service logic providing time of day routing.

In the present eY~mple, the association l~lw~" B's Webtel nllmhçr and the UR~ of25 B's phone page is stored in an ~o~i~tinn table ~cçs~ihle to SCP 43.

Upon a user A s~ ng to contact user B by rli~lling the Webtel number of B, the t~lephollP 40 being used by A passes a call set up request to SSP 41 (note that in Figure 13 the bearer paths through the telephony network are shown by the thicker 30 lines 60, the other heavy lines in~ ting ~ign~lling flows). SSP 41 detects the dialled n--mh~r as a Webtel number and sends a service request to SCP 43 together with B's Webtel n-lmb~s. SCP 43 on receiving this service request initi~t~os a service logic PCT~GB96/03055 program for controlling tr~n~l~tiQ~ of B's Webtel number into a current roaming number for B; in fact, in the ~l~sellL case, this p~o~,~alll simply requests the resource access block 46 to access the service resource ifl~ontifiec~ by B's Webtel number, (that is, B's phone page 49) and return the result of this access. To this end, block 46 first S tr~n~l~tes B's Webtel number into the URL of B's phone page and then uses this URL
to access B's phone page over the ~ klllP~ ~for example, using the 'phone' scheme already referred to with a method corresponding to the HTTP GET method). This results in B's current ro~ming number B-telNb being passed back to block 46 and in due course this number is l'GLI I ~ I ~r~l to the SSP 41 which then i ~ s completion of call 10 set up to the telephone 40 corresponding to B-telNb.

The Figure 13 example related to a called-party service; it will, of course, be appreciated that the principle of ~ccPssing service resources over the Internet can be applied to all types of services, ;nr~ ing both calling-party and called-party services 15 and hybrids. Thus, ~ dal~ 800 number services can be impl~ntontPrl with the dialled 800 number reslllting in access to a phone page resource cO"~Iill,lrd by ~~YPc--t~-in-place service logic that returns the niost ~o~liate number for controlling onward callrouting.

20 It will be a~ cialt:d that although in the Figure 13 example the service request from the SSP was triggered by a leading number string of a dialled number, a service request may be triggered by a variety of triggers inrlllrling calling-party number.
called-party number, or some other user input, such triggers being possibly qll~by call setup progress (for example, called-party number ~ ifi~d by a busy status or 25 by ringing for more than a certain time).

With respect to the logging service resource mentioned above, one possible application for such a l~,suul.:e is in telephone voting. In this case, ~ lling the voting number causes the SSP picking up the call to pass a service request to SCP 43 which then 30 contacts the ~plo~liate logging resource over the Internet to re~ a vote after which the call is termin~t~cl To minimi.~e bottlenecks, a logging resource could be provided at a different URL for each SCP, it being a simple matter to collect and collate voting from all these logging resources over the Tnr~rnPt If an SCP with Tn~rn~t access is provided at every SSP, then the risk of congestion is greatly re~llre~l As already noted, a user's phone page may hold multiple service resources in which S case the access request from the ~ccPccing SCP needs to contain an a~lo~lia~e RRI
identifying the required resource.

In the event that an SCP is to provide both a traditional IN service to some users and an equivalent service using an Internet-arc~cce(l service resource to other users, then 10 a lookup table may need to be provided in the SCP to ensure that a service request is a~l,rul,riately handled; such a lookup table can conveniently be combined with the customer record ~l~t~h~.c~.

Once a user, such as user B, has set up one or more phone pages specifying his desired 15 service resources (particularly service logic defining ~ ollalised services), it is clearly logical for user B to want any PSTN o~el~Lol he cares to use, to access and utilise such service resources. This is possible if the Webtel-to-URI fi~t~h~ces are available to all operators. Thus multiple operators could be set to access B's phone page or pages. If an operator declines to use B's phone pages, B can obviously chose not to use 20 that operator (at least where that operator provides a long haul carrier service subject to user selection). The possibility therefore arises that service provision will cease to comm~n~l a premium from operators, but that the provision of phone-page ~tilic~tion by an operator will become a nPcecs~ry basic feature of PSTN operation.

25 Provisionin~ and Updatin Service Resources Consideration will next be given as to how the service resources 49 are provisioned to the servers 51 and subsequently updated.

So far as provisioning is concerned, n,vo basic actions are required: firstly, the service 30 resource must be placed on a server 51 and, secondly, the URI of the service resource must be notified to the PSTN operator along with the trigger conditions (number plus any other condition such as point in call3 calling for access to the resource; if multiple , W O 97n2212 ~ ; ~ 95'~3055 r.,SOul~5 are ~)~ovidcd at the same URI, then the RRI values needed to l~lLicve the a~lol.,idt~, ~. soulce for a particular trigger Cc~ ;Oll~ must also be ~
uotir; ~ n p~vC~ will be ~f,~ to ~L~ larl~ as '~ ,' the sen~ice .cs~ ce ~vith the PSTN G~C~atCn, r.~ - is, of Course"l~rc ~ to ellablc the ~Soe -l inn 5 tables used by SCP 43 to be set up and for trigger co.~ ;. nc to be set in SSPs 43. For certain ~c~vic~s. such as that ~Ir~ A above with ~r~,~e to Figure 13, it is not the user th~t s~lrpli~s the 1. ;~ n lmher (the Webtel ....- ..k~, in the Figure 13 eY~mp~e);
in.ct~ ~e PSTN Opl -d~ oc;1t~; arl ~ u~}~dk~ to the user as part of the dli~n ~uC~-As to the ~ucess of placill~; a service l~o-u~ on a server 51, how this is carried out will depend on the ~ c1~ of the PSIN C~ to the possible effects of such service LeSuul~;eS on o~ ~I;---, of the PSTN. Where the service L.,Suul.~ sm~b returns a data item tO an ~c~s~ entity, then an O~atlJ~ may not be too cc,..~ A about possiblc 15 errors (~r~ ent~i or Acl~"t~ ) in ~ " the service ~.,uu~. Ho er, the O~ a~ul will probably be much more c~ about the proper o~ of any service logic that may be ~ --PA by a l~ul~; i~ a~ ~)f 1~ may not permit such a service ..,.,u.u~.

20 ~ for ~che ...~ that an o~lall,l has no co..~.,..c about the nah~re or imple~nt~fion of service r~ Jul~s, then how a l~soulcc IS placed on â server 51 will largely A~penA on the nature of the server CQ~'e~ For e~-...ple, if a user has a co..~ t~, with ~lwOIh access to the Tnt~ t and this co,..~ . is used as server 51, then the user can simply lOâd a desired l~Cu~,e onto the server as a WWW phone ~5 page for e~ l access. A similar .~ ;on arises if the server is ~n ol~n;.~t;o ~W
server to which the 4~ has access over an int~rn~l LAN. I.n. ~oth these latter cases, lo~Ain the ~CSuu~CC as a WWW phone page does not itself re~luire TntPrn~t access.
Ho~.~.,.,., if the server ~1 is ûne run by an e~te~ nt~t service ~lovider, then a user can ~ e to downlûad the l~lUil~li service l~,sOul~,c into the user's allocated 30 Web site space on the server; ~his may or may not involve Tnt~rn~t access. One special case of this latter sce~ is where the PSTN Ope~a~ plo~ides a special server for user phone pages cont~inin~ service l~suul~,es.

A~'~;Ei~t'DEE~ SitE~

W O 97/22212 PCT/~B96/03055 39 Except where a user's own co~ u~r acts as server 51, placing a service resource on a server will generally involve cle~ring one or more levels of password protection.

As regards the origin of the service resource loaded by a user onto server 51, this may 5 be generated by the user or, particularly where the resource includes service logic, may be provided by a third party (inr~ np: the PSTN operator).

If the PSTN operator wishes to have control over the service resources 49 to avoid any adverse effects on operation of the PSTN, two approaches are possible. Firstly, the 10 operator could require that every resource (or, possibly, a particular subset) had to be subject to a verification process before use, a~lo~liate measures then being taken to avoid subsequent alteration of the resource by the user (except, possibly, for particular data items); in this respect, the operator could re~uire that the resource be placed on a server under the operator's control and to which the user had no write access (except 15 possibly for altering particular data items, as in~ t~-l above). A second, more attractive, approach to minimi~ing adverse effects by the service l~suu.~;es 49, is for the o~el~tor to provide standard service resources to which a user could add the user's own data (and possibly make limited functional selections in case where the resource included service logic); the c~ctomi~e~ resource would then be loaded onto a server ~l 20 controlled by the operator. This process can be conveniently implemented for a particular resource using an ~ITML "form" which a user could download over the WWW from the operator-controlled server. After completing the form and activating a 'commit' graphical button of the fo~n, the entered hlrollllation would be 'posted' back to the server where the hlrullllation would be used to produce a customised25 service resource thereafter placed on the server for access over the Internet. An advantage of this approach is that registration of the service resource with the Op~,~dlUl is ~imlllt~nP~Qusly effected. (It may be noted that if registration needs to be done as a separate act from having a service resource loaded on a server, then using an HTML
form is a very convenient way to implement the registration process).
3û
From the foregoing it can be seen that whilst the provisioning process does not n~cec~rily require information to be passed over the Internet, in many cases this will W O 97~2212 be the best solutio~, particularly if an HTML form e~rh~n~çcl over the WWW can be used to produce a customised service resource. It should be noted that producing a customised service resource using an HTML form is not limited to cases where thePSTN operator controls the server.
As regards updating service resources, there is likely to be a need to update certain data items on a fairly frequent basis (for example, roaming number). Where the PSTN
operator does not place any controls on the service resources 49, then update is a relatively simple matter, only requiring write access to the server con~ern~d (as already 10 infiir~ter1~ this will generally involve one or more levels of password protection).
However, where the PSTN operator exercises control over the service lcsuul~;es, for example by only ~e, ~ lolllie~tione of standard service resources, such c l~tomi.~e~l resources being loaded on servers controlled by the operator), then write access to the service resource may be tightly controlled. Again, an HTML forrn may 15 conveniently be used as the medium for modifying a data item in such cases; to the operator, this has the benefit of limiting the modi~lcations possible whilst to the user, a form interface should provide a simple route to resource morlifir~tion.

For more complex: updates, it may be n~cess~. ~/ to go through a process similar to that ~0 required for initial provisioning.

Particularly where the service resources are held on a server 51 controlled by the PSTN operator, resource update will generally involve co,-"."~"i~ )n over the Tnter~l~t Web User Interaction Consideration will next be given to other possible uses of the service resources held in phone pages on the servers 51. For example, if user B's phone page contains adiversion number, then provided this phone page is read-~cceeeihle over the Internet 30 from user A's termin~t 53, user A can use a graphical Web browser running on 53 to view B's phone page and discover B's diversion nurnber. As earlier ~lieClleserl~ the diversion number may be passed to user A for display in an existing -W O 97t22212 PCT/GB96/03055 41 visual context giving m~nin~ to the number, or may be passed to user A with accol~allyhlg explanatory text.

A more useful example is a current roaming number service for user B. Suppose B's S phone page 49 on server 51 (see Figure 14) is operative when ;ltcçc~e-l to return a current roaming number where B can be re~ch~d. Further suppose that user B has aWeb site with several Web pages written in HTML and each page contains a gr~I~hir~l 'phone' button which when activated uses the G}~T m~thorl to access B's phone page by its URL. Now if user A whilst bl~w~ g (arrow 66) B's Web site over the WWW
10 from user A's l~ l 53, ~~eei~l~s that he would like to call user B to discuss some item of interest, user A simply acLiv~tes the phone button 65 on the ~;u~ ly viewed page of B. This causes B's phone page to be ~ccesse~l using the HTTP request "GET
URL (B Phone Page)" - see arrow 67.

15 B's current l~u~lll)el- to be called is then ~le~. "~;"~-rl and passed to user A's terminal 53 (see arrow 68) where it is displayed. An explanaloly text conce~ llg the number will generally also be displayed; for example the text "Please call me at the following number:" could be displayed, this text being provided either by the ~ITML scriptassociated with the phone button, or from the phone page when lc~ ..i.tg the current 20 number. In fact, it would probably be more helpful to provide user A, not only with the current number for re~hing user B, but also with all numbers where B could be reached together with the times when B was most likely to be at each number. Since this extra il~o....i~l;nn is likely to be subject to fre~uent change, the only sensible way to provide the hlr~ ion is from the phone page. Thus, B's phone page not only 25 provides the current number for re~rhing B, but also a text that includes numbers and times subject to change; scripting B's phone page is, of course, done in a way that ensures that variable data need only be altered in one place.

In a further example, B's phone page might include downloadable service logic for 3() execution at user A's terminal. This is useful where choices are to be present-?~l to a user, each choice producing a follow-up action such as fet~hing a further phone page.
For example, the first-accesse~l phone page may be a family phone page giving the general telephone number for a family but also giving the user the possibility of selecting further phone h~ru.-~ on on each family member, such as a time-of-day dependent number; in this case, each family member has their own follow-up phonepage.

In the above scenarios, user A has been prese~t~l with a number to call over thePSTN. User A can now pick up his standard telephone and dial the number given. In fact, a compiication arises if A only has Tnt~ t access via a SLIP/PPP connection over an ordinary, non-ISDN, PSTN line since, in this case, A's telephone line is10 already tied up with m~kin~ Tntorn~t access when gatew~y 90 seeks to set up a call to A's telephone; with an ISDN connection, as two channels are available, this problem does not arise. One way of overcoming this problem would be to have user A's termin~l 53, after obtaining the llullll,c~ to call from B's phone page, ~l~tnm~tir~lly suspend its Tnternlot session by storing any required state hlr)lllld~ion (for example, 15 current WWW IJRL being ~cce~ssed) and then L. ..lli~ P its SLIP/PPP connection to thereby free up the telephone line. A can then telephc-n~ B. At the end of this call, A
can resume the suspended Tnternt?t session, using the stored state hlro~ inn to return to the point where A left off to call B. An ~ Ativc: approach is to operate a suitable multiplexing modulation scheme on the telephone line to A allowing voice and data to 20 be siml-lt~nt~ously carried. A number of such srhe~nes already exist. The PSTN would then need to separate the combined data and voice sLl~allls coming from A at some point and pass each to its a~plo~.iale ~Pstin~tion (the Tnt~ornPt data being forwarded to the ISP providing the SLIP/PPP conn~ction for user A and the voice stream being passed to B); of course, data and voice traffic in the reverse direction would also need 2~ combining at some point for sen-lin~ over the last leg to A's t~

Rather than A m~ml~lly ~i~lling 13 using a standard telephone, another possibility is that user A's te~rnin~l is provided with functionality enabling A to make a call over the PSTN from his terrninal; this functionality generally coll~plises a hardware interface 30 70 (Figure 14) to a telephone line and phone driver software 71 for driving the interface 70 in response to input from application sor~wdl~ such as the Web browser 73. A could call up his phone sor~w~l~ and enter the required number or, preferably, , A need only "select" on screen the ~ llbel retllrn~ from B's phone page and then pass it into A's phone sorLw~l~. Tn-1eerl, provided user B knew the sOr~w~l~ interface to the software 71 providing ~ llin~ functionality on A's l~ l, it would be possibie for B's phone page to return to A's t~ .ni..Al program code for ~lt~-m~tir~lly fii~lling B's S number upon A cnl~li-..~i--~ that he wishes to proceed with call pl~rPme~t As an alternative to placing a voice call, if A's 1~ . .llil.~l is equiped with a suitable modem and controlling sor~wal~, A could, in~te~rl, elect to send a fax or data to B through the PSTN either to B's ordinary number or to one specified in B's phone page as the number to be used for such ~ i.c~ions. Of course, placing a call from A's L~. ",i~
10 over the PSTN may be subiect to the problem already rlicc~c~ecl of conflict for use of the telephone line where this is not an ISDN line and A gains rntrrnrt access via a SLIP/PPP connection.

However the call is placed, if B's telephone corresponding to the number tried by A
15 is busy, a number of possibilities exist. Thus if B has a phone page that specifies a diversion number, and B has le2~ ed this service resource with the PSTN, then the diversion number should be autom~tic~lly tried by the PSTN. However, if the diversion number resource has not been registered with the PSTN. a busy signal will reL~
to A. Where A has placed the call through a standard tel~phone, A must now decide 20 how to proceed and A may elect either to give up or to refer again to B's phone page to look up the diversion number and redial using this number. If A placed the original call using his trrmin~l ~3 then the latter can be programmed to detect the return of a busy signal and then autom~tir~lly look up B's diversion number and redial using this number. This functionality can be included in service logic downlo~-ie-l from B's phone 25 page and run on A's termin~h If A had to l~,."i~ his Internet session in order to free up the telephone line for voice use, then l~Ç~"ill~ back to B's phone page requires a new Internet session to be started (in fact, this inconvenienre could be avoided if B's diversion number were 30 passed to A' s te.l,linal at the time the original number to be dialled for B was supplied).

The service resource ~crPs~ed on B's phone page upon B's tel~phone being busy may, of course, be more complex than just a diversion nnmher. In particular, user A may be ~lese~ with a range of options inr~ n~ for example, B's fax or voice mailbox number, the selection of an option po~ .lially in;ti~ting the lu~ in~ of &~ lia S ~cces~in~ so~Lwal~. Another possible option would be for A to leave B a call back mPs~ge using a form downloaded from B's phone page upon this option being chosen;
the completed form would be posted back to server 51 and logged for B to check in due course.

Of course, it may arise that user A wishes to access B's phone page to find out, for example, B's current roaming number, but user A does not know the URI of B's Website and only has B's Webtel number. A could just call B through the PSTN in which case the translation of B's Webtel number to lO~lillg number would be ~nt~m~ti~lly 15 effected (~nming B is still le~is~d for this service); however, A may not wish to call B str~i~ht away, but just note his current roaming number. In order to solve A's problem, the Webtel-to-URI association tables previously described are preferably made acc~ssi'ole on the TnternPt at a known address (for example, at a known Website). All that A need now do is to access this Web site passing B's Webtel number;
20 B's phone page URI will then be retllrnP~l to A who can then use it to access B's phone page. This process can, of course be made ~IlLc~ lic from the point when A sends B's Webtel number to the association-table Web site.

25 Internet/PSTN Call Interface In the Figure 14 scenario, A's access to the PSTN was through a standard telephon interface even though the actual form of A's tclephol~ differed from standard bSr being integrated into A's co~ uLel termin~l 53. Figure 15 illustrates a situation where A, after being supplied with B's current roaming number as in the Figure 14 case, calls 30 B via a route that starts out over the Tnt~rn~t and then passes through a user network interface 80 into the PSTN. Tnt~ ce 80 is alldnged to convert between ISDN-type telephone .sis~n~lling on the PSTN and corresponding ~ign~lling in~ir~tions carried across the Interne~ in IP packets; in addition, interface 80 ll~r~. j voice data from IP
packets onto trunk 60 and vice versa.

Thus, upon A initi~ting a call to B, rntPrnPt phone sofLw~l~ 81 in A's ~ l sends 5 call initiation ~i~n~ll;ng over the Tnttorn~t to interface 80, the address of which is already known to A's l~ ....i.-~l At interface 80, the .c;gn~llin~ is collve.led into ISDN-type ~ign~lling and passed to SSP 41. Call set up then proceeds in the norrnal way and return sign~lling is ~ldl~r~ d back through interface 80, over the Tntçrn~t, to the soîLw~c 81 in A's l~l.ll;l~AI This software passes call setup progress h~o,lnation to 10 the WWW l)lu~er 73 for display to A. Upon the call becoming established, A can talk to B through his telephone and A's voice input is ffrst rligiticecl in phone hardware interface 83 and then inserted into IP pacl~ets by software 81 to traverse the Internet to interface 80 (see arrow 84); voice traffic from B follows the reverse path.

lS IN services can be provided to this call by SCP in response to a service request from an SSP 41. Thus, if B's phone is busy, and B is registered for call diversion, SCP 43 on receiving a service request will access B's ap~lop.iale phone page for call diversion and retrieve the diversion number. If SSP 41 is not set to initiate a service request on B's telephone being busy, the busy in~ic~tion is retl-rnP~I to A's t~ ....i..~l where it can 20 be h~nfll~o-l in the l~la~ r already described with reference to Figure 14.

In fact, interface 80 can be provided with functionality similar to an SSP to set trigger conditions and ~l~ldte a service request to SCP 43 on these conditions being s~ti~le~

25 Third-Partv Call Setup Gatewa~
Figure 16 illustrates a further arrangement by which A can call B after receiving B's current roaming number. In this case, a third-party call set-up gateway 90 is provided that interfaces both with the Internet 50 and with an SSP 41. Conveniently, gaLew~y 90 can be co-located with SCP 43 (though this is not e~nti~l). Gateway 90 has the capa~ility of co.. ~ g SSP 41 to set up a call between specified telephones.

W O 97/22212 PCT/GB96/~3055 46 Thus, upon A wishing to call B, a third-party call setup request is sent from A's tPrrnin~l over the TnternPt to the gateway 90 (see arrow 91). This setup request includes A's telephone number and B's current roaming number. Gateway 90 f~st aL~~ s to setup the call to A's telephone (which should generally s~ ceeA) and thereafter to set 5 up the call to B's identified telephone. Once the call is setup, A and B co..~ ic~te in standard manner across the PST~.

If B's phone had been busy, then any of the previously described scenarios may ensue.

10 Gateway 90 can also be arranged to make service requests to SCP 43 upon predele~",i"ed trigger conditions being ~t;c~le~. Thus, g~lewdy 90 might be set to pick up the busy condition on B's telephone and initiate a service request to SCP 43 ~or a diversion number. However p~ ng the busy in~lir~tion back to A's tPrmin:ll via gateway 90 is preferred because of the flexibility it gives A regarding further action.
As already generally di~rll~se~i in relation to Figure 14, a complication arises if A only has Internet access via a SLIP/PPP connection over an ol.lil~ly, non-ISDN, PSTN line since, in this case, A's telephone line is already tied up with m~ktng Internet access when gateway 90 seelcs to set up a call to A's telephone. The solutions discussed in 20 respect of Figure 14 (tprmin~tion of Internet session; multiplexing voice and Internet data on same telephone line) can also be used here. An alternative approach both for Figure 14 and for Figure 16 scenarios is possible if user A's terrnin~l can handle a voice call as ~ligiti~P~l voice passed over the Internet. In this case, the voice call can be placed through an interface 80 of the Figure 15 form, and the voice traf~lc and the 25 Internet c~,-,...-l"~ic~tion with the B's phone page and/or gaL~w~y 90 are both carried in Internet packets passed over the SLIP/PPP connection to/from A's L~ linal ~3 but as logically distinct flows passed to ~epal~l~ applications running on tennin~l s3.

It may be noted that the third party call setup request made by A's tt~ n~l to ~Lew~y 30 90 could equally have been made by service logic held in B's phone page and executed by server 51 (such an arrangement would, of course, require A's telephone number to be passed to B's phone-page service logic and this could be arranged to occur either -autom~tir~lly or through a form plcs~ to user A at terrnin~l A and then posted back to server 51).

It may also be noted that the interface 80 of ~igure 15 and the ~alew~y 90 of Figure 5 16 provide examples of service requests being passed to the service control su~y~Lt;, by entities other than SSPs 41.

WWW-based "FreePhone" (800 number) Services It is possible to implement a "FreePhone" or "800 number" type of service using a 10 combination of the WWW and the PSTN. As will be seen from the following desc~ ion of such a service with r~r~ ce to Figure 17, a WWW/PSTN
implern~nt~tit n does not "~cecs,.. ily rely either on Ll~ ;ng call charges from the calling to called par~h~r or on the use of a special "800" number, two characteristics of standard "Freephone" schPmPs. The WWW/PSTN impl~om.ont~tions do, however, 15 possess the more general cllala~;Lt:listic of placing an en~ iring party and the party to whom the enquiry is directed, in telephone contact at the expense of the latter party.

In the Pigure 17 arrangement, a user D such as a large department store has a website on a se;ver 51; for the sake of simplicity, it will be assumed that the server is under 20 the control of user D who has direct co~ uL~l access to the server over line 125. D's Website may, for example, contain many catalogue-like Web pages illustrating goods offered for sale by D. In addition, D has a freephone page 124 for h~n-lling enquiries placed on a freephone basis; the URL of this page is associated with a "freephone"
graphical button 122 placed on each of the Website catalogue pages.
Suppose user A at ~rrnin~l 53 is browsing D's Website, looking at the catalogue pages (arrow 121). If A sees an item of hlLe,es~ and wishes to make an en~uiry to D about this item, then A can a-;Liv~L;: at (e~ 53 the graphical freephone button 122 associated with the catalogue page conrern~l This activation causes code embedded 30 in the catalogue page ~;ull~llLly loaded in A's terminal to prompt the user to enter their telephone number and, optionally, their narne, after which an HTTP request is sent to D's freephone page using the POST method and enclosing the entered data (arrow , W O 97~2212 PCT/GB96/03055 123). D's freephone page on receiving this request ~ec~ s service logic to enter a new enquiry (including A's name and telephone number) in an e~uily ~ueue 127 m~int~in~ 1 in an enquiry control system 126. In the present example, the enquiry control system is co~ cl~rl to the server 51 via line 125"?xt.orn~lly of tne Tnt--rnPt;
5 however, it would also be possible to have server 51 COI~ t~ with the enquiry control system through the Internet and, indeed, this may be the most practical arrangement where D's Website is on an ISP server rather than on a server controlled by D. In fact, the code run in A's termin~l upon activation of the freephone graphical button 122 could be arranged to directly ro~ l ,he enquiry request to the enquiry 10 control system over the rntP-nPt rather than passing it back through the server ~1.

The enquiry control system 126 manages enquiries passed to it to ensure that they are dealt with in an ordered m~nnl?r. The system 126 on receiving a new enquiry preferably P~ t~'; approximately how long it will be before the enquiry is dealt with, 15 this estim~tion being based on the nT-Tnher of ~;ull~ ly queued enquiries and the average time taken to handle an enquiry. This estim~tinn of waiting time is passed back via server 51 to user A in the r~SpOllSe to the POST request message.

The enquiry control system 126 looks after the distribution of enquiries to a number 20 of agents each of which is equipped with a telephone 40 and a display 129. A's enquiry will be dealt with as soon as it reaches the head of the queue 127 and there is an agent ~ietect~fl as available to handle the enguiry (thus, for example, the system may be arranged to detect when an agent's telephone goes on hoolc). When these cond~tions are met, a distribution and setup control unit 128 takes A's enquiry and displays A's 25 name and telephone lluln7Ger on the display 129 of the available agent (~or clarity, herein l~rt:le,lced as agent D'); if user D keeps a ~l~t~b~e on D's past customers or credit rating data, then unit 128 will also look for and display any such further information known about A. At the same time, unit 128 malces a third-party call setup request (arrow 130) over the Internet to ga~ev~,~ 90 asking for a call to be set up 30 between the telephone of the available agent D' and the telephone of user A, both telephones being i~1~ntT~T~l by their respective numbers. If both D' and A pick up the call, the enquiry then proceeds, tne cost of the call being paid for hy D as it is D that ori~in~t-~-l the call over the PSTN. If, for whatever reason, the call remains incomplete (for example, unal~w~lcd by A) for a predeterrnined timeout period, then unit 128 can be allal~ed to ~ltcln~tir~lty pass on to the next enquiry at the head of the queue 127.

S It would, of course, be possible to dis~ellse with having the unit 128 request call setup through gateway 90 and either have the agent D' dial A's nllmher m~ml~lly or have unit 126 initiate auto~ llin~ for D' telephone (agent D' having, for example, a co~ uLel-integrated telephone similar to that of A's in Figure 14). The advantageof these approaches is that the e~ ting PSTN could be used without adaption and without 10 any service in~t~ tion, in imp~ementing the W~ based f~eephonP service.

As tliccllssed in relation to Figures 11 and 13, a complication arises in placing a call to A if A only has TnternPt access via a SLIP/PPP connection over an ordinary, non-ISDN, PSTN line since, in this case, A's telephone line is already tied up with making 15 Internet access when user D tries to set up a call to A's telephone. The solutions cnsserl in respect of Figures 11 and 13 can also be used here ((~ tion of Tnternet session; multiplexing voice and Tnt~ ot data on same telephone line; and placing the call over the Tntern~t to A's tc. ~ ). With respect to the solution based on terrnin~tion of the Internet session, such Lt;;~ tiQn could be delayed until A's enquiry 20 was about to be dealt with; however, to do this, it would be ~-Pces,~ r to provide feedback from the control system 126 over the Internet to A's terminal 53 and toassociate this feedback with code for bringing about ~ntprn~t-session t~nin~tion. One way to achieve this would be to have the response message sent by server 51 in reply to the original POST request message from A, include a correlation code; any 25 subsequent feedback from system 126 passed to A would also include this code (server A having also passed the code to control system 126) thereby allowing A's tPrm;n~l to correctly identi~y this feedback. In fact, the same mPcll~ni~m could be used to provide user A with updates on how much longer user A is likely to be waiting to be called back, this mech~nicm being usable independently of whether or not there was a conflict 30 problem for use of A's telephone line.

W O 97~2212 PCT/GB96/03055 Where user A only has a telephone 40 and no terminal 53, it is still possible to utilise the basic structure of Figure 17 to provide a freephone service for user A without esolLillg to the compleYity of call charge transfer. More particularly, A would dial a special n~ er for user D's freephon~o service (typically an 800 number), and the SSP
5 41 would recognise this special nllmher in standard ll,a~ el and make a service request to SCP 43 in~ lin~ both this special .~ b~f and A's nllmher. SCP 43 would then ascel~i,~ D's freephone-page URL by doing a number-to-URL t~n~l~tion and access D's rr~l~ho"e page using a POST-method HI~P request similar to request 123. Oncethis request had been registered as an enquiry by D's freephone page 124, the lattter 10 could send a response to SCP 43 asking it to play an annollnrçmçnt such as "Your freephone enquiry has been registered; please hang up and you will be co~t~rted shortly". This an,lounc~.nent could be played to A by an IP in standard manner. A
would then hang up and be ready to receive a call from D.

15 A .~ nifi~nt advantage of the above freephone schPmrs using WWW, is that user D
is not running up charges for use of the PSTN during periods when an en~uiry is enqueued, waiting to be handled.

Variants 20 Many variants are, of course, poss;ble to the above-described arrangements and a number of these variants are described below.

D~l,ih.led ~oc~ Ellviro..-.-P..1 As is ill--strat~1 in Figure 18, the SCP 43 mayaccess the ~l~P servers 51 ll-lvu~h a distributed procç~sing environment, DPE 98, 25 at least logically ;,~dLe from the Internet. Preferably in this case the servers 51 are controlled by PSTN O~,dtOlS and are thus restricted in number.

Se. tice Resources on DN~-Type Se. ~ ,. In the foregoing examples, the service 1~ s~,ul.;e items have been been placed on servers 51 connr~t~1 to th~ Internet and a 30 desired service l~sour~e has then been ~rcçscecl over the Internet by the service control ~iU~ illl of the PSTN, and/or by Internet users, through the use of an URI derived from a IGsc,ulce code that identifies the the desired service resource item. In a ~-~f~ d ~ ngemPnt for deriving the URI from a Ic;sol,ree code in the form of a telephone number, all or part of the te~ hone number cQncern~d was parsed into domain name form and then resolved into an URI using a DNS-type distributed ~b~e system that, indeed, could be inlcgl~ted into the DNS itself (see Figures 11 ~ 5 and 12, and related description). In fact, it would be possible to place service lcsoul-;e items directly in E2Pgi~tr~hc~n Records held by a DNS-type distributed database system so that instead of the parsed telephone number being resolved to an URI which is then used to access the required ,t;soul~e, the parsed telephone number is directly resolved to the required service resource item. The rntq~ ni~m employed in this process is exactly as already described for resolving a parsed telephone number into an URI. The DNS-type distributed fi~t~h~e system used for this would preferably be one ~çs~ible over the Tnt~.rnet or the DNS itself so as to provide access to the service resource items for Internet users as well as for the service control subsystem of the PSTN (in the same manner as described above with reference to Figure 18, the DNS-type servers holding the service r~soul~e items may be ~r~ce~ihle to the service control subsystem by a network other than the Internet). Whilst the placing of service resource items in RRs held on DNS-type servers may not be suitable for all types of service resource items, it is suitable for items such as telephone numbers that do not change frequently. Thus, a suitable usage is to provide number portability; in this case, a dialled p~lsonal 20 nul.,a.~r triggers a lookup in the DNS-type system with all or part of the p~,ollal number being first parsed and then applied to the DNS type system to return a current nUlllbC~ for call routing. All dialled nlll..bel . could be treated as ~cl~onal numbers or simply a subset of such numbers, this subset comprising numbers that are readilyif~ l le as ~c~ al numbcl~ by, for example, local lookup at an SSP or the 25 presence of a predelel"~ined leading digit string. The general concept of parsing a telephone number (or similar number) in whole or in part to form a domain name for resolution in a DNS-type distributed ri~t~h~e system can be used for the retrieval of other items of inf4~ lion besides URIs and service le~ou~ce items.

30 F~e _--k l~rhsn~ . In discussing the WWW-based freephone arrangement of Figure 17, it was l~lcnliolled that user A could be supplied with fe~db~ck on the lik~ly length of waiting time before A would be called back. This is one example of using -the Internet to provide a feedback path for a potential or actual telephone user. Another example was provided in relation to Figure 16 where the progress of call setup was reported back by the call setup gateway to user A's terrninal. In fact, generally where a user is known to be using a termin~l actively on the Internet the oppolLulliLy arises S to provide the user with fee~ ck on the progress of call setup through the telephone system. In oreder to do this, it is of course nPces~ry to ensure that the feedbaclc can be passed to the a~ploplidte application running on termin~l A and this will generally require the application to have made ap~ iate linking illrol~llaLion available. As well as call setup progress h~ ation, other information can also be fedback for example 10 during a call holding period. Thus, for example, a special server can be provided on the Internet holding ml-ltimP~i~ clips or even videos that could be output to user A
during a call holding period.

In the described arrangments, the servers ~1 have held service resource items 15 coll~erntod ~limarily with call setup control. It may be noted that in a somewhat ~lirr~lel.l application, Internet servers could be arranged to hold data that could be ~ccess-o-l from the telephone system in response to a user-initi~tec~ telephone request and n ~ to that telephone user. Such a service would he provided, for example, in resporlce to an SSP triggering a service request upon a ?articular telephone number 20 being input, the service request ~ru~ tillg an SCP to cause an intelligent peripheral to access a particular Internet server (not npc-pcc-~rily an HTTP server~ and retrieve ~he required data for return to the calling party. The intelligent peripheral may include a text-to-voice converter for replaying the data vocally to the user.

25 One further fee~ih~ck process is also worthy of note, in this case in relation to service resource items thPm~elves. By way of example, a telephone user G may subscribe to a service by which calls passed through to G's telephone are to be separated by a Tni"i""~"~ of X mim-tes, X being user settable. To implement this service, G has a phone page on a server 51 that includes a "busy" status in~iic~tion. Upon termin~tion 30 of a sncces~ call to G, G's local SSP triggers the serlriing of a message by the associated SCP over the Internet to G's phone page. This message causes G's busyindication to be set to indicate that G is busy; the mess~gto also starts a timer which W O 97~2212 PCT/GB96/03055 times out after a period X and causes the busy status inrlir~ti~n to be reset. A call attempt to G will either be reJected at G's SSP because G's line is gemlinrly busy or will trigger the SSP to enquire via the SCP whether G s phone-page busy status in~ir~tion is set. If the busy status in~lir~tinn is set (which it will be during the period S X following termin~tiQn of a sllrcessfill call) the call aLl~ is rejected whereas if the busy status in-lir~tion is in its reset condition, the call ~LLt;~ iS allowed to proceed.
By placing the busy status inf~i~ation mechanism on G's phone page, it is possible to arrange for G to be able to easily change the value of X.

10 More General Variants. Whilst the service control sub~y~L~l" of the PSTN has been embodied as an SCP in the foregoillg examples, it will be appreciated that the functionality of the service control subsy~lelll could be provided as part of an SSP or in an associated adjunct. Furthermore, the trig~l"~ of service requests can be effected by equipment other than SSPs, for example by i~ L~;~t boxes inserted in the SS7 15 si~:n~lling links.

It will be appreciated that the term "Tnt~rn,ot" is to be lln-1Ptstood to include not only the current specification of the TCP/IP protocols used for the Tnt~rnrt and the current addressing scheme, but also evolutions of these ~aLùl~s such as may be needed to deal 20 with isochronous media. Furthermore, references to the VVWW and the HTTP protocol should equally be understood to encompass their evolved tTesce~

The present invention can also be applied to telephone systems other than just PSTNs, for example to PLMNs and other mobile n~lwolh~, and to private systems using 25 PABXs. In this latter case, a LAN or campus-wide co~ ule~ wolk serving generally the same int~rr~l users as the PABX, will take the role of the Tnternrt in the descri~ed embo~limrnt~

Furthermore, the present invention has application where any switched 30 telecc,...~ ir~tion system (for example, a bro~ n-l ATM system) requires service control and a colll~uL~l l~LWOlk can be used for the delivery of service resources to the service control subsystem of the teleco"..".l,-ir~tion system.

Claims (18)

1. A method of accessing service resource items (49) for use in respect of setting up bearer channels (60) through a switched telecommunications system, said method including the steps of:
(a) -- provisioning at least one server (51) connected to a computer network (50) with a plurality of service resource items (49) that are thereafter locatable on saidcomputer network (50) by corresponding known URIs, said computer network being logically distinct from the telecommunications system, and said service resource items (49) relating to setup control for bearer channels (60) through said telecommunications system with each said service resource item being associated with a respective predetermined code (54), said predetermined codes being distinct from said URIs and identifying end-point entities for said bearer channels;
(b) -- providing a mapping (55) between each said predetermined code (54) and the said known URI of the service resource item (49) associated with that predetermined code; and (c) -- utilising a said predetermined code (54) to access a corresponding said service resource item by using said mapping (55) to determine the URI corresponding to that resource item and then using this URI to access the service resource item (49) over said computer network (50).

2. A method according to claim 1, wherein at least some of said URIs are derivable from their corresponding said predetermined codes (54) by manipulation according to a function specified by said mapping.

3. A method according to claim 1, wherein at least some of said URIs are derivable from their corresponding said predetermined codes by look up in an association table associating said predetermined codes and URIs according to said mapping.

4. A method according to claim 3, wherein said association table is held on at least one database server connected to said computer network, step (c) involving accessing said database server over the computer network (50) to determine the said URI corresponding to the said predetermined code (54).

5. A method according to claim 4, wherein said at least one database server is provided by a DNS-type distributed database system in which said URIs are held in recordsassociated with respective names, herein referred to as domain names, by which the records can be retrieved, step (c) involving translating said predetermined code (54) into a corresponding said domain name and using this domain name to retrieve the URI of the required service resource item (49) from said DNS-type distributed database system.

6. A method according to claim 1, wherein at least two said service items items (49) are located at the same URI, the said predetermined codes (54) of these service resource items including respective relative-resource-identifier (RRI) values that are used at the server (51) holding the service resource items to identify the required resource item amongst the service resource items at the same URI.

7. A method according to any one of the preceding claims, wherein said switched telecommunications system is a telephone system and said predetermined codes comprise numbers from at least one of the following categories:
-- the telephone number of the calling party;
-- the telephone number of the called party.

8. A method according to claim 1, wherein said switched telecommunication system is a telephone system, at least some of said predetermined codes (54) being called-party telephone numbers and serving to retrive service resource items (49) that are the current telephone numbers of the called parties.

9. A method according to any one of the preceding claims, wherein at least one said service resource item (49) is service logic which is executed by the corresponding server (51) upon being accessed with the result of this execution being returned to the accessing entity for use in bearer-channel setup control.

10. A method according to any one of the preceding claims, wherein at least one said service resource item (49) is downloadable service data which upon being accessed is downloaded to the accessing entity for use thereby in bearer-channel setup control.

11. A method according to any one of the preceding claims, wherein at least one said service resource item (49) is downloadable service logic which upon being accessed is downloaded to the accessing entity for execution in bearer-channel setup control.

12. A method according to claim 1, wherein said computer network (50) is generally accessible to users of the telecommunications system.

13. A method according to any one of the preceding claims, wherein said computer network (50) is the Internet.

14. A method according to any one of the preceding claims, wherein said switched telecommunication network is a PSTN.

15. A method according to any one of claims 1 to 13, wherein said telecommunication system is a private system including a PABX with which said service control system (42) is associated, and wherein said computer network (50) is a LAN.

16. A method according to any one of the preceding claims, wherein said URIs areURLs and/or URNs, and said server (51) is an HTTP server.

17. A method of accessing service resource items (49) for use in respect of setting up bearer channels (60) through a switched telecommunications system, said method including the steps of:

(a) - provisioning an HTTP server (51) connected to a computer communication system (50) with a plurality of service resource items (49) at a known URL by which said items are locatable on said computer communication system (50), said computer network being logically distinct from the telecommunication system, and said service resource items (49) relating to setup control for bearer channels (60) through said telecommunications system with each said service resource item being associated with a respective predetermined code (54), said predetermined codes (54) being distinct from said known URL and including respective relative-resource-identifier (RRI) values usable to identify a required said service resource item (49) amongst the service resource items at the same URL;
(b) - providing a mapping (55) between each said predetermined code (54) and the said known URL of the service resource item (49) associated with that predetermined code; and (c) - utilising a said predetermined code (54) to access a corresponding said service resource item by the substeps of:
(i) - using said mapping (55) to determine the URL corresponding to that resource item, (ii) - using the URL determined in substep (ii) to access the HTTP server (51) holding the required service resource item (49) over said computer communications system (50); and iii) - using the relative-resource-indicator (RRI) part of the predetermined code (54) to identify the required service resource item from amongst the service resource items held at the same URL.

18. A method according to claim 17, wherein said telecommunications system is a telephone system and said predetermined codes (54) are personal numbers associated with individual telephone users, said service resource items (49) being current telephone numbers where said individual telephone users may be reached.