Patent Application
20230070215
The present disclosure relates generally to the field of payment transactions and, more particularly, to systems and methods for managing payment transactions between bank accounts associated with a consumer and a merchant.
Traditionally, merchants have point of sale (POS) terminals and POS systems that accept payments from consumers for goods and services rendered. Merchants typically contract an acquirer to process the payment transactions originating from the merchant's POS terminals and POS systems. The acquirer processors process the payment transactions and settle funds between consumers' and merchants' accounts. However, such processing methods rely on complex communications among multiple entities in order to process a transaction without taking advantage of ubiquitous modern technology infrastructure.
Typically, the acquirer processors charge substantial fees to the merchants for processing each payment card transaction. A large portion of these high fees may be pass-through fees from the card-issuing banks, e.g., interchange fees, and the card networks, e.g., assessment fees. Furthermore, timing is important to merchants and they may prefer to receive payments from the consumers as soon as possible, but the complex communication channels that involve acquirer processors delay the payment delivery.
Consumers may prefer the convenience of payment by the payment card because the fees are not directly reflected in the cost of the items being purchased. Though invisible to consumers, the pass-through fees burden the consumers by indirectly increasing the cost of goods and services. In addition, consumers may prefer the payments for goods and services to be delayed so that they have the freedom to pay over time without the need to obtain credit.
Accordingly, there is a need for systems and methods for efficient routing and settlement of payment transactions between bank accounts associated with a registered user and a merchant.
According to certain aspects of the disclosure, systems and methods are disclosed for providing configuration parameters in a streamlined manner so that developers can construct end-to-end solutions in an automated manner.
In one embodiment, a method is disclosed for routing and settling payment transactions between bank accounts associated with a registered user and a merchant. The method includes: determining, in real-time, a plurality of transactions for a payment account associated with a payment vehicle of a registered user; aggregating outstanding amount associated with the plurality of transactions for the payment account based, at least in part, on a first preset time period; transmitting payments for the aggregated outstanding amount to a plurality of recipient accounts associated with merchants to the plurality of transactions based, at least in part, on the first preset time period, a pre-determined total outstanding amount threshold, or a combination thereof; aggregating the transmitted payments based, at least in part, on a second preset time period, wherein the first preset time period is a subset of the second preset time period; deducting an amount that equals the aggregated transmitted payments from the payment account based, at least in part, on the second preset time period; and generating a user interface element in a user interface of a device associated with the registered user, wherein the user interface element includes a notification on the deduction of the aggregated transmitted payments from the payment account.
In one embodiment, an apparatus comprises at least one processor, and at least one memory including computer program code for one or more computer programs, the at least one memory and the computer program code configured to, with the at least one processor, cause, at least in part, the apparatus to route and settle payment transactions between bank accounts associated with a registered user and a merchant. The apparatus causes: determining, in real-time, a plurality of transactions for a payment account associated with a payment vehicle of a registered user; aggregating outstanding amount associated with the plurality of transactions for the payment account based, at least in part, on a first preset time period; transmitting payments for the aggregated outstanding amount to a plurality of recipient accounts associated with merchants to the plurality of transactions based, at least in part, on the first preset time period, a pre-determined total outstanding amount threshold, or a combination thereof; aggregating the transmitted payments based, at least in part, on a second preset time period, wherein the first preset time period is a subset of the second preset time period; deducting an amount that equals the aggregated transmitted payments from the payment account based, at least in part, on the second preset time period; and generating a user interface element in a user interface of a device associated with the registered user, wherein the user interface element includes a notification on the deduction of the aggregated transmitted payments from the payment account.
In accordance with another embodiment, a non-transitory computer-readable storage medium having stored thereon one or more program instructions which, when executed by one or more processors, cause, at least in part, an apparatus to route and settle payment transactions between bank accounts associated with a registered user and a merchant. The apparatus causes: determining, in real-time, a plurality of transactions for a payment account associated with a payment vehicle of a registered user; aggregating outstanding amount associated with the plurality of transactions for the payment account based, at least in part, on a first preset time period; transmitting payments for the aggregated outstanding amount to a plurality of recipient accounts associated with merchants to the plurality of transactions based, at least in part, on the first preset time period, a pre-determined total outstanding amount threshold, or a combination thereof; aggregating the transmitted payments based, at least in part, on a second preset time period, wherein the first preset time period is a subset of the second preset time period; deducting an amount that equals the aggregated transmitted payments from the payment account based, at least in part, on the second preset time period; and generating a user interface element in a user interface of a device associated with the registered user, wherein the user interface element includes a notification on the deduction of the aggregated transmitted payments from the payment account.
Additional objects and advantages of the disclosed embodiments will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosed embodiments. The objects and advantages on the disclosed embodiments will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the detailed embodiments, as claimed.
It may be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and together with the description, serve to explain the principles of the disclosed embodiments.
While principles of the present disclosure are described herein with reference to illustrative embodiments for particular applications, it should be understood that the disclosure is not limited thereto. Those having ordinary skill in the art and access to the teachings provided herein will recognize additional modifications, applications, embodiments, and substitution of equivalents all fall within the scope of the embodiments described herein. Accordingly, the invention is not to be considered as limited by the foregoing description.
Various embodiments of the present disclosure relate generally to smart forms and, more particularly, to a smart forms solution that enables large as well as mid-tier transactions (e.g., financial) institutions to provide configuration parameters in a streamlined manner so that developers can construct end-to-end solutions in an automated manner.
As described above, existing methods and systems for electronic payment transaction processing rely on complex communications among multiple entities in order to process a transaction without taking advantage of ubiquitous modern technology infrastructure. For example, in a traditional payment processing system, a consumer, during a checkout process with a merchant, pays for goods or services via payment vehicle at a POS terminal. Because merchants generally can use a different bank or financial institution than a consumer, an acquirer processor (not shown) handles the financial transactions between the financial institution of the consumer and that of the merchant. Merchant submitting payment transaction requests according to these traditional methods may encounter processing delays and higher fees from various intermediaries, e.g., acquirer processors, involved in the transaction. In the early days of payment transaction processing, such intermediaries were necessary because of the limited communication and data processing capabilities available to most merchants. However, modern communication and data processing capabilities make it possible for merchants to more readily connect to financial institutions directly. The embodiments of the present disclosure are directed to providing systems and methods for processing electronic payment transactions that take advantage of modern technology infrastructure.
Furthermore, at the time of purchase, a transaction is implemented in a process that involves authorization and capture of the payment amount. The payment amount of purchase transactions are recorded and settled at some point. Though merchants may desire to have the settlement occur as soon as possible, there are delays in the settlement of payments. Since payments are not final, and the dispute resolution process is expensive, merchants have no recourse. Thus, a merchant submitting payment transaction requests by the methods disclosed herein may achieve savings in reduced processing delays and/or avoided processing fees.
In addition, the pluralities of intermediaries involved in payment transactions may not have the same security or commitment to privacy as a bank, and may struggle to balance data availability, data confidentiality, and data integrity. So, there may be a risk for consumers' personal information to be hacked, misused, or intercepted. The consumers' submitting payment transaction requests by the methods disclosed herein may take advantage of a secure intra-bank or inter-bank payment method where the bank plays the role of both payer and payee, and carries out payment transactions on private networks to transfer funds.
In one embodiment, consumer 101 may be an individual, a company, or other entity having accounts with issuer 105. Consumer 101 may generally have at least one payment vehicle 103 associated with a payment account with issuer 105. In one embodiment, consumer 101 is a registered user for payment-related services with transaction processing system 109.
In one embodiment, payment vehicle 103 may refer to any type of alternative to currency. As is to be clear to those skilled in the art, no aspect of the present disclosure is specifically limited to a specific type of payment vehicle. Therefore, it is intended that the following description encompasses the use of the present disclosure with many other forms of financial alternatives to currency, including debit cards, smart cards, single-use cards, prepaid cards, electronic currency (such as might be provided through a cellular telephone or personal digital assistant), credit cards, and the like. Payment vehicles can be traditional plastic transaction cards, titanium-containing, or other metal-containing, transaction cards, clear and/or translucent transaction cards, foldable or otherwise unconventionally-sized transaction cards, radio-frequency enabled transaction cards, or other types of transaction cards, such as debit, prepaid or stored-value cards, electronic benefit transfer cards, charge, credit, or any other like financial transaction instrument. In one embodiment, payment vehicle 103 may be used as a means of authentication, and no amount is levied to payment vehicle 103.
In one embodiment, issuer 105 is a bank that manages payment accounts on behalf of consumer 101. For example, issuer 105 may hold accounts for consumer 101, and consumer 101 may have a payment vehicle 103 affiliated with that account. In another embodiment, issuer 105 is the bank that manages recipient accounts on behalf of merchant 113. For example, issuer 105 may hold accounts for merchant 113, and merchant 113 may receive payments for the goods and services rendered in that account.
Further, various elements of system 100 may communicate with each other through communication network 107. Communication network 107 may support a variety of different communication protocols and communication techniques. In one embodiment, communication network 107 allows transaction processing system 109 to communicate with consumer 101, issuer 105, and merchant 113. The communication network 107 of system 100 includes one or more networks such as a data network, a wireless network, a telephony network, or any combination thereof. It is contemplated that the data network may be any local area network (LAN), metropolitan area network (MAN), wide area network (WAN), a public data network (e.g., the Internet), short range wireless network, or any other suitable packet-switched network, such as a commercially owned, proprietary packet-switched network, e.g., a proprietary cable or fiber-optic network, and the like, or any combination thereof. In addition, the wireless network may be, for example, a cellular communication network and may employ various technologies including 5G (5th Generation), 4G, 3G, 2G, Long Term Evolution (LTE), wireless fidelity (Wi-Fi), Bluetooth®, Internet Protocol (IP) data casting, satellite, mobile ad-hoc network (MANET), vehicle controller area network (CAN bus), and the like, or any combination thereof.
In one embodiment, transaction processing system 109 may be a platform with multiple interconnected components. Transaction processing system 109 may include one or more servers, intelligent networking devices, computing devices, components, and corresponding software for routing and settling payment transactions between bank accounts associated with a registered user and a merchant to a transaction. In addition, it is noted that transaction processing system 109 may be a separate entity of system 100. Further details of transaction processing system 109 are provided below.
In one embodiment, database 111 may be any type of database, such as relational, hierarchical, object-oriented, and/or the like, wherein data are organized in any suitable manner, including as data tables or lookup tables. In one embodiment, database 111 may store and manage multiple types of information that can provide means for aiding in the content provisioning and sharing process. In an embodiment, database 111 may include a machine-learning based training database with pre-defined mapping defining a relationship between various input parameters and output parameters based on various statistical methods. In an embodiment, the training database may include machine-learning algorithms to learn mappings between input parameters related to the user such as but not limited to financial transaction information, online activity information, historical user information and interests, contextual information, travel information, etc. In an embodiment, the training database may include a dataset that may include data collections that are not subject-specific, i.e., data collections based on population-wide observations, local, regional or super-regional observations, and the like. Exemplary datasets include retail data, market data, geographic data, encyclopedias, business information, financial information, and the like. In an embodiment, the training database is routinely updated and/or supplemented based on machine learning methods.
Merchant 113 may be a merchant offering goods and/or services for sale to consumer 101. Merchant 113 may be equipped with a POS device (not shown), which is configured to receive payment information from payment vehicle 103 and to relay received payment information to transaction processing system 109. Merchant 113 can be any type of merchants, such as a brick-and-mortar retail location or an e-commerce/web-based merchant with a POS device or a web payment interface. In one embodiment, merchant 113 is registered with transaction processing system 109 for payment-related services.
In one embodiment, the user equipment (UE) 115 may include, but is not restricted to, any type of a mobile terminal, wireless terminal, fixed terminal, or portable terminal. Examples of the UE 115, may include, but are not restricted to, a mobile handset, a wireless communication device, a station, a unit, a device, a multimedia computer, a multimedia tablet, an Internet node, a communicator, a desktop computer, a laptop computer, a notebook computer, a netbook computer, a tablet computer, a Personal Communication System (PCS) device, a personal navigation device, a Personal Digital Assistant (PDA), a digital camera/camcorder, an infotainment system, a dashboard computer, a television device, or any combination thereof, including the accessories and peripherals of these devices, or any combination thereof. In addition, the UE 115 may facilitate various input means for receiving and generating information, including, but not restricted to, a touch screen capability, a keyboard, and keypad data entry, a voice-based input mechanism, and the like. Any known and future implementations of the UE 115 may also be applicable.
By way of example, UE 115, issuer 105, transaction processing system 109, and merchant 113 communicate with each other and other components of the communication network 107 using well-known, new or still developing protocols. In this context, a protocol includes a set of rules defining how the network nodes within the communication network 107 interact with each other based on information sent over the communication links. The protocols are effective at different layers of operation within each node, from generating and receiving physical signals of various types, to selecting a link for transferring those signals, to the format of information indicated by those signals, to identifying which software application executing on a computer system sends or receives the information. The conceptually different layers of protocols for exchanging information over a network are described in the Open Systems Interconnection (OSI) Reference Model.
Communications between the network nodes are typically effected by exchanging discrete packets of data. Each packet typically comprises (1) header information associated with a particular protocol, and (2) payload information that follows the header information and contains information that may be processed independently of that particular protocol. In some protocols, the packet includes (3) trailer information following the payload and indicating the end of the payload information. The header includes information such as the source of the packet, its destination, the length of the payload, and other properties used by the protocol. Often, the data in the payload for the particular protocol includes a header and payload for a different protocol associated with a different, higher layer of the OSI Reference Model. The header for a particular protocol typically indicates a type for the next protocol contained in its payload. The higher layer protocol is said to be encapsulated in the lower layer protocol. The headers included in a packet traversing multiple heterogeneous networks, such as the Internet, typically include a physical (layer 1) header, a data-link (layer 2) header, an internetwork (layer 3) header and a transport (layer 4) header, and various application (layer 5, layer 6 and layer 7) headers as defined by the OSI Reference Model.
In one embodiment, data collection module 201 may automatically collect relevant data associated with registered users or potential users through various data collection techniques. For example, the data collection module 201 may use a web-crawling component to access various databases or other information sources to determine the online activities information of the registered users or potential users. Data collection module 201 may be programmed to collect, in real-time, financial information pertaining to the registered users or potential users, so that the risk identification, analysis, response, monitoring, and control may be performed using the most recent data. In one example embodiment, data collection module 201 may include a software application, e.g., data mining applications in Extended Meta Language (XML), that automatically search for and return relevant information pertaining to the registered users or potential users. In one embodiment, data collection module 201 comprises context information processing module 301, matching module 303, and recommendation module 305.
In one embodiment, context information processing module 301 may determine context information associated with registered users, devices associated with the registered users, payment vehicles associated with the registered users, or a combination thereof. By way of example, the context information may include users' computing environment, users' data environment, online activities, historical information, preference information, spending patterns, or a combination thereof. Once received, context information processing module 301 may analyze the context information to trigger the execution of user interface module 309 in presenting relevant content to the registered users. In one example embodiment, context information processing module 301 may determine that a registered user regularly uses an online shopping portal to purchase goods and services, user interface module 309 may present an advertisement for a payment-related service on the online shopping portal to grab the user's attention.
In one embodiment, matching module 303 may retrieve a plurality of content from one or more devices, payment vehicles, or a combination thereof associated with the registered users. Matching module 303 may compare and evaluate the retrieved content with the corresponding data record to determine a degree of similarity. In one embodiment, matching module 303 may implement a text matching process or an image matching process, e.g., grid point matching, to compare and evaluate content for similarity. In one embodiment, matching module 303 may utilize one or more algorithms, e.g., machine learning algorithms, to determine a match for the content based, at least in part, on the comparison. Based on this matching, similar content is clustered in the same category for the registered users. In another embodiment, matching module 303 may match consumer 101, e.g., consumer ID, with merchant 113, e.g., merchant ID, based on their unique identification number. In one example embodiment, a transaction involves consumer 101 spending money for goods and services at one or more merchants 113, e.g., train travel expenses, filling car at a gas station, fast food meal, etc. Matching module 303 may co-relate consumer 101 with each of the merchants to the transactions based on their unique identification number.
In one embodiment, recommendation module 305 may implement a deep learning-based recommendation system that aims to provide adaptive user representations which can process many forms of user interest/signal by assessing interests over the short-term vs. long-term. In another embodiment, recommendation module 305 may present a ranking of the registered users based, at least in part, on their financial history information and real-time financial information. In a further embodiment, recommendation module 305 may recommend potential users based on their financial history or may disapprove potential users based on their deficient financial history.
In one embodiment, registration module 203 comprises user interface module 309, authentication module 311, and enrollment module 313 to register one or more potential users. In one embodiment, user interface module 309 enables a presentation of a graphical user interface (GUI) in a device associated with a user (hereinafter “user devices”). User interface module 309 employs various application programming interfaces (APIs) or other function calls corresponding to the applications on the user devices, thus enabling the display of graphics primitives such as icons, menus, buttons, data entry fields, etc., for generating the user interface elements. In a further embodiment, user interface module 309 may cause interfacing of the guidance information with one or more users to include, at least in part, one or more annotations, audio messages, or a combination thereof. Still further, user interface module 309 may be configured to operate in connection with augmented reality (AR) processing techniques, wherein various applications, graphic elements, and features may interact. In one example embodiment, user interface module 309 may display a login widget in the user device, and the login widget may be linked to the payment facilitator computing system. User interface module 309 may ensure that the login widget is distinctive to be recognized by the users and unobtrusive to avoid any negative user experiences while visiting the linked websites. In a further example embodiment, user interface module 309 may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, storage devices, and the like.
In one embodiment, authentication module 311 authenticates users and their devices for interaction with transaction processing system 109. It is noted that the authentication may include a first-time registration procedure for establishing one or more profile settings. In one embodiment, authentication may include receiving and validating a login name and/or user identification value as provided or established for a particular user during a registration process with the service provider. In one embodiment, the authentication procedure may also be performed through the automated association of database 111 with an IP address, a carrier detection signal of a user device, mobile directory number (MDN), subscriber identity module (SIM) (e.g., of a SIM card), radiofrequency identifier (RFID) tag or other identifiers. These means of authentication reduces privacy concern related to data sharing services.
Enrollment module 313 may enroll a user and/or a device associated with the user for payment-related service if the user desires enrollment. In one embodiment, enrollment module 313 may determine the eligibility of a user for enrollment based, at least in part, on information received from authentication module 311. In another embodiment, enrollment module 313 may comprise of a logic configured to determine the eligibility of a user for enrollment based, at least in part, on historical user information. In one instance, historical user information may include credit rating information, credit history information, adequate income, reasonable debt-to-income ratio, online fraud information, crime information, and the like. If the user and/or device associated with the user are eligible for enrollment, enrollment module 313 presents an enrollment offer in the user interface module 309. If the user responds positively to an enrollment offer, i.e., wants to be enrolled, enrollment module 313 may enroll the user and/or the device by updating a user profile associated with the user to reflect the enrollment of the user and/or device.
In one embodiment, account management module 205 may set up, modify, manage, and control a payment-related service account of a user. In one embodiment, account management module 205 comprises aggregation module 315, settlement module 317, and exception handling module 319.
In one embodiment, aggregation module 315 may collect or receive a set of transaction information, e.g., a log, a listing, a history, a file, a data structure, and/or other record types, associated with the registered users. Aggregation module 315 may classify the aggregated set of transaction information into various categories for efficient processing. In one embodiment, aggregation module 315 may collect or receive transaction information in real-time or per scheduled time interval.
In one embodiment, settlement module 317 may determine an optimal settlement path between the registered user and the merchants to a transaction. Settlement module 317 may implement sophisticated rules engine that accesses account information, payee information, banking rules and/or other information in performing transaction decisions. In one embodiment, settlement module 317 may process the categorized transaction information to determine whether the financial institution associated with the merchant is within the network of financial institutions of transaction processing system 109. Upon determining the merchant is within the network of financial institutions, e.g., merchant 113 hold an account at the same financial institution as consumer 101, settlement module 317 initiates reconciliation of payments per the methods described herein.
In one embodiment, exception handling module 319 may detect transaction errors, e.g., failed transactions, rejected transactions, unfunded account rejections, etc., for registered users. In one example embodiment, exception handling module 319 may determine that the bank account of the registered user cannot be debited, e.g., insufficient amount. In one instance, exception handling module 319 may debit the bank account of the registered user during the next time interval or may levy a penalty based at least in part on information received from data collection module 201. In one example embodiment, exception handling module 319 may detect failed transactions for a registered user, and may alert the registered users on such failed transactions with recommendations on resolving the issue.
Risk assessment module 207 may perform the functions of risk identification, risk impacts, development of corresponding responses, and monitoring and control of risks. Risk assessment module 207 may execute one or more probability and/or statistical methods to determine a risk assessment value associated with a registered user. Risk assessment module 207 may periodically, per schedule, or in real-time monitor financial records of the registered users to determine a risk assessment value. For example, if a registered user or a potential user previously defaulted in their payments, e.g., refuse to pay the amount owed, or declared bankruptcy, risk assessment module 207 may predict higher risk in enrolling such users. In one example embodiment, risk assessment module 207 may assess payment data across different accounts, historical payment data across several accounts, to generate a financial risk score. In one embodiment, risk assessment module 207 comprises fraud management module 323 and loss management module 325.
In one embodiment, fraud management module 323 may monitor, in real-time, transactions of one or more registered users to detect anomalies during transactions, and may either block or flag the fraudulent transaction for review. Fraud management module 323 may maintain a whitelist and a blacklist of merchants based on the monitoring. In one example embodiment, fraud management module 323 may determine fraudulent transactions based on IP addresses or historical transaction information of the merchants to the transactions. In one embodiment, consumer 101 may whitelist or blacklist merchant 113. In another example embodiment, fraud management module 323 may apply an address verification service (AVS) to compare the billing address supplied by a user to the address on file with the issuing bank. A mismatch in address information may be a sign of fraud. In a further example embodiment, fraud management module 323 may detect multiple failed purchase attempts in succession from a user and may block access to the user. In another embodiment, merchant 113 may whitelist or blacklist consumer 101.
In one embodiment, loss management module 325 may monitor, detect, correct, or control sources of financial damage. Loss management module 325 may develop and implement policies and best practices that are designed to identify and minimize any risks that can lead to losses.
In one embodiment, training module 209 trains machine learning module 211 using various inputs to enable machine learning module 211 to automatically find contextual information associated with a registered user and/or a potential user from unstructured data. In another embodiment, training module 209 trains machine learning module 211 using various inputs to identify key data, e.g., descriptive data, supplemental data, etc., related to financial information of a registered user and/or a potential user. In a further embodiment, training module 209 trains machine learning module 211 using various inputs to enable machine learning module 211 to combine unstructured data with structured data to improve the accuracy of artificial intelligence models, validate data, and leverage for advisors and customer engagement. In one instance, the training module 209 can continuously provide and/or update machine learning module 211 during training using, for instance, supervised deep convolution network or equivalents.
In one embodiment, machine learning module 211 is data-driven and takes into account different combinations of the data. As can be appreciated by one skilled in the art, machine learning techniques can be used to predict and improve the potency of the user's data. Machine learning can ingest the user's data, draw parallels and conclusions across disparate data sets to provide refined data. The refined data can then be abstracted further by performing operations such as categorizing, coding, transforming, interpreting, summarizing, and calculating. Further, the abstracted data can be used in the future for decision-making. In one embodiment, machine learning module 211 may estimate the expense pattern of a registered user based, at least in part, on spending habits, shopping cart contents, etc. In another embodiment, the machine learning module 211 may also analyze historical records of the registered users to suggest different data points and outcomes to provide timely credit rating/scores. In an exemplary embodiment, data abstraction can be done by reviewing the user's payment transaction information and abstracting (i.e., extracting) key data, which can be used further. As a next step, analytics can then be performed on the abstracted data to determine payment-related services to improve the user's experience. In one embodiment, the analytics performed on the user's historical record can aid system 100 to determine the first preset time period, second preset time period, preset rules for payment-related services, benefit programs, etc. The data analytics can generate a dynamic report based on the refined user's record. Examples of the reports may include charts, graphs, pivot tables (e.g., the axis of which may be selectable by the users in real-time), dashboards, etc. Further, other available data analytics tools that depict the user's financial status can be used.
Customer engagement module 213 may implement a conversational user experience “UX” that presents one or more automated interfaces to the registered user via user interface module 309 and learns about the registered user based on information supplied by the registered user to the automated interface. Customer engagement module 213 may organize, automate, and synchronize user information to provide improved assistance and a personalized user experience. In one embodiment, customer engagement module 213 may include an artificial intelligence (AI) engine configured to use natural language processing to conduct automated conversations with the users. For example, customer engagement module 213 may automatically prompt the customer for one or more responses and automatically understand the intentions of the customer based on the response.
In one embodiment, system 100 implements artificial intelligence (AI), machine learning, and blockchain technology to locate the registered user's account and then automatically recommend them with payment-related service based on real-time processing of their historical information. The blockchain is configured to propagate one or more branching blockchains, wherein each branching blockchain is configured to propagate one or more additional branching blockchains. In general terms, blockchain 215 is an immutable cryptographically linked list of data blocks called a ledger and maintained within a distributed peer-to-peer framework such as a consortium network 217 with nodes 219a-219n (also collectively referred to as nodes 219). These nodes 219, for instance, each maintains an identical copy of the ledger by appending transactions that have been validated by a consensus protocol, grouped into blocks. Each block generally contains a cryptographic hash of previous block, a timestamp and transaction data (e.g., generally represented as a Merkle tree). The concept of blockchain 215 does not require a trusted authority or central server as all nodes 219 in the network 217 are equal and act as transaction initiators and validators at the same time, thereby providing full visibility of the blockchain 215 (e.g., the trust chain for consent transactions) across all nodes 219. All blocks that are added to blockchain 215 are unalterable and changing any of them retroactively would require alteration of all subsequent blocks which in turn requires consensus of network majority.
In a permissionless blockchain 215, virtually anyone can participate, and every participant is anonymous. In such a context, there can be no trust other than that the state of the blockchain 215, prior to a certain depth, is immutable. In order to mitigate this absence of trust, permissionless blockchains 215 typically employ a “mined” native cryptocurrency or transaction fees to provide economic incentive to offset the costs of participating in a form of byzantine fault tolerant (BFT) consensus based on “proof of work” (PoW) or “proof of stake” (PoS) algorithm.
Permissioned blockchains 215, on the other hand, operate a blockchain 215 amongst a set of known, identified and often vetted participants operating under a governance model that yields a certain degree of trust. Private and permission-based blockchains 215, for instance, are generally proposed for the business or enterprise sector. Permissioned blockchains 215 widely use an access control layer to govern who can access the distributed network 217. In one embodiment, new members are invited to join the consortium network 217 by a network owner (starter) or other members with the sufficient authorities applied by a set of rules or policies. By way of example, there are different types of access control mechanisms such as but not limited to: existing participants can invite newcomers; regulatory authority can issue a license or certificate for participation etc.
In one embodiment, the blockchain network (e.g., the consortium network 217) includes a smart contract or chaincode layer 221 comprising one or more smart contracts or chaincodes 223a-223m (also collectively referred to as chaincodes 223 or smart contracts 223). Each smart contract or chaincode 223 is automatically executable computer code running on top of a blockchain network (e.g., the consortium network 217), being encoded into blockchain 215 itself. It is noted that the terms “smart contract” and “chaincode” are used interchangeably even though chaincode is the Hyperledger Fabric implementation specific term for smart contract. Each smart contract or chaincode 223, for instance, contains a set of rules and conditions under which the parties of the “smart” contract agree to interact with each other. For example, a smart contract or chaincode 223 can initiate a recording of a request on the blockchain 215 after the nodes 219 verify that a payment has been made. In this way, the smart contract code or chaincode 223 facilitates, verifies, and enforces negotiation of agreements or transactions between parties.
For example, considering a blockchain 215 as the data, the smart contract or chaincode 223 is a logic which allows the manipulation of virtual assets. As described above, the chaincode 223 is executed (e.g., by nodes 219 of the consortium network 217 to reach a consensus) when programmed conditions are met. The advantage of the smart contract or chaincode 223 is that it does not require third-parties being involved in the agreement based on a blockchain 215. All transactions made are validated by required members or nodes 219 using the instantiations of the chaincode 223 and stored in the blockchain 215 only when consensus is met. In one embodiment, a smart contract or chaincode 223 is a secure and, in most cases, public way of managing assets, agreements, registries, etc. including but not limited to points to at least one registered user for acquisition of a registered service.
The above presented modules and components of transaction processing system 109 may be implemented in hardware, firmware, software, or a combination thereof. Though depicted as a separate entity in
In step 401, transaction processing system 109 may determine, in real-time, a plurality of transactions for a payment account associated with a payment vehicle of a registered user. In one example embodiment, consumer 101 may travel using the public bus multiple times a week, and when she taps her debit card on the magnetic card reader of the bus, her debit card is used as a means of identification and to authorize the commute. The actual cost of the commute is not debited from her payment account. In another example embodiment, consumer 101 eats at a restaurant multiple times a week, and when she swipes her debit card on the POS terminal of the restaurant, the debit card is used as a means of authentication to authorize the meal. The actual cost of the meal is not debited from her payment account. Transaction processing system 109 monitors, in real-time, the plurality of transactions associated with the payment account of consumer 101.
In step 403, transaction processing system 109 may aggregate outstanding amount associated with the plurality of transactions for the payment account based, at least in part, on a first preset time period. In one example embodiment, transaction processing system 109 may aggregate the expenses incurred in the payment account, e.g., the cost of the commutes and the meals, at the end of the day. In one embodiment, the first preset time period may be configured to an hourly basis, a daily basis, per user preference, and so on. Such accumulation of expenses in a bundle reduces the processing cost incurred by merchant 113.
In step 405, transaction processing system 109 may transmit payments for the aggregated outstanding amount to a plurality of recipient accounts associated with merchants to the plurality of transactions based, at least in part, on the first preset time period, a pre-determined total outstanding amount threshold, or a combination thereof. In one embodiment, the payment account and the recipient account are associated with the same financial institution. In one example embodiment, transaction processing system 109 may transmit payments to the recipient account of the bus service provider and the restaurant for the aggregated expenses incurred in the payment account, e.g., the total cost for the commutes and the meals, at the end of the day. In another example embodiment, transaction processing system 109 may transmit payments to the recipient account of the bus service provider and the restaurant upon determining that the expenses incurred in the payment account of consumer 101 exceed the outstanding amount threshold limit. In one embodiment, the pre-determined total outstanding amount threshold may overrule the first preset time period or may work in conjunction with the first preset time period. This ensures faster and timely payments to merchant 113 for the goods and services rendered.
In step 407, transaction processing system 109 may aggregate the transmitted payments based, at least in part, on a second preset time period. In one embodiment, the first preset time period is a subset of the second preset time period. In one example embodiment, transaction processing system 109 may accumulate the payments transmitted to the recipient accounts of merchants 113 from the payment account of consumer 101 during a three-day time period. For example, the payments were transmitted during the first preset time period, e.g., at the end of the day, and the transmitted payments were aggregated at the second preset time period, e.g., a three-day time period. In one embodiment, the second preset time period may be configured to a bi-weekly basis, a weekly basis, per user preference, and so on.
In step 409, transaction processing system 109 may deduct an amount that equals the aggregated transmitted payments from the payment account based, at least in part, on the second preset time period. In one example embodiment, transaction processing system 109 debits the payment account of consumer 101 for the payments transmitted to the recipient account of merchant 113 during the three days. Such postponed deduction of payments for goods and services gives the consumer the choice to pay their debt over time.
In step 411, transaction processing system 109 may generate a user interface element in a user interface of a device associated with the registered user. In one embodiment, the user interface element includes notification on the deduction of the aggregated transmitted payments from the payment account of consumer 101. In another embodiment, the user interface element includes an alert on the aggregated outstanding amount during the first preset time period, and that the aggregated outstanding amount is debited from the payment account of consumer 101 during the second preset time period.
In step 501, transaction processing system 109 may receive, over a communication network, access credentials of the registered user. In one embodiment, the access credentials include predefined values, a preset username and password, international mobile equipment identity (IMEI), an electronic serial number, a mobile equipment identity (MEID), one or more identifiers unique to the device, or a combination thereof. In another embodiment, consumer 101 may use other authentication mechanisms, e.g., log-in credentials of other social networking services, fingerprint log-in, or facial recognition log-in, to access the payment-related service.
In step 503, transaction processing system 109 may authenticate the access credentials of the registered user, e.g., consumer 101, to authorize access to a payment-related service. In one example embodiment, consumer 101 may enter access credentials in the log-in screen of UE 115, whereupon transaction processing system 109 may authenticate the credentials to grant access to the payment-related services or display an error notification, e.g., invalid log-in, to notify the user that the log-in credentials were incorrect. In another embodiment, transaction processing system 109 may notify the registered user to enter a ‘captcha’ to prevent automated software from creating fake accounts.
In step 505, transaction processing system 109 may integrate the payment vehicle, the payment account, and the plurality of recipient accounts with the payment-related service. In one embodiment, the integration is based on consent from the registered user and the merchants. In one example embodiment, the registered user and the merchants may authorize transaction processing system 109 to link the payment vehicle, the payment account, and the plurality of recipient accounts with the payment-related service during the registration process. Such integration/linkage of accounts with payment-related service of transaction processing system 109 facilitates real-time transmission of payment information.
In step 507, transaction processing system 109 may synchronize, in real-time, transaction information for the plurality of transactions, the aggregated outstanding amount, the aggregated transmitted payments, or a combination thereof between the payment account, the plurality of recipient accounts, and the payment-related service. In one example embodiment, transaction processing system 109 may coordinate, in real-time, transaction information for the plurality of transactions in the payment account of consumer 101, the aggregated outstanding amount in the payment account of consumer 101, and the aggregated transmitted payments to the recipient account of merchant 113 with the payment-related service.
In step 601, transaction processing system 109 may process historical transaction information associated with the registered user to determine a probability of expenses in the next instance of time. In one embodiment, historical transaction information includes payments made by consumer 101 for goods and services over a specified time period. In one example embodiment, transaction processing system 109 may determine that the daily expenses of consumer 101 average around $150 based on the processing of historical transaction information.
In step 603, transaction processing system 109 may determine the expenses in the next instance of time exceeds payment account balance. In one example embodiment, transaction processing system 109 may compare, in real-time, balance in the payment account of consumer 101 with the expenses in the next instance of time, e.g., transaction processing system 109 previously determined that the daily expenses of consumer 101 average around $150. If the balance in the payment account is below the average expense of $150, then transaction processing system 109 determines that the payment account does not have sufficient balance to cover the anticipated expenses.
In step 605, transaction processing system 109 may determine preset rules for the registered user based on the determination that the expenses in the next instance of time exceed the payment account balance. In one embodiment, preset rules include setting a limit to the payment for the anticipated expenses of consumer 101 without an undue increase in the risk of defaults. In another embodiment, preset rules include generating an alert in the user interface of UE 115 associated with the registered user to add funds to the payment account or incur overdraft charges for the payment of the predicted aggregated outstanding amount. In a further embodiment, preset rules include deferring the payment for the predicted aggregated outstanding amount until the balance in the payment account matches the predicted aggregated outstanding amount.
In step 701, transaction processing system 109 may process historical transaction information to determine a credit ranking and a credit score for the registered user. In one embodiment, the historical transaction information includes credit history information, income information, debt-to-income ratio information, or a combination thereof. In one example embodiment, higher income and lower debt-to-income ratio earn higher credit ranking and credit score for the registered user. Whereas, a lower income, higher debt-to-income ratio, and a record of defaulted payments garner lower credit ranking and credit score for the registered user.
In step 703, transaction processing system 109 may determine the first preset time period, the second preset time period, the pre-determined total outstanding amount threshold, or a combination thereof based on the credit ranking and the credit score. In one example embodiment, consumer 101 with higher credit ranking and credit score may be provided with a higher pre-determined total outstanding amount threshold. In another example embodiment, consumer 101 with higher credit ranking and credit score may be provided with a reduced first preset time period, and an extended second preset time period.
In step 801, transaction processing system 109 may process the payment account of the registered user to determine the payment account balance is below a pre-determined minimum balance threshold. In one example embodiment, transaction processing system 109 may set a minimum threshold limit for payment account balance at $250, and may alert the registered user, via UE 115, if the payment account balance is below $250. The minimum threshold limit may be based on the average expenses of the registered user. In one embodiment, the minimum threshold limit set by the transaction processing system 109 is separate from the minimum account balance set by the financial institution, e.g., issuer 105.
In step 803, transaction processing system 109 may determine the aggregated outstanding amount exceeds the payment account balance. In one example embodiment, transaction processing system 109 may compare the aggregated outstanding amount in the first preset time period with the payment account balance, and may notify the registered user, via UE 115, if the payment account balance is lower than the aggregated outstanding amount.
In step 805, transaction processing system 109 may determine to transmit payments for the aggregated outstanding amount during the second preset time period based on the historical transaction information of the registered user. In one embodiment, the historical transaction information includes a predicted income of the registered user, wherein the predicted income is sufficient to settle the aggregated transmitted payments. In one example embodiment, transaction processing system 109 may determine that the payment account balance of the registered user is below the minimum threshold limit and the aggregated outstanding amount exceeds the payment account balance. The transaction processing system 109 may process the historical transaction information of the registered user to determine that the upcoming income of the registered user overcomes the aggregated outstanding amount. Transaction processing system 109 may determine to transmit payments for the aggregated outstanding amount.
In step 901, transaction processing system 109 may determine a failure of at least one transaction from the plurality of transactions of the registered user. In one example embodiment, transaction processing system 109 may process, in real-time, the plurality of payment transactions associated with the registered user. Transaction processing system 109 may determine, in real-time, at least one payment transaction from the plurality of payment transactions was unsuccessful.
In step 903, transaction processing system 109 may process at least one transaction to determine a reason for the failure. In one example embodiment, a payment transaction may fail because of insufficient funds in the payment account, a technical glitch in the system, compromised card, communication error, the merchant to the transaction is blacklisted, or a combination thereof.
In step 905, transaction processing system 109 may generate a user interface element in the user interface of UE 115. In one embodiment, the user interface element is an alert on the reason for the failure of at least one payment transaction.
In step 1001, transaction processing system 109 may process historical transaction information associated with the registered user. In one embodiment, the historical transaction information includes past payment transactions, shopping basket contents, or a combination thereof.
In step 1003, transaction processing system 109 may determine a benefit program for the registered user based, at least in part, on the processing. In one embodiment, the benefit program includes a loyalty program, a coupon redemption program, a lottery program, or a combination thereof. In one example embodiment, transaction processing system 109 may process the purchase history of the registered users to determine a benefits program suitable for the registered users. Transaction processing system 109 may then recommend a loyalty service, e.g., shopping rebates, coupons, rebates, and other benefits, to maintain engagement level between the merchant brand and the consumer. In another example embodiment, transaction processing system 109 may create a shopping profile for consumer 101 based on their spending behaviors. Thereafter, transaction processing system 109 may provide consumer 101 with spend analysis and spend footprint, e.g., the amount spent by consumer 101 on the types of goods and services. Consumer 101 may then compare their profile with peers and/or monetize their profile against targeted offers. In a further example embodiment, transaction processing system 109 may provide a wallet expander service to consumer 101, wherein a short term loan of small amount, e.g., $50-$200, with low APR is provided to consumer 101 short on funds at the end of the month. The loaned amount can only be spent on selected item categories, e.g., excluding tobacco, alcohol, cigarettes, etc. In another example embodiment, transaction processing system 109 may provide post-sales services, e.g., product repair and support services, product-related insurances, guaranty/warranty extensions, product recalls, etc.
In step 1101, consumer 101 may send a registration request to transaction processing system 109 for a payment-related service, and transaction processing system 109 may review and approve the registration request for consumer 101 (step 1103).
In step 1105, consumer 101 may input the log-in credentials to transaction processing system 109 to access the payment-related service. The log-in credentials may include predefined values, a preset username and password, international mobile equipment identity (IMEI), an electronic serial number, a mobile equipment identity (MEID), one or more identifiers unique to the device, biometric authentication, or a combination thereof. Transaction processing system 109 may grant access upon authenticating the log-in credentials or deny access upon determining the log-in credentials do not match or are incorrect (step 1107).
In step 1109, consumer 101 may pay for goods or services via payment vehicle 103 at a POS terminal. Issuer 105 may then receive, in real-time, the transaction information in the payment account associated with consumer 101 via POS terminal over communication network 107 (step 1111). Issuer 105 transmits the transaction information, in real-time, to transaction processing system 109. Upon receiving the transaction information, transaction processing system 109 may aggregate the outstanding amount in the payment account during a first preset time period, and transmit a notification regarding the aggregated outstanding amount to UE 115 associated with consumer 101 (step 1115). The notification may also include a message that the aggregated outstanding amount will be debited from the payment account during a second preset time period.
In step 1117, transaction processing system 109 may transmit payments for the aggregated outstanding amount to a recipient account associated with a merchant to the transaction. In one instance, the payment account of consumer 101 and the recipient account of merchant 113 may be associated with issuer 105, i.e., the same financial institution. In one embedment, transaction processing system 109 may transmit payments for the aggregated outstanding amount based on the first preset time period or pre-determined total outstanding amount threshold. Transaction processing system 109 may receive a payment confirmation from issuer 105 (step 1119), whereupon transaction processing system 109 may present a notification pertaining to the deposit in the user interface of a device associated with the merchant (step 1121).
Transaction processing system 109 aggregates the payments transmitted to the recipient account of the merchant during a second preset time period and then deducts the aggregated transmitted amount from the payment account of consumer 101 (step 1123). The deduction occurs during the second preset time period. In step 1125, transaction processing system 109 generates a presentation in a user interface of a device associated with consumer 101 regarding the deduction from the payment account.
Referring to
As depicted in
Transaction processing system 109 transmits the aggregated outstanding amount, e.g., $79, to a plurality of recipient accounts associated with merchants to the transactions. In one embodiment, such transmission of the aggregated outstanding amount is based on the first preset time period, e.g., the transmission may occur at the same time the aggregated outstanding amount is calculated. In another embodiment, the transmission of the aggregated outstanding amount is based on a pre-determined total outstanding amount threshold, e.g., the cost for the expenses in the payment account of consumer 101 exceeds the maximum limit to overcome the first preset time period requirement. The transmitted payment for the outstanding amount is then displayed in user interface 1305 in UE 115 associated with merchant 113, e.g., merchant 113 is notified that a total amount of $79 has been credited.
Transaction processing system 109 then aggregates the transmitted payments based, at least in part, on a second preset time period, e.g., every three days. In one embodiment, the first preset time period is a subset of the second preset time period. The aggregated transmitted payment is displayed as user interface 1307 in UE 115 associated with consumer 101, e.g., consumer 101 is notified that a total amount of $200 is pending in her payment account for the past 3 days. Transaction processing system 109 deducts an amount that equals the aggregated transmitted payments, e.g., $200, from the payment account during the second preset time period, e.g., the 3 day time threshold. Thereafter, a user interface element 1309 is generated in UE 115 associated with consumer 101, e.g., the consumer is alerted that $200 has been debited from her payment account.
Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining”, analyzing” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities.
In a similar manner, the term “processor” may refer to any device or portion of a device that processes electronic data, e.g., from registers and/or memory to transform that electronic data into other electronic data that, e.g., may be stored in registers and/or memory. A “computer,” a “computing machine,” a “computing platform,” a “computing device,” or a “server” may include one or more processors.
In a networked deployment, the computer system 1400 may operate in the capacity of a server or as a client user computer in a server-client user network environment, or as a peer computer system in a peer-to-peer (or distributed) network environment. The computer system 1400 can also be implemented as or incorporated into various devices, such as a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communications device, a wireless telephone, a land-line telephone, a control system, a camera, a scanner, a facsimile machine, a printer, a pager, a personal trusted device, a web appliance, a network router, switch or bridge, or any other machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. In a particular implementation, the computer system 1400 can be implemented using electronic devices that provide voice, video, or data communication. Further, while a computer system 1400 is illustrated as a single system, the term “system” shall also be taken to include any collection of systems or sub-systems that individually or jointly execute a set, or multiple sets, of instructions to perform one or more computer functions.
As illustrated in
The computer system 1400 may include a memory 1404 that can communicate via a bus 1408. The memory 1404 may be a main memory, a static memory, or a dynamic memory. The memory 1404 may include, but is not limited to computer readable storage media such as various types of volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one implementation, the memory 1404 includes a cache or random-access memory for the processor 1402. In alternative implementations, the memory 1404 is separate from the processor 1402, such as a cache memory of a processor, the system memory, or other memory. The memory 1404 may be an external storage device or database for storing data. Examples include a hard drive, compact disc (“CD”), digital video disc (“DVD”), memory card, memory stick, floppy disc, universal serial bus (“USB”) memory device, or any other device operative to store data. The memory 1404 is operable to store instructions executable by the processor 1402. The functions, acts or tasks illustrated in the figures or described herein may be performed by the processor 1402 executing the instructions stored in the memory 1404. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firm-ware, micro-code and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like.
As shown, the computer system 1400 may further include a display 1410, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid-state display, a cathode ray tube (CRT), a projector, a printer or other now known or later developed display device for outputting determined information. The display 1410 may act as an interface for the user to see the functioning of the processor 1402, or specifically as an interface with the software stored in the memory 1404 or in the drive unit 1406.
Additionally or alternatively, the computer system 1400 may include an input/output device 1412 configured to allow a user to interact with any of the components of computer system 1400. The input/output device 1412 may be a number pad, a keyboard, or a cursor control device, such as a mouse, or a joystick, touch screen display, remote control, or any other device operative to interact with the computer system 1400.
The computer system 1400 may also or alternatively include drive unit 1406 implemented as a disk or optical drive. The drive unit 1406 may include a computer-readable medium 1422 in which one or more sets of instructions 1424, e.g. software, can be embedded. Further, instructions 1424 may embody one or more of the methods or logic as described herein. The instructions 1424 may reside completely or partially within the memory 1404 and/or within the processor 1402 during execution by the computer system 1400. The memory 1404 and the processor 1402 also may include computer-readable media as discussed above.
In some systems, a computer-readable medium 1422 includes instructions 1424 or receives and executes instructions 1424 responsive to a propagated signal so that a device connected to a network 1470 can communicate voice, video, audio, images, or any other data over the network 1470. Further, the instructions 1424 may be transmitted or received over the network 1470 via a communication port or interface 1420, and/or using a bus 1408. The communication port or interface 1420 may be a part of the processor 1402 or may be a separate component. The communication port or interface 1420 may be created in software or may be a physical connection in hardware. The communication port or interface 1420 may be configured to connect with a network 1470, external media, the display 1410, or any other components in computer system 1400, or combinations thereof. The connection with the network 1470 may be a physical connection, such as a wired Ethernet connection or may be established wirelessly as discussed below. Likewise, the additional connections with other components of the computer system 1400 may be physical connections or may be established wirelessly. The network 1470 may alternatively be directly connected to a bus 1408.
While the computer-readable medium 1422 is shown to be a single medium, the term “computer-readable medium” may include a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term “computer-readable medium” may also include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the methods or operations disclosed herein. The computer-readable medium 1422 may be non-transitory, and may be tangible.
The computer-readable medium 1422 can include a solid-state memory such as a memory card or other package that houses one or more non-volatile read-only memories. The computer-readable medium 1422 can be a random-access memory or other volatile re-writable memory. Additionally or alternatively, the computer-readable medium 1422 can include a magneto-optical or optical medium, such as a disk or tapes or other storage device to capture carrier wave signals such as a signal communicated over a transmission medium. A digital file attachment to an e-mail or other self-contained information archive or set of archives may be considered a distribution medium that is a tangible storage medium. Accordingly, the disclosure is considered to include any one or more of a computer-readable medium or a distribution medium and other equivalents and successor media, in which data or instructions may be stored.
In an alternative implementation, dedicated hardware implementations, such as application specific integrated circuits, programmable logic arrays and other hardware devices, can be constructed to implement one or more of the methods described herein. Applications that may include the apparatus and systems of various implementations can broadly include a variety of electronic and computer systems. One or more implementations described herein may implement functions using two or more specific interconnected hardware modules or devices with related control and data signals that can be communicated between and through the modules, or as portions of an application-specific integrated circuit. Accordingly, the present system encompasses software, firmware, and hardware implementations.
The computer system 1400 may be connected to a network 1470. The network 1470 may define one or more networks including wired or wireless networks. The wireless network may be a cellular telephone network, an 1402.11, 1402.16, 1402.20, or WiMAX network. Further, such networks may include a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to TCP/IP based networking protocols. The network 1470 may include wide area networks (WAN), such as the Internet, local area networks (LAN), campus area networks, metropolitan area networks, a direct connection such as through a Universal Serial Bus (USB) port, or any other networks that may allow for data communication. The network 1470 may be configured to couple one computing device to another computing device to enable communication of data between the devices. The network 1470 may generally be enabled to employ any form of machine-readable media for communicating information from one device to another. The network 1470 may include communication methods by which information may travel between computing devices. The network 1470 may be divided into sub-networks. The sub-networks may allow access to all of the other components connected thereto or the sub-networks may restrict access between the components. The network 1470 may be regarded as a public or private network connection and may include, for example, a virtual private network or an encryption or other security mechanism employed over the public Internet, or the like.
In accordance with various implementations of the present disclosure, the methods described herein may be implemented by software programs executable by a computer system. Further, in an exemplary, non-limited implementation, implementations can include distributed processing, component/object distributed processing, and parallel processing. Alternatively, virtual computer system processing can be constructed to implement one or more of the methods or functionality as described herein.
Although the present specification describes components and functions that may be implemented in particular implementations with reference to particular standards and protocols, the disclosure is not limited to such standards and protocols. For example, standards for Internet and other packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP) represent examples of the state of the art. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same or similar functions as those disclosed herein are considered equivalents thereof.
It will be understood that the steps of methods discussed are performed in one embodiment by an appropriate processor (or processors) of a processing (i.e., computer) system executing instructions (computer-readable code) stored in storage. It will also be understood that the disclosure is not limited to any particular implementation or programming technique and that the disclosure may be implemented using any appropriate techniques for implementing the functionality described herein. The disclosure is not limited to any particular programming language or operating system.
It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.
Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.
Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention.
In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.
The above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other implementations, which fall within the true spirit and scope of the present disclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description. While various implementations of the disclosure have been described, it will be apparent to those of ordinary skill in the art that many more implementations and implementations are possible within the scope of the disclosure. Accordingly, the disclosure is not to be restricted except in light of the attached claims and their equivalents.
