Patent Publication Number: US-2022230103-A1

Title: Machine learning artificial intelligence system for predicting hours of operation

Description:
RELATED APPLICATIONS 
     This application is related to U.S. Provisional Patent Application No. 62/487,529, filed Apr. 20, 2017. The contents of this application are incorporated in their entirety by reference. 
    
    
     TECHNICAL FIELD 
     The present disclosure relates generally to a machine learning artificial intelligence system for modeling hours of operation, and more particularly, to an artificial intelligence system to model a merchant&#39;s hours of operation using credit card authorization data and machine learning. 
     BACKGROUND 
     Consumers often prefer to know whether and when business establishments are open for business, to allow them organize and plan their own schedules. There is no central repository, however, as to when all businesses are open. 
     When a credit card is used to pay for a product, the merchant submits a request to an acquirer bank. The acquirer bank then sends a request to an issuer bank that authorizes or declines the transaction. If the transaction is approved, the issuer bank provides an authorization code to the acquirer bank, which notifies the merchant to complete the transaction. Each request and authorization involved in this process includes data about the merchant, the consumer, and the transaction. For example, credit card authorizations may have time stamps, a merchant identifier, a transaction amount, and an account number, among other things. Therefore, credit card authorizations may be used to make inferences about the merchant, the consumer, or the transaction. Particularly nowadays, when millions of credit card transactions are recorded every day, statistical methods can be used to analyze credit card authorization data, make accurate inferences, and observe trends. 
     Credit card authorizations are normally generated when a merchant is open for operation and serving customers. Typically, merchants submit the credit card authorization requests to the acquirer bank concurrently with a consumer making a purchase. Therefore, credit card authorizations can be used to infer whether the merchant is serving customers and is thus “open.” For example, a restaurant may normally issue multiple credit card authorization requests between 11 am and 1 pm when it serves customers during lunch. Thus, it is possible to infer that the restaurant is open between 11 am and 1 pm, based on credit card authorization requests. On the other hand, the same restaurant may not issue any credit card authorization requests between 1 am and 2 am. Thus, it is possible to infer that the restaurant is “closed” between 1 am and 2 am. Therefore, analysis of credit card authorization data can be used to predict a merchant&#39;s hours of operation. 
     However, making accurate predictions of merchant&#39;s hours of operation based on credit card authorization request data alone may be challenging for several reasons. First, there may be an imperfect correlation between credit card authorization data and hours of operation. For example, a restaurant may open at 10 am but only start issuing credit card authorizations at 10:30 am, when the first customer finishes his or her meal and pays. In this example, the correlation between hours of operation and authorization requests is offset and may lead to prediction errors. Second, data repositories of credit card authorizations may store millions of authorizations per day. The large quantity and variety of authorization formats and merchant practices may make it difficult to effectively process the authorization data. Third, the correlations between credit card authorizations and hours of operation can be dynamic and may be influenced by externalities. For example, the correlation between authorizations and hours of operation may be influenced by merchant location, season, and/or business type. For instance, a merchant may have summer hours of operation that are different to the winter hours of operation. These are some of the difficulties that make prediction of hours of operation challenging, but other variables also affect correlations and predictions. 
     The disclosed machine learning artificial intelligence system and modeling methods address one or more of the problems set forth above and/or other problems in the prior art. 
     SUMMARY 
     One aspect of the present disclosure is directed to an artificial intelligence system for communicating predicted hours of operation to a client device. The system may include a processor in communication with a client device and a database; and a storage medium storing instructions. When executed, the instructions in the storage medium configure the processor to: receive, from the client device, a request for hours of operation of a merchant, the request specifying a day of the week; obtain, from the database in response to the request, a set of credit card authorizations associated with the merchant; determine a selected day authorizations subset by selecting, from the set of credit card authorizations, credit card authorizations issued on the specified day of the week; generate a posted transaction array based on the selected day authorizations subset, the posted transaction array may include a plurality of time intervals and numbers of transactions for the time intervals; generate a predictions list based on the posted transaction array, the predictions list including the time intervals and prediction indications for the time intervals; and communicate the predictions list to the client device. 
     Another aspect of the present disclosure is directed a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to operate an artificial intelligence system for communicating predicted hours of operation to a client device. The instructions may include receiving, from a client device, a request for hours of operation of a merchant, the request specifying a day of the week; obtaining, from a database in response to the request, a set of credit card authorizations associated with the merchant; determining a selected day authorizations subset by selecting, from the set of credit card authorizations, credit card authorizations issued on the specified day of the week; generating a posted transaction array based on the selected day authorizations subset, the posted transaction array including a plurality of time intervals and numbers of transactions for the time intervals; generating a predictions list based on the posted transaction array, the predictions list including the time intervals and prediction indications for the time intervals; and communicating the predictions list to the client device. 
     Yet another aspect of the present disclosure is directed to an artificial intelligence method for communicating hours of operation to a client device, the method including: receiving, from a client device, a request for hours of operation of a merchant, the request specifying a day of the week; obtaining, from a database in response to the request, a set of credit card authorizations associated with the merchant; determining a selected day authorizations subset by selecting, from the set of credit card authorizations, credit card authorizations issued on the specified the day of the week; generating a posted transaction array based on the selected day authorizations subset, the posted transaction array including a plurality of time intervals and numbers of transactions for the time intervals; generating a predictions list based on the posted transaction array, the predictions list including the time intervals and prediction indications for the time intervals; and communicating the predictions list to the client device. 
     Another aspect of the present disclosure is directed to an artificial intelligence system for generating an hours of operation model. The system may include a processor in communication with a prediction system and a database; and a storage medium. The storage medium may include instructions that, when executed, configure the processor to: receive, from a prediction system, a request for an hours of operation model for merchants; determine a merchant classification based on metadata associated with the merchants; obtain, from a ground truth analyzer, ground truth data associated with the merchant classification; obtain, from the database, a set of credit card authorizations associated with the merchant classification; generate input model features based on the set of credit card authorizations; generate a training data set and a validation data set based on the ground truth data and the set of credit card authorizations; determine an hours of operation model based on training data set and the input model features; determine a performance of the hours of operation model based on the validation data set; and communicate the hours of operation model for the merchant to the prediction system. 
     Yet another aspect of the present disclosure is directed to a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to operate an artificial intelligence system for generating an hours of operation model. The instructions may include receiving, from a prediction system, a request for an hours of operation model for merchants; determining a merchant classification based on metadata associated with the merchants; obtaining, from a ground truth analyzer, ground truth data associated with the merchant classification; obtaining, from the database, a set of credit card authorizations associated with the merchant classification; generating input model features based on the set of credit card authorizations; generating a training data set and a validation data set based on the ground truth data and the set of credit card authorizations; determining an hours of operation model based on training data set and the input model features; determining accuracy of the hours of operation model based on the validation data set; and communicating the hours of operation model for the merchant to the prediction system. 
     Another aspect of the present disclosure is directed to an artificial intelligence method for generating an hours of operation model for a prediction system. The method may include receiving, from a prediction system, a request for an hours of operation model for merchants; determining a merchant classification based on metadata associated with the merchants; obtaining, from a around truth analyzer, ground truth data associated with the merchant classification; obtaining, from the database, a set of credit card authorizations associated with the merchant classification; generating input model features based on the set of credit card authorizations generating a training data set and a validation data set based on the ground truth data and the set of credit card authorizations; determining an hours of operation model based on training data set and input model features; determining a performance of the hours of operation model based on the validation data set; and communicating the hours of operation model for the merchant to the prediction system. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate disclosed embodiments and, together with the description, serve to explain the disclosed embodiments. In the drawings: 
         FIG. 1  is a block diagram of an exemplary system, in accordance with disclosed embodiments. 
         FIG. 2  is a block diagram of an exemplary prediction system, in accordance with disclosed embodiments. 
         FIG. 3  is a block diagram of an exemplary model generator, in accordance with disclosed embodiments. 
         FIG. 4  is a block diagram of an exemplary database, in accordance with disclosed embodiments. 
         FIG. 5  is a block diagram of an exemplary client device, in accordance with disclosed embodiments. 
         FIG. 6  is an exemplary flow chart illustrating a prediction process, in accordance with disclosed embodiments. 
         FIG. 7  is an exemplary flow chart illustrating a prediction list generation process, in accordance with disclosed embodiments. 
         FIG. 8  is an exemplary flow chart illustrating a posted transaction array generation process, in accordance with disclosed embodiments. 
         FIG. 9  is an exemplary flow chart illustrating a prediction model generation process, in accordance with disclosed embodiments. 
         FIG. 10A  is an exemplary posted transaction array, in accordance with disclosed embodiments. 
         FIG. 10B  is an exemplary prediction list, in accordance with disclosed embodiments. 
         FIG. 11  is a graph of an exemplary calculation of accuracy as a function of time intervals, in accordance with disclosed embodiments. 
         FIG. 12  is a group of exemplary graphs presenting ground truth and prediction values as a function of time intervals for control examples, according with disclosed embodiments. 
         FIG. 13  is a group of exemplary graphs presenting ground truth and prediction values as a function of time intervals for testing examples, according with disclosed embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     The disclosure is generally directed to a machine learning artificial intelligence system for predicting hours of operation and communicating them to a client device. The artificial intelligence system may model a merchant&#39;s hours of operation using credit card authorization data. In some embodiments, a client device may present to a prediction system a request for a merchant&#39;s hours of operation. The prediction system may analyze credit card authorization data associated with the merchant using prediction models. The prediction models may be generated using machine learning algorithms that study training data sets that associate merchants with corresponding “ground truth,” that is, information provided by direct observation as opposed to information provided by inference. The machine learning algorithms may update and tailor the prediction models based on the client request. The prediction system may output a prediction of hours of operation based on the analysis of credit card authorizations. In some embodiments, the prediction system may be coupled with databases that store credit card authorizations and use data processing methods to curate information and facilitate data analysis. In other embodiments, the prediction system may improve accuracy by using iterative methods in which multiple prediction models are generated and then aggregated. In yet other embodiments, the prediction system may be hardware configured to efficiently conduct filtering, sorting, and parallel calculation tasks to improve computing time and cost. 
     Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings. 
       FIG. 1  is a block diagram of an exemplary system  100 , in accordance with disclosed embodiments. System  100  may be used to predict a merchant&#39;s hours of operation, in accordance with disclosed embodiments. System  100  may include a prediction system  110 , a model generator  120 , financial services  130 , online resources  140 , client devices  150 , merchants  160 , and databases  180 . In some embodiments, as shown in  FIG. 1 , each component of system  100  may be connected to a network  170 . However, in other embodiments components of system  100  may be connected directly with each other, without network  170 . 
     Financial services  130  may be a system associated with a financial service provider, which may be an entity providing financial services. For example, financial services  130  may be associated with a bank, a credit card issuer, or other type of financial service entity that generates, provides, manages, and/or maintains financial service accounts. Financial services  130  may store information about accounts and include, for example, credit card accounts, loan accounts, checking accounts, savings accounts, reward accounts, loyalty program accounts, debit card accounts, cryptocurrency accounts, and/or other types of financial service accounts known to those skilled in the art. Financial services  130  may include infrastructure and components that are configured to generate and/or provide financial service accounts such as credit card accounts, checking accounts, debit card accounts, loyalty or reward programs, lines of credit, and the like. Financial services  130  may authorize or decline credit card authorization requests and may issue authorization codes. 
     Online resources  140  may include one or more servers or storage services provided by an entity such as a provider of website hosting, networking, cloud, or backup services. In some embodiments, online resources  140  may be associated with hosting services or servers that store web pages for merchants  160 . In other embodiments, online resources  140  may be associated with a cloud computing service such as Microsoft Azure™ or Amazon Web Services™. In yet other embodiments, online resources  140  may be associated with a messaging service, such as, for example, Apple Push Notification Service, Azure Mobile Services, or Google Cloud Messaging. In such embodiments, online resources  140  may handle the delivery of messages and notifications related to functions of the disclosed embodiments, such as credit card authorization creation, credit card authorization alerts, and/or completion messages and notifications. 
     Client devices  150  may include one or more computing devices configured to perform one or more operations consistent with disclosed embodiments. For example, client devices  150  may include a desktop computer, a laptop, a server, a mobile device (e.g., tablet, smart phone, etc.), a gaming device, a wearable computing device, or other type of computing device. Client devices  150  may include one or more processors configured to execute software instructions stored in memory, such as memory included in client devices  150 . Client devices  150  may include software that when executed by a processor performs known Internet-related communication and content display processes. For instance, client devices  150  may execute browser software that generates and displays interfaces including content on a display device included in, or connected to, client devices  150 . Client devices  150  may execute applications that allows client devices  150  to communicate with components over network  170 , and generate and display content in interfaces via display devices included in client devices  150 . The disclosed embodiments are not limited to any particular configuration of client devices  150 . For instance, a client device  150  may be a mobile device that stores and executes mobile applications that provide functions offered by prediction system  110  and/or online resources  140 , such as providing information about merchants  160 . In certain embodiments, client devices  150  may be configured to execute software instructions relating to location services, such as GPS locations. For example, client devices  150  may be configured to determine a geographic location and provide location data and time stamp data corresponding to the location data. 
     Merchants  160  may include one or more entities that provide goods, services, and/or information, such as a retailer (e.g., Macy&#39;s®, Target®, etc.), a grocery store, an entertainment venue (e.g. cinema, theater, museum, etc.), a service provider (e.g., utility company, etc.), a restaurant, a bar, a non-profit organization (e.g., ACLU™, AARP®, etc.) or other type of entity that provides goods, services, and/or information that consumers (e.g., end-users or other business entities) may purchase, consume, use, etc. Merchants  160  are not limited to entities associated with any particular business, specific industry, or distinct field. 
     Merchants  160  may include one or more computing systems, such as servers, that are configured to execute stored software instructions to perform operations associated with a merchant, including one or more processes associated with processing purchase transactions, generating transaction data, generating product data (e.g., stock keeping unit (SKU) data) relating to purchase transactions, etc. 
     In some embodiments, merchants  160  may be brick-and-mortar locations that a consumer may physically visit and purchase goods and services. Such physical locations may include merchant paying system  162 , which may include computing devices that perform financial service transactions with consumers (e.g., Point-of-Sale (POS) terminal(s), kiosks, etc.). Merchant paying system  162  may include one or more computing devices configured to perform operations consistent with facilitating purchases at merchants  160 . Merchant paying system  162  may also include back- and/or front-end computing components that store data and execute software instructions to perform operations consistent with disclosed embodiments, such as computers that are operated by employees of the merchant (e.g., back office systems, etc.). 
     While merchant paying system  162  is shown within merchants  160  in  FIG. 1 , in some embodiments merchant paying system  162  may be separated from merchant  160 . For example, merchant paying system  162  may be a different entity that services merchants  160 . In such embodiments, merchants  160  may provide goods and/or services via online solutions. Merchants  160  may sell goods via a website to market, sell, and process online transactions. Then, merchant paying system  162  may provide an infrastructure for online payments. 
     In some embodiments, merchant paying system  162  may include a point-of-sale terminal  166 . In particular, a financial card purchase may be carried out by presenting a financial card at a point-of-sale terminal  166 . Data associated with the financial card may be provided to payment processor  164 , and payment processor  164  may process payment the purchase. For example, payment processor  164  may generate the credit card authorization and include the time stamp and information about the merchant. 
     For each purchase, merchant paying system  162  may collect and/or maintain data identifying the financial card that has been used to make the purchases at merchants  160 . Additionally, merchant paying system  162  may collect and/or maintain data identifying a customer associated with the financial card and/or data identifying a date on which the purchase was made. The merchant paying system  162  may collect and/or maintain other data as well. Data collected and/or maintained by merchant paying system  162  may be provided to databases  180 , model generator  120 , and/or prediction system  110 . 
     In some embodiments, payment processor  164  may be a device configured to collect credit card information and issue credit card authorizations. Payment processor  164  may be a magnetic stripe reader that collects credit card information and connects with a credit card network. In such embodiments, payment processor  164  may include software to append information to the credit card authorization or issue new notifications that facilitate hours-of-operation modeling. For example, payment processor  164  may include a program to flag a credit card authorization, append a time stamp based on a location code (e.g. Zip code™, and specify the merchant&#39;s address. 
     In some embodiments, to simplify the collection of data, payment processor  164  may also be connected to databases  180 . In such embodiments, payment processor  164  may include a communication device that sends information to both financial services  130  (i.e., acquirer bank) and databases  180 . In such embodiments, when payment processor  164  is used to complete a credit card transaction, payment processor  164  may issue a simplified authorization with only time, date, and location. The simplified authorization may then be transmitted to databases  180  and be later used by prediction system  110  or model generator  120 . The simplified authorization improves transmission rates and facilitates selection of authorizations for modeling hours of operation. For instance, simplified credit card authorization records may be easier to filter and sort. In yet other embodiments, payment processor  164  may add information to the credit card authorization for the prediction model. For example, payment processor  164  may append local time and merchant ID to the authorization before sending it to databases  180  and/or financial services  130 . 
     Databases  180  may include one or more computing devices configured with appropriate software to perform operations consistent with providing prediction system  110  and model generator  120  with data associated with merchants  160 . Databases  180  may include, for example, Oracle™ databases, Sybase™ databases, or other relational databases or non-relational databases, such as Hadoop™ sequence files, HBase™, or Cassandra™ Database(s)  180  may include computing components (e.g., database management system, database server, etc.) configured to receive and process requests for data stored in memory devices of the database(s) and to provide data from the database(s). 
     Data associated with merchants  160  may include, for example, historical data identifying authorizations associated with financial cards used to make purchases at merchants  160 . A financial card may represent any manner of making a purchase at merchants  160 . A financial card may be, for example, a financial services product associated with a financial service account, such as a bank card, key fob, or smartcard. For example, a financial card may comprise a credit card, debit card, loyalty card, or other similar financial services product. In some embodiments, a financial card may comprise a digital wallet or payment application. Thus, a financial card is not limited to a specific physical configuration and may be provided in any form capable of performing the functionality of the disclosed embodiments. In some embodiments, a financial card may include or be included in a mobile device; a wearable item, including jewelry, a smart watch, or any other device suitable for carrying or wearing on a customer&#39;s person. Other financial cards are possible as well. Data identifying financial cards used to make purchases at merchants  160  may include, for example, dates on which the purchases were made at merchants  160  and identification of customers associated with the financial cards. 
     Data associated with merchants  160  may further include, for example, data identifying financial cards, dates on which credit card authorizations were issued, and times of the day when credit card authorizations were issued. In some embodiments, data associated with merchants  160  may further include data describing merchant paying system  162 . Data describing merchants  160  may include, for example, data identifying a brand or operator of merchant paying system  162 , data identifying a merchant type associated with merchants  160  (e.g., restaurant, grocery, hair cutter, clothing retailer, etc.), data identifying a geographic location of merchants  160  (e.g., Zip code™, county, state, etc.), data describing a point-of-sale terminal  166  used at merchants  160  (e.g., terminal manufacturer, terminal hardware, terminal software, etc.), and/or data describing a payment processor  164  used by merchants  160  (e.g., processor operator, processor hardware, processor software, etc.). The data describing payment processor  164  used by the merchants  160  may include an indication that a reduced authorization is appended to the authorization. 
     While databases  180  are shown separately, in some embodiments databases  180  may be included in or otherwise related to one or more of prediction system  110 , model generator  120 , financial services  130 , and online resources  140 . 
     Databases  180  may be configured to collect and/or maintain the data associated with merchants  160  and provide it to the prediction system  110 , model generator  120 , financial services  130 , and client devices  150 . Databases  180  may collect the data from a variety of sources, including, for instance, merchants  160 . payment processor  164 , model generator  120 , and/or third-party systems (not shown). Other sources of data associated with merchants  160  are possible as well. Databases  180  are further described below in connection with  FIG. 4 . 
     Model generator  120  may include one or more computing systems configured to generate prediction models to estimate hours of operations using credit card authorizations. Model generator  120  may receive or obtain information from databases  180 , merchants  160 , online resources  140 , and financial services  130 . For example, model generator  120  may receive credit card authorization records from databases  180  and merchants  160 . Model generator  120  may also receive information about hours of operation from online resources  140  and financial services  130 . 
     In some embodiments, model generator  120  may receive requests from prediction system  110 . As a response to the request, model generator  120  may generate one or more prediction models. Prediction models may include statistical algorithms that are used to determine the probability of an outcome, given a set amount of input data. For example, prediction models may include regression models that estimate the relationships among input and output variables. Prediction models may also sort elements of a dataset using one or more classifiers to determine the probability of a specific outcome. Prediction models may be parametric, non-parametric, and/or semi-parametric models. 
     In some embodiments, prediction models may cluster points of data in functional groups such as “random forests.” Random Forests may comprise combinations of decision tree predictors. (Decision trees may comprise a data structure mapping observations about something, in the “branch” of the tree, to conclusions about that thing&#39;s target value, in the “leaves” of the tree.) Each tree may depend on the values of a random vector sampled independently and with the same distribution for all trees in the forest. Prediction models may also include artificial neural networks. Artificial neural networks may model input/output relationships of variables and parameters by generating a number of interconnected nodes which contain an activation function. The activation function of a node may define a resulting output of that node given an argument or a set of arguments. Artificial neural networks may generate patterns to the network via an ‘input layer’, which communicates to one or more “hidden layers” where the system determines regressions via a weighted connections. Prediction models may additionally or alternatively include classification and regression trees, or other types of models known to those skilled in the art. Model generator  120  may submit models to predict hours of operation. To generate prediction models, model generator  120  may analyze information applying machine-learning methods. Model generator  120  may communicate back with prediction system  110  via network  170  or other communication avenues. Model generator  120  is further described below in connection with  FIG. 3 . 
     Prediction system  110  may include one or more computing systems configured to perform one or more operations consistent with modeling the hours of operation of merchants  160 . In some embodiments, prediction system  110  may receive a request for information. Prediction system  110  may receive the request directly from client devices  150 . Alternatively, prediction system may receive the request from other components of system  100 . For example, client devices  150  may send requests to online resources  140 , which then sends requests to prediction system  110 . The request may specify a merchant and a day of the week. Additionally, in some embodiments the request may specify a date. In other embodiments, the request may be done for a plurality of merchants and a minimum prediction confidence. 
     As a response to information requests, prediction system  110  may request prediction models from model generator  120 . The request may include information about the merchant. The request may additionally specify a day of the week. In addition, prediction system  110  may retrieve information from databases  180 . 
     Prediction system  110  may generate a prediction result based on the information received from the client request and transmit the information to the client device. Prediction system  110  may plot the prediction result. Prediction system  110  is further described below in connection with  FIG. 2 . 
       FIG. 1  shows prediction system  110  and model generator  120  as a different components. However, prediction system  110  and model generator  120  may be implemented in the same computing system. For example, prediction system  110  and model generator  120  may be embodied in a single server. 
     Network  170  may be any type of network configured to provide communications between components of system  100 . For example, network  170  may be any type of network (including infrastructure) that provides communications, exchanges information, and/or facilitates the exchange of information, such as the Internet, a Local Area Network, near field communication (NFC), optical code scanner, or other suitable connection(s) that enables the sending and receiving of information between the components of system  100 . In other embodiments, one or more components of system  100  may communicate directly through a dedicated communication link(s). 
     It is to be understood that the configuration and boundaries of the functional building blocks of system  100  have been defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. 
       FIG. 2  is a block diagram of an exemplary prediction system, in accordance with disclosed embodiments. Prediction system  110  may include a communication device  212 , a prediction memory  220 , and one or more prediction processors  208 . Prediction memory  220  may include prediction programs  222  and prediction data  224 . Prediction processor  230  may include authorization selector  232 , authorization aggregator  234 , and prediction engine  236 . 
     In some embodiments, prediction system  110  may take the form of a server, general purpose computer, mainframe computer, or any combination of these components. Other implementations consistent with disclosed embodiments are possible as well. 
     Communication device  210  may be configured to communicate with one or more databases, such as databases  180  described above. In particular, communication device  210  may be configured to receive from the database data associated with merchants  160 . In addition, communication device  210  may be configured to communicate with other components as well, including, for example, merchant payment system  166  and model generator  120 . 
     Communication device  210  may include, for example, one or more digital and/or analog devices that allow communication device  210  to communicate with and/or detect other components, such as a network controller and/or wireless adaptor for communicating over the Internet. Other implementations consistent with disclosed embodiments are possible as well. 
     Prediction memory  220  may include one or more storage devices configured to store instructions used by prediction processor  230  to perform functions related to disclosed embodiments. For example, prediction memory  220  may store software instructions, such as prediction program  222 , that may perform one or more operations when executed by prediction processor  230 . The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, prediction memory  220  may include a single prediction program  222  that performs the functions of prediction system  110 , or prediction program  222  may comprise multiple programs. Prediction memory  220  may also store prediction data  224  that is used by prediction program(s)  222 . 
     In certain embodiments, prediction memory  220  may store sets of instructions for carrying out processes to model hours of operation, generate a prediction list, and/or generate a posted transaction array, described below in connection with  FIGS. 6-8 . In certain embodiments, prediction memory  220  may store sets of instructions for generating graphical objects, such as the ones described below in connection with  FIGS. 11-13 . Other instructions are possible as well. In general, instructions may be executed by prediction processor  230  to perform one or more processes consistent with disclosed embodiments. 
     In some embodiments, prediction processor  230  may include one or more known processing devices, such as, but not limited to, microprocessors from the Pentium™ or Xeon™ family manufactured by Intel™, the Turion™ family manufactured by AMD™, or any of various processors from other manufacturers. However, in other embodiments, prediction processor  230  may be a plurality of devices coupled and configured to perform functions in accordance with the disclosure. 
     Prediction processor  230  may include an authorization selector  232 , an authorization aggregator  234 , and a prediction engine  236 . In some embodiments, prediction processor  230  may execute software to perform functions associated with each component of prediction processor  230 . In other embodiments, each component of prediction processor  230  may be an independent device. In such embodiments, each component may be hardware configured to specifically process data or perform operations associated with modeling hours of operation, generating prediction models and/or handling large data sets. For example, authorization selector  232  may be a field-programmable gate array (FPGA), authorization aggregator  234  may be a Graphics processing unit (GPU), and prediction engine  236  may be a central processing unit (CPU). Other hardware combinations are also possible. In yet other embodiments, combinations of hardware and software may be used to implement prediction processor  230 . 
     Authorization selector  232  may select credit card authorizations from databases  180  based on parameters such as a day of the week, a specific merchant, and/or a merchant identification. For example, communication device  210  may receive from databases  180  a set of credit card authorizations. The set of credit card authorizations may include multiple credit card authorizations recorded during a selectable or variable period of time. For example, the period of time may be selected to be at least one year so the set of credit card authorizations represent every season throughout the year. Authorization selector  232  may select a subset of credit card authorizations that are associated with a merchant by filtering the data set. In some embodiments, authorization selector  232  may employ techniques such as the pigeonhole principle, hierarchical verification, and the PEX algorithm, to filter and select credit card authorizations. In some embodiments, authorization selector  232  may compare specific fields of the credit card authorization to accept or discard authorizations. For example, authorization selector  232  may select credit card authorizations using information appended by payment processor  164 . 
     In some embodiments, prediction processor  230  may implement authorization selector  232  by executing instructions to create an environment in which credit card authorizations are selected. In other embodiments, however, authorization selector  232  may be a separate device or group of devices. In such embodiments, authorization selector  232  may include hardware configured to carry out filtering tasks. For example, to improve performance and minimize costs, authorization selector  232  may be an SRAM-based FPGA that functions as authorization selector  232 . Authorization selector  232  may have an architecture designed for implementation of specific algorithms. For example, authorization selector  232  may include a Simple Risc Computer (SRC) architecture or other reconfigurable computing system. 
     Authorization aggregator  234  may determine time intervals and create a frequency table for the intervals. The frequency table may represent the number of authorizations that were issued during a time interval for a merchant. Authorization aggregator  234  may create the frequency table using time stamps associated with the credit card authorizations. For example, authorization aggregator  234  may receive a group of credit card authorizations such as shown in Table 1, below, and calculate a frequency table of authorizations using the time intervals presented in Table 2. 
     
       
         
           
               
               
               
               
               
             
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Authorization No. 
                 Time 
                 Merchant 
                 Amount 
               
               
                   
                   
               
             
            
               
                   
               
            
           
           
               
               
               
               
               
            
               
                   
                 1458 
                 11:30 
                 A 
                 $58 
               
               
                   
                 3221 
                 11:32 
                 A 
                 $23 
               
               
                   
                 4434 
                 11:45 
                 A 
                 $93 
               
               
                   
                 6244 
                 12:40 
                 A 
                 $11 
               
               
                   
                 7985 
                 12:41 
                 A 
                 $13 
               
               
                   
                 9499 
                 12:42 
                 A 
                 $61 
               
               
                   
                 10765 
                 16:40 
                 A 
                 $92 
               
               
                   
                 12164 
                 16:45 
                 A 
                 $24 
               
               
                   
                   
               
            
           
         
       
     
     
       
         
           
               
               
               
             
               
                   
                 TABLE 2 
               
               
                   
                   
               
               
                   
                 Time interval 
                 Frequency 
               
               
                   
                   
               
             
            
               
                   
               
            
           
           
               
               
               
            
               
                   
                 11:30-12:00 
                 3 
               
               
                   
                 12:30-13:00 
                 2 
               
               
                   
                 16:30-17:00 
                 2 
               
               
                   
                   
               
            
           
         
       
     
     Prediction processor  230  may implement authorization aggregator  234  by executing software to create an environment for aggregation of credit card authorizations. However, in other embodiments authorization aggregator  234  may include independent hardware with specific architectures to improve the efficiency of aggregation or sorting processes. For example, authorization aggregator  234  may be a GPU array configured to sort credit card authorizations. In some embodiments, authorization aggregator  234  may be configured to implement sorting algorithms such as, for example, radix sort. Alternatively or additionally, authorization aggregator  234  may be configured to implement a programming interface, such as Apache Spark, and execute data structures, cluster managers, and/or distributed storage systems. For example, authorization aggregator  234  may include a resilient distributed dataset that is manipulated with a standalone software framework and/or a distributed file system. 
     Prediction engine  236  may calculate a prediction indication based on one or more models and a selected credit card authorization data set. For example, prediction engine  236  may use a model from model generator  120  and apply inputs based on a posted transaction array to generate a prediction list of hours of operation for merchant  160 . 
     Prediction engine  236  may be implemented by prediction processor  230 . For example, prediction processor  230  may execute software to create an environment to execute models. However, in other embodiments prediction engine  236  may include hardware configured to carry out parallel operations. Some hardware configurations improve the efficiency of calculations, particularly when multiple calculations are being processed in parallel. For example, prediction engine  236  may include multicore processors or computer clusters to divide tasks and quickly perform calculations. In some embodiments, prediction engine may receive a plurality of models from model generator  120 . In such embodiments, prediction engine  236  may include a scheduling module. The scheduling module may receive models and assign each model to independent processors or cores. In other embodiments, prediction engine  236  may be FPGA Arrays to provide greater performance and determinism. 
     The components of prediction system  110  may be implemented in hardware, software, or a combination of both, as will be apparent to those skilled in the art. For example, although one or more components of prediction system  110  may be implemented as computer processing instructions embodied in computer software, all or a portion of the functionality of prediction system  110  may be implemented in dedicated hardware. For instance, groups of GPUs and/or FPGAs maybe used to quickly analyze data in prediction processor  230 . 
       FIG. 3  is a block diagram of an exemplary model generator, in accordance with disclosed embodiments. Model generator  120  may include training data module  330 , a model processor  340 , a model memory  350 , and a communication device  360 . 
     One of the fundamental challenges in obtaining accurate hours-of-operation predictions based on credit card authorization data is the lack of sufficient training data sets. Training sets are sets of data used to discover potentially predictive relationships. They may include an input vector and an answer vector, that are used together to train an AI machine or a knowledge database. A training data set may only be sufficient when it includes a number of samples that enables an artificial intelligence machine or a regression model to be “trained” (e.g., initialized) with an acceptable confidence interval. Sufficient training data sets may include samples that represent the full distribution to be modeled and have enough samples to identify outliers and minimize deviations. In some embodiments, training data sets include a validation subset and a test subset. In such embodiments, each one of the subsets must include a representative sample size. 
     In some embodiments, training data sets associate credit card authorizations with ground truth hours of operation, that is, actual hours of operation information as specified by merchants and obtained directly or indirectly from the merchants. Training data sets may include information of brick and mortar merchants with “open” and “closed” hours, permanently dosed merchants as negative controls (e.g., merchants that changed locations), and permanently open merchants as positive controls (e.g., online retailers). While collecting credit card authorization information issued by merchants  160  can be done by retrieving information from databases  180  or financial services  130 , there is no central source for ground truth of the hours of operation of merchants  160 . In some embodiments model generator  120  may include a training data module  330  that monitors network  170  and online resources  140  to capture ground truth and facilitate generating the training data set. Training data module  330  may combine and select information to generate the training data sets used to generate prediction models. 
     Training data module  330  includes an event detector  310 , ground truth analyzer  320 , and training filter  332 . 
     Event detector  310  may be a software or hardware module configured to detect events in network  170  that may be relevant to model generator  120 . In some embodiments, event detector  310  may be configured to detect when merchants  160  issue a credit card authorization. In such embodiments, event detector  310  may signal model generator  120  to request the authorization information and build the training data set. In addition, event detector  310  may be configured to detect changes in online resources  140 . For example, online resources  140  may include web sites operated by merchants  160 . If the website is updated, event detector  310  may detect changes and request that ground truth analyzer  320  investigate the changes and update records. Event detector  310  may create a system to automatically update a training data set of hours of operation. Event detector  310  may detect merchants  160  that are actively issuing credit cards, and may have the ability to monitor changes of ground truth to automatically generate a training data set. 
     Merchant hours of operation are dynamic; that is, businesses change their hours of operation, and temporarily or permanently open or close new locations. Event detector  310  may facilitate updating databases to keep up-to-date information by monitoring the network  170  and flagging transactions that can be used in the training data set. 
     Ground truth analyzer  320  may include software or hardware modules configured to collect and organize data that is associated with merchants  160 . For example, ground truth analyzer  320  may be configured to collect hours of operation from online resources  140 . Ground truth analyzer  320  may collect information using a “bot,” such as a web scraper, to automatically fetch and extract information from websites such as yellowpages.com™, Google™, or Yelp™. In some embodiments, ground truth analyzer  320  may download source code of web pages and parse, search, reformat, and copy data. Ground truth analyzer  320  may sort information to select information about merchants  160 . 
     In some embodiments, ground truth analyzer  320  may use text pattern matching, html parsing, vertical aggregation, or semantic annotation recognizing, among other processes. Ground truth analyzer  320  may include tools to look for hours of operation. For example, in some embodiments a web scraper may be configured to look for text formats of “XX:XX-XX:XX” where X is a digit. In other embodiments, a web scraper may be configured to recognize labels in html code such as “&lt;time itemprop=“openingHours”&gt;, “&lt;datetime“Tu,Th 13:00-20:00”&gt;,” or “&lt;p&gt;Open: Monday-Thursday 9am-noon&lt;/p&gt;.” 
     In other embodiments ground truth analyzer  320  may include crowd-sourced services to obtain information about a merchant. In yet other embodiments, ground truth analyzer  320  may include a verification service that uses phone calls to retrieve information. For example ground truth analyzer  320  may include an automated calling service that calls merchants phone numbers. In such embodiments, ground truth analyzer  320  may determine whether the merchant is open or closed based on the phone call response. For example, ground truth analyzer  320  may include auto dialer software that calls merchants. Ground truth analyzer  320  may determine that the businesses are open any time merchants  160  pick up the phone but assume merchants  160  are dosed if there is no answer. 
     Training data module  330  may include software or hardware modules configured to create a training data set. Training data module  330  may create the training data set by combining credit card authorizations from a group of merchants and ground truth information for the same group of merchants. For example, communication device  360  may receive a collection of credit card authorizations generated by a group of merchants. If ground truth analyzer  320  has identified hours of operation about the same group of merchants, training data module  330  may combine these data sets to create a training data set that includes credit card authorizations and ground truth for a group of merchants. 
     Model processor  340  may include a processor similar to prediction processor  230 . Model processor may include a data normalizer  342 , a training data filter  344 , and accuracy estimator  348 , and a model builder  346 . 
     Data normalizer  342  may include hardware or software modules configured to normalize information under certain parameters. For example, data normalizer  342  may normalize time stamps by setting them in the same local time zone or to UTC time. Alternatively, data normalizer  342  may adjust time stamps based on a Zip code™ associated with a merchant that issued a credit card authorization request. 
     Training data filter  344  may have a similar configuration to authorization selector  232  but instead of filtering credit card authorizations associated with merchants  160 , training data filter  344  may select a training data subset before it is used to generate models. The accuracy of the model used to predict hours may vary significantly when different data sets are used. For example, predicting hours of operation of a restaurant using a training data set that is based on grocery stores may undermine the prediction&#39;s accuracy. For this reason, training data filter  344  may be configured to select training data sets based on, for example, the category of the merchant in client devices  150  requests. Then, the training data set may be constrained to certain types of credit card authorizations or models. 
     Model builder  346  may be software or hardware configured to create prediction models based on the training data. In some embodiments, model builder  346  may generate decision trees. For example, model builder  346  may take training data to generate nodes, splits, and branches in a decision tree. Model builder  346  may calculate coefficients and hyper parameters of a decision tree based on the training data set. In other embodiments, model builder  346  may use Bayesian algorithms or clustering algorithms to generate predicting models. In yet other embodiments, model builder  346  may use association rule mining, artificial neural networks, and/or deep learning algorithms to develop models. In some embodiments, to improve the efficiency of the model generation, model builder  346  may be hardware configured to generate models for hours of operation. For example, model builder  346  may be an FPGA. 
     Accuracy estimator  348  may be software or hardware configured to evaluate the accuracy of a model. For example, accuracy estimator may estimate the accuracy of a model, generated by model build  346 , by using a validation dataset. In some embodiments, the validation data set is a portion of the training data set, that was not used to generate the prediction model. Accuracy estimator may generate error rates for each one of the prediction models. Accuracy estimator  348  may additionally assign weight coefficients to models based on the estimated accuracy. 
       FIG. 4  is a block diagram of an exemplary database  180 , in accordance with disclosed embodiments. Database  180  may include a communication device  402 , one or more database processors  404 , and database memory  410  including one or more database programs  412  and data  414 . 
     In some embodiments, databases  180  may take the form of servers, general purpose computers, mainframe computers, or any combination of these components. Other implementations consistent with disclosed embodiments are possible as well. 
     Communication device  402  may be configured to communicate with one or more components of system  100 , such as merchants  160 , prediction system  110 , model generator  120 , and/or financial services  130 . In particular, communication device  402  may be configured to provide to the prediction system  110  and model generator  120  data associated with a number of merchants. 
     Communication device  402  may be configured to communicate with other components as well, including, for example, one or more merchant payment systems, such as merchant payment system  166  described above, and one or more financial services  130  and/or online resources  140 . Communication device  402  may take any of the forms described above for communication device  210 . 
     Database processors  404 , database memory  410 , database programs  412 , and data  414  may take any of the forms described above for prediction processors  230 , memory  220 , prediction programs  222 , and prediction data  224 , respectively. The components of databases  180  may be implemented in hardware, software, or a combination of both hardware and software, as will be apparent to those skilled in the art. For example, although one or more components of databases  180  may be implemented as computer processing instruction modules, all or a portion of the functionality of databases  180  may be implemented instead in dedicated electronics hardware. 
     Data  414  may be data associated with a number of merchants, such as merchant(s)  160 . Data  414  may include, for example, credit card authorization data. Data  414  may describe purchases made by customers at merchants using financial cards. 
       FIG. 5  is a block diagram of an exemplary client device, in accordance with disclosed embodiments. In one embodiment, client devices  150  may include one or more processors  502 , one or more input/output (I/O) devices  504 , and one or more memories  510 . In some embodiments, client devices  150  may take the form of mobile computing devices such as smartphones or tablets, general purpose computers, or any combination of these components. Alternatively, client devices  150  (or systems including client devices  150 ) may be configured as a particular apparatus, embedded system, dedicated circuit, and the like based on the storage, execution, and/or implementation of the software instructions that perform one or more operations consistent with the disclosed embodiments. According to some embodiments, client devices  150  may comprise web browsers or similar computing devices that access web site consistent with disclosed embodiments. 
     Processor  502  may include one or more known processing devices, such as mobile device microprocessors manufactured by Intel™, NVIDIA™, or various processors from other manufacturers. The disclosed embodiments are not limited to any specific type of processor configured in client devices  150 . 
     Memory  510  may include one or more storage devices configured to store instructions used by processor  502  to perform functions related to disclosed embodiments. For example, memory  510  may be configured with one or more software instructions, such as programs  512  that may perform one or more operations when executed by processor  502 . The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, memory  510  may include a single program  302  that performs the functions of the client devices  150 , or program  312  may comprise multiple programs. Memory  510  may also store data  314  that is used by one or more programs  312 . 
     In certain embodiments, memory  510  may store an hours-of-operation application  514  that may be executed by processor(s)  502  to perform one or more prediction processes consistent with disclosed embodiments. In certain aspects, hours-of-operation application  514 , or another software component, may be configured to request predictions from prediction system  110  or determine the location of client devices  150 . For instance, these software instructions, when executed by processor(s)  502  may process information to generate a request for hours of operation. 
     I/O devices  504  may include one or more devices configured to allow data to be received and/or transmitted by client devices  150  and to allow client devices  150  to communicate with other machines and devices, such as other components of system  100 . For example, I/O devices  504  may include a screen for displaying optical payment methods such as Quick Response Codes (OR), or providing information to the user. I/O devices  504  may also include components for NFC communication. I/O devices  504  may also include one or more digital and/or analog devices that allow a user to interact with client devices  150  such as a touch-sensitive area, buttons, or microphones. I/O devices  504  may also include one or more accelerometers to detect the orientation and inertia of client devices  150 . I/O devices  504  may also include other components known in the art for interacting with prediction system  110 , merchants  160 , and/or financial services  130 . 
     The components of client devices  150  may be implemented in hardware, software, or a combination of both hardware and software, as will be apparent to those skilled in the art. 
       FIG. 6  is an exemplary flow chart illustrating a prediction process, in accordance with disclosed embodiments. In some embodiments, prediction process  600  may be executed by prediction system  110 . 
     Prediction system  110  may receive requests for hours of operation from client devices  150 , or other components of system  100 , in step  602 . These requests may come in the form of an Internet protocol message, a query data packet, or a port opening instruction, and may further include information of client devices  150  and specify one or more merchants  160 . For example, the requests may specify name and/or identification number of merchants  160 . The requests may also specify a day of the week to be used as a parameter to predict opening and closing times and/or a location associated with the client devices  150  and merchants  160 . 
     In step  604  prediction system  110  may obtain credit card authorizations associated with the one or more merchants  160  specified in the requests. For example, prediction system  110  may query databases  180  to obtain all the credit card transactions that have been issued by the merchants  160  associated with the requests. In some embodiments, prediction system  110  may limit the query to a subset of the credit card authorizations issued by merchants  160 . For example, prediction system  110  may request only credit card authorizations that have been issued for a specific day. Also, prediction system  110  may request credit card authorizations issued in the last year, in the last month, or between two dates. 
     In step  606 , prediction system  110  may filter, or select, a portion of the data received from the database based on information contained in the received requests. For example, in embodiments where prediction system  110  retrieves all credit card authorizations issued by a merchant, prediction system  110  may select credit card authorizations issued on the day of the week specified in the request. In other applications, prediction system  110  may select only credit card authorizations above certain dollar amount. In yet other applications, prediction system  110  may receive a set of credit card authorizations and determine a subset of credit card authorizations based on the requests. For example, prediction system  110  may determine a subset of credit card authorizations based on day of the week specified by the request. 
     In some embodiments, prediction system  110  may filter the credit card authorization data retrieved from databases  180  to simplify future analysis. In such embodiments, authorization selector  232  may curate and classify credit card data authorizations. For example, authorization selector  232  may use information from the requests issued by client devices  150  to create a subset of credit card authorizations. Authorization selector  232  may use information associated with credit card authorizations to select or discard authorizations. For example, authorization selector  232  may discard authorizations that are not generated in within the specified day of the week. Also, authorization selector  232  may remove transactions considered abnormal. For example, authorization selector  232  may disregard authorizations that have a dollar amount significantly different from the other authorizations. Such authorizations may represent credit card activity that is not related with hours of operation. For example, a merchant that wholesales to other businesses may make large sales after hours to a selected distributor while the merchant is not being open to the public. Those transactions that do not correlate with hours of operation may be filtered based on transaction amount or other related parameters. 
     In some embodiments prediction system  110  and authorization selector  232  may use data-mining algorithms to efficiently curate, parse, and/or filter the credit card authorizations. For example, prediction system  110  may use algorithms such as C4.5, Support Vector Machines, Apriori algorithm, Expectation-maximization algorithm, among others, to handle large data sets of credit card authorizations. 
     In step  610  prediction system  110  may determine a total number of authorizations for the selected day authorizations subset. In some embodiments, prediction system  110  may aggregate the number of authorizations to determine a total number of authorizations for the specified day of the week. 
     In step  612 , prediction system  110  may determine whether the quantity of credit card authorizations is sufficient to make an accurate prediction. In some embodiments, prediction system  110  may determine a threshold number of transactions over a period of time. For example, prediction system  110  may set a threshold of 50 transactions over a 5 month period. If the threshold is not met, then prediction system  110  may determine that the quantity of authorizations is insufficient. In other embodiments, prediction system  110  may determine that the quantity of credit card authorizations is not sufficient if the oldest record is less than 5 months old. In yet other embodiments, prediction system  110  may determine the quantity is not sufficient if a requested prediction accuracy cannot be met with the available records. For example, client devices  150  may request a minimum prediction accuracy of 90%. Prediction system  110  may determine a minimum quantity of credit card authorizations required to achieve the requested prediction accuracy. If the available quantity of credit card authorizations is less than the determined minimum, prediction system  110  may return an error message reporting that there are not enough records to make the prediction. 
     If prediction system  110  determines that there is not enough data, process  600  continues to step  614  in which the prediction system may return an error message. In some embodiments, the error message may be sent to online resources  140  which then may send a message to client devices  150 . In such embodiments, online resources  140  may transmit default values for hours of operation to client devices  150  or simply not send any data for hours of operation. Additionally or alternatively, prediction system  110  may send the error message to merchants  160  to indicate that potential customers cannot access hours of operation. Alternatively, if prediction system  110  determines that there is enough data, it continues to step  616 . 
     In step  616 , prediction system  110  determines time intervals for the hours of operation analysis, for example, 30 minutes. In some embodiments, the time intervals may be determined based on a classification for merchant  160 . In other embodiments, the time intervals may be based on the requests for information. In yet other embodiments, prediction system  110  may determine time intervals based on time rules. 
     Time rules may instruct prediction system  110  to determine time intervals with equal time length that do not overlap each other. Also, time rules may instruct prediction system  110  to have time intervals wherein the sum of time lengths equals one day. Time rules may additionally instruct prediction system  110  to determine time intervals of 30 minutes. For example a full day may be divided in 48 time intervals of half an hour. Half hour time intervals facilitate the prediction process as they match with standard business hours. Alternatively, time rules may instruct prediction system  110  to determine time intervals of other or varying length and that may or may not overlap with each other. 
     In step  618 , prediction system  618  may generate a posted transactions array. The posted transaction array may associate the determined time intervals with an aggregated number of transactions. For example, authorization aggregator  234  may utilize the plurality of times to generate an array that indicates how many transactions were recorded for a given time period. 
     In some embodiments, prediction system  110  may adjust the posted transactions array based on the total number of authorizations for the selected day. For example, authorization aggregator  234  may normalize the number of aggregated authorizations using the total number of transactions. In such embodiments, prediction system  110  may use the total number of authorizations to prevent over reliance in a single merchant. Using the absolute number of transactions to create prediction models may result in a model dominated by large merchants that post many transactions. Such models may be inaccurate when predicting hours of operation of smaller merchants or may result in models that have poor adaptation. Thus, prediction system  110  may adjust the posted transactions using the total number of authorizations to smooth the effect of large merchants with many transactions and extract patterns that are insensitive to absolute volume of transactions (e.g., normalizing). 
     In step  620 , prediction system  110  generates a prediction list. In some embodiments, prediction system  110  generates the prediction list by determining, for each one of the time intervals in the posted transaction array, prediction probabilities. The prediction probabilities may be calculated using prediction models from model generator  120 . Each prediction model may output a model result, which may be a probability between 0-100%. 
     Step  620  may be carried out by prediction engine  236 . Prediction engine may compute a probability of a merchant being open or closed. For example, in step  620  prediction system  110  may request from model generator  120  one or more models to predict hours of operation for a selected merchant. Prediction system  110  may then send prediction models and credit card authorization data to prediction engine  236  to perform the probability calculations. 
     In some embodiments, prediction engine  236  may receive a plurality of models from model generator  120  and compute probabilities independently for each one of the models. Prediction engine  236  may then tally each one of the prediction model results. In such embodiments, prediction engine  236  may determine an accuracy value for each model and each model result. For example, based on the evaluation performed by accuracy estimator  348 , prediction engine  236  may determine an accuracy value for each model and each model result. Then prediction engine  236  may assign weighting coefficients to the models based on the accuracy values. In such embodiments, prediction engine  236  may modify the computed probability for each one of the models (i.e. the model results) using the assigned weighting coefficient to calculate a total prediction. For example, total prediction may be defined by: 
     
       
         
           
             
               Total 
               ⁢ 
               
                   
               
               ⁢ 
               Prediction 
             
             = 
             
               
                 
                   ∑ 
                   
                     i 
                     = 
                     0 
                   
                   j 
                 
                 ⁢ 
                 
                   
                     α 
                     i 
                   
                   * 
                   M 
                   ⁢ 
                   
                       
                   
                   ⁢ 
                   
                     R 
                     i 
                   
                 
               
               N 
             
           
         
       
     
     where TotalPrediction is the value to be stored in the prediction list, j is the total number of models retrieved from model generator  120 , α is the assigned coefficient (which is a function of the determine accuracy), and MR is the model result for one prediction model, and N is a normalization value. Thus, prediction engine  236  may add modified tree results to determine a total prediction. The total prediction may be used to determine a prediction indication, such as “open” or “closed.” 
     In step  622 , prediction system  110  may communicate the results list to the client that issued the request. For example, prediction system  110  may communicate the request with a list of Boolean values indicating whether the merchant is open or closed during each half-hour interval of the day for the day of the week as specified in the original request. 
       FIG. 7  is an exemplary flow chart illustrating a prediction list generation process, in accordance with disclosed embodiments. Prediction list generation process  700  may be carried out by prediction system  110 . 
     In step  702 , prediction system  110  may determine whether there is a classification associated with the merchant. For example, prediction system  110  may determine if the merchant to be analyzed is a restaurant, a grocery store, a bar, etc. It may do so using the credit card authorization data retrieved from the databases  180 . For example, in some embodiments prediction system  110  may use Federal Identification Codes (FIC) in the credit card authorization requests to determine a merchant classification. 
     In step  704 , prediction system  110  may obtain a model for the merchant. In some embodiments, prediction system  110  may send a request to model generator  120  to generate prediction models for the merchant. Model generator  120  may respond with one or more prediction models for the merchant based on, for example, the classification for the merchant and the day of the week. For instance, model generator  120  may send to prediction system  110  a group of prediction models specifically for restaurants open on Saturdays. 
     In step  706 , prediction system  110  may prepare to carry out an iterative calculation to estimate a prediction indication for each one of the time intervals. The status of the looping variable is then tested in step  708 . If the looping variable indicates the iterative process is culminated, prediction system  110  may send the prediction list to the client in step  710 . Alternatively, if the looping variable indicates the iterative process is not culminated, prediction system  110  may continue to step  712  and calculate a prediction for a time interval using the group of models. To carry out step  712  prediction system  110  may send a request for calculation to prediction engine  236 . 
     In step  712 , prediction system  110  may tally results of prediction models as previously disclosed for step  620  and save the estimated total prediction in a prediction list in step  716 . In some embodiments, prediction system  110  may generate a prediction indication based on the total prediction value. In some embodiments, the prediction indication may be a Boolean value, such as “open” or “closed” value. In other embodiments, the prediction indication may represent a status associated with the total prediction value. For example, the prediction indication may be “likely open,” “likely closed,” “out of business,” or “24/7 open.” 
     In step  718 , prediction system  110  may modify the looping variable to continue the iterations. 
       FIG. 8  is an exemplary flow chart illustrating a posted transaction array generation process, in accordance with disclosed embodiments. Posted transaction array generation process  800  may be carried out by prediction system  110 . 
     In step  802 , prediction system  110  may adjust information in the credit card authorizations. For example, in some embodiments the credit card authorizations may comprise time stamps. In such embodiments, prediction system  110  may adjust the time stamps in credit card authorizations based on a location code associated with merchants  160  to facilitate generating the prediction list. For example, a credit card authorization system may always record time stamps in Eastern Standard Time, regardless of merchant&#39;s  160  location. Then prediction system  110  may adjust the time stamp of the credit card authorization based on a location code associated with the merchant. For example, prediction system  110  may adjust time stamps using the Zip codes™ of merchants  160 . 
     In step  804 , prediction system  10  may associate the credit card authorization with a time interval. In some embodiments, prediction system  110  may sort credit card authorizations using the time stamp associated with the credit card authorizations. In such embodiments, prediction system  110  may utilize sorting algorithms to process data and obtain the categories that associate time intervals and the credit card authorizations. 
     In step  806 , prediction system  110  may aggregate the number of authorizations issued within the time intervals to generate a frequency table that quantifies the number of times a credit card authorization was issued for in a time interval. 
     In step  808 , prediction system  110  may generate a posted transaction array using the information of the number of authorizations and data. 
       FIG. 9  is an exemplary flow chart illustrating a model generation process, in accordance with disclosed embodiments. In some embodiments, model generator  120  may carry out model generator process  900 . 
     In step  902 , model generator  120  may receive a request for prediction models. In some embodiments, the request may specify a merchant, a time of the day, and/or a merchant classification. For example, prediction system  110  may send a request for prediction models. The request may include information about merchants  160  and/or client devices  150 . 
     In step  904 , model generator  120  may generate a training data set. Model generator  120  may generate the training data set using information from databases  180 , online resources  140 , and/or financial services  130 . For example, model generator  120  may retrieve, from databases  180 , credit card authorizations associated with a group of merchants  160 . Model generator  120  may also collect a ground truth data set, from the ground truth analyzer  320 , associated with the same group of merchants. Training data module  330  may merge or combine these data sets to generate a training data set. In some embodiments, training data module  330  may be configured to rate the accuracy of information in the data set. For example, training data module  330  may create ground truth accuracy scores for merchants  160 . When ground truth analyzer is highly confident of hours of operation for merchants  160 , for example ground truth analyzer verified the determined hours of operation on a website of merchants  160 , then training data module  330  may assign a high ground truth accuracy score. Alternatively, if ground truth analyzer  320  is not confident of hours of operation, for example hours of operation were guessed based on phone calls responded, then training data module  330  may assign a low score. Ground truth accuracy scores may enable including more merchants  160  in the training data set. Even if the ground truth information is not verified for a group of merchants  160 , training data module  330  may still include those merchants and tailor the model&#39;s reliance on those samples with the ground truth accuracy score. 
     In some embodiments, model generator  120  may generate input model features based on credit card authorizations associated with a group of merchants  160 . Model features may represent a variable useful for prediction that may be used in the prediction solution. For example, model features may include the number of credit card authorizations issued by merchants  160  within a period, a location associated with the credit card authorizations, or a merchant type. In certain embodiments, model generator  120  may generate multiple model features and determine a feature importance score for all the generated features. The feature importance score may reflect the correlation between the selected features and other identified features. For example, model generator  120  may assign a high importance score to a variable or feature that exhibits a high correlation with the other identified features. Alternatively, a feature with low correlation with respect to other features may be assigned a low importance score. Furthermore, in additional or alternative embodiments, the model features may be categorized based in the influence they have in the target result. In some embodiments, the input model features may then be used to determine a model. For example, in a decision tree input model features may be used to make node determinations. 
     In some embodiments, model generator  120  may generate model features using techniques such as Principal Component analysis and/or unsupervised clustering methods. In other embodiments model generator  120  may include line or edge detection, or Digital Signal Processing (DSP) methods. In such embodiments, model generator  120  may implement iterative regressions to evaluate features. For example, model generator  120  may execute algorithms such as least absolute shrinkage and selection operator to determine least squares models for each generated feature to estimate a feature behavior. 
     In some embodiments, training data module  330  may select data based on the request for a prediction model of step  902 . For example, prediction system  110  may request a model from model generator  120  for a restaurant on Saturday. Training data module  330  may generate a training data set only using credit card authorization and ground truth only for restaurants on Saturdays. 
     In step  906 , model generator  120  may create training data subsets by dividing the training data set. In some embodiments, model generator  120  may divide the training data set randomly creating random training subsets. Then, prediction models may be generated using the randomly selected subsets of the training data set. Elements in the training data subsets may be unique to each subset to create independent training data subsets. Alternatively, training data subsets may share elements and overlap. In other embodiments, model generator  120  may divide the training data set using division rules. 
     The training data set division rules may indicate the number of divisions and/or ratios between different groups. For example, the training data set may be divided using an 80/20 split for testing and validation data. Training data division rules may also specify the training data set should be divided in three portions. A first portion to calculate coefficients for a model, a second portion used to calculate hyper parameters associated with a model, and a third portion used to validate and calculate accuracy of the model. Division rules may be a function of the information included in the request for a prediction model. For example, if the request specifies the model is for a restaurant, model generator  120  may apply a 60/40 split for testing and validation to have stricter accuracy measurements. 
     Model generator  120  may generate a candidate model using a training data set. For example, model generator may process the training data set of step  906  to determine coefficients (step  908 ) and hyper parameters (step  910 ) for a prediction model. The prediction models may be parametric, non-parametric, or semi-parametric. 
     In some embodiments, model generator  120  may create a plurality of decision trees as prediction models. For example, model generator  120  may use a top-down or a bottom-up approach to generate candidate decision trees in steps  908  and  910 . In such embodiments, model generator  120  may generate nodes by finding a discrete function of the input attributes values using a training data set or a training data subset. Based on a splitting metric, a coefficient may be assigned to the node. Decision trees created by model generator  120  may then be used in a random forest analysis. 
     In other embodiments, model generator  120  may generate neural networks, Group Method of Data Handling (GMDH) algorithms, Naive Bayes classifiers, and/or Multivariate Adaptive Regression Splines. For example, model generator  120  may implement Convolutional Neural Networks (CNN), generating nodes and connections associated with multiple dimensions using the training data. CNNs consist of multiple layers of receptive fields and various combinations of convolutional and fully connected layers. Additionally, model generator  120  may implement Recurrent Neural Networks (RNN), generating nodes and connections with directed cycles that dynamically adjust to behaviors of the training data. 
     In some embodiments, model generator  120  may generate candidate models under defined constraints. For example, in embodiments in which the generated models are decision trees, model generator  120  may be constrained to have a maximum depth of 10 node levels. 
     In step  914 , model generator  120  may evaluate if the model is completed or if it has reached a stopping criteria. For example, when model generator  120  generates decision trees, in step  914  model generator  120  may evaluate if a stopping criteria is fulfilled for the end nodes. In some embodiments, stopping criteria may be intrinsic to the model or defined by hyper parameters. For example, the stopping criteria may be achieved when all the samples there is no further classifications or variables to further split the model. Alternatively, the stopping criteria may be defined by user imposed constrains and hyper variables. 
     If the stop criteria in not fulfilled, model generator  120  may continue to step  916  and select a new variables or parameters to determine new classifiers. In embodiments in which model generator  120  generates a decision tree, in step  916  model generator  120  may select a new function for splitting a subset of the training data set after the first split in the root node. If the splitting results are above a splitting ratio then model generator  120  may include a new node in the decision tree. In other embodiments, model generator  120  may continue adding nodes or modes to the model in step  916 . After developing the model, model generator  120  may return to step  914  and evaluate again if the model is completed. 
     Alternatively, when the stop criteria is fulfilled, model generator  120  may continue to step  918 , in which model generator  120  calculate the accuracy of the model using a portion of the training data set. Model generator  120  may use, for example, information gain, Gini index, likelihood-ratio chi-square statistics, Dietterich Kearns, and Mansour (DKM) splitting criterion, and/or normalized impurity based criteria to evaluate accuracy of the generated model. In some embodiments, model generator  120  may also generate a receiver operating characteristic curve to evaluate the performance of a binary classifier. 
     In step  920 , model generator  120  may evaluate whether the accuracy for the model is above an accuracy threshold. In some embodiments, the accuracy threshold for the model may be automatically adjusted based on optimization objectives set for the prediction models. If the model is not above the threshold (step  920 : No) the model may be discarded in step  926 . If the calculated accuracy is above the threshold (step  920 : Yes), model generator  120  may assign a weighted coefficient to the model in step  922  and include the model to the set of models in step  924 . The weighted coefficient may associated with the calculated accuracy. For example, the weighted coefficient may be proportional to the accuracy. 
     Process  900  may be repeated a plurality of times to generate a plurality of models. In some embodiments, model generator  120  may repeat the process until a minimum of models is generated. For example, prediction system  110  may request that model generator  120  generates models for a random forest analysis. In such embodiments, model generator  120  may generate between 20-100 decision trees to conduct the prediction analysis. Less than 20 models may not provide the required accuracy while more than a 100 decision trees may demand too much computing power. In such embodiments, prediction system may require at least 50 decision trees. 
       FIG. 10A  is an exemplary posted transaction array  1010 , in accordance with disclosed embodiments. Prediction system  110  may generate posted transaction array  1010  in, for example, step  618  of  FIG. 6 . Posted transaction array  1010  may be issued by authorization aggregator  234 , and may associate time intervals  1012  with aggregated number of authorizations  1014 . 
     Time intervals  1012  may have a start time and an end time, may be determined by prediction system  110 , and may have different formats. While  FIG. 10A  shows independent and sequential time intervals, time intervals need not be sequential or independent. For example, time intervals may overlap, or may be non-consecutive. 
     Aggregated number of authorizations  1014  may indicate the total number of authorizations that were issued by a merchant during the time interval. Prediction system  110  may generate a frequency table by adding the number of credit card transactions for each time interval. 
       FIG. 10B  is an exemplary prediction list  1020 , in accordance with disclosed embodiments. In some embodiments prediction list  1020  may be generated by prediction system  110 , for example, at step  620 . In such embodiments prediction list  1020  may be generated by prediction engine  236 . Prediction list  1020  may associate time intervals  1022  with a prediction indication  1024 . 
     Prediction time intervals  1022  may be based on transaction time interval  1012 . In some embodiments, prediction time intervals  1022  may replicate transaction time intervals  1012 . In other embodiments, prediction time interval  1022  may be a subset of transaction time intervals. For example, some prediction time intervals may group two or more transaction time intervals if they a have similar number of authorizations  1014  to facilitate plotting an minimizing transmission time. 
     Prediction list  1020  may include prediction indications  1024 , In some embodiments, prediction indications  1024  may be Boolean and indicate whether the prediction model calculates the merchant to be open or closed. In other embodiments, however, prediction indication  1024  may be a category associated with the prediction probability. For example, prediction indication  1024  may assign a label such as “likely open,” “likely closed,” “out of business,” or “24/7 open.” 
     Prediction list  1020  may include probability values  1026 . Probability indications  1026  may represent a calculated prediction probability for the merchant being open at the time intervals. Alternatively, probability indications  1026  may represent a calculated prediction probability for the merchant being closed at the time intervals. Probability indications  1026  may be based on the model results that are estimated in step  714 . 
       FIG. 11  is a graph of an exemplary prediction accuracy calculation as a function of a time interval, in accordance with disclosed embodiments. Information presented in  FIG. 11  may be generated by model generator  120  at, for example, step  918 . 
       FIG. 11  presents a plot in which the x-axis presets a time interval, for example time intervals  1012  ( FIG. 10 ), and the y-axis represent an accuracy estimation. The accuracy estimation may calculate accuracy of the model using the a training data subset. The accuracy calculation may be performed for each one of the time intervals. In some embodiments, accuracy may represent the ratio of correct predictions to the total number of cases evaluated. In other embodiments, accuracy may represent the area under the curve of receiver operating characteristic (ROC) curve. In yet other embodiments, accuracy may represent a positive predictive value or a sensitivity for a specific criterion value or a group of criterion values. For example, accuracy may be the positive predictive value for an optimal criterion based on costs. 
       FIG. 12  shows graphs of two exemplary comparative results, presenting a ground truth and a prediction as a function of a time interval for control merchants, according with disclosed embodiments. The comparative results are presented in plots where the X axis represents a time interval, for example time intervals  1022  ( FIG. 10 ), and the Y axis represents a predicted probability of the merchant being open (for the prediction solid line) and the hours of operation ground truth (dotted line). 
     Example 1 shows results for a negative control. Merchant in Example 1 is never open. For example, the merchant in Example 1 may be a closed business. Therefore the ground truth plot shows that the merchant is always closed. In Example 1, the prediction, calculated by prediction system  110  using credit card authorization data, is always low. In Example 1, because the merchant is closed, the merchant does not issue any credit card authorizations. Therefore prediction system  110  generates a prediction list with low probabilities for all time intervals. 
     Example 2 shows results for a positive control. The merchant in example 2 is always open. For example, the merchant in Example 1 is an online business that does not close and continuously receives orders and issues credit card authorizations. Therefore the ground truth plot shows that the merchant is always open. In Example 1, the prediction is always high. In Example 2, the merchant constantly receives orders and issues credit card authorizations. Therefore, prediction system  110  generates a prediction list with high probabilities for all time intervals. 
       FIG. 13  shows graphs of exemplary comparative results presenting a ground truth and a prediction as a function of a time interval for testing merchants, according with disclosed embodiments.  FIG. 13  presents plots similar to the ones in  FIG. 12  with the same coordinate axes. Examples 3-6 show predicted and around truth hours of operation for four different merchants. 
     Merchants of Examples 3-6 open and close within a day. The dotted line represent the ground truth of hours of operation while the solid line represent the prediction probability of the merchant being open or closed. Examples in  FIG. 13  show that the prediction generally follows the hours of operation for each merchant. The prediction is low with the merchant is closed while the prediction is high when the merchant is open. 
     In some embodiments the prediction can be further classified in a binary state. For example in some embodiments, prediction system  110  may determine any prediction probability above 50% is open while any prediction below 50% is closed. In other embodiments prediction system  110  may classify in different states. For example prediction probabilities below 25% may have a status of “closed”, prediction probabilities between 25-50% may have a status of “likely closed,” prediction probabilities between 50-75% may have a status of “likely open,” and prediction probabilities between 75-100% may have a status of “open.” 
     Another aspect of the disclosure is directed to a non-transitory computer-readable medium storing instructions that, when executed, cause one or more processors to perform the methods, as discussed above. The computer-readable medium may include volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other types of computer-readable medium or computer-readable storage devices. For example, the computer-readable medium may be the storage unit or the memory module having the computer instructions stored thereon, as disclosed. In some embodiments, the computer-readable medium may be a disc or a flash drive having the computer instructions stored thereon. 
     It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed remote control system and related methods. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed remote control system and related methods. It is intended that the specification and examples be considered as exemplary only, with a true scope being indicated by the following claims and their equivalents