Detailed Description
The technical solutions of the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is apparent that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure. In addition, the descriptions of "first" and "second" in this specification are used to distinguish between different service processing requests, tracking identifiers, local pipeline identifiers, accounting data, etc., and do not represent a sequential order, and do not limit that "first" and "second" are of different types.
Please refer to fig. 1. To facilitate understanding of the technical solutions of the embodiments of the present specification by those skilled in the art, one example of a scenario of the embodiments of the present specification is described below.
The execution subject to which the present scenario example relates may include a terminal device, a service server, a payment server, an account server, a clearing server, and a bank server. The terminal device may be, for example, a PC, a server, an industrial personal computer (industrial control computer), a mobile smart phone, a tablet electronic device, a portable computer (such as a notebook computer), a Personal Digital Assistant (PDA), a desktop computer, or an intelligent wearable device. The business server, the payment server, and the account server may be affiliated with a payment mechanism, such as with a payment treasury, a financial payment, or a hundred degree wallet, etc. The service server, the payment server and the account server may be different servers, respectively. Alternatively, a plurality of the service server, the payment server, and the account server may be integrated into one server. The business server may be used in particular to provide business services such as providing personal account supplements, loans, or online shopping, etc. The payment server may be used in particular for providing payment services. The account server may be used in particular for providing account management services, such as updating account balances, etc. The clearing server may be affiliated with a clearing house, such as affiliated with a silver-tie or the like. The banking server may be affiliated with a banking institution, such as a construction bank or an industrial and commercial bank.
The account types to which the present scenario examples relate may include personal bank accounts, payment mechanism bank accounts, and personal payment mechanism accounts. The personal bank account refers to an account opened by a person at a banking institution, for example, an account opened by a person at a banking institution such as a construction bank or an industrial and commercial bank. The payment mechanism bank account refers to an account opened by a payment mechanism at a banking institution, for example, an account opened by a payment mechanism at a banking institution such as a construction bank or an industrial and commercial bank. The personal payment mechanism account refers to an account opened by a person at a payment mechanism, for example, an account opened by a person at a payment mechanism such as a payment treasures, a financial payment or a hundred-degree wallet.
The service to which the present scenario example relates may be a recharge service. The service server, the payment server and the account server may form a processing link for the pen refill service. According to the recharging business, the user can recharge the personal payment mechanism account by utilizing the personal bank account.
In this scenario example, according to a user operation, the terminal device may send a page data acquisition request to the service server. The service server can receive a page data acquisition request; the page data may be fed back to the terminal device. The terminal device may receive page data; a recharge page may be displayed.
The terminal equipment can receive a payment channel, a recharging amount and a personal bank account which are input by a user on the recharging page; a recharge request may be sent to the service server. The recharge request may include a payment channel, recharge amount, personal bank account, personal payment mechanism account, transaction time, transaction type, etc. The payment channel can be, for example, a business debit card channel or a farming credit card channel. The recharge amount may be, for example, 100 or 1000. The transaction time may be 20190130, for example. The transaction type may be, for example, a top-up.
In this scenario example, the service server may receive the recharge request. As a source server in the processing link, the traffic server may generate a global pipeline identity. The global running water identification may be recorded by each server (e.g., a service server, a payment server, an account server, etc.) in the processing link, for identifying accounting data corresponding to the recharging service at each server. The global pipeline identifier may be, for example, TLR-TERM-001. The traffic server may also generate a first local pipeline identification and a first tracking identification. The first local pipelining identifier can be recorded by the service server and is used for identifying accounting data corresponding to the recharging service locally at the service server. The first LOCAL pipeline identifier may be, for example, TLR-TRAC-LOCAL-001. The first tracking identifier may be recorded by the service server and the payment server, and may represent a call relationship between the service server and the payment server, so as to facilitate reconciliation. The first tracking identifier may be, for example, TLR-TRAC-001.
The service server may process the recharging request and record corresponding accounting data (hereinafter referred to as first accounting data for convenience of description); a payment request may be sent to the payment server. The first accounting data may include a global running water identifier, a first local running water identifier, a first tracking identifier, a payment channel, a recharge amount, a personal bank account, a personal payment mechanism account, a transaction time, a transaction type, and the like. The payment request may include a global running water identification, a first tracking identification, a payment channel, a recharge amount, a personal bank account, a personal payment mechanism account, a transaction time, a transaction type, and the like.
In this scenario example, the payment server may receive the payment request; a second local pipeline identification and a second trace identification may be generated. The second local pipelining identifier can be recorded by the payment server and used for identifying accounting data corresponding to the recharging service locally at the payment server. The second LOCAL pipeline identifier may be, for example, TLR-PAY-LOCAL-001. The second tracking identifier may be recorded by the payment server and the account server, and may represent a call relationship between the payment server and the account server to facilitate reconciliation. The second tracking identifier may be, for example, TLR-PAY-001.
The payment server may process the payment request and record corresponding accounting data (hereinafter referred to as second accounting data for convenience of description); a balance update request may be sent to the account server. The second accounting data may include a global running water identifier, a second local running water identifier, a first tracking identifier, a second tracking identifier, a payment channel, a recharge amount, a personal bank account, a personal payment mechanism account, a transaction time, a transaction type, and the like. The balance update request may include a global running water identification, a second tracking identification, a payment channel, a recharge amount, a personal bank account, a personal payment mechanism account, a transaction time, a transaction type, and the like.
In this scenario example, the account server may receive the balance update request; a third local pipeline identification and a third trace identification may be generated. The third local pipelining identifier can be recorded by the account server and is used for identifying accounting data corresponding to the recharging service locally at the account server. The third LOCAL pipeline identifier may be, for example, TLR-ACCOUNT-LOCAL-001. The third tracking identification may be recorded by the account server. The third tracking identifier may be, for example, TLR-ACCOUNT-001.
The account server may process the balance update request and record corresponding accounting data (hereinafter referred to as third accounting data for convenience of description); a message that the balance update was successful may be fed back to the payment server. The third accounting data may include a global running water identifier, a third local running water identifier, a second tracking identifier, a third tracking identifier, a payment channel, a recharge amount, a personal bank account, a personal payment mechanism account, a transaction time, a transaction type, and the like.
In this scenario example, the payment server may receive a message that the balance update was successful; a deduction request may be sent to the bank server. The deduction request may include a recharge amount, a personal bank account, a payment mechanism bank account, a transaction time, a transaction type, and the like. The bank server may receive the deduction request; the recharge amount may be deducted from the personal bank account and increased at the payment mechanism bank account; a message that the payment was successful may be fed back to the payment server. The payment server can receive a message that the deduction is successful; and feeding back a message of successful recharging to the service server. The service server can receive the message of successful recharging; and feeding back a message of successful recharging to the terminal equipment. The terminal equipment can receive the message of successful recharging; a message that the recharge was successful may be displayed.
The payment server may send a deduction request directly to the bank server. The bank server can directly feed back the successful deduction message to the payment server. Alternatively, the payment server may also send a deduction request to the bank server via the clearing server. In particular, the payment server may send a deduction request to the clearing server. The clearing server may receive the deduction request; the deduction request may be sent to the bank server. The bank server may also feed back a successful deduction message to the payment server via the clearing server. Specifically, the bank server may feed back a message that the deduction is successful to the clearing server. The clearing server can receive a message that the deduction is successful; a message that the payment was successful may be fed back to the payment server.
In this scenario example, the payment mechanism may also include a reconciliation platform. The reconciliation platform may agree on a reconciliation time with respective servers (e.g., business server, payment server, account server, etc.) in the processing link. After the accounting time arrives, the servers can send the accounting data recorded by the servers to the accounting platform. Specifically, the service server may send the first accounting data recorded by itself to the reconciliation platform, the payment server may send the second accounting data recorded by itself to the reconciliation platform, and the account server may send the third accounting data recorded by itself to the reconciliation platform. The reconciliation platform may receive the first accounting data, the second accounting data, and the third accounting data.
As can be seen from the accounting process of the present scenario example, when there is a call relationship between two servers, the accounting data recorded by the two servers includes the same tracking identifier. Specifically, a call relationship exists between the business server and the payment server, and the first accounting data and the second accounting data both comprise a first tracking identifier. And a calling relationship is arranged between the payment server and the account server, and the second account data and the third account data both comprise a second tracking identifier. Therefore, the reconciliation platform can reconcile the two accounting data comprising the same tracking identifier, so that the reconciliation between the two servers with the calling relationship is realized. Specifically, the reconciliation platform may perform reconciliation processing on the first and second account data; the second and third accounting data may be reconciled.
In this scenario example, when the reconciliation result of the two accounting data is an abnormal result, the reconciliation platform may send error handling requests to the two servers that record the two accounting data, respectively, so that the two servers perform check-up. For example, when the reconciliation result of the first and second account data is an abnormal result, the reconciliation platform may send an error handling request including a first local-flow identification to the business server; an error handling request including a second local pipeline identity may be sent to the payment server.
In this scenario example, please refer to fig. 2. According to the global flow identification, the reconciliation platform can perform overall display on accounting data corresponding to the recharging business in each server (such as a business server, a payment server, an account server and the like) of the processing link.
Note that, please refer to fig. 3. The service server may directly invoke the payment server to send a recharge request to the payment server. The payment server may directly invoke the account server to send a balance update request to the account server. Alternatively, the payment mechanism may further comprise a dispatch platform. In this manner, the service server may also invoke the payment server via the dispatch platform. The payment server may also invoke the account server via the dispatch platform.
It should be further noted that, the service server may directly send the first accounting data to the reconciliation platform, the payment server may directly send the second accounting data to the reconciliation platform, and the account server may directly send the third accounting data to the reconciliation platform. Alternatively, the payment mechanism may further comprise a data transmission platform. In this way, the business server may also send the first accounting data to the reconciliation platform via the data transfer platform. The payment server may also send second accounting data to the reconciliation platform via the data transfer platform. The account server may also send third accounting data to the reconciliation platform via the data transfer platform.
Please refer to fig. 4. The present specification provides one embodiment of a billing method. The execution body of this embodiment may be the first server. The first server may be a server in a certain service processing link, for example, may be a source server in the processing link (e.g., a service server in the previous scenario example). The services may include payment services, settlement services, proxy services, etc., and the proxy services may include, in particular, a reimbursement fund, reimbursement national debt, reimbursement insurance, reimbursement payroll, public payment to be collected, reimbursement management fees, etc. This embodiment may include the following steps.
Step S10: and receiving a first service processing request sent by the terminal equipment.
In some embodiments, the terminal device may send a first service processing request to the first server. The first service processing request may be, for example, a recharge request or the like. The first server may receive the first service processing request.
Step S12: a global pipeline identification and a tracking identification are generated.
In some embodiments, the global pipeline identifier may be recorded by a plurality of servers in the processing link, and used to identify accounting data corresponding to the business at the plurality of servers. The first server may generate the global pipeline identification in any manner, such as generating the global pipeline identification according to a particular rule.
In some embodiments, the tracking identifier may be recorded by the first server and the second server, and may represent a call relationship between the first server and the second server to facilitate reconciliation. The first server may generate the tracking identifier in any manner, for example, according to a particular rule. The second server may be, for example, a payment server in the previous scenario example.
Step S14: and processing the first service processing request and recording corresponding financial data.
In some embodiments, the first server may parse the first service processing request and generate a response; corresponding accounting data may be recorded. The accounting data may include the global flowing water identification and the tracking identification. Of course, the accounting data may also include other data such as one or more of payment channel, recharge amount, personal bank account, personal payment mechanism account, transaction time, and transaction type.
In some embodiments, the first server may also generate a local pipeline identification. The local pipeline identification may be recorded by the first server for locally identifying the accounting data at the first server. Accordingly, the accounting data may also include the local pipeline identification.
In some embodiments, the first server may also send a second service processing request to the second server. The second business process request may include the tracking identifier.
According to the billing method of the embodiment, the first server can generate the global pipelining identifier and the tracking identifier, and the global pipelining identifier and the tracking identifier can be recorded as accounting data, so that convenience is brought to subsequent reconciliation.
Please refer to fig. 5. The present description also provides another embodiment of the billing method. The execution subject of this embodiment may be a second server. The second server may be a server in a certain service processing link, for example, may be a server in the processing link other than the source server (e.g., a payment server in the previous scenario example). The services may include payment services, settlement services, proxy services, etc., and the proxy services may include, in particular, a reimbursement fund, reimbursement national debt, reimbursement insurance, reimbursement payroll, public payment to be collected, reimbursement management fees, etc. This embodiment may include the following steps.
Step S20: and receiving a first service processing request sent by the first server.
In some embodiments, the first server may be, for example, a traffic server in the previous scenario example. The first server may generate a first tracking identifier; a first service processing request may be sent to the second server. The first service processing request may include the first tracking identifier. The first tracking identifier can be recorded by the first server and the second server, and can represent the calling relationship between the first server and the second server so as to facilitate checking. The first server may specifically generate the first tracking identifier in any manner, for example, according to a specific rule. Of course, the first business process request may also include other data, such as one or more of a payment channel, a recharge amount, a personal bank account, a personal payment mechanism account, a transaction time, and a transaction type. The first service processing request may be, for example, a payment request or the like.
The second server may receive the first service processing request.
Step S22: a second tracking identifier is generated.
In some embodiments, the second server may generate a second tracking identifier. The second tracking identifier may be recorded by the second server and the third server, and may represent a call relationship between the second server and the third server, so as to facilitate checking. The second server may generate the second tracking identifier in any manner, for example, according to a specific rule. The third server may be, for example, an account server in the previous scenario example.
Step S24: and processing the first service processing request and recording corresponding financial data.
In some embodiments, the second server may parse the first service processing request and generate a response; corresponding accounting data may be recorded. The accounting data may include the first tracking identification and the second tracking identification. Of course, the accounting data may also include other data such as one or more of payment channel, recharge amount, personal bank account, personal payment mechanism account, transaction time, and transaction type.
In some embodiments, the first business process request may further include a global pipeline identification. The global pipeline identifier can be recorded by a plurality of servers in the processing link and used for identifying accounting data corresponding to the business at the plurality of servers. The global pipeline identification may be generated by the first server. Alternatively, the global pipelined identification may be generated by a server other than the first server and the second server. After generating the global pipeline identifier, the other servers may send the global pipeline identifier to the first server. Accordingly, the accounting data may also include the global pipeline identification.
In some embodiments, the second server may also generate a local pipeline identification. The local pipeline identification may be recorded by the second server for locally identifying the accounting data at the second server. Accordingly, the accounting data may also include the local pipeline identification.
In some embodiments, the second server may further send a second service processing request to the third server. The second service processing request may include the second tracking identifier.
According to the billing method of the embodiment, the second server can generate the second tracking identifier, and the first tracking identifier and the second tracking identifier can be recorded as accounting data, so that convenience is brought to subsequent reconciliation.
Please refer to fig. 6. The present specification also provides one embodiment of a reconciliation method. The execution subject of this embodiment may be a reconciliation platform, and specifically may include the following steps.
Step S30: a plurality of accounting data is received.
In some embodiments, the plurality of accounting data may each include a global pipeline identifier, so that it can be indicated that the plurality of accounting data corresponds to the same business.
The plurality of accounting data may be sent by a plurality of servers in the traffic handling link. The reconciliation platform may receive the plurality of accounting data. In particular, the plurality of accounting data may be directly transmitted by the plurality of servers. Alternatively, the plurality of servers may send a plurality of accounting data to the data transmission platform. The data transmission platform may receive the plurality of accounting data; the plurality of accounting data may be sent to the reconciliation platform.
In some embodiments, the accounting data may include at least one tracking identifier.
In some embodiments, the accounting data may include a local pipeline identification. Different ones of the plurality of accounting data may include different local flow identification.
In one example scenario, the accounting data may include one or more of a payment channel, a recharge amount, a personal bank account, a personal payment mechanism account, a transaction time, and a transaction type.
Step S32: at least one set of accounting data is determined.
In some embodiments, the set of accounting data may include at least two accounting data. The accounting data in the accounting data set may include the same tracking identity, which can indicate that the accounting data in the accounting data set is recorded by at least two servers having a calling relationship. For example, the set of accounting data may include first accounting data and second accounting data, which may include the same tracking identification. The first accounting data may be recorded by a first server, the second accounting data may be recorded by a second server, and a call relationship may be provided between the first server and the second server. Specifically, for example, the first server may be a caller, and the second server may be a server.
It should be noted that this does not exclude the case that the accounting data in the accounting data set may also comprise different tracking identifications. Continuing the former example, taking the common tracking identifier in the first accounting data and the second accounting data as a first tracking identifier. The first accounting data may then further comprise a second tracking identifier, the second accounting data may further comprise a third tracking identifier, the second tracking identifier and the third tracking identifier being different.
Step S34: and according to the tracking identification, checking account data in the account data set.
In some embodiments, for each account data set, the reconciliation platform may reconcile the account data in the account data set according to a common tracking identifier of each account data in the account data set.
According to the accounting method of the embodiment, the accounting platform can determine at least one accounting data set according to a plurality of accounting data, wherein the accounting data set comprises at least two accounting data with the same tracking identification; and checking account data in the account data set according to the tracking identification. Thus, according to the tracking identification, the reconciliation platform can realize unified reconciliation processing on a plurality of account data, and the reconciliation efficiency is improved.
Please refer to fig. 7. The present specification also provides one embodiment of a billing apparatus. This embodiment may be applied to the first server, and may include the following elements in particular.
A receiving unit 40, configured to receive a first service processing request sent by a terminal device;
a generating unit 42, configured to generate a global running water identifier and a tracking identifier;
and a recording unit 44, configured to process the first service processing request, and record corresponding accounting data, where the accounting data includes the global running water identifier and the tracking identifier.
Please refer to fig. 8. The present description also provides one embodiment of a server. The embodiment may include a memory and a processor.
In some embodiments, the memory may be implemented in any suitable manner. For example, the memory may be a read-only memory, a mechanical hard disk, a solid state hard disk, or a usb disk. The memory may be used to store computer instructions.
In some embodiments, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a programmable logic controller, and an embedded microcontroller, among others. The processor may execute the computer instructions to implement the steps of: receiving a first service processing request sent by terminal equipment; generating a global running water identifier and a tracking identifier; and processing the first business processing request, and recording corresponding accounting data, wherein the accounting data comprises the global running water identifier and the tracking identifier.
Please refer to fig. 9. The present description also provides another embodiment of the billing apparatus. This embodiment may be applied to the second server, and may include the following elements in particular.
A receiving unit 50, configured to receive a first service processing request sent by a first server, where the first service processing request includes a first tracking identifier generated by the first server;
a generating unit 52, configured to generate a second tracking identifier;
and a recording unit 54, configured to process the first service processing request, and record corresponding accounting data, where the accounting data includes the first tracking identifier and the second tracking identifier.
Please refer to fig. 8. The present description also provides one embodiment of a server. The embodiment may include a memory and a processor.
In some embodiments, the memory may be implemented in any suitable manner. For example, the memory may be a read-only memory, a mechanical hard disk, a solid state hard disk, or a usb disk. The memory may be used to store computer instructions.
In some embodiments, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a programmable logic controller, and an embedded microcontroller, among others. The processor may execute the computer instructions to implement the steps of: receiving a first service processing request sent by a first server, wherein the first service processing request comprises a first tracking identifier generated by the first server; generating a second tracking identifier; and processing the first business processing request, and recording corresponding financial data, wherein the financial data comprises the first tracking identifier and the second tracking identifier.
Please refer to fig. 10. The present specification also provides one embodiment of a reconciliation apparatus. This embodiment may include the following units.
A receiving unit 60 for receiving a plurality of accounting data;
a determining unit 62 for determining at least one set of accounting data comprising at least two accounting data having the same tracking identity;
and the reconciliation unit 64 is configured to reconcile the accounting data in the accounting data set according to the tracking identifier.
Please refer to fig. 8. The present description also provides one embodiment of a server. The embodiment may include a memory and a processor.
In some embodiments, the memory may be implemented in any suitable manner. For example, the memory may be a read-only memory, a mechanical hard disk, a solid state hard disk, or a usb disk. The memory may be used to store computer instructions.
In some embodiments, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a programmable logic controller, and an embedded microcontroller, among others. The processor may execute the computer instructions to implement the steps of: receiving a plurality of accounting data; determining at least one set of accounting data comprising at least two accounting data having the same tracking identity; and according to the tracking identification, checking account data in the account data set.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment is mainly described in a different point from other embodiments. In particular, for the server embodiment and the device embodiment, since they are substantially similar to the method embodiment, the description is relatively simple, and reference is made to the partial description of the method embodiment for relevant points.
In addition, it will be appreciated that those skilled in the art, upon reading the present specification, may readily devise some or all of the embodiments that, although still within the scope of the disclosure and protection herein, may be combined without undue effort.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips 2. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but HDL is not only one, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog2 are most commonly used at present. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
From the above description of embodiments, it will be apparent to those skilled in the art that the present description may be implemented in software plus a necessary general purpose hardware platform. Based on this understanding, the technical solution of the present specification may be embodied in essence or a part contributing to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present specification.
The specification is operational with numerous general purpose or special purpose computer system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Although the present specification has been described by way of example, it will be appreciated by those skilled in the art that there are many variations and modifications to the specification without departing from the spirit of the specification, and it is intended that the appended claims encompass such variations and modifications as do not depart from the spirit of the specification.