Vending Machines for Schools POS Interface Architecture

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

2. <VENDING_REQUEST> <VENDING_RESPONSE> <VENDING_REQUEST> <VENDING_RESPONSE> (i.e. – YES or NO, plus Any Essential Messages to Be Displayed on The iGuard LCD) Information technology landscape In-School Student Information System Server iGuard™ LM-SM-5000: configured as the Master iGuard device Application Programs Running on the In-School Food Service Server • Connected to other In-School Applications via Router& the In-school LAN • Source of Student Admin Update Data <DAILY_STUDENT_ADMIN_UPDATE (T.B.D.)> 1 Vending Machine 6 Vending Machine 6 All iGuard Devices Are Connected to One Another and the API via Router to the In-School LAN Vending Machine 6 iGuard API (using the API Server Module & its Windows Messaging Capabilities) Vending Machine 6 POS System Middleware Vending Machine 6 Vending Machine 6 Vending Machine 7 POS System • 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 In-School Food Service 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. 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. Interface communications sequence (continued) • iGuard API receives iGuard data structure and sends to POS Middleware a <VEND_REQUEST> message containing {STUDENT_PIN} and waits for response • POS Middleware receives <VEND_REQUEST> and relays to POS for processing • POS System • Receives and processes <VEND_REQUEST> message & processes request from student for reimbursable meal • Generates <VEND_RESPONSE> 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 <VEND_RESPONSE> message to POS Middleware • POS Middleware receives <VEND_RESPONSE> message and relays to iGuard API for processing

5. Interface communications sequence (continued) • iGuard API receives <VEND_RESPONSE> from POS Middleware and relays to the awaiting iGuard • The awaiting iGuard receives the incoming <VEND_RESPONSE> 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 <VEND_RESULT> 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] • <VEND_RESULT> completes the audit trail for food service accounting • Interface Communication Complete

6. iGuard API-to-POS <VEND_REQUEST> {STUDENT_PIN} <VEND_RESULT> {MEAL_SERVED} including an optional {NOT_SERVED_REASON_CODE} when desired POS-to-iGuard API <VEND_RESPONSE> {VEND_SALE} including optional {VEND_ RESPONSE_MSG} when desired • 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

7. Data element dictionary

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 interface1 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