Patent Application
20130060587
The present application relates generally to computer applications and more particularly to determining best time to reach customers in a multi-channel world ensuring right party contact and increasing interaction likelihood.
Leveraging sophisticated insights to improve risk management, channel performance and client satisfaction may allow enterprises, where a substantial portion of the business is conducted using front office operations for sales, support, account management, etc., to become more client centric. Insightful operations also may allow for continuously tailoring services offered to changing client needs. To succeed in the market place, front office operations of businesses need to strengthen client relationships and improve client experience in the different channels of interaction. Most often, this requires increasing the quality and quantity of productive interactions with the clients. The inventors in the present application have recognized that fundamental to this, is the ability to have insights about the customers such that customers can be reached at their preferred, convenient time depending on the communication channel used. This is especially the case, when businesses and organizations need to reach out and initiate a contact with their customers and clients (outbound contact attempts) or simply return customer calls as part of their customer relationship management.
Modern contact centers can handle a multitude of communication channels, such as phone, e-mail, text messaging, paper mail, telefax, instant messaging, and messages on social networks. Some of these channels can have more than one type; for instance, there may be several types of phone channels, such as Home, Work, Cell phone, etc. and there may be different types of e-mail addresses, such as private and work email addresses.
Traditionally, the timing of customer contact attempts is based on staffing capacity, customer segments, risk priorities, and may be guided by “typical” or “expected” behavior. In the call center industry, customers are increasingly asked about their preferred time to be contacted. While this information is collected, there is no systematic way of analyzing or using the captured information. In addition, the call/response patterns at the individual level are rarely utilized to guide outbound notifications. System operations such as interactive voice responses (IVRs) or the like are not set up to ensure that contacts are always made during the most convenient/preferred time for all customers increasing the likelihood that dials are converted to successful business outcomes. Contacting customers at inconvenient times or at plain unavailable times lead to wasted contact attempts, poor customer experience, dissatisfied customers and a loss of business revenue as the opportunity to convert a call/contact into business value such as a sale or obtaining a payment is lost. Often, when outbound contact campaigns are made, the phone calls are picked up by parties who are not authorized to discuss the matter, which leads to enormous waste of resources and delayed resolution. The ability to increase right party contact and the ability to have an interaction enhances all front operations.
A method for predicting likelihood of contacting a customer in a time period, in one aspect, may include receiving a first set of historical customer contact data. The method may also include estimating a statistical model which computes a score for determining a successful contact with the customer for the time period based on the first set of historical customer contact data. The method may further include receiving a second set of historical customer contact data associated with at least one customer. The method may also include providing the score of a successful contact for said at least one customer based on the second set of historical data and the estimated statistical model.
A system for predicting likelihood of contacting a customer in a time period, in one aspect, may include a statistical model estimated based on a first set of historical customer contact data to compute a score for determining a successful contact with the customer for the time period. The system may also include a prediction module operable to receive a second set of historical customer contact data associated with at least one customer, and provide the score of a successful contact for said at least one customer based on the second set of historical data and the estimated statistical model.
A computer readable storage medium storing a program of instructions executable by a machine to perform one or more methods described herein also may be provided.
Further features as well as the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.
The present disclosure in one aspect describes a method of producing a score indicating the best time to use a channel of a type for a specific customer. These scores may be based on historical customer data and the method may be flexible enough to handle varying levels of data availability. For customers with little or no historical data, the method may provide a “best time to contact” score that is based on general observations about the likelihood of reaching a customer in a time period. For customers with plenty of historical data, the method may provide a “best time to contact” score that closely resembles the historical reachability patterns of the customer.
The scale of “best time” may depend on the channel used to contact the customer. For phone calls, the relevant time scale may be “time of the day”, for instance, described by the one-hour time slots. For paper mailings, on the other hand, the relevant time scale may be likely to be “day of the week”, and for e-mails it may be “day of week” in combination with a coarser measure of “time of day”, such as morning/afternoon/evening. Moreover, the “best time” may also be described in relative terms—in the case of instant messages, for example, the relevant time scale may be “minutes after a customer becomes available to chat”. Similarly, the definition of a “successful contact attempt” may be different for different channels. For a phone call, a successful contact may entail (a) somebody picking up the phone, who is (b) authorized to talk about the matter, and who (c) does not immediately indicate that this is a “bad time to talk”. The combination of (a) and (b) is referred to as a “Right Party Contact” (RPC), while the combination of (a), (b), and (c) is referred to as a “Long RPC”. For an e-mail, a successful contact attempt may be defined as whether the customer responded to the email or clicked on a certain link within a specified period of time. For a paper mail, a successful contact attempt may be defined as whether the addressee mailed back a filled-out form or took a specified action by a deadline. In a multi-channel world, the time scale of “best time” and the definition of a “successful contact” may depend on the channel and possibly on the channel type.
The present disclosure in one aspect proposes a model that uses historical contact pattern data, customer metrics, customer life situations, and possibly additional variables to determine a best time to contact a customer, ensuring a right party contact. As an example, an embodiment for outbound call center operations is disclosed such that a best time to contact (or in this case “best time to call”) is determined for each customer, and for each telephone type (cellular, home, work, and other). Information about customer inbound calling behavior and situations where a preferred time is explicitly indicated by the customer can be integrated as adjustments to determine the best time to contact the customer.
Existing solutions typically do not make use of customer-specific call histories. A typical outbound calling system might recommend calling home phones between the hours of 8 a.m. and 11 a.m., then cell phones between the hours of 11 a.m. and 1 p.m., then work phones between 1 p.m. and 5 p.m., and finally home phones between 5 p.m. and 9 p.m. The methodologies in the present disclosure may improve the likelihood of reaching the customer by using customer-specific historical call patterns to guide the outbound calling systems and to guide the outbound calling by agents in the front office.
In another embodiment, the right time to e-mail or short message service (SMS) may be determined in a way that responses are ensured. Usage patterns of e-mail and cell phone SMSs used in real time mode may be utilized to mine for the best time to send e-mail or SMSs so as to improve response rates for those customers who prefer to use those channels the most.
As an example application, call centers are described in connection with the methodology of the present disclosure in one embodiment. In one embodiment, the methodology of the present disclosure uses customer specific historical call patterns to determine the best time to contact a customer. For each customer in the system, the method generates a matrix with scores indicating the chance of reaching the customer at a certain phone type (home, cell, work, other) during a given time slot as shown in
In one embodiment of the present disclosure, different levels of data availability for different customers/phone types/time slots are addressed by balancing an overall baseline best time to contact (BTTC) score with customer-specific information. If the outbound call history is limited (or completely absent) for a given customer (at a given phone type during a given time slot), the method in one embodiment places most (or all) of the weight on the overall baseline rate. The more customer-specific information is available for a given phone-type/time slot combination, the more weight is given to that information. The resulting weighted, customer specific BTTC score is then adjusted using inbound call information. An inbound effect is estimated for customers that actively called the call center during a certain time slot using a given phone type. Typically, if a customer contacted the call center during a given time slot, this increases the probability of reaching the customer with an outbound call during that time slot.
The present disclosure in one embodiment uses an additive model to incorporate outbound call/response history, inbound calling effects, and others. In another embodiment of the present disclosure, an adaptive/predictive model may be built that would estimate the score of the best time to contact a customer based on not only these features, but also additional model features which can be the result of aggregation, transformation (log, power, identity, etc.), categorization, or combinations thereof. This may include the total and time-weighted contact time (including the customer wait time before being connected to a live agent for customer-placed inbound calls) per time period for each customer, the total number of contact attempts and the total number of successful contacts per time period, the sum of time-weighted contact attempts and the sum of time-weighted successful contacts, a customer's risk profile, occupancy, customer life style choices, work life constraints, wait time until abandonment of an inbound call, and others. This adaptive/predictive model can be trained to learn the statistical relationships between various variables or factors affecting the likelihood of contacting a customer, and can be run every day or in intervals periodically to accommodate for the latest information. For instance, a logistic regression approach may be used to estimate coefficients of a relationship between the model features and a binary response variable, indicating whether the historical contact attempt had been successful or not.
The methodology—in one embodiment of the present disclosure—may be applied to determine the best time to contact customers using alternative channels, e.g., in an e-mail setting with different e-mail types or in a call center setting with different phone types. For example, the methodology of the present disclosure in one embodiment may consider and determine: has the customer ever used email to contact us? If so, when should we email a customer in order to maximize the likelihood of a reply? On which day of the week? During what time of the day? In addition, the answers may be different for different types of email such as personal email, work email, or the email on social network sites (e.g., Facebook™), internal messaging system. As another example, the methodology of the present disclosure in one embodiment may consider and determine in a call center context: what time of the day? e.g., call between 8 am and 9 pm; restrictions on weekends and national holidays restrictions on calling cell phones; restrictions on calling work phones; an entry on the national “do not call list”, etc. Answers may be different for different phone types such as a home phone, cellular phone, or others. Other examples include determining best time to contact customers by determining when to send out paper mail, when to send a facsimile, when to send text messages (SMS), and when to send an instant message relative to the time a customer becomes available to chat, and others.
One embodiment of the methodology of the present disclosure utilizes data, for example, historical contact patterns such as overall historical patterns, patterns specific to the individual and other data in order to determine the above answers. A trained model, e.g., a trained statistical model may generate a score or recommendation about when to contact with what medium the selected customers (or persons). Such contact recommendations may be generated based on data driven, customer-specific information and provide an increased right party contact likelihood leading to an increased likelihood of interacting productively with the customer.
The output provided by the methodology of the present disclosure may be used to schedule a number of contacts over a period of time (e.g., a number of phone calls to be scheduled over a whole day). This is especially useful in situations where there are capacity constraints. Such a Best-Time-To-Contact scheduling approach allows for the minimization of “wasted” contact attempts, which are often costly because of lost time spent by contact center agents (and therefore labor costs), in some cases phone charges or text messaging charges, and which can be bothersome for the customers.
In one embodiment of the present disclosure, the right party connect 320 and 322 are the response variables that the methodology of the present disclosure solves for. In one embodiment, instead of, or in addition to 1 or 0 indication, the methodology of the present disclosure may provide a probability or score of getting a successful contact (such as a right party contact that lasts at least one minute. A response variable value of 1 denotes that the right party picked up the phone and the call took up at least a predetermined length of time, e.g., one minute.
R
w(pt,ts,cid)=
u(n(cid,ts))·Rs(cid,ts)
+(1−u(n(cid,ts)))·Rb(pt,ts)
where pt indicates the phone type, ts the time slot, cid the Customer ID, n( ) the count of contact attempts (or the sum of time-weighted contact attempts), u( ) the mixing weight for customer-specific vs. baseline information, Rs the customer-specific historical RPC rate, and Rb the overall baseline rate. The result Rw is then adjusted for additional factors such as inbound information. The expected RPC rate (eRPCr) may then be determined as follows:
eRPCr(pt,ts,cid)=
R
w(pt,ts,cid)
+I—ib(cid)*A(pt)
+I—ibts(cid,ts)*v(cid,ts)*B(pt,ts)
where A( ) and B( ) are the overall and timeslot-specific inbound adjustments, respectively, I_ib( ) is an indicator function taking on a value of 1 if the customer has had at least one historical inbound contact and 0 otherwise, I_ibts( ) is an indicator function taking on a value of 1 if the customer has had at least one historical contact attempt in a certain time period, and 0 otherwise, and v is a recency weight determined by how far in the past the latest inbound call in a certain time slot took place.
The BTTC model of the present disclosure may be employed or applied in a call center setting. For instance, a call center agent needing to contact a customer may run the model, which provides a customer-specific score, indicating the likelihood of having a successful contact for different times of the day. The BTTC model of the present disclosure may be also employed by an interactive voice response system which automatically places a call to the customers. Such interactive voice response system may automatically trigger the BTTC model of the present disclosure to determine the appropriate or best time to contact the customer, then based on such determination, automatically contact the customer during the “best” or one of the good/recommended periods of time.
The present disclosure in one embodiment expands the scope: “Best Time To Reach” and provides a methodology that is applicable to complete contact analytics efforts, e.g., including but not limited to, phone calls, e-mail, paper mail, facsimile (fax), text messages (e.g., SMS), instant messages, and others. The present disclosure may provide recommendations for all levels of data availability and mix baseline with individual information. The recommendations in the present disclosure may be based on a statistical model (e.g., as opposed to “business rules”) combining different data types and making use of historical call and outcome patterns, historical outbound RPC patterns, historical inbound RPC patterns, personal characteristics, aggregated call duration by time slot, aggregated inbound wait time by time slot, occupancy status, employment status and others.
Referring to
The above table shows the baseline outbound RPC rates, Rb(pt, ts), for different phone types (pt) and different time slots (ts). For instance, the baseline outbound RPC rate for Work phones for the 4:00 PM-4:59 PM time slot is denoted as Rb(W, 16) and has been estimated (in this example) to be 2.55%.
In general, the baseline outbound RPC rates are defined as the proportion of successful contacts for a given phone type in a given time slot using all the of historical contact data for es-timation:
R
b(pt,ts)=(number of successful contacts using phone type pt in time slot ts)/(number of contact attempts using phone type pt in time slot ts)
Alternatively, the baseline outbound RPC rate may be defined as the ratio of the (a) the sum of time-weighted successful contacts using phone type pt in time slot ts and (b) the sum of time-weighted contact attempts using phone type pt in time slot ts.
At 1004, phone type/customer-specific outbound RPC rates are estimated. For instance, the following describes estimation of phone type/CustomerID-specific outbound RPC rates as an example. In the example version described herein, the individual-level information is computed on a PhoneType/CustomerID basis. Therefore, multiple phone numbers of the same phone type are aggregated for the same Customer ID. For instance, if multiple home phone numbers exist for a given Customer ID, they may all be aggregated to the same pt_lid (Phone-Type/CustomerID) identifier. CustomerID in this example identifies a customer. Other identifi-ers may be used. Thus, there is flexibility in the choice of the identifier used for generating cus-tomer-specific information. For example, the BTTC model may use the phone number instead of the Customer ID as the main identifier. In any case, the methodology described in this disclosure would be analogous. The phone type/CustomerID-specific outbound RPC rates, Rs(pt_lid, ts), are determined for each pt_lid and time slot (ts). In one embodiment, this involves weighting the available data in order to put more emphasis on recent information.
Weighting function for Count of Calls and Count of RPCs
The following derives the weighting function wpt
Computation of Phone Type/CustomerID-Specific Outbound RPC Rates
Given the weighting function wpt
Referring to
Mixing Weight Between Baseline and Phone Type/CustomerId-Specific Information
The mixing weight for the phone type/CustomerID-specific RPC rate Rs(pt_lid, ts) will be denoted u(n(pt_lid, ts)), where n(pt_lid, ts) is the sum of time-weighted calls for a given pt_lid and time slot ts:
The mathematical formula for the mixing weight u can be found in
Computation of the Weighted Outbound RPC Rate
The weighted outbound RPC rate will be denoted as Rw(pt, ts, pt_lid) and is computed as follows:
R
w(pt,ts,pt—lid)=u(n(pt—lid,ts))·Rs(pt—lid,ts)+(1−u(n(pt—lid,ts)))·Rb(pt,ts)
Referring to
An Additive Model for the eRPCr
An embodiment of the present disclosure may use an additive model for the expected right party contact (RPC) rate (eRPCr):
eRPCr(pt,ts,pt—lid)=Rw(pt,ts,pt—lid)+I—ib(pt—lid)*A(pt)+I—ibts(pt—lid,ts)*v(pt—lid,ts,d)*B(pt,ts)
The main component of the eRPCr model in one embodiment is the weighted outbound RPC rate Rw(pt, ts, pt_lid), which depends on the phone type, the time slot and the phone type/CustomerID. The eRPCr is then adjusted for pt_lid's with at least one inbound phone call and there is an additional (interaction) adjustment if at least one inbound call occurred in the time slot ts.
Components of the eRPCr model may include:
pt: phone type, either H, C, W, or O.
ts: time slot, a number between 8 and 20.
pt_lid: PhoneType/CustomerID, e.g “C1—12345678”.
I_ib(pt_lid): indicator variable with value 1 if the phone type/CustomerID pt_lid has been used at least once for an inbound call and 0 otherwise.
I_ibts(pt_lid, ts): indicator variable with value 1 if the phone type/CustomerID pt_lid has been used at least once for an inbound call in time slot ts and 0 otherwise.
v(pt_lid, ts): recency weight, depending on the date of the last inbound phone call from phone type/CustomerID pt_lid during time slot ts.
Rw(pt, ts, pt_lid): weighted outbound RPC rate for phone type pt, time slot ts, and phone type/CustomerID pt_lid.
A(pt): adjustment factor for phone numbers of type pt with at least one inbound call.
B(pt, ts): adjustment factor for phone numbers of type pt with at least one inbound call in time slot ts.
The recency weight v(pt_lid, ts), is defined as
if the last inbound phone call occurred on or after the Left cut-off date L and zero otherwise.
In one embodiment, similar to the baseline outbound RPC rate Rb(pt, ts), the parameters A(pt) and B(pt, ts) are estimated using the available data. The following describes one way to determine A(pt) and B(pt, ts):
1. For each phone type and combining all time slots, measure the outbound RPC rate for phone type/CustomerID's that had at least one inbound phone call since ‘Today-L’ and call it r_with. Compute the same outbound RPC rate for all phone type/CustomerID's that did not have at least one phone call since “Today-L” and call it r_without. Define A(pt)=(r_with−r_without)/2
2. For each phone type and time slot, measure the outbound RPC rate for phone type/CustomerID's that had at least one inbound phone call since ‘Today-L’ and call it r_with2. Compute the same outbound RPC rate for all phone type/CustomerID's that did not have at least one phone call since “Today-L” and call it r_without2. Define B(pt,ts)=(r_with2−r_without2)−A(pt)
Example of inbound parameters with four different phone types and time slots:
At 1010, a consistency check may be performed as follows.
Optionally, the above algorithm may check and adjust if needed, the values for the eRPCr that are unreasonable, i.e., outside the range (0%, 100%), which may have resulted from the additive model. For instance, one may overwrite any eRPCr smaller than a positive, non-zero lower threshold (such as 0.25%) and set it equal to that lower threshold. Similarly, one can set all the eRPCr values larger than an upper threshold (which is smaller than 100%) and set it to that upper threshold (e.g., upper threshold=90%).
In one embodiment of the present disclosure, instead of using ‘raw’ RPC flags, the BTTC model can be estimated using “Long RPC” flags. A “Long RPC” is defined as an RPC with a connect time of at least a predetermined time interval, e.g., 60 seconds. The assumption is that some outbound calls will reach the right party, however, the person reached might quickly indicate that this is not a convenient time to talk. Using “Long RPC” flags allows the BTTC model to account for this.
In one aspect of the BTTC model, the BTTC probabilities are defined on the destination time of the customer (or the location of the property corresponding to the Customer ID, e.g.). Therefore, the call center times are converted into local destination times before running the BTTC model. This time conversion also may handle the daylight saving time adjustments.
Phone Numbers not Found in Database
In one embodiment of the present disclosure, if a phone type/CustomerID has no call history, the BTTC model may use the phone type-specific baseline rate Rb(pt, ts).
At 1104, the historical contact data may be processed to be used as inputs for a statistical model. This processing might include aggregation, arithmetic transformations such as log, square root, categorization, and/or others. In the following description, this processing step is described with reference to a call center example. It should be understood, however, that the methodology of the present disclosure is not limited to the application in a call center. Aggregation can take place many different levels such as a customer level (total number of calls in the last year for a given customer), customer and phone type level (total number of calls in the last year using a particular phone type to a given customer), customer and time period level (cumulative call duration in last year broken down by time period), customer/time period/phone type level, and/or others.
At 1106, a statistical model may be estimated that predicts a successful contact using the data retrieved and processed at 1102 and 1104. “Statistical Model Estimation” is also referred to as “Model Training”, or “training a statistical model.” Different statistical models may be estimated and used. One is an additive model, that mixes an overall baseline rate with a customer-specific rate (depending on how much data is available for a customer and time period), for instance, as described above. Another model may employ a different statistical approach, e.g., Logistic Regression which estimates the coefficients of a relationship between the model features and a binary response variable, indicating whether the historical contact attempt had been successful or not. Yet another estimation may combine these two models by estimating a logistic regression, that takes the output of the additive model (or a transformation thereof, such as the Logit) as an input in addition to other variables such as historical cumulative call time, inbound wait time, weekday/weekend effect, and others. More statistical models exist and can be combined. The models (1) provide a score indicating the likelihood of a successful contact attempt (by time period) (2) they use historical contact data to estimate a model for providing aforementioned score, (3) they compute these scores as a function of inputs such as the Customer ID and the proposed time period/time slot for a contact attempt and possibly additional variables, such as the data from Step 1102 (e.g., phone type) or Step 1104 (aggregated call duration by customer and time period).
At 1108, the estimated model may be stored. At 1110, a second set of historical contact data is received or retrieved. The second set of historical contact data may include the same data received at 1102 or different data, or combinations thereof. The processed data associated with the customers on the list may be also received or retrieved. At 1112, the score indicating the likelihood of a successful contact attempt is computed based on the second data set and the estimated model.
As described above, a methodology is presented that in one embodiment utilizes customer identification and contact data available and processed from historical data to train a statistical model. The model is then used to provide a customer-specific score indicating the likelihood of a successful contact attempt for different time periods.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages, a scripting language such as Perl, VBS or similar languages, and/or functional languages such as Lisp and ML and logic-oriented languages such as Prolog. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The systems and methodologies of the present disclosure may be carried out or executed in a computer system that includes a processing unit, which houses one or more processors and/or cores, memory and other systems components (not shown expressly in the drawing) that implement a computer processing system, or computer that may execute a computer program product. The computer program product may comprise media, for example a hard disk, a compact storage medium such as a compact disc, or other storage devices, which may be read by the processing unit by any techniques known or will be known to the skilled artisan for providing the computer program product to the processing system for execution.
The computer program product may comprise all the respective features enabling the implementation of the methodology described herein, and which—when loaded in a computer system—is able to carry out the methods. Computer program, software program, program, or software, in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form.
The computer processing system that carries out the system and method of the present disclosure may also include a display device such as a monitor or display screen for presenting output displays and providing a display through which the user may input data and interact with the processing system, for instance, in cooperation with input devices such as the keyboard and mouse device or pointing device. The computer processing system may be also connected or coupled to one or more peripheral devices such as the printer, scanner, speaker, and any other devices, directly or via remote connections. The computer processing system may be connected or coupled to one or more other processing systems such as a server, other remote computer processing system, network storage devices, via any one or more of a local Ethernet, WAN connection, Internet, etc. or via any other networking methodologies that connect different computing systems and allow them to communicate with one another. The various functionalities and modules of the systems and methods of the present disclosure may be implemented or carried out distributedly on different processing systems or on any single platform, for instance, accessing data stored locally or distributedly on the network.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements, if any, in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Various aspects of the present disclosure may be embodied as a program, software, or computer instructions embodied in a computer or machine usable or readable medium, which causes the computer or machine to perform the steps of the method when executed on the computer, processor, and/or machine. A program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform various functionalities and methods described in the present disclosure is also provided.
The system and method of the present disclosure may be implemented and run on a general-purpose computer or special-purpose computer system. The computer system may be any type of known or will be known systems and may typically include a processor, memory device, a storage device, input/output devices, internal buses, and/or a communications interface for communicating with other computer systems in conjunction with communication hardware and software, etc.
The terms “computer system” and “computer network” as may be used in the present application may include a variety of combinations of fixed and/or portable computer hardware, software, peripherals, and storage devices. The computer system may include a plurality of individual components that are networked or otherwise linked to perform collaboratively, or may include one or more stand-alone components. The hardware and software components of the computer system of the present application may include and may be included within fixed and portable devices such as desktop, laptop, and/or server. A module may be a component of a device, software, program, or system that implements some “functionality”, which can be embodied as software, hardware, firmware, electronic circuitry, or etc.
The embodiments described above are illustrative examples and it should not be construed that the present invention is limited to these particular embodiments. Thus, various changes and modifications may be effected by one skilled in the art without departing from the spirit or scope of the invention as defined in the appended claims.
