1. Vending Machines for Schools POS Interface Architecture for the Reimbursable School Meals Program

2. iGuard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V6.ppt 2 Information technology landscape Vending Machine 6 Multiple iGuard™ LM520-FSCs: Configured as Slave devices Communicate Directly with SuperMaster™ to Retrieve Student Fingerprint Templates for PINs Not Resident on the Individual Device Communicate Directly with iGuard™ API for POS Message Processing iGuard™ LM-SM-5000: configured as the Master iGuard device iGuard API (using the API Server Module & its Windows Messaging Capabilities) POS System Vending Machine 7 All iGuard Devices Are Connected to One Another and the API via Router to the In-School LAN POS System Middleware In-School Food Service Server Connected to other In-School Applications via Router& the In- school LAN Source of Student Admin Update Data 1 Application Programs Running on the In-School Food Service Server (i.e. – YES or NO, plus Any Essential Messages to Be Displayed on The iGuard LCD) In-School Student Information System Server (1) Daily_Student_Admin_Update will likely be accomplished through a download from the POS System, since it already receives a daily update from the Student Information System Server; actual iGuard update process is still to be defined.

3. iGuard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V6.ppt 3 Interface communications sequence Interface Communication Start Student enters PIN and presents fingerprint to iGuard scanner mounted on vending machine –iGuard authenticates identity of student using fingerprint template –iGuard retrieves student fingerprint template from SuperMaster™ for any PIN entered at the machine that is not found in the local device iGuard sends a data structure to iGuard API via LAN and waits for response (i.e. – vending decision); agreed data structure will contain: –PIN of authenticated student Exact format of PIN to be specified for each POS System Will likely be the normal POS PIN now used by student in a check-out line –Any other data elements deemed essential & mandatory by the project team stakeholders

4. iGuard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V6.ppt 4 Interface communications sequence (continued) iGuard API receives iGuard data structure and sends to POS Middleware a message containing {STUDENT_PIN} and waits for response POS Middleware receives and relays to POS for processing POS System –Receives and processes message & processes request from student for reimbursable meal –Generates message (in an agreed data structure) Must contain {VEND_SALE} [This is a YES or NO decision on the sale of a reimbursable meal to the awaiting student] [Mandatory] May contain a {VEND_ RESPONSE_MSG} string constant for display in iGuard LCD to the awaiting student [Optional] –Sends message to POS Middleware POS Middleware receives message and relays to iGuard API for processing

5. iGuard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V6.ppt 5 Interface communications sequence (continued) iGuard API receives from POS Middleware and relays to the awaiting iGuard The awaiting iGuard receives the incoming message and –Interprets the {VEND_SALE} response & generates vending action command to the appropriate vending machine circuitry –Displays any {VEND_ RESPONSE_MSG} message in iGuard LCD –Generates a message containing {MEAL_SERVED} and sends to the POS Middleware for relay to POS System {MEAL_SERVED} confirms delivery/non-delivery of a reimbursable meal to the awaiting student [MANDATORY] {NOT_SERVED_REASON_CODE} can be included if desired [OPTIONAL] completes the audit trail for food service accounting Interface Communication Complete

6. iGuard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V6.ppt 6 What is the simplest way to transfer these three messages between systems so that communications are independent of the specific POS System that controls food service operations in the school? We think it is through the use of the iGuard API and its Windows Messaging protocol…, but Is this the best overall technical solution? Data element transfers required of the interface iGuard API-to-POS 1. {STUDENT_PIN} 3. {MEAL_SERVED} including an optional {NOT_SERVED_REASON_CODE} when desired POS-to-iGuard API 2. {VEND_SALE} including optional {VEND_ RESPONSE_MSG} when desired

7. iGuard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V6.ppt 7 Data element dictionary Data ElementDefinition & Example 1. {STUDENT_ID}Normal 4 or 5 digit POS PIN Code used by student at cafeteria line check-out register [e.g. – 4552] 2. {VEND_SALE}A one-bit switch that authorizes or denies sale of a reimbursable school meal to the awaiting student [e.g. – 1 = YES; 0 = NO] 3. {VEND_ RESPONSE_MSG} [Optional] A string constant that can accompany {VEND_SALE} to convey a message to the awaiting student [e.g. – if VEND_SALE = 0, then {VEND_RESPONSE_MSG=“Declined, Please See Cashier” 4. {MEAL_SERVED}A one-bit switch that confirms: Delivery of a reimbursable meal to the awaiting student, or Non-delivery of a reimbursable meal to the awaiting student [e.g. – 1 = DELIVERED; 0 = NOT DELIVERED] 5. {NOT_SRVD_RSN_CODE} [Optional] A string constant accompanying {MEAL_SERVED} that conveys to the POS a reason why the meal was not delivered. [e.g. – if VEND_SALE = 0, then {NOT_SRVD_RSN_CODE = 2} if reason for non-delivery was “Vending Machine Malfunction”. Acceptable values and definitions will be predefined.

8. iGuard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V6.ppt 8 Using iGuard API as a common vending interface Reasons to use the API (Pro’s) –It is already developed, tested & deployed with other interfaced applications today –It uses standard Microsoft Windows messaging protocol to communicate –Through this API, we can provide any data structure needed by the interfaced POS application –This API could serve as the standard interface point for use in communications with any POS System [using a very small set of standard data elements] Reasons not to use the API (Con’s) –It makes the interface OS-dependent (i.e. – Microsoft Windows) –It does not contain as many robust features as would a standard TCP/IP Client-Server application interface 1 for managing Dropped communications and the resulting missed messages Reprocessing open / unresolved messages until they are satisfactorily processed 1 As outlined in POS – iGuard™ Interface Specification, Version 2