U.S. patent application number 14/643196 was filed with the patent office on 2015-10-29 for shared vehicle systems and methods.
This patent application is currently assigned to Ford Global Technologies, LLC. The applicant listed for this patent is Ford Global Technologies, LLC. Invention is credited to Richard Brown, Will Farrelly.
Application Number | 20150310379 14/643196 |
Document ID | / |
Family ID | 54335112 |
Filed Date | 2015-10-29 |
United States Patent
Application |
20150310379 |
Kind Code |
A1 |
Farrelly; Will ; et
al. |
October 29, 2015 |
SHARED VEHICLE SYSTEMS AND METHODS
Abstract
A map indicating respective locations of a plurality of vehicles
included in a ride-sharing service is generated. A vehicle is
identified in the plurality of vehicles that is in need of
relocation. A user is identified in a vicinity of the identified
vehicle for an offer to use the identified vehicle. The offer is
transmitted, via a network, to the user for use of the identified
vehicle in a manner to support the relocation.
Inventors: |
Farrelly; Will; (Chelmsford,
GB) ; Brown; Richard; (London, GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Ford Global Technologies, LLC |
Dearborn |
MI |
US |
|
|
Assignee: |
Ford Global Technologies,
LLC
Dearborn
MI
|
Family ID: |
54335112 |
Appl. No.: |
14/643196 |
Filed: |
March 10, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61985010 |
Apr 28, 2014 |
|
|
|
61985004 |
Apr 28, 2014 |
|
|
|
61985005 |
Apr 28, 2014 |
|
|
|
61985009 |
Apr 28, 2014 |
|
|
|
61985011 |
Apr 28, 2014 |
|
|
|
Current U.S.
Class: |
705/7.15 |
Current CPC
Class: |
G06Q 10/20 20130101;
G08G 1/202 20130101; G01C 21/3438 20130101; G06Q 10/063114
20130101; G06Q 50/30 20130101; G01C 21/34 20130101; G06Q 30/0206
20130101; G08G 1/005 20130101; G06Q 30/0203 20130101; G08G 1/14
20130101; G06Q 30/0207 20130101; G08G 1/205 20130101 |
International
Class: |
G06Q 10/06 20060101
G06Q010/06; G06Q 10/00 20060101 G06Q010/00; G06Q 30/02 20060101
G06Q030/02 |
Claims
1. A system, comprising a computer including a processor and a
memory, the memory storing instructions executable by the processor
such that the computer is programmed to: generate a map indicating
respective locations of a plurality of vehicles included in a
ride-sharing service; identify a vehicle in the plurality of
vehicles that is in need of relocation; identify a user in a
vicinity of the identified vehicle for an offer to use the
identified vehicle; and transmit the offer, via a network, to the
user for use of the identified vehicle in a manner to support the
relocation.
2. The system of claim 1, wherein the computer is further
programmed to identify the user according to retrieved user
information including at least one of a common user destination and
a common route of travel.
3. The system of claim 1, wherein the computer is further
programmed to identify a plurality of users to receive a message
including the offer or a second offer relating to use of the
identified vehicle.
4. The system of claim 1, wherein the computer is further
programmed to identify cargo to be transported during relocation of
the identified vehicle.
5. The system of claim 1, wherein the computer is further
programmed to take at least one of fuel and maintenance
requirements into account in identifying the vehicle that is in
need of relocation.
6. The system of claim 1, wherein the computer is further
programmed to provide a survey to a second user concerning a state
of the identified vehicle following a relocation.
7. The system of claim 6, wherein the computer is further
programmed to adjust a user profile based on data from the
survey.
8. The system of claim 1, wherein the offer includes a discount in
pricing for use of the identified vehicle in exchange for user
assistance in relocating the shared vehicle.
9. The system of claim 1, further comprising a user device
including a processor and a memory, the memory storing instructions
executable by the processor such that the user device is programmed
to receive and respond to the offer via the network.
10. The system of claim 1, further comprising a user device
including a processor and a memory, the memory storing instructions
executable by the processor such that the user device is programmed
to provide a user location to the computer via the network.
11. A method, comprising: generating a map indicating respective
locations of a plurality of vehicles included in a ride-sharing
service; identifying a vehicle in the plurality of vehicles that is
in need of relocation; identifying a user in a vicinity of the
identified vehicle for an offer to use the identified vehicle; and
transmitting the offer, via a network, to the user for use of the
identified vehicle in a manner to support the relocation.
12. The method of claim 11, further comprising identifying the user
according to retrieved user information including at least one of a
common user destination and a common route of travel.
13. The method of claim 11, further comprising identifying a
plurality of users to receive a message including the offer or a
second offer relating to use of the identified vehicle.
14. The method of claim 11, further comprising identifying cargo to
be transported during relocation of the identified vehicle.
15. The method of claim 11, further comprising taking at least one
of fuel and maintenance requirements into account in identifying
the vehicle that is in need of relocation.
16. The method of claim 11, further comprising providing a survey
to a second user concerning a state of the identified vehicle
following a relocation.
17. The method of claim 16, further comprising adjusting a user
profile based on data from the survey.
18. The method of claim 11, wherein the offer includes a discount
in pricing for use of the identified vehicle in exchange for user
assistance in relocating the shared vehicle.
19. The method of claim 11, further comprising receiving and
responding to the offer via the network.
20. The method of claim 11, further comprising providing a user
location to the via the network.
Description
RELATED APPLICATIONS
[0001] This application claims priority to Provisional Application
Ser. No. 61/985,010 filed Apr. 28, 2014 entitled "Identifying
Vehicle Parking"; Provisional Application Ser. No. 61/985,004 filed
Apr. 28, 2014 entitled "Facilitating Vehicle Parking", Provisional
Application Ser. No. 61/985,005 filed Apr. 28, 2014 entitled
"Unauthorized Vehicle Detection"; Provisional Application Ser. No.
61/985,009 filed Apr. 28, 2014 entitled "Vehicle Parking
Facilitated by Public Transmit Conveyances"; and Provisional
Application Ser. No. 61/985,011 filed Apr. 28, 2014 entitled "Air
Quality Improvements from Vehicle Parking, each of which
provisional applications are hereby incorporated herein by
reference in their respective entireties.
BACKGROUND
[0002] Personal vehicles generally provide a flexible form of
transportation for commuters and passengers within urban
environments. However, owning and operating a personal vehicle can
be expensive when costs for the vehicle, fuel, insurance, and
maintenance are factored in. in addition, personal vehicles
increase congestion and pollution in urban environments. Public
transit systems, including buses, trains, subways, etc., that
operate on a fixed schedule, provide alternate lower cost options
for commuters. Shared transportation options reduce in-city
congestion and improve air quality. However, a commuter may have
limited flexibility in terms of departure and arrival times, as
well as departure and arrival locations.
[0003] Another shared transportation option that provides a good
mix of flexibility, cost, ease of use, and environmental impact is
a shared vehicle system. Therein, a fleet of vehicles are
distributed over an operating zone (e.g., a city) and a user can
rent any vehicle of the fleet for a short period (e.g., a few hours
of a day). Once a user account is set up, the user can identify a
vehicle he or she wishes to rent based on its location within the
operating zone, and rent the vehicle without requiring additional
paperwork. The user can then return the vehicle to the point of
origin or drop off the vehicle at an alternate location, per the
user's convenience. The shared vehicle system reduces the user's
commuting costs while also reducing in-city congestion and
pollution. At the same time, the ability to pick-up and drop-off a
vehicle at a time and location determined by the user increases the
user's flexibility.
[0004] Unfortunately, shared vehicles intermittently have to be
relocated to provide for rebalancing locations of vehicles in a
shared fleet. Specifically, to ensure uniform or some other desired
distribution of vehicles over an operating zone, once user rides
are completed, based on the location of the fleet vehicles, one or
more vehicle may have to be driven to a different part of the
operating zone so that they are accessible to users there. In some
cases, this may include driving a vehicle across the city. In
addition to the cost of relocating the vehicle, the fleet
management system may have to hire dedicated drivers to drive the
vehicles to the specific locations where rebalancing is achieved.
As such, this adds cost and time to fleet management.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 is a block diagram of an exemplary shared vehicle
system.
[0006] FIG. 2 is a high level representation of an implementation
of the system of FIG. 1.
[0007] FIG. 3 is a process flow diagram illustrating an exemplary
process for relocating a shared vehicle as part of providing a
shared vehicle to a user.
[0008] FIG. 4 is a process flow diagram illustrating an exemplary
process for relocating a shared vehicle including providing
transport to a user.
DESCRIPTION
[0009] In one example, rebalancing problems may be addressed by a
method that provides targeted advertisements to users based on
fleet rebalancing needs. For example, if one or more vehicles have
to be relocated from a first region to a second region of the
shared vehicle system's operating zone (e.g., due to a larger ratio
of vehicles in the first region relative to the second region), a
central server may identify users in the first region who have a
history of riding into the second region. This and other operations
disclosed herein may be provided according to instructions included
in the central server or the like that is communicatively coupled
to one or more shared vehicles, mobile devices, etc., e.g., via a
wide area network that may include cellular, WiFi, and/or other
technologies.
[0010] For example, based on user profile settings, preferences,
and well as user trip history, the server may be programmed to make
a prediction or predictions about a user's likely destination. If
the user's destination matches a region where it is desired to
relocate the vehicle, a targeted notification may be sent to the
user advertising a discounted fare for the trip. In one example, it
may be desired to relocate a vehicle to an area in the vicinity of
a user's home location. A notification may then be pushed to the
user, e.g., to a user's mobile computing device such as a
smartphone or the like, advertising a discounted fare for driving
the vehicle home. The notification may be pushed to an application
running on a mobile device, such as a smart phone, of the user,
while the user is in the vicinity of the vehicle needing
relocation. In one example, the notification may be pushed when the
user is passing by the vehicle needing relocation.
[0011] In some examples, the user may also be notified about ride
sharing opportunities that then factor can in rebalancing
requirements. For example, ride shares that achieve rebalancing may
be discounted more heavily than ride shares that require subsequent
rebalancing.
[0012] In still other examples, users may be given a monetary
incentive for relocating a vehicle for rebalancing purposes. The
user selection may be based on user preferences, user settings, as
well as user location relative to a location of the vehicle that
requires relocation.
[0013] In some examples, the user may be rated upon completion of
the rebalancing job. For example, after a first user has relocated
the vehicle via their ride, a second user may request the vehicle.
The second user may be queried about the status of the vehicle,
such as whether the vehicle is clean, if fuel level is sufficient,
vehicle maintenance is adequate, etc. Based on the second user's
input, the rebalancing job performed by the first user may be rated
and the rating updated in the first user's profile. Future
rebalancing notifications may then be pushed based on the user's
rebalancing rating. For example, users who have a higher rating may
receive rebalancing requests more often than those with a lower
rating. Alternatively, users who have a higher rating may receive
better incentives for rebalancing jobs than those with a lower
rating.
[0014] Note that the rebalancing operation and management may be
operated through a central rebalancing system that receives
information on user locations, vehicle locations, reservations,
past routes, statistically likely routes in the future, weather,
etc. Further, the rebalancing system may factor in the vehicle's
state of charge and/or fuel level in managing rebalancing
advertisements and notifications, as well as to parcel deliveries
as part of the overall rebalancing goals. Users may he offered
reduced rates that help increase the balance of the vehicle fleet
to the desired spatial and geographic distribution and/or that
enable a parcel or another user (for shared vehicle use) to reach a
desired destination as part of the rebalancing.
[0015] Maintenance may also be factored into the rebalancing
management system. For example, a user may be notified of a
discount if the user assists with a quick service of the vehicle
during the journey/rental and/or if they user modifies a drop off
location to improve rebalancing. Vehicle charging and/or refueling
may also be part of the rebalancing operation, such that a user may
be incentivized to move vehicles to a certain location as well as
to plug the vehicle in for charging at the specified location. The
system may monitor whether the vehicle not only reaches the
specified location, but whether the vehicle enters a charging
condition.
[0016] The system may incentive certain rebalancing actions by
providing incentives such as an increase user rating, increased
discounts, etc.
[0017] Again, the vehicle itself may advertise, or a central
application may push advertisements to users near the vehicle, the
advertisements based on the particular user's profile that are near
the vehicle. The advertisements (sometimes also called offers) may
be focused on rebalancing the vehicle to a new location and target
users more likely to be headed toward the rebalanced location.
[0018] Further, the users may be rated based on their likelihood of
leaving the vehicle in a position with high, or low, need for
rebalancing afterward. Such a rating may be further based on
whether the user leaves the vehicle with a low charge, low fuel,
dirty, unlocked, window open, etc.
[0019] Turning now to the drawings, FIG. 1 is a block diagram of an
exemplary shared vehicle system 100 that includes at least one, and
typically, a plurality, of vehicles 101, e.g., a shared vehicle
such as a motorcycle, car, van, etc. Each vehicle 101 includes a
computer 105 communicatively coupled with a network 120. The
vehicle 101 may further include a global positioning system (GPS)
device 16 or the like in a vehicle 101. Vehicles 101 may share
roadways with vehicles 102 that are not part of the shared vehicle
system 100, i.e., that are not available for sharing via a server
125.
[0020] A vehicle 1101 computer 105 may be configured for
communications on a controller area network (CAN) bus or the like,
and/or other wire or wireless protocols, e.g., Bluetooth, etc.,
i.e., the computer can communicate via various mechanisms that may
be provided in a vehicle 101, and can accordingly receive data from
vehicle sensors, communications via the network 125, e.g., from the
server 125, etc. The computer 105 may also have a connection to an
onboard diagnostics connector (OBD-II). Via the CAN bus, OBD-II,
and/or other wired or wireless mechanisms. Further, a navigation
system 106 may be provided in the vehicle 101 and communicatively
coupled to the computer 105 to provide location data, e.g., via a
global positioning system (GPS) or the like. The computer 105 may
provide data, including location information of the vehicle 101, to
the server 125 via a network 120.
[0021] The network 120 represents one or more mechanisms by which a
vehicle computer 105 may communicate with a remote server 125
and/or a user device 150. Accordingly, the network 120 may be one
or more of various wired or wireless communication mechanisms,
including any desired combination of wired (e.g., cable and fiber)
and/or wireless (e.g., cellular, wireless, satellite, microwave,
and radio frequency) communication mechanisms and any desired
network topology (or topologies when multiple communication
mechanisms are utilized). Exemplary communication networks include
wireless communication networks (e.g., using Bluetooth, IEEE
802.101, etc.), local area networks (LAN) and/or wide area networks
(WAN), including the Internet, providing data communication
services.
[0022] The server 125 may be one or more computer servers, each
generally including at least one processor and at least one memory,
the memory storing instructions executable by the processor,
including instructions for carrying out various steps and processes
described herein. The server 125 may include or be communicatively
coupled to the data store 130 for storing data received from one or
more vehicles 101.
[0023] A user device 150 may be any one of a variety of computing
devices including a processor and a memory, as well as
communication capabilities. For example, the user device 150 may be
a portable computer, tablet computer, a smart phone, etc. that
includes capabilities for wireless communications using IEEE
802.101, Bluetooth, and/or cellular communications protocols.
Further, the user device 150 may use such communication
capabilities to communicate via the network 125 including with a
vehicle computer 105. A user device 150 could communicate with a
vehicle 101 computer 105 the other mechanisms, such as a network in
the vehicle 101, a known protocols such as Bluetooth, etc. Further,
a user device 150 could be used to provide a human machine
interface (HMI) to the computer 105.
[0024] FIG. 2 is a high level representation of an implementation
of the system 100 of FIG. 1 in a geographic area 200. Vehicles 101
in the geographic area 200 may communicate with the server 125,
e.g., via the network 120 (as seen in FIG. 1). Further, vehicles
102 that are not part of the system 100, as mentioned above, may be
included in the geographic area 200. Vehicles 101 in the geographic
area 200 may be available for use by a participant in the shared
vehicle system 100, or in use. For example, vehicles 101 in FIG. 2
represented by unshaded squares may be considered to be available
for use, whereas vehicles 101 represented by shaded squares may be
considered to be in use. For reasons such as described herein, it
may sometimes be desired that vehicles 101 that are available for
use, i.e., currently unused, be relocated, sometimes referred to as
rebalanced, from a first location in the geographic area 200 to a
second location in the geographic area 200.
[0025] FIG. 3 is a process flow diagram illustrating an exemplary
process 300 for relocating a shared vehicle 101 as part of
providing a shared vehicle 101 to a user. The process 300 begins in
a block 310, in which the server 125 receives data from vehicles
101, generally including location data, e.g., geo-coordinates
specifying latitude and longitude information, from vehicle GPS
systems 106. Data from a vehicle 101 may include other information,
e.g., whether the vehicle 101 is currently in use, i.e., occupied
by a user and/or being used to transport cargo.
[0026] Next, in a block 315, the server 125 generates and/or
updates a map for a geographic area 200 of locations of shared
vehicles 101. Such map may be stored in a memory of the server 1125
and/or in the data store 130.
[0027] Next, in a block 320, the server 125, analyzing the map,
determines whether it is necessary or desirable to relocate any of
the shared vehicles 101 included in the map and not in use. Such
relocation may sometimes be referred to as rebalancing, as
mentioned above. If rebalancing is warranted, then a block 330 is
executed next. Otherwise, the process 300 proceeds to a block
325.
[0028] In the block 325, the server 125 makes vehicles available
for use without rebalancing, and may schedule a ride for a user
pursuant to a received request according to regular, undiscounted,
unincentivized, etc. fares. The process 300 then ends.
[0029] In the block 330, the server 125 determines relocation
details for a rebalancing, including, for example, an
identification of particular vehicles 101 that should be relocated,
a count of the vehicles 101 that should be relocated, an
identification of respective desired drop-off locations for each
vehicle 101 to be relocated, any fueling requirements, e.g.,
recharging for an electric vehicle 101, etc.
[0030] Next, in a block 335, the server 125 identifies potential
users, if any, in the vicinity, e.g., within 20 meters, 50 meters,
100 meters, 500 meters, etc., of each shared vehicle 101 needing
relocation.
[0031] Following the block 335, in a block 340, if any users have
been identified in the block 335, the server 125 retrieves from the
data store 130, and analyzes, profiles for such users. The server
125 generally also retrieves and analyzes a profile for the user
having made the ridesharing request in the block 305. As part of
the analysis of the block 340, the server 125 generally executes
programming to find potential matches between users' ride needs,
e.g., looking at frequently traveled bus routes, frequently
traveled vehicle trip routes, known home locations, work locations,
etc.
[0032] Following the block 340, in the block 345, the server 125
determines whether any potential users for a vehicle 101 relocation
were identified in the block 340. If so, a block 350 is executed
next. Otherwise, a block 355 is executed next.
[0033] In the block 350, the server 125 sends ride proposals to one
or more users identified in the block 335, and then determined to
match a planned ride as described with respect to the block 340.
For example, a ride a proposal could offer to allow a user to ride
a shared vehicle 101 home for a discounted fare, a coupon for a
future ride, or some other incentive. Once the ride proposal or
proposals are sent, the process 300 may continue with steps
described as part of the process 400 of FIG. 4. Alternatively, the
ride proposal could simply be accepted, whereupon a user or users
could be provided with access to the vehicle 101, and the process
300 would then end.
[0034] In the block 355, because no second users have been matched
to the ride planned for the first user 101, the server 125 proceeds
to schedule rebalancing, e.g., using designated, hired drivers for
that purpose. Following the block 355, the process 300 ends.
[0035] FIG. 4 is a process flow diagram illustrating an exemplary
process 400 for relocating a shared vehicle 101 including providing
transport to at least one user pursuant to an offer provided as
described above with respect to the process 300. The process 400
begins in a block 405 in which, as in the block 355 described
above, the server 125 pushes an offer for a ride in a shared
vehicle 101 to a user.
[0036] In the block 410, the server 125 determines whether the
offer provided in the block 405 has been accepted, e.g., a user
device 150 may be used to transmit an acceptance to the server 125
via the network 120. If the offer is not accepted, then the process
400 ends. Otherwise, the process 400 proceeds to a block 415.
[0037] In the block 415, the server 125 determines whether there is
a further transportation opportunity for the vehicle 101 to be
relocated. For example, another user may be in the vicinity of the
vehicle 101, there may be an opportunity to transport cargo, etc.
If there is no further transport opportunity, then the process 400
proceeds to a block 435. Otherwise, a block 420 is executed
next.
[0038] In the block 420, the server 125 notifies the user who
accepted the ride offer in the block 405 concerning the transport
opportunity identified in the block 415. For example, a user device
150 may be sent a message by the server 125 via the network 120.
The message could include an incentive, e.g., pick up a second user
at a location near your planned route to receive a 10 percent ride
discount, etc.
[0039] Next, in a block 425, the server 125 determines whether the
opportunity offered in the block 420 has been accepted, e.g., a
user device 150 could send a message to the server 125 indicating
acceptance or declination of the offer, the server 125 could
determine that the offer was declined after not receiving a
response for a predetermined period of time, e.g., three minutes,
etc. in any case, if the offer is accepted, then a block 430 is
executed next. Otherwise, the process 400 proceeds to the block
435.
[0040] In the block 430, the server 125 provides transportation
details to the user whose has accepted the offer of the block 420,
For example, pickup and drop-off locations of another user, cargo
such as a parcel, etc., may be identified.
[0041] Next, in the block 435 that follows the block 430, the
server 125 receives notification that a rebalancing trip has been
completed. For example, a vehicle 101 could be used to pick up a
second user, a parcel, etc., drop-off the second user, parcel,
etc., and be used by the first user to reach an intended
destination, whereupon a vehicle 101 computer 105 could provide the
notification to the server 125.
[0042] Next, in a block 440, the server 125 determines whether a
new request for a relocated vehicle 101 has been received. If not,
then the process 400 ends. Otherwise, the process 400 proceeds to a
block 445.
[0043] In the block 445, the server 125 provides a survey to a new
user of the vehicle 101 relocated as described above, For example,
cleanliness, fuel levels, etc., of the vehicle 101 may be described
according to responses to the survey, which may be conducted via
questions provided to a user device 150 via the network 120.
[0044] Next, in a block 450, the server 125 updates a first user's
profile in the data store 130 according to responses received to
the survey provided in the block 445. Accordingly, a user may be
rated or otherwise tracked, and such information may be used to
provide future offers and/or opportunities to the user, Following
the block 450, the process 400 ends.
[0045] Computing devices such as those discussed herein generally
each include instructions executable by one or more computing
devices such as those identified above, and for carrying out blocks
or steps of processes described above. Computer-executable
instructions may be compiled or interpreted from computer programs
created using a variety of programming languages and/or
technologies, including, without limitation, and either alone or in
combination, Java.TM., C, C++, Visual Basic, Java Script, Perl,
HTML, etc. In general, a processor (e.g., a microprocessor)
receives instructions, e.g., from a memory, a computer-readable
medium, etc., and executes these instructions, thereby performing
one or more processes, including one or more of the processes
described herein. Such instructions and other data may be stored
and transmitted using a variety of computer-readable media. A file
in a computing device is generally a collection of data stored on a
computer readable medium, such as a storage medium, a random access
memory, etc.
[0046] A computer-readable medium includes any medium that
participates in providing data (e.g., instructions), which may be
read by a computer. Such a medium may take many forms, including,
but not limited to, non-volatile media, volatile media, etc.
Non-volatile media include, for example, optical or magnetic disks
and other persistent memory. Volatile media include dynamic random
access memory (DRAM), which typically constitutes a main memory.
Common forms of computer-readable media include, for example, a
floppy disk, a flexible disk, hard disk, magnetic tape, any other
magnetic medium, a CD-ROM, DVD, any other optical medium, punch
cards, paper tape, any other physical medium with patterns of
holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory
chip or cartridge, or any other medium from which a computer can
read.
[0047] With regard to the media, processes, systems, methods, etc.
described herein, it should be understood that, although the steps
of such processes, etc. have been described as occurring according
to a certain ordered sequence, such processes could be practiced
with the described steps performed in an order other than the order
described herein. It further should be understood that certain
steps could be performed simultaneously, that other steps could be
added, or that certain steps described herein could be omitted. In
other words, the descriptions of systems and/or processes herein
are provided for the purpose of illustrating certain embodiments,
and should in no way be construed so as to limit the disclosed
subject matter.
[0048] Accordingly, it is to be understood that the above
description is intended to be illustrative and not restrictive,
Many embodiments and applications other than the examples provided
would be apparent to those of skill in the art upon reading the
above description. The scope of the invention should be determined,
not with reference to the above description, but should instead be
determined with reference to claims appended hereto and/or included
in a non-provisional patent application based hereon, along with
the full scope of equivalents to which such claims are entitled. It
is anticipated and intended that future developments will occur in
the arts discussed herein, and that the disclosed systems and
methods will be incorporated into such future embodiments. In sum,
it should be understood that the disclosed subject matter is
capable of modification and variation.
* * * * *