Abstract:
A software sign on sequence is provided that allows devices to negotiate how they will communicate, what data will be exchanged and how they will mechanically operate, when they are connected to each other. This avoids the necessity of supplying new software programs to each device which is time consuming and expensive.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention relates generally to the field of the exchange of media items, media item data, and processing instructions from one device to another, and more particularly to the exchange of configurable mechanical configuration and protocol information between two devices. 
       BACKGROUND OF THE INVENTION 
       [0002]    In media handling equipment, it is often desirable to interface the output of one media processing device to the input of a second mechanical device to create integrated single step media processing solutions. Invariably, the interface of these mechanisms requires not only the exchange of physical media, but the also the exchange of media meta data that includes, among other things, media attributes, customer data, and processing instructions. 
         [0003]    The term “protocol” is used in information technology to represents an agreed upon format for transmitting data between two devices. The protocol determines the following: the type of error checking to be used; the data compression method, if any; how the sending device will indicate that it has finished sending a message; and how the receiving device will indicate that it has received a message. Protocols exist at several levels in a connection. For example, there are protocols for the data interchange at the hardware device level and protocols for data interchange at the application program level. Often there are one or more protocols at each exchange of information between devices. 
         [0004]    At the application level, it becomes necessary to develop a communications protocol that could support the exchange of data between a first device and a second device that are components of a system, while the devices and system are under development. Typically, this would be done by determining the requirements of the finished system, designing a protocol that allows for this exchange of data, and creating a specification that defines the application level interface that meets the needs of the system. Often, placeholders are put into the specification to support features which may not be implemented for the original launch of the product, but are known to be desirable for future enhanced releases. This is done to minimize, or possibly, eliminate the need for changes to the protocol in these future releases. 
         [0005]    The problem becomes still further complicated when the interface extends beyond either software and hardware messaging, and incorporates mechanical connections between devices. In these cases, even adopting placeholders in the specification does not provide sufficient means to connect devices, as suitable connection of the mechanical devices cannot be established. 
         [0006]    One problem with the foregoing is that it is usually impossible to accurately identify all changes and enhancements that will be needed for future versions of the protocol at the time of the original implementation. The associated changes that are made at a later time then create incompatibilities between systems that were sold during the initial launch phase, and the newer systems containing the enhancements. Such incompatibilities are undesirable since they result in service calls to replace/update systems in the field and make inventory management more difficult. 
         [0007]    A additional problem is that it is difficult to envision a fully adaptable mechanical interface point between two systems that can be configured to all ranges of critical mechanical parameter variations. 
         [0008]    A further problem of the prior art is the ability for enhancements and changes to be made to the communications protocol without creating any incompatibilities. 
         [0009]    Another problem of the prior art is that in the design portion of a project communications protocols were often designed to meet the immediate launch requirements of the project with little focus on the ease of maintaining backward compatibility when improvements are implemented at a later time. This results in either incompatibilities between different devices that comprise the system or large amounts of effort in subsequent software releases to avoid these incompatibilities. 
       SUMMARY OF THE INVENTION 
       [0010]    This invention overcomes the disadvantages of the prior art by providing a software sign on sequence that allows the devices to negotiate how they will communicate, what data will be exchanged and how they will mechanically operate, when they are connected to each other. This avoids the necessity of supplying new software programs to each device which is time consuming and expensive. 
         [0011]    It avoids the development of mechanical interface hardware which is equally time consuming and expensive. 
         [0012]    The invention also includes a mechanical interface device, capable of accepting media items from the first device having a critical set of mechanical parameters, i.e., velocity, length and a motion profile and modifying these parameters to values acceptable to the second device. The mechanical interface device can facilitate the synchronization of critical timing between the two devices. The mechanical interface device can also provide additional processing functionality including diverting pieces from the main process flow, scanning to confirm collation integrity and measuring or identifying unknown properties of the media item such as, length, width or weight. Thus, the mechanical device may operate over a wide range of configurable parameters to accept media from device A and provide this media to device B. 
         [0013]    The foregoing may be accomplished by providing a detailed sequence of “sign-on” messages whereby both the system and the external device that is connected to the system identify their capabilities and requirements to each other. During the course of this sign-on sequence, the devices select a mutually understandable variation of the protocol that supports the largest number of optional features. 
         [0014]    Optional features may include collation data such as postage amounts, collation weight, class of service, any special services as well as collation processing instructions such as divert, seal or select feed for additional mail piece contents. 
         [0015]    Additional optional data may include display screen information or supporting operating modes of the connected systems. It would be obvious to one skilled in the art that additional data may be exchanged such as dimensions of the collation input speed of the collation, information regarding the mail piece. 
         [0016]    Using this flexible protocol, both the system and external devices software may be programmed to remain backward compatible with earlier versions of the other device. However there is no requirement that they do so. 
         [0017]    An advantage of this invention is that additional devices connected to the system may be made by different vendors and can be more easily integrated with the system. 
         [0018]    A further advantage of this invention is that fewer incompatibilities are created between the system and the attached external device as upgraded software becomes available for the device and/or the system. 
         [0019]    A still further advantage of this invention is that new external devices are more easily connected to the system. In many cases, an external device can be connected with existing systems without the need for new software or the development of mechanical hardware. 
         [0020]    An additional advantage of this invention is that compatibility can be determined simply by attempting to connect an external device to a system. There is no detriment to attempting to connect a non-compatible device. 
         [0021]    A further advantage of this invention is that the external device or the system can be easily made to remain backward compatible with older versions of the system and device. 
         [0022]    An additional advantage of the invention is that the protocol&#39;s sign-on concept is easily extensible to other products. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
         [0023]      FIG. 1  is a schematic block diagram of the major mechanical devices in the system and their interconnection; 
           [0024]      FIG. 2  is a block diagram illustrating the major software devices in the system and their relationship to devices  50 ,  60  and  70  of  FIG. 1 ; 
           [0025]      FIG. 3  is a detailed schematic view of an example of a mechanical interface device; 
           [0026]      FIG. 4  is a flow chart illustrating the sign on process of the devices shown in  FIGS. 1 and 2 ; 
           [0027]      FIG. 5  is an example of the compatibility that may be achieved by the devices shown in  FIGS. 1 and 2 ; and 
           [0028]      FIGS. 6A-6C  describe the messages and message parameters of example protocols  1 ,  2  and  3 ; 
           [0029]      FIG. 7A  is a sequence diagram showing an example of the usage of the message contained in rows  420 - 427  of table  400 ; 
           [0030]      FIG. 7B  is a sequence diagram showing an example of the run sequence that would be used if microcontroller  100  and microcontroller  101  had connected using the sign on sequence of  FIG. 7A ; 
           [0031]      FIG. 7C  is a sequence diagram showing an example the messages contained in table  402  that would be used if microcontroller  100  and microcontroller  101  supports protocol versions  1 ,  2  and  3 ; and 
           [0032]      FIG. 7D  is a sequence diagram showing an example of the run sequence that would be used if microcontroller  100  and microcontroller  101  had connected using the sign on sequence of  FIG. 7C . 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
       [0033]    Turning now to the drawings and more particularly to  FIG. 1 , which is a schematic block diagram of the major mechanical devices in this invention and their interconnection. Source device  50  and receiving device  70  interface with interface device  60 . Device  50  may be for example a printer, sheet feeder, sheet cutter, accumulator, or any combination of the foregoing. Device  70  may be for example an accumulator, document inserter, folder, taber, or any combination thereof. Device  50  processes physical components of mail pieces, i.e., items  51  including sheets, sets of sheets, inserts, booklets and other mail piece contents. Device  50  transports and operates on the foregoing items  51  by transporting items  51  at specified velocities, for instance, the velocity of items  51  at the output of device  50  is V 1  and the input velocity of items  51  to device  70  is V 2  , where V 1  may be equal to, greater that or less than V 2 . 
         [0034]    One of the tasks of interface device  60  is to recognize or be informed of the velocity of its input items and similarly recognize or be informed of the velocity of items  51  received by device  70  and coordinate the necessary adaptation of the items  51  velocity such that the constraints of devices  50  and  70  are satisfied. Item  51  has a length L 1  a width W 1  and a height H 1 . Device  70  may require knowledge of L 1 , W 1  and H 1  to perform correct operation on items  51 . Interface  60  can negotiate the transfer of acquisition information from device  50  to device  70  to facilitate the transfer of items  51 . 
         [0035]    Device  60  can also store and cue one or more items  51  received from device  50  and at the request of device  70  provide items  51  at an appropriate time and velocity. Device  60  may also be instructed by device  50  to remove an item  51  from the mail path so that item  51  is not transported to device  70 . To accomplish the removal of items  51  divert gate  62  may be rotated such that item  51  is diverted into divert bin  61  as it is transported from device  50  to device  60 . Alternatively device  70  may remove item  51  from the processing path by advancing item  51  into accumulator  71  such that the trailing edge of item  51  clears gate  72 . Accumulator  71  may then reverse direction driving item  51  through divert path  73  into divert bin  63 . 
         [0036]      FIG. 2  is a block diagram illustrating the major software devices in the system and their relationship to devices  50 ,  60  and  70  of  FIG. 1 . Source device microcontroller  100  contains control software (which is well known in the art) to control source device  50 , and receiving device microcontroller  101  contains control software (which is well known in the art) to control receiving device  70  and interface  60 . Microcontroller  100  also implements communication protocol  110  and microcontroller  101  implements communication protocol  110 . The sign on process of protocol  110  is described in the description of  FIG. 4 , the protocol compatibility is shown in  FIG. 5 , examples of version differences between protocols is shown in  FIG. 6  and examples of message sequences for two versions of the communications protocols are shown in  FIGS. 7A-7D . The communications link  103  supplies a path for messages to be exchanged between microcontrollers  100  and  101 . Link  103  may be any communications path known in the art either hard wired or on an electromagnetic frequency. The physical link between device  50  and device  70  is interface device  60 . Items  51  ( FIG. 1 ) are physically transferred from device  50  to device  70  through interface device  60 . Interface device  60  is more fully described in the description of  FIG. 3 . 
         [0037]      FIG. 3  is a detailed schematic view of mechanical interface device  60 . Device  60  consists of media transport mechanism  120 . Mechanism  120  is comprised of a series of roller pairs  121  and  122  that form transport nips for items  51  and sheet metal guides  123  and  124  that form a contained paper path for items  51 . Roller pairs  121  and  122  are driven by a pair of DC motors  125  and  126  which drive the roller pairs  121  and  122  in two contiguous drive segments  130  and  131 . The partnering of roller pairs  121  and  122  into drive segments  130  and  131  provides a means to verify the transport velocity of item  51  as it is transported from device  50  to device  70 . The use of drive segments  130  and  131  avoids the need to introduce large physical gaps between items  51 . Divert bins  61  and  63  are used to hold items  51  that have been removed from the processing stream. Device  60  is equipped with sensors that sense the presence of items  51  in bins  61  and  63  and sensors that sense a full condition of bins  61  and  63 . Drive zone  131  extends from device  60  into device  70  thus, forming a contiguous drive region spanning devices  60  and  70 . 
         [0038]      FIG. 4  is a flow chart illustrating the sign on process of the devices shown in  FIGS. 1 and 2 . The process starts at step  500 . Then in step  501  microcontroller  101  requests microcontroller  100  identifier information and specific device data for the microcontroller  100  being connected to microcontroller  101 . Then in step  502  microcontroller  100  sends the requested information to microcontroller  101 . Now in step  503  microcontroller  101  saves microcontroller  100  information in its memory. Next in step  504  microcontroller  101  requests protocol version support from microcontroller  100 , i.e., what protocols are you capable of using. Then in step  505  microcontroller  100  sends all versions of protocols it is capable of using to microcontroller  101 . At this point the process goes to decision step  506 . Decision step  506  determines whether or not there is at least one compatible version of the protocol. If step  506  determines that there is not one compatible version of the protocol, the next step is step  510 . Step  510  concludes that microcontroller  100  and microcontroller  101  are not compatible and the connection fails. If step  506  determines that there is one compatible version of the protocol, the next step is step  515 . 
         [0039]    In step  515  microcontroller  101  compares a list of protocol versions supported by microcontroller  100  to its own internal list of supported versions and selects the matched version with the most functionality. Then in step  516  microcontroller  101  sends the protocol version with the most functionality to microcontroller  100 . Next in step  517  microcontroller  100  confirms the protocol version selection. Now in step  518  microcontroller  101  requests session configuration information from microcontroller  100 , e.g. microcontroller  100  indicates if it can measure paper, if it can support the transfer of postal data, i.e., rate, class and postage amount, is it capable of using diverse bin status information, etc. Then in step  519  device  50  provides session configuration information to microcontroller  101 . 
         [0040]    At this point the process goes to step  525 . Decision step  525  determines whether or not all configuration options required by microcontroller  100  are supported by microcontroller  101 . If step  525  determines that the configuration options required by microcontroller  100  are not supported by microcontroller  101  the next step is step  530 . In step  530  microcontroller  101  indicates the protocol version is not usable. The next step is step  531 . Step  531  determines whether or not there is at least one other compatible protocol version supported by microcontroller  100  and microcontroller  101 . If step  531  determines that there is not one other compatible protocol version supported by microcontroller  100  and microcontroller  101 , the next step is step  510 , which indicates the devices are not compatible and the connection fails. If step  531  determines that there is one other compatible protocol version supported by microcontroller  100  and microcontroller  101 , the next step is step  515 . If step  525  determines that the configuration options required by microcontroller  100  are supported by microcontroller  101  the next step is step  535 . 
         [0041]    Step  535  determines whether or not all the configuration options required by microcontroller  101  is supported by microcontroller  100 . If step  535  determines that all the configuration options required by microcontroller  101  are not supported by microcontroller  100 , the next step is step  530 . If step  535  determines that all the configuration options required by microcontroller  101  are supported by microcontroller  100 , the next step is step  536 . In step  536  microcontroller  101  selects the configuration options with the most functionality and sends the session configuration to microcontroller  100 . Next in step  537  microcontroller  100  confirms the selection to microcontroller  101 . Now step  538  indicates the connection is successful. 
         [0042]      FIG. 5  is an example of the protocol compatibility that may be achieved by the devices shown in  FIGS. 1 and 2 . The protocol compatibility establishes the data that may be exchanged between micro controller  100  and microcontroller  101 . The data includes mechanical parameters that will set devices  50 ,  60  and  70  as well as other data that is not related to the mechanical parameters of devices  50 ,  60  and  70 . Microcontroller  100   a  supports protocol version  1  and device microcontroller  100   b  supports protocol version  2 . Microcontroller  100   c  supports protocol versions  1  and  2  and device microcontroller  100   d  supports protocol version  3 . Microcontroller  100   e  supports protocol versions  2  and  3 . Microcontroller  101   a  supports protocol version  1  and microcontroller  101   b  supports protocol version  2 . Microcontroller  101   c  supports protocol versions  1  and  2  and microcontroller  101   d  supports protocol versions  1 ,  2  and  3 . In this example protocol version  3  has more functionality that protocol version  2  and protocol version  2  has more functionality than protocol version  1 . 
         [0043]    Line  75  indicates that microcontroller  100   a  may be connected to microcontroller  101  a using protocol version  1  and line  76  indicates that microcontroller  100   c  may be connected to microcontroller  101   a  using protocol version  1 . Line  88  indicates that microcontroller  100   a  may be connected to microcontroller  101   d  using protocol version  1 . Line  77  indicates that microcontroller  100   a  may be connected to microcontroller  101   c  using protocol version  2  and line  78  indicates that microcontroller  100   b  may be connected to microcontroller  101   b  using protocol version  2 . Line  79  indicates that microcontroller  100   b  may be connected microcontroller  101   b.  Microcontroller  100   b  may be connected to microcontroller  101   d  using protocol version  2 . Line  81  indicates that device microcontroller  100   c  may be connected to microcontroller  101   b  using protocol version  2  and line  82  indicates that device microcontroller  100   c  may be connected to microcontroller  101   c  using protocol version  2 . Line  83  indicates that microcontroller  100   c  may be connected to microcontroller  101   d  using protocol version  2  and line  84  indicates that microcontroller  100   e  may be connected to microcontroller  101   b  using protocol version  2 . Line  85  indicates that microcontroller  100   e  may be connected to microcontroller  101   c  using protocol version  2 . Line  86  indicates that microcontroller  100  may be connected to microcontroller  101   d  using protocol version  3  and line  87  indicates that microcontroller  100   e  may be connected to microcontroller  101   d  using protocol version  3 . 
         [0044]      FIG. 6  describes the messages and message parameters of example protocols  1 ,  2  and  3 . Protocol version  1  is shown in table  400  and protocol version  2  is shown in table  401 . Protocol version  3  is shown in table  402 . Tables  400 ,  401  and  402  have columns  410 ,  411  and  412 . The message names are contained in column  410  and the direction of message travel are contained in column  411 . The expression “SDM′” represents source device microcontroller  100  ( FIG. 2 ) and the expression “RDM′” represents receiving device microcontroller  101 . The names of message parameters when required are contained in column  412 . 
         [0045]    Tables  400 ,  401  and  402  are similar. In table  400 , row  420  indicates that a message entitled “protocol support information request may be transferred from microcontroller  101  to microcontroller  100 . The above message is used to request the list of protocols versions supported by microcontroller  100 . There are no message parameters required in row  420 . Row  421  indicates that a message entitled “protocol support information response may be transferred from microcontroller  100  to microcontroller  101 . The above message is used by microcontroller  100  to provide a list of protocol versions it supports to microcontroller  101  when requested. Row  422  indicates that a message entitled “protocol select request” may be transferred from microcontroller  101  to microcontroller  100 . The above message is used to select protocol versions that will be used for the remainder of the connection. Row  423  indicates that a message entitled “protocol select response may be transferred from microcontroller  100  to microcontroller  101 . The above message is used to confirm the successful selection of the protocol version specified when the message parameter in row  422  was received. The message indicated in rows  420 ,  421 ,  422  and  423  would be included in any protocol versions. Row  424  indicates that a message entitled “session configuration information request” may be transferred from microcontroller  101  to microcontroller  100 . The above message is used to request session configuration information. Row  425  indicates that a message entitled “session configuration information response” may be transferred from microcontroller  100  to microcontroller  101 . The above message is used by microcontroller  100  to indicate which of the configurable session options controller  100  supports. The session configuration selected determines the feature set that will be available in the integrated system. The feature set may include features related to the electromechanical operation of the system, for example automatic selection of divert bins, the automatic measurement of material in the source device, or the ability to vary the transfer velocity of item  51  for each item being fed instead of requiring that the velocity be constant for the entire mail run. The feature set may also include features related to the user interface of the integrated system, for example the ability to start and stop the integrated system from a control panel connected to either device  50  or device  70 , or for example the ability to display error messages detected by device  70  on a control panel connected to device  50 . The feature set may also include data that is associated with each item  51  being fed, such as the postage amount, the rating class, or the weight. The feature set may also include features that are not obvious to the end user of the integrated system, but that offer an advantage in implementing the software in either microcontroller  100  or microcontroller  101 , for example the ability to store data required by microcontroller  100  in memory belonging to microcontroller  101 . 
         [0046]    Row  426  of table  400  indicates that a message entitled “session connect request” may be transferred from microcontroller  101  to microcontroller  100 . The above message is used to choose a session configuration. Row  427  indicates that a message entitled “session connect response” may be transferred from microcontroller  100  to microcontroller  101 . The above message is used to confirm the successful selection configuration options. Row  428  indicates that a message entitled “start” may be transferred from microcontroller  101  to microcontroller  100 . The above message is used to start the generation of items  51  ( FIG. 3 ). Row  429  indicates that a message entitled “items ready” may be transferred from microcontroller  100  to microcontroller  101 . The above message is used every time source device  50  ( FIG. 2 ) has an item  51  available for delivery to interface device  60 . The message parameters are as follows: the number of pages in item  51 , divert location (bin  1 /bin  2 ), no divert location, and the paper length of item  51 . Row  430  indicates that a message entitled “release items” may be transferred from microcontroller  101  to microcontroller  100 . The above message is used when item  51  should be released from device  50  to interface device  60 . Row  431  indicates that a message entitled “items released” may be transferred from microcontroller  100  to microcontroller  101 . The above message is used when device  50  releases item  51  to interface device  60 . 
         [0047]    Only those rows in tables  401  and  402  that differ from the above rows in table  400  will be described. Row  445  indicates that a message entitled “session configuration information response” may be transferred from microcontroller  100  to microcontroller  101 . The above message is used by microcontroller  100  to indicate which of the configurable session options microcontroller  100  supports. The aforementioned message differs from the message in row  425  of table  400  by having an additional parameter named “postal data transfer supported”. The above parameter is used by microcontroller  100  to indicate if it is capable of providing the rate, class and postage amount associated with item  51 . Row  446  indicates that a message entitled “session connect request” may be transferred from microcontroller  101  to microcontroller  100 . This message is used to choose a session configuration. The aforementioned message differs from the message in row  426  of table  400  in that it adds the used postal data transfer parameter which microcontroller  101  may decide whether or not it wants to use the rate, class and postage amount associated with item  51 . 
         [0048]    Row  449  indicates that a message entitled “item ready” may be transferred from microcontroller  100  to microcontroller  101 . The message is used every time source device  50  has an item  51  available for delivery to interface device  60 . The aforementioned message differs from the message in row  429  of table  400  in that it adds parameters for the rate, class and postage amount associated with item  51 . These additional parameters are populated with valid data by microcontroller  100  if microcontroller  101  indicates that postal data transfer should be used via the used postal data transfer parameter of the session connect message indicated in row  446  of table  400 . 
         [0049]    Row  465  of table  402  indicates that a message entitled “session connect request” may be transferred from microcontroller  101  to microcontroller  100 . The above message is used to choose a session configuration. The above message is used by microcontroller  100  to indicate which of the configurable session options microcontroller  100  supports. The aforementioned message differs from the message in row  445  of table  401  by having an additional parameter named “divert bin status reporting”. The above parameter is used by microcontroller  100  to indicate if it is capable of using bin status information that can be provided by microcontroller  101 . An additional difference is that there are three possible values for this parameter. They are as follows. The value of required is used if microcontroller  100  can not operate with out the bin status information being provided by microcontroller  100 . The value of optional is used if microcontroller  100  can provide additional functionality if bin status information is provided by microcontroller  101 . However it can also function without it. The value not supported is used if microcontroller  100  does not support handling the bin status information. Row  466  indicates that a message entitled “session connect request” may be transferred from microcontroller  101  to microcontroller  100 . This message is used to choose a session configuration. The aforementioned message differs from the message in row  446  of table  401  in that it adds the use divert bin status parameter which microcontroller  101  uses to indicate whether or not it will provide the new message “bin status update”. Row  472  indicates that a message entitled “bin status update” may be transferred from microcontroller  101  to microcontroller  100 . This message is used to report a change in status of either divert bin  1  or divert bin  2 . The parameters of row  472  are bin  1  empty, partially filled or full and bin  2  empty, partially filled or full. The aforementioned message differs from the message adds a new message to protocol version  3  that is not part of protocol version  1  or protocol version  2 . It would be obvious to one skilled in the art that additional messages and/or additional message parameters may be added to new protocol versions. 
         [0050]      FIG. 7A  is a sequence diagram showing an example of the usage of the message contained in rows  420 - 427  of table  400 . In this example where microcontroller  101  supports protocol versions  1 ,  2  and  3  and microcontroller  100  only supports protocol version  1 . Note in line  475  microcontroller  101  has determined only protocol version  1  is mutually understood by microcontroller  100  and microcontroller  101 . Thus, protocol version  1  is selected. In line  476  microcontroller  100  indicates that it does not support paper measurement and indicates the same, since it does not have a sensor capable of paper measurement. 
         [0051]      FIG. 7B  is a sequence diagram showing an example of the run sequence that would be used if microcontroller  100  and microcontroller  101  had connected using the sign on sequence of  FIG. 7A . Note in line  477  the paper length parameter is not applicable to the item ready message. This is consistent with the sensor configuration that was negotiated in  FIG. 7A . 
         [0052]      FIG. 7C  is a sequence diagram showing an example the messages contained in table  402  that would be used if microcontroller  100  and microcontroller  101  supports protocol versions  1 ,  2  and  3 . Note in line  478  microcontroller  101  has determined that protocol version  3  provides the most functionality and select protocol version  3 . In line  479  microcontroller  100  uses message parameters shown in line  480 , namely postal data transfer support and line  481  divert bin status reporting. The above message parameters are available for use and in fact are used due to the selection of protocol version  3 . In the above example microcontroller  100  indicates it can support postal data transfer and can make use of divert bin status reporting at the option of microcontroller  101 . In line  482  microcontroller  101  indicates not to use postal data transfer since it is not connected to a postal meter. Line  482  also indicates that microcontroller  101  will provide divert bin status messages because it has this capability. It would be obvious to one skilled in the art that if device  60  did not contain sensors to detect a bin full condition or partially full condition, a successful connection using protocol version  3  could still be achieved since microcontroller  100  indicated in line  481  that divert bin status reporting is optional. In such a case microcontroller  101  would have indicated it would not provide such messages in line  482 . 
         [0053]      FIG. 7D  is a sequence diagram showing an example of the run sequence that would be used if microcontroller  100  and microcontroller  101  had connected using the sign on sequence of  FIG. 7C . Note in line  483  microcontroller  101  indicates that both divert bin  1  and divert bin  2  are empty. Note that the above message is being sent in accordance with the session configuration that was negotiated in  FIG. 7C , lines  481  and  482 . In line  484  microcontroller  100  wants to divert item  51  because item  51  contains a large amount of pages. Microcontroller  100  receives bin status messages. Therefore microcontroller  100  may always select an empty bin, i.e., bin  1 . In line  485  microcontroller  101  detects that bin  1  is full and reports this fact to microcontroller  100 . As a result of the above in line  486  microcontroller  100  selects divert location bin  2 , since bin  2  is now the only empty bin. 
         [0054]    The above specification describes a new and improved method for connecting future devices to a system or enhancing the capability of existing devices that are connected to the system. It is realized that the above description may indicate to those skilled in the art additional ways in which the principles of this invention may be used without departing from the spirit. Therefore, it is intended that this invention be limited only by the scope of the appended claims.