Vending Machines for Schools POS Interface Architecture for

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

Information technology landscape i. Guard™ LM-SM 5000: configured as the Master i. Guard device Application Programs Running on the In-School Food Service Server <DAILY_STUDENT_ADMIN_UPDATE (T. B. D. )> 1 <VENDING_REQUEST> All i. Guard Devices Are Connected to One Another and the API via Router to the In-School LAN Vendin g Machi. Vendin g ne. Machi 6 Vendin g g ne. Machi 6 Vendin ne. Machi 6 g ne. Machi 6 ne 7 Multiple i. Guard™ LM 520 -FSCs: • Configured as Slave devices • Communicate Directly with Super. Master™ to Retrieve Student Fingerprint Templates for PINs Not Resident on the Individual Device • Communicate Directly with i. Guard™ API for POS Message Processing (1) i. Guard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V 6. ppt <VENDING_RESPONSE> i. Guard API (using the API Server Module & its Windows Messagin g Capabiliti es) POS System Middlewar e In-School Student Information System Server • Connected to other In-School Applications via Router& the Inschool LAN • Source of Student Admin Update Data POS System <VENDING_REQUEST> <VENDING_RESPONSE> (i. e. – YES or NO, plus Any Essential Messages to Be Displayed on The i. Guard LCD) In-School Food Service Server 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 i. Guard update process is still to be defined. 2

Interface communications sequence • Interface Communication Start Student enters PIN and presents fingerprint to i. Guard scanner mounted on vending machine – i. Guard authenticates identity of student using fingerprint template – i. Guard retrieves student fingerprint template from Super. Master™ for any PIN entered at the machine that is not found in the local device • i. Guard sends a data structure to i. Guard 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 i. Guard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V 6. ppt 3

Interface communications sequence (continued) • • • i. Guard API receives i. Guard 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 i. Guard LCD to the awaiting student [Optional] – Sends <VEND_RESPONSE> message to POS Middleware • POS Middleware receives <VEND_RESPONSE> message and relays to i. Guard API for processing i. Guard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V 6. ppt 4

Interface communications sequence (continued) • • i. Guard API receives <VEND_RESPONSE> from POS Middleware and relays to the awaiting i. Guard The awaiting i. Guard 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 i. Guard 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 i. Guard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V 6. ppt 5

Data element transfers required of the interface i. Guard API-to-POS 1. <VEND_REQUEST> {STUDENT_PIN} POS-to-i. Guard API 2. <VEND_RESPONSE> {VEND_SALE} including optional {VEND_ RESPONSE_MSG} when desired 3. <VEND_RESULT> {MEAL_SERVED} including an optional {NOT_SERVED_REASON_CODE} 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 i. Guard API and its Windows Messaging protocol…, but • Is this the best overall technical solution? i. Guard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V 6. ppt 6

Data element dictionary Data Element Definition & 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. i. Guard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V 6. ppt 7

Using i. Guard 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 i. Guard – POS Interface Configuration, Version 6 RSMP Equip Config Overview_V 6. ppt outlined in POS – i. Guard™ Interface Specification, Version 2 8