SYSTEM AND METHOD FOR CONTROLLING DEVICES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on and derives the benefit of the filing date of United States Provisional Patent Application No. 61/360,091 , filed June 30 _. . 2010. The entire content of this application is herein incorporated by reference in its entirety.

BRIEF DESCRIPTION OF THE DRAWINGS

|0 ⁽ )02| FIGURE 1 illustrates a communications system, according to one embodiment. |0003| FIGURE 2 illustrates a method for utilizing a communications system, according to one embodiment.

[0004] FIGURES 3-8 illustrates various details of the IVC software, according to several embodiments.

DESCRIPTION OF EMBODIMENTS OF THE INVEN ION

Intelligent Device System

[00051 FIGURE 1 illustrates a communications system 100. according to one embodiment. Multiple devices (105, 106) can be connected, for example, by a bus. such as. but not limited to, a controller area network (CAN) bus 120.

|0006j The system 100 can comprise: at least one master device 106 comprising at least one master processor 130 and at least one master driver 1 10; at least one slave device 105 comprising at least one slave processor 135 and at least one slave driver 1 1 5; and at least one controller area network (CAN) bus 120 facilitating communication between the at least one master device 106 and the at least one slave device 105. The CAN bus 120 can be a vehicle bus standard (hat can allow drivers (and thus devices) to communicate with each other and with at least one host computer 1 25 in a limited area without each driver needing to communicate separately with the host computer 1 25. A CAN message can be broadcast to the network so that each driver reads every message and determines whether or not the message is for it.

[0()07j As illustrated in FIGURE 1 , a master/slave configuration can be used. This configuration can allow the master driver 1 10 to tell the slave drivers 1 15 when it can transfer data to the host application 125. A slave driver 1 1 5 can make a request to the master driver 1 10, which can check to see i f it (the master driver 1 10) is currently communicating with the host application 1 25. If the master driver 1 1 0 is idle, the master driver 1 1 0 can tel l the slave driver 1 15 to go ahead and send the communication, which the master driver 1 1 0 wi ll then forward. I f the master driver 1 10 is communicating with the host computer, the master driver 1 1 0 can tell the slave driver 1 1 5 to wait until the master driver 1 10 gives the slave driver 1 15 permission to send the communication, which the master driver 1 10 will then forward.

[0008] CAN. As indicated above, CAN is a controller-area network vehicle bus standard that can allow devices 1 05 and 1 06 connected by the CAN bus 120 to communicate with each other in a limited area. Each device in the CAN bus 120 can send and receive messages. Each device (e.g., 105, 106) can comprise at least one driver (e.g., 1 10, 1 1 5) and at least one processor (e.g., 1 30, 1 35). The driver can receive messages from the bus, and then communicate the messages to the processor. In addition, the driver can receive message from the processor, and communicate them to the CAN bus 120. The processor can decide what the messages mean and can also create messages to transmit.

[0009) A message can comprise an ID (e.g., the driver ID) and data, and can be transmitted serial ly onto the CAN bus 1 20, one bit after another. This message can be sensed by all devices attached to the CAN bus 120. If the CAN bus 120 is free, any device may begin to transmit. If two or more devices begin sending messages at the same time, one message can override another using various override algorithms, which will be known to those of ordinary skill in the art. More information on the CAN bus 1 20 can be found in ISO 1 1 898- 1 (2003), which is herein incorporated by reference.

|0010] Many drivers can be configured as either master drivers 1 10 or slave drivers 1 15. I n this case, the CAN bus 120 has a special master connector. Only the driver attached to the master connector receives the signal to be the master driver 1 10. That driver can then configure itsel f as the master dri ver 1 10. Since the other drivers receive no signal, they can default to slave mode.

[001 11 Within the CAN bus 1 20, a master device 106 can communicate with any slave device 1 05 that is located within approximately 1 000 meters of the at least one master device 1 06. However, those of ordinary ski ll in the art will see that the area that can be covered can increase as the CAN technology becomes more advanced.

|0012| IVC Software. As illustrated in FIGURE 1 , the master driver 1 10 can communicate with at least one master processor 1 30, which can comprise at least one intelligent vending control ler (JVC) software 140, which can communicate with at least one host appl ication 125 on at least one host computer 1 30.

|0013| The master device 106 can facilitate communication between at least one host appl ication 1 25 and the slave device 105 such that only the master device 1 06 needs to have the IVC software 140 allowing the master device 106 as well as the slave device 105 to communicate with the host application 1 25. In this way, system 100 can be less expensive because fewer software licenses/packages are required. In addition, when the software 140 needs to be updated, fixed, or changed, only the software 140 in the master processor 1 30 needs to be updated, fixed, or otherwise changed. Because software 1 40 is not needed in the slave drivers 1 1 5, there is no need to bother with updating, fixing, or otherwise changing software in the slave drivers 1 1 5 which enables the slave drivers 1 1 5 to communicate with the host application 125, as the slave driver 1 1 5 is impacted as if its software 140 was updated, fixed or otherwise changed. This can be helpful when software changes very quickly, need to be fixed often, or is expensive. In addition, system 1 00 can have a high level of security because the software 140 is only present behind a firewall 1 30 in the master processor 1 30. and is not present at all in the slave devices 105. It should be noted that the slave devices 105 can have other software, however, and the slave devices are not required to have software 140 which communicates with the host application 125.

|0014 | FIGURE 3 sets forth details of the IVC software 140, according to one embodiment. The IVC software 140 can include, but is not limited to: at least one device unique ID database 305, at least one CAN ID database 3 10, at least one IVC engine 320, and at least one error log 3 1 5.

[«0151 Device Unique ID Database. As illustrated in FIGURE 2, the IVC software 140 can include a unique ID number database for any device connected to or part of master device 1 06 or slave device 1 05. The unique ID numbers can be, for example, serial numbers of the devices. A record can be kept of the different devices (e.g., keyboard devices, scanner devices, cash (e.g., bill, coin) validating and dispensing devices, etc.) that should be connected to or part of each master device 106 and slave device 1 05. This record can be kept at the IVC software 140 For example, a record can be kept of all devices that should be connected to the master device 1 06 and/or the slave device 105. The host application 1 25 can also keep a record of all devices that should be connected to the master devices 1 06 and/or host devices 105 as a back-up in some embodiments. (In some embodiment, this information can also be kept at the master driver 1 10 and/or the slave driver 1 1 5. and at a central maintenance and security host server.) In this way, the IVC software 140 can determine when an unauthorized device attempts to connect to the CAN bus 120. For example, if an unauthorized device (e.g., keyboard) attempts to connect to the master device 106 and/or slave devices 1 5 (e.g., in order to obtain PFN numbers from users), the IVC software 140 can be configured to shut down the master device 106 or slave device 105. In addition, in some embodiments, this information can help determine when any device or any part of device needs maintenance or replacement. For example, if the model information and dates are kept along with the serial numbers for each device (e.g., slave device 1 05, master device 1 06, as well as any devices connected to the slave device 1 05 and/or the master device 106, such as a keyboard) when the devices are older than a pre-set date, the master device 106 and/or slave device 1 05 can indicate that these devices need to be checked and/or replaced, and can communicate this information to the host application 125. (Note that in the case of a slave device 105 having connected devices that need to be replaced, the slave device 1 5 would first communicate to the master device 1 06, which would then communicate to the host application 1 25, as explained below.) In addition, i f there is a problem with a particular device (e.g., a scanner of model X that has been recalled due to problems), the system 100 can indicate where these certain devices are located without the need to check each device. (00161 CAN ID Database. The CAN ID database 31 0 can include information regarding the IDs of the various drivers connected to the CAN bus.

[ 001 V ] IVC Engine. The IVC engine 320 can receive and send messages to the host application 1 25. Details regarding the messages are discussed below with respect to FIGURE 2.

[0018| Error Database. The error database 3 1 5 can record errors. The error database can have fields for the error code, sub-code, date, time and severity level. When an error is recorded for a particular error code, any subsequent error with the same code can update the date and time for that code. Thus each error type can remain in the log until it is cleared. Additional information on example types of errors is described below with respect to FIGURE 2.

|00 I 9| FIGURE 4 illustrates another embodiment of IVC software 140, which can comprise an administration module 405, a monitoring module 410. or a reporting module 41 , or any combination thereof. The administration module 405 can maintain information regarding users and device usage information. IThe monitoring module 410 can monitor various types of information related to the devices. The reporting module 41 5 can provide various reports related to the devices.

[0020] Administration Module. FIGURE 5 illustrates details related to the administration module 405, according to an embodiment. The administration module 405 can include: parameter module 505. client module 5 10, branch module 51 5, terminal module 520. model module 525, value module 530, application module 535, alert module 540, profile module 545, user module 550, or error module 555, or any combination thereof. The parameter module 505 can manage various device parameters, such as. but not l imited to: when the device is allowed to operate (e.g., 9 AM - 6 PM), what kinds of bills and coins the device is allowed to accept and/or distribute, etc. The client module 51 0 can manage information related to cl ients (e.g., name, tax ID, phone numbers, fax numbers, etc.). The branch module 5 1 5 can manage in formation related to which client branches have devices instal led. The terminal module 520 can manage information related to the devices (e.g., which client is usi ng the device at which branch, the serial number of the device). The model module 520 can manage information related to which models of the devices are available. The value module 530 can manage information related to other entities, such as, but not limited to, a Cash in Transit company, which can pick up and drop off cash at the devices. The appl ication module 535 can manage which applications a certain device utilizes. For example, a certain device may be configured to provide an ink stain feature, where bills can be stained by ink i f the device is opened by someone without authorization. As another example, a certain device may be configured to keep track of how much cash is in the device at any gi ven lime. Many other types of applications related to the devices can be offered to the client. The alert module 540 can manage which alerts can be sent relating to the devices. For example, a certain device may keep track of how much cash is normally deposited even,' hour, and send an alert if cash is not deposited as expected. Many other types of alerts related to the devices may be offered to the client. The profile module 545 can manage various types of profiles. For example, profi le A may be set up as al lowing a user to enter cash into the device and also open the device; and profile B may be set up as al lowing a user to only enter cash into the device. The user module 550 may manage information related to various users. For example, a user's name, user ID, password, contact information, profile information, etc. may be uti lized. T hus, for example, a Cash in Transit employee's user ID and password may be stored, along with the user's profile, which indicates that this employee may open the device. T he error module 555 can manage various errors. For example, errors can be shown lo the users i f Ihey do something they should not do or that can ^' t be done on the system.

[00211 Monitoring Module. FIGURE 6 illustrates details related to the monitoring module 410, which can include: a device module 605 ; an ink stain module 610: and an accounting module 620. The device module 605 may manage information related to the device, i ncluding, but not limited to: how much money is in the device, communications with the device, the monitoring of al l alarms, and sending alarms when triggered. The ink stain module 725 may manage when the cash is stained with ink. For example, if certain conditions are met (e.g., an unauthorized user opens the device), the ink stain module 725 will cause ink to be distributed on the bills. The accounting module 620 can manage accounting information related to all of the devices, or all of a particular cl ient's devices (e.g., how much money a client has in all of the client's different ATMs and PDTs at certain points in time).

|0()22 | FIGURE 8 provides details related to the ink stain module 61 0 of FIGURE 6. The ink stain module 61 can comprise: a monitoring module 805, a reporting module 810, an open/close module 81 5; or any combination thereof. The monitoring module 805 can have various modes: normal mode 820; alarm mode 825 (e.g.. when unauthorized activity detected), and urgent mode 830 (e.g., when a device is open and/or the initialization of the ink slain process). The communications module 835 can be used to monitor the communications between a host and a device to make sure the communications are working normally (e.g., there is no electricity lost, etc.).

[0023| The ink stain reporting module 81 0 can comprise: an incident module 840: an open/close module 845; or an up time module 850; or any combination thereof. The incident module can keep a log of all information related to all incidents. The reporting open/close module 845 can keep a log of whenever the device is open and/or closed. The up time module 850 can keep a log of how long the device was on and working. For example, the customer can see that the device was up and running when it should be (e.g., between 9 AM and 6 PM, five days a week 98% of the time).

|0024| The open/close module 81 5 can comprise: a remote open module 855 and/or a deactivate system module 860. The remote open module 855 can allow someone with authority to open the device from a remote location. The system deactivation module 860 can allow someone with authority lo deactivate the device from a remote location.

[ 0025] Those of ordinary skill in the art will see that the modules can be moved around within the IVC software 140, and that alternate configurations are possible, such that some modules described herein as sub-modules of certain modules, can also be sub-modules of other modules within the IVC software 140. [0026] Reporting Module. FIGURE 7 illustrates details related to the reporting module 41 5, which can include a reporting administration module 710 and/or a reporting monitoring module 71 5. The reporting administration module 710 can manage the various reporting capabilities related to the administration of the devices. The reporting monitoring module 71 5 can manage the reporting related to any monitoring of the devices, and can include: a device monitoring module 720. an monitoring ink slain module 725, or a reporting accounting module 730, or any combination thereof. The reporting device monitoring module 720 can create reports related to various abilities to monitor the devices. The reporting ink stain monitoring module 725 can create reports related to when ink staining is triggered. The reporting accounting module 730 can create reports related to how much, money is at certain devices when.

Method for Using an Intelligent Device

|0027] FIGURE 2 illustrates a method for communicating. In 205, information is communicated between the host application 1 25 and the master driver 1 10. For example, to send the master driver 1 10 an instruction, the host application 125 can assemble a message and send it to the master driver 1 1 0 as a sequence of characters on the communications link. In one example, the command can comprise the following fields: package length, message authentication signature, driver CAN ID, command code, data length, and data elements. The package length Held can contain information on the total length in bytes for the command package. The message authentication signature field can be a byte sequence with a signature indicating that the host application 125 is allowed to access a device (e.g.. a master device 106, a slave device 1 05). The command code field can indicate which commands should be performed. The data length field and data element field can have the data and the length of the data that is to be sent from the host appl ication 125 to the master driver 1 10. and possibly to a slave driver 1 1 5.

[0028| In 2 10, information is communicated between the master driver 1 10 and the slave driver(s) 1 1 . For example, to send the host application 125 a message, the master driver 1 10 can assemble a message and send it to the host application 125 as a sequence of characters on the communications link, In one example, the command can comprise the following fields: Package length, driver ID, response code, error code, data length, and data elements. The response code Held can be a unique character code corresponding to the command to which it is a response. The error code field can be used to report errors detected during processing. The values can be numeric. A value (e.g.. 00) can indicate that no errors were found. If an error value is returned (e.g., other than 00), subsequent fields may not be included in the message back to the host application 125.

|0029| Errors can include fatal errors, non-recoverable- errors, recoverable errors, and programming errors. Fatal errors can indicate a hardware fault in the equipment, and can be logged and reported for user action to be taken (e.g.. report to supervisor, maintenance requi rements, security needs). Non-recoverable errors may not be rectified by the program and may need user intervention. Such errors can be logged and reported for user action to be taken (e.g. _; report to supervisor). Non-recoverable errors may prevent the master dri ver 1 1 0 from taking action on other types of commands. Recoverable errors may be the result of data corruption or may indicate that the master driver 1 10 cannot process a command because some other action is required first. The master driver 1 10 may attempt to recover by reissuing the command, attempting to clear the corruption, or by implementing the missing action. Programming errors can be errors caused by programming.

[0030J The bi-directional arrow on FIGURE 2 illustrates that the communicating can go in both directions, that is, irom the host application 125 to the master driver 1 10 to (he slave driver 1 1 5, and also from the slave driver 1 1 5 to the master driver 1 10 to the host application 1 25.

(0031 ] In some embodiments, the master device 106 and the slave device 1 05 can be devices. Such devices can include, but are not limited to: at least one ATM; at least one point of deposit terminal (PDT); at least one currency in out handler; at least one cash dispenser (e.g.. bil l, coin); at least one recycler (e.g.. bill recirculator); at least one sensor; at least one bi ll accepter; at least one printer; at least one scanner; at least one kiosk; at least one garage door opener; at least one cash register; at least one cash validator (e.g., bill, coin); at least one card reader; at least one card dispenser; at least one ticket dispenser (e.g.. with or without embossing); at least one keyboard (e.g.. standard keyboard, pad); at least one alarm device (e.g., fire alarm, safety alarm); at least one locking device; at least one power fi lter (e.g.. surge protection system); or at least one vending machine; or any combination thereof. Any type of computer or processor can be included in any vendor device, or can be configured to work with any vendor device.

[0032 j In some embodiments of the system 100. the master device 106 and the slave device 1 05 are simi lar devices (e.g., al l are ATMs and/or PDTs). In other embodiments, the master device 1 06 and slave device 105 are di fferent types of devices (e.g., di fferent devices within an ATM, such as a bill recirculator and cash dispenser within an ATM; an ATM and cash machine; an ATM and garage door opener (e.g., for parking lot control, a point of deposit terminal (PDT) for monitored cash collection). Examples of such systems 1 00 are set forth below.

ATM Example

[0033) I n one example, a banking entity can operate a host application 1 25, which can communicate with an ATM device. The ATM device can have a master driver 1 1 0 with software 140 to communicate with the host application 1 25. (It should be noted that throughout the examples listed here and below, in some embodiments, more than one master driver 1 1 0 may be utilized.) This master driver 1 1 0 can communicate over the CAN bus 120 with slave dri ers 1 1 in the same ATM, the slave drivers 1 1 5 including, but not limited to: a bill dispenser, a bill acceptor, a bill recycler (e.g., bill recirculator), a coin dispenser, a coin acceptor, a coin recycler, sensors, a laser printer, a bar code reader, a check reader, a card dispenser, a card reader, a central control module for ink staining, or an electronic locking systems, or any combination thereof). Thus, for example, the host application 1 25 can communicate with the 1VC software 140 such that the host appl ication 125 is able to communicate with the bill dispenser and bi l l recirculator so that the same bills that are used by one client to make a deposit or pay a bill are given out to pay another client who is withdrawing money from the ATM .

Multiple A TM Example

| 0034| in another example, a banking entity can operate a host application 125, which can communicate with one master ATM device (with a master driver 1 1 0). This master ATM device can in turn communicate over the CAN bus 120 with multiple slave devices (using slave drivers 1 1 5). When a user enters in a request for cash (e.g., bank card information, amount information, PIN information) in one of the slave ATM devices, the slave ATM device can indicate to the master ATM device that it wishes to communicate this information to the host application through the CAN bus 1 20. If the master ATM device is not already communicating with the host application 1 25, the master ATM device can indicate to the slave ATM device to forward the information, which the master ATM device can then forward to the banking entity ^' s host application 125, which can determine that the bank card information matches the PIN information, and send instructions back to the slave ATM device, by way of the master ATM device, indicating that the amount of cash requested should be distributed and a receipt should be printed.

ATM/Cash Register Example

|0035| In one example, the master device 106 could be an ATM, and the slave devices 1 05 could be other ATMs as well as cash registers. The cash registers can be configured so that when a certain pre-set amount of cash has been input into a cash register, the cash register can indicate and/or require that a certain pre-set amount of cash be moved to an ATM. For example, if there are two ATMs and nine cash registers in a grocery store, one ATM can be the master devices 106 and one ATM and all of the cash registers can be the slave devices 1 05. I t can be determined when a certain cash register has over $ 1 000 in cash. For example, when cash is received, this can be electronically designated by a clerk or automatically designated before the cash is added to the cash register. This information can either be stored or computed (e.g., added) at the slave cash register, at the master ATM, or at the grocery store's host computer. Once the $ 1000 threshold has been met, the clerk can be instructed to give the cash to someone to deposit in one of the ATMs. (Note that the clerk can also have permission to do this.) In this example, the cash registers can be very secure because they do not have more than $ 1 000 of cash at any one time. In addition, costs for running the ATMs can be reduced because the ATMs are continually replenished with cash from the cash registers. Thus, cash does not need to be delivered to the ATMs by cash in transit companies.

ATM/Garage Door Opener Example

[0036] In another example, an entity could operate a host application 125, which can communicate with one master ATM device. This master ATM device can in turn communicate over the CAN bus 120 with a slave garage door opener device. When a user enters in parking ticket information and cash or credit information in the slave garage door opener device, the slave garage door o'pener device can indicate to the master ATM device that it wishes to communicate this information to the host application through the CAN bus 1 20. If the master ATM device is not already communicating with the host appl ication 125, the master ATM device can indicate to the slave ATM device to forward the information, which the master ATM device can then forward to the entity's host application 1 25, which can determine the cost of parking from the parking ticket and confirm that the right amount of cash (or credit information) was received. The host application 125 can then send instructions back to the slave garage door opener device, by way of the master ATM device, indicating that the bar should be lifted and a receipt should be printed.

PDT Example

|0037| A PDT device can be a terminal that allows a user to make a deposit. For example, a cashier can have a PDT behind her in the store where she can make deposits of cash. In other embodiments, the PDT device can be accessible by the public, in case someone with a bank account wishes to make a deposit. In all of the above examples, a PDT device can be used instead of or in addition to the ATM device. For example, an entity could operate a host application . 125. which can communicate with one master PDT device (or in some embodiments, more than one master PDT device). This master PDT device can in turn communicate over the CAN bus 1 20 with other slave devices. When a user enters a cash deposit in the slave PDT device, the slave PDT device can indicate to the master ATM device that it wishes to communicate this information to the host application through the CAN bus 1 20 so that the host application 125 can keep precise records of al l money deposited into the PDT network. If the master PDT device is not already communicating with the host application 125, the master PDT device can indicate to the slave PDT device to forward the information, which the master PDT device can then forward to the host application 125, which can determine the amounts deposited into the different PDT devices and confirm that the right amount of cash (or credit infonnation) was received and report this information to interested entities. The host application 125 can also send instructions back to the slave PDTs by way o f the master PDT device, such as information about which users are authorized to deposit in the PDT network.

| 38| A network utilizing PDT and/or ATM devices can be used, for example, in supermarket lanes, where many cashiers col lect money. I f the money is accounted for in the network, this money can be stored in secure boxes and credited even before the Cash in Transit company picks up this money.

CONCLUS ION

[0039| Whi le various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It wil l be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the present invention. Thus, the present invention should not be limited by any of the above-described exemplary embodiments.

|0040] In addition, it should be understood that the figures described above, which highlight the functionality and advantages of the present invention, are presented for example purposes only. The architecture of the present invention is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown in the figures.

[0041 | In addition, the terms "a", "an", "the", "said ", etc. should be interpreted as "at least one", "the at least one", "said at least one", etc. throughout the application and claims. | 0042 | Further, the purpose of ^" the Abstract of the Disclosure is to enable the U .S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the appl ication. The Abstract of the Disclosure is not intended to be limiting as to the scope of the present invention in any way.

[0043) Finally, it is the applicant's intent that only claims that include the express language "means for" or "step for" be interpreted under 35 U.S.C. 1 1 2, paragraph 6. Claims that do not expressly include the phrase "means for" or "step for" are not to be interpreted under .15 U .S.C. 1 1 2, paragraph 6.