systems and methods for processing rebates for a telecommunication subscriber are disclosed herein. Call detail records, related to telecommunication service activity by the telecommunication subscriber, are obtained for a previous billing period. Based on the call detail records, the service cost under a current rate plan is calculated and hypothetical service costs are calculated had the telecommunication subscriber been subscribed under other available rate plans. Then, a rebate is provided to the subscriber based on at least one rate plan that is less expensive than the current rate plan.
|
15. A business method comprising:
obtaining, in a computing system, call detail records related to telecommunication service activity by a telecommunication user during a plurality of previous billing periods;
calculating, in the computing system and on the basis of the call detail records, a service cost under a current rate plan and hypothetical service costs under one or more other available rate plans;
determining, in the computing system, a most cost effective service plan available to the telecommunication user based at least upon the call detail records for the previous billing periods, the most cost effective service plan being determined by calculating a plurality of hypothetical service costs for the previous billing periods for a plurality of available rate plans and determining a most efficient service plan for a plurality of previous billing periods, the hypothetical service costs and the service cost being weighted by applying a weighting function that discounts earlier billing periods relative to recent billing periods associated with the telecommunications user, the weighting function being an exponential envelope, the most cost effective service plan determined by identifying the hypothetical service plan with a highest efficiency measure for the previous billing periods based upon the call detail records; and
providing a rebate based on a difference between the most cost effective service plan and the current rate plan.
21. A computer program stored on a computer-readable medium, the computer program comprising:
logic configured to calculate the service cost of a plurality of telecommunication rate plans, one telecommunication rate plan including a current rate plan to which a telecommunication service user subscribes;
logic configured to determine a most cost effective service plan available to the telecommunication user based at least upon call detail records for previous billing periods associated with the telecommunication user, the most cost effective service plan being determined by calculating a plurality of hypothetical service costs for the previous billing periods for a plurality of available rate plans and determining a most efficient service plan for a plurality of previous billing periods, the hypothetical service costs and the service cost being weighted by applying a weighting function that discounts earlier billing periods relative to recent billing periods associated with the telecommunications user, the weighting function being an exponential envelope, the most cost effective service plan determined by identifying the hypothetical service plan with a highest efficiency measure for the previous billing periods based upon the call detail records; and
logic configured to provide a rebate to the telecommunication service user based on the service cost of at least one telecommunication rate plan that is less expensive than the current rate plan.
5. A method for generating a rebate comprising:
obtaining, in a computing system, call detail records related to telecommunication service activity by a telecommunication user during a plurality of previous billing periods;
calculating, in the computing system and on the basis of the call detail records, a service cost under a current rate plan and hypothetical service costs under one or more other available rate plans;
determining, in the computing system, a most cost effective service plan available to the telecommunication user based at least upon the call detail records for the previous billing periods, the most cost effective service plan being determined by calculating a plurality of hypothetical service costs for the previous billing periods for a plurality of available rate plans and determining a most efficient service plan for a plurality of previous billing periods, the hypothetical service costs and the service cost being weighted by applying a weighting function that discounts earlier billing periods relative to recent billing periods associated with the telecommunications user, the weighting function being an exponential envelope, the most cost effective service plan determined by identifying the hypothetical service plan with a highest efficiency measure for the previous billing periods based upon the call detail records; and
providing a rebate based on a difference between the most cost effective service plan and the current rate plan.
1. A system for processing rebates comprising:
means for receiving call detail records related to telecommunication service activity by a telecommunication user during a plurality of prior billing periods;
means, in response to the call detail records, for calculating the service cost of the telecommunication service activity during said prior billing periods, the service cost calculating means calculating the service cost on the basis of a current rate plan, said calculated service cost of the prior billing periods being weighted by applying a weighting function, the weighting function discounting earlier billing periods relative to recent billing periods, the weighting function being an exponential weighting envelope;
means, in response to the call detail records, for calculating hypothetical service costs of the telecommunication service activity during said prior billing periods had the telecommunication user been on one or more different available rate plans, said calculated hypothetical service costs being weighted by applying the weighting function;
means, in response to the service cost calculated by the service cost calculating means and the hypothetical service costs calculated by the hypothetical service costs calculating means, for determining a most efficient service plan for the telecommunication user by calculating an efficiency measure based at least upon the hypothetical service costs and the service cost during the prior billing periods;
means, in response to determining the most efficient service plan for the telecommunication user, for calculating a rebate based on a comparison between the service cost and a cost of the most efficient service plan; and
means for crediting the rebate to the telecommunication user.
2. The system of
3. The system of
4. The system of
6. The method of
7. The method of
8. The method of
determining, in the computing system, a cost comparison value to which the service cost of the current rate plan is compared, wherein the cost comparison value is a cost of the most cost effective service plan;
calculating, in the computing system, a difference between the service cost of the current rate plan and the cost comparison value; and
detuning, in the computing system, the difference to obtain a rebate value.
9. The method of
10. The method of
11. The method of
12. The method of
14. The method of
16. The business method of
17. The business method of
18. The business method of
19. The business method of
20. The business method of
22. The computer program of
23. The computer program of
24. The computer program of
logic configured to determine a cost comparison value to which the service cost of the current rate plan is compared, the cost comparison value being the most cost effective service plan;
logic configured to determine a difference between the cost comparison value and the service cost of the current rate plan; and
logic configured to detune the difference.
25. The computer program of
26. The computer program of
27. The computer program of
|
This application is a continuation-in-part application of U.S. patent application Ser. No. 09/758,815, filed Jan. 11, 2001, now U.S. Pat. No. 7,184,749 and entitled “System and Method for Analyzing Wireless Communication Data,” which claims the benefit of U.S. Provisional Application No. 60/230,846, filed on Sep. 7, 2000, and entitled “System and Method for Analyzing Wireless Communications Records and for Determining Optimal Wireless Communication Service Plans,” both of which are incorporated by reference herein in their entirety.
The present invention is generally related to wireless telecommunication, and, more particularly, is related to a system and method for analyzing wireless communication data to enable the determination of an optimal wireless communication service plan.
Because immediate access to information has become a necessity in virtually all fields of endeavor, including business, finance and science, communication system usage, particularly for wireless communication systems, is increasing at a substantial rate. Along with the growth in communication use has come a proliferation of wireless communication service providers. As a result, a variety of wireless communication service alternatives have become available to consumers and businesses alike.
Subscribers to communication services, particularly wireless communication services, and the businesses that may employ them, who are dissatisfied with the quality of service or the value of the service provided by a particular provider, may terminate their current service and subscribe to a different service. Unfortunately, due to the vast number of communication service providers available, it is difficult to determine an optimal service plan, as well as optional service packages. In addition, due to the competitive nature of the wireless communication field, the cost and options made available with service plans frequently change, adding to the difficulty of finding the most optimal service plan available at a specific time.
Thus, a heretofore unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.
Systems and methods for determining optimal wireless communication service plans are disclosed herein. Generally, the system uses at least one transceiver that is configured to receive billing information associated with a subscriber of a telecommunications service under a current rate plan that is stored in a storage unit. A processor is also used by the system which is configured to: process the subscriber related billing information to produce organized data in a calling profile record for each telecommunication service being used by the subscriber; create a usage history table and a call detail table within the storage unit from the processed billing information; analyze the processed data in relation to at least one rate plan of at least one telecommunication service provider; determine at least one proposed rate plan that would save the subscriber telecommunication costs relative to the current rate plan, via use of the usage history table and call detail table; and, produce a report of the at least one proposed rate plan to enable selection of a best telecommunication service provider and a best rate plan.
A method for analyzing wireless communication records and for determining optimal wireless communication service plans is also disclosed. In this regard, the method can be broadly summarized by the following steps: receiving billing information associated with a subscriber of a telecommunication service under a current rate plan; processing the subscriber related billing information to produce organized data in a calling profile record for each telecommunication service being used by the subscriber; creating a usage history table and a call detail table from the processed billing information; analyzing the processed data in relation to at least one rate plan of a plurality of at least one telecommunication service provider; determining at least one proposed rate plan that would save the subscriber telecommunication costs relative to the current rate plan, via use of the usage history table and call detail table; and producing a report of the at least one proposed rate plan to enable selection of a best telecommunication service provider and a best rate plan.
One advantage of the invention is that it automatically provides a subscriber with the best telecommunication service provider and the best rate plan without necessitating unnecessary subscriber interaction.
Another advantage is that it improves the quality of service and the value of the telecommunication services received by a subscriber.
Other additional systems, methods, and business methods are disclosed for providing a rebate to a telecommunication user when other available rate plans are calculated to be more cost-effective than the rate plan that is currently being used. One such method, among others, includes comparing a service cost for telecommunication service usage under a current rate plan with a hypothetical service cost had the telecommunication service usage been contracted under one or more other rate plans. Based on this comparison, a rebate is provided to the telecommunication user. As an example, the rebate may be in the form of a retroactive upgrading of a user to a more cost-effective plan, a credit to the user's account, a check sent to the user's billing address, and/or a coupon or gift certificate toward the purchase of merchandise or services.
Other systems, methods, features, and advantages will become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description and protected by the accompanying claims.
The invention can be better understood with reference to the following drawings. Like reference numerals designate corresponding parts throughout the several views.
The moving average monthly bill analysis (MAMBA) system 100, as is structurally depicted in
Note that the MAMBA system 100, when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM or Flash memory) (magnetic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory. As an example, the MAMBA system 100 software may be magnetically stored and transported on a conventional portable computer diskette.
By way of example and illustration,
Alternatively, instead of implementing the MAMBA system 100 via use of the Internet, the MAMBA system 100 may also be implemented via use of a first transmitting and receiving device such as, but not limited to, a modem located at a customer premises, which is in communication with a second transmitting and receiving device such as, but not limited to, a modem located at a central office. In accordance with such an embodiment, personal computers may be located at the customer premises and the central office having logic provided therein to perform functions in accordance with the MAMBA system 100.
Referring to
The host processor, or server, 31 is coupled to a communication line 41 that interconnects or links the networks 21A, 211B to each other, thereby forming an Internet. As such, each of the networks 21A, 21B are coupled along the communication line 41 to enable access from a digital processor 33a, 35a, 37a of one network 21A to a digital processor 33b, 35b, 37b of another network 21B.
A client server 51 is linked to the communication line 41, thus providing a client with access to the Internet via a client digital processor 53, as further described hereinbelow. In accordance with the preferred embodiment of the invention, the software for implementation of the MAMBA system 100 is provided by a software program that is operated and located on an analyzing digital processor 71, and connected through an analyzing server 61, to the communication line 41 for communication among the various networks 21A, 211B and/or digital processors 33, 35, 37 and the client connected to the Internet via the client server 51.
It should be noted that the number of client servers, client digital processors, analyzing digital processors, and analyzing servers may differ in accordance with the number of clients provided for by the present MAMBA system 100. As an example, if five separately located clients were utilizing the MAMBA system 100, five separate client digital processors may be connected to a single client server, or five separate client servers.
In accordance with the preferred embodiment of the invention, the client digital processor 53 may be any device, such as, but not limited to, a personal computer, laptop, workstation, or mainframe computer. Further, the networks used by the MAMBA system 100 are preferably secure and encrypted for purposes of ensuring the confidentiality of information transmitted within and between the networks 21A, 21B.
The analyzing digital processor 71, further depicted in
Several embodiments of the analyzing digital processor 71 are possible. The preferred embodiment of analyzing digital processor 71 of
Referring to
As shown by block 120, data regarding a given cellular account, subscriber, or group of subscribers if the service is provided for a corporate customer, is provided by a carrier. As shown by block 130, the data is loaded into the analyzing digital processor database 74 by a dataloader process 320 (shown in
The MAMBA system 100 can be offered on an application service provider (ASP) basis to telecommunication personnel at the customer premises, or to purchasing or other appropriate managers or administrators of wireless services at corporations, government agencies and/or similar organizations as a “cost assurance” tool. The MAMBA system 100 assures that all of the wireless accounts or subscribers under the management or control of administrators are on the best possible service plan, given their specific usage profile trends, and therefore minimizes overall expenditures for wireless services by the enterprise.
The MAMBA system 100 is an extension of the existing “one user at a time” Hypertext Markup Language (HTML)-based profiler application, which takes as input from an individual account or subscriber, via an HTML or Web-based interface, an interactively constructed user-defined profile, i.e., how many minutes of airtime a user may consume according to the three “W's” that, combined, bound the mobile calling environment: “When” (peak, off-peak, or weekend), “What” (local or toll), and from “Where” (home market or non-home market) the call is made. This calling profile, entered via the profiler HTML page, is then provided as input to an analysis component labeled an “optimator,” which provides as output the best set of possible service plans, including optional packages, promotions, etc., based upon the entered calling profile. The results are presented to the user in the same HTML/Web-based format.
Several embodiments of a profiler application 200 are possible. By way of example, the flow of logic comprising one possible embodiment of the profiler application 200 is shown in
The bus_Account putProfile function 210 is connected to an optimator doEval function 250 and to service plan (SP) instances 260, 270 via the inc_plan_loading.asp function 205, which presents the usage profile information stored via the dbAccount putProfile function 215 to the optimator doEval function 250.
The optimator doEval function 250 then presents a list of user-provided ZIP codes, symbolic of where the user can purchase service (at least their home zip code and possibly one or more zip codes of locations for the user's place of employment) from the user profile, to an optimator findPackages function 225. The optimator findPackages function 225 is, in turn, connected to an SPPackage getPackagesByZIP function 220 which determines which wireless service plan packages are offered within the user provided ZIP codes. The SPPackage getPackagesByZIP function 220 then presents these wireless service plan packages to the optimator doEval function 250 via the optimator findPackages function 225. The optimator doEval function 250, in turn, presents the plan packages and the user profile information to an optimator calcCosts function 235 which then calls an SPPackage calcCost function 230 to calculate and organize, from lowest cost to highest cost, the cost of each service plan package combination for the given user usage profile. The cost information is then presented to the optimator doEval function 250 which uses an optimator createEvaluation function 245 and a dbOptimator putEvaluation function 240 to write the resulting evaluations, which represent comparison of the user usage profile to available service plans, to a database.
Finally, the optimator doEval function 250 utilizes a combination of an SPInstance getEvalID function 255, an SPInstance getEval function 260, a dbInstance getSPInstance function 265 and an SPInstance getSPInstance function 270 to present the results to the user via the inc_plan_loading.asp function 205.
The MAMBA system 100 extends the ad hoc profiler application 200 into a multi-account or subscriber-automated and recurring process that provides an analysis of periodically loaded wireless service usage of a given account or subscriber, and/or group of accounts or subscribers (e.g., a set of subscribers all employed by the same company and all subscribing to the same carrier), and determines whether or not that subscriber, or group of subscribers, is on the optimal wireless service plan according to the particular subscriber's usage patterns across a variable number of service billing periods. If not, the MAMBA system 100 suggests alternative cellular service plans that better meet the users' usage patterns and that reduce the overall cost of service to the account/subscriber.
The DL process 320 makes use of two text files, namely, a “Map” file 440 and a “Visual Basic, Scripting Edition (VBS)™” file 450, to flexibly define or control the configuration of the data import process. The “Map” file 440 dictates to the DL process 320 how to map incoming data fields to destination data fields. The “VBS” file 450 is used by the DL process 320 to perform any custom transformations of input data before writing it to a destination, e.g., get dow_id from day_of_week. The Map 440 and VBS files 450 are developed as part of the data conversion process undertaken whenever new input data formats are presented by a customer base or carrier relationship base.
The DL process 320 is used to import initial customer data as well as to import ongoing call detail data. In one implementation of the invention, each of these data loads has a “base” set of user-provided data existing in a destination database, such as, for example, the local database 74 located within the analyzing digital processor 71 of
TABLE 1
Data Tables that Exists in Database Prior to Running the DL Process
ACCESSORY_ITEMS
ACCESSORY_PRODUCT_LINK
ACTIVITY
ACTIVITY_LINK
ADDRESS
ADDRESS_TYPE
BTA
CARRIER
CARRIER_ADDRESS_LINK
CARRIER_CONTACT_LINK
CARRIER_DBA
CONTACT
CONTACT_TYPE
COUNTY
COVERAGE_AREA_BTA_LINK
COVERAGE_AREA_MRSA_LINK
DB_HISTORY
FCC_CELL_LICENSE
FCC_PCS_LICENSE
LERG_FOREIGN
LERG_US
MRSA
MTA
MTA_MRSA_LINK
NATION
PHONE_ITEMS
PHONE_PRODUCT_LINK
PRODUCT_BUNDLE_ITEMS
PRODUCT_FAMILY
PRODUCT_INFO_STATUS_TYPE
REQUEST_STATUS
REQUEST_TYPE
SERVICE_PLAN
SERVICE_PLAN_STATUS_TYPE
SP_FEATURE
SP_FEATURE_BUNDLE
SP_FEATURE_BUNDLE_LINK
SP_FEATURE_TYPE
SP_PACKAGE
SP_PACKAGE_COVERAGE_LINK
SP_PACKAGE_TYPE
SP_PHONE_ITEM_LINK
SP_TAX
STATE
STATE_MTA_LINK
TECHNOLOGY_TYPE
USERINFO_STATUS_TYPE
ZIP_CODE
The initial customer data load may then be loaded within the tables shown in Table 2.
TABLE 2
Data Tables into which Customers Initially Load Data
ACCOUNT
ACCOUNT_ADDRESS_LINK
ADDRESS
ADDRESS
CLIENT
CLIENT_ADDRESS_LINK
DEPARTMENT
PHONE_ITEMS
REQUEST_LOOKUP
TELEPHONE
USAGE_HISTORY
USER
In accordance with one embodiment of the DL process 320, in the ongoing call detail data load the initial customer load may be completed prior to the running of the DL process 320. The ongoing call detail load may load data into the following tables shown in Table 3.
TABLE 3
Data Tables into which Customers May Load Ongoing Call Detail
CALL_DETAIL
PACKAGE_INSTANCE
SERVICE_PLAN
SERVICE_PLAN_INSTANCE
SP_PACKAGE
The call_detail table shown in Table 3 contains the minimum set of information provided by the wireless providers detailing calls made which can be reduced into a single calling_profile by the buildProfile process 350. The layout of the call_detail table is shown in Table 4.
TABLE 4
Layout of Call_detail Table
Field Name
Data Type
Call_detail_id
Integer
Usage_id
Integer
billing_period
Datetime
mkt_cycle_end
Datetime
invoice_number
Varchar
billing_telephone_number
Varchar
originating_date
Datetime
originating_time
Varchar
originating_city
Varchar
originating_state
Varchar
terminating_number
Varchar
call_duration
Decimal
air_charge
Money
land_charge
Money
Surcharge
Money
Total
Money
user_last_updt
Varchar
tmsp_last_updt
Datetime
dow_id
Integer
It should be noted that the dow_id field, as well as other fields, may contain a numerical representation of data to be inputted within a field, such as, instead of text for the day of the week that a call was placed, using 1=Sunday, 2=Monday, etc.
Operation of DataLoader Process
In accordance with the preferred embodiment of the invention, the DL script process includes the following steps. As shown by block 324, the DL script process is first started. Parameters are then retrieved from the dataloader process 320 application, as shown by block 325. As shown by block 326, the user's authorization is then checked in order to run the dataloader process 320 application. As shown by block 327, all pre-process SQL scripts are then executed to check the integrity/validity of the data and to otherwise put the data into the appropriate format for data transformation. Data transformation services (DTS) 328 are then used to load the pre-processed data. As shown by block 329, all post-process SQL scripts are then executed to confirm the integrity/validity of the data, after which the DL script is exited (block 331).
After the DL script process 323 is run, the DL process 320 selects a wireless service provider, or carrier, provided customer account and related (e.g., usage history) data 332. The DL script process is then run again 333, after which the DL process 320 selects “CallDetail Data” 334. As shown by block 335, the DL script process once again runs, after which the DL application ends block 336.
Build Profile Process
The following further illustrates the build profile process 350 with reference to
The calling_profile record 360 is created by the buildProfile process 350. This record is used by the optimator process 370, which provides a service plan comparison and generates a list of potential service plans that may better fit the account or subscriber's particular calling profile. The calling_profile record 360 contains the fields and source data shown in Table 5.
TABLE 5
Fields and Source Data Contained in calling_profile Record
Field Name
Data Type
Len
Source data
profile_id
Integer
IDENTITY field
account_id
Integer
from the user/account record
date_created
DateTime
current date
billing_period
DateTime
contains the billing period
periods_averaged
Integer
contains the number of
periods averaged for
this record.
monthly_minutes
Integer
sum of all minutes for a
month
peak_percentage
Decimal
buildProfile process
offpeak_percentage
Decimal
buildProfile process
local_percentage
Decimal
buildProfile process
home_zip
Varchar
20
From the user/address record
corp_zip
Varchar
20
From the user/client/address
record
alt_zip1
Varchar
20
buildProfile process
alt_zip2
Varchar
20
buildProfile process
alt_zip3
Varchar
20
buildProfile process
alt_zip4
Varchar
20
buildProfile process
home_zip_percentage
Decimal
buildProfile process
corp_zip_percentage
Decimal
buildProfile process
alt_zip1_percentage
Decimal
buildProfile process
alt_zip2_percentage
Decimal
buildProfile process
alt_zip3_percentage
Decimal
buildProfile process
alt_zip4_percentage
Decimal
buildProfile process
total_calls
Integer
buildProfile process
total_rejected_calls
Integer
buildProfile process
user_last_updt
Varchar
20
Username of person creating
record
tmsp_last_updt
DateTime
Current date
The originating_city and originating_state from each call_detail record 340 may be used to determine the originating postal_code from the zip_code table. This process results in some degree of approximation because of the different methods employed by the carriers to input the destination_city information, e.g. Kansas_cit for Kansas City. However, using both the originating_city and originating_state minimizes the chances of selecting the wrong city, e.g., avoiding selecting Austin, Pa. instead of Austin, Tex., because of including the originating_state in this process.
All calls not made from either the home or corporate zip code are separated by originating_city, originating_state zip code and the total number of minutes added for each. Once calls have been separated into separate zip codes, using one implementation of the buildProfile process 350, if there are four or fewer zip codes, the zip codes may be written to the zip code fields, e.g., alt_zip1, alt_zip2, alt_zip3 and alt_zip4, in descending order by the amount of minutes for each zip code and the corresponding minutes, as a percentage of the total, may be written to the corresponding zip code percentage fields, e.g., alt_zip1_percentage, alt_zip2_percentage, alt_zip3_percentage and alt_zip4_percentage.
However, in this particular implementation, if there are more than four zip code sets, the zip code with the highest number of minutes is written to alt_zip 1. Then the remaining zip codes are grouped by combining zip codes with the same first 3 digits, e.g., 787xx, and adding up the associated minutes.
Once this grouping has been completed, and if there are more than three groupings in this implementation, the zip code from the grouping with the highest number of minutes is added to alt_zip2. The remaining zip codes may then be grouped by combining zip codes with the same first two digits, e.g., 78xxx, and adding up the associated minutes.
Once this grouping has been completed, and if there are more than two groupings in this implementation, the zip code from the grouping with the highest number of minutes is added to alt_zip3. The remaining zip codes may then be grouped by combining zip codes with the same first digit, e.g., 7xxxx, and adding up the associated minutes. Once this grouping has been completed, the zip code with the highest number of minutes may be added to alt_zip4.
Once completed, the percentages may be computed from the total number of minutes and written to each zip code percentage field, including the home_zip_percentage and corp_zip_percentage fields. The periods_averaged field of the buildProfile process 350 contains the number of periods averaged to create this record. Records that are created by the buildProfile process 350 contain a value of 1 in this field. Records created by the “AvgProfilesByClient” or the “AvgProfilesByAccount” functions contain the number of profile records found for the given client or account with a billing period during the given dates. However, this value may be decremented due to the fact that the user has changed home market during that time frame.
Operation of BuildProfile Process
Data “Bucketizing” Functions
The data “bucketizing” functions, previously mentioned with reference to the buildProfile process 350 portion of
The recommendations are created as records in the service_plan_instance 390 and package_instance tables 710. These records are linked to the associated account by a record in the rate_plan_evaluation table 380 which, in turn, is associated with the specific billing period associated with the calling_profile record. The optimator process 370 returns the identification of this new record.
Operation for Creating Rate Plan Evaluations
Averaging Profiles
AvgProfilesByClient and avgProfilesByAccount (see “The MAMBA Component”) methods (
The decidePlan Process
Returning to
The decidePlan process 400 is based upon what can best be described as a “historical prediction” algorithm. Given the fundamental complexity of determining the optimal service plan solution set, the application of a traditional trend-based predictive methodology, e.g., a linear or other form of extrapolation, is not practical. Rather, the decidePlan process 400 leverages the “hindsight” intrinsic to a series of historical single period optimator 370 analyses in order to predict the optimal solution looking forward.
The decidePlan process 400 takes advantage of the “reactive system” type of behavior that is inherent in the analysis or decision process for selecting the optimal plan for a given subscriber. Specifically, the decision engine 400 calculates the total cost for a given set of optimator 370 generated service_plan_instances 390 over a known set of historical periods. The decidePlan process 400 then compares this total cost to the optimator 370 results of the corresponding service_plan_instances 390 for the most recent single period available, and on that basis predicts the optimal service plan going forward.
The known set of historical optimator 370 results is referred to herein as the “training set,” while the single most recent set of period results is referred to as the “test set”, where the test set period can also be included as part of the training set. An optimal service plan solution is selected from the training set and then compared to the result of the test set to determine how well the training set would have predicted the test set result. In implementing the training and test set, the data set to execute the historical prediction analysis is preferably a minimum of two periods, two periods for the training set and one period for the test set, in order to execute the historical prediction.
The relative attractiveness of a service plan instance 390 is determined by comparing it to the corresponding actual billed usage of the current service plan for the given period(s). The specific measure, termed “efficiency”, is calculated as the following ratio:
efficiency=current plan costs/service plan instance estimated cost
If the efficiency factor is greater than 1, then the service plan instance is more cost effective than the current plan. Among a group of service plan instances, the plan instance with the highest efficiency factor is the optimal solution.
Implementation of the historical prediction analytic and decision-making model is best demonstrated by way of example. Table 6 shows an exemplary two period set of optimator 370 results for a single subscriber.
TABLE 6
Example of Historical Prediction Model for a Two Period Set
of Results
Efficiency
Efficiency
Training Set
(Current/
Test Set
(Current/
Month 1
Plan X)
Month 2
Plan X)
Calling
200
250
Profile
MOUs
PLANS
A
$50
1.38
$50
1.38
B
$65
1.06
$65
1.06
C
$40
1.73
$45*
1.53*
D
$60
1.15
$60
1.15
E
$30*
2.30*
$45
1.53*
Current
$69
1.00
$69
1.00
Where * indicates the lowest cost plan option
Based upon this minimum two period data set, the training set predicts plan E as the optimal choice, a selection confirmed by the corresponding results for the test set (Month 2).
The larger the data set, where larger is measured by the number of periods of service plan instance results available for the training set, the better the forward looking “prediction” will likely be. Table 7 shows the same two period data set presented earlier in Table 6, extended by an additional four periods, for a total of six periods, with five applied to the training set and one to the test set.
TABLE 7
Example of Historical Prediction Model for a Six Period Set of Results
Training Set
Training
Sum
Set
Mon 6
Mon 1
Mon 2
Mon 3
Mon 4
Mon 5
1-5
efficiency
Mon 6
Efficiency
Calling
200
250
300
260
310
225
Profile
MOUs
PLANS
A
$50
$50
$60
$60
$62
$282
1.22
$50
1.38
B
$65
$65
$65
$65
$65
$325
1.06
$65
1.06
C
$40
$45
$50
$46
$52
$233*
1.48*
$42
1.64
D
$60
$60
$60
$60
$62
$302
1.14
$60
1.15
E
$30
$45
$60
$48
$62
$245
1.41
$37*
1.86*
Current
$69
$69
$69
$69
$69
$345
1.00
$69
1.00
Where * indicates the lowest cost plan option
In this case, use of only the most recent period's, month 6, optimator 370 output would have resulted in the selection of plan E as the optimal service plan option for this user or account. However, applying the historical prediction analysis, the total of 1-5 ranked by efficiency factor, the optimator 370 output indicates that plan C would be optimal choice for this user. Although plan E would have been the best option in for the most recent period, month 6, when the variability of this subscriber's usage profile is taken into account over the available six period data set, plan C would have been selected as the superior solution.
The above analysis assumes that the data in the test set has equal “value” in the analysis. In reality, the more recent the data set, or the “fresher” the data, the more relevant it is to the analysis as it reflects the more recent behavior of the user. Thus, the use of a weighting strategy which gives greater relevance to more current, fresher data as compared to the older, more stale data, improves the predictive results. Optionally, the weighing strategy can be added to the decidePlan process if needed to provide such increase relevance to more recent data.
There are a number of possible weighting functions that can be applied. One possible weighting function would be an exponential envelope of the type:
weighting factor=n+e(1−Period) where n>=0
The weighting functions for n=0, n=0.5, n=1 and n=2 are plotted in
Applying these two versions of exponential weighting envelopes to the previous six periods of training and test data sets generates the result set shown in Table 8, with the original “equal weighting” results shown as well for reference.
TABLE 8
Results of Table 7 Data After Applying the Weighting Factor
Training Set
Sum
Training Set
Mon 6
Mon 1
Mon 2
Mon 3
Mon 4
Mon 5
1-5
efficiency
Mon 6
Efficiency
Calling
200
250
300
260
310
225
Profile
MOUs
PLANS
A
$50
$50
$60
$60
$62
$282
1.22
$50
1.38
B
$65
$65
$65
$65
$65
$325
1.06
$65
1.06
C
$40
$45
$50
$46
$52
$233*
1.48
$42
1.64
D
$60
$60
$60
$60
$62
$302
1.14
$60
1.15
E
$30
$45
$60
$48
$62
$245
1.41
$37*
1.86*
Current
$69
$69
$69
$69
$69
$345
1.00
$69
1.00
Weighting
1.02
1.05
1.14
1.37
2.00
Factor
n = 1
PLANS
A
$51
$53
$68
$82
$124
$378
1.20
$50
1.38
B
$66
$68
$74
$89
$130
$428
1.06
$65
1.06
C
$41
$47
$57
$63
$104
$312*
1.46*
$42
1.64
D
$61
$63
$68
$82
$124
$399
1.14
$60
1.15
E
$31
$47
$68
$66
$124
$336
1.35
$37*
1.86*
Current
$70
$72
$79
$95
$138
$454
1.00
$69
1.00
Weighting
0.02
0.05
0.14
0.37
1.00
Factor
n = 0
PLANS
A
$1
$3
$8
$22
$62
$96
1.13
$50
1.38
B
$1
$3
$9
$24
$65
$103
1.06
$65
1.06
C
$1
$2
$7
$17
$52
$79
1.38*
$42
1.64
D
$1
$3
$8
$22
$62
$97
1.13
$60
1.15
E
$1
$2
$8
$18
$62
$91
1.20
$37*
1.86*
Current
$1
$3
$10
$26
$69
$109
1.00
$69
1.00
Where * indicates the lowest cost plan option
Although the result of the historical prediction analysis in this specific scenario does not change per se as a result of applying either weighting scheme to the training set, where both the n=1 and n=0 weightings identify Plan C as the optimal plan, the application of these two weighting envelopes do have the effect of increasing the “spread” between the efficiency factor of the optimal plan, plan C, as compared to the next best solution, plan E. This is compared against the actual cost because the weighting function that more heavily favors recent or fresher data, i.e., the n=0 exponential decay envelope, provides a greater efficiency spread (1.38-1.20, or 0.18) compared to the n=1 weighting function that less aggressively discounts older or more “stale” data (1.46-1.35 or 0.11).
The methodology, historical prediction with time-based weighting, described thus far does not take into account the intrinsic period-to-period variability in the user or account's behavior. One way this variability is reflected is by the user's usage of the account, as measured by the minutes of wireless service use on a period-by-period basis. By measuring the standard deviation in a usage set for the user or account, and comparing it to per period usage data, the suitability of the data set for each period can be assessed relative to the total available array of periodic data sets. In particular, a significant “discontinuity” in a usage pattern of a user or account, for example, as a result of an extraordinary but temporary amount of business travel, especially if such a spike occurs in a current or near-current data period, could skew the results of the analysis and provide a less-than-optimal service plan solution or recommendation on a going-forward basis.
To appreciate the potential impact of period-to-period deviations, consider for example two calling profiles arrays: one for the baseline data set that has been examined thus far, and another for a more variable data set. These two data sets, their average and standard deviations and the deviations of the usage profile of each period to the average, are shown in Table 9.
TABLE 9
Comparison of Baseline and Variable Data Sets
Training Set
Test Set
1-5
1-5
1-6
1-6
Mon 1
Mon 2
Mon 3
Mon 4
Mon 5
Ave
StdDev
Mon 6
Ave
StdDev
Baseline
200
250
300
260
310
264
43.9
225
258
42.4
Calling
Profile
MOUs
Ave. - X
64
14
36
4
46
33
>StdDev
yes
no
no
no
yes
no
Second
350
400
375
600
325
410
109.8
320
395
104.9
Calling
Profile
MOUs
Ave. - X
60
10
35
190
85
75
>StdDev
no
no
no
yes
no
no
Using one standard deviation unit (one sigma, or σ) as the “filter” to identify and exclude discontinuities in a sequence of calling profiles, results in months 1 and 5 of the baseline sequence, and month 4 of the second calling profile sequence, being excluded from the analysis.
Another parameter that can be factored into the decision process of the present invention of what service plan to select for a given user or account, based upon an array of calling profiles and optimator 370 service plan instance 390 inputs, is the sensitivity of the result set to changes in calling profile. Specifically, the service plan solution set, plans A-E in the example used up to this point, should be tested by perturbing the usage profile in a positive and negative fashion by a fixed usage amount, for example, one σ. The results are shown in Table 10.
TABLE 10
Results of Perturbing the Usage Profile by One Sigma
Sum Mon
1-5
Training
(using n = 0
Set
Ave/
Mon 6
+1 Sigma
−1 Sigma
weighting)
efficiency
StdDev
Mon 6
efficiency
Cost
eff.
Cost
eff.
Calling
264/43.9
225
269
181
Profile
MOUs
PLANS
A
$96
1.13
$50
1.38
$52
1.33
$50
1.38
B
$103
1.06
$65
1.06
$65
1.06
$65
1.06
C
$79
1.38*
$42
1.64
$47
1.47*
$37
1.86
D
$97
1.13
$60
1.15
$60
1.15
$60
1.15
E
$91
1.20
$37
1.86*
$47
1.47*
$27
2.56*
Current
$109
1.00
$69
1.00
$69**
1.00
$69**
1.00
Where * indicates the lowest cost plan option
**this sensitivity cannot be performed unless the current plan is known
Based on the above “± one sigma” analysis, the optimal service plan option, minimizing the sensitivity of the decision to variations in usage both up and down, is plan E. Using only the upside variation results in the selection of plan C. Because there is less sensitivity to an upside in usage than a downside for many wireless service plans currently offered by the wireless service providers, either weighting the +1 analysis more heavily than the −1 analysis, or using only the +1 analysis results in the selection of plan C.
The implementation of the decision algorithms into the decidePlan process must allow for one of the following four (4) possible recommendations or actions:
As with the dataLoad 320, buildProfile 350 and optimator 370 processes, decidePlan 400 can be implemented as a manual or automated process. The following inputs may be used to launch the decidePlan process 400. Please note that blank spaces indicate input variable numbers that are considered to be within the scope of the present invention.
1. Client Name
2. Account: active accounts (default) or —————— account file
3. Analysis Parameters
If the MAMBA system 100 returns any recommendations for the given user, the MAMBA system 100 takes the user information and the information for the recommended cellular service plans and dynamically creates a report Web page that details this information. The HTML for this report Web page is stored in the database 74 for later display. Once the report Web page has been generated, the MAMBA system 100 sends an electronic mail message (email) to the specified user informing the user of the availability of more economical cellular service plans. This email may contain a hyperlink that will allow them to navigate to the stored HTML Web report. The HTML Web report page contains the information shown in Table 11. It should be noted that the presentation may also be made without use of the Web, but instead may be presented via any means of communication.
TABLE 11
Information contained in HTML Web Report
Client Name
Date Generated
Department ID
User Name
Current Plan Name (hyperlink)
Recommend Plan
Name 1 (hyperlink)
Recommend Plan
Name 2 (hyperlink)
Recommend Plan
Name 3 (hyperlink)
The user information is repeated for all requested users or accounts. The hyperlinks allow the viewer to view the specific information for the given plan.
The MAMBA system 100 causes the creation of a table that contains the HTML code for the report Web page and an ID value that will be part of the hyperlink that is sent to the user. The MAMBA system 100 may also cause the fields in Table 12 to be added to the USER table.
TABLE 12
Fields the MAMBA System May Add to USER Table
Field Name
Data Type
Length
MAMBA
Varchar
1
MAMBAMailDate
DateTime
MAMBAViewDate
DateTime
MAMBAReviewUser
Varchar
50
MAMBAHTML
Text
32765
The MAMBA field may contain either a “Y” or “N” to denote to which user to send the MAMBA email for a given account. The MAMBAMailDate may contain the date the email was sent to the specified user, and the MAMBAReviewDate may contain the date the MAMBA report Web page was viewed. Further, the MAMBAReviewUser field may contain the user name of the person who viewed the MAMBA report Web page. Also, the MAMBAHTML field may contain the HTML code for the Web report page.
The MAMBA Component
The MAMBA Component (twiMAMBA) may be configured to implement a number of different methods, a few of which are shown by example in Tables 13-16 for completing the preferred functionality. These methods are as follows:
TABLE 13
BuildProfile—Method that builds the calling_profile record
A. Parameters:
Name
Type
Description
IclientID
Integer
client id to process
DloadStartDate
Date
first date to process
DloadEndDate
Date
last date to process
IprofileIds( )
Integer array
returned array of created profile ids
InumZips
Integer
number of zip codes to process
B. Returns
True—upon successful completion
False—upon failed completion
TABLE 14
RunProfiler—Method that launches the optimator process 370
A. Parameters:
Name
Type
Description
iProfileIDs( )
Integer array
array of profile ids—returned by
buildProfile
dLoadStartDate
Date
returned array of evaluation ids
B. Returns:
True—upon successful completion
False—upon failed completion
TABLE 15
AvgProfilesByClient—Method that takes a client name, a start
and an end date, and then averages the usage totals for all
profile records with a billing period between those dates and
creates a new profile record.
A. Parameters:
Name
Type
Description
SclientName
string
name of client to process
DstartDate
date
first date to process
DendDate
date
last date to process
IavgProfileIDs( )
integer array
array of average profile ids—returned
by buildProfile
B. Returns:
True—upon successful completion
False—upon failed completion
TABLE 16
AvgProfilesByAccount—Method that takes an account ID, a start and an
end date, and then averages the usage totals for all profile records
with a billing period between those dates and creates a new profile record.
A. Parameters:
Name
Type
Description
IAccountId
integer
account id
DStartDate
date
first date to process
DEndDate
date
last date to process
IAvgProfileIDs( )
integer array
array of average profile ids—returned
by buildProfile
B. Returns:
True—upon successful completion
False—upon failed completion
The Application Related to MAMBA System
The following represents a detailed description of the logic of the system and method for analyzing the wireless communication records and for determining optimal wireless communication service plans.
The getZipCodes process of block 1280, then proceeds to a decision in block 1300 if buildProfileDic is TRUE. If “NO”, the process goes to the Exit function of block 1220. If “YES”, the process proceeds to block 1320 where a decision is made if addProfileRecord is TRUE. If “NO”, the process proceeds to Exit function 1220. If “YES”, the process proceeds to block 1340, the “rsNumbers.MoveNext” function. From here, the process then returns to the decision block 1080 of do while NOT rsNumbers.EOF.
The getClientID process of block 1020 (
The getCorpZip process of block 1040 (
The getNumbersByClient process of block 1060 (
The getZipFromPhone process of block 1100 is detailed in
The getType process 1180 shown in block 1160 (
The getLataAndState function of block 1185 (
The getWhen function 1200 depicted in block 1160 (
The getWhere process 1221 of block 1160 (
The getZipFromCityState process referred to in block 1226 (
The getZipCodes process of 1280 of
If the looping operation through zipDictionary of block 1286 proceeds through the decision block of 1287, the decision is made if the max zip and count is greater than the current zipArray item. If “NO”, the process returns to block 1285, the looping operation through zipArray. If the answer to decision block 1287 is “YES” (max zip and count are greater than current zipArray item), then the process proceeds to block 1288, where the max zip and count are added to zipArray. The process then proceeds to block 1289, to remove max zip and count from dictionary. From block 1289, the process then returns to block 1285, the looping operation through zipArray. Once the looping operation through zipArray of block 1285 is completed, the process proceeds to the decision block 1291, wherein the decision is made if zipDictionary count is greater than zero. If “NO”, the process then proceeds to the Exit function of block 1283. If “YES”, the process then proceeds to roll up remaining zip dictionary items in to the first Zip Array item as instructed in block 1292, and then proceeds to the Exit function of block 1283. Returning to the decision block of 1284, if “YES” (ZipCode count is greater than or equal to max_us_zips), then the process proceeds to the decision block 1293, wherein the decision is made if testLen is greater than zero. If “NO”, the process proceeds to the Exit function of block 1283. If “YES” (testLen is greater than zero), then the process proceeds to the function of block 1294, and looping operation through all zipCodes in zipDictionary.
The loop then proceeds to block 1295, where tempZip is equal to left(testLen) characters of zipCode. The process then proceeds to block 1296, where the function Add tempZip and count to tempZipDictionary is performed, and then returns to the looping operation through all zipCodes in zipDictionary of block 1294. If in block 1294 the testLen is equal to the testLen−1, the process proceeds to the Enter function of block 1281, and the getZipCodes begins again.
The buildProfilesDic process of block 1300 (
The addProfileRecord process of block 1320 (
Once the profiles are built, according to the steps detailed in the flowchart of
The doEval process of block 1406 (
The getUserProfile process of block 1420 (
The getProfile process of block 1435 (
The findPackages process of block 1460 (
The getPackagesByZIP process of block 1464 (
From block 1477, the process may then proceed to the Exit function of block 1476, or it may proceed to block 1478, where it performs the function Save rs values to newPackage. From block 1478, the process proceeds to the decision block 1479, where the decision is made if package type equals base or extendedLocalCalling. If “NO”, the process proceeds to the decision block of 1482. If “YES” (package type is equal to base or extendedLocalCalling), the process then proceeds to the decision block 1480. In the decision block 1480, the decision is made areZips in package coverage area. If “NO”, the process then proceeds to the decision block 1482. If “YES” (areZips in package coverage area), then the process proceeds to block 1481, where it performs the function Add minutes to newPackage coveredZips.
From block 1481, the process then proceeds to the decision block 1482, where the decision is made is package type equal to Base. The answer to the decision block 1482 is necessarily “YES”, and the process proceeds to block 1483, where it performs the function Add minutes for Digital and Analog Roaming. From block 1483, the process proceeds to block 1484, where it performs the function Save profile zip for package.
From block 1484, the process proceeds to block 1485, where it performs the function Add package to retDic. From block 1485, the process returns again to block 1477, and this loop is repeated until the function is rs.EOF. Then the process proceeds from block 1477 to the Exit function of block 1476.
The selectCoveredZIPs process of block 1480 (
The calcCosts process of block 1490 (
From block 1496, the process can either proceed directly to the Calculate minimum costs function of block 1506, or the function of block 1495, twiOptimizer.SPPackage.calcCost. From block 1495, the process proceeds to the decision block 1497, where the decision is made whether package type equals longdistance. If “YES” (package type is longdistance), the process proceeds to the decision block 1498, where the decision is made if current savings is greater than max savings. If the answer to the decision block 1498 is “NO” (current savings is not greater than max savings), the process proceeds to the decision block 1500. If “YES” (current savings is greater than max savings), the process proceeds to the function of block 1499, Save current savings.
From block 1499, the process then proceeds to the decision block 1500. In the decision block 1500, the decision is made if package type is equal to offpeak, weekend, or offpeakweekend. If “YES” (package type is either offpeak, weekend, or offpeakweekend), the process proceeds to the decision block 1501. In the decision block 1501, the decision is made whether current savings are greater than max savings. If “NO”, the process proceeds to the decision block 1503. If “YES” (current savings are greater than max savings), the process proceeds to the function of block 1502, Save current savings.
From block 1502, the package type then proceeds to the decision block 1503. If the decision of block 1500 is “NO” (package type is not offpeak, weekend, or offpeakweekend), then the process proceeds to the decision block 1503, where the decision is made if package type is equal to extendedLocalCalling. If “NO”, the process returns back to the function of block 1406, for each optional package, and then proceeds to the function of block 1495, twiOptimizer.SPPackage.calcCost, and the procedure is run again. If the decision of block 1503 is “YES” (package type is extendedLocalCalling), the process then proceeds to the decision block 1504. In the decision block 1504, the decision is made whether current savings is greater than max savings. If the answer to the decision of block 1504 is “NO”, the process returns again to the looping operation of block 1496, and the procedure is run again for each optional package. If the answer to block 1504 is “YES” (current savings is greater than max savings), then the process proceeds to the function of block 1505, Save current savings.
From block 1505, the process then returns to block 1496, where the procedure is repeated. Once the procedures have been calculated for each optional package of block 1496, the process then continues on to the function of block 1506, Calculate minimum costs. From block 1506, the process then proceeds to the function of block 1507, Add costs to m_dicBasePackages. From block 1507, the process proceeds to the function of block 1508, Use twiOptimizer.ServicePlan.GetServicePlansById to Get activation fee and add it to m_dicBasePackages.
From block 1508, the process continues to the function of block 1509, Build array of lowest cost package ids. The array may contain any number of items according to several embodiments of the invention. By way of example, in one embodiment of the invention, the array contains three items. From block 1509, the process continues to the function of block 1510, a looping operation through array of lowest cost package ids and set the matching packages includedInEval flag to true. From block 1510, the process then proceeds to the Exit function of block 1493.
The process for the calcCost function of block 1495 (
The process then proceeds to the function of block 1516, Calculate roaming minutes, and then to block 1517, Get the total roaming minutes for those profile ZIPS not in the current calling area. From block 1517, the process proceeds to block 1518, the function Now Calculate the corresponding costs, and then proceeds to the decision block 1519, where the decision is made if package type is longdistance. Further, if the decision of block 1512 is “NO” (package type is not base), the process proceeds to the decision block of 1519. If the decision of block 1519 is “NO”, the process then proceeds to the decision of block 1523, as to whether Package type is equal to offpeak. If the decision of block 1519 is “YES” (package type is equal to longdistance), the process proceeds to the function of block 1520, Calculate the number of minutes over the plan minutes.
From block 1520, the system proceeds to block 1521, the function Find how much this package saves against the current base package cost. Once the function of 1521 is complete, the process moves to the function 1522, Now calculate the corresponding costs. Once the function of block 1522 is completed, the process then moves to the decision block 1523, where the decision is made if package type is equal to offpeak. If the decision is “NO”, the process proceeds to the decision block of 1526. If the decision of block 1523 is “YES” (package type is offpeak), then the process proceeds to the function of block 1524, Calculate the offpeak minutes cost.
After the function of block 1524, the process proceeds to the function of block 1525, Find how much this package saves against the current base package cost. Upon completion of the function 1525, the process then proceeds to the decision block of 1526, where the decision is made if package type is equal to weekend. If “NO”, the process proceeds to the decision block 1529. If the decision of block 1526 is “YES” (package type is weekend), then the process proceeds to the function of block 1527, Calculate the weekend minutes cost. Upon the completion of the function of block 1527, the process proceeds to the function of block 1528, Find how much this package saves against the current base package cost. Upon completion of the function of block 1528, the process will then proceed to the decision block 1529, where the decision is made if package type is equal to offpeak weekend. If “NO”, the process proceeds to the decision block 1532. If the decision of block 1529 is “YES” (package type is offpeak weekend), then the process proceeds to the function of block 1530, Calculate the offpeak minutes cost.
Upon completion of the function of block 1530, the process continues to the function of block 1531, Find how much this package saves against the current base package cost. Upon completion of this function, the process then proceeds to the decision block 1532, where the decision is made if package type is equal to extended local calling. If “NO”, the process then proceeds to the Exit function of block 1535. If the decision of block 1532 is “YES” (package is extended local calling), then the process proceeds to the function of block 1533, Calculate the extended local calling minutes cost. After the function of block 1533, the process continues to the function of block 1534, Find how much this package saves against the current base package cost. The process then proceeds to the Exit function 1535.
The getServicePlanByID process of block 1508 (
The createEvaluation function of block 1600 (
The putEvaluation process of block 1620 (
From block 1625, the process then returns to the looping operation base packages of block 1623. If the decision of block 1624 is “YES” (includedInEval is TRUE), then the process proceeds to the function of block 1627, Insert in to service plan instance. The process then proceeds to the function of block 1628, Insert in to SPI_RPE_LINK, before proceeding to the function of block 1629, Insert in to package instance. The process then continues to the function of block 1630, the looping operation through optional packages. In the looping operation, the process proceeds to the decision block 1631, where the decision is made if package selected is True. If “NO”, the looping operation then goes directly to the next optional package, as shown in block 1633, before returning through to the looping operation through optional packages of block 1630. If the decision of block 1631 is “YES” (if package selected is True), then the process proceeds to the function of block 1632, Insert in to package instance, and then to the function of block 1633 for the next optional package.
Once the looping operation is completed, the process then proceeds from block 1633 to the function of block 1625 for the next base package, which is part of the looping operation through based packages as depicted in block 1623. Once the looping operation through base packages is complete, the process then moves from block 1625 to the Exit function of block 1626.
The calling profiles may be averaged by client or account. The avgProvilesByClient process 1700 is depicted in the flowchart of
The decision is made in block 1706 if avgProfilesByAccount is TRUE. If “NO”, the process proceeds to the Exit function of block 1703. If “YES” (avgProfilesByAccount is TRUE), the process proceeds to the function of block 1707, rsNumbers.MoveNext. From the function of block 1707, the process then returns to the decision block 1705, and is repeated while NOT rsNumbers.EOF. The getClientId function of block 1702 has been previously described and is depicted in process 1020 (
The avgProfilesByAccount process 1706 (
From block 1800, the process then continues to the function of block 1810, iPeriods equals iPeriods plus 1. The process then returns to the function Do while NOT rsProfiles.EOF of block 1780. Once the block 1780 is “NO”, and leads to the getZipCodes function of block 1820, the process then continues to the decision block 1830. The decision is made in block 1830 if iPeriods is greater than zero. If “NO”, the process proceeds to the Exit function of block 1770. If “YES” (iPeriods is greater than zero), then the process continues to the function of block 1840, Average all sums. The process then continues to the Build profile dictionary function of block 1300. The Build profile dictionary function is depicted in process 1300 (
The getProfileRecords process of block 1760 is depicted in greater detail in the flowchart of
Rebate Generator
The MAMBA system 100 of
The rebate processing system 1850 contains a call detail record receiving module 1852 that receives, using various accumulating and/or retrieving means, the call detail records of a telecommunication user. Preferably, the call detail records are received during a single previous billing period, but may also be received during multiple billing periods. Typically, although not necessarily, a billing period is equal to one month. The call detail record receiving module 1852 may also include a module for converting the call detail records to a calling profile record that is indicative of the calling patterns of the telecommunication user by averaging the service usage over multiple months.
The rebate processing system 1850 further contains a service cost calculating module 1854 that receives at a first input the call detail records from the call detail record receiving module 1852. The service cost calculating module 1854 receives at a second input 1856 information pertaining to the present rate plan under which the user is currently contracted. The service cost calculating module 1854 calculates the actual service cost under the present plan, preferably for one billing period, and provides the calculated service cost to a rebate calculating module 1858. The calculated service cost may also be provided to a billing processor for billing the user or deducting the service cost from the user's account.
The rebate processing system 1850 further includes a hypothetical service cost calculating module 1860 that also receives the call detail records from the call detail record receiving module 1852. The hypothetical service cost calculating module 1860 receives from a set of inputs 1862 information pertaining to a plurality of rate plans, other than the present rate plan, which are available to the user. This rate plan information includes data that may be used to determine service costs based on the call detail records from module 1852. The hypothetical service cost calculating module 1860 calculates a plurality of hypothetical service costs corresponding to the number of available rate plans. The hypothetical service costs refer to the service costs had the user been under a different rate plan, i.e. one of the plurality of rate plans provided at inputs 1862. The respective service costs for each available rate plan are provided to the rebate calculating module 1858.
The rebate calculating module 1858 receives the actual service cost from the service cost calculating module 1856 and a plurality of hypothetical service costs from the hypothetical service cost calculating module 1860. With these different service costs, the rebate calculating module 1858 calculates a rebate according to predefined factors that determine the criteria for calculating the rebate. For example, the rebate calculating module 1858 may use the formula:
R=d*(p−c)
where R is equal to the rebate, d is equal to a detuning factor, p is equal to the service cost of the present rate plan, and c is equal to a cost comparison value.
The cost comparison value c is a value based on at least one rate plan that would result in a savings to the user. The cost comparison value c provides a value to which the cost of the current rate plan can be compared. The value c, for example, may be the hypothetical service cost of the most cost effective plan that is available to the user. Using this optimal hypothetical service cost provides the greatest savings for the user. Alternatively, c may be the average hypothetical service cost of a number of the most cost effective plans. In this regard, a telecommunication company may advertise the rebate generating process as providing a rebate to the user based on the average cost of five, or some other number, of the most cost effective rate plans available. The cost comparison value c may alternatively be equal to the average hypothetical service cost of one or more, but preferably all, of the known available rate plans that are less expensive than the current rate plan. Furthermore, the value c may be equal to the average hypothetical service cost of one or more, but preferably all, of the known available rate plans that are equal to or less than the cost of the current rate plan.
The detuning factor d is a constant value between zero and one that is multiplied by the difference between the cost of the present rate plan p and the cost comparison value c to scale down or detune the total rebate that is provided to the user. In other words, a telecommunication company offering such a rebate plan may decide to give a fraction of the hypothetical savings as a rebate. Preferably, the detuning factor may be about 0.2, 0.4, or 0.6, representing 20%, 40%, or 60%, respectively, of the highest possible savings. Depending on a number of factors, the detuning factor d may be determined in light of the criteria for determining the cost comparison value c.
The rebate that is calculated by the rebate calculating module 1858 is provided to a rebate generating module 1864. The rebate generating module 1864 provides the rebate to the user in one of a number of possible forms. For instance, the rebate generating module 1864 may be configured as a credit transmitting device such that the rebate is provided to the user in the form of a credit applied to the user's account to reduce payments for future telecommunication service. Alternatively, the rebate generating module 1864 may be a check printing device such that the rebate is provided in the form of a check, such as a bank check or cashier's check, to the user's billing address. The rebate generating module 1864 may also include a mailing device for providing to the user with the rebate check, as mentioned above, or with a coupon or gift certificate for merchandise or services in the amount of the rebate. The coupon or gift certificate may be either related or unrelated to telecommunication services.
After obtaining the call detail records, the rebate generating process proceeds to block 1872 in which the service cost under the present rate plan is calculated. The present rate plan is the plan under which the user is currently contracted. The service cost is preferably calculated on the basis of the call detail records obtained in block 1870. In block 1874, hypothetical service costs are calculated by applying the call detail record to a number of other available rate plans. These other available rate plans are evaluated according to the call detail records or calling profile record in order to determine the hypothetical service costs had the user been under these different plans.
Block 1876 includes the process of providing a rebate to the user based on at least one hypothetical service cost of at least one other rate plan that is less expensive than the present rate plan. The process of providing a rebate preferably includes the use of a mathematical formula that calculates a savings that a user would have gotten had the user been on a more cost-effective rate plan. From the highest possible savings, the rebate generating process calculates an amount of a rebate that is equal to or less than the difference in cost between the least expensive rate plan and the present rate plan. Since most telecommunication companies could not easily afford to give away a rebate to undersell the rates of known competitors, a formula may be derived such that only a portion of the highest possible savings is credited back to the user. For example, one such rebate generating formula may be given by:
R=d*(p−c)
as repeated from above, where R is equal to the rebate, d is equal to a detuning factor, p is equal to the actual service cost of the present rate plan, and c is equal to a cost comparison value.
The cost comparison value c is a value calculated on the basis of at least one rate plan that would result in a savings to the user, as mentioned above. The detuning factor d is a constant value between zero and one for detuning the total rebate provided to the user, as mentioned above. The cost comparison value c and detuning factor d may be determined with respect to each other to adjust the amount and range of rebates that may result from this formula.
The process of providing a rebate, as indicated in block 1876, may further include the actual transfer of the calculated rebate to the user. The rebate provided to the user may be in the form of a credit that is applied to the user's account that may be used toward future telecommunication service. Alternatively, the telecommunication company may provide the rebate in the form of a check, such as a bank check, that is sent to the user's billing address. Another way in which the rebate may be provided is by providing a coupon or gift certificate for merchandise or services either related or unrelated to telecommunication services.
It should be emphasized that the above-described embodiments of the present invention, particularly, any “preferred” embodiments, are merely possible examples of implementations, merely set forth for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiment(s) of the invention without departing substantially from the spirit and principles of the invention. All such modifications and variations are intended to be included herein within the scope of this disclosure and the present invention and protected by the following claims.
Marsh, William, DeCesaris, Wayne
Patent | Priority | Assignee | Title |
10404865, | Oct 12 2009 | AT&T MOBILITY II LLC | Dynamic usage inequity detection and/or remedy |
11606350, | Sep 15 2020 | The Toronto-Dominion Bank | Initiating provisioning of an existing account based on an unauthenticated request |
11985121, | Sep 15 2020 | The Toronto-Dominion Bank | Initiating provisioning of an existing account based on an unauthenticated request |
7986935, | Oct 26 2007 | T-MOBILE INNOVATIONS LLC | Service plan optimizer |
8229395, | May 03 2004 | Chikka Pte Ltd. | System and method for facilitating communication between two parties |
8958770, | Oct 12 2009 | AT&T MOBILITY II LLC | Dynamic usage inequity detection and/or remedy |
9503585, | Oct 12 2009 | AT&T MOBILITY II LLC | Dynamic usage inequity detection and/or remedy |
9979832, | Oct 12 2009 | AT&T MOBILITY II LLC | Dynamic usage inequity detection and/or remedy |
Patent | Priority | Assignee | Title |
4979207, | Feb 01 1990 | MOTOROLA, INC , A CORP OF DE | Method of processing cellular telephone call detail data for billing multi-line customers for cellular telephone services |
5027388, | Feb 01 1990 | MOTOROLA, INC , A CORP OF DE | Method of selecting the most cost effective cellular service plan provided by cellular telephone resellers to multi-line customers |
5287270, | Aug 14 1989 | CENTILLION DATA SYSTEMS, LLC | Billing system |
5325290, | Aug 14 1989 | CENTILLION DATA SYSTEMS, LLC | Billing system with data indexing |
5553131, | Jul 09 1993 | MOUNTAIN INTERATIONAL CORP | Providing the most cost-effective long-distance telephone service based on milage band rates |
5615408, | Nov 12 1992 | AUTHORIZE NET LLC | Apparatus and method for credit based management of telecommunication activity |
5659601, | May 09 1995 | Google Technology Holdings LLC | Method of selecting a cost effective service plan |
5684861, | Dec 04 1995 | Apparatus and method for monitoring cellular telephone usage | |
5878126, | Dec 11 1995 | BELLSOUTH INTELLECTUAL PROPERTY GROUP, INC ; Bellsouth Intellectual Property Corporation | Method for routing a call to a destination based on range identifiers for geographic area assignments |
5907800, | Jun 07 1995 | AUTHORIZE NET LLC | Apparatus for use in inhibiting telecommunication subscriber termination |
6018718, | Aug 28 1997 | PayPal, Inc | Method and system for processing customized reward offers |
6125173, | May 21 1997 | AT&T Corporation | Customer profile based customized messaging |
6192223, | Jul 29 1994 | GRAY ELECTRONICS, LLC | Apparatus and method for automatically programming frequency scanning radio receivers |
6198915, | Jan 30 1995 | TRACFONE WIRELESS, INC | Mobile phone with internal accounting |
6240169, | May 06 1999 | HINDMAN, W JAMES | Communications protocol for least cost call routing system |
6252952, | Dec 30 1999 | AT&T Corp | Personal user network (closed user network) PUN/CUN |
6301471, | Nov 02 1998 | UNWIRED PLANET IP MANAGER, LLC; Unwired Planet, LLC | Online churn reduction and loyalty system |
6345090, | Sep 04 1996 | PRICELINE COM INCORPORATED | Conditional purchase offer management system for telephone calls |
6408174, | May 13 1997 | Telefonaktiebolaget LM Ericsson (publ) | Communication method, system, and device for reducing processor load at tariff switch |
6509833, | May 18 2001 | NOKIA SOLUTIONS AND NETWORKS US LLC | Method and system for providing a warning alert |
6529722, | Jun 19 1998 | TELECOMMUNICATION SYSTEMS, INC | System and method for enhanced 9-1-1 address development, maintenance and call routing using road access zones |
6574464, | Aug 03 2000 | Verizon Patent and Licensing Inc | Apparatus and method for real-time rate changes for telecommunication services |
6574465, | Sep 07 2000 | TANGOE US, INC | System and method for determining optimal wireless communication service plans |
6697469, | Aug 20 1998 | BELLSOUTH INTELLECTUAL PROPERTY GROUP, INC ; Bellsouth Intellectual Property Corporation | Method and system for implementing calling-party-pays telecommunication services |
EP541535, | |||
WO9103023, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Jan 06 2001 | GONZALES, JUAN | TRAQ WIRELESS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 024927 | /0913 | |
Jan 06 2001 | MARSH, WILLIAM | TRAQ WIRELESS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 024927 | /0913 | |
Jan 08 2001 | MERRITT, JOHN | TRAQ WIRELESS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 024927 | /0913 | |
Jul 13 2010 | TRAQ WIRELESS, INC | TANGOE, INC | MERGER SEE DOCUMENT FOR DETAILS | 024953 | /0117 | |
Jan 21 2011 | TANGOE, INC | ORIX VENTURE FINANCE LLC | AMENDMENT TO IP SECURITY AGREEMENT | 026167 | /0684 | |
May 09 2012 | DECESARIS, WAYNE | TANGOE, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 028208 | /0878 | |
May 29 2017 | MARSH, WILLIAM | NEXETHER, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042639 | /0380 | |
Jun 16 2017 | TANGOE, INC | OBSIDIAN AGENCY SERVICES, INC , C O TENNENBAUM CAPITAL PARTNERS, LLC | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 042734 | /0555 | |
Jun 16 2017 | ORIX VENTURE FINANCE LLC | TANGOE, INC | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 042754 | /0266 | |
Jun 16 2017 | ASENTINEL, LLC | OBSIDIAN AGENCY SERVICES, INC , C O TENNENBAUM CAPITAL PARTNERS, LLC | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 042734 | /0555 | |
Dec 12 2017 | TANGOE, INC | TANGOE US, INC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 047590 | /0729 | |
Nov 30 2018 | TANGOE US, INC | CORTLAND CAPITAL MARKET SERVICES LLC, AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 047697 | /0104 | |
Nov 30 2018 | MOBI WIRELESS MANAGEMENT, LLC | CORTLAND CAPITAL MARKET SERVICES LLC, AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 047697 | /0104 | |
Nov 30 2018 | OBSIDIAN AGENCY SERVICES, INC | TANGOE, LLC | TERMINATION AND RELEASE OF PATENT SECURITY INTEREST RECORDED AT REEL 042734 FRAME 0555 | 047691 | /0457 | |
Nov 30 2018 | OBSIDIAN AGENCY SERVICES, INC | TANGOE US, INC | TERMINATION AND RELEASE OF PATENT SECURITY INTEREST RECORDED AT REEL 042734 FRAME 0555 | 047691 | /0457 | |
Nov 30 2018 | TANGOE, LLC | CORTLAND CAPITAL MARKET SERVICES LLC, AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 047697 | /0104 |
Date | Maintenance Fee Events |
Nov 26 2013 | ASPN: Payor Number Assigned. |
Jan 02 2014 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jan 03 2014 | STOL: Pat Hldr no Longer Claims Small Ent Stat |
Jan 02 2018 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jan 11 2022 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Jul 20 2013 | 4 years fee payment window open |
Jan 20 2014 | 6 months grace period start (w surcharge) |
Jul 20 2014 | patent expiry (for year 4) |
Jul 20 2016 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jul 20 2017 | 8 years fee payment window open |
Jan 20 2018 | 6 months grace period start (w surcharge) |
Jul 20 2018 | patent expiry (for year 8) |
Jul 20 2020 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jul 20 2021 | 12 years fee payment window open |
Jan 20 2022 | 6 months grace period start (w surcharge) |
Jul 20 2022 | patent expiry (for year 12) |
Jul 20 2024 | 2 years to revive unintentionally abandoned end. (for year 12) |