System and method for pre-paid and pay-per-use internet services

[0001] This application is a continuation of U.S. patent application Ser. No. 09/409,686 filed Sep. 30, 1999, now U.S. Pat. No. ______, issued ______ which is herein incorporated by reference in its entirety.

BACKGROUND

[0002] 1. Field of the Invention

[0003] The present invention relates generally to telecommunications systems. More particularly, the present invention relates to an advanced intelligent network system for Internet service provision on a per-use basis. The present invention also provides pre-paid Internet service connections.

[0004] 2. Background of the Invention

[0005] Over the last ten years, use of the Internet has grown rapidly. A large segment of this growth stems from an increase in individual dial-up subscribers. These dial-up subscribers use the public switched telephone network (“PSTN”) to establish connections to their Internet Service Providers (“ISPs”). In many cases, individual subscribers are required to enter into long-term contractual agreements when they sign up for Internet service. Such long-term agreements are generally required to reduce the ISP's overhead in creating accounts and billing subscribers. However, many subscribers find such long term agreements undesirable.

[0006] Strong competition exists among the many ISPs in the marketplace for acquiring new customers and for retaining existing customers. Subscribers entering the market for ISP services may prefer trying out different ISPs before making a long term commitment to the service. Thus, rather than entering into a long-term agreement with a single ISP, such new customers may desire a system providing access to multiple ISPs on a pre-paid or pay-per-use basis. Similarly, for privacy or security reasons, subscribers may prefer the option of using several different ISPs on a recurring basis. Under the conventional systems and methods for accessing an ISP, a user would have to subscribe to many services, thereby incurring multiple monthly fees to achieve this result. Again, these subscribers may prefer a system providing access to multiple ISPs on a pre-paid or pay-per-use basis.

[0007] One reason such pre-paid or pay-per-use services are not readily available in conventional ISP systems and methods is that the overhead for tracking and billing customers outweighs the benefits of catering to the needs of these customers. Additionally, some ISPs may view such short term arrangements as cutting into their customer base without providing the financial returns to justify the cost. It is commonly known in the art that tracking and billing systems are complex and expensive to operate. To accurately bill customers for units used requires a complex infrastructure of hardware, software and personnel resources. If the monthly bill per subscriber is a low dollar amount, then bill collection procedures may not be cost-effective without additional leverage to encourage payment. For these and similar reasons, ISPs have been reluctant to provide pre-paid or pay-per-use Internet access services. Thus, there remains a need for a system that provides access to multiple ISPs on a pre-paid or pay-per-use basis and does not increase the ISPs' overhead.

[0008] In conventional ISP systems, the PSTN is used merely to connect the caller to the ISP. The PSTN does not verify the caller and does not track the caller's usage of the ISP's resources. FIG. 1 is a schematic diagram illustrating how dial-up subscriber <b>30</b> connects to ISP <b>20</b> using PSTN <b>10</b>. Dial-up subscriber (also referred to as “caller” herein) <b>30</b>, places a call over PSTN <b>10</b> using computer <b>31</b>, modem <b>32</b> and subscriber line <b>33</b>. Within PSTN <b>10</b>, the call is processed by the caller's Service Switching Point (“SSP” or “switch,” herein) <b>11</b> and the ISP's SSP <b>12</b>. To support multiple connections, ISPs must maintain numerous telephone lines connected to modems. Rather than advertising a different telephone number for each telephone line, ISPs generally advertise a limited number of telephone access numbers. Each telephone access number corresponds to one or more telephone lines. These telephone lines may be made up of, e.g., individual POTS lines, one or more T<b>1</b> lines, or Primary Rate ISDN (“PRI”) lines. For simplicity, the figures and discussion herein show the connection to be made up of PRI lines <b>21</b>, as shown in FIG. 1.

[0009] PRI lines <b>21</b> lead to ISP <b>20</b> where they are connected to multi-line hunt group (“MLHG”) <b>22</b> as shown in FIG. 1. MLHG <b>22</b> is modem pool allowing multiple simultaneous connections and is controlled by access server <b>23</b>. MLHG <b>22</b> takes incoming subscriber calls and routes them to the first open modem in the modem pool. When a caller dials the telephone access number for ISP <b>20</b>, from the PSTN's point of view, the call is processed like any other call in PSTN <b>10</b>. That is, the call is routed between the caller and called party (in this case, ISP <b>20</b>) through one or more switches. If ISP <b>20</b>'s lines are all busy, or “off-hook”, i.e., there are no voice communications paths available, the caller gets a busy-signal, which is provided by the PSTN. On the other hand, if lines are available, switch <b>12</b> will terminate the call to ISP <b>20</b> and it is ISP <b>20</b>'s responsibility to answer the call, verify the caller's authorization for access to ISP <b>20</b>, and setup the caller's connection to the Internet.

[0010] From ISP <b>20</b>'s point of view, several intervening steps must be accomplished before granting the caller access to the Internet. When a call reaches ISP <b>20</b> via PRI lines <b>21</b> and MLHG <b>22</b>, access server <b>23</b> answers the call. After answering the call, access server <b>23</b> must determine whether or not the caller should be granted access and if so, to which services. Access server <b>23</b> queries the caller for information such as a username and password for use in identifying the caller and the caller's authorized services. The dialog between the caller and access server <b>23</b> is usually performed automatically between access server <b>23</b> and communications software operating on the caller's computer <b>31</b>.

[0011] Generally, ISPs use centralized servers to store and manage its subscriber databases. Remote Authentication Dial-In User Service (“RADIUS”) server <b>24</b>, having database <b>24</b><i>a, </i>shown in FIG. 1, is functionally connected to access server <b>23</b> and provides this centralized management. Thus, access server <b>23</b> collects username and password information from the subscriber and passes it on to RADIUS server <b>24</b>. After RADIUS server <b>24</b> verifies a subscriber's username and password, it provides access server <b>23</b> with configuration information specific to the caller. Access server <b>23</b> uses the configuration information to provide the authorized services to the caller. Access servers and RADIUS servers are described in more detail in commonly assigned U.S. patent application Ser. No. 09/133,299, which is incorporated herein by reference in its entirety. Additional information on access servers and RADIUS servers may be found in Rigney et al., <i>Remote Authentication Dial</i>-<i>In User Service </i>(<i>RADIUS</i>), Network Working Group, January, 1997, or in Rigney et al., <i>RADIUS Accounting, </i>Network Working Group, April, 1997.

[0012] The conventional system and methods described above pose a further obstacle to providing pre-paid Internet services. As noted above, typically every ISP subscriber is assigned a unique username and password. Typically, the subscriber may change the password, but the username remains fixed to ensure it is unique. The combination of username and password allows for verification to ensure the user has permission (i.e., is an authorized customer) to use ISP <b>20</b>'s services. Pre-paid telecommunications services are desirable in one respect because of the inherent anonymity that may be gained. However, under the current systems and methods, ISPs generally demand some means to track the usage of their resources to a specific account for billing purposes.

SUMMARY OF THE INVENTION

[0013] The present invention is a system and method for providing subscribers with pre-paid and pay-per-use access to multiple Internet Service Providers (“ISPs”). The present invention utilizes an Advanced Intelligent Network (“AIN”) to set up and manage the services as described below. AIN systems are described in U.S. Pat. No. 5,701,301 and U.S. Pat. No. 5,774,533, which are incorporated herein by reference in their entirety. FIG. 2 shows the key components of the AIN used in the present invention. FIGS. 3<i>a </i>and <b>3</b><i>b </i>are flowcharts detailing the steps comprising a preferred embodiment of the present invention. The steps described herein can be performed by computer-readable program code operating on the various AIN components and other computer systems, as described below.

[0014] The present invention is implemented as an AIN service application. At least one telephone access number assigned to each ISP is provisioned with a suitable AIN trigger on the terminating switch. When a user, presumably using a computer and modem, calls a telephone access number having the trigger, the call is temporarily suspended while a database query is processed. The database query is sent from a Service Switching Point (“SSP” or “switch”) to a Service Control Point (“SCP”), which checks to see whether the caller has blocked access to the pay-per-use service, or has an unknown number.

[0015] In a preferred embodiment, if the call is not from a blocked or unknown number, the SCP checks to see if the caller has a pre-paid subscription. If so, the SCP then checks to see whether the caller has some pre-paid units available. In one embodiment, the call is processed as a regular non-pre-paid and non-pay-per-use call if the caller is pre-paid but has no remaining pre-paid units. In an alternative embodiment the call is still processed as a pay-per-use call even when a pre-paid caller has no pre-paid units left.

[0016] In a preferred embodiment, blocked or unknown numbers are not processed by the pre-paid or pay-per-use Internet service. Instead, calls from blocked or unknown numbers are terminated by the ISP's switch without any changes to the call parameters. In this case, the caller must have a valid account with the ISP in order to access the Internet through that ISP. Furthermore, billing for caller's use of the ISP's services are handled by the ISP, not by the telephone network.

[0017] If the caller is a pre-paid or a pay-per-use customer, the SCP changes certain call parameters in the call setup message, as described below, and instructs the SSP to continue processing the call with the new parameters. The SCP further instructs the SSP to inform the SCP if the line was busy, answered or the caller hung up before the call was answered. Additionally, if the call was answered, the SSP notifies the SCP when the call is disconnected. The SCP uses this information to track the subscriber's usage of the system for billing purposes. If the caller was pre-paid, the SCP subtracts the number of units used from the pre-paid units available for the subscriber. If the caller was processed under the pay-per-use system, the charge is calculated by the telephone service provider and included in the caller's telephone bill for the period. Billing techniques for such pay-per-use telephone connections are well known in the art of telephone service providers.

[0018] Authentication of pre-paid and pay-per-user callers is still performed by the ISP's RADIUS server, as described above. However, in the present invention, the SCP generates a transaction identification (“ID”) that serves as a pseudo username and password. The transaction ID is a ten digit number chosen specifically to be an invalid telephone number. The SCP inserts the transaction ID into the calling party number (“CgPN”) field when the SCP instructs the SSP to proceed with call setup. Because such an invalid telephone number can only be placed in the CgPN field by the telephone service provider, the ISP will identify the caller as being billed through the telephone system and not the ISP. When a pre-paid or pay-per-use call is terminated to the ISP's multi-line hunt group, the RADIUS server authorizes connection to the ISP's services because the CgPN is recognized as a transaction ID generated by the SCP.

[0019] It is an object of the present invention to provide Internet access to subscribers on a pre-paid basis as well as on a pay-per-use basis.

[0020] It is a further object of the present invention to use an Advanced Intelligent Network to provide and manage Internet access to subscribers on a pre-paid basis as well as on a pay-per-use basis.

[0021] It is another object of the present invention to provide Internet access to subscribers on a pre-paid basis as well as on a pay-per-use basis without prohibitively increasing overhead for Internet Service Providers.

[0022] It is an object of the present invention to provide an integrated bill to subscribers obtaining access to multiple Internet Service Providers on a pre-paid basis and a pay-per-use basis.

[0023] These and other objects of the present invention are described in greater detail in the detailed description of the invention, the appended drawings and the attached claims.

DESCRIPTION OF THE DRAWINGS

[0024]FIG. 1 is a schematic diagram of the main components of a telephone service provider's network and an Internet Service Provider's network used in establishing a dial-up connection to the Internet in conventional ISP systems.

[0025]FIG. 2 is a schematic diagram of the main components of a telephone service provider's telephone network utilizing a Advanced Intelligent Network and an Internet Service Provider's network used in establishing a dial-up connection according to the present invention.

[0026]FIG. 3<i>a </i>is a flow diagram showing the steps executed in an example illustrating one embodiment of the present invention.

[0027]FIG. 3<i>b </i>is a flow diagram showing the steps executed in an example illustrating another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0028] The present invention utilizes an Advanced Intelligent Network (“AIN”) to provide a system and method for allowing individual users to access multiple Internet Service Providers (“ISPs”) on a pre-paid or pay-per-use basis. Users of the present invention gain access to the ISPs using dial-up telephone connections. FIG. 2 shows the key components of the AIN used in the present invention. Such AIN components include Service Switching Points (“SSPs”) <b>11</b> and <b>12</b>, a Service Control Point (SCP) <b>13</b>, and a Common Channel Signaling System <b>7</b> (“SS7”) data network <b>15</b>. FIG. 2 shows two distinct SSPs, the caller's SSP <b>11</b> and ISP <b>20</b>'s SSP <b>12</b>. The subscriber and ISP could be served by the same SSP, or they could be served by distinct SSPs as shown in FIG. 2. SCP <b>13</b> responds to queries from the SSPs using database <b>13</b><i>a </i>and service package applications (“SPAs”), i.e., software systems running on SCP <b>13</b>.

[0029] Billing services in a preferred embodiment are accomplished using the standard records commonly used in telephone billing systems. Telephone billing systems and records used in AIN systems are described in U.S. Pat. No. 5,774,533, referenced above. Billing records are created by the pay-per-use system of the present invention and are periodically transferred, in aggregate form, to billing system <b>28</b>. Records are transferred from SCP <b>13</b> through Service Management System (“SMS”) <b>29</b> to billing system <b>28</b> via interconnects <b>27</b><i>a </i>and <b>27</b><i>b. </i>Interconnects <b>27</b><i>a </i>and <b>27</b><i>b </i>may use any suitable data transmission protocol, such as TCP/IP. In a preferred embodiment, interconnects <b>27</b><i>a </i>and <b>27</b><i>b </i>employ the X.25 protocol. SMS <b>29</b> and billing system <b>28</b> have databases <b>29</b><i>a </i>and <b>28</b><i>a, </i>respectively. SMS <b>29</b> is used to manage and synchronize service applications and databases within telephone network <b>10</b>. Billing system <b>28</b> is used to generate customer bills on a periodic (usually monthly) basis.

[0030] In addition to the AIN components, FIG. 2 shows gateway server <b>16</b>, which acts as a buffer between the telephone network <b>10</b> of the present invention and the Internet <b>25</b>. (For simplicity, the Internet is labeled as item “<b>25</b>” in FIG. 1, but will only be referred to hereafter as “the Internet” without numeric identification). Gateway server <b>16</b> is connected to ISP <b>20</b> via the Internet through TCP/IP interconnections <b>26</b><i>a </i>and <b>26</b><i>b. </i>Alternatively, gateway server <b>16</b> could be directly connected to ISP <b>20</b> via a private high speed link. ISP <b>20</b> has access server <b>23</b> connected to PRI lines <b>21</b> and RADIUS server <b>24</b> providing user verification and authorization as described above.

[0031] At least one telephone access number assigned to each ISP is provisioned with a suitable AIN trigger. In a preferred embodiment, a Public Office Dialing Plan (“PODP”) trigger is utilized. As is well known in the art, a PODP trigger can be provisioned on either end of the call. That is, the trigger may be on the originating switch or on the terminating switch. When a user, presumably using a computer and modem, calls a telephone access number having the PODP trigger, the call is temporarily suspended while a database query is processed. The database query is issued by the switch where the PODP trigger is actually provisioned, e.g., the terminating switch.

[0032] Examples 1 and 2 below each describe a specific implementation of the present invention. However, the present invention may be implemented using many variations of the sequences described in Examples 1 and 2.

EXAMPLE I

[0033] As shown in FIG. 3<i>a, </i>a subscriber (or caller) accesses the Internet using the pre-paid or pay-per-use system of the present invention by dialing the telephone access number for a given ISP (step <b>100</b>). Each ISP is assigned a different telephone access number, e.g., 222-333-1000 may be assigned to one ISP and 444-444-4000 may be assigned to another. In this example, caller <b>40</b> dials 444-444-4000 using computer <b>41</b> and modem <b>42</b> (shown in FIG. 2). Modem <b>42</b> is connected to subscriber line <b>43</b>, having a telephone number of 222-333-3000 on SSP <b>11</b>. Thus, the Calling Party Number (“CgPN”) is 222-333-3000 and the Called Party Number (“CdPN”) is 444-444-4000. In step <b>110</b>, caller <b>40</b>'s switch, SSP <b>11</b>, sends initial address message (“IAM”) message <b>1</b> over SS7 network <b>15</b> to ISP <b>20</b>'s switch, SSP <b>12</b>. IAM message <b>1</b> is an Integrated Services Digital Network User Part (“ISUP”) message informing SSP <b>12</b> that a caller is trying to place a call to 444-444-4000. As discussed above, a PODP trigger may be provisioned on either the originating or the terminating switch. In the present example, the PODP trigger is provisioned on SSP <b>12</b>. Thus in step <b>120</b>, SSP <b>12</b> initiates database query <b>2</b> to SCP <b>13</b>. Query <b>2</b> is a Transaction Capabilities Application Part (“TCAP”) message transmitted from SSP <b>12</b> to SCP <b>13</b> over SS7 network <b>15</b>. In an alternate embodiment, the PODP trigger is provisioned on SSP <b>11</b>. In this alternate embodiment, SSP <b>11</b> issues the database queries, described herein, prior to sending IAM message <b>1</b> to SSP <b>12</b>.

[0034] In the preferred embodiment shown in FIG. 3<i>a, </i>access to the pre-paid or pay-per-use Internet service of the present invention is available by default, on all subscriber lines. In this preferred embodiment, a subscriber may block access on a temporary or permanent basis by contacting the telephone service provider. In an alternate embodiment, access to the services is denied by default. In this embodiment, subscribers must affirmatively request access from the telephone service provider.

[0035] In step <b>130</b>, SCP <b>13</b> determines the type of call, i.e., whether or not the call is from an unknown or blocked telephone number, or if the call will be billed on prepaid or pay-per-use basis. SCP <b>13</b> looks up the CgPN in database <b>13</b><i>a </i>to make this determination. In a preferred embodiment, database <b>13</b><i>a </i>comprises the line information database (“LIDB”), which is well known in the art. If the number is blocked or unknown, SCP <b>13</b> moves on to step <b>140</b>, described below. If call is from a line having pre-paid access to the Internet service SCP <b>13</b> moves on to step <b>150</b>. Otherwise, if SCP <b>13</b> determines the call should be billed as a pay-per-use Internet call, SCP <b>13</b> moves on to step <b>160</b>.

[0036] Step <b>140</b> is performed if the call is from an unknown number, or a blocked telephone line or if SCP <b>13</b> determines in step <b>150</b> that a pre-paid subscriber has no remaining pre-paid units. In step <b>140</b>, SCP <b>13</b> issues a Continue message to SSP <b>12</b> (response <b>3</b> in FIG. 2). The Continue message contains no changes in the call setup parameters, i.e., the CgPN is still set to 222-444-3000. SSP <b>12</b> then terminates the call to MLHG <b>22</b> and ISP <b>20</b> takes over responsibility for authenticating the user, i.e., ISP <b>20</b>'s RADIUS server <b>24</b> treats the call as a call from an ordinary customer. This is possible because RADIUS server <b>24</b> is programmed to check the CgPN to determine if the call is to be treated as a pre-authorized call, i.e., authorized through the telephone service provider. If RADIUS server <b>24</b> determines that the call is not pre-authorized, it waits for a valid username and password from caller <b>40</b> before allowing access to ISP <b>20</b>'s resources. In a preferred embodiment, when step <b>140</b> is executed, it is the last step performed by the present invention.

[0037] In step <b>140</b>, SCP <b>13</b> optionally issues a Send_to_Resource message and SSP <b>12</b> plays an announcement to caller <b>40</b> before terminating the call. The announcement informs caller <b>40</b> that pre-paid and pay-per-use Internet service is not currently available from caller <b>40</b>'s telephone line. In an alternate embodiment, rather than terminating the call to ISP <b>20</b>, SSP <b>12</b> plays an announcement then disconnects the call.

[0038] For pre-paid Internet calls, SCP <b>13</b> checks the number of pre-paid units available for caller <b>40</b>'s account (step <b>150</b>). The pre-paid units may correspond to the number of minutes allowed, or the number of times the system has been accessed, or some other method for quantifying usage of the pre-paid Internet service. If pre-paid units are available, SCP <b>13</b> moves on to step <b>160</b>, described below. If pre-paid units are not available, SCP <b>13</b> proceeds to step <b>140</b> where the call is processed as a regular call (i.e., not pre-paid and not pay-per-use call) as described above. SCP <b>13</b> may optionally play an announcement informing caller <b>40</b> that no pre-paid units are available, before proceeding to step <b>140</b>.

[0039] If caller <b>40</b> has remaining pre-paid units, SCP <b>13</b> sends a Continue and Termination_Notification messages in response <b>3</b> to SSP <b>12</b> (step <b>160</b>). The Continue message instructs SSP <b>12</b> to proceed with the call setup between caller <b>40</b> and ISP <b>20</b>'s telephone access number. However, SCP <b>13</b> inserts a transaction ID in the CgPN field before issuing the Continue message. As discussed earlier, the transaction ID is a number that cannot represent a true telephone number. The presence of this “erroneous” telephone number in the CgPN field informs RADIUS server <b>24</b> that the call is pre-authorized for access to ISP <b>20</b>'s resources.

[0040] In a preferred embodiment, the transaction ID is formed by replacing the area code of the calling party number with “111.” The area code may be encoded so that the last 2 digits represent the time remaining on the pre-paid account. Other encodings are also possible. Thus in the present example, the new CgPN is set to 111-333-3000, while the CdPN remains unchanged. Under the current telephone networking protocols, “111” is not a valid area code. Of course, the transaction ID could be any other string that notifies RADIUS server <b>24</b> that caller <b>40</b> will be billed through the telephone network and should be granted access to the Internet without further authentication. The Termination_Notification message instructs SSP <b>12</b> to alert SCP <b>13</b> if the line is busy, answered or not answered, and if the call was answered, when that call is eventually disconnected. This allows SCP <b>13</b> to track the usage of the Internet service by caller <b>40</b>.

[0041] In step <b>180</b>, SSP <b>12</b> terminates the call to ISP <b>20</b> over PRI lines <b>21</b> and informs SCP <b>13</b> when the call is answered by access server <b>23</b>. In the present example, access server <b>23</b> is programmed transmit the calling party number to RADIUS server <b>24</b>. In step <b>185</b>, RADIUS server <b>24</b> checks the CgPN received from access server <b>23</b> and authorizes access to ISP <b>20</b>'s services if the special code has been appended to a portion of the CgPN. If the CgPN does not contain the special code, RADIUS server <b>24</b> treats the call as a normal call to ISP <b>20</b>. In that case, RADIUS server <b>24</b> waits for caller <b>40</b> to transmit a username and password as previously described.

[0042] In step <b>190</b>, SSP <b>12</b> notifies SCP <b>13</b> when the call is disconnected. In step <b>200</b>, SCP <b>13</b> again determines the type of caller so that caller <b>40</b> can be correctly billed for the call. If caller <b>40</b> is a pre-paid user of the service, then SCP <b>13</b> subtracts the number of units used in from the subscriber's pre-paid units stored in database <b>13</b><i>a </i>(step <b>210</b>). If caller <b>40</b> is a pay-per-use user of the service, then SCP <b>13</b> generates a billing record for caller <b>40</b>'s telephone number (step <b>220</b>). Billing records are transferred at regular intervals, preferably once per day, between SCP <b>13</b> and SMS <b>29</b> and billing system <b>28</b>. Billing system <b>28</b> generates a monthly bill for caller <b>40</b>, including all charges for the units used in the pay-per-use Internet service.

EXAMPLE II

[0043] This example uses many of the same steps as Example I. However, in this example, SCP <b>13</b> sends a message to RADIUS server <b>24</b> informing RADIUS server <b>24</b> of caller <b>40</b>'s transaction ID. This allows enhanced security of the system because RADIUS server <b>24</b> can verify the transaction ID prior to granting access to ISP <b>20</b>'s resources. As shown in FIG. 3<i>b, </i>steps <b>100</b> through <b>150</b> are identical to the like-numbered steps from Example I (shown in FIG. 3<i>a</i>). A new step <b>160</b>A replaces step <b>160</b> as follows: instead of changing the actual CgPN by including a special code to identify the call as a pre-authorized user, SCP <b>13</b> generates a unique transaction ID, and inserts the transaction ID in place of the actual CgPN.

[0044] In new step <b>175</b>, SCP <b>13</b> transmits the transaction ID to RADIUS server <b>24</b>. This message is transmitted via gateway server <b>16</b> through the Internet to RADIUS server <b>24</b>. After the call is connected in step <b>180</b>, RADIUS server <b>24</b> checks all incoming calls to see if the CgPN of the incoming call matches the transaction ID in new step <b>182</b>. In new step <b>184</b>, if the CgPN matches the transaction ID, RADIUS server <b>24</b> moves on to steps <b>185</b> through <b>220</b>, as described in Example I above. Otherwise, if the CgPN does not match the transaction ID, RADIUS server <b>24</b> moves on to step <b>140</b>, and treats the call as a normal call to ISP <b>20</b>, as described above.

[0045] The foregoing disclosure of embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many variations and modifications of the embodiments described herein will be obvious to one of ordinary skill in the art in light of the above disclosure. The scope of the invention is to be defined only by the claims appended hereto, and by their equivalents.