VEHICLE WITH GEO-FENCED RIDE CONTROL SYSTEM

Abstract

A vehicle with a Geo-Fenced Ride Control System including: one or more battery modules including one or more battery cells; one or more processors operably connected to the one or more battery cells to control vehicle performance; and a Global Positioning System (GPS) or cellular network receiver configured to determine location of the vehicle; wherein the one or more processors communicates with a remote sever to determine a plurality of available vehicle performance settings for the vehicle based on the location of the vehicle. The vehicle further includes a user input interface configured to receive user input including selection of the vehicle performance setting form the plurality of available vehicle performance settings based on the geographic location of the vehicle.

Claims

1. A two wheel vehicle comprising: one or more battery modules including one or more battery cells; one or more processors operably connected to the one or more battery cells to control two wheel vehicle performance; and a Global Positioning System (GPS) or cellular network receiver configured to determine location of the two wheel vehicle; the one or more processors configured to select a two wheel vehicle performance setting from a plurality of two wheel vehicle performance settings based on the location of the two wheel vehicle.

2. The two wheel vehicle of claim 1, wherein the plurality of two wheel vehicle performance settings correspond to US Federal Motor Vehicle Safety Standards (FMVSS) including type 1 or 2 e-Bicycle, moped, or motorcycle.

3. The two wheel vehicle of claim 1, comprising: a wireless transmitter operably connected to the one or more processors and configured to transmit data wirelessly including location of the vehicle to a remote server; a wireless receiver operably connected to the one or more processors to receive data from the remote server including vehicle performance parameters, the processor configured to select the two wheel vehicle performance setting from the plurality of two wheel vehicle performance settings based on the vehicle performance parameters.

4. The two wheel vehicle of claim 1, comprising a user input interface configured to receive user input including selection of the two wheel vehicle performance setting from the plurality of two wheel vehicle performance settings.

5. The two wheel vehicle of claim 1, comprising a user input interface configured to indicate the selected two wheel vehicle performance setting from the plurality of two wheel vehicle performance settings.

6. The two wheel vehicle of claim 1, comprising a user input interface configured to indicate a set of two wheel vehicle performance settings from the plurality of two wheel vehicle performance settings currently available for selection by the user based on the location of the two wheel vehicle, the user input interface configured to receive user input including selection of a two wheel vehicle performance setting from the set of two wheel vehicle performance settings.

7. The two wheel vehicle of claim 1, the one or more processors configured to communicate with a mobile device including a user input interface configured to indicate a set of two wheel vehicle performance settings from the plurality of two wheel vehicle performance settings currently available for selection by the user based on the location of the two wheel vehicle, the user input interface configured to receive user input including selection of a two wheel vehicle performance setting from the set of two wheel vehicle performance settings, the one or more processors configured to receiver the user input and select the two wheel vehicle performance setting from the set of two wheel vehicle performance settings based on the user input.

8. The two wheel vehicle of claim 1, wherein the one or more processors prevent a user from selecting a two wheel vehicle performance setting from the plurality of two wheel vehicle performance settings not currently available for selection by the user based on the location of the two wheel vehicle.

9. A vehicle comprising: one or more battery modules including one or more battery cells; one or more processors operably connected to the one or more battery cells to control vehicle performance; and a location information receiver configured to receive geographical location of the vehicle; the one or more processors configured to select a vehicle performance setting from a plurality of vehicle performance settings based on the geographical location of the vehicle.

10. The vehicle of claim 9, wherein the plurality of vehicle performance settings corresponds to US Federal Motor Vehicle Safety Standards (FMVSS) including type 1 or 2 e-Bicycle, moped, or vehicle.

11. The vehicle of claim 9, comprising: a wireless transmitter operably connected to the one or more processors and configured to transmit data wirelessly including location of the vehicle to a remote server; a wireless receiver operably connected to the one or more processors to receive data from the remote server including vehicle performance parameters, the processor configured to select the vehicle performance setting from the plurality of vehicle performance settings based on the vehicle performance parameters.

12. The vehicle of claim 9, comprising a user input interface configured to receive user input including selection of the vehicle performance setting from the plurality of vehicle performance settings.

13. The vehicle of claim 9, comprising a user input interface configured to indicate the selected vehicle performance setting from the plurality of vehicle performance settings.

14. The vehicle of claim 9, comprising a user input interface configured to indicate a set of vehicle performance settings from the plurality of vehicle performance settings currently available for selection by the user based on the location of the vehicle, the user input interface configured to receive user input including selection of a vehicle performance setting from the set of vehicle performance settings.

15. The vehicle of claim 9, the one or more processors configured to communicate with a mobile device including a user input interface configured to indicate a set of vehicle performance settings from the plurality of vehicle performance settings currently available for selection by the user based on the location of the vehicle, the user input interface configured to receive user input including selection of a vehicle performance setting from the set of vehicle performance settings, the one or more processors configured to receiver the user input and select the vehicle performance setting from the set of vehicle performance settings based on the user input.

16. The vehicle of claim 9, wherein the one or more processors prevent a user from selecting a vehicle performance setting from the plurality of vehicle performance settings not currently available for selection by the user based on the location of the vehicle.

17. A method of controlling a vehicle, comprising: providing a geographical location of the vehicle; and selecting a vehicle performance setting from a plurality of vehicle performance settings based on the geographical location of the vehicle.

18. The method of claim 17, comprising: the vehicle transmitting data wirelessly including location of the vehicle to a remote server; the vehicle receiving data from the remote server including vehicle performance parameters; and selecting the vehicle performance setting from the plurality of vehicle performance settings based on the vehicle performance parameters.

19. The method of claim 17, comprising: indicating to a rider of the vehicle a set of vehicle performance settings from the plurality of vehicle performance settings currently available for selection by the rider based on the location of the vehicle; and receiving user input from the rider including selection of a vehicle performance setting from the set of vehicle performance settings.

20. The method of claim 17, comprising: preventing a user from selecting a vehicle performance setting from the plurality of vehicle performance settings not currently available for selection by the user based on the location of the vehicle.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The annexed drawings, which are not necessarily to scale, show various aspects of the invention.

[0024] FIG. 1 illustrates a schematic diagram of an exemplary geo-fenced ride control system.

[0025] FIG. 2A illustrates a block diagram of an exemplary battery module.

[0026] FIG. 2B illustrates a perspective view of an exemplary battery module.

[0027] FIG. 2C illustrates a perspective view of the exemplary battery module and a plug in base.

[0028] FIG. 3 illustrates a display for an exemplary geo-fenced ride control system.

[0029] FIG. 4 illustrates a flow chart of an exemplary method for a geo-fenced ride control system.

[0030] FIG. 5 illustrates an exemplary computing environment for a geo-fenced ride control system.

DETAILED DESCRIPTION

[0031] The principles and aspects of the present disclosure have particular application to electric motorcycles and bicycles, and thus will be described below chiefly in this context. It is understood, however, that the principles and aspects of the present disclosure may be applicable for other electric vehicle applications.

[0032] FIG. 1 illustrates a schematic diagram of an exemplary battery-centric Geo-Fenced ride modes (GF) system 1. For purposes of this disclosure, Geo-Fenced means a geographical boundary between more than one location or jurisdiction. The geographical boundary can be state-line boundaries as shown on the map M. The map M refers to portions of the U.S. for illustrative purposes. However, the principles and aspects described therein are applicable to other regions, countries, continents, etc. Furthermore, the same principles may be applied to other geographical divides such as county lines, municipalities, etc. The system 1 detects geographical location of a vehicle PD-V and selects the vehicle's ride/performance setting from a plurality of performance settings based on the geographical location. That is, based on the geographical location of the vehicle, a set of rules applying to that location is determined, and those rules are applied to the performance or ride mode of the vehicle.

[0033] The invention, thus, allows for the manufacturing of one vehicle. The vehicle PD-V may determine its geographical location and based on that location, select the applicable rules governing its legal behavior. The vehicle PD-V may then automatically select a driving/ride mode based on the applicable rules. This way the rider always complies with the rules and manufacturers may produce one product that alters its own performance depending on where the vehicle PD-V is located at any specific time.

[0034] Each vehicle PD-V may be powered by a battery module 10. The GF system 1 is referred herein as battery-centric because battery modules 10 allow for the construction of the GF system 1, as described in detail below.

[0035] FIGS. 2A-2C illustrate a block diagram and profile views of an exemplary battery module 10. The battery module 10 may include one or more battery cells 12, one or more module processors 14, a battery management system (BMS) 16, a wireless transceiver 18, a power port 24, and a data port 26. The battery module may also include an enclosure 20 for at least partially housing the one or more battery cells 12, one or more module processors 14, battery management system (BMS) 16, wireless transceiver 18, power port 24, and data port 26.

[0036] The battery module 10 may include the one or more battery cells 12 electrically organized to enable delivery of targeted range of voltage and current for a duration of time against expected load scenarios. The number and capacity of the battery cells may result in various different capacities for the battery module 10. The battery cells 12 may be, for example, lithium-ion rechargeable cells, but may be other types of rechargeable cells.

[0037] The battery module 10 may include one or more module processors 14 operably connected to the one or more battery cells 12 to obtain performance information from the one or more battery cells 12. In the illustrated embodiment of FIG. 2A, the processor 14 is operably connected to the battery cells 12 via the battery management system (BMS) 16. The BMS 16 may perform oversight of the battery cells 12 including, for example, monitoring parameters (e.g., voltage, current, temperature, etc.), providing battery protection (e.g., overcurrent, short circuit, over-temperature, etc.), preventing operation outside a battery cell's ratings, estimating a battery cell's operational state, continually optimizing battery performance, reporting operational status to the processor 14, etc. The processor 14 is operably connected to the BMS 16 to obtain the performance information of the battery cells 12. Performance information in this context includes all information the BMS 16 may obtain from the battery module 10 including the battery cells 12 including, for example, voltage, current, temperature, abnormal conditions such as overcurrent, short circuit, over-temperature, battery cell's operational state, etc.

[0038] The battery module 10 may also include a wireless transceiver 18 operably connected to the processor 14 to remotely transmit data including the performance information from the battery cells 12. The wireless transceiver 18 may include a transmitter, a receiver, or both and, thus, it may exclusively transmit information, exclusively receive information, or it may transmit and receive information. The wireless transceiver 18 may be a broadband cellular network (e.g., 3G, 4G, 5G, etc.) transceiver or a transceiver employing other local area network (LAN) or wide area network (WAN) technologies. The wireless transceiver 18 may, for example, communicate in a network using Wi-Fi, Bluetooth, satellite communication, etc.

[0039] As best illustrated in FIG. 2B, the battery module 10 may also include an enclosure 20 at least partially enclosing the one or more battery cells 12, the one or more module processors 14, and the wireless transceiver 18. The enclosure 20 may have mounted to or built thereupon one or more handles 22 for a user to grab to transport the module 10. The weight, size, and form factor of the module 10 is designed with ergonomics in mind to be “human-sized.” That is, the module 10 may be designed to be transportable by a single person: of such size, shape, and weight that a single person may carry it relatively comfortably and without injury.

[0040] Regarding weight, the module may be designed to comply with maximum lifting weight regulations or guidelines such as, for example, the Revised National Institute of Occupational Safety and Health (NIOSH) Lifting Equation (2021), guidelines for evaluating two-handed manual lifting tasks.

[0041] Regarding size and form factor, the module 10 may be designed to have a generally “suit case” rectangular form factor with the handle 22 installed or built thereupon at one end of the module 10. The dimensions of the module 10 may be height in the range of 12 inches to 24 inches, width in the range of 6 inches to 12 inches, and depth in the range of 4 inches to 8 inches. In one embodiment, the module 10 may be 16 inches tall, 9.5 inches wide, and 5.5 inches deep. In some embodiments, the battery module 10 is designed with height in a range shorter than 12 inches or taller than 24 inches, width in a range narrower than 6 inches or wider than 12 inches, and depth in a range shallower than 4 inches or deeper than 8 inches.

[0042] Returning to FIG. 2A, the module 10 may include a power port 24 for connecting the battery module 10 to a powered device PD. The powered device PD may correspond to a vehicle, a home appliance, etc. as described in detail below. The power port 24 may also serve as a recharge port for the battery module 10. That is, since the battery module 10 is removable and transportable, a user may plug in the power port 24 of the battery module 10 in, for example, a vehicle's power port to power the vehicle, remove the battery module 10 from the vehicle, transport the battery module 10 to a charging station, and plug the battery module 10 to the charging station to be charged via the power port 24.

[0043] The battery module 10 may also include a data port 26 to connect the battery module 10 to a data buss of the powered device PD. For example, if the powered device PD is a vehicle, the data port 26 may be connected to a CAN bus (ISO 11898 Standard) of the vehicle. Similarly, the data port 26 may be connected to other communications systems such as, for example, wired standard (RS485, etc.) as well as wireless standard (Wi-Fi, Bluetooth, ZigBee, WiMax, etc.) communications systems. Thus, the data port 26 may be wired port, a wireless port, or combinations thereof.

[0044] As best shown in FIG. 2C, the battery module 10 may have a connector 11 to plug in to a connector 15 of a base 13. The connector 11 may incorporate the power port 24 and data port 26. The base 13 may be a stand-alone charging/power distribution port connected to a building's power distribution system. The base 13 may also be a vehicle battery dock or receiver for the vehicle PD-V.

[0045] The battery module 10 may also include a global position system (GPS) 28 receiver operably connected to the processor 14 to communicate to the processor 14 a geographical location of the battery module 10. In some embodiments, the battery module 10 may employ techniques (e.g., Bluetooth communication with GPS-equipped mobile phone CD, Wi-Fi Positioning System (WPS), etc.) instead of or in addition to the to the GPS 28 to obtain the geographical location of the battery module 10.

[0046] Returning to FIG. 1, the GF system includes a constellation of battery modules 10.

[0047] Some battery modules 10 may be connected to vehicles PD-V to power the vehicles, to serve as one-way or two-way vehicle wireless data transmission devices, and to serve as the vehicles' link to the IoT. The battery module 10 power capacity allows for powering of the electric vehicle PD-V via the power port 24. The BMS 16 of the battery module may also allow for the collection of vehicle and battery performance data. The GPS 28 may be used to obtain location data of the vehicle PD-V and whether the battery module 10 (and hence the vehicle PD-V) is stationary or moving, etc. The battery module 10 may also be connected to a vehicle data system of the electric vehicle PD-V via the data port 26. The wireless transmitter 18 of the battery module 10 may transmit the collected data via the cloud CL to be stored in a database 30.

[0048] The system 1 may also include a remote server 32 that communicates with the battery modules 10 or the database 30 including receiving the data including the performance information. That is, the battery modules 10 may use their wireless transceiver 18 to communicate the data including the performance information to the cloud CL and the server 30, also connected to the cloud CL, may receive the data including the performance information either directly from the battery modules 10 or from the database 30.

[0049] The system 1 uses the GPS 28 (or any other known technique) to determine the geographical location of the electric vehicle PD-V and uses the geographical location to select an electric vehicle performance/ride setting from a plurality of electric vehicle performance settings. The plurality of electric vehicle performance settings may correspond to the US Federal Motor Vehicle Safety Standards controlled by the Department of Transportation (FMVSS). The FMVSS safety standards may include type 1 or 2 e-Bicycle, moped, or motorcycle. Different jurisdictions may require different safety or performance standards for a vehicle to have one the four classes.

[0050] FIG. 3 illustrates a simplified view of a potential display for the system 1. The electric vehicle PD-V may include a digital display that displays a current performance/ride setting as selected by the system 1 based on the geographical location of the electric vehicle PD-V as determined by the battery module 10.

[0051] In one embodiment, the battery module 10 and specifically the processor 14 or the BMS 16 may have stored therein or in associated storage or memory a database with the various ride mode rules correlated to geographical locations. In this embodiment, the remote server 32 may maintain the ride mode database of the battery module 10 up to date (e.g., in case a jurisdiction changes its rules) by sending over the air updates to the battery module 10 via the wireless transceiver 18. A battery module 10 or specifically the processor 14 or the BMS 16 detects geographical location of the vehicle PD-V to which it is connected, looks up in the database a corresponding riding mode for the geographical location, and controls the vehicle PD-V to which it is connected to perform in the corresponding ride mode or at least communicates the information to the vehicle PD-V so it may set the proper ride mode for the geographical location.

[0052] In another embodiment, the database 30 may have stored therein or in associated storage or memory the various ride mode rules correlated to geographical locations. In this embodiment, the remote server 32 may maintain the ride mode rule information in the database 30 up to date (e.g., in case a jurisdiction changes its rules). A battery module 10 or specifically the processor 14 or the BMS 16 detects geographical location of the vehicle PD-V to which it is connected and transmits the location to the remote server 32 via the wireless transceiver 18. The remote server 32 may look up in the database 30 a corresponding riding mode for the geographical location and communicate to the battery module 10 via the wireless transceiver 18. The battery module 10 or specifically the processor 14 may control the vehicle PD-V to which it is connected to perform in the corresponding ride mode or at least communicate the information to the vehicle PD-V so it may set the proper ride mode for the geographical location.

[0053] If the newly determined ride mode is different from the currently set ride mode, the processor 14 may automatically alter the vehicle performance parameters to match the selected electric vehicle performance setting. In one embodiment, the processor 14 may delay until the electric vehicle PD-V comes to a stop to update the ride mode parameters.

[0054] For example, in FIG. 1, a rider may ride the vehicle PD-V from the state of Minnesota to the state of Wisconsin, which as of the time of this disclosure have different rules applying to LEV. Immediately prior to entering Wisconsin, the vehicle PD-V was performing in a ride mode corresponding to the state of Minnesota. The battery module 10 or specifically the processor 14 or the BMS 16 detects location of the vehicle PD-V (from the GPS 28) as Wisconsin. The battery module 10 transmits the location to the remote server 32 via the wireless transceiver 18. The remote server 32 may look up in the database 30 a corresponding riding mode for Wisconsin and communicate to the battery module 10 via the wireless transceiver 18. The battery module 10 or specifically the processor 14 may control the vehicle PD-V to which it is connected to perform in the corresponding ride mode for Wisconsin or at least communicate the information to the vehicle PD-V so it may set the proper ride mode for the new location.

[0055] For manufacturers, a vehicle PD-V may be transported anywhere after manufacturing. At the point of sale or first use, the battery module 10 or specifically the processor 14 or the BMS 16 detects location of the vehicle PD-V (from the GPS 28). The battery module 10 transmits the location to the remote server 32 via the wireless transceiver 18. The remote server 32 may look up in the database 30 a corresponding riding mode for the geographical location and communicate to the battery module 10 via the wireless transceiver 18. The battery module 10 or specifically the processor 14 may control the vehicle PD-V to which it is connected to perform in the corresponding ride mode for the location or at least communicate the information to the vehicle PD-V so it may set the proper ride mode for the location.

[0056] In some circumstances a given electric vehicle PD-V may be determined to comply with regulations corresponding to multiple ride modes and, therefore, the electric vehicle PD-V may be set to perform in multiple ride modes. In the embodiment of FIG. 3, the display may also be a user input interface configured for a user to select from available ride modes. The user input interface may indicate ride modes that are available for selection by the user based on the location of the electric vehicle PD-V. The user input interface may receive user input including the selection of the electric vehicle ride mode from the available ride modes.

[0057] The battery module 10 may be configured to communicate with a mobile device CD via, for example, the wireless transceiver 18. The mobile device CD may further include a user input interface (e.g., an app) configured to indicate a set of electric vehicle performance settings including ride modes currently available for selection by the user based on the location of the electric vehicle PD-V. The user input interface of the mobile device CD may be configured to receive user input selection of the desired electric vehicle performance settings from the set of performance settings. The user may then use the user interface of the mobile device CD to select the desired performance setting including a ride mode.

[0058] The one or more processors 14 may prevent a user from selecting an electric vehicle performance setting such as a ride mode that is not currently available for selection by the user based on the location of the electric vehicle.

[0059] These and other scenarios are possible because of the capabilities of the battery-centric Geo-Fenced (GF) Ride Control system of the present disclosure.

[0060] Exemplary methods may be better appreciated with reference to the flow diagram of FIG. 4. While for purposes of simplicity of explanation, the illustrated methodologies are shown and described as a series of blocks, it is to be appreciated that the methodologies are not limited by the order of the blocks, as some blocks can occur in different orders or concurrently with other blocks from that shown and described. Moreover, less than all the illustrated blocks may be required to implement an exemplary methodology. Furthermore, additional methodologies, alternative methodologies, or both can employ additional blocks, not illustrated.

[0061] In the flow diagrams, blocks denote “processing blocks” that may be implemented with logic. The processing blocks may represent a method step or an apparatus element for performing the method step. The flow diagrams do not depict syntax for any particular programming language, methodology, or style (e.g., procedural, object-oriented). Rather, the flow diagrams illustrate functional information one skilled in the art or artificial intelligence (AI) may employ to develop logic to perform the illustrated processing. It will be appreciated that in some examples, program elements like temporary variables, routine loops, and so on, are not shown. It will be further appreciated that electronic and software applications may involve dynamic and flexible processes so that the illustrated blocks can be performed in other sequences that are different from those shown or that blocks may be combined or separated into multiple components. It will be appreciated that the processes may be implemented using various programming approaches like machine language, procedural, object oriented or artificial intelligence or machine learning techniques.

[0062] FIG. 4 illustrates a flow diagram for an exemplary method 400 for a battery-centric Geo-Fenced Ride Control (GF) system. At 410, the method 400 includes obtaining original vehicle performance setting information. At 420, the method 400 includes obtaining vehicle location. At 430, the method 400 includes transmitting the vehicle location data wirelessly to a remote sever. At 440, the method 400 includes wirelessly receiving vehicle performance settings currently available for selection from the remote servers based on the vehicle location data. At 450, the method 400 may include comparing the vehicle performance settings currently available for selection with the currently set vehicle performance settings. If the currently set vehicle performance setting is one of the vehicle performance settings currently available for selection, then the method restarts. If the currently set vehicle performance setting is not one of the vehicle performance settings currently available for selection, then at 460 the method includes selecting a vehicle performance setting from the plurality of vehicle performance settings based on the geographical location of the vehicle.

[0063] FIG. 5 illustrates a block diagram of an exemplary computing environment 500 that may be used to deploy the battery module 10 or the remote server 32 of the present disclosure. The environment 500 includes a processor 502 (e.g., the processor 14), a memory 504, and I/O Ports 510 operably connected by a bus 508. The environment 500 may also include the database 30 or may communicate with the database 30 via the cloud CL.

[0064] The processor 502 (e.g., the processor 14) can be a variety of various processors including dual microprocessor and other multi-processor architectures. The memory 504 can include volatile memory or non-volatile memory. The non-volatile memory can include, but is not limited to, ROM, PROM, EPROM, EEPROM, and the like. Volatile memory can include, for example, RAM, synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), and direct RAM bus RAM (DRRAM).

[0065] A storage 506 may be operably connected to the environment 500 via, for example, an I/O Interfaces (e.g., card, device) 518 and an I/O Ports 510. The storage 506 can include, but is not limited to, devices like a magnetic disk drive, a solid state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash memory card, or a memory stick. Furthermore, the storage 506 can include optical drives like a CD-ROM, a CD recordable drive (CD-R drive), a CD rewriteable drive (CD-RW drive), or a digital video ROM drive (DVD ROM). The memory 504 can store processes 514 or data 516, for example. The storage 506 or memory 504 can store an operating system that controls and allocates resources of the environment 500. The database 30 may reside in the storage 506.

[0066] The bus 508 can be a single internal bus interconnect architecture or other bus or mesh architectures. While a single bus is illustrated, it is to be appreciated that environment 500 may communicate with various devices, logics, and peripherals using other busses that are not illustrated (e.g., PCIE, SATA, Infiniband, 1394, USB, Ethernet). The bus 508 can be of a variety of types including, but not limited to, a memory bus or memory controller, a peripheral bus or external bus, a crossbar switch, or a local bus. The local bus can be of varieties including, but not limited to, an industrial standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an extended ISA (EISA) bus, a peripheral component interconnect (PCI) bus, a universal serial (USB) bus, and a small computer systems interface (SCSI) bus.

[0067] The environment 500 may interact with input/output devices via I/O Interfaces 518 and I/O Ports 510. Input/output devices can include, but are not limited to, a keyboard, a microphone, a pointing and selection device, cameras, video cards, displays, storage 506, network devices 520, and the like. The I/O Ports 510 can include but are not limited to, serial ports, parallel ports, and USB ports.

[0068] The environment 500 (and the battery module 10) can operate in a network environment and thus may be connected to network devices 520 via the I/O Interfaces 518, or the I/O Ports 510. Through the network devices 520, the environment 500 may interact with a network. Through the network, the environment 500 may be logically connected to remote computers including, for example, a network computer or file server hosting the database 30. The networks with which the environment 500 may interact include, but are not limited to, a local area network (LAN), a wide area network (WAN), and other networks. The network devices 520 can connect to LAN technologies including, but not limited to, fiber distributed data interface (FDDI), copper distributed data interface (CDDI), Ethernet (IEEE 802.3), token ring (IEEE 802.5), wireless computer communication (IEEE 802.11), Bluetooth (IEEE 802.15.1), Zigbee (IEEE 802.15.4) and the like. Similarly, the network devices 520 can connect to WAN technologies including, but not limited to, point to point links, circuit switching networks like integrated services digital networks (ISDN), packet switching networks, satellite communication, and digital subscriber lines (DSL). While individual network types are described, it is to be appreciated that communications via, over, or through a network may include combinations and mixtures of communications.

DEFINITIONS

[0069] The following includes definitions of selected terms employed herein. The definitions include various examples or forms of components that fall within the scope of a term and that may be used for implementation. The examples are not intended to be limiting. Both singular and plural forms of terms may be within the definitions.

[0070] An “operable connection,” or a connection by which entities are “operably connected,” is one in which signals, physical communications, or logical communications may be sent or received. Typically, an operable connection includes a physical interface, an electrical interface, or a data interface, but it is to be noted that an operable connection may include differing combinations of these or other types of connections sufficient to allow operable control. For example, two entities can be operably connected by being able to communicate signals to each other directly or through one or more intermediate entities like a processor, operating system, a logic, software, or other entity. Logical or physical communication channels can be used to create an operable connection.

[0071] To the extent that the term “includes” or “including” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim. Furthermore, to the extent that the term “or” is employed in the detailed description or claims (e.g., A or B) it is intended to mean “A or B or both.” When the applicants intend to indicate “only A or B but not both” then the term “only A or B but not both” will be employed. Thus, use of the term “or” herein is the inclusive, and not the exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).

[0072] While example systems, methods, and so on, have been illustrated by describing examples, and while the examples have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit scope to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the systems, methods, and so on, described herein. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention is not limited to the specific details, the representative apparatus, and illustrative examples shown and described. Thus, this application is intended to embrace alterations, modifications, and variations that fall within the scope of the appended claims. Furthermore, the preceding description is not meant to limit the scope of the invention. Rather, the scope of the invention is to be determined by the appended claims and their equivalents.