CA2250673A1 - Method of providing internet service - Google Patents
Method of providing internet service Download PDFInfo
- Publication number
- CA2250673A1 CA2250673A1 CA 2250673 CA2250673A CA2250673A1 CA 2250673 A1 CA2250673 A1 CA 2250673A1 CA 2250673 CA2250673 CA 2250673 CA 2250673 A CA2250673 A CA 2250673A CA 2250673 A1 CA2250673 A1 CA 2250673A1
- Authority
- CA
- Canada
- Prior art keywords
- access
- server
- account
- time
- prepaid
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
- G06Q20/127—Shopping or accessing services according to a time-limitation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/28—Pre-payment schemes, e.g. "pay before"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/342—Cards defining paid or billed services or quantities
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/16—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for devices exhibiting advertisements, announcements, pictures or the like
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/02—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
- G07F7/025—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered
Abstract
A method of providing prepaid time-related access from a remote computer terminal, which is linked to the Internet through an access server of an Internet Service Provider, provides such access only when an outstanding balance of time remains in the prepaid account of an authorized customer. The method may further provide for on-line replenishing of the prepaid account, using a transaction form which is accessed by the customer. The method may be implemented using so-called RADIUS protocols.
Description
10~ 1998 1~:21i 1--1~il3--82~3--el0~4 T~{OMAS ADAMS R. ASSOC. P. ~6~Z2 METHOD OF ~ROVIDI~G INTER~IET SERVICE
FIELD OF T~E INVE~ION
The present invention relates generally to Intemet access services and more S particularly to a method ~hich allows access to the Intemet through ess~blish~d Intemet Service Providers.
B~CKGROUND OF ~E INVENTION
One current me~od, which perrmts users to access the lntPm~t requires the 10 customer to first pU~Il~ S~ llt; from an rntemet Service Provider. The son~.. ; is in~llP~ on She cu~to7in~r~s COnl~U~ and the cu.~ then subscribes to the InternetService Provider's service, which provides the user with a col~ ion to the Internet.
A s~scl;~lion plan normally involves paying a set amount of money to the Internet Service Provider for a ~I-erifi~r1 number of hours of service over a given period, 15 ~e.g. up to 6C1 hours of IntRrnet access per month). If the customer uses more than the ~l~ ir.~ amount of time in the given period, an ~ n~l charge is levied f~r each zul~li*nn:~l hour of service.
There are also ~.lbscLi~lion plans whercby the cl3sS~P~ pays a set amount of money for an l~nlimit~ number of hours oî acccss per period. There are also "batchP
20 plans whereby the cn~tom~r pays the Intemet Service Provider a set amount of money for a ~ ; r. 1 amount of access time over a specificd period of time, norrnally one year In each of the above~libed cases, thc customer is required topay the Int~rnet Service Provider a certain amount of money to use the Internet Service Provider's service over a prescr bed period of dme.
Under the current systems, the Internet Service Provider assigns each of its cUctnrnprs two unique security codes, one being the user identif~cation code and the other being the user pa5;.~. In order to gain access to thc ~ternet Servic~ Providcrs services, the customer must input these unique codes when ~)ro.ll~d by the Internct Service Provider's cen~al system. The authenticity of these codes is then verified in a 30 d?~t~h~CP of user icl~rltifir~lion codes and pas~ d~ which have been ~ccignrd to each of thc '_:'J'~
There are several drawbacks to the current method of providing Internet service.
18-16-1998 1~:26 1-613-828-0024 THOMAS A~AMS ~ ASSOC. P_87/22 .
A particular ~ .ck to the current method is that the customer must use the Internet Service Provider's service for the entire number of hours per period that the tu~ has sul~s~ b~d for, in order to gain full value of the service. For inS~nrr, if the ~ ,tu~er sul,~ to a plan which provides 60 hours per month of Internet access, 5 in order to receive full value for the amount paid, the customer would have to use the system for the entire 60 hours. Using anything less than 60 hours would not give the ~;u~ ~~ full value.
Under the current system, Int~rnet Service Providers are faced ~vith the problems of billing and ~ e the accoun~s of thcir ~ u~ . They must also face the 10 possibility of c ust~ not paying their account. This leads to loss of revenue for the Internet Service Provider and to some degree poor rrlst;~n~
Such problems create a strong incentive to provide an access and billing system which ~,vill ov~;G---e the disadvantages of the current ~ul~s~ Jtion plans.
The present invention provides a method for overcoming these disadvantages by providing Internet service for prepaid time-related access to a access server of an Internet Service Provider. The method cc,ln~,;ses the steps of first receiving an access sccurity code L m~ l from a remote COI--p~t~f terminal over a cc;-----lu~ ion path. After20 verifying that the access security code is a--thori~l, the next step is dctermining the o~l~rtAndine balance of access time in a prepaid account -~o~ d with the access security code; then linking the con-putef terminal to the Internet through the access server over the co.. ~ nn path when a positive outcPnrlinE balance of access time remains in the a~vu.lL; and thereafter reducing the outstanding balance of access time 25 in the account a~cu~ ,g to the period the computer termin~l is c..nne~le~l to the access server Advantageously, emh~rlimPnt~ of the invention may be used in conjunction with a related debitlcredit card billing and rep1eni.~hine system. A unique aspect of an acce~s account a~ul~ g to the present invention is that the prepaid access time will eventually 30 run out. In order to provide continuous access, the method may also include steps for ~p1r.~ ;n~ the account by: cu-... cL;.~g to ~he Co~ JUt~,l terminal over the ...... ~;t ~tion path; ~ g an authonzation request for additional funds to increase the ollt~t~rlAing halance of access time in the acco~mt; and increasing the ~u~ r..1;ng 10-16-1998 17-27 1-~13-828-0024 THOMAS ADAMS & ASSOC. P.08/22 balance of access time in the prepaid account in accordance with the ~A~hiQn~l funds ~u~ Dd in a l~O..~ to the request.
BRIEF DESCRIPIION OF THE DRAWINGS
S An ~.llbodil.. Lat of the invention will now be describcd by way of example only and with l.,r~,~nc~ to the accoll.ya~ying drawings in which:
Fi~ure l is n block sc.t~ t;c diagram of a portion of an Intemet syst_m, imlufii~ an ISP (Internet Service Provider) server, that provides prepaid tim~related access to the Intemet in acco~nce with the present invention;
Figure 2 is a flow chart of primary prepaid account operations used in part of the system illu;7llated in Figure 1 to provide the prepaid access to the TntPmPt, Figures 3 and 4 are flow charts of s~ prepaid account opcrations uscd in parts of the system illustrated in Figure 1 to provide the prepaid a~cess to the Internet;
Figure S is an illustration of a Tr~n~ tion Form used to rcquest funds to lS replenish a prepaid account which provides the prepaid time-related access to the T.~t~ ~b.(;
Figures 6, 7 and 8 illustrate typical opGlatitlg cnnflitinn!C at 10 m~nute intervals7 of a ~i~t~ used in the system illu~llat~d in Figure 1 to provide the prepaid tim~related access to the Internet; and Figure 9 illustrates a modification of the system of Figure 1.
DESCRIPI'ION OF pRE~RR~n EMBODIMENT
Referring to Figure 1, the relevant portions of the Internet system include an ISP
(Internet Service Provider) server 10 with a corn~tinn 15 to a prepaid account server 25 12 and a cash spttlp-m~nt server 16. The server 12 includes a prepaid account ~l_t;-hace 14. In addition there is a high-spced conncction 18 from the server 10 to the Internet 20. The C~J~P t;on 15 may bc a separate ~ ic~tP~d link or a link ~rough the Internct 20.
Also illustrated are five typical remote dial-up ~Illyutw tcrminals 30, 32, 34, 36 30 and 38 ~C.. Y I~ via tel&pho"~, lines 31, 33, 35, 37 and 39 fes~~ ely, (which providc the ~ ullication paths) to a access server 40. Installed in each of the COII~
terminals 30, 32, 34, 36 and 38 i5 typical co.,....--nications and Internet browser soft vare, that is c~-mrPtihle with the server 10. In addition, each of the co~
~ -lS98 1~ 28 1-613-828-0B24 T~OMAS ADAMS ~. ASSOC. P.09/22 terminals i~-~lud~s 3~r~.dL~: enabling it to interrupt and Intemet session and display m~ q~ s sent to it from the access server 40 in order to advise the user that prepa~d access time is about to run out and prompt the user to take ay~ dtc action, as will be described later. This inl~lluyLioa sorL~ may be i~ ted into the L ..~ , or a S plug-in, or be sepq-r~t~ software provided to the user when the account is being set up, perhaps even downloaded. It may also be capable of monitonng session duration and providing po~;vd;c in~lici~tiorl~ of elapscd time.
The acc~ss server 40 connr~, via a typical high-spced link 42, to the server 10, utilizcs .,,,,-1~ .,c, routers and other well known deviccs (not shown) to controi the 10 flow of data to and from the ISP server 10 and the tenninals 30, 32, 34, 36 and 3X, in a well known manner. Typically, the high-spee~ links and conncctions d~ iLil~l above could be Tl camer or r~ t links.
As is typical in the o~eldLoll of such a system, each customer is ~c~ ned an unique access security code, which typically consists of a use~ identification (USER ID) 15 and a password (PSWD). In the following cles~ ,iylion, each cl~stom~r will be identified by a sinE~le alpha . L~ . "A", IIBn ~C~, "D" or "N" as shown in Figure l. The basic op~...l;.~n of the system will be dcsclil,cd with reference to customer A.Referring to Pigure 1 and Figure 2, ~iu;~tu~er A at the dial-up computer terminal 30 initially diRls the access ~le~honc number of the server 10 to est-q-hlish a conn~ ction 20 over the cc..n...~-.if qtion path 31 through the access server 40 to the server 10. The server 10 in tum solicits customer A's access security code. The server 10, uponidentifying that the code is for the server 12, passes control to the prepaid account server 12 which initially does a lookup in the prepaid account ~~ e 14 to venfy that the access security code is allthor ~ If verified, a "VE~IED" flag is set to "~/". If it 25 is not d~Ltl~ ~d, the flag remains "~", and a control signal is returned to the server 10 which then ~ ro.~r. 1~. the computer tenninal 30.
If the access security code is authorized, the server l 2 then does a second lookup in the ,l~l~h~cA 14 to d~ nil-e the access time r~ .~ini~ "REMAINING HRS:MIN"
in the .;u~h r.~'s prepaid account. If the time rçm~ining has run ouL, i.e. is not 11 >0 30 minutes, a control signal is returned to the se~vcr 10 which then dii,conlleel~ th cG~ uLcl ter~ninql 30. As well, the ~ t~ three transaction flags of A's account in the ~ 14 are set to UX".
16--l9S8 17:29 1--613--828--~E~2~ THOMAS AD~MS 8, ASSOC. P. 10/22 If the access time l~ n~ ine is " > 0" minutes, a "LINK FLAG" i~ ~et to ''~f" and the prepaid account aerver 12 sends a control signal to the server 10 which then links the dial-u~ tenninal 30 to the Intemct 20 ovcr the hi~h-speed connecdon 18. lnaddition, if the time reTn~inine is also "c30" minutes, a transaction flag "TRANS
S FLAG" is set to ~
The server 12 continues to monitor the prepaid time rem~ ining in the ~17t~h~ce 14, and the status of the c.~nc~l~nn to the terminal 30 as reported by lhe server 10 If, as shown in the flow chart of ~igure 2, the dial-up computer terminal 30 is ~
such as by customer A going off line or for any other reason, the server 10 signals the 10 selver 12, and thc A'~r ~l~d three transaction fla~s in the ~l~t~h~cc 14 are set to "x".
If the time ~ i ;..g "REMAINING HRS:MIN" has run out ~i.e. not " >0"
minutes"), a control signal is sent from the prepaid account server 12 to the ISP server lQ which then ~ con~ c uaLu ~ A's terminal 30, and again, the ass~iaL~d three s. clion flags in the d~ 14 are set to "x"
As d~qr,;1~ed above, when the r~-m~ininE time is "C30" minutes, the "TRANS
I7LAG" is set to ~/n, As illustrated in Figure 3, the server 12 then tr~nsmits notiflcation to ~ A's co~ r terminal with an option to coll-pl~t~, a "TRANSACTION
FORM" as il11lch~t~d 3n Figure S to ~ h the access time in customer A s z~nroun~
If customer ~ accepts, the termin~l 30 i9 con--~t~ to a WEB site, cont;~ining the form 20 shown in Figure 5, requesting C~iatOI~ A to complete the form by providing the pe~lincnt information (NAME, USER ID, and ~REDITID~BIT CARD) and ch~l~in~
the "FE~E" covering the amount of access time to bc credit~d to ~'Ui~UlllG~ A's prepaid account. Upon cG~ ;nrl of thc form, customer A clicks the "S~ND" button to L~ula~ the fonn ~-Ç.,ln~.Ltion directly to the cash settlement server 16. Alternatively, 25 customer A can click the DEF~R" button to delay the ~equest for additional prepaid ac~ess time In this example, the WB site containing the form is located on the ISP server 10 It could however, be located on any ISP server throughout the Intcrnct When the form ~n~",.~on is received from the server 10, the cash s~ttl~m~nt seIver 16, which 30 is ope.dt~ by a Cash Settl~mt~nt Provider, conducts an internal check, in a well known manner, to asc~li.in whether the "$" amount can be ~ luvt;d. If approved, the cash ~ t server 16 informs the server 1~ of the amount. The server 12 then tr~ncl~t~
the $" amount to "N" minutes of additional access timc, and p~ xls to update 10--16--1998 1~: 30 1--513--828--0024 TT~OMAS ADAM5 & ASSOC. P. 1 1/22 ~,Ui~t~ A's rREMAINING ~RS:MI~" in the account r~ 14. As well, the scrver 12 sets the "TR~NS FLAa" to "7C". Should no approvt:d "$" amount be received from the server 16 after a S minute wait, the server 12 again sends notification to the terminal 30. Altematively, ~;U~ r A has the option of initi~tin~ the transaction by ~lu~e.,ti~lg S directly to the WEB site ~-.1~ the form.
Referring to Figure 4, ~.he~.e~_~ the "LINK FLAG" is set to "~/" as described with l.,re~lc~ to Pigure 2, the server 12 cond~ct~ a periodic lookup of the "~EMAINING ~IRS:MI~" in cu~t~ ,r A's prepaid account. The server 12 counts " 1"
minute, then dcclG.,~ b the "~EMAlNING HRS:MIN" by that amount of time. This 10 is ~t~d as long as the "LINK FLAG" is set to '~".
Figures 6, 7 and 8 illustrate typical operations of a number of prepaid accountsat 10 minute intervals and the data stored in the prepaid account ~l~t~ e 14. In Figure ~i, only the con-~utcr terminal 32 of ~u~t~lll~l B is not co--n~t~l to the server 10 and all three flags in ~ f ~ B's account are set to "x". The "LINK FLAG" of customer A
15 is set to '~" and the terminal 30 is linked through the server 10 to the Internet 20 as ~;..he~ above. Similarly~ terminals 34, 36 and 38 of customers C, D and N
ely, are also linked to the Intemet 20.
Re~ there is " <30" minutes remaining in the account of ~;usto~l~er C, the "Tl~ANS FLAG" is set to '~". An approval of $20.00 has just bOEn received from the 20 cash settlçmPnt server 16, which is translated to an increase of 30 hours to be added to customer C's prepaid account. The "TRANS ~LAG" for customer D is also set to '~", but no .~ d ~-$" amount has been received by the server 12 from the server 16.
In Figure 7, the time is now lO minutes later (+ lO minutes), so that the "REMAINING HRS:MIN" in each of the active accounts has been d~ lu.,llLccl by lO
25 minnt~c A~-iitinns-11y, ~ U .t~-l... r C's account has been increased by 30 hours and the "T~ANS FLAG" set to "~". Since ~,u~Lu~ r N's account now has " ~ 30" rninutes, the "I~JS FLAG" has been set to '~" and an al~proved arnount of $10, received by these~ver 12, has been n~n~ r~ into an increase of lO hours.
In Fi~ure 8, the time is lO minutes later than is shown in Figure 7 (+20 30 minutes), and the "REMAI~ING ~IRS:MIN" in each of the active accounts of Cu~Lul~
B, C and N, has been do~ nl~ by another lO minutes The "REMAINING
HRS:MIN" in ~ Iv~- D's account has reached "00:00" As a result, customer D's 10~ 1998 17:30 1--613--828--0024 THOMAS ADAMS & ASSOC. P_ 12/22 trrmin~l 36 has been ~ ~nllf 1~ fmm the server lO, as desc:liL.ed above with reÇG~-_a~e to Figure 2, and all thrce 5-~C~;sttt!d flags have been set to "x".
Since ~ h.~ J A's terminal 30 has been discolu~e4LGd from thc server 10, the "3~EMAINI~O IIME" is no longer being ~lt ~ P~, and the three flags in CU:.t 5 A's account in the f~ hA~s 14, are set to "x" by the servcr 12.
Various modifications may be made to the above-described embodiment without d~til-g from the spirit and scope of thc invention as cl-imPd Thus, it ~Anll be evidcnt that any two, or all three of the servers lO, 12 and 16 could be Am~tl~;.. _lt~, so as to function as a single entity. It is also possible to implement the invention in systems using 10 so-called RADIUS (Remote ~uth~ntification Dial-In User Service) routing, as will be d~liL;~,d with lef~Gnce to Figure 9, in which f~lemt n~ which are i~--Qti-~l, orc~ ,~nd, to cl~ cn~ in Figure 1 have the same lG~~ e number, but with a prime.
For convenience of illust~tion~ the individual terminals 30-38 of Figure 1 are not shown in Figure 9. The terminals are C~;t...lr~t' ~, as before, to a access server 40'. In this case, 15 however, the output of access server 40' is directed to a RADIUS router 50 which fol~.~Js calls to either the RADIUS server 10' of the ISP or to the prepaid account server 12' which, as before, includes or has access to a prepaid account .~t ~hac~ (not shown in Figure 9).
The RADIUS router 50 is sof~.~G able to monitor the packets from the access 20 server 40'. In order for the packet to be forwarded to the prepaid account server 12', the user ID must contain certain unique chC ~, Jr~ " ~or ~~Y~mp~ a?" and "S" and a number. I~e RADIUS router 50 also dct~nlillGs where to fon1vard accou~ g packets.
If, in either ;..-~ -nce, the packet cannot be ul.d~ ~tJod, or the user name is not idPnt1fiPd as a prepaid account user, then the packet is forwarded to the ISP RADIUS server 10'.
~5 In the case of an "accounting" packct, if the R~DIUS router 50 determines that the user is a prepaid account user, it not only fol~dltls the packet to the prepaid account server 12', but also forwards a copy of the packet to the ISP RADIUS server lO'. This packe~
oopy provides info~ .tion necessary for the ISP to m,~int tin proper usage st~tiC~ics.
There may, of course, be more than one prcpaid server 12', so the uruque 30 ~ l~,.,,..-t.,. j ~CCi~YI to prepaid account user names include an idcll~ir--, specifically a context server or server number, which assist_ the RADIUS router 50 to dett~ ne the location of the par~cular prepaid server 12' for that user.
10--IB--1998 17:31 1--613--828--0024 THOMAS Ar)AMS & ASSOC. P. 13/22 Every time the RADIUS router 50 .cends a packet to either a prepaid account server 12' or the ISP RADIUS server l0', it waits for a rcply packet. If th~e is no response after a w-l~;ul~ble timeout, e.B. 3 seCon~1s, the RADIUS router 50 sends the packet again, and will do until either a l~ sc is recdved or the packet has been sent S a ~ A~ ;n-~d num'oer of times. The number of times that a packct is re-sent isconfigurab1e. Tf a reply is not received after t'ne configured number of a L~ , the RADIUS router 50 will "time out". On receipt of a rcply, ho.~,ie., the RADIUS router 50 forwards it to the access server (client) 40'.
Operation using the RADIUS protocol is similar to that described with lef~ CC
10 to ~;gure~ 1-8. Thus, when a user at a terminal ~lLe.n~t~ to log-on, the prepaid account se~ver 12' receives a colr~s~..-ling Access-~equest messa~e (comprising one or more packets) from the access server 40', via RADIUS router 50, and sr~,.llcs the prepaid account ~ h~ for the user name/ID. If it is not found, thc prepaid account server 12' returns an "Access-Reject" message to the access server 40'. If the user name is found, 15 however, the next step is for the prepaid account server 12' to d~ unc whether or not the received password matches the user name If there is no match, or if it is de~ermin that the user is already online, the prepaid account server 12' returns an "Access-Reject"
~f, to thc access server 40' If there is a match, and the user is not online, the prepaid account server 10' looks up the time ~ g, as before. If there is timc 20 ~ n-;~due, the prepaid account server 40' returns an "Acccss-Accept" message to the aca~ss server 40' via the RADIUS router 50. The message includes the total amount of time r~.n~ning on the account, which tells tne access server 40' when to .liscollne. t the user. After the "Access-Accept" message has been sent, the applop.i~te nag is set, as before, to show that the user in online.
~5 When the access server 40' receives the "Acces~-Accept" message, it connect~
the user to the Internet and sends to the prepaid account server 10', via the RADIUS
router 50, an "Acco.,l~L;ng-Request" ~~-G Z.~y~C~ which can be described as an "Accou.-L;ng-Start" .,,~ because it notifies the prepaid account server 10' of the start time of the session. In addition, the prepaid account server t2' includes in the "Access-Accept"
30 ...- ~- t~,e the maximum amount of time the access server 40' may allow for the session, i.e. based upon the prepaid time in the prepaid account tl~h~-~P The prepaid account ser~er 40' replies with a co~ JollJ;ng "Accounting-Response" message. When the session is ~e.---;n.lt~l, whether because the uscr t~.,lLin.~ the session, or the acoess l~-IB-19~8 17:32 1-613-828-~024 THOMAS ADAMS & ASSOC. P.14/22 server 40' d~ s that the allowable time has heen spent, or for any other reason, the access server 40' sends to the prepaid account server 10- an "Accounting-Stop"
...e, ~, which ir~lurlrq the stop time of the session and thc tot~ duration of the session.
On receipt, the prepaid account server 40' sets the flag to show that the user is oMine 5 and CO~ S the ~lul~t;.,~l of the session itself by co~ u~ g the start time and stop time.
At this time, the prepaid account se~ver 40' decreases the user account to reflect the d~ n of the session.
Thus, all time flags are set after the user has terrninated their comlo~;lion and the prcpaid account server has received an accou~ g request from the access server.
In the fo.~ lg d~ ip~ion, the user is p~U~ t~ by means of inleilul ~ me~rs to r~pl~i~h his ~ o~nt It will be ~ cc;at~d that an initial "deposit" may bc madc using other means, such as by t~lf~l-nnr when the account is being set up, and e-mail ...PS,~5 might be sent to the user when the balance of time in the account is reduced to a p~ t~ ...hl~ level, say 2 hours fr~m timeout. It is also envisaged that the u~r 15 could access the ~l~h~u- himself to dct~ i..c, perhaps when comm~cing a session, how much prep~ud time is left. It should be noted that this alTangement obviates the need for ''l~t~lu~t'l S~Snw~ to be loaded in each terminal to allow the user to be warned that the pr~paid time has been used up.
It should be app~_;,.t~d that, although the Ç~ o;~lg description rcfers to the 20 terrninal server 40', ~ADIUS router 50 and RADIUS server 10' as if thcy are physical entities, in practice they will comprise software running on suitable hardware controlled by the Intemet Service Provider, or perhaps on two or more sep~rate COIll~utw:~ which CO~ ;eqt~ with each other. Moreover, the RAD~US router software could be stand-alone or ;,~ e;1 into the terminal server 40' or thc RADIUS server 10'. It should also 25 be ap~iakd that the prepaid account server 12' may handle accounts for several Internet service providers 52. Tndeed, there could be several prepaid account servers 12' to handle prepaid a~ u~ for a plurality of Internet service providers.
Tn the l~,~going de~ ion, the radius router e,Y~h~n~es packets with the ISP
RADTUS server 50 and the prepaid account server 19' via the Intemet. It would be30 possible, of course, for these packets to be PYch~ngrA by an alternative route, such as a ~.~.~ dnta l~.lw.,rL, for PY~mrlP Signsllin~ Systcm No. 7.
Tlhe cash s~ttlP~n~nt server 16' is c~n~ L~I only to a prepaid account server 12', either via the Intemet or using another c~.n.. -;cation link, sueh as SS7.
FIELD OF T~E INVE~ION
The present invention relates generally to Intemet access services and more S particularly to a method ~hich allows access to the Intemet through ess~blish~d Intemet Service Providers.
B~CKGROUND OF ~E INVENTION
One current me~od, which perrmts users to access the lntPm~t requires the 10 customer to first pU~Il~ S~ llt; from an rntemet Service Provider. The son~.. ; is in~llP~ on She cu~to7in~r~s COnl~U~ and the cu.~ then subscribes to the InternetService Provider's service, which provides the user with a col~ ion to the Internet.
A s~scl;~lion plan normally involves paying a set amount of money to the Internet Service Provider for a ~I-erifi~r1 number of hours of service over a given period, 15 ~e.g. up to 6C1 hours of IntRrnet access per month). If the customer uses more than the ~l~ ir.~ amount of time in the given period, an ~ n~l charge is levied f~r each zul~li*nn:~l hour of service.
There are also ~.lbscLi~lion plans whercby the cl3sS~P~ pays a set amount of money for an l~nlimit~ number of hours oî acccss per period. There are also "batchP
20 plans whereby the cn~tom~r pays the Intemet Service Provider a set amount of money for a ~ ; r. 1 amount of access time over a specificd period of time, norrnally one year In each of the above~libed cases, thc customer is required topay the Int~rnet Service Provider a certain amount of money to use the Internet Service Provider's service over a prescr bed period of dme.
Under the current systems, the Internet Service Provider assigns each of its cUctnrnprs two unique security codes, one being the user identif~cation code and the other being the user pa5;.~. In order to gain access to thc ~ternet Servic~ Providcrs services, the customer must input these unique codes when ~)ro.ll~d by the Internct Service Provider's cen~al system. The authenticity of these codes is then verified in a 30 d?~t~h~CP of user icl~rltifir~lion codes and pas~ d~ which have been ~ccignrd to each of thc '_:'J'~
There are several drawbacks to the current method of providing Internet service.
18-16-1998 1~:26 1-613-828-0024 THOMAS A~AMS ~ ASSOC. P_87/22 .
A particular ~ .ck to the current method is that the customer must use the Internet Service Provider's service for the entire number of hours per period that the tu~ has sul~s~ b~d for, in order to gain full value of the service. For inS~nrr, if the ~ ,tu~er sul,~ to a plan which provides 60 hours per month of Internet access, 5 in order to receive full value for the amount paid, the customer would have to use the system for the entire 60 hours. Using anything less than 60 hours would not give the ~;u~ ~~ full value.
Under the current system, Int~rnet Service Providers are faced ~vith the problems of billing and ~ e the accoun~s of thcir ~ u~ . They must also face the 10 possibility of c ust~ not paying their account. This leads to loss of revenue for the Internet Service Provider and to some degree poor rrlst;~n~
Such problems create a strong incentive to provide an access and billing system which ~,vill ov~;G---e the disadvantages of the current ~ul~s~ Jtion plans.
The present invention provides a method for overcoming these disadvantages by providing Internet service for prepaid time-related access to a access server of an Internet Service Provider. The method cc,ln~,;ses the steps of first receiving an access sccurity code L m~ l from a remote COI--p~t~f terminal over a cc;-----lu~ ion path. After20 verifying that the access security code is a--thori~l, the next step is dctermining the o~l~rtAndine balance of access time in a prepaid account -~o~ d with the access security code; then linking the con-putef terminal to the Internet through the access server over the co.. ~ nn path when a positive outcPnrlinE balance of access time remains in the a~vu.lL; and thereafter reducing the outstanding balance of access time 25 in the account a~cu~ ,g to the period the computer termin~l is c..nne~le~l to the access server Advantageously, emh~rlimPnt~ of the invention may be used in conjunction with a related debitlcredit card billing and rep1eni.~hine system. A unique aspect of an acce~s account a~ul~ g to the present invention is that the prepaid access time will eventually 30 run out. In order to provide continuous access, the method may also include steps for ~p1r.~ ;n~ the account by: cu-... cL;.~g to ~he Co~ JUt~,l terminal over the ...... ~;t ~tion path; ~ g an authonzation request for additional funds to increase the ollt~t~rlAing halance of access time in the acco~mt; and increasing the ~u~ r..1;ng 10-16-1998 17-27 1-~13-828-0024 THOMAS ADAMS & ASSOC. P.08/22 balance of access time in the prepaid account in accordance with the ~A~hiQn~l funds ~u~ Dd in a l~O..~ to the request.
BRIEF DESCRIPIION OF THE DRAWINGS
S An ~.llbodil.. Lat of the invention will now be describcd by way of example only and with l.,r~,~nc~ to the accoll.ya~ying drawings in which:
Fi~ure l is n block sc.t~ t;c diagram of a portion of an Intemet syst_m, imlufii~ an ISP (Internet Service Provider) server, that provides prepaid tim~related access to the Intemet in acco~nce with the present invention;
Figure 2 is a flow chart of primary prepaid account operations used in part of the system illu;7llated in Figure 1 to provide the prepaid access to the TntPmPt, Figures 3 and 4 are flow charts of s~ prepaid account opcrations uscd in parts of the system illustrated in Figure 1 to provide the prepaid a~cess to the Internet;
Figure S is an illustration of a Tr~n~ tion Form used to rcquest funds to lS replenish a prepaid account which provides the prepaid time-related access to the T.~t~ ~b.(;
Figures 6, 7 and 8 illustrate typical opGlatitlg cnnflitinn!C at 10 m~nute intervals7 of a ~i~t~ used in the system illu~llat~d in Figure 1 to provide the prepaid tim~related access to the Internet; and Figure 9 illustrates a modification of the system of Figure 1.
DESCRIPI'ION OF pRE~RR~n EMBODIMENT
Referring to Figure 1, the relevant portions of the Internet system include an ISP
(Internet Service Provider) server 10 with a corn~tinn 15 to a prepaid account server 25 12 and a cash spttlp-m~nt server 16. The server 12 includes a prepaid account ~l_t;-hace 14. In addition there is a high-spced conncction 18 from the server 10 to the Internet 20. The C~J~P t;on 15 may bc a separate ~ ic~tP~d link or a link ~rough the Internct 20.
Also illustrated are five typical remote dial-up ~Illyutw tcrminals 30, 32, 34, 36 30 and 38 ~C.. Y I~ via tel&pho"~, lines 31, 33, 35, 37 and 39 fes~~ ely, (which providc the ~ ullication paths) to a access server 40. Installed in each of the COII~
terminals 30, 32, 34, 36 and 38 i5 typical co.,....--nications and Internet browser soft vare, that is c~-mrPtihle with the server 10. In addition, each of the co~
~ -lS98 1~ 28 1-613-828-0B24 T~OMAS ADAMS ~. ASSOC. P.09/22 terminals i~-~lud~s 3~r~.dL~: enabling it to interrupt and Intemet session and display m~ q~ s sent to it from the access server 40 in order to advise the user that prepa~d access time is about to run out and prompt the user to take ay~ dtc action, as will be described later. This inl~lluyLioa sorL~ may be i~ ted into the L ..~ , or a S plug-in, or be sepq-r~t~ software provided to the user when the account is being set up, perhaps even downloaded. It may also be capable of monitonng session duration and providing po~;vd;c in~lici~tiorl~ of elapscd time.
The acc~ss server 40 connr~, via a typical high-spced link 42, to the server 10, utilizcs .,,,,-1~ .,c, routers and other well known deviccs (not shown) to controi the 10 flow of data to and from the ISP server 10 and the tenninals 30, 32, 34, 36 and 3X, in a well known manner. Typically, the high-spee~ links and conncctions d~ iLil~l above could be Tl camer or r~ t links.
As is typical in the o~eldLoll of such a system, each customer is ~c~ ned an unique access security code, which typically consists of a use~ identification (USER ID) 15 and a password (PSWD). In the following cles~ ,iylion, each cl~stom~r will be identified by a sinE~le alpha . L~ . "A", IIBn ~C~, "D" or "N" as shown in Figure l. The basic op~...l;.~n of the system will be dcsclil,cd with reference to customer A.Referring to Pigure 1 and Figure 2, ~iu;~tu~er A at the dial-up computer terminal 30 initially diRls the access ~le~honc number of the server 10 to est-q-hlish a conn~ ction 20 over the cc..n...~-.if qtion path 31 through the access server 40 to the server 10. The server 10 in tum solicits customer A's access security code. The server 10, uponidentifying that the code is for the server 12, passes control to the prepaid account server 12 which initially does a lookup in the prepaid account ~~ e 14 to venfy that the access security code is allthor ~ If verified, a "VE~IED" flag is set to "~/". If it 25 is not d~Ltl~ ~d, the flag remains "~", and a control signal is returned to the server 10 which then ~ ro.~r. 1~. the computer tenninal 30.
If the access security code is authorized, the server l 2 then does a second lookup in the ,l~l~h~cA 14 to d~ nil-e the access time r~ .~ini~ "REMAINING HRS:MIN"
in the .;u~h r.~'s prepaid account. If the time rçm~ining has run ouL, i.e. is not 11 >0 30 minutes, a control signal is returned to the se~vcr 10 which then dii,conlleel~ th cG~ uLcl ter~ninql 30. As well, the ~ t~ three transaction flags of A's account in the ~ 14 are set to UX".
16--l9S8 17:29 1--613--828--~E~2~ THOMAS AD~MS 8, ASSOC. P. 10/22 If the access time l~ n~ ine is " > 0" minutes, a "LINK FLAG" i~ ~et to ''~f" and the prepaid account aerver 12 sends a control signal to the server 10 which then links the dial-u~ tenninal 30 to the Intemct 20 ovcr the hi~h-speed connecdon 18. lnaddition, if the time reTn~inine is also "c30" minutes, a transaction flag "TRANS
S FLAG" is set to ~
The server 12 continues to monitor the prepaid time rem~ ining in the ~17t~h~ce 14, and the status of the c.~nc~l~nn to the terminal 30 as reported by lhe server 10 If, as shown in the flow chart of ~igure 2, the dial-up computer terminal 30 is ~
such as by customer A going off line or for any other reason, the server 10 signals the 10 selver 12, and thc A'~r ~l~d three transaction fla~s in the ~l~t~h~cc 14 are set to "x".
If the time ~ i ;..g "REMAINING HRS:MIN" has run out ~i.e. not " >0"
minutes"), a control signal is sent from the prepaid account server 12 to the ISP server lQ which then ~ con~ c uaLu ~ A's terminal 30, and again, the ass~iaL~d three s. clion flags in the d~ 14 are set to "x"
As d~qr,;1~ed above, when the r~-m~ininE time is "C30" minutes, the "TRANS
I7LAG" is set to ~/n, As illustrated in Figure 3, the server 12 then tr~nsmits notiflcation to ~ A's co~ r terminal with an option to coll-pl~t~, a "TRANSACTION
FORM" as il11lch~t~d 3n Figure S to ~ h the access time in customer A s z~nroun~
If customer ~ accepts, the termin~l 30 i9 con--~t~ to a WEB site, cont;~ining the form 20 shown in Figure 5, requesting C~iatOI~ A to complete the form by providing the pe~lincnt information (NAME, USER ID, and ~REDITID~BIT CARD) and ch~l~in~
the "FE~E" covering the amount of access time to bc credit~d to ~'Ui~UlllG~ A's prepaid account. Upon cG~ ;nrl of thc form, customer A clicks the "S~ND" button to L~ula~ the fonn ~-Ç.,ln~.Ltion directly to the cash settlement server 16. Alternatively, 25 customer A can click the DEF~R" button to delay the ~equest for additional prepaid ac~ess time In this example, the WB site containing the form is located on the ISP server 10 It could however, be located on any ISP server throughout the Intcrnct When the form ~n~",.~on is received from the server 10, the cash s~ttl~m~nt seIver 16, which 30 is ope.dt~ by a Cash Settl~mt~nt Provider, conducts an internal check, in a well known manner, to asc~li.in whether the "$" amount can be ~ luvt;d. If approved, the cash ~ t server 16 informs the server 1~ of the amount. The server 12 then tr~ncl~t~
the $" amount to "N" minutes of additional access timc, and p~ xls to update 10--16--1998 1~: 30 1--513--828--0024 TT~OMAS ADAM5 & ASSOC. P. 1 1/22 ~,Ui~t~ A's rREMAINING ~RS:MI~" in the account r~ 14. As well, the scrver 12 sets the "TR~NS FLAa" to "7C". Should no approvt:d "$" amount be received from the server 16 after a S minute wait, the server 12 again sends notification to the terminal 30. Altematively, ~;U~ r A has the option of initi~tin~ the transaction by ~lu~e.,ti~lg S directly to the WEB site ~-.1~ the form.
Referring to Figure 4, ~.he~.e~_~ the "LINK FLAG" is set to "~/" as described with l.,re~lc~ to Pigure 2, the server 12 cond~ct~ a periodic lookup of the "~EMAINING ~IRS:MI~" in cu~t~ ,r A's prepaid account. The server 12 counts " 1"
minute, then dcclG.,~ b the "~EMAlNING HRS:MIN" by that amount of time. This 10 is ~t~d as long as the "LINK FLAG" is set to '~".
Figures 6, 7 and 8 illustrate typical operations of a number of prepaid accountsat 10 minute intervals and the data stored in the prepaid account ~l~t~ e 14. In Figure ~i, only the con-~utcr terminal 32 of ~u~t~lll~l B is not co--n~t~l to the server 10 and all three flags in ~ f ~ B's account are set to "x". The "LINK FLAG" of customer A
15 is set to '~" and the terminal 30 is linked through the server 10 to the Internet 20 as ~;..he~ above. Similarly~ terminals 34, 36 and 38 of customers C, D and N
ely, are also linked to the Intemet 20.
Re~ there is " <30" minutes remaining in the account of ~;usto~l~er C, the "Tl~ANS FLAG" is set to '~". An approval of $20.00 has just bOEn received from the 20 cash settlçmPnt server 16, which is translated to an increase of 30 hours to be added to customer C's prepaid account. The "TRANS ~LAG" for customer D is also set to '~", but no .~ d ~-$" amount has been received by the server 12 from the server 16.
In Figure 7, the time is now lO minutes later (+ lO minutes), so that the "REMAINING HRS:MIN" in each of the active accounts has been d~ lu.,llLccl by lO
25 minnt~c A~-iitinns-11y, ~ U .t~-l... r C's account has been increased by 30 hours and the "T~ANS FLAG" set to "~". Since ~,u~Lu~ r N's account now has " ~ 30" rninutes, the "I~JS FLAG" has been set to '~" and an al~proved arnount of $10, received by these~ver 12, has been n~n~ r~ into an increase of lO hours.
In Fi~ure 8, the time is lO minutes later than is shown in Figure 7 (+20 30 minutes), and the "REMAI~ING ~IRS:MIN" in each of the active accounts of Cu~Lul~
B, C and N, has been do~ nl~ by another lO minutes The "REMAINING
HRS:MIN" in ~ Iv~- D's account has reached "00:00" As a result, customer D's 10~ 1998 17:30 1--613--828--0024 THOMAS ADAMS & ASSOC. P_ 12/22 trrmin~l 36 has been ~ ~nllf 1~ fmm the server lO, as desc:liL.ed above with reÇG~-_a~e to Figure 2, and all thrce 5-~C~;sttt!d flags have been set to "x".
Since ~ h.~ J A's terminal 30 has been discolu~e4LGd from thc server 10, the "3~EMAINI~O IIME" is no longer being ~lt ~ P~, and the three flags in CU:.t 5 A's account in the f~ hA~s 14, are set to "x" by the servcr 12.
Various modifications may be made to the above-described embodiment without d~til-g from the spirit and scope of thc invention as cl-imPd Thus, it ~Anll be evidcnt that any two, or all three of the servers lO, 12 and 16 could be Am~tl~;.. _lt~, so as to function as a single entity. It is also possible to implement the invention in systems using 10 so-called RADIUS (Remote ~uth~ntification Dial-In User Service) routing, as will be d~liL;~,d with lef~Gnce to Figure 9, in which f~lemt n~ which are i~--Qti-~l, orc~ ,~nd, to cl~ cn~ in Figure 1 have the same lG~~ e number, but with a prime.
For convenience of illust~tion~ the individual terminals 30-38 of Figure 1 are not shown in Figure 9. The terminals are C~;t...lr~t' ~, as before, to a access server 40'. In this case, 15 however, the output of access server 40' is directed to a RADIUS router 50 which fol~.~Js calls to either the RADIUS server 10' of the ISP or to the prepaid account server 12' which, as before, includes or has access to a prepaid account .~t ~hac~ (not shown in Figure 9).
The RADIUS router 50 is sof~.~G able to monitor the packets from the access 20 server 40'. In order for the packet to be forwarded to the prepaid account server 12', the user ID must contain certain unique chC ~, Jr~ " ~or ~~Y~mp~ a?" and "S" and a number. I~e RADIUS router 50 also dct~nlillGs where to fon1vard accou~ g packets.
If, in either ;..-~ -nce, the packet cannot be ul.d~ ~tJod, or the user name is not idPnt1fiPd as a prepaid account user, then the packet is forwarded to the ISP RADIUS server 10'.
~5 In the case of an "accounting" packct, if the R~DIUS router 50 determines that the user is a prepaid account user, it not only fol~dltls the packet to the prepaid account server 12', but also forwards a copy of the packet to the ISP RADIUS server lO'. This packe~
oopy provides info~ .tion necessary for the ISP to m,~int tin proper usage st~tiC~ics.
There may, of course, be more than one prcpaid server 12', so the uruque 30 ~ l~,.,,..-t.,. j ~CCi~YI to prepaid account user names include an idcll~ir--, specifically a context server or server number, which assist_ the RADIUS router 50 to dett~ ne the location of the par~cular prepaid server 12' for that user.
10--IB--1998 17:31 1--613--828--0024 THOMAS Ar)AMS & ASSOC. P. 13/22 Every time the RADIUS router 50 .cends a packet to either a prepaid account server 12' or the ISP RADIUS server l0', it waits for a rcply packet. If th~e is no response after a w-l~;ul~ble timeout, e.B. 3 seCon~1s, the RADIUS router 50 sends the packet again, and will do until either a l~ sc is recdved or the packet has been sent S a ~ A~ ;n-~d num'oer of times. The number of times that a packct is re-sent isconfigurab1e. Tf a reply is not received after t'ne configured number of a L~ , the RADIUS router 50 will "time out". On receipt of a rcply, ho.~,ie., the RADIUS router 50 forwards it to the access server (client) 40'.
Operation using the RADIUS protocol is similar to that described with lef~ CC
10 to ~;gure~ 1-8. Thus, when a user at a terminal ~lLe.n~t~ to log-on, the prepaid account se~ver 12' receives a colr~s~..-ling Access-~equest messa~e (comprising one or more packets) from the access server 40', via RADIUS router 50, and sr~,.llcs the prepaid account ~ h~ for the user name/ID. If it is not found, thc prepaid account server 12' returns an "Access-Reject" message to the access server 40'. If the user name is found, 15 however, the next step is for the prepaid account server 12' to d~ unc whether or not the received password matches the user name If there is no match, or if it is de~ermin that the user is already online, the prepaid account server 12' returns an "Access-Reject"
~f, to thc access server 40' If there is a match, and the user is not online, the prepaid account server 10' looks up the time ~ g, as before. If there is timc 20 ~ n-;~due, the prepaid account server 40' returns an "Acccss-Accept" message to the aca~ss server 40' via the RADIUS router 50. The message includes the total amount of time r~.n~ning on the account, which tells tne access server 40' when to .liscollne. t the user. After the "Access-Accept" message has been sent, the applop.i~te nag is set, as before, to show that the user in online.
~5 When the access server 40' receives the "Acces~-Accept" message, it connect~
the user to the Internet and sends to the prepaid account server 10', via the RADIUS
router 50, an "Acco.,l~L;ng-Request" ~~-G Z.~y~C~ which can be described as an "Accou.-L;ng-Start" .,,~ because it notifies the prepaid account server 10' of the start time of the session. In addition, the prepaid account server t2' includes in the "Access-Accept"
30 ...- ~- t~,e the maximum amount of time the access server 40' may allow for the session, i.e. based upon the prepaid time in the prepaid account tl~h~-~P The prepaid account ser~er 40' replies with a co~ JollJ;ng "Accounting-Response" message. When the session is ~e.---;n.lt~l, whether because the uscr t~.,lLin.~ the session, or the acoess l~-IB-19~8 17:32 1-613-828-~024 THOMAS ADAMS & ASSOC. P.14/22 server 40' d~ s that the allowable time has heen spent, or for any other reason, the access server 40' sends to the prepaid account server 10- an "Accounting-Stop"
...e, ~, which ir~lurlrq the stop time of the session and thc tot~ duration of the session.
On receipt, the prepaid account server 40' sets the flag to show that the user is oMine 5 and CO~ S the ~lul~t;.,~l of the session itself by co~ u~ g the start time and stop time.
At this time, the prepaid account se~ver 40' decreases the user account to reflect the d~ n of the session.
Thus, all time flags are set after the user has terrninated their comlo~;lion and the prcpaid account server has received an accou~ g request from the access server.
In the fo.~ lg d~ ip~ion, the user is p~U~ t~ by means of inleilul ~ me~rs to r~pl~i~h his ~ o~nt It will be ~ cc;at~d that an initial "deposit" may bc madc using other means, such as by t~lf~l-nnr when the account is being set up, and e-mail ...PS,~5 might be sent to the user when the balance of time in the account is reduced to a p~ t~ ...hl~ level, say 2 hours fr~m timeout. It is also envisaged that the u~r 15 could access the ~l~h~u- himself to dct~ i..c, perhaps when comm~cing a session, how much prep~ud time is left. It should be noted that this alTangement obviates the need for ''l~t~lu~t'l S~Snw~ to be loaded in each terminal to allow the user to be warned that the pr~paid time has been used up.
It should be app~_;,.t~d that, although the Ç~ o;~lg description rcfers to the 20 terrninal server 40', ~ADIUS router 50 and RADIUS server 10' as if thcy are physical entities, in practice they will comprise software running on suitable hardware controlled by the Intemet Service Provider, or perhaps on two or more sep~rate COIll~utw:~ which CO~ ;eqt~ with each other. Moreover, the RAD~US router software could be stand-alone or ;,~ e;1 into the terminal server 40' or thc RADIUS server 10'. It should also 25 be ap~iakd that the prepaid account server 12' may handle accounts for several Internet service providers 52. Tndeed, there could be several prepaid account servers 12' to handle prepaid a~ u~ for a plurality of Internet service providers.
Tn the l~,~going de~ ion, the radius router e,Y~h~n~es packets with the ISP
RADTUS server 50 and the prepaid account server 19' via the Intemet. It would be30 possible, of course, for these packets to be PYch~ngrA by an alternative route, such as a ~.~.~ dnta l~.lw.,rL, for PY~mrlP Signsllin~ Systcm No. 7.
Tlhe cash s~ttlP~n~nt server 16' is c~n~ L~I only to a prepaid account server 12', either via the Intemet or using another c~.n.. -;cation link, sueh as SS7.
Claims (5)
1. A method of providing Internet service for prepaid time-related access to an access server of an Internet Service Provider, comprising the steps of:
receiving an access security code transmitted from a remote computer terminal over a communication path;
verifying that the access security code is a prepaid account associated determining the outstanding balance of access time in a prepaid account associated with the access security code, linking the computer terminal to the Internet through the access server over thecommunication path when a positive outstanding balance of access time remains in the account; and reducing the outstanding balance of access time in the account in dependence upon the period the computer terminal is linked to the Internet.
receiving an access security code transmitted from a remote computer terminal over a communication path;
verifying that the access security code is a prepaid account associated determining the outstanding balance of access time in a prepaid account associated with the access security code, linking the computer terminal to the Internet through the access server over thecommunication path when a positive outstanding balance of access time remains in the account; and reducing the outstanding balance of access time in the account in dependence upon the period the computer terminal is linked to the Internet.
2. A method of providing Internet service as claimed in claim 1, further comprising the steps of:
in response to reduction of the outstanding balance to a predetermined minimum outstanding balance of access time in the prepaid account, conveying to the computer terminal over the communication path, an authorization request for additional funds to increase the outstanding balance of access time in the account; and increasing the outstanding balance of access time in the prepaid account in accordance with the additional funds authorized in a response to the authorization request.
in response to reduction of the outstanding balance to a predetermined minimum outstanding balance of access time in the prepaid account, conveying to the computer terminal over the communication path, an authorization request for additional funds to increase the outstanding balance of access time in the account; and increasing the outstanding balance of access time in the prepaid account in accordance with the additional funds authorized in a response to the authorization request.
3. A method of providing Internet service as claimed in claim 2, further comprising the steps of:
forwarding the information in the additional funds authorization request to a cash settlement server; and increasing the outstanding balance of access time in the prepaid account upon receiving from the cash settlement server, the amount of the additional funds authorized.
forwarding the information in the additional funds authorization request to a cash settlement server; and increasing the outstanding balance of access time in the prepaid account upon receiving from the cash settlement server, the amount of the additional funds authorized.
4. A method of providing Internet service as claimed in claim 2, further comprising the step of:
terminating the connection between the computer terminal and the access server when the outstanding balance of access time is fully depleted.
terminating the connection between the computer terminal and the access server when the outstanding balance of access time is fully depleted.
5. A method of providing Internet service as claimed in claim 2, further comprising the step of terminating the connection between the computer terminal and the access server when the access server has determined that there is no balance of access time outstanding.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2250673 CA2250673A1 (en) | 1997-10-17 | 1998-10-16 | Method of providing internet service |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2,218,587 | 1997-10-17 | ||
| CA 2218587 CA2218587A1 (en) | 1997-10-17 | 1997-10-17 | Method of providing internet service |
| CA 2250673 CA2250673A1 (en) | 1997-10-17 | 1998-10-16 | Method of providing internet service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2250673A1 true CA2250673A1 (en) | 1999-04-17 |
Family
ID=25679738
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2250673 Abandoned CA2250673A1 (en) | 1997-10-17 | 1998-10-16 | Method of providing internet service |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2250673A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001099053A2 (en) * | 2000-06-19 | 2001-12-27 | Emt As | Method and system for organizing the payment of parking services |
| EP1407401A1 (en) * | 2001-06-01 | 2004-04-14 | Watercove Networks | Topping up a subscriber's account for a multimedia service on a communications network while the service is being provided |
-
1998
- 1998-10-16 CA CA 2250673 patent/CA2250673A1/en not_active Abandoned
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001099053A2 (en) * | 2000-06-19 | 2001-12-27 | Emt As | Method and system for organizing the payment of parking services |
| WO2001099053A3 (en) * | 2000-06-19 | 2002-09-12 | Emt As | Method and system for organizing the payment of parking services |
| EP1407401A1 (en) * | 2001-06-01 | 2004-04-14 | Watercove Networks | Topping up a subscriber's account for a multimedia service on a communications network while the service is being provided |
| EP1407401A4 (en) * | 2001-06-01 | 2004-08-25 | Watercove Networks | Topping up a subscriber's account for a multimedia service on a communications network while the service is being provided |
| US7609682B2 (en) | 2001-06-01 | 2009-10-27 | Alcatel-Lucent Usa Inc. | Implementing an intelligent network service for a packet-switched service using a node interfacing a mobile communications network to a packet data network |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7319855B1 (en) | Method for charging internet services via a mobile telephone | |
| US8606719B2 (en) | System for management of alternatively priced transactions on network | |
| US5845267A (en) | System and method for billing for transactions conducted over the internet from within an intranet | |
| EP1031106B1 (en) | A retail method over a wide area network | |
| CN1826766B (en) | Method and apparatus for controlling credit based access (prepaid) to a wireless network | |
| US20020133412A1 (en) | System for management of transactions on networks | |
| WO1997040615A2 (en) | Method for billing for transactions over the internet | |
| US20030220994A1 (en) | Wireless network access system and method | |
| US7552870B2 (en) | Trading network resources | |
| WO2005006228A2 (en) | Method for charging costs of enjoying contents transmitted over a telecommunications network and system thereof | |
| US20030069855A1 (en) | Control server for supporting the charging of services | |
| US7525956B2 (en) | Architectures for clearing and settlement services between internet telephony clearinghouses | |
| US20200349531A1 (en) | Method and system for transferring funds from an account to an individual | |
| EP1014672A2 (en) | Arrangement for billing or billing authorization using a calling card | |
| WO2002023789A2 (en) | A charge number issuing system and method | |
| CA2250673A1 (en) | Method of providing internet service | |
| US20040139015A1 (en) | Method for preparing a payment transaction in a communication network | |
| RU2296367C2 (en) | Method for receiving or purchasing a service provided via information network | |
| CA2218587A1 (en) | Method of providing internet service | |
| KR101134229B1 (en) | Method of and system for communicating liability data in a telecommunications network | |
| KR100484903B1 (en) | System for collecting money on-line using of a multi-media public-phone and method of the same | |
| CN104038352A (en) | Method and system for transmitting liability data in telecommunication network | |
| US20070005491A1 (en) | Method for depositing a credit on an account associated to a terminal subscribed to a communication network | |
| RU2310995C2 (en) | Method for transferring credit to account connected to terminal which subscribes a communication network | |
| EP1756722A2 (en) | A retail method over a wide area network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |