Abstract:
A system registers mobile devices for flight status updates and sends relevant updates to the wireless devices. Flight status updates are processed by the system and evaluated for their usefulness to the end-user. Updates that are above a minimum level of usefulness are sent to the mobile device. The system compensates for missing and/or invalid data in flight status updates. In addition to flight status updates, the system may evaluate and provide status updates for complete travel itineraries including, but not limited to, connecting flights, hotel availability and transportation options.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    The present invention is directed generally to communications with a wireless mobile device and, more particularly, to a system and method for sending travel information to a wireless mobile device. 
         [0003]    2. Description of the Related Art 
         [0004]    Flight data aggregation companies have developed technology that enables applications to query for flight information updates as needed. In recent years, some companies have added a “push” mode to the more common “pull” mode that responds to user queries. In the push mode, an application can register for flight change requests and receive notifications as flight information changes. However, such systems are limited in their usefulness to the end-user due to the sheer number of flight updates that can occur. Each data item associated with a flight can change at any time, including (for both departure and arrival) scheduled runway time, estimated runway time, actual runway time, scheduled gate time, estimated gate time, actual gate time, gate, terminal, and so on. Moreover, data items such as the times described above can change frequently, and can even oscillate among multiple values if the flight data aggregator receives conflicting data from multiple sources. For a traveler trying to act on flight information updates, such an overwhelming influx of data renders virtually all received data useless. Therefore, it can be appreciated that there is a significant need for a system and method that limits flight notifications to those that are actually applicable to a given user. The present invention provides this, and other advantages as will be apparent from the following detailed description and accompanying figures. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S) 
         [0005]      FIG. 1  illustrates a sample system architecture used to implement the system of the present disclosure. 
           [0006]      FIG. 2  is a functional block diagram of the flight update server illustrated in  FIG. 1 . 
           [0007]      FIG. 3  illustrates a mobile device registration process with the flight update server of  FIG. 2 . 
           [0008]      FIG. 4  illustrates a process for handling event data by the flight update server of  FIG. 2 . 
           [0009]      FIG. 5  is a flow chart illustrating the operation of the system of  FIG. 1  to measure relevance or usefulness of change data to the end-user. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0010]    As discussed above, flight data aggregation sources often provide overwhelming amounts of data that may be irrelevant to the end-user. For any given flight there are often 15-30 status updates, of which five may contain useful information for the end-user. The techniques described below register a wireless mobile device and track an itinerary. Furthermore, the large amounts of data are analyzed to determine which pieces of information are relevant or useful to the end-user. Only that relevant or useful data is sent to the end-user. As described below, other travel data sources permit the technology described herein to be applied to other modes of travel. 
         [0011]    The invention is embodied in a system  100  illustrated in the system architecture of  FIG. 1 . The system  100  takes advantage of a conventional wide-area network, such as the Internet  102 , to provide communication links with various components. 
         [0012]      FIG. 1  illustrates wireless devices  106 - 108 , which are operated by end-users. The wireless devices  106 - 108  communicate with a base station  110  via communication links  112 - 114 , respectively. The system  100  may be satisfactorily implemented on virtually any wireless communication system. That is, the system  100  may be implemented on a 2G network utilizing only SMS communication. Alternatively, the system  100  may be implemented with a 3G or 4G wireless network. Furthermore, the system  100  may be implemented in accordance with one or more communication standards. That is, the system  100  may be implemented using a GSM, CDMA, TDMA, FDMA, OFDMA, W-CDMA, CDMA2000, LTE, or other communication standard. With the present disclosure, one of ordinary skill in the art can implement the system  100  on various types of communication networks. Although  FIG. 1  illustrates only a single base station  110 , those skilled in the art will appreciate that typical wireless network comprises a large number of base stations distributed throughout a geographic region of coverage. However, for the sake of simplicity,  FIG. 1  illustrates only the base station  110 . 
         [0013]    The base station  110  is coupled a mobile network  116  by a communication link  118 . While the communication links  112 - 114  are wireless communication links, the communication link  118  between the base station  110  and the mobile network  116  may be implemented using a variety of known techniques, such as a hard wired connection, fiber optic, wireless (e.g., a microwave link), or the like. The communication link  118  may also be implemented by one or more of these conventional technologies in combination. 
         [0014]    As is known in the art, the mobile network  116  typically provides voice communications for the wireless devices  106 - 108 . In addition, the mobile network  116  may serve as an access point to the Internet  102 . In  FIG. 1 , the mobile network  116  is coupled to the Internet via a communication link  120 . The communication link  120  may be implemented by a variety of technologies, such as those described above with respect to the communication link  118 . 
         [0015]    As will be described in greater detail below, the wireless devices  106 - 108  communicate with the Internet  102  via the mobile network  116 . In addition, the wireless device  108  may communicate directly with the Internet  102  via a wireless communication link  122 . As is known by those skilled in the art, modern wireless devices (e.g., the wireless device  108 ) may be referred to as “smart phones” that have Internet access via the mobile network  116  using the conventional wireless network circuitry. However, many smart phone devices also include additional communication capability, such as Bluetooth or WiFi (i.e., IEEE 802.11) that permits communications between the Internet and the wireless communication device  108  via a “hot-spot” or other well known wireless access point (WAP). The system  100  may be implemented with wireless devices (e.g., the wireless device  108 ) that has multiple modes of communication. 
         [0016]    A data provider  124  is also coupled to the Internet  102  via a communication link  126 . The data provider  124  is intended to represent one or more servers on which flight data aggregation companies provide the flight data described herein. 
         [0017]      FIG. 1  also illustrates a flight update server  128  coupled to the Internet  102  via a communication link  130 . As will be described in greater detail below, the flight update server  128  receives flight data from the data provider  124  and analyzes it to determine its relevancy to the scheduled itinerary of a registered end-user. 
         [0018]    Those skilled in the art will appreciate that communication between various elements (e.g., the data provider  124  and the flight update server  128 ) of  FIG. 1  occurs via the Internet  102 . Although illustrated in  FIG. 1  as simple communication links (e.g., the communication links  126  and  130 ), a typical connection may include firewalls, routers, switches, and the like. For the sake of simplicity, those conventional elements are not illustrated in  FIG. 1 . 
         [0019]      FIG. 1  also illustrates a computing device, such as a personal computer (PC)  132 , which is coupled to the Internet  102  via the communication link  134 . The PC  132  may be any known form of computing device, such as a desktop computer, laptop computer, or the like. The communication link  134  may be a wired connection, such as a dial-up modem, DSL connection, cable modem, wireless connection, or the like. 
         [0020]      FIG. 2  illustrates a functional block diagram of the flight update server  128 . The flight update server  128  includes a number of conventional components whose operation is well understood. The flight update server  128  includes a central processing unit (CPU)  140  and a memory  142 . In general, the memory  142  contains data and instructions that are executed by the CPU  140 . The CPU  140  may be implemented as a conventional microprocessor, microcontroller, programmable gate array, application specific integrated circuit, or the like. The system  100  is not limited by the specific implementation of the CPU  140 . Similarly, the memory  142  may be implemented by a variety of known technologies. The memory  142  may include dynamic memory, static memory, programmable memory, or the like. A portion of the memory  142  may be integrated into a single chip with the CPU  140 . The system  100  is not limited by any specific implementation of the memory  142 . 
         [0021]      FIG. 2  also includes a network interface controller (NIC)  144 . The NIC  144  is representative of many types of network communication devices, such as an Ethernet connection, fiber optic connection, wireless interface, or the like. The various interfaces represented by the NIC  144  are well known in the art and need not be described in greater detail herein. The NIC  144  permits communication between the flight update server  128  and the Internet  102 . 
         [0022]      FIG. 2  also illustrates a data storage element  146 , such as a magnetic drive, optical drive, tape drive, or the like. A database  148  or other data storage structure is included in the flight update server  128  to store end-user registration information and flight itinerary information. The operation of the database  148  will be described in greater detail below. The database  148  may be implemented as a portion of the memory  142  or a portion of the data storage  146 . In these embodiments, the database  148  may be co-located with the flight update server  128 . Alternatively the database  148  may be remote from the flight update server  128  and coupled to the flight update server by a local area network (not shown) or a wide area network, such as the Internet  102 . Although elements of the flight update server  128  may be implemented as a distributed computing system, its functionality as described herein can be readily understood by those of ordinary skill in the art. 
         [0023]    The flight update server  128  also includes a decision engine  150 . As will be described in detail below, the decision engine  150  receives the end-user itinerary and the aggregated flight data. The decision engine  150  analyzes the data to determine its relevance or usefulness to the end-user itinerary and ultimately makes the decision whether or not to pass any updated information along to the wireless device (e.g., the wireless device  108 ). 
         [0024]    The various components in the block diagram of  FIG. 2  are coupled together by a bus system  152 . The bus system  152  may include a data bus, address bus, control bus, power bus, and the like. For the sake of simplicity, those various buses are illustrated in  FIG. 2  as the bus system  152 . 
         [0025]    Some components illustrated in the functional block diagram of  FIG. 2  may be implemented as computer instructions stored in the memory  142  and executed by the CPU  140 . For example, the database  148  and the decision engine  150  may be readily implemented as a set of instructions stored in the memory  142 . However, these components are illustrated as separate elements in the functional block diagram of  FIG. 2  because each performs a separate function. 
         [0026]    At the outset an end-user must register the wireless device (e.g., the wireless device  108 ) with the flight update server  128 . That process is illustrated in  FIG. 3 . The necessary instructions for registration and display of flight information on the wireless devices  106 - 108  may be readily implemented using an application program executing on the respective wireless devices. In one embodiment, the necessary travel update application program may be pre-loaded on the wireless device as supplied by the device manufacturer and/or service provider. Alternatively, it is well known to download application programs to the wireless devices  106 - 108 . In this embodiment, the application program may be downloaded from the mobile network  116  via the base station  110 . Alternatively, the application program may be downloaded to the wireless device (e.g., the wireless device  108 ) directly from the Internet  102  using, by way of example, the WiFi wireless communication link  122  (see  FIG. 1 ). 
         [0027]    As illustrated in the flowchart of  FIG. 3 , the mobile device  108  performs a registration operation to register the wireless device with the flight update server  128 . The device registration includes contact information, such as the telephone number of the wireless device or the e-mail address associated with the wireless device. The end-user may also specify communication preferences, such as telephone, e-mail, text messaging, or the like. The system  100  may also provide for different types of notification for different times. For example, changes to the itinerary that occur more than 24 or 48 hours prior to the trip may be sent, by way of example, using email. The email may be retrieved by the user&#39;s personal computer or via the wireless communication device (e.g., the wireless communication device  108  in  FIG. 1 ). Conversely, the system  100  may use text messaging to the wireless communication device  108  for itinerary changes that occur less than 1-2 hours prior to departure. Finally, the system  100  may use voice messaging for changes to the itinerary that occur closer to departure time. The time periods described above are merely examples to illustrate the possible modes of communication and how the different modes of communication may change as departure time approaches. The system  100  is not limited by the specific communication modality or the example time periods discussed above. In one embodiment, the system  100  may select default time periods for the various communication modes. Alternatively, the system  100  may permit user selection of time periods associated with different modes of communication. The device identification, contact preferences, and itinerary are saved by the flight update server  128  for future use. In addition, the mobile device  108  sends the end-user itinerary to the flight update server  128 . The flight information includes the flight number, airline, departure airport and time, arrival airport and time, and the like. Itinerary information may also include data related to connecting flights, car rental or transportation information, hotel reservations, and the like. 
         [0028]    The identification information and contact information may be entered manually by the user a single time and stored in the wireless device  108  in association with the travel update application program. Upon subsequent execution of the application program, the stored identification and contact information may be automatically forwarded to the flight update server  128 . Alternatively, the identification and contact information may be stored indefinitely in the flight update server  128 . In addition, the itinerary data may be manually entered into the wireless device  108  by the end-user or automatically entered by a service provider that provides itinerary data to the wireless device. This data could be provided by the travel provider, such as the airline, train line, cruise ship line, travel agency, or the like. Alternatively, the flight update server  128  may retrieve specific itinerary data from the travel provider. For example, the user could partially identify the itinerary, such as day and airline, and the flight update server  128  can retrieve the detailed information. Following the registration, the wireless device  108  may close the connection with the flight update server  128 . 
         [0029]    After receiving the information from the wireless device  108 , the flight update server  128  stores the identification information, contact preference information, and itinerary data in the data storage  146  and/or the database  148 . In an exemplary embodiment, the flight data is stored until the arrival time of the flight is twenty-four hours old. At that time, the flight data may be automatically deleted. At the user&#39;s preference, identification information and contact preference information may be stored indefinitely in the database  148  for future use. The flight update server  128  may also store time zone information for each wireless device as well as a list of flights and other travel information associated with each wireless device. 
         [0030]    In one embodiment, the system  100  can permit flight registration via a wireless communication device, as described above, or permit the initial registration via the PC  132  (see  FIG. 1 ). When using the PC  132  to perform the Initial registration, the user can include contact information, such as the telephone number for the wireless communication device (e.g., the wireless communication device  108 ), as well as an email address and other contact information, as discussed above. 
         [0031]    Once all of the necessary data is received by the flight update server  128 , the flight update server communicates with the data provider  124  to arrange for status updates. As previously discussed, the data provider  124  may operate in a push mode where data is provided only upon inquiry. In this embodiment, the flight update server  128  periodically sends a query to the data provider  124  to extract the requested data. Alternatively, if the data provider  124  operates in a push mode, the flight update server  128  can simply register with the data provider to request updated information on selected flights. In this embodiment, the data provider  124  automatically provides updated information for any flights registered with it by the flight update server  128 . 
         [0032]    As noted above, the data provider  124  represents one or more servers that provide travel information. While the example presented herein focuses on airline travel, those skilled in the art will appreciate that the principles of the system  100  can be readily applied to any common carrier in which scheduling information may be accessed by the system  100 . For example, flight information may be available from the Federal Aviation Administration (FAA) or from a number of commercial services that track airline flights and provide information. In addition, organizations such as the International Civil Aviation Organization (ICAO) have developed a tracking system known as an automated dependent surveillance-broadcast (ADS-B) system. With an ADS-B system, satellites provide commercial aircraft with precise location information. The aircraft, in turn, relay that information through other radio channels. The data available from ADS-B can provide precise tracking information as another implementation of the data provider  124 . With respect to other forms of transportation, trains, subways, municipal busses, and ferries also provide information that may be publically available and may thus be considered forms of the data provider  124 . For example, the Washington State Ferry System includes GPS tracking on all ferries and makes this information available through a website. In addition, the ferry system generates automatic messages to inform users of scheduling delays. The system  100  may extract these forms of information to provide updated ferry travel itineraries. Similarly, passenger trains are often equipped with similar tracking technology that can be accessed through the Internet  102 . Thus, passenger train information may also be a form of the data provider  124  to provide up-to-the-minute train travel information. The flight update server  128  provides examples of updates for airline travel. However, the update server  128  may be readily applicable to other modes of travel. The various sources of travel information, such as airline, ferry, train and the like, may be generically referred to herein as “travel data sources.” Thus, the system  100  is not limited to airline travel. 
         [0033]      FIG. 4  illustrates the event handling process used by the flight update server  128  when it receives information from the data provider  124 . The data provider  124  sends a flight status update to the flight update server  128  via the Internet  102 . For event processing, the flight update server  128  must first handle missing data and then compare the event to the last set of data in the flight update server  128  to determine if it is useful to the end-user. The first step of processing an update is to handle the missing data. There are a large number of different times provided for each flight arrival and departure. For example, the system  100  can provide airline departure updates, using the first time entry found in the following list to compare to previous events: 
         [0034]    1. Actual gate departure; 
         [0035]    2. Actual runway departure; 
         [0036]    3. Estimated gate departure; 
         [0037]    4. Scheduled gate departure; 
         [0038]    5. Estimated runway departure; 
         [0039]    6. Scheduled runway departure; and 
         [0040]    7. Published departure. 
         [0041]    The term “event” is defined herein as a set of data received from the data provider  124  with data for one or more flights. If the data provider  124  is responding to a query from the flight update server  128 , there may not be any changes from the previous query. However, if the data provider  124  is employed in a push implementation, each event received from the data provider would indicate that some changes have been made in the flight information. The flight update server  128  compares the newly received event from the data provider  124  with the previous event, which may be stored in the data storage  146  (see  FIG. 2 ) of the flight update server. Because many elements of the data may not be available to the data provider  124 , an event is often provided with missing data. 
         [0042]    The flight update server evaluates the received event to extract useful data and compensate for missing data. When comparing two events, the flight update server  128  finds the first available time in the list provided above to use for comparison to the prior stored event. Thus, in one example, the actual runway departure time from one event may be compared to the estimated gate departure time from a different event. The flight update server  128  can calculate delay times even though certain information may be missing from an event. In the example described above, the actual gate departure in a current event can be compared with the scheduled gate departure or estimated gate departure from a prior event to determine flight delay information. Thus, the flight update server  128  can accommodate missing information from an event. 
         [0043]    Flight status, gate changes and terminal changes can be ignored by the flight update server  128  if the data is missing. If a new event includes one or more of these data elements and the previous event did not, the new data can be marked as useful to the user. 
         [0044]    The arrival information uses a list similar to that illustrated above, but checks for the available arrival times, such as actual gate arrival, actual runway arrival, estimated gate arrival, and the like. The flight update server  128  handles missing data for flight arrivals in a manner such as that described above for departure information. 
         [0045]    Once the missing data is handled, the received update is compared with the last useful data for that flight. This is either the original published schedule data for the flight or the data from the last useful update. The updated data may be temporarily stored in the database. The flight update server  128  also determines the relevance of updated information. In one embodiment, the determination of what is relevant can be made based on information about the end user, by way of example, whether he/she is the traveler or is making an airport pickup. Any relevant updated information is forwarded to the wireless device  108 . The updated information may be sent to the wireless device  108  via the mobile network  116  or via the WiFi wireless connection  122  (see  FIG. 1 ). The flight update server  128  saves updated information and closes the connection with the data provider  124 . 
         [0046]    The flight update server  128  may also save a copy of the information sent to the end-user and designate this information as the “last event.” When a new event is received from the data provider  124 , the flight update server  128  may determine changes, as described above, and compare those changes to the last event sent to the user. Based on this comparison, the flight update server may determine whether or not to send additional flight change information to the end-user. For example, the data provider  124  often sends multiple events within a short period of time with minor changes from the prior event. In addition, other data sources, such as the FAA, send multiple messages with minor changes. For example, a flight may have been delayed 15 minutes as indicated by a previous event. This notification may have been sent to the user and is saved as the last event. One or more new events from the data provider  124  may indicate a change in the delay from 15 minutes to 17 minutes. However, this is a relatively minor change. Thus, the flight update server  128  will compare the 17 minute delay notification from the current event with the last event that informed the end-user of a 15 minute delay. Based on this minor additional delay, the flight update server  128  will ignore the new event indicating the additional 2 minute delay. 
         [0047]      FIG. 5  illustrates the processing by the decision engine  150  (see  FIG. 2 ) to determine the relevance of new data. As previously discussed, the system  100  analyzes received update information to determine its relevance or usefulness to the end-user and only transmits updated data that has been determined to be relevant or useful to the end-user. 
         [0048]      FIG. 5  illustrates the processing by the decision engine  150  to determine the relevance of new information. At step  160  a new status update is received from the data provider  124 . In decision  162 , the decision engine determines whether the update is a scheduled reminder. The end-user may optionally request a scheduled reminder to be sent at a predetermined time prior to the start of travel. In the example of airline travel, the scheduled reminder could be sent, by way of example, 2 hours prior to departure. If delays occur, the flight update server  128  can automatically reschedule the reminders based on the actual expected departure time. If the update is a scheduled reminder, the result of decision  162  is YES and, in that case, the update is marked as useful. In step  164  if the new status update is not a scheduled reminder, the result of decision  162  is NO and, in step  166 , the decision engine  150  determines whether the status update is a status change. There is a long list of status changes that may be sent to the flight update server  128  by the data provider  124 . Some status changes are useful only to airport personnel. For example, notifications about arrival time changes for a flight that is already marked “landed” may be useful for improving airport operations, but not for traveling. For the system  100 , if the status in an event from the data provider  124  is a departed status, landed status, canceled status, redirected status, or diverted status, the flight update server  128  will send a notification to the end-user. In step  166 , the decision engine  150  determines whether the status of the flight has changed from the previous data. If the status update is indicative of a status change, the result of decision  166  is YES and, in step  164 , the decision engine marks the status update as useful. If the status update is not indicative of a status change, the result of decision  166  is NO and, the decision engine moves to decision  168 . 
         [0049]    In decision  168 , the decision engine  150  determines whether the status update is indicative of a gate or terminal change. If so, the result of decision  168  is YES and, in step  164 , the decision engine  150  marks the status change as useful. If the status update is not indicative of a gate or terminal change, the result of decision  168  is NO and, in step  170 , the decision engine determines whether the status update is indicative of a large time change. In one embodiment, the time change may be considered a large time change if it is at least ten minutes different from the previous event. That is, either the arrival time or the departure time is at least ten minutes different from the previous event. In an alternative embodiment, the decision engine  150  may evaluate the overall itinerary to determine whether the time change is significant. For example, a ten minute time change may be significant if the end-user has a layover of, for example, one hour. However, if the end-user has a layover of four hours, by way of example, a ten-minute change in arrival time or departure time may not be considered relevant to the overall itinerary. If the time change is considered a large time change, the result of decision  170  is YES and, in step  164 , the decision engine  150  marks the status update as useful. If the time change is not considered a large time change, the result of decision  170  is NO and, in step  172 , the decision engine ends the analysis by ignoring the updated status information. 
         [0050]    Also illustrated in  FIG. 5 , status change, gate/terminal change and time change information resulting from the analysis of decisions  168 - 170  are also stored in the database  124  or the data storage  146  (see  FIG. 2 ). As previously discussed, this change information considered useful will be sent to the end-user and stored in the data structure  146  or the database  124  as the last event. 
         [0051]    Those skilled in the art will appreciate the change thresholds may be important as there are many updates to flight data that are provided by travel data sources that change the time by only a few minutes and that are not useful to the end-user. In addition, changes may happen rapidly. There are occasions where time updates are changed five or more times within one minute. 
         [0052]    If the update is marked as useful (step  164 ) by the decision engine  150 , the flight update server  128  will notify all users registered for that flight and send a message to each of them with the updated data. In addition, the current update is saved to the database  124  as the last event for comparison with the next update received by the flight update server  128 . As previously noted, updates may be sent to the wireless devices  106 - 108  using the contact information and preferences provided by the user during the registration process. The updates may be provided to the wireless devices  106 - 108  via the mobile network  116  (see  FIG. 1 ) or directly from the Internet  102  via the WiFi wireless connection  122 . 
         [0053]    The foregoing description utilizes examples from the perspective of the traveler. However, those skilled in the art will appreciate that the system  100  may be readily utilized by a third party to track an itinerary. For example, the third party may be meeting the traveler at the airport and will find the system  100  useful in tracking changes in the traveler&#39;s itinerary such as arrival times and/or arrival terminal or gate. As described above, the third party can utilize a wireless device (e.g., the wireless communication device  108  of  FIG. 1 ), the PC  132  to initiate a registration with the flight update server  128 . The system  100  operates in the same manner described above and provides the same type of notifications as specified by user preference data provided during the registration. Thus, the system  100  has great utility for the traveler and any third party having a need to monitor the traveler&#39;s itinerary. 
         [0054]    In addition, the examples presented herein relate to flight travel. However, those skilled in the art will appreciate that the system  100  can be satisfactorily employed for other forms of travel, such as trains, busses, taxis, automobile rentals, and the like. For example, an auto rental agency can utilize the system to track the itinerary of a traveler and will know when the traveler will arrive at, by way of example, the airport. Similarly, a taxi company may utilize the system  100  to track the itinerary of a traveler to meet the traveler at an appointed location, such as an airport, train station or the like. In addition, the system  100  can be employed to track other travel reservations, such as hotel reservations. In this manner, a hotel could track a traveler itinerary and know when to expect the arrival of the guest traveler. Thus, the system  100  is broadly applicable to various forms of travel. 
         [0055]    The foregoing described embodiments depict different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can also be viewed as being “operably connected”, or “operably coupled”, to each other to achieve the desired functionality. 
         [0056]    While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to inventions containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations). 
         [0057]    Accordingly, the invention is not limited except as by the appended claims.