Abstract:
A system includes a first device and a second device. The first device is configured to transmit a discover message on a first upstream channel, where the discover message includes information representing capabilities of the first device. The second device is configured to receive the discover message from the first device and determine whether to switch the first device to a second upstream channel based on the capabilities information in the discover message. The second device makes the determination before a registration of the first device. The second device transmits a message to the first device instructing the first device to switch to the second upstream channel based on a result of the determination.

Description:
RELATED APPLICATION 
       [0001]    This application claims priority under 35 U.S.C. §119 based on U.S. Provisional Application No. 60/485,713, filed Jul. 10, 2003, the entire disclosure of which is incorporated herein by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates generally to data communications and, more particularly, to data communications within cable modem systems. 
       BACKGROUND OF THE INVENTION 
       [0003]    In cable modem systems, a cable modem termination system (CMTS) at one end of a cable network typically services multiple cable modems (CMs) connected to the cable network. CMs are generally installed locally at the end user&#39;s location, and communicate with the CMTS, which may be installed at a cable company&#39;s facility. The CMTS transmits data and messages to the CMs in a “downstream” direction and receives data bursts from the CMs in an “upstream” direction. 
         [0004]    Data over Cable Service Interface Specification (DOCSIS) is a commonly used communications protocol that defines interface requirements for CMs. DOCSIS 2.0, for example, builds upon the capabilities of DOCSIS 1.0 and DOCSIS 1.1 and adds throughput in the upstream portion of the cable system. This increased upstream data capacity enables symmetrical and time-critical services, such as videoconferencing and peer-to-peer applications. When sharing a communication channel with a CMTS, the CMs may use modulation schemes in which the modems transmit data bursts to the CMTS during designated time intervals. 
         [0005]    CMTSs typically receive data though a number of physical ports and further distinguish between different frequencies or “channels” of data using a number of internal receivers. Current CMTSs typically have a fixed relationship between their internal receivers and the physical ports. 
         [0006]    Certain data communications, such as Voice over Internet Protocol (VoIP), may require data blocks to be transmitted on an upstream channel on a periodic basis, such as once in every 10 ms, 20 ms, or 30 ms time interval. The same time period may be allocated to the data communications within each time interval. It is important to use each upstream channel as fully as possible. Therefore, data blocks from different data communications may be packed together as much as possible. 
         [0007]    CM initialization requires that certain information be communicated from the CMs to the CMTS on the upstream channels. As a result, CM initialization requires a lot of bandwidth, thereby limiting the amount of data communication that can occur on the upstream channels. In the current CM initialization process, the CMTS receives the CM&#39;s capabilities (e.g., information indicating the CM&#39;s configured class of service) in a registration message that is received near the end of the CM initialization process. In some instances, the CMTS may determine, based on these capabilities, that the CM needs to be switched from its current upstream channel to another upstream channel that is better suited to handling traffic for this particular CM. In such situations, the CM may need to be rebooted to the new upstream channel. The CM then re-performs the entire CM initialization process on the new upstream channel. This can cause significant delay to the end user(s) associated with the CM. 
         [0008]    Accordingly, there is a need to improve the CM initialization process. 
       SUMMARY OF THE INVENTION 
       [0009]    Systems and methods consistent with the principles of the invention address this and other needs by providing the CM&#39;s capabilities to the CMTS early in the CM initialization process. As such, the CMTS may switch the CM from a first upstream channel to a more appropriate upstream channel before the CM performs the entire initialization process on the first upstream channel. 
         [0010]    In accordance with one implementation consistent with the principles of this invention as embodied and broadly described herein, a method for initializing a device in a cable modem network is provided. The method includes transmitting a discover message from the device to a CMTS on a first upstream channel, where the discover message includes information representing capabilities of the device; determining, at the CMTS, whether to switch the device to a second upstream channel based on the capabilities information in the discover message, where the determining occurs before a registration of the device; and transmitting a message to the device instructing the device to switch to the second upstream channel based on the determining. 
         [0011]    In another implementation consistent with the principles of the invention, a system includes a first device and a second device. The first device is configured to transmit a discover message on a first upstream channel, where the discover message includes information representing capabilities of the first device. The second device is configured to receive the discover message from the first device and determine whether to switch the first device to a second upstream channel based on the capabilities information in the discover message. The second device makes the determination before a registration of the first device. The second device transmits a message to the first device instructing the first device to switch to the second upstream channel based on the determining. 
         [0012]    In yet another implementation consistent with the principles of the invention, a method for initializing a device in a cable modem network is disclosed. The method includes receiving a discover message from the device via a first upstream channel, where the discover message includes information representing one or more capabilities of the device; determining whether to switch the device to a new upstream channel based on the one or more capabilities in the discover message; and transmitting a message to the device instructing the device to switch to the new upstream channel based on the determining. The transmitting a message to the device occurs prior to a registration of the device. 
         [0013]    In still another implementation consistent with the principles of the invention, a network device in a cable network includes an upstream communication interface, a processing device, and a downstream communication interface. The upstream communication interface is configured to receive a message from a remote device via a first upstream channel, where the message includes information representing one or more capabilities of the remote device. The processing device is configured to determine whether to switch the remote device to a new upstream channel based on the one or more capabilities included in the received message. The downstream communication interface is configured to transmit a control message to the remote device instructing the remote device to switch to the new upstream channel based on the determining. The downstream communication interface transmits the control message prior to a registration of the remote device. 
         [0014]    In a further implementation consistent with the principles of the invention, a method for initializing a device in a cable network is provided. The method includes generating a first message that includes one or more capabilities of the device; transmitting the first message to a remote device via a first upstream channel; and receiving, in response to the transmitting, a second message from the remote device, where the second message instructs the device to switch to a second upstream channel. 
         [0015]    In yet a further implementation consistent with the principles of the invention, a method for initializing a device in a cable network is provided. The method includes generating a first message that includes one or more capabilities of the device; transmitting the first message to a remote device via a first upstream channel; receiving, in response to the transmitting, a second message from the remote device, where the second message instructs the device to switch to a second upstream channel; and switching the device to the second upstream channel without rebooting the device. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings, 
           [0017]      FIG. 1  is a diagram of an exemplary system in which systems and methods consistent with the principles of the invention may be implemented; 
           [0018]      FIG. 2  is a diagram of an exemplary configuration of the CMTS of  FIG. 1  in an implementation consistent with the principles of the invention; 
           [0019]      FIG. 3  is a diagram of an exemplary configuration of the CM of  FIG. 1  in an implementation consistent with the principles of the invention; 
           [0020]      FIG. 4  illustrates a conventional CM initialization process; 
           [0021]      FIG. 5  illustrates an exemplary process for performing CM initialization according to an implementation consistent with the principles of the invention; and 
           [0022]      FIG. 6  is a diagram of an exemplary configuration of a discover message that may be transmitted by a CM in an implementation consistent with the principles of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0023]    The following detailed description of implementations consistent with the present invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and their equivalents. 
         [0024]    Systems and methods consistent with the principles of the invention optimize the CM initialization process in certain situations, such as where the CMTS determines that the initializing CM is to be switched to a different upstream channel. In an exemplary implementation, the CM provides its capabilities in a DHCP discover message, which allows the CMTS to determine the CM&#39;s capabilities early in the initialization process. 
       Exemplary System 
       [0025]      FIG. 1  is a diagram of an exemplary system  100  in which systems and methods consistent with the principles of the invention may be implemented. As illustrated, system  100  may include a CMTS  110  that connects to a CM  120  via a cable network  130 , a number of servers  140 - 160 , and a network  170 . 
         [0026]    CMTS  110  may transmit data received from server(s)  140 - 160  and/or network  170  on one or more downstream channels via cable network  130  to CM  120 . CMTS  110  may also transmit data received from CM  120  to server(s)  140 - 160  and/or network  170 . CM  120  may receive downstream transmissions from CMTS  110 , process the transmissions in a well-known manner, and pass the processed transmissions on to customer premises equipment (CPE) (not shown). The CPE may include, for example, a television, a computer, a telephone, or any other type of equipment that can receive and/or send data via cable network  130 . CM  120  may further receive data from the CPE, process the data, and transmit the data on one or more upstream channels to CMTS  110  via cable network  130 . 
         [0027]    Cable network  130  may include a coaxial or hybrid optical fiber/coaxial (HFC) cable network. CM  120  may interconnect with cable network  130  via coaxial cable/optical fiber. Servers  140 - 160  may include a dynamic host configuration protocol (DHCP) server  140 , a time of day (TOD) server  150 , and a trivial file transfer protocol (TFTP) server  160 . DHCP server  140  may provide an Internet Protocol (IP) address and any other information needed to allow CM  120  to establish IP connectivity. TOD server  150  may provide CM  120 , as well as CMTS  110 , with the current date and time. CM  120  may use this time of day information, for example, for time-stamping events. TFTP server  160  may provide CM  120  with operational configuration parameters. 
         [0028]    Network  170  can include one or more networks of any type, such as a Public Land Mobile Network (PLMN), Public Switched Telephone Network (PSTN), local area network (LAN), metropolitan area network (MAN), wide area network (WAN), the Internet, or an intranet. The PLMN may include packet-switched sub-networks, such as, for example, General Packet Radio Service (GPRS), Cellular Digital Packet Data (CDPD), and Mobile IP sub-networks. 
         [0029]    It will be appreciated that the number of components and their arrangement as illustrated in  FIG. 1  is provided for explanatory purposes only. A typical system may include more or fewer components than are illustrated in  FIG. 1  and may be connected in different ways. For example, in a typical system, hundreds or thousands of CMs may be connected to a CMTS. 
       Exemplary CMTS Configuration 
       [0030]      FIG. 2  is a diagram of an exemplary configuration of CMTS  110  of  FIG. 1  in an implementation consistent with the principles of the invention. As illustrated, CMTS  110  may include one or more processing units  205 , a memory  210 , a communication interface  215 , an upstream/downstream communication interface  220 , and a bus  225 . It will be appreciated that CMTS  110  may include other components (not shown) that aid in the reception, processing, and/or transmission of data. 
         [0031]    Processing unit(s)  205  may perform data processing functions for data transmitted/received via communication interface  215  to/from servers  140 - 160  and network  170 , and data transmitted/received via upstream/downstream communication interface  220  to/from cable network  130 . Memory  210  may include Random Access Memory (RAM) that provides temporary working storage of data and instructions for use by processing unit  205  in performing control and processing functions. Memory  210  may additionally include Read Only Memory (ROM) that provides permanent or semi-permanent storage of data and instructions for use by processing unit  205 . Memory  210  can also include large-capacity storage devices, such as a magnetic and/or optical recording medium and its corresponding drive. 
         [0032]    Communication interface  215  may include conventional circuitry well known to one skilled in the art for transmitting data to, or receiving data from, servers  140 - 160  and/or network  170 . Upstream/downstream communication interface  220  may include transceiver circuitry for transmitting data bursts on downstream channels, and receiving data bursts on upstream channels, via cable network  130 . Such transceiver circuitry may include amplifiers, filters, modulators/demodulators, interleavers, error correction circuitry, and other conventional circuitry used to convert data into radio frequency (RF) signals for transmission via cable network  130 , or to interpret data bursts received from CM  120  via cable network  130  as data symbols. 
         [0033]    Bus  225  interconnects the various components of CMTS  110  to permit the components to communicate with one another. 
       Exemplary CM Configuration 
       [0034]      FIG. 3  is a diagram of an exemplary configuration of CM  120  of  FIG. 1  in an implementation consistent with the principles of the invention. As illustrated, CM  120  may include a processing unit  305 , a memory  310 , a CPE interface  315 , an upstream transmitter  320 , a downstream receiver  325 , and a bus  330 . It will be appreciated that CM  120  may include other components (not shown) that aid in the reception, processing, and/or transmission of data. 
         [0035]    Processing unit  305  may perform data processing functions for data received via downstream receiver  325  and data transmitted via upstream transmitter  320 . Processing unit  305  may also perform data processing functions for data transmitted to and received from CPE via CPE interface  315 . Memory  310  may include a RAM that provides temporary working storage of data and instructions for use by processing unit  305  in performing control and processing functions. Memory  310  may additionally include some type of ROM that provides permanent or semi-permanent storage of data and instructions for use by processing unit  305 . Memory  310  can also include large-capacity storage devices, such as a magnetic and/or optical recording medium and its corresponding drive. 
         [0036]    CPE interface  315  may include circuitry well known to one skilled in the art for interfacing with CPE. Upstream transmitter  320  may include circuitry for transmitting on an upstream channel. For example, upstream transmitter  320  may include amplifiers, filters, modulators, interleavers, error correction circuitry, and other circuitry used to convert data into RF signals for transmission via cable network  130 . Downstream receiver  325  may include circuitry for receiving data bursts on a downstream channel. For example, downstream receiver  325  may include amplifiers, filters, demodulators and other circuitry used to interpret data bursts received from CMTS  110  as data symbols. 
         [0037]    Bus  330  interconnects the various components of CM  120  to permit the components to communicate with one another. 
       Exemplary Processing 
       [0038]    As described above, during a conventional CM initialization process under the DOCSIS protocol, a large amount of data is typically exchanged between the initializing CM and the CMTS. When a large number of CMs connect to a CMTS, this initialization process can not only be time consuming, but can also consume a large amount of valuable upstream channel bandwidth. To better understand the advantages with respect to time and upstream channel bandwidth savings, a description of a conventional CM initialization process will be described with respect to  FIG. 4 . This conventional process is described in greater detail in Data-Over-Cable Service Interface Specifications (DOCSIS) Radio Frequency Interface Specification, SP-RFIv2.0-103-021218, Cable Television Laboratories, Inc., Third Issued Release, Dec. 18, 2002, pp. 233-251, which is hereby incorporated by reference in its entirety. 
         [0039]    Processing begins with a CM performing a physical initialization operation (act  405 ). The physical initialization operation may include, for example, scanning and synchronizing to a downstream channel, obtaining a set of transmission parameters for a possible upstream channel, and performing a ranging and ranging parameter adjustment process. The physical initialization process may also include a device class identification operation in which the CM identifies itself to the CMTS for use in provisioning. 
         [0040]    Following the physical initialization operation, the CM establishes IP connectivity. To do so, the CM transmits a DHCP discover message to a DHCP server through the CMTS to obtain a network address and any other parameters needed to establish IP connectivity (act  410 ). The discover message requests that the DHCP server assign a network address to the CM. In some instances, the discover message may suggest values for the network address and a network address lease duration. 
         [0041]    The DHCP server responds to the DHCP discover message by sending a DHCP offer message to the CM (act  415 ). The DHCP offer message may include an available network address. Upon receiving the DHCP offer message, the CM transmits a DHCP request (REQ) message to the DHCP server (act  420 ). The DHCP request message may request that the DHCP server allocate the offered network address to the CM. The DHCP server acknowledges the assignment of the particular network address by transmitting a DHCP acknowledgment (ACK) message to the CM (act  425 ). The DHCP acknowledgment message may also include an address of the server (e.g., a TFTP server) to be accessed for retrieving operational configuration parameters and the name of the configuration file to be read from the server. 
         [0042]    The CM sends a time of day (TOD) request to a time of day server to obtain the current date and time (act  430 ). In response to receiving the TOD request, the time of day server transmits a time of day response to the CM that includes the current date and time (act  435 ). The CM downloads operational parameters from the TFTP server using the address and file name specified in the DHCP acknowledgment message (act  440 ). 
         [0043]    To begin transmitting data to the network, the CM performs a registration operation. The CM sends a registration (REG) request to the CMTS (act  445 ). The registration request may include the CM&#39;s capabilities, such as its configured class of service and other operational parameters from the CM&#39;s configuration file. In response to the registration request, the CMTS records the CM capabilities transmitted in the registration request and transmits a registration reply that indicates that the CM may begin forwarding traffic to the network (act  450 ). 
         [0044]    To verify receipt of the registration reply, the CM sends a registration acknowledgment message to the CMTS (act  455 ). The CM may then optionally initialize Baseline Privacy (BP) or Baseline Privacy Plus (BP+) operations, in a well-known manner, in those instances when the CM is provisioned to run Baseline Privacy (act  460 ). 
         [0045]    In some instances, the CMTS may determine, based on the CM&#39;s capabilities information in the registration request, that the CM should switch to another upstream channel (e.g., one that is better suited to handle the type of traffic coming from this CM). Assume that the CMTS determines, based on the configuration information provided in the registration request, that the CM needs to be switched to a specific upstream channel (act  465 ). For example, the configuration information may indicate that the CM handles VoIP traffic. If the upstream channel to which the CM is assigned cannot handle VoIP traffic, the CMTS may send the CM an Upstream Channel Change (UCC) message or a Dynamic Channel Change (DCC) message to notify the CM that it is to switch to a new upstream channel (e.g., one that is better suited for handling VoIP traffic) (act  470 ). 
         [0046]    In response to the UCC or DCC message, CM may have to reboot (since it has already registered with the CMTS) and processing returns to act  405  where the CM goes through the entire initialization process again on the new upstream channel. Having to reboot and go through the entire initialization process again can cause a large delay in getting the CM initialized and ready to send traffic to the network. This delay can be, for example, as long as 45 minutes, which is unacceptable to end users. 
         [0047]    To significantly reduce this delay consistent with the principles of the invention, the CM may transmit its capabilities in the DHCP discover message. When the CM is to be switched to another channel (like in the example given above), this allows the CMTS to stop the initialization process at an early stage of the process and switch the CM to a new channel. Moreover, the CM can switch to the new channel without having to reboot thereby significantly reducing the delay associated with the conventional technique described above. 
         [0048]      FIG. 5  illustrates an exemplary process for performing CM initialization in an implementation consistent with the principles of the invention. Similar to the conventional technique described with respect to  FIG. 4 , processing may begin with a CM, such as CM  120 , performing a physical initialization operation (act  505 ). The physical initialization operation may include, for example, scanning and synchronizing to a downstream channel, obtaining a set of transmission parameters for a possible upstream channel, and performing a ranging and ranging parameter adjustment process. The physical initialization process may also include a device class identification operation in which CM  120  identifies itself to a CMTS, such as CMTS  110 , for use in provisioning. 
         [0049]    Following the physical initialization operation, CM  120  may establish IP connectivity. To do so, CM  120  may generate and transmit a DHCP discover message to a DHCP server, such as DHCP server  140 , through CMTS  110  to obtain a network address and any other parameters needed to establish IP connectivity (act  510 ). The discover message requests that DHCP server  140  assign a network address to CM  120 . In some instances, the discover message may include information, such as suggested values for the network address and a network address lease duration. In an implementation consistent with the principles of the invention, CM  120  stores information representing its capabilities in the discover message transmitted to DHCP server  140 . In one implementation, the capabilities information is stored in the vendor class identifier field of the DHCP discover message. 
         [0050]      FIG. 6  is a diagram of an exemplary configuration of a discover message  600  that may be transmitted by CM  120  in an implementation consistent with the principles of the invention. As illustrated, discover message  600  may include a hardware type field  610 , a hardware length field  620 , a client hardware address field  630 , a client identifier (ID) field  640 , a vendor class identifier field  650 , and a parameter request list  660 . 
         [0051]    Hardware type field  610  may store information identifying the type of downstream receiver  325  (e.g., Ethernet) associated with CM  120 . Hardware length field  620  may store a value representing a length of the address associated with downstream receiver  325  of CM  120 . Client hardware address field  630  may store the address (e.g., a 48 bit MAC address) associated with downstream receiver  325  of CM  120 . Client identifier field  640  may store, as will be appreciated by one skilled in the art, the address information when CM  120  is in a BOUND, RENEW or REBINDING state and can respond to address resolution protocol (ARP) requests. 
         [0052]    Vendor class identifier field  650  may include a code sub-field  652 , a length sub-field  654 , and several CM capabilities sub-fields  656 . Code sub-field  652  is generally set to a value, such as 60. Length sub-field  654  stores information identifying the length (n) of vendor class identifier field  650 . CM capabilities sub-field  656  may store values that represent CM  120 &#39;s capabilities. These capabilities can include, for example, whether CM  120  requests concatenation support from CMTS  110 , the DOCSIS version of this CM  120 , whether CM  120  requests fragmentation support from CMTS  110 , whether CM  120  requests payload header suppression support from CMTS  110 , whether CM  120  supports DOCSIS 1.1-compliant Internet gateway message protocol (IGMP), whether CM  120  supports BPI or BPI+, the number of downstream security association identifiers (SAIDs) that CM  120  can support, the number of upstream service identifiers (SIDs) that CM  120  can support, the filtering support (e.g., 802.1P filtering or 802.1Q filtering) in CM  120 , the maximum number of pre-equalizer taps per modulation interval T supported by CM  120 , the number of equalizer taps supported by CM  120 , and the dynamic channel change support of CM  120 . Other CM capabilities may also be provided. For example, the capabilities may include the CM&#39;s configured class of service, such as information indicating that the CM is VoIP-capable, data supporting capable, etc. 
         [0053]    CM  120  may use parameter request list field  660  to request specific configuration parameters from DHCP server  140 . These configuration parameters may include, for example, a network address or an address lease duration. 
         [0054]    Returning to  FIG. 5 , CMTS  110  may record the CM capabilities from DHCP discover message  600  prior to routing discover message  600  to DHCP server  140  (act  515 ). DHCP server  140  may receive DHCP discover message  600  and respond by sending a DHCP offer message to CM  120  (act  520 ). The DHCP offer message may include an available network address. Upon receiving the DHCP offer message, CM  120  may transmit a DHCP request (REQ) message to DHCP server  140  (act  525 ). The DHCP request message may request that DHCP server  140  allocate the offered network address to CM  120 . DHCP server  140  may acknowledge the assignment of the particular network address by transmitting a DHCP acknowledgment (ACK) message to CM  120  (act  530 ). The DHCP acknowledgment message may also include an address of the server (e.g., a TFTP server  160 ) to be accessed for retrieving operational configuration parameters and the name of the configuration file to be read from server  160 . 
         [0055]    In an implementation consistent with the principles of the invention, CMTS  110  may determine, based on the CM&#39;s capabilities information in DHCP discover message  600 , the CM&#39;s configured class of service (e.g., that CM  120  is VoIP-capable) and whether this CM  120  should switch to another upstream channel (e.g., one that is better suited to handle the type of traffic coming from this type of CM). Similar to the exemplary situation described above with respect to  FIG. 4 , assume that CMTS  110  determines, based on the CM capabilities information provided in DHCP discover message  600 , that CM  120  should switch to a specific upstream channel (act  535 ). For example, the capabilities information may indicate that CM  120  handles VoIP traffic. If CMTS  110  determines that the upstream channel to which CM  120  is assigned cannot handle VoIP traffic, CMTS  110  may send CM  120  a UCC message or a DCC message to notify CM  120  that it is to switch to a new upstream channel (e.g., one that is better suited for handling VoIP traffic) (act  540 ). 
         [0056]    In response to the UCC or DCC message, processing may return to act  505  where CM  120  may re-perform the above acts on the new upstream channel. By redirecting CM  120  to a new channel early in the CM initialization process, the large delay associated with the conventional technique described above with respect to  FIG. 4  can be considerably reduced. Moreover, CM  120  need not reboot since the CM has not yet registered with CMTS  110 . The delay associated with the conventional CM initialization process can thereby be reduced, for example, to a few minutes, which is much more acceptable to end users. 
       CONCLUSION 
       [0057]    Systems and methods consistent with the principles of the invention optimize the CM initialization process in situations where the CMTS determines that the initializing CM is to be switched to a different upstream channel. In an exemplary implementation, the CM provides its capabilities in a DHCP discover message, which allows the CMTS to determine the CM&#39;s capabilities early in the initialization process. 
         [0058]    The foregoing description of exemplary embodiments of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while the above description focused on the DOCSIS protocol, it will be appreciated that implementations consistent with the invention may be applicable to other cable network protocols. 
         [0059]    While a series of acts has been described with regard to  FIG. 5 , the order of the acts may be varied in other implementations consistent with the present invention. Moreover, non-dependent acts may be implemented in parallel. 
         [0060]    No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. 
         [0061]    The scope of the invention is defined by the claims and their equivalents.