WO2013037029A1

WO2013037029A1 - Data record management and processing for fungible instruments

Info

Publication number: WO2013037029A1
Application number: PCT/CA2011/001015
Authority: WO
Inventors: Ambrose CHOY; David MAN; Winston Mok
Original assignee: Simply Good Technologies Inc.
Priority date: 2011-09-12
Filing date: 2011-09-12
Publication date: 2013-03-21

Abstract

The present specification provides a system for processing data records representing fungible instruments across a set of issuing servers, client machines and point of sale terminals that can each have different computing environments. A method and point of sale terminal are provided for processing a data record representing a fungible instrument at a point of sale terminal having a specific computing environment comprising receiving a data record representing a fungible instrument, receiving a set of programming instructions unique to the fungible instrument and unique to the specific computing environment, executing the programming instructions to redeem a value assigned to the fungible instrument and sending a clearing data record to a clearing server.

Description

SYSTEM FOR DATA RECORD MANAGEMENT AND PROCESSING

FIELD

[0001] The present specification relates generally to computing devices and more specifically relates to a system for data record management and processing.

BACKGROUND

[0002] The migration of paper-based data records to electronic-based data records is increasing. However a mere transition to having an electronic device mimic paper a paper data- record can be cumbersome to the processing resources of the electronic device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 is a schematic representation of a system for data record management and processing.

[0004] Figure 2 is a flow chart depicting a method for data record management and processing.

[0005] Figure 3 shows the system of claim 1 during example performance of certain blocks of the method of Figure 2.

[0006] Figure 4 is a flow chart depicting a method for processing a data record.

[0007] Figure 5 shows a first example of a point of sale terminal and other related components from the system of Figure 1.

[0008] Figure 6 shows a first example of a point of sale terminal and other related components from the system of Figure 1.

[0009] Figure 7 is a flow chart depicting a method for clearing a data record.

[0010] Figure 8 is a flow chart depicting a method for processing a data record.

[0011] Figure 9 is a flow chart depicting a method for modifying a profile.

[0012] Figure 10 is a perspective view of an embodiment of a mounting frame for a portable computing device.

[0013] Figure 11 is a left side view of an embodiment of a mounting frame for a portable computing device.

[0014] Figure 12 is a front view of an embodiment of a mounting frame for a portable computing device.

[0015] Figure 13 is a back view of an embodiment of a mounting frame for a portable computing device.

[0016] Figure 14 is a right side view of an embodiment of a mounting frame for a portable computing device.

[0017] Figure 15 is a plan view of an embodiment of a mounting frame for a portable computing device.

[0018] Figure 16 is a bottom view of an embodiment of a mounting frame for a portable computing device.

[0019] Figure 17 is a perspective view of an embodiment of a mounting frame for a portable computing device with the portable computing device and a client machine in place.

[0020] Figure 18 is a side view of an alternative embodiment of a mounting frame for a portable computing device.

[0021] Figure 19 is a side view of another alternative embodiment of a mounting frame for a portable computing device.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] Figure 1 a schematic representation of a non-limiting example of a system 50 for managing and processing data records representing fungible instruments. As will be discussed further below, the term fungible instrument represents a particular good or service or portion thereof which is unilaterally issued by a first entity and redeemable by a second entity.

[0023] System 50 comprises a central server 54 that connects, via a first link 58 to a profile engine 62 and via a second link 66 to a clearing engine 70. Central server 54 also connects to a wide area network 74 such as the Internet. [0024] Network 74, in turn, interconnects central server 54 with one or more issuing servers 78-1 , 78-2 ... 78-n. Generically, these are referred to as "issuing server 78" and collectively they are referred to as "issuing servers 78". This nomenclature is used elsewhere herein. Network 74 also interconnects central server 54 with one or more point of sale terminals 82-1 , 82-2 ... 82-0. Network 74 also interconnects central server 54 with one or more client machines 86-1 , 86-2 ... 86-p.

[0025] Central server 54 can be based on any desired server-type computing environment, including appropriate configurations of one or more central processing units (CPUs) configured to control and interact with memory (including volatile memory such as Random Access Memory (RAM), and non-volatile memory such as hard disk drives or FLASH drives, or a Redundant Array of Inexpensive Disks (RAID) or cloud-based storage), network interfaces (to connect to link 58 and link 70). Central server 54 can also be configured to include input devices such as a keyboard or pointing device or output devices such as a monitor or any of or all of them, to permit local interaction. Other types of hardware configurations for central server 54 are contemplated. For example, central server 54 can also be implemented as part of a cloud- based computing solution, whereby the functionality of central server 54 is implemented as one or more virtual machines executing at a single data center or in a mirrored form across a plurality of data centers. The software aspect of the computing environment of central server 54 can also include remote access capabilities in lieu of, or in addition to, any local input devices or local output devices. Any desired or suitable operating system can be used in the computing environment of central server 54. The computing environment can be accordingly configured with appropriate operating systems and applications to effect the functionality discussed herein. In general central server 54 is configured to manage and process data records representing fungible instruments as will be discussed further below.

[0026] Profile engine 62 can be based on a server-type computing environment, much along the possible lines of the computing environments described in relation to central server 54. Profile engine 62 is configured to maintain profiles 90 associated with various individual subscriber accounts 94, which are in turn associated with each client machine 86, the details of which will be discussed further below. (In variations, a plurality of profile engines 62 (not shown in the Figures) can be provided which aggregate profile information from a plurality of different linked subscriber accounts. For example a Facebook™ subscriber account may be linked to a mobile telephone subscriber account and each of those accounts may in turn have their own individual profiles, which are then linked to provide a merged profile 90 that can be used according to the teachings of this specification.)

[0027] Clearing engine 70 can also be based on a server-type computing environment, much along the possible lines of the computing environments described in relation to central server 54. Clearing engine 70 is configured to maintain and process responses from client machines 86 or point of sale terminals 82 or both relating to the issuances of data records representing fungible instruments, the details of which will be discussed further below.

[0028] Link 58 and link 66 can be implemented as part of network 74, but in a present implementation it is contemplated that profile engine 62 and clearing engine 70 are local to central server 54 in which case link 58 and link 66 can be implemented as part of a local area network. Alternatively, the functionality of profile engine 62 and clearing engine 70 can be incorporated directly into central server 54 obviating link 58 and link 66 altogether.

[0029] Each issuing server 78 can be also based on a server-type computing environment, much along the possible lines of the computing environments described in relation to central server 54. Each issuing server 78 can generate data records representing one or more fungible instruments which are sent to central server 54 for processing and distribution to client machines 86 according to various matching criteria. Thus an issuing server 78 can issue such data records on behalf any entity that desires to issue data records representing fungible instruments. The type of entity, be it an entity that delivers goods or services or both, is not particularly limited though specific, non-limiting illustrative examples include retailers (e.g. clothing, grocery, durable goods), in which case the fungible instrument can represent currency, funds, a credit, or a coupon towards a portion or the entirety of a purchase price of a good available from that entity; or a service provider (e.g. telephony, personal grooming, airline, real estate agent, movie theatres, etc.), in which case the fungible instrument can represent currency, funds, a credit, or a coupon towards a portion or the entirety of a purchase price of a service available from that entity. By way of some further, but non-limiting examples, a fungible instrument can include passes, such as passes to movie theatres, concerts, executive airline lounges or an airline seating upgrade. Other examples of fungible instruments within the scope of this specification will now occur to those skilled in the art.

[0030] Each point of sale terminal 82 is also based on computing environment that is configured to finalize financial transactions whereby funds are exchanged for a particular good or service. The structure of such a computing environment again comprises an interconnection of processor(s), memory, along the lines of the computing environments described in relation to central server 54, however scaled in resources and software for point of sale purchases. The computing environment of each point of sale terminal 82 also typically includes one or more input devices in the form of one more of a keyboard, a pointing device and a proximity reader. Various types of proximity readers are contemplated including but not limited to bar code scanners, radio frequency identification (RFID) readers, smart card readers, and magnetic bar stripe readers. The foregoing generally contemplates a cash-register type staffed by a clerk, or an unstaffed stand-alone kiosk, the kind of point of sale terminal 82 found in retailers, service providers or other physical premises. Other types of point of sale paradigms are also contemplated within to be in the scope of point of sale terminals 82 however, including servers that are hosted by Internet retailers which process on-line ordering of goods which are scheduled for physical delivery, or services which may be rendered over the Internet (e.g. a media purchase or rental of music or film or book). It is generally contemplated that one or more point of sale terminals 82 are configured differently, with different computing environments, so that the particular processing operations to effect a financial transaction are different. Point of sale terminals 82 can also typically connected a traditional financial services clearing infrastructure 84 consisting of banks, credit card companies, and other financial institutions.

[0031] Client machines 86 can be based on any suitable computing environment, and the type is not particularly limited. For example, one or more of client machines 86 can be traditional client computers, such as a desktop computer, a laptop computer, or mobile computing device. A physical printer 94 is also shown, by way of example, as connected to client machine 86-p, though a printer may be connectable any of client machines 86 for printing a physical document.

[0032] As noted above, at least one account 94 is associated with each client machine 86. The means by which such association is effected is not particularly limited. However, presently it is contemplated that each client machine 86 will include an absolute identifier that is uniquely associated with each client machine 86 and a relative identifier that is associated with its respective account 94 and with the absolute identifier, thereby providing a logical link between the account 94 and the client machine 86. Such a linkage can be temporary where a set of credentials can be used to access the respective account 94 via the respective client machine 86. The linkage can also be more persistent, as is common in the mobile telephony context when client machine 86 is a mobile telephone that is associated with an account 94 belonging to a particular subscriber through a subscriber identity module (SIM) card or similar means depending on the applicable telecommunication standard.

[0033] Thus the specific nature of a given relative identifier and a given absolute identifier can vary according to the particular computing environment of each client machine 86 and the nature of its connection to network 74. As a non-limiting example, in a mobile telephony context, an absolute identifier can comprise an International Mobile Equipment Identity (IMEI) associated with a given client machine 86 that is implemented as a mobile smart phone. Likewise, in the mobile telephony context, relative identifiers can comprise an International Mobile Subscriber Identity (IMSI).

[0034] Referring now to Figure 2, a flowchart depicting a method for processing data records representing financial instruments is indicated generally at 200. Method 200 is one way in which central server 54 can be configured. It is to be emphasized, however, that method 200 need not be performed in the exact sequence as shown; and likewise various blocks may be performed in parallel rather than in sequence; hence the elements of method 200 are referred to herein as "blocks" rather than "steps". It is also to be understood, however, that method 200 can be implemented on variations of system 50 as well.

[0035] Block 205 thus comprises receiving a fungible instrument data record. In relation to system 50, it is assumed that such a fungible instrument data record is received at central server 54 from an issuing server 78 via network 74. Example, illustrative performance of block 205 is represented in Figure 3, as a fungible instrument data record 100-1 is shown as being sent from issuing server 78-1 via network 74 and being received at central server 54. Table I shows an illustrative, non-limiting example of the structure and contents of fungible instrument data record 100-1.

Table I

[0036] In Table I, Column 1 , labeled "Source" represents a issuing server 78 shown Figure 1 as discussed above. Column 2, labeled "Fungible Instrument Identifier" represents unique identifier for the fungible instrument data record. Column 3, labeled "Valuation" represents the financial or other consideration associated with the fungible instrument. Column 4, labeled "Good/Service" represents how the value in Column 3 may be applied. Column 5, labeled "Target Accounts Criteria" specifies any demographic information that may be used in conjunction with profile engine to identify which client machines 86 should ultimately receive the fungible instrument data record. Column 6, labeled "Expiration Criteria", specifies the time after which the fungible instrument becomes of zero value.

[0037] It is to be emphasized that the structure and contents of Table I are for illustrative purposes only, and are not intended to limit how a fungible instrument data record 100 may be structured, or what it may contain. Generally, however, each fungible instrument data record will typically at least include an indication of a valuation and a good or service against which such a valuation may be applied. The target account determination and the expiration, if any, can be omitted. Furthermore, the valuation itself can be dynamic in nature, by, for example, including ranges and criteria such that the ultimate valuation may be determined by central server 54 itself (e.g. The valuation may range from lOcents to 50cents, with the value increasing as the current time approaches the expiration time), or so that a specific value may be tailored to specific accounts 94 central server, (e.g. The valuation may be 50 cents for new accounts 94, and may be 10 cents for older accounts) However, the example contents of Table I will be referred to hereafter to further explain the present specification.

[0038] Block 210 comprises receiving profiles. \ln relation to system 50, it is assumed that one or more profiles 90 are received at central server 54 from profile engine 62 via link 58. Example, illustrative performance of block 205 is also represented in Figure 3, as a fungible instrument data record 100-1 is shown as being sent from issuing server 78-1 via network 74 and being received at central server 54. Table II shows an illustrative, non-limiting example of the structure and contents of profiles 90.

Table II

Exam le rofiles 90

[0039] In Table II, Column 1 , labeled "Source" represents profile engine 62 shown in Figure 1 as discussed above. However, at this point it can be pointed out that in variations, that profiles 90 can be obtained from multiple sources and need not all be stored in a single, or even local profile engine 62, though at some point it is contemplated the contents of various profiles would be normalized into a common record or tabular format. Column 2, labeled "profile identifier" represents one of the specific profiles 90 shown in Figure 1 and Figure 3. Column 3, labeled "Profile Data" represents profiling information for the specific profile. Column 4, labeled "Account" identifies a particular account 94 that is associated with the specific profile 90. And, as discussed above, each account 94 includes a relative identifier that has a linkage to a particular client machine 86, so each profile 90 has an implicit association with a specific client machine 86.

[0040] It is to be emphasized that the structure and contents of Table II are for illustrative purposes only, and are not intended to limit how profile 90 may be structured, or what it may contain. Generally, however, each profile 90 will typically at least include an indication of an account 94 (or other identifier that can be linked to a particular client machine 86) and profile data. The profile data itself may comprise a large plurality of variables, such as age, location, gender, address, occupation, annual income, purchasing history, hobbies, interests and the like, all of which can be used to develop a match between a particular instrument data record 100 and a particular account. Portions of the profile data may also be dynamically updated, such as a location of a particular client machine 86 associated with the profile 90, or a purchasing history associated with a given account 94. It will now be apparent that a rich amount of profile data can facilitate a rich set of target account criteria from Table I and can be used for more precise targeting of a given fungible instrument data record 100 to a given account 94 and client machine 86. However, the example contents of Table II will be referred to hereafter to further explain the present specification.

[0041] Referring again to Figure 2, Block 215 comprises determining target accounts. In relation to system 50, central server 54 is configured to perform a matching operation using the contents of the fungible instrument data record from block 205 and the contents of the profiles received at block 210. Again, the matching operation performed at block 215 is not particularly limited and can be as simple or as complex as desired, making use of profiles 90 and fungible instrument data record 100. For illustrative purposes, an simple matching operation is contemplated in relation to Table I and Table II, whereby the target account criteria of Table I ("homemaker") is compared with the profile data of Table II. A match is found only the first row of Table II, whereby profile 90-1 contains "homemaker", and accordingly a match between fungible instrument data record 100-1 and profile 90-1 is made, resulting in determining that account 94-1 is a target account.

[0042] Block 220 comprises preparing fungible instrument data records for the accounts determined at block 215. Block 220, which can be omitted in variations of this specification, contemplates that within the parameters of fungible instrument data record 100-1 , specific tailoring of that fungible instrument data record 100-1 may be desired prior to sending that fungible instrument data record 100-1 to the client machine(s) 86 associated with the target account(s) determined at block 215. For example, each client machine 86 may be based on a different computing environment, so that formatting, or data records, or communication channels may be different and so fungible instrument data record 100-1 may need to be tailored to so accommodate. As another example, the valuation, or expiry criteria, or other aspects of the fungible instrument data record 100-1 may be dynamically changed within parameters established by issuing server 78-1 , or within fungible instrument data record 100-1 , to tailor those aspects to the determine target account(s) 94. For example, different valuation, or different expiries may be sent to different accounts 94 to tailor those aspects to the unique profile 90 associated with those accounts. As another example, certain client machines 86 may operate on a "pull" paradigm, such as a web browser, so the preparation at block 220 is to create a web page that can be accessed from a client machine 86. Conversely, other client machines 86 may operate on a "push" paradigm, such as email, so the preparation at block 220 is create an email that can be sent to client machine 86. Other preparations are contemplated. For purposes of further discussion, it will be assumed that (as a result of performing block 220, in accordance with the example being discussed in relation to Table I and Table II) a modified fungible instrument data record 100-1 ' is generated.

[0043] Block 225 comprises sending the prepared fungible instrument data record to the target accounts (or client machine(s)) determined at block 215. Again the means by which the sending occurs is not particularly limited and is consistent with any preparations made at block 220. Figure 3 shows example performance of block 225 where modified fungible instrument data record 100-1 ' is sent from central server 54 to client machine 86-1.

[0044] Block 230 comprises determining if any response to the fungible instrument data record sent at block 225 has occurred. A "yes" determination results in advancement to block 235 at which point the response is processed. A "yes" determination is made when the prepared fungible instrument 100-1 ' sent at block 225 is processed at a point of sale terminal 82. Example "processing" at block 235 is discussed later in relation to method 300 and method 400. A "no" determination at block 230 leads to block 240 at which point a determination is made as to whether the fungible instrument 100-1 ' has expired. A "yes" determination ends method 200, while a "no" determination leads to block 210.

[0045] A "yes" determination can be made at block 240 in a number of ways. One way can be a determination based on a comparison of the current time with the expiration criteria provided in the final column of Table I. According to that specific example, if more than two weeks have passed since the performance of block 225, then a "yes" determination is made and method 200 ends, with the value of fungible instrument 100-1 ' being deemed at zero thereafter. Other ways for reaching a "yes" determination at block 240 can comprise reaching a point in time when a particular quantity of fungible instruments have been redeemed, which in turn can be further limited to a particular quantity for a particular geographic location, or by receipt of instructions from a relevant issuing server 100 that expiration has occurred. Still further ways of reaching a "yes" determination at block 240 will now occur to those skilled in the art. In a present embodiment, a "no" determination at block 240 leads to block 210, though variations are contemplated which will become apparent from further understanding of this specification. When block 210 is reached from block 240, then block 210, block 215, block 220 and block 225 can be performed again with further processing considering that no response was received at block 230. For example, if no response was received at block 230 then during a subsequent performance of block 215, different target accounts 94 may be determined than during the initial performance of block 215 in order to attempt to elicit a "yes" determination at block 230. As another example, if no response was received at block 230 then during a subsequent performance of block 220, a different valuation can be generated for the prepared fungible instrument 100-1' (e.g. an increased valuation) in order to increase likelihood of eliciting a "yes" determination at block 230.

[0046] Returning again to block 235, in general, a response is processed by central server 54 by receiving an indication that prepared fungible instrument 100-1 ' has been exchanged for its valuation and the associated good or service or portion thereof, and in addition, performing one or more of, recording particulars of that exchange at clearing engine 70, generating reports of the exchange for the respective issuing server 78, updating purchasing history of the respective profile.

[0047] The means by which the exchange of fungible instrument 100-1 ' is exchanged is not particularly limited, although presently, in general terms, it is contemplated such an exchange is initiated by outputting the prepared fungible instrument 100-1' from an output device within client machine 86 and inputting the prepared fungible instrument 100-1 ' into the respective point of sale terminal 82 (this encompasses outputting the prepared fungible instrument 100-1 ' from printer 94 in paper form and then inputting the data thereon into point of sale terminal 82) and then by an interaction between the target client machine 86 and a point of sale terminal 82. It is also presently contemplated that the prepared fungible instrument 100-1' is prepared in a format that can be processed at any point of sale of terminal 82, regardless of differences between the different computing environments of each point of sale terminal 82. This aspect will be explained further below.

[0048] Having emphasized that the means by which block 235 is effected is not particularly limited, some specific non-limiting examples will now be discussed. Referring now to Figure 4, a method for processing a fungible instrument data record is indicated generally at 300. In system 50, method 300 is a general process that can be performed at any point of sale terminal 82, despite the fact that each point of sale terminal 82 may have a different computing environment.

[0049] Block 305 comprises receiving a fungible instrument data record. In general terms block 305 contemplates a transfer of a prepared fungible instrument data record 100' from a client machine 86 into a point of sale terminal 82. Any suitable electronic transfer technique can be applied. Non-limiting examples of electronic transfer techniques include: a) the generation of a bar code or other optical indicia on the display of client machine 86, and the use of a bar code reader (or other optical reader apparatus) used a point of sale terminal 82; or b) the generation of a non-optical signal at client machine 86, such as an RFID signal, or an infra red signal, or a Bluetooth signal, or a near-field-communication signal, that is readable by an appropriate electronic reading device connected to point of sale terminal 82. Currently the former modality is considered to be more prevalent in present implementations, though the latter modalities can be accommodated should client machines 86 and point of sale terminals 82 be so equipped. Another contemplated electronic transfer technique includes the generation of an alphanumeric sequence on the display of the client machine 86 which can be manually typed directly into a keyboard connected to point of sale terminal 82. Other techniques, and combinations of the various techniques, are contemplated.

[0050] Block 310 comprises receiving processing instructions for the data record. In general terms, block 310 contemplates the loading of programming instructions into a local point of sale terminal 82 that are specific to the fungible instrument data record received at block 310, and yet consistent with the computing environment of the local point of sale terminal 82. As will be discussed further below, the programming instructions may comprise workflow(s), software object(s), or other type(s) of programming instructions, or combinations thereof. The means by which the loading occurs is not particularly limited and can again vary according to the computing environment of the local point of sale terminal 82. For example, the programming instructions may be manually loaded into the point of sale terminal 82, or if point of sale terminal 82 has network connectivity then the programming instructions may be downloaded dynamically at or near the time of performance of block 305. It can thus be noted that the timing of the loading can also occur at any time, and need not occur according to the sequence shown in Figure 4.

[0051] Block 315 comprises executing the programming instructions received at block 310, and thereby process the data record from block 305 at the local point of sale terminal. As part of the processing, the good or service is delivered taking into account the valuation in the fungible instrument data record 100.

[0052] Block 320 comprises sending a clearing data report to a clearing server or the like, noting the delivery of the good or service and the ultimate fulfillment of the terms of the fungible instrument data record 100.

[0053] As noted elsewhere, one of the features of this specification is the fact that different computing environments for different point of sale terminals 82 can be accommodated in relation to method 300 and its variants. Two specific examples of point of sale terminals 82 having different computing environments will now be discussed, and from that discussion the skilled reader will learn to appreciate how other point of sale terminal 82 computing environments can be accommodated according to the present teachings.

[0054] Referring now to Figure 5, a first example point of sale terminal is indicated generally at 82-1. Point of sale terminal 82-1 thus comprises a traditional cash register 104 and a portable computing device 108. Traditional cash register 104 can be purely mechanical, or electronic - and indeed can be based on any model of traditional cash register 104 that is little more than a simple adding machine. Such traditional cash registers 104 are typically equipped with a numeric keyboard 112 a rudimentary display for showing a total amount, or possibility to also show accumulated sub-totals. Such a traditional cash register 104 is typically capable of also producing a printed receipt showing the various items and their total. The ability to calculate and add sales tax is also often a feature of these traditional cash registers 104. Another feature that may be included in a traditional cash register 104 is the ability to subtract an amount from the subtotal to reflect a discount or a refund or to reverse an incorrect entry. The ability to update the programming instructions, if any, is typically very limited in such traditional cash registers 104.

[0055] Portable computing device 108 can be based on a personal digital assistant, a smart phone, a portable digital music player, a laptop computer, a tablet device or any other known platform for a portable computing device 108. Indeed, in variations portable computing device 108 can be based on a "non-portable" computer such as a desktop computer. However, unlike traditional cash register 104, portable computing device 108 is configured to readily and quickly accept and execute new programming instructions. Presently contemplated concrete examples that can be used to implement portable computing device 108 comprises a BlackBerry computing device from Research in Motion Inc., an iPhone, iPod or iPad computing device from Apple Computer Company, an Android phone based on the eponymous operating system from Google Inc., or a Windows phone based on the operating system from Microsoft. System 50 can also be configured to support a plurality of different types of portable computing devices 108. Generally, for efficiency, the more ubiquitous and inexpensive portable computing device computing environments would be preferred for portable computing device 108, although this is by no means a limitation to the present specification. Also in a present implementation, portable computing device 108 typically includes an ability to connect to network 74 in order to download an "app" or other software object that reflects the programming instructions contemplated at block 310. Also in a present implementation, portable computing device 108 includes a camera or other electronic input device. Where a camera is used, then block 305 can be implemented by generating a optical indicia such as a bar code or a QR code on the display of client machine 86, while the camera on portable computing device 108 can be used "photograph" or otherwise optically receive an electronic image of the bar code being generated on the display of client machine 86. According to this specific example, a bar code generated on the display of client machine 86 can include data representing fungible instrument 100', or the bar code can include its own programming instructions that cause portable computing device 108 to download the application that implements block 310 via network 74, or depending on the functionality of portable computing device 108, the bar code may contain both. These details thus impact the sequence in which block 305 and block 310 occur, but the skilled reader will now appreciate various ways to effect block 305 and block 310 according to the functionality of client machine 86 and portable computing device 108.

[0056] In relation to the specific example discussed in relation to point of sale terminal 82-1 , block 315 thus contemplates execution of the programming instructions received at block 310. At this point it can be noted that the programming instructions at block 310 are executable on portable computing device 108, but are also tailored to the specific model of traditional cash register 104. The programming instructions at 310 include an examination of the contents of fungible instrument data record 100', which are now locally stored in portable computing device 108, and also include the generation, on the display of portable computing device 108, a set of instructions advising a sequence of keystrokes on traditional cash register 104 instructing how to record the valuation redemption associated with fungible instrument data record 100'.

[0057] According to the specific example in relation to Figure 5 and portable computing device 108, block 315 can thus include the installation of a set of programming instructions 114 onto portable computing device 108 that results in the generation on the display of portable computing device 108, a set of screens with a workflow 115 as follows:

[0058] SCREEN 1 : "You are currently using a traditional cash register of the model type . This device has currently received an electronic coupon (I.e. a fungible instrument data record) worth 10cents towards the purchase of a can of ACME tomato soup. Press "continue" if you are ready to complete the cash register transaction of this purchase".

[0059] SCREEN 2: "Enter the full purchase price of the ACME tomato soup can into the cash register as normal. Press "continue" when this is complete."

[0060] SCREEN 3: "Press the "coupon redeem" button located in the lower right corner of the cash register. Press "continue" when this is complete."

[0061] SCREEN 4: "Enter the amount of 10 cents into the cash register. Press "continue" when this is complete."

[0062] SCREEN 5: "The subtotal should now be reduced by 10 cents on the display of the cash register. Press "continue" to end this program and to send confirmation of this transaction back to the "ACME" soup company. On doing so, a credit in the amount of 10 cents will be sent to you."

[0063] (As an optional, additional auditing step, a screen can be generated instructing the scanning (using portable computing device 108) of the bar code on the tin of the ACME tomato soup that is being sold.)

[0064] Once "continue" is pressed from SCREEN 5, block 320 is invoked and, in relation to point of sale terminal 82-1 , is ultimately performed by portable computing device 108 sending a message over network 74 to issuing server 78 or clearing server 70 or both to record the redemption of fungible instrument data record 100-1', expire its value, and to initiate payment processing to the operator of point of sale terminal 82-1. Advantageously it can be noted that the a plurality of redemptions of fungible instrument data records 100 originating from the same issuing server 78 can be accumulated so only a single credit representing the accumulation need be processed.

[0065] This five screen workflow is of course a simplification but illustrates how portable computing device 108 can be dynamically configured to provide a workflow set of instructions as to how to effect the transaction contemplated in the fungible instrument data record 100' in relation to the specific make and model of traditional cash register 104.

[0066] Having discussed a first example point of sale terminal 82-1, a second example point of sale terminal 82-2 will now be discussed in relation to Figure 6. Point of sale terminal 82-2 thus comprises a modern electronic cash register 116 which is based on a desktop computing platform and accordingly includes a full alpha-numeric keyboard, a full computer monitor, a mouse or other pointing device. Modern electronic cash register 116 also includes its own bar code reader 120 (or other proximity reader). Modern electronic cash register 116 also includes network connectivity to network 74. While not shown, modern electronic cash register 116 also typically includes electronic payment processing equipment such as a magnetic stripe card reader, or smart card reader. Modern electronic cash register 116 comprises a rich computing environment and may be based on a well-known desktop operating system such as Windows from Microsoft Corporation. Thus modern electronic cash register 116 is capable of performing all of the functions of traditional cash register 104, but is also dynamically configurable to perform many more functions. Such additional functions can include, but are not limited to, credit card or debit card processing, generation of very detailed itemized receipts, the ability to scan an article with a bar code and automatically identify the article and its price. Thus, there a number of ways to implement method 300 on point of sale terminal 82-2 including the generation of a workflow of the type discussed above in relation to point of sale terminal 82-1 , although more likely the need for such a workflow is obviated because the actual processing of the redemption can be programmed directly into modern electronic cash register 116, such that once the fungible instrument data record 100' is received via bar code reader 110, the remainder of method 300 can be performed entirely by modern electronic cash register 116. Accordingly, method 300 can be modified according to the specific make and model of modern electronic cash register 116.

[0067] It will now be understood that other computing environments for different point of sale terminals 82 are contemplated, other than the specific examples of point of sale terminal 82-1 and point of sale terminal 82-2. For example, a hybrid is contemplated whereby portable computing device 108 is used in conjunction with modern electronic cash register 116. In this manner, no modification is needed to modern electronic cash register 116, and thus if one has not been effected, then portable computing device 108 in conjunction with modern electronic cash register 116 to effect method 300, creating a unique workflow set of screens on portable computing device 108 instructing operation of modern electronic cash register 116.

[0068] Referring now to Figure 7, a flowchart depicting a method of clearing a fungible instrument data record is indicated generally at 400. Method 400 can be performed by clearing server 70 in response to the clearing data record sent at block 320, and overall as a part of block 235, but it is to be understood that variations on method 400 are contemplated.

[0069] Block 405 thus comprises receiving a clearing data record for a fungible instrument record. As noted above, block 405 can be invoked in response the clearing data record sent at block 320. In system 50, the clearing data record is received at clearing server 70.

[0070] Block 410 comprises expiring the fungible instrument data record. Block 410 thus contemplates setting a flag so that a prepared fungible instrument data record cannot be redeemed again, so that only a single full performance of method 300 can occur for a single prepared fungible instrument data record 100'. On this point, another variation on method 300 can be pointed out, whereby as part of method 300 a validation request can be sent to clearing server 70 querying whether or not the particular prepared fungible instrument data record 100' is valid, or has not otherwise expired. Alternatively, or in addition, client machine 86 can be configured so that fungible instrument data record 100' is deleted upon performance of method 300. Thus, as part of block 410, an instruction can be sent to client machine 86-1 instructing the deletion of prepared fungible instrument data record 100-1'.

[0071] Block 415 comprises updating the account. By way of a specific example of what can be effected at block 415, block 415 contemplates that the profile 90 associated with the client machine 86 that was involved at block 305 is updated to record the fact that a redemption of a particular fungible instrument data record 100-1' occurred. This updated aspect of the profile 90 can be used during subsequent performances of block 215 as part of determining whether or not to include that target account as part of delivery of another fungible instrument data record. Block 415 can also contemplated directly accessing a respective account 94 with a similar record, or to send the prepared fungible instrument expiry instruction to the relevant client machine 86, as discussed above in relation to block 410.

[0072] Block 420 comprises sending a clearing data record report to the issuing server. Again, as noted elsewhere herein, block 420 can be obviated in variations of method 400, but in a present implementation an report is sent back to the issuing server 78 that sent the original fungible instrument data record at block 205, so that the issuing server 78 can, for example, process payments to an entity that operates the relevant point of sale terminal 82 or to perform its own analytics on the success of promoting a good or service or for any other purpose desired.

[0073] Variations are contemplated.

[0074] For example, as noted above Table I is an illustrative, non-limiting example of the structure and contents of fungible instrument data record 100-1 , but variations are contemplated. Table l-A shows an example of such a variation.

Table l-A

Example fun ible instrument data record 100-1

[0075] Of note is that Table l-A is substantially the same as Table I, however, Table l-A further includes an additional column that identifies a particular workflow that is used in association with redemption of fungible instrument data record 100-1. In Table l-A, the final column is populated with "115", which refers to the example workflow 115 labelled in Figure 5 and discussed above in relation to five example screens. According to this variation, the specific workflow 115 for processing fungible instrument data record 100-1 is uniquely identified within the fungible instrument data record 100-1 itself, thus contemplating that other fungible instrument data records 100 (not shown) may have their own respective workflows (not shown). That specific workflow 115 can be dynamically downloaded over network 74, from, for example, central server 54, or could even be embedded within QR code (or other proximity code) generated on the display of the relevant client machine 86 that is scanned by portable computing device 108.

[0076] By the same token, Table l-A can also be implemented or used by point of sale terminal 82-2 in a similar manner.

[0077] As another variation, a modified version of method 300 is shown in the form of a flowchart and labeled as method 300a in Figure 8. Method 300a is thus substantially the same as method 300, and like blocks bear like references except followed by the suffix "a". Of note is that method 300a also includes block 307a where a determination is made as to whether the fungible instrument data record received at block 305a is valid. A "yes" determination leads to block 310a and method 300a continues as described above in relation to method 300. However, a "no" determination leads to block 308a where an exception process is invoked. Such an exception process can be an error message indicating that the fungible instrument data record is not valid and a termination of method 300.

[0078] The means by which the validation at block 307a occurs is not particularly limited. In one implementation, the validation may be performed remotely, by, for example, a validation request using information within the fungible instrument data record 100 which is sent to central server 54 (or other component attached to network 74) to determine if the received fungible instrument data record 100 is valid, (e.g. it has not been previously used or is otherwise expired). In another implementation, the validation can be performed locally based on local processing interactions. As a simple example if the expiration criteria within Table I has passed, then point of sale terminal 82 can locally determine that the received fungible instrument data record 100 is invalid. As a more complex example, hashing information, encryption key or checksum information can be incorporated into fungible instrument data record 100 which must be validated against locally stored criteria within the point of sale terminal 82. Combinations of remote validation and local validation techniques can also be employed at block 307a. [0079] A still further variation, it is contemplated that various aspects can be implemented on a more peer-to-peer basis to reduce or obviate certain interactions with central server 54. Indeed, as noted above with relation to block 307a, it is contemplated that validations at block 307a can be purely local. However, as another example, the expire function at block 410 could be also performed by point of sale terminal 82 sending an instruction to client machine 86 to delete fungible instrument data record 100 from client machine 86 once the processing instructions at block 315 are completed, thereby rendering fungible instrument data record 100 unavailable for future use from client machine 86. This expire function could be done in addition to block 410, or in lieu of block 410. Other peer-to-peer functionality will now occur to those skilled in the art.

[0080] As another variation, method 300 can be modified to provide an enhancement to the valuation or the good or service of the fungible instrument data record 100 depending on variables unique to the actual time or location that method 300 is executed. For example, using the example in Table I, an additional valuation of $1.00 and an additional good of a "Reduction in price of a second tin of ACME tomato soup" can be added at the time of execution of block 315. The variables can include, for example, a level of inventory of the particular good associated with the enhancement, or based on a level of funds received at the point of sale terminal 82 in association with performance of method 300.

[0081] Figure 9 shows a further flowchart with a further variation, depicting a method for modifying a profile and indicated generally at 500. Method 500 comprises, in association with a particular profile 90, including a setting that records the number of times a redemption in association with a particular account 94 has occurred. The incrementing occurs at block 520, and occurs every time method 300 or method 300a or one of its variants (i.e. a redemption) of a fungible instrument for a particular profile 90 and account 94 occurs. Block 510 contemplates setting a redemption level based on the number of recorded redemptions. The level set in block 510 can then be used at block 220 and block 225, to dynamically adjust the contents of the valuation or the good or service within fungible instrument data record 100 according to the redemption level. In one implementation, it is contemplated that the valuation for a particular good or service may increase with an increased redemption level.

[0082] A variation on method 500 contemplates further increasing the redemption level (leading to selection of different valuation for a particular good or service, or changing a particular good or service at block 220 and block 220 of method 200) where a particular account 94 is used to identify other accounts 94 which are used to create new profiles 90 for those other accounts 94, thereby increasing the pool of profiles 90 that are available to profile engine 62.

[0083] As another variation, it is contemplated that central server 54 and its related components could be omitted altogether, with a "peer-to-peer" type model being used with issuing server(s) 78 directly communicating with client machines 86 and point of sale terminals 82, such that method 200 is performed by each individual issuing server 78. In another notable variation, the profiling of block 210, block 215, block 220 are omitted, with the fungible instrument data record 100 being widely broadcast to any or all client machines 86. As a further example, while method 400 was specifically discussed as being performed by clearing engine 70, in a variation, blocks 405 and block 410 could be performed by an issuing server 78 and block 415 and block 420 could be omitted. Such a variation could also be performed in addition to method 400 being performed by clearing engine 70.

[0084] It is also contemplated that method 300 can stand alone from other aspects of this specification, particularly in relation to point of sale terminal 82-1 and its usage of portable electronic device 108, and utilized in relation to other fungible instrument data processing method.

[0085] Referring now to Figure 10, a first embodiment of a mounting frame for portable computing device 108 is indicated generally at 600. Specifically, mounting frame 600 may be used as part of, or in conjunction with, point of sale terminal 82-1 as shown in Figure 5. Mounting frame 600, as shown in Figure 10, comprises a first surface 605, a second surface 610 and an optical path 615 (shown in Figure 11). The first surface 605 and the second surface 610 are held in a fixed geometrical relationship to one another by a base 620.

[0086] First surface 605 comprises a cut-out 625. Cut-out 625 is sized and shaped to accommodate portable computing device 108, which may comprise an iPod, iPhone, iPad, android device, etc. as discussed above. Portable computing device 108 also comprises a camera. In the present embodiment cut-out 625 is sized and shaped to retain portable computing device 108 in order to retain portable computing device 108 within cut-out 625. First surface 605 may, as shown, also comprise overlapping portion 626. Overlapping portion 626 aids in retaining portable computing device 108 within cut-out 625 by overlapping a portion of portable computing device 108. Preferably, overlapping portion 626 overlaps a portion of portable computing device 108 but leaves a gap, as shown, so that controls on portable computing device 108 may be accessed, into which a user may insert a finger to aid in the removal of portable computing device 108.

[0087] In an alternative embodiment (not shown), cut-out 625 may be sized an shaped to be sufficiently large to accommodate any one of several different implementations of portable computing device 108. In this alternative embodiment, at least one insert, customized to a particular implementation of portable computing device 108, is also provided. In this alternative embodiment, cut-out 625 is sized and shaped to retain the edges of the at least one insert while the at least one insert is sized and shaped to retain the edges of the particular implementation of portable computing device 108 to which it has been customized so that portable computing device 108 is retained within cut-out 625.

[0088] The orientation of first surface 605 is selected for ease of use of portable computing device 108, specifically, first surface 605 is oriented so that a person operating point of sale terminal 82-1 will find be able to view the display of portable computing device 108 and enter input into portable computing device 108. Typically, first surface 605 will be angled between about zero and about 90 degrees. Preferably, as in the embodiment shown, first surface 605 will be angled at about 45 degrees.

[0089] Attached to the back side of surface 605 is a backing plate 606 comprising a hole 630. Backing plate 606 helps retain portable computing device 108 within cut-out 625. Backing plate 606 is attached to the back side of first surface 605 in such a manner that the aperture of the camera of portable computing device 108 is aligned with hole 630 and optical path 615. Backing plate 606 is mounted removably mounted to the backside of first surface 605 by any suitable means known to those of skill in the art. Preferably, backing plate 606 may be repositioned so that mounting frame 600 may be reconfigured to accommodate a multitude of different implementations of portable computing device 108.

[0090] Second surface 610 comprises a window 635. Window 635 is sized so that at least a portion of the display on client machine 86-1 may be imaged through window 635. Window 635, as in the embodiment shown, may consist only of a gap in second surface 610 through which light may pass. Alternatively, window 635 may comprise an optically transparent material such as glass or plastic, the selection of which may be accomplished according to known methods by those of skill in the art.

[0091] The orientation of second surface 610 is selected for ease of use of client machine 86-1 , specifically, second surface 610 is oriented so that a person operating client machine 86-1 will be able to position client machine 86-1 such that the display of client machine 86-1 may be imaged through window 635. Typically, second surface 610 will be angled between about zero and about 90 degrees. Preferably, as in the embodiment shown, second surface 610 will be angled at about 45 degrees.

[0092] Optical path 615 optically connects hole 630 in first surface 605 with window 635 in second surface 610 so that the camera in portable computing device 108 may capture an image of the display of client machine 86-1. In the embodiment shown in Figure 11 , optical path 615 is redirected once by mirror 640. Mirror 640 is mounted to base 620 with support platform 641. As shown, first surface 605 and second surface 610 are both angled about 45 degrees, although in opposite directions, therefore optical path 615 must be turned about 90 degrees in order to optically connect hole 630 with window 635. The placement of mirror 640, shown as angled about zero degrees, and the height of support platform 641 are selected so that optical path 615 will optically connect hole 630 to window 635. Different desired orientations of first surface 605 and/or second surface 610 may necessitate a different placement and orientation of mirror 640 as well as a different height of support platform 641.

[0093] Those skilled in the art will realize that, since optical path 615 is redirected once, the image captured at portable computing device 108 will be a "mirror image" of the display at client machine 86-1 and may according to the capability of portable computing device 108 require further processing, according to known methods, by portable computing device 108 in order to correct the image, before processing the content of the fungible instrument 100-1.

[0094] In use, as shown in Figure 17, portable computing device 108 is installed in cut-out 625 so that the camera in portable computing device 108 is aligned with hole 630, along optical path 615. Cut-out 625 retains the sides of portable computing device 108 and backing plate 606 supports portable computing device 108 so as to retain portable computing device 108 within cut-out 625. Client machine 86-1 is then placed in window 635 until an image of the display on client machine 86-1 is captured by the camera on portable computing device 108 via optical path 615. It is contemplated that one way for client machine 86-1 to remain in window 635 while an image is captured, is that a client, after turning the display on client machine 86-1 away from themselves, will hold client machine 86-1 in window 635. The captured image is then processed by portable computing device 108 and client machine 86-1 is removed. Portable computing device then displays instructions and prompts based on the nature of the fungible instrument 100-1 associated with the captured image as discussed above. [0095] In some alternative embodiments, it is contemplated that optical path 615 may be redirected as few as zero times or as many as two or more times in order to accommodate the desired geometry of first surface 605 and second surface 610. Figures 18 and Figure 19 show other sample geometries. Those of skill in the art will appreciate that the number of mirrors as well as the location and orientation of those mirrors may be adjusted to suit a preferred geometry of the first surface 605 and the second surface 610. Referring now to Figure 18, an alternative embodiment of a mounting frame 700 is shown. In this embodiment, second surface 610 is the opposite side of backing plate 606. Hole 630 and window 635 are co-located. Optical path 615 is not redirected. Client machine 86-1 may be placed directly into optical path 615, perhaps lying on the open palm of a client, so that the camera on portable computing device 108 may image the display of client machine 86-1. In use, the embodiment shown in Figure 17 has portable computing device 108 installed in cut-out 625 with the camera on portable computing device 108 aligned along optical path 615. When a display of client machine 86-1 is positioned in optical path 615 an image of the display on the client machine 86-1 is captured and processed by portable computing device 108. The procedure then continues as discussed above.

[0096] Referring now to Figure 19, an alternative embodiment of a mounting frame 800 is shown. In this embodiment, optical path 615 is redirected twice by mirrors 640. In use, the embodiment shown in Figure 18 has portable computing device 108 installed in cut-out 625 with the camera on portable computing device 108 aligned along optical path 615. When a client machine 86-1 is placed in optical path 615, perhaps by placing client machine 86-1 face up on a counter-top, an image of the display on the client machine 86-1 is captured and processed by portable computing device 108. The procedure then continues as discussed above.

[0097] While the foregoing provides certain non-limiting example embodiments, it should be understood that combinations, subsets, and variations of the foregoing are contemplated.

[0098] The present specification thus provides a novel system for processing data records representing fungible instruments. Various advantages are afforded by the present specification and will now be apparent, including the fact that a plurality of disparate issuers operating issuing servers 78 can each issue different fungible instrument data records 100 which can be delivered to a plurality of disparate client machines 86, and redeemed on a plurality of disparate point of sale terminals 82 thereby providing a unified electronic system for managing fungible instrument data records that is agnostic to the various different computing environments that may be employed to implement various components of the system.

Claims

A method for processing a data record representing a fungible instrument at a point of sale terminal having a specific computing environment comprising:

receiving a data record representing a fungible instrument;

receiving a set of programming instructions unique to the fungible instrument and unique to the specific computing environment;

executing the programming instructions to redeem a value assigned to the fungible instrument; and

sending a clearing data record to a clearing server.

The method of claim 1 wherein the step of receiving a data record representing a fungible instrument comprises an electronic transfer of the data record from a client machine to the point of sale terminal.

The method of claim 2 wherein the electronic transfer is accomplished by generating and displaying optical indicia on a display of the client machine and reading of the optical indicia by the point of sale terminal.

The method of claim 3 wherein the optical indicia comprise data representing the fungible instrument.

The method of claim 3 wherein the optical indicia comprise the programming instructions unique to the fungible instrument and unique to the specific computing environment.

The method of any one of claims 1-5 wherein the specific computing environment comprises a portable computing device and a traditional cash register.

The method of claim 6 wherein the programming instructions unique to the fungible instrument and unique to the specific computing environment comprise instructions for recording the fungible instrument using the traditional cash register.

The method of any one of claims 1-4 wherein the specific computing environment comprises a modern cash register.

9. The method of any one of claims 1 -8 further comprising validating the fungible instrument.

10. A point of sale terminal for processing a data record representing a fungible

instrument at a point of sale terminal having a specific computing environment, the point of sale terminal configured to:

receiving a data record representing a fungible instrument;

sending a clearing data record to a clearing server.

11. The point of sale terminal of claim 10 wherein the point of sale terminal comprises a portable computing device and a traditional cash register.

12. The point of sale terminal of claim 11 wherein the executing the programming

instructions to redeem a value assigned to the fungible instrument comprises displaying instructions for entering information about the fungible instrument into the traditional cash register.

13. The point of sale terminal of claim 10 wherein the point of sale terminal comprises a modern cash register.

14. The point of sale terminal of claim 10 wherein the receiving a data record

representing a fungible instrument comprises an electronic transfer of the data record from a client machine to the point of sale terminal.

15. The method of claim 14 wherein the electronic transfer is accomplished by

generating and displaying optical indicia on a display of the client machine and reading of the optical indicia by the point of sale terminal.

16. The method of claim 15 wherein the optical indicia comprise data representing the fungible instrument.

17. The method of claim 15 wherein the optical indicia comprise the programming instructions unique to the fungible instrument and unique to the specific computing environment.

18. An mounting frame comprising:

a. a base;

b. a first surface mounted to the base, the first surface comprising a hole and means for aligning a camera on a portable computing device with the hole; c. a second surface mounted to the base, the second surface comprising a window through which a display on a client machine may be imaged; and d. an optical path, the optical path optically connecting the hole and the window such that the camera on the portable computing device may image the display on the client machine.

19. The mounting frame of claim 18 wherein first surface comprises a cut out for

receiving an insert and the means for aligning a camera on a portable computing device with the hole comprises an insert shaped to accommodate a portable computing device and align the camera on the portable computing device with the hole.

20. The mounting frame of claim 18 further comprising at least one mirror mounted to the base, the at least one mirror redirecting the optical path such that the camera on the portable computing device may image the display on the client machine.