Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
GEOLOCATION COMPLIANCE FOR A MOBILE WORKFORCE
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. Application No.
17/092,576,
filed on November 9, 2020, which is a continuation of U.S. Application No.
16/189,252, filed on
November 13, 2018, which is a divisional of U.S. Application No. 15/353,049,
filed on
November 16, 2016; which claims the benefit of and priority to U.S.
Provisional Application No.
62/256,355, filed on November 17, 2015, and U.S. Provisional Application No.
62/421,507, filed
on November 14, 2016; all of which are hereby incorporated by reference herein
in their
entireties.
BACKGROUND
[0002] 1.0 Field of the Disclosure
[0003] The present disclosure relates to a method, a system and a
computer program for
geo-based regulation and compliance and more particularly, to a system, method
and computer
program for geo-based regulation and compliance for mobile workforce, among
other features.
[0004] 2.0 Related Art
[0005] The nature of many jobs in today's modem economy is such that
personnel
routinely perform work activities in various cities, municipalities, counties,
and states and cross
between different jurisdictions during the same work day. For example,
commercial operators,
e.g., professional drivers, often cross state lines perhaps many times during
a given workday and
drive in and out of different cities and counties as they go about their work.
Recently there has
been a dramatic increase in new regulations and enforcement activity designed
to control details
of employment relationships.
[0006] For example, cities and states may have different rules with
respect to required
meal breaks, required rest breaks, sick leave entitlements, as well as unique
minimum wage
-1-
7259508
Date Recue/Date Received 2022-02-07
levels. Companies are lacking a user-friendly technological solution to track
and monitor where
and for how long personnel perform work activity and to capture data to ensure
personnel are
taking required meal and rest breaks. Such a solution, which does not
currently exist, would
enhance a company's ability to conduct efficient and compliant nationwide
operations despite
the growing patchwork of unique state and local regulations.
SUMMARY OF THE INVENTION
[0007] In one aspect, the present disclosure provides a method, a system
and a computer
program for geo-based regulation and compliance for mobile workforce.
[0008] In one aspect, a system for geo-based regulation and compliance
for mobile
workforce is provided comprising a server comprising a computer configured to
receive GPS
location information related to a plurality of mobile units, a rules
compliance module executable
by a computer and configured to determine rules for a jurisdiction based on a
geographic
location of the plurality of mobile units, a rest break optimizer module
executable by the server
and configured to determine at least one rest break plan based on the
geographic location of at
least one of the plurality of mobile units, and configured to determine a
labor law compliance
plan based on the geographic location of at least one of the plurality of
mobile units and a display
device located in or associated with the at least one of the plurality of
mobile units for receiving
a directive to conform to the at least one rest break plan. The at least one
of the plurality of
mobile units may be configured to provide to the server in response to the
directive at least one
of: an opt-out of break activity, a defer break activity, a take a break
activity. The system
further comprising a rules engine configured to de-conflict rules for multiple
jurisdictions related
to a plurality of different geographic locations traversed by the at least one
of the plurality of
mobile units. The rest break optimizer module may be configured to determine
at least one rest
break plan based on different geographic locations of at least one of the
plurality of mobile units,
and may be configured to determine a compliance plan based on different
geographic locations
of at least one of the plurality of mobile units for sequencing rest breaks to
maximize work break
-2-
7259508
Date Recue/Date Received 2022-02-07
synergy, wherein the different geographic locations include jurisdictions
having differing labor
laws affecting the at least one rest break plan.
[0009] In one aspect, a computer-implemented method for geo-based
regulation and
compliance for mobile workforce comprises providing a server configured to
receive GPS
location information related to a plurality of mobile units, providing a rules
compliance module
executable by a computer and configured to determine rules for a jurisdiction
based on a
geographic location of the plurality of mobile units, providing a rest break
optimizer module
executable by the computer and configured to determine at least one rest break
plan based on the
geographic location of at least one of the plurality of mobile units, and
configured to determine a
compliance plan based on the geographic location of at least one of the
plurality of mobile units.
The method may further include that the plurality of mobile units are
configured to receive and
display from the computer a directive indicating a activity to conform to the
at least one rest
break plan.
[0010] In one aspect, a computer program product embodied on a non-
transitory storage
medium that, when read and executed by a computer, performs the steps for geo-
based
regulation and compliance for mobile workforce according to the computer-
implemented
method described above.
[0011] In one aspect, a system for geo-based regulation and compliance
for mobile
workforce comprises a server comprising a computer configured to receive GPS
location
information related to a plurality of mobile units and a rules engine module
executable by a
computer and configured to determine rules for a jurisdiction based on a
geographic location of
the plurality of mobile units, and a display device located in or associated
with the at least one of
the plurality of mobile units for receiving a directive to conform to at least
one rest break plan.
[0012] In one aspect, a system is provided for dynamic geographic based
rules
management to identify and de-conflict a plurality of rules that are
applicable to: i) a role of a
user, ii) at least one region, and iii) at least one timeframe based on a
previous geographic
location of the mobile a current location of the user, at least one planned
future location of the
-3-
7259508
Date Recue/Date Received 2022-02-07
user, or any combination thereof, the system comprising: a rules engine module
executing on a
mobile device associated with the user; a global positioning system (GPS)
device to track a
plurality of locations of the mobile device; wherein the rules engine module
sends geographic
locations over a network to a remote geographic information service (GIS) and
receives at least
one region for identifying and de-conflicting the plurality of rules. The
plurality of rules may be
dynamically identified and comprises one or more of: predefined rules,
removable rules and
updateable rules. The region may comprise a jurisdiction or a geographic area.
The jurisdiction
may comprise a country, a county, a city, a state, a postal code area, or a
predefined area. The
geographic area may be defined by an organization that specifies which of the
plurality of rules
are to be applied to the geographic area. The rules engine module may manage
the plurality of
rules that align to workday requirements, work breaks, personnel pay, or tax
rules. The at least
one region may be a plurality of regions and the rule engine module identifies
and de-conflicts
the plurality of rules that are applicable to the plurality of regions. The
system may further
comprise a repository of the plurality of rules maintained by a server, the
plurality of rules reflect
laws, policy or regulations for the at least one region. The plurality of
rules may reflect at least
one of: organizational rules and policies for the at least one region, a tax
regulation and a pay
regulation. The rules engine module may dynamically identify for a
predetermined duration at
least one of the plurality of rules for which the user must abide based on the
role of the user and
the at least one future planned location. The mobile device may be associated
with a vehicle.
[0013] In one aspect, a system is provided for dynamically capturing and
tracking
activities related to an individual; comprising: a mobile device associated
with the individual; a
global positioning system (GPS) device for providing GPS location information
of the mobile
device; and a server to receive from a computer associated with the mobile
device over a
wireless communication link a plurality of activities related to the
individual, each of the
plurality of activities including time duration information and the GPS
location information of
the mobile device for recording the plurality of activities, wherein the
mobile device determines
compliance to a set of dynamic rules and generates a notice when not in
compliance to initiate
renewed compliance. The set of dynamic rules may define activities that
require completion by
-4-
7259508
Date Recue/Date Received 2022-02-07
the individual over time to satisfy at least one rule and wherein each of the
received plurality of
activities is used to determine compliance with the at least one dynamic rule.
The set of dynamic
rules may define activities that require completion by the individual to
satisfy a plurality of the
set of rules and wherein each of the received plurality of activities is used
to determine
compliance with the set of dynamic rules. The set of dynamic rules are
applicable to the
plurality of jurisdictions and reflect laws or regulations for the plurality
of jurisdictions.
Activities may be created to capture tasks associated with the set of rules,
compensable work, or
billable work. The mobile unit may comprises a vehicle. The vehicle may be
configured to
provide event data to the mobile device, the event data including at least one
of: a current speed,
an odometer reading and a power-take-off state. The mobile device may use the
event data to
generate an activity for use in determining compliance to the set of dynamic
rules. The server
may be configured to send new activity types to the mobile unit, the new
activity types for
satisfying existing rules, new rules or for recording billable or compensable
work. The server
may be configured to send new event types to the mobile unit, the new event
types for creating
new types of activities.
[0014] In one aspect, a computer-implemented method is provided for
dynamically
capturing and tracking activities related to an individual, comprising:
receiving a plurality of
activities related to an individual, each of the plurality of activities
including time duration
information and GPS location information of a mobile unit associated with the
individual;
determining compliance or non-compliance to the plurality of rules based on
the received
plurality of activities, the plurality of rules applicable to the plurality of
regions and reflect laws
or regulations for the plurality of regions; and providing a warning
notification to the mobile unit
before non-compliance occurs or sending a non- compliance notification when
non-compliance
occurs. The step of determining compliance may include determining activities
that require
completion by the individual over time to satisfy at least one of the
plurality of rules and wherein
each of the received plurality of activities is used to determine compliance
with the at least one
of the plurality of rules. The computer-implemented method may further
comprise sending a
non- compliance notification to a third-party when non-compliance is
determined. The mobile
-5-
7259508
Date Recue/Date Received 2022-02-07
unit may comprise a vehicle. The computer-implemented method may further
comprise
receiving event data at a mobile device, the event data including at least one
of: a current speed,
an odometer reading and a power-take-off state. The computer-implemented
method may
further comprise generating an activity based on the received event data for
use in determining
compliance to the plurality of rules. The computer-implemented method may
further comprise
sending by the server new activity types to the mobile unit, the new activity
types for satisfying
existing rules or new rules. The computer- implemented method may further
comprise sending
by the server new event types to the mobile unit, the new event types for
creating new types of
activities.
[0015] In
one aspect, a system is provided to optimize a plan of activities for a
workday
and to monitor the plan for compliance, comprising: an optimizer module
executing on a
computer that receives work tasks to be performed by an individual for a work
period; an
interface to a geographic information system (GIS) tool, the GIS tool
configured to provide to
the optimizer module a route based on projected destinations related to the
work tasks, wherein
the optimizer module creates an optimized work plan for the individual
including an optimized
break plan based on the received work tasks and the route; and a compliance
module executing
on a computer that receives geographic location information from a GPS device
indicative of at
least one location of the individual over a time period, the compliance module
monitoring
compliance to the optimized work plan including the optimized break plan and
creating an alert
when not in compliance. The compliance module may monitor compliance to the
work plan
based on received event data related to a vehicle associated with the
individual. The individual
may be a vehicle operator and the work plan may be presented to a mobile unit
for viewing by
the individual on a display thereby creating a cohesive experience to the
individual which is the
work plan that includes the route, the work tasks, workday expectations, the
optimized break
plan, monitoring and sequencing thereof. The compliance module may monitor the
work plan
throughout a workday, and includes receiving an event and translating the
event to an activity to
satisfy at least one rule associated with the work plan. The optimizer module
may create an
optimized break plan to identify and de-conflict at least one rule based on a
starting location, an
-6-
7259508
Date Recue/Date Received 2022-02-07
ending location and zero or more intermediary locations. The at least one rule
may reflect a law,
a company policy or a regulation for at least one region. The system may
further comprising a
rules engine module executing on the computer that identifies at least one
rule requiring
compliance by the individual for the optimized work plan. The at least one
rule may be a
plurality of rules that reflect a plurality of regions with differing labor
regulations. The optimizer
module resolves at least one conflict in labor regulations between at least
two of the plurality of
regions.
[0016]
In one aspect, a computer-implemented method to optimize a plan of activities
for
a workday and to monitor the plan for compliance, comprising: receiving at a
computer work
tasks to be performed by an individual for a work period; determining at the
at least one
computer a route using a geographic information system (GIS) tool based on one
or more
geographic locations related to the work tasks, optimizing at the computer a
work plan for the
individual including an optimized break plan based on the received work tasks,
and based on at
least one rule related to a region and the determined route; receiving at the
computer geographic
location information from a GPS device indicative of at least one location of
the individual over
a time period; monitoring at the computer compliance of the individual to the
work plan; and
creating an alert when there is a non-compliance. The computer may comprises a
computer at a
vehicle associated with the individual. The one or more geographic locations
may comprise a
plurality of geographic locations to be traversed by the individual over the
course of a workday
and includes a plurality of: a starting location, an intermediate location and
an ending location.
The step for monitoring may monitor compliance to the work plan based on a
received event
related to a vehicle associated with the individual. The individual may be a
vehicle operator, the
computer-implemented method further comprising displaying the work plan on a
display for
viewing by the individual thereby creating a cohesive experience to the
individual which is the
work plan that includes the route, the work tasks, workday expectations, the
optimized break
plan, monitoring and sequencing thereof. The step for monitoring may include
monitoring the
work plan throughout a workday, and may include receiving an event and
translating the event to
an activity to satisfy the at least one rule associated with the work plan.
The step for optimizing
-7-
7259508
Date Recue/Date Received 2022-02-07
may create the optimized break plan to identify and de-conflict at least one
rule based on a
starting location, an ending location and zero or more intermediary locations.
The at least one
rule may reflect a company policy, a law for at least one region or a
regulation for the at least
one region. The computer-implemented method may further comprise identifying
the at least
one rule requiring compliance by the individual for the optimized work plan.
The at least one
rule may a plurality of rules that reflect a plurality of regions with
differing labor regulations.
The computer-implemented method may further comprising resolving at least one
conflict in
regulations between at least two of the plurality of regions. The computer-
implemented method
may further comprising modifying the work plan at a mobile unit associated
with the individual
to account for unexpected changes to the workday. The computer-implemented
method may
further comprising creating a list of required breaks based on the received
work tasks and the
step for optimizing optimizes the work plan to minimize time related to the
route and the
required breaks. The step of creating an alert may send a message to the
individual, a third-
party, or both. The step for monitoring determines there is an imminent non-
compliance to the at
least one rule, further comprising sending a notice to the individual at a
vehicle before there is an
actual non-compliance. The computer-implemented method may further comprising
capturing
one or more activities related to the individual to record compliance to the
at least one rule or the
work plan. The at least one rule may relate to a tax regulation or a pay
regulation. The region
may comprise a jurisdiction or a geographic area. The jurisdiction may
comprise a country, a
county, a city, a state, a postal code area, or a predefined area. The
geographic area may be
defined by an organization that specifies which of the plurality of rules are
to be applied to the
geographic area.
[0017] Additional features, advantages, and embodiments of the disclosure
may be set
forth or apparent from consideration of the detailed description and drawings.
Moreover, it is to
be understood that both the foregoing summary of the disclosure and the
following detailed
description are exemplary and intended to provide further explanation without
limiting the scope
of the disclosure as claimed.
-8-
7259508
Date Recue/Date Received 2022-02-07
BRIEF DESCRIPTION OF THE DRAWINGS
[0018] The accompanying drawings, which are included to provide a further
understanding of the disclosure, are incorporated in and constitute a part of
this specification,
illustrate embodiments of the disclosure, and together with the detailed
description, serve to
explain the principles of the disclosure. No attempt is made to show
structural details of the
disclosure in more detail than may be necessary for a fundamental
understanding of the
disclosure and the various ways in which it may be practiced. In the drawings:
[0019] Fig. 1 is an illustrative block diagram of an example system for
geo-based
regulation and compliance for mobile workforce, configured according to
principles of the
disclosure.
[0020] Fig. 2 is a block diagram of various example client device
configurations that may
be employed to provide end user functionality while interacting with a server,
configured
according to principles of the disclosure.
[0021] Fig. 3 is an example overview functional block diagram of a system
including
components for geo-based regulation and compliance for mobile workforce
showing an example
functional interrelationship of those components, configured according to
principles of the
disclosure.
[0022] Fig. 4A is an example flow diagram of an process to update Rules
for Period,
performed according to principles of the disclosure.
[0023] Fig. 4B is a flow diagram showing an example process to determine
if a new rule
is satisfied by an activity that has been previously recorded, the process
performed according to
principles of the disclosure.
[0024] Fig. 5 is a flow chart of an example process for optimization of
an individual's
workday and breaks, the process performed according to principles of the
disclosure.
-9-
7259508
Date Recue/Date Received 2022-02-07
[0025] Fig. 6A is a flow diagram showing an example process to determine
rules to be
monitored for compliance, the process performed according to principles of the
disclosure.
[0026] Fig. 6B is a flow diagram showing an example process for rule
compliance
monitoring and notification, the process performed according to principles of
the disclosure.
[0027] Fig. 7 is an example interface to describe an activity
configurator functionality,
configured according to principles of the disclosure.
[0028] Fig. 8A is an illustration showing an example of functions
provided in the activity
logger application program interface (API) and how they interact with each
other. The ovals are
included to provide example context on how these functions would be used,
according to
principles of the disclosure.
[0029] Fig. 8B is a flow diagram showing an example process for a create
activity
function, performed according to principles of the disclosure.
[0030] Fig. 8C is a flow diagram showing an example process for a start
activity
function, performed according to principles of the disclosure.
[0031] Fig. 8D is a flow diagram showing an example process for an end
activity
function, performed according to principles of the disclosure.
[0032] Fig. 8E is a flow diagram showing an example process for a search
activity
function, performed according to principles of the disclosure.
[0033] Fig. 8F is a flow diagram showing an example process for an update
activity
function, performed according to principles of the disclosure.
[0034] Fig. 8G is a flow diagram showing an example process for a delete
activity
function, performed according to principles of the disclosure.
-10-
7259508
Date Recue/Date Received 2022-02-07
[0035] Fig. 8H is a flow diagram showing an example process for set rules
to satisfied
function, performed according to principles of the disclosure.
[0036] Fig. 81 is a flow diagram showing an example process for remove
satisfied
function, performed according to principles of the disclosure.
[0037] Fig. 8J is a flow diagram showing an example to manage approval
notification
process, performed according to principles of the disclosure.
[0038] Fig. 8K is a flow diagram showing an example process to receive
new external
events using a get event function, performed according to principles of the
disclosure.
[0039] Fig. 8L is a flow diagram showing an example process for approve
activity
function performed according to principles of the disclosure.
[0040] Fig. 8M is a flow diagram showing an example process for
disapprove activity
function performed according to principles of the disclosure.
[0041] Fig. 8N is a flow diagram showing an example process to create
consistent
location calculations based on a GPS reading, performed according to
principles of the
disclosure.
[0042] Fig. 80 is a flow diagram showing an example process to interact
with a GIS
service for a get geocode function, performed according to principles of the
disclosure.
[0043] Fig. 9 is a functional block diagram of an event API 232 including
a set of
methods to permit an external system to interact with an activity engine of
server, configured
according to principles of the disclosure.
[0044] Fig. 10 is an example flow diagram outlining the operations of a
process for
dynamic task injection based on rules defined for customer preferences, in
accordance with some
embodiments of the present disclosure.
-11-
7259508
Date Recue/Date Received 2022-02-07
[0045] Fig. 11 is another example flow diagram outlining the operations
of a process for
dynamic task injection based on rules defined for predetermined conditions, in
accordance with
some embodiments of the present disclosure.
[0046] Fig. 12 is yet another example flow diagram outlining the
operations of a process
for dynamic task injection based on load type, in accordance with some
embodiments of the
present disclosure.
[0047] Fig. 13 is an example flow diagram outlining the operations of a
process for
dynamic task injection based on detected mobile unit conditions, in accordance
with some
embodiments of the present disclosure.
[0048] Fig. 14 is an example flow diagram outlining the operations of a
process for
dynamic task injection based on alerts, in accordance with some embodiments of
the present
disclosure.
[0049] The present disclosure is further described in the detailed
description that follows.
DETAILED DESCRIPTION
[0050] The disclosure and the various features and advantageous details
thereof are
explained more fully with reference to the non-limiting embodiments and
examples that are
described and/or illustrated in the accompanying drawings and detailed in the
following
description. It should be noted that the features illustrated in the drawings
are not necessarily
drawn to scale, and features of one embodiment may be employed with other
embodiments as
the skilled artisan would recognize, even if not explicitly stated herein.
Descriptions of well-
known components and processing techniques may be omitted so as to not
unnecessarily obscure
the embodiments of the disclosure. The examples used herein are intended
merely to facilitate
an understanding of ways in which the disclosure may be practiced and to
further enable those of
skill in the art to practice the embodiments of the disclosure. Accordingly,
the examples and
embodiments herein should not be construed as limiting the scope of the
disclosure. Moreover,
-12-
7259508
Date Recue/Date Received 2022-02-07
it is noted that like reference numerals represent similar parts throughout
the several views of the
drawings.
[0051] A "computer", also referred to as a "computing device" or a "CPU,"
as used in
this disclosure, means any machine, device, circuit, component, or module, or
any system of
machines, devices, circuits, components, modules, or the like, which are
capable of manipulating
data according to one or more instructions, such as, for example, without
limitation, a processor,
a microprocessor, a central processing unit, a general purpose computer, a
super computer, a
personal computer, a laptop computer, a palmtop computer, a notebook computer,
a desktop
computer, a workstation computer, a server, or the like, or an array of
processors,
microprocessors, central processing units, general purpose computers, super
computers, personal
computers, laptop computers, palmtop computers, cell phone, notebook
computers, desktop
computers, workstation computers, servers, or the like. Further, the computer
may include an
electronic device configured to communicate over a communication link. The
electronic device
may include, for example, but is not limited to, a mobile telephone, a
personal data assistant
(PDA), a mobile computer, a laptop, a tablet, a stationary computer, a smart
phone, mobile
station, user equipment, or the like.
[0052] A "server", as used in this disclosure, means any combination of
software and/or
hardware, including at least one application and/or at least one computer to
perform services for
connected clients. The at least one server application may include, but is not
limited to, for
example, an application program that can accept connections to service
requests from clients by
sending back responses to the clients. The server may be configured to run the
at least one
application, often under heavy workloads, unattended, for extended periods of
time with minimal
human direction. The server may include a plurality of computers configured,
with the at least
one application being divided among the computers depending upon the workload.
For example,
under light loading, the at least one application can run on a single
computer. However, under
heavy loading, multiple computers may be required to run the at least one
application. The
server, or any if its computers, may also be used as a workstation.
-13-
7259508
Date Recue/Date Received 2022-02-07
[0053] A "database", as used in this disclosure, means any combination of
software
and/or hardware, including at least one application and/or at least one
computer. The database
may include a structured collection of records or data such as a table, or
organized according to a
database model, such as, for example, but not limited to at least one of a
relational model, a
hierarchical model, a network model or the like. The database may include a
database
management system application (DBMS) as is known in the art. The at least one
application
may include, but is not limited to, for example, an application program that
can accept
connections to service requests from clients by sending back responses to the
clients. The
database may be configured to run the at least one application, often under
heavy workloads,
unattended, for extended periods of time with minimal human direction.
[0054] A "network," as used in this disclosure, means an arrangement of
two or more
communication links. A network may include, for example, a public network, a
cellular
network, the Internet, a local area network (LAN), a wide area network (WAN),
a metropolitan
area network (MAN), a personal area network (PAN), a campus area network, a
corporate area
network, a global area network (GAN), a broadband area network (BAN), any
combination of
the foregoing, or the like. The network may be configured to communicate data
via a wireless
and/or a wired communication medium. The network may include any one or more
of the
following topologies, including, for example, a point-to-point topology, a bus
topology, a linear
bus topology, a distributed bus topology, a star topology, an extended star
topology, a distributed
star topology, a ring topology, a mesh topology, a tree topology, or the like.
[0055] A "communication link", as used in this disclosure, means a wired
and/or wireless
medium that conveys data or information between at least two points. The wired
or wireless
medium may include, for example, a metallic conductor link, a radio frequency
(RF)
communication link, an Infrared (IR) communication link, an optical
communication link, or the
like, without limitation. The RF communication link may include, for example,
WiFi, WiMAX,
IEEE 802.11, DECT, OG, 1G, 2G, 3G or 4G cellular standards, Bluetooth, ZigBee
or the like.
-14-
7259508
Date Recue/Date Received 2022-02-07
[0056] The terms "including", "comprising" and variations thereof, as
used in this
disclosure, mean "including, but not limited to", unless expressly specified
otherwise.
[0057] The terms "a", "an", and "the", as used in this disclosure, means
"one or more",
unless expressly specified otherwise. A "pre-determined time period" and may
be a period of
time such as, e.g., a day, a week, month, year, one hour or several hours.
[0058] Devices that are in communication with each other need not be in
continuous
communication with each other, unless expressly specified otherwise. In
addition, devices that
are in communication with each other may communicate directly or indirectly
through one or
more intermediaries.
[0059] Although process steps, method steps, algorithms, functions or the
like, may be
described in a sequential order, such processes, methods, algorithms and
functions may be
configured to work in alternate orders. In other words, any sequence or order
of steps that may
be described does not necessarily indicate a requirement that the steps be
performed in that order.
The steps of the processes, methods or algorithms described herein may be
performed in any
order practical. Further, some steps may be performed simultaneously.
[0060] When a single device or article is described herein, it will be
readily apparent that
more than one device or article may be used in place of a single device or
article. Similarly,
where more than one device or article is described herein, it will be readily
apparent that a single
device or article may be used in place of the more than one device or article.
The functionality
or the features of a device may be alternatively embodied by one or more other
devices which
are not explicitly described as having such functionality or features.
[0061] A "computer-readable medium", as used in this disclosure, means
any medium
that participates in providing data (for example, instructions) which may be
read by a computer.
Such a medium may take many forms, including non-volatile media, volatile
media, and
transmission media. Non-volatile media may include, for example, optical or
magnetic disks and
other persistent memory. Volatile media may include dynamic random access
memory
-15-
7259508
Date Recue/Date Received 2022-02-07
(DRAM). Transmission media may include coaxial cables, copper wire and fiber
optics,
including the wires that comprise a system bus coupled to the processor.
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 non-transitory
storage
medium from which a computer can read.
[0062] Various forms of computer readable media may be involved in
carrying
sequences of instructions to a computer. For example, sequences of instruction
(i) may be
delivered from a RAM to a processor, (ii) may be carried over a wireless
transmission medium,
and/or (iii) may be formatted according to numerous formats, standards, or
protocols, including,
for example, WiFi, WiMAX, IEEE 802.11, DECT, OG, 1G, 2G, 3G, 4G or 5G cellular
standards,
Bluetooth, ZigBee, or the like. Computer readable media may be non-transitory
computer
readable media.
[0063] The nature of many jobs in the modern economy often requires
personnel to
routinely perform activities in various cities, municipalities, countries, and
states and cross
between such different jurisdictions during the same work day or predetermined
time period.
For example, commercial operators often cross state lines many times during a
given workday
and drive in and out of different cities and counties as they go about their
work. There has been
an increase in new ordinances and state laws, including an increase in
enforcement activity for
controlling employment relationships. For example, cities and states have
different rules with
respect to required meal breaks, required rest breaks, sick leave and
entitlements, as well as
differing minimum wage levels. Companies often do not have a technological
solution to
accurately track and monitor where and for how long personnel perform work
activities and for
capturing data to ensure regulation compliance, such as across a nationwide
setting.
[0064] In one aspect, this present disclosure describes a system and
method that uses
geo-location and a rules engine to facilitate compliance to federal, state,
and local regulations as
-16-
7259508
Date Recue/Date Received 2022-02-07
well as company policies. Moreover, the system and methods according to
principles of this
disclosure may be used by a mobile workforce to manage work assignments,
report activities,
and to manage and track time as related to determined geographic locations,
such as by global
positioning system (GPS). This system and method according to principles of
this disclosure
may be used, e.g., in the transportation industry, but is not limited to this
industry.
[0065] Fig. 1 is an illustrative block diagram of an example system for
geo-based
regulation and compliance for mobile workforce, configured according to
principles of the
disclosure. The system 100 may include one or more mobile units 105a-1 05c,
which may
include but is not limited to a vehicle 112a - 112c, a computing device 110a -
110c,
communications unit 111a - 111c, user interface 114a - 114c, and a by global
positioning system
(GPS) 113a - 113c. These may be contained in one device or multiple units
connected though a
common local area network (LAN).
[0066] The one or more mobile units 105a-105c may be equipped with a
computing
device 110a -110c to control and interface with a communications unit llla -
111c for
communicating across a network 125 (which may be, e.g., a cellular network)
via a
communication link 130 to a server 115. The communication link 130 may be bi-
directional.
The computing device 110a-110c may also interface with a vehicle e.g., such as
a truck, bus, or
similar vehicle 112a -112c for the purpose of receiving events and providing
context of the user
based on vehicle operation.
[0067] The computing device 110a-110c may also interact with a user
interface 114a-114c
including an input device to receive input from a user and an output to convey
messages and
output to a user (e.g., a driver) of the one or more mobile units 105a-1 05c.
The input device
114a-114c may comprise of but not limited to a touch sensitive screen, a
keypad, a keyboard, a
mouse, voice activated input device. The output device may include but not
limited to a visual
screen, LED or warning lights, dashboard indicators, sound such as voice or
tones. The
computing device 110a-110c may also interface with a GPS tracking device 113a-
113c that may
be configured to provide location data information of the one or more mobile
units 105a-105c.
-17-
7259508
Date Recue/Date Received 2022-02-07
[0068] A system user such as a system manager may interact with the
server 115 via an
input device 116, such as to implement or manage the rules among other
functions, as described
more fully below. In some configurations, the input device 116 may be
connected to the server
115 over the network 125.
[0069] As the one or more mobile units 105a-105c travels from one
geographic location
to another geographic location, the GPS tracking device 113a-113c may provide
updates of the
current location to the computing device 110a-110c, which in tum, may provide
updates to the
server 115. The updates may be continuous or may be periodic.
[0070] The system 100, in particular the server 115, may record in the
database 120
activities of the one or more mobile units 105a-105c and also the associated
user (as part of
normal business processes) and may tag such activities with geo-locations
provided by the GPS
tracking device 1 13a-1 13c.
[0071] A Rule herein is a representation of government laws, regulations
or company
rules and policies that an individual is expected to show compliance to. In
the applications
herein a rule includes an expectation of an activity that needs to be
performed. Rules are tied to
the specific geographic regions or jurisdictions, and user roles that the law,
regulations, rules or
policies apply to. For example, to manage US Hours of Service, rules to
represent Motor Carrier
Safety (FMCSA) standards (Title 49 Part 395 - Hours of Service of Drivers) may
be created and
tied to the US region with a role of drive. Likewise, to manage Canadian Hours
of Service, rules
to represent Canadian Council of Motor Transport Administrators (CCMTA)
Commercial
Vehicle Drivers Hours of Service Regulations may be created and tied to
Canadian region with a
role of driver. A third set of rules may be created that aligns to the Oil &
Gas Related
Exceptions in the Federal Hours-of-Service Rules and may be tied to a U.S.
region with a role of
Oilfield Driver To ensure alignment to California labor laws, the application
may include rules to
manage California's Meal and Rest break laws which would be tied to California
Region and all
roles.
-18-
7259508
Date Recue/Date Received 2022-02-07
[0072] In one aspect, the computing device 110a-110c may interpret
predefined rules
based on work location (as provided by the GPS tracking device 113a-113c
associated with a
respective mobile unit 105a-105c), and may, for example, prompt a particular
user associated
with any one of the mobile units 105a-105c to:
1) Enter data (e.g., via input device 114a-114c)
2) Take an action (e.g., meal or rest break) and
3) Record compensable and/or billable activities (e.g., hand unload,
detention, record
paperwork) as a part of the user's work process.
The server 115 may be operatively coupled 132 to a back-end processing system
(not shown) for
further processing based on information gathered and/or maintained by server
115. Such back-
end processing may include, e.g., payroll functions, human resource functions,
management
functions, report generation, billing, and the like.
[0073] Fig. 2 is a block diagram of various example configurations of
Mobile Units 185,
195 and Mobile Devices 180, 190 that may be interacting with a server,
configured according to
principles of the disclosure. Mobile Units 185, 195 may be required to satisfy
the FMCSA
electronic logging (ELD) mandate as they include a connection to the vehicle
112a - 112c using
a standard vehicle connection such as SAE J1939. SAE J1939 supports real-time
control
functions, simple information exchanges, and diagnostic data exchanges between
electronic
control units physically distributed throughout the vehicle 112a - 112c.
Control units may
include, e.g., odometer readout, power-take-off (PTO) engaged, engine RPM,
speed indicator,
tire pressure, engine status (On/Off), or similar internal readout or status.
Mobile Devices 180,
190 may be used as an extension of the system and method to other industries
that don't require a
connection to the vehicle.
[0074] In configuration 180, a mobile device 134 such as a tablet
computer, laptop or cell
phone that contain; a computing device 110a - 110b, communication unit 111a -
111b, global
-19-
7259508
Date Recue/Date Received 2022-02-07
positioning unit (GPS)113a - 113b and user interface 114a - 114b may be used
to provide end
user capability.
[0075] In Configuration 185, a mobile device 135 such as a table
computer, laptop or cell
phone are connected to broadband router 121 using a wireless connection. The
Broadband router
provides connectivity to the Vehicle 112a using a standard protocol such as
SAE Jl 708 or SAE
J1939 providing vehicle events to the mobile device 135. The broadband router
then provides
network connectivity 111a - 111c to communicate to servers 115. The mobile
device 135 may
contain; a computing device 110a- 110b, communication unit 111a - 111b and
user interface 114a-
114b and may contain a global positioning unit (GPS)113a-113b. The broadband
router may
contain; a computing device 110a - 110b, communication unit 111a - 111b and
may contain a
global positioning unit (GPS)113a-113b. The vehicle 112a may provide a
connection to the
controller area network (CAN) bus to provide events to the mobile device 135.
[0076] Configuration 190, is a depiction of a generic device recognizing
that as
technology advances there may be new mobile devices that contain the required
components
including; a CPU 123, Storage 124, communication unit 111a, global positioning
unit (GPS) 113a
and user interface 114a may be used to provide end user capability.
[0077] Configuration 195, is a depiction of a generic device recognizing
that as
technology advances there may be new Mobile Units that contain the required
components
including; a CPU 123, Storage 124, communication unit 111a - 111b, global
positioning unit
(GPS)113a-113b, user interface 114a and vehicle 112a- 112c may be used to
provide end user
capability.
[0078] Fig. 3 is an example overview functional block diagram of a system
200 including
components for geo-based regulation and compliance for mobile workforce
showing an example
functional interrelationship of those components, configured according to
principles of the
disclosure. A brief introduction of these components follows, with a more
detailed explanation
thereafter.
-20-
7259508
Date Recue/Date Received 2022-02-07
[0079] An event generator 230 may monitor, read, or receive events from a
vehicle 112a
- 112c related to statuses and states of the vehicle, a server 115 to
facilitate approval process, an
application deployed on computing device 110a - 110c to provide app to app
communication.
Events may also come from a mobile device 134, 135, router 121 or from within
system 200 as
well. The event generator 230 may log or store these events in an events
database 225. The
event generator 230 and events database 225 typically are located within or
associated with the
respective mobile unit 105a-105c.
[0080] The activity logger application programming interface (API) 220 is
a tool that
may be used to provide functionality to the end user at the mobile unit 105a-1
05c to log their
activities. The activity editor 215 is a description of a generic use of the
activity logger API 220.
The Activity Editor 215 may include a responsive Web Application that may
permit users to
create, update and delete activities after the fact (i.e., after an activity
has occurred). The
activities database 235 records activities as they are created or modified.
The activities
configurator 250 is a tool that permits a user to create, update and remove
activity types in
activities database 235.
[0081] The rules configurator 210 is a tool that permits a system user to
create, update
and remove rules in rules database 205. The rules configurator 210 may reside
and execute on
server 115. The rules engine 240 is a module that identifies one or more rules
that a specific user
may need to follow based on inputs provided. The rules engine 240 can satisfy
what is needed
by the optimizer 245 and compliance engines 250. Rules engine 240 may execute
on the server
115, the computing device 110a-110c, or both. The geographic information
system (GIS) tool
280 is a system that is designed to capture, store, manipulate, analyze,
manage, and present
spatial or geographical data. A GIS tool can provide information such as maps,
geographic
points, geo fences, region management, location lookup, historic route
visualization, and such to
the Rules engine 240. The GIS tool 280 may execute on server 115. The
optimizer engine 245
optimizes a user of the mobile unit 105a -105c, such as a truck driver, by
integrating meal and
rest breaks as required by Federal, State and local authorities for a time
period, for multiple
jurisdictions, based on rules. The optimizer engine 245 may execute on the
computing devices
-21-
7259508
Date Recue/Date Received 2022-02-07
110a - 110c. The compliance engine 252 is configured to enforce rules based on
geo-location of
the mobile unit 105a -105c. The compliance engine 252 may execute on the
computing device
110a - 110c. In one aspect, the GPS device 113a -113c may report one of mobile
units 105a -105c
physical positions. A clock 265 may provide a time stamp of GPS locations and
events in the
system 200 overall. The routing tool 260 may be configured to provide, among
other features, a
route given the information provided, such as, e.g., current user of mobile
unit, start location and
time, stops (location and duration), end location, weather, traffic, fuel,
cargo type and type of
vehicle. A billing tool or system 270 may receive activity information for
accounting for billable
time. A pay tool or system 275 may receive activity information for assisting
in appropriate pay
calculation for a mobile unit user. An activity reporting module 255 may
report on various
activities by mobile user. The regulation resource 204 may include one or more
resources for
determining regulations related to various jurisdictions such as cities,
counties, states, countries.
This resources may be a compilation of regulations from multiple sources and
may provide the
guiding basis upon which rules may be created for each of the jurisdictions
for which the system
100 may provide operational service. The regulation resource 204 may be
manually compiled,
automatically compiled from jurisdiction publications and regulations, or a
combination of
manual and automatic.
[0082] Rule configurator 210 is a software tool executable at server 115
that permits a
system user, such as a system administrator, to create, update and remove
rules. The rule
configurator also provides an ability for system users to tie rules to the
geographic region and
user roles. Rules may also be assigned to a period rule (time period which the
rule is valid).
Each rule can have a notification type assigned to it. Rules may be assigned
to activities and
prompts via the activities configurator 250. A system user may be required to
log in as a user to
ensure proper permissions. Rule configurator 210 provides several functions
including:
= Rules Search
o This provides an ability to explore existing Rules. The
search has an
ability to find rules based on:
-22-
7259508
Date Recue/Date Received 2022-02-07
= Saved Search
= This is a drop down that contains all searches the user has
saved. Selecting one populates all of the fields below.
= Rules fields
= Rule Name
= Parent
= Rule Type
= Rule Family
= Region
= Roles
= Active
o Actions
= Search
= This takes the users input, and call queries the database to
find all results that match.
= Display the results in the Rules Search Results.
= Save
= This saves the user's search selection. When the user
clicks save search, it may ask them to name the search.
-23-
7259508
Date Recue/Date Received 2022-02-07
= Clear
= This re-sets the search fields
= Rules Search Results
o The search results provide a list of all rules that match the users
search.
o Data that may be displayed includes:
= Rule Name
= Rule Display Name
= Rule Value
= Rule Parent
= Rule Type
= Rule Family
= Time Period
= Overdue Notify Duration
= Notification Type
= Back Office Notification
= Warning Duration
= Warning Type
= Active
o Actions
-24-
7259508
Date Recue/Date Received 2022-02-07
= Export
= Export provides a delimited text file of the results of the
search.
= Clicking on a row
= This opens the Rules detail page with the selected Rule.
= Delete
= This prompts a "confirm" popup. If the user confirms, the
rule may be deleted.
= New
= This opens the rule detail area with none of the fields
populated.
= Rules Detail
o The Rules detail area provides additional detail and information for the
user to create, update and view a rule. If the page was called with a rule it
is populated with the data about that rule. If it was created by selecting the
new button, it may populate with no data filled in.
o Fields
= Rule Name
= The rule name is the name of the rule. It is used in all
configuration tools, and back end systems.
-25-
7259508
Date Recue/Date Received 2022-02-07
= The rule name should be descriptive of the rule, and to
benefit users, unique names make maintenance easiest.
= This is a free form text field
= Rule Display Name
= The rule display name is what the end user sees. Often this
rule will not be unique.
= Rule Name, Rule Display, Name Examples (California
Lunch Break, 30 min break), (HOS 30 min Break, 30 min
break)
= This is a free form text field
= Rule Value
= This is the value that the rule applies to. The Rule Type
determines what this value means. For example, if it is a
"Break" Rule it will be the time in minutes that a break
must be taken. Work Day rules indicate a maximum
amount of time in minutes. If it is a pay rule, it may be a
currency value.
= Parent
= If a rule has a parent, it supersedes the parent rule.
= The user is able to select only one rule to be the parent.
= Rule Type
-26-
7259508
Date Recue/Date Received 2022-02-07
= Rule types is used to classify a specific high level grouping
of rules.
= A rule can have only one rule type.
= Types include:
o Work Period
o Break
o Pay
o Tax
= Rule Family
= A rule family is a way to group rules that are part of the
same regulation. Rule family indicates that specific rules
cannot be satisfied by the same activity.
= Region
= Region is important, as a rule cannot exist without a region.
A region represents a geographic area to which the rules
apply. How the system user identifies and assigns the
region to the tool depends on the GIS system used.
= Period
= A period represents the time period that a rule is valid.
There can be a number of time periods. Only one period
type can be selected.
-27-
7259508
Date Recue/Date Received 2022-02-07
= Roles
= This is a list of the end user roles to which the rules apply.
If no roles are selected, the rule is valid for all roles.
= Overdue Notify Duration
= This indicates the time when a notification should be
generated indicating an activity is overdue.
= 9999 = do not notify
= Number can be positive or negative. Negative represents
minutes after rule was supposed to be satisfied.
= Overdue Notification
= Type of notification to provide to the user (Sound, Image,
Text)
= Value
o if Sound or Image Type are selected, this may be a
file path to where the sound may be on the device.
o if it is Text, this should include the text message to
provide to the end user.
= Back Office Notification
= This is a checkbox that indicates someone in the back
office should be notified that the user is not in compliance.
= Warning Duration
-28-
7259508
Date Recue/Date Received 2022-02-07
= This indicates the time when we should notify that an
activity is coming up.
= 9999 = do not notify
= Number can only be positive. Minutes before rule is
supposed to be satisfied.
= Warning Notification
= Type of notification to provide to the user (Sound, Image,
Text)
= Value
o if sound or image type are selected, this may be a
file path where the sound is located on the device.
o if it is text, this should include the text message to
provide to the end user.
= Active
= Check Box that indicates whether a rule should be used. If
Active= False, the system ignores it completely.
o Actions
= Save
= Create or update the rule in the database.
= Cancel
-29-
7259508
Date Recue/Date Received 2022-02-07
[0083] Rules Engine 240 is a tool running at the server 115, the mobile
unit 105a - 105c,
or both, and is configured to identify the rule or rules that a specific
mobile unit 105a -105c user
needs to follow based on inputs provided. To determine if a mobile unit 105a -
105c user is
required to satisfy a rule, three pieces of information is required: i) what
role(s) the mobile unit
105a - 105c user is performing, where the particular mobile unit 105a -105c
is, and the
timeframe a rule needs to be satisfied. Once a rule is identified as applying
to the user, the rule is
added to the specific user's "Rules for Period" table (as part of the Rules
database 205).
[0084] The following are example types of rules that may be configured
and enforced.
a. Workday: Workday rules manage items such as the maximum/ minimum
period of time for a work day, overtime rules, FMCSA 70 hour rules &
restarts. Workday rules may be tied to break rules as more complex break
rules may apply to specific workdays.
b. Break: Break rules manage regulations and policies such as mandated
paid and unpaid breaks, lunch breaks and other activities with a mandated
minimum duration.
c. Pay: Pay rules may be used to manage items such as varying minimum
wage by region, and items such as per diem, hazard pay or millage
premium for specific geographic area.
d. Income, Sales and Use Taxes: These rules may be used to support
organizations or individuals who need to pay taxes specific to a geography
such as International Fuel Tax Agreement (IFTA) Tax.
[0085] Rules may also be tied together and configured to work with each
other.
a. In some cases, rules may be configured to ensure they don't
overlap
-30-
7259508
Date Recue/Date Received 2022-02-07
1. Example: 3 break rules may be required to support
current
California laws that may require 2, 10-min breaks and 1, 30-min
break. As a result, all 3 breaks may not be considered satisfied
when the driver takes 1, 30-min break.
b. In other cases, rules can be configured to allow overlap.
1. Example: The FMCSA 30 min break requirement if driving
for
more than 8 hours can overlap with California's 30 min meal break
rule. This way when the user takes their 30 min break both rules
are satisfied.
[0086] Rules can be in a hierarchy, where a child rule may supersede the
parent rule
a. Example: Minimum wage for the United States is currently
$7.25, Illinois
is $8.25 and Chicago, IL is currently $10.50. As Chicago is within the
Illinois region (parent) it would supersede Illinois and the United States
which would be Illinois regional parent.
[0087] Rules can be tied to a position, job or work configuration.
a. Example: Sometimes rules in the same region may be different
for
specific work configuration. In the trucking industry, the rules in the
United States region are different for Farm Use, Over the Road, Oil Field,
Port Dray Short Haul.
[0088] Rules for Time Period is a significant aspect of the system 200,
and may be a first
mode that other applications of system 200 may interact with the Rules Engine
240. Rules for
Period may be viewed as an instance when a rule needs to be applied, and may
include the
following attributes:
-31-
7259508
Date Recue/Date Received 2022-02-07
= User ID - The user that must comply to this rule
= Rule - The rule identification that needs to be followed
= Satisfied - An indicator that lets system applications know if the
user completed the rule.
o Satisfied may be checked in processes that could
impact completion such as:
= When an activity is created
= When an activity is changed
= When a rule is added to rules for a period
= Activity - The activity that was performed that caused
satisfied to be marked true.
= Valid Period Start - is a timestamp that indicates the earliest
time an activity can start to satisfy this rule for period.
= Valid Period End - is the timestamp that indicates the latest
time an activity can start to satisfy the rule for the period.
With this information, the system 200 is able to ascertain what rules a mobile
unit 105a-1 05c
user needs to comply with, at what time based on where they have been, when
and how long they
were there, and the role they perform. Update Rules for Period provides an
interface for other
applications of system 200 may interact with the Rules Engine 204.
= Inputs
o User
-32-
7259508
Date Recue/Date Received 2022-02-07
o Latitude
o Longitude
o Date, Time
= Output
o List (Rules for Period) or <null>
[0089] Fig. 4A is an example flow diagram of an Update Rules for Period
process used to
depict a possible way to identify new rules that apply to a user, performed
according to
principles of the disclosure. The flow diagram of Fig. 4A (and all other flow
diagrams herein)
may also represent a block diagram of components that when read from a
computer readable
medium and executed by a computer perform the respective step. The optimizer
engine 245 and
compliance engine 252 may call this process starting at step 400. The
optimizer engine 245 may
call this process with information about points a geo position (Latitude,
Longitude) and times in
a route to have rules built that the mobile unit 105a-105c user may interact
with. The
compliance engine 252 may call every X- distance @redetermined distance) based
on a GPS
location (Latitude, Longitude) to find out if there is a new rule or rules for
the current location.
At step 405, a determination is made to identify a defined region(s) (e.g.,
state, county, locality)
that the geo position falls into. The process may interact with a GIS system
or GIS service 280
to determine the defined regions that the point falls into. Example GIS
systems may include,
e.g., Nokia Here , Google Maps , ESRI geonet, or the like. The GIS system 280
is typically
configured to return a region or a set of regions for the geo position. The
system can use pre-
defined regions such as countries, states, postal codes and cities, or it can
also use user defined
regions like southwest United States.
[0090] At step 410, a check is made to determine if the mobile unit 105a-
1 05c and user
entered a new region. This may include determining if the region or set of
regions are the same
as the region or set of regions the mobile unit 105a-1 05c and user were in
last time Update Rules
for Period was called. If they are in the same region, then at step 460,
return <null>. However,
-33-
7259508
Date Recue/Date Received 2022-02-07
if there is a new region, at step 415 all rules are obtained for that region
that apply to that user's
role from the rules database 205. All existing rules for the current period
for the user are
obtained, including satisfied rules. At step 420, for each of the rules
obtained from step 415,
compare them with the existing rules for the period from the rules for period
database 206. If at
step 430, it is determined that the rule is already in rules for period 206,
processing continues at
step 450. However, if the rule is new, then at step 435, a new rule is created
for the period using
information passed in, and the rule found to create an instance of the rule.
The results may
include:
a. User will be the user passed in.
b. Rule will be the rule found in step 415.
c. Using the time passed in and the rules found in the rules for period
table
206 for the rule set the valid period start and valid period end dates and
time.
d. Satisfied may be set to False.
e. Activity ID may be set to null.
[0091] When a new rule is added, it may have already been satisfied by
one or more an
activities. Step 440 determines if a rule has been satisfied, which may be a
sub- process
explained in relation to Fig. 4B below. At step 445, the new rule may be added
to the result set
in the rules database 205, and the new rule may be added to a result list 465
for eventual return at
step 470. At step 450, a check may be made to determine if there are more
rules to evaluate; if
so, processing continues at step 425. If, however, there are no more rules to
evaluate as
determined at step 450, then at step 455 a check may be made to determine if
any results were
found. If no results were found, then a null result may be returned at step
460. If at least one
result was found, then the result list 465 of rules may be returned at step
470.
-34-
7259508
Date Recue/Date Received 2022-02-07
[0092] Fig. 4B is a flow diagram showing an example process to determine
if a new rule
is satisfied, the process performed according to principles of the disclosure
starting at step 480.
This may be a sub-process callable as required such as at step 440 of Fig. 4A.
At step 482,
acquire all activates from the activities table 235 that could satisfy the
rule by querying the
activities table 235 with the following criteria: i) activity start is after
the rule valid start time
and date, ii) activity start is before the rule valid end time and date, and
iii) through join, the rules
should be associated to this activity type. At step 484, a check is made to
determine if any
activities are found satisfying the rule. If no activities are found, the sub-
process may complete
at step 494. If there is one or more activities found satisfying the rule,
then at step 486, all rules
with the Activity are extracted. At step 488, a check is made to determine if
the new rule is the
same family as this rule. If yes, then processing continues at step 492, where
a check is made to
determine if there are more activities. If there are no more activities, the
sub-process completes
at step 494. If there are more activities, then processing continues at step
486 with the next
activity. If at step 488 the new rule is not in the same family as this rule,
the new rule is updated
to satisfy and update the new rule with the Activity. The sub- process may end
at step 494.
[0093] The optimizer 245 is an application and tool which works in
conjunction with the
rules engine 240 and a location based plan (e.g., a route for trucking), to
provide individual
associated with mobile units 105a-105c an interactive tool to plan their day
including, e.g., when
and where to take breaks. The optimizer 245 provides the individual associated
with a mobile
unit 105a-105c optimal overlap of breaks to satisfy as many regulations and
policy's as possible
to maximize their productivity, while still being compliant with policies and
regulations for all
geographic regions the individual associate with mobile units 105a-105c plans
to be in.
[0094] By way of example, a driver intends to drive from Utah to
California. The driver
must follow the Federal Motor Carrier Safety Administration (FMCSA) Hours of
Service rules
the Nevada workday break rules and California workday break rules. The
optimizer 235 is
configured to overlay all of the rules and identify that by taking two 10
minute breaks and one 30
minute break may satisfy all rules in these jurisdictions. Moreover, the
optimizer 245 is
configured to further recognize that the 30 minute break needs to occur
between the hours of a
-35-
7259508
Date Recue/Date Received 2022-02-07
first time (X) and a second time (Y) to be compliant. This information permits
the driver to
better plan the trip, and determine when and where to take required breaks.
[0095] The optimizer 245 may accept a number of inputs to create the
optimized plan
including:
o An origin and destination.
= Example: The driver knows they need to travel from Milwaukee,
WI to New York, NY. They enter the origin, destination and start
time as inputs. The optimizer 245 works with a routing software
260 to determine the route for the driver, and then may display best
options for breaks that align with rules & regulations for the
locales the user intends to be traveling through.
o A multi-stop route.
= Example: Not all trips are direct. The driver knows that the
intended travel from Milwaukee, WI to New York, NY, will have a
stop in Buffalo, NY. The origin, destination and start time may be
entered. Stops may be added with an order and indication about
how long each stop may take. The optimizer 245 may employ a
routing software to determine the route for the driver, and then
display best options for breaks that align with rules and regulations
for the jurisdictions that the user anticipates traveling through. The
system 100 may automatically compensate for entering new time
zones, e.g., for adjusting total times.
o A route in a standardized format including stops and times for segments
as
well as times stopped from another application by way of an API.
-36-
7259508
Date Recue/Date Received 2022-02-07
[0096] The optimizer 245 may take into account all rules currently
applied to an
individual associate with mobile units 105a-105c as well as any new rules that
may be applied
during the route because of entering new regions.
o Example: As a driver who needs to follow FMCSA Hours of
Service,
when selecting a route going to Oakland CA, the rules may take into
account where the driver is currently located, a 14-hour shift, an 11-hour
drive time, and when a 30-minute break must be taken (or if already
taken). Any new rules may be taken into account that apply because the
driver will be entering the California region.
[0097] As part of the optimizer 245, or as a separate route optimizer
tool, a function is
provided that identifies all rules that should be followed for a given route.
Moreover, the
optimizer 245 may be configured to identify an activity that satisfies more
than one rule and may
recommend that activity as a better option. Optimizer 245 may be configured to
identify if the
route plus activities required to satisfy necessary compliance rules may go
past the individual
associated with a mobile unit 105a-105c expected end of day (rule). In this
case, an optimized set
of rules may be returned, with a message or recommendation suggesting a
different end point be
created, and to re-optimize. This re- optimization may change the individual's
rules due to any
new geography. This functionality may be accessed directly by a custom user
interface tailored
for this capability which may accept a start location, an end location, and
any points between.
This route optimization functionality may also be accessed by another
application like a trip
planner that may provide another layer of detail into the individual's
activities.
[0098] Fig. 5 is a flow chart of an example process for route
optimization, the process
performed according to principles of the disclosure. The entry point to the
process begins at 500,
which may be a callable function accepting the following as input parameters:
current user, such
as an individual associated with a mobile unit 105a-105c, a start location and
a time including
any anticipated stop or stops with location and estimated duration, and an end
location. At step
505, the start, stop and end locations may be provided to a routing tool 260.
At step 510, the
-37-
7259508
Date Recue/Date Received 2022-02-07
routing tool 260 determines at least one route. At step 515, the routing tool
260 provides a set of
latitude, longitude and time as results that represent the determined route.
The route typically is
represented by a large set of latitude, longitude, date/time. These points
represent every
predestined distance, e.g., 5 miles, but is configurable, of the route.
[0099] At
step 520, a first latitude and longitude set is identified to be used by the
Rules
Engine 240 to initiate building a planned route. At step 525, the rules engine
is called to update
rules for the period 400 for the input parameters. At step 530, a check is
made to determine if
there are more points of latitude and longitude, and if so, the rule engine is
called again at step
525 with the next latitude and longitude set to continue updating rules for
the period 400. The
update rules for period marks any existing and new rule as satisfied if they
are satisfied by a
current activity. If there are no further points of latitude and longitude,
then at step 535, all rules
for the current period that are not marked satisfied are located. At step 540,
the first or next
unsatisfied rule is obtained. At step 545, a check is made to see if there is
more than one rule of
the same type for an overlapping period. If not, then processing continues at
step 565. If there is
more than one rule of the same type for the overlapping period, then at step
550, an evaluation is
done to determine if a family relationship prevents overlap. At step 555, for
overlapping rules, a
check is made to determine if any share a family. If not, processing continues
at step 560. If so,
a check is made at step 570 to determine if all rules are in the same family.
If yes, the processing
continues at step 565. Otherwise, if the rules are not all in the same family,
then at step 575,
those rules with the best overlap, i.e., longest duration overlap, are
identified. At step 560, using
the latest start time and location and earliest end time and location of the
rules, create a
recommendation. At step 565, the recommendation for the rules may be saved as
a result.
Processing continues with step 580 where a check is made to determine if there
are more rules to
be processed. If so, then processing continues at step 540, otherwise, at step
585, a check is
made to determine whether or not the added at least one activity conflicts
with the end of day
rule. If not, the result may be returned at step 595. The determination at
step 585 may be
accomplished by taking the date and time of the last point from step 525 and
adding in the
duration of the at least one activity to satisfy the rule. If the result
occurs later than the end of
-38-
7259508
Date Recue/Date Received 2022-02-07
day rule, raise an error indicating that the end of route is not feasible with
current route. At step
590, the end point change recommended with re-optimization message is created
as a result. At
step 595, the result is returned. If there isn't an issue, just return the
result to the user. The
process may end or return at step 597.
[0100] Optimizer Example
[0101] A driver of a vehicle 11 2a-11 2c needs to drive from Las Vegas,
NV to Mountain
Pass, CA He had driven for 7.5 hours before this new load was assigned to
finish his day. The
driver just completed his 36 hour re-start before he started this day. He
plans to leave at noon as
that is when he should complete hooking up to the trailer. Referring to steps
505 to 515, to
illustrate an example result from a routing tool, a user may enter:
= Start Location: Dean Martin Dr, Las Vegas, NV
= Start Date Time: 5/1/2016 12:00
= <No Stops>
= End Location: Clark Mt. Road, Mountain Pass, CA
TABLE 1 shows a result expected from the routing tool.
TABLE 1
Latitude Longitude Date Time
1 36.0672239 - 5/1/2016
115.1891994 12:00
2 36.0110969 - 5/1/2016
115.2019974 12:07
3 35.9221474 - 5/1/2016
115.2277161 12:13
4 35.8677653 - 5/1/2016
115.3300632 12:19
35.7471878 - 5/1/2016
115.4426557 12:25
-39-
7259508
Date Recue/Date Received 2022-02-07
6 35.7471878 - 5/1/2016
115.4426557 12:31
7 35.7200864 - 5/1/2016
115.4323792 12:37
8 35.6367557 - 5/1/2016
115.5134218 12:43
9 35.6367557 - 5/1/2016
115.5134218 12:49
10 35.4407923 - 5/1/2016
115.5639171 12:55
11 35.4407923 - 5/1/2016
115.5639171 13:01
12 35.4786224 - 5/1/2016
115.5426342 13:07
Referring to steps 520, 400, 530, to illustrate Update Rules for Period based
on the route in the
previous step.
Rules before a First Call is shown in TABLE 2:
TABLE 2
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
8hr workday Workday No 5/1/2016 5/1/2016 HOS 480
no break 04:30 12:30
70 hr in 8 days Workday No 5/1/2016 5/9/2016 HOS 4200
04:30 4:30
[0102] Using the results from TABLE 1, calling Rules for Period in the
Rules Engine
240 for each row shows that Call 1 - Call 5 results in no change because the
driver did not
change regions, so no new rules for time, shown in TABLE 3.
TABLE 3
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
8hr workday Workday No 5/1/2016 5/1/2016 HOS 480
no break 04:30 12:30
70 hr in 8 days Workday No 5/1/2016 5/9/2016 HOS 4200
04:30 4:30
-40-
7259508
Date Recue/Date Received 2022-02-07
[0103] But for Call 6: the driver is working more than 8 hours (since he
has already
worked 7.5 hours). So now, add the 14-hour workday with break rule.
= This rule has the parent of 8-hour workday so it supersedes the 8-hour
rule. 8-
hours will be removed (shown by strikethrough) and 14-hours will be added as
shown in TABLE 4 in the third row.
= This rule requires the driver take a 30 min break. So that rule gets
added too, as
shown in the last row of TABLE 4.
TABLE 4
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
8 hr workday Workday No 5/1/2016 5/1/2016 HOS- 484
no break 1:30 12:30
70 hr in 8 days Workday No 5/1/2016 5/9/2016 HOS 4200
04:30 4:30
14 hr workday Workday No 5/1/2016 5/1/2016 HOS 840
with break 04:30 18:30
30 min Hours of Break No 5/1/2016 5/1/2016 HOS 30
Service Break 07:30 15:30
[0104] Calls 7 and 8 result in no change because the driver did not
change regions;
therefore no new rules for time, as shown in TABLE 5.
TABLE 5
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
70 hr in 8 days Workday No 5/1/2016 5/9/2016 HOS 4200
04:30 4:30
14 hr workday Workday No 5/1/2016 5/1/2016 HOS 840
with break 04:30 18:30
30 min Hours of Break No 5/1/2016 5/1/2016 HOS 30
Service Break 07:30 15:30
-41-
7259508
Date Recue/Date Received 2022-02-07
[0105] However, for Call 9, the route just added the California region by
crossing the
state line. Therefore, California break rules now need to be added, as shown
in the last three
rows of TABLE 6.
TABLE 6
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
70 hr in 8 days Workday No 5/1/2016 5/9/2016 HOS 4200
04:30 4:30
14 hr workday Workday No 5/1/2016 5/1/2016 HOS 840
with break 04:30 18:30
30 min Hours of Break No 5/1/2016 5/1/2016 HOS 30
Service Break 07:30 15:30
min Break I Break No 5/1/2016 5/1/2016 CA 10
06:30 14:30 Breaks
10 min Break 2 Break No 5/1/2016 5/1/2016 CA 10
10:30 18:00 Breaks
30 min Lunch Break No 5/1/2016 5/1/2016 CA 30
Break 08:30 12:30 Breaks
[0106] Calls 10 - 12 result in no change because the driver did not
change regions;
therefore no new rules for time, as shown in TABLE 7.
-42-
7259508
Date Recue/Date Received 2022-02-07
TABLE 7
Rule Rule Satisfied Valid Period Valid Period Rule Value
Type Start End Family
70 hr in 8 days Workday No 5/1/2016 5/9/2016 HOS 4200
04:30 4:30
14 hr workday Workday No 5/1/2016 5/1/2016 HOS 840
with break 04:30 18:30
30 min Hours of Break No 5/1/2016 5/1/2016 HOS 30
Service Break 07:30 15:30
min Break 1 Break No 5/1/2016 5/1/2016 CA 10
06:30 14:30 Breaks
10 min Break 2 Break No 5/1/2016 5/1/2016 CA 10
10:30 18:00 Breaks
30 min Lunch Break No 5/1/2016 5/1/2016 CA 30
Break 08:30 12:30 Breaks
[0107] To illustrate an overlap example (steps 535-580), using TABLE 7 as
a final
ruleset for optimization, the first rule and second rule are used to begin as
shown in TABLE 8.
TABLE 8
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
70 hr in 8 days Workday No 5/1/2016 5/9/2016 HOS 4200
04:30 4:30
14 hr workday Workday No 5/1/2016 5/1/2016 HOS 840
with break 04:30 18:30
[0108] Since these rules are of the same type (Workday) and they cover
the same period,
they are evaluated together. Moreover, these rules are in the same family
(HOS). Both rules are
in the same family, so they can't overlap. Therefore, the 14 hour workday with
break may be put
back on the primary table. Add to that the recommendation (step 565) that the
driver has 61
-43-
7259508
Date Recue/Date Received 2022-02-07
hours and 3 minutes left to work in 8 days or before a 36-hour restart. Notice
the 70 hours in 8
days (see TABLE 8) is gone, as shown in TABLE 9.
TABLE 9
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
14 hr workday with Workday No 5/1/2016 5/1/2016 HOS 840
break 04:30 18:30
30 min Hours of Break No 5/1/2016 5/1/2016 30
Service Break 07:30 15:30
min Break I Break No 5/1/2016 5/1/2016 CA 10
06:30 14:30 Breaks
10 min Break 2 Break No 5/1/2016 5/1/2016 CA 10
10:30 18:00 Breaks
30 min Lunch Break No 5/1/2016 5/1/2016 CA 30
Break 08:30 12:30 Breaks
[0109] To review for Overlap, we would start with the next rule shown in
TABLE 10.
TABLE 10
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
14 hr workday with Workday No 5/1/2016 5/1/2016 HOS 840
break 04:30 18:30
[0110] There is no overlap as this is the only Workday rule. A
recommendation (step
565) may be added that the driver ends the workday at 18:30. Both of the
Workday rules are
now complete so they are no longer on the table, as shown in TABLE 11.
-44-
7259508
Date Recue/Date Received 2022-02-07
TABLE 11
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
30 min Hours of Break No 5/1/2016 5/1/2016 30
Service Break 07:30 15:30
min Break 1 Break No 5/1/2016 5/1/2016 CA 10
06:30 14:30 Breaks
10 min Break 2 Break No 5/1/2016 5/1/2016 CA 10
10:30 18:00 Breaks
30 min Lunch Break No 5/1/2016 5/1/2016 CA 30
Break 08:30 12:30 Breaks
[0111] To review for overlap (step 545), begin with the first rule and
moving forward,
referring to TABLE 11. Since these break rules are of the same type (Break)
and they cover the
same period they are evaluated together. Some of the rules are in the same
Family (CA Breaks)
(step 555). Since not all rules are in the same family, identify which rules
from the family fit
best. This may be done using the duration (step 575). Because both the "30 min
Hours of
Service Break" and the "30 min Lunch Break" are 30 minutes, the tool
recommends overlapping
these (step 560). Overlap rules may find rules with the highest minutes of
overlap in a case
where it is not as clear cut as being the same. A recommendation may be added
that the driver
take a 30 min break between now and 12:30 (step 565).
[0112] Both of the 30 minute breaks were taken care of last pass so they
are no longer on
the table, as shown in TABLE 12.
-45-
7259508
Date Recue/Date Received 2022-02-07
TABLE 12
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
min Break 1 Break No 5/1/2016 5/1/2016 CA 10
06:30 14:30 Breaks
10 min Break 2 Break No 5/1/2016 5/1/2016 CA 10
10:30 18:00 Breaks
[0113] To review again for Overlap, begin with the first two rules, as
shown in TABLE
12. These rules are of the same type (Break) and they cover the same period so
they may be
evaluated together. The rules are in the same Family (CA Breaks) (step 555).
Both rules are in
the same family, so they can't overlap (step 570). Add a recommendation that
the driver has to
take a 10 min break between now and 14:30 (step 565).
[0114] Since both of the 30 minute breaks were taken care of last pass they
are no longer
on the table, as shown in TABLE 13.
TABLE 13
Rule Rule Satisfied Valid Valid Rule Value
Type Period Start Period End Family
10 min Break 2 Break No 5/1/2016 5/1/2016 CA 10
10:30 18:00 Breaks
[0115] To review Overlap (step 545), we would start with the next rule, as
shown in
TABLE 13.
[0116] There is no overlap as this is the last rule on the table. Add a
recommendation
that the driver has to take a 10 min break between now and 18:00.
[0117] Based on the above example, the driver could receive five messages:
-46-
7259508
Date Recue/Date Received 2022-02-07
= You have 61 hours and 3 min left to work in 8 days or before a required
36-hour
restart.
= Your workday must end before 18:30.
= You need to take a 30 min break between now and 12:30.
= You need to take a 10 min break between now and 14:30.
= You need to take a 10 min break between now and 18:00.
[0118] The compliance module 252 is an application that works with the
rules engine
240 to ensure a user associated with a mobile unit 105a-105c is in compliance
with the rules that
must be followed based on their geographic position (current and historic). To
enable the user to
be compliant, the compliance module 252 is configured to provide information
about upcoming
rules to follow. The compliance module 252 may be configured to provide the
user a warning or
alert based on a configured time period that they may soon be out of
compliance.
= Example: workday must end in the next 30 min or will be out of compliance
with
company policy on overtime.
[0119] The compliance module 252 may be configured to notify the end user
and have
the ability to notify a third party that the user is operating out of
compliance.
= Example: FMCSA regulation states that a driver must take a 30 min break
before
starting the 7th hour of driving. When the user enters their 7th hour, the
application will notify them that they are now out of compliance. The driver's
leader may receive a notification (e.g., a text, an email, or the like)
letting them
know that the driver is operating out of compliance.
[0120] The compliance module 252 may configure standardized reports for
the user to
review. For the transportation industry these reports may have specific
formatted reports that
meet FMCSA ELD Regulations.
-47-
7259508
Date Recue/Date Received 2022-02-07
= Example: A driver will be able to view their FMCSA Log activities for a
week in
the 5-line log format.
[0121] Moreover, a web application may be provided for users to create a
custom report
to show a user's compliance. Reports also can be created across multiple
users.
= Example: the leader can pull up a report of all times they were out of
compliance
in the last 6 months during our semi-annual performance review.
= Example: a compliance officer may pull up a report of all users who were
not in
compliance this week to share with individual leaders to ensure they take
corrective action.
[0122] The compliance engine uses Update Rules for Period 400 to leverage
the rules
engine 240. Based on an application configuration, every X mile(s) (default
may be 1 mile, but
is configurable) the rules builder may read the latitude (Lat), longitude
(Long) from the mobile
unit 105a-105c GPS 113a-113c. The rules builder may send the Lat, Long to the
rules engine
240. The rules engine 240 may determine if there are any changes to a user
associated with a
mobile device 105a-105c rules for period.
[0123] Fig. 6A is a flow diagram showing an example of a compliance
engine process to
maintain the rules that must be complied to, the process performed according
to principles of the
disclosure. At step 600, by configuration 266 and a programmable timer or
clock function 265 is
used to initiate how often the compliance module 252 should check the location
of a mobile unit
105a-105c. By default, the system 100 may make this call every 30 seconds. The
compliance
module 252 interacts with the GPS 113a-113c on the mobile unit 105a-105c.
Using the last GPS
position, and the obtained current position (step 605), calculate distance
traveled (step 610). A
configurable setting may be used to configure how often the compliance module
252 should
check the location of the mobile unit 105a-105c. Because this typically
requires a call to the
server 115, the more often it runs the more data may be used. By default, the
system 100 may
make this call every 1 mile, but is configurable. A step 615, a check may be
made to determine
7259508
Date Recue/Date Received 2022-02-07
if the distance from step 610 is greater than the configured distance. If the
determined distance is
less than the configured distance, exit the function at step 618. Otherwise,
at step 620, update
rules for period using the rules engine 240 using current user, Lat and Long
from step 605. This
may return any new rules for the period found based on the new geographic
position. At step
625, any new rules are saved to the rules for period database 206.
[0124] Fig. 6B is a flow diagram showing an example process for rule
monitoring and
notification, the process performed according to principles of the disclosure.
The process of Fig.
6B may be considered a sub-system for rule monitoring and notification. The
sub-system rules
monitor and notification of Fig. 6B may leverage the rules for period table of
the rules database
206 to determine what rules a user associated with mobile unit 105a-105c must
comply. For
rules types that directly impact the user's work, the sub-system rules monitor
and notification
sub-system may provide feedback to the user through the interface 1 14a-1 14c.
In some cases,
the sub-system of Fig. 6B may send notifications to someone other than the end
user to alert
them of an issue.
[0125] By configuration 266, rule monitoring and notification sub-system
provides an
ability to configure (step 640) how often to validate compliance and provide
feedback to the
user. By default, the system 100 may make this call every 5 seconds, but is
configurable. At
step 645, a query for the Rules for Period table may be made. The query only
returns rules that
have not yet been satisfied by a user activity (as indicated on the rules for
period table) and the
valid period has started. The query also only focuses on the rule types that a
user would need
notifications. At step 650, a sort first by type, then by valid period end may
be performed. This
allows a correct order of processing the rules. At step 655, a loop is created
to process all rules.
If the current timestamp (data & time) is later than the valid period end data
and time, proceed to
step 675 where an alert may be created to the user indicating that the event
is overdue.
Moreover, if the rule has back office communication set to true, at step 680 a
message may be
sent to the backend server to indicate the user is out of compliance. The
server may then notify
the interested parties in the manner they indicate (e.g., email, SMS, chat
bot, workflow alert, or
-49-
7259508
Date Recue/Date Received 2022-02-07
the like). At step 670, a countdown clock may be initiated or updated at the
user interface of
time until out of compliance.
[0126] If at step 655 the period is not past due, then at step 660 a
check is made whether
or not the rule is within a warning period. If not, then continue at step 670.
If the rule is within a
warning period, then at step 665 an alert may be created to warn the user that
an activity must
occur soon. This alert can include audio and visual information to notify the
user that they are
not in compliance with the rule. Because of different work configurations
(safety could be an
issue with some alert types if the user is driving), the notification type is
configurable by rule.
Using the notification Type Table, an audio file (if one exists) may be played
located at the path
indicated. The text may be displayed in the notification, and the image may be
displayed on the
screen, e.g., 114a-114c if an image path is provided. Processing may continue
at step 670.
[0127] An Activity is the actual record of "What has occurred" over a
period of time.
And activity may have a start time, end time, start location and end location.
Activities may
reflect Work Performed (Driving, stuck in Traffic, Loading, Unloading,
Waiting, Paperwork,
etc) and other items that need to be recorded for regulatory purposes
(Workday, Lunch Breaks,
Rest Breaks, 36-hour Restart, Sleeper, Off Duty).
= Activities reflect a start and end time.
o All activities have a duration that they occurred. To determine this
duration, the activities may be stamped with a start and end time.
= Activities reflect a start and end location Lat and Long to reflect where
the
activities occurred.
o All activities may have a location indicating where they occurred. To
determine this the activity may be stamped with a Lat and Long. As some
activities occur at a given location, the start and end location may be the
same.
-50-
7259508
Date Recue/Date Received 2022-02-07
= Activities can be hierarchal in their structure.
o Example: in the trucking industry, a driver must be in a specific hours
of
service state (e.g., driving, off duty, on duty, sleeping, personal
conveyance), these activities could be parents to activities such as loading,
unloading or stuck-in-traffic if further detail is needed. The stuck-in-
traffic could resolve the need to determine if a driver is earning at least
minimum wage every hour if they are paid by the mile.
= Activities can be added/ configured.
o If a company using the system 100 needs to track a new activity in
accordance to a rule or as an event for compensation or billing, these can
be added using the activity logger.
= Activates can be associated to rules. An activity may be associated to
more than
one rule, and more than one rule may be associated to an activity.
o Example: a company could create a break activity; and may associate that
activity to the break rule. This could be taken further to create a lunch
break activity that could be associated to only some breaks.
= Activities may be used to show compliance to rules.
o Example: in the trucking industry the set of activities (driving, off
duty,
on duty, sleeping, personal conveyance) would be created to satisfy
FCMSA Hours of Service Logging rules. By recording the time spent in
each of these activities, a driver's compliance to these regulations may be
demonstrated.
= Activities can be used to pay for work performed.
-51-
7259508
Date Recue/Date Received 2022-02-07
o Example: An organization could write extracts of activities and push them
to a compensation calculation tool to determine a portion or all of an
individual's pay. As an example, if a company needed to pay a driver for
time spent in traffic without moving, they could create a "stuck-in-traffic"
activity, then extract it and provide it to the compensation calculation tool
to pay the driver for that time.
= Activities can be used to invoice for work performed.
o Example: an organization could write extracts of activities and push them
to a billing tool to determine a portion or all of the charges for a customer.
As an example if an HVAC specialist spends 2.5 hours cleaning ducts, this
recorded activity can be sent to a billing system to generate the labor
portion of a customer's invoice.
= Specific user inputs of activities / events can be configured. These
actions /
events may be used to show compliance.
o Example: a user may input the start of a workday by pressing a "clock in"
button.
= A user may be notified of an expected input based on a rule
configuration.
o Example: 30 min after a user indicates that they are going to take their
30
min break, the user may be prompted to record the time they come off of
break.
= A portal may allow an individual with proper security to update
activities.
o Example: an individual left for the day 3 hours ago, and forgot to clock
out. The individual called and asked that their manager clock them out at
the correct time. This may be permitted based on rule configurations.
-52-
7259508
Date Recue/Date Received 2022-02-07
= Activities that are configured to allow edits can be further configured
to have an
edit approval process.
o Example: a manager updates an individual's time record to reflect the
time they left the office at the individual's request, however policy
requires the individual to acknowledge that change.
[0128] An Event is the actual record of something that happened. A key
difference
between activities and events is that an event is a specific time, where and
activity provides a
time and duration. Events are triggered by something external to the system
like the connection
to the truck. For Example: (Start Driving, Stop Driving, Engine On).
= Events may be created on its own based on key factors.
o Example: in the trucking example, a rule could be created to create a
start
driving event when the vehicle starts moving.
= Events may have an Event Type which is a reference object that contains
information to define events and their behavior.
= Events are primarily used to provide a way for external factors to assist
in
managing activities.
o Recording when a truck has started moving based on information found on
a controller area network (CAN) bus within the truck, and not the internal
GPS. An interface with the truck and the CAN bus may be provided to
determine when the truck is moving based on, e.g., the power-take-off
(PTO), speedometer, or odometer. These events may be used by the
activities application.
= An end user may update their activities to reflect actual events. This
ability may
be configured by rule to ensure compliance with policies and regulations.
-53-
7259508
Date Recue/Date Received 2022-02-07
o Example: a user took a break 4 hours ago and forgot to log it, they may
need to update their activities to indicate the break was taken.
o Example: a driver does not agree with the system's 100 recording driving
activity, and wants to update the record to reflect driving starting 30 min
later, however the rule has been configured to not allow an end user to
update this event to prevent log falsification.
[0129] An Activity Type is reference object that contains information to
define activities
and their behavior.
[0130] The activity type configurator 250 is a tool that may allow a user
to create, update
and remove activity types. Users may tie activities to the rules that they
satisfy. The activities
can also be configured to automatically be created based on time, location or
event, or based on
the same factors, a prompt to the user to log then may be issued. The
activities configurator 250
may leverage external tools to create the user interface for prompts. As the
back office works to
create the configurations, the configurations may be synced on a periodic
basis to the end user's
devices 110a-110c. The period of this integration can be set by the back
office though
configuration.
[0131] Fig. 7 is an example interface to describe an activity type
configurator
functionality, configured according to principles of the disclosure. The
activity type configurator
may include:
700 - Edit/ Delete Activity Type Screen may be used to search for
activity types. The user can select an activity to edit or delete. The
layout of this screen should include any data about the activity that
the user may want to have.
705 - Search Field(s) & Search Button, Create the ability for a user
to search for activities. Name or parent are the most likely search
-54-
7259508
Date Recue/Date Received 2022-02-07
fields, by joining activity type to rules, a search on activities
associated to specific rules can be performed.
710 -An edit feature. Clicking Edit may bring up the activity detail
in a screen that allows the user to edit the activity type record.
715 -A delete feature. Clicking Delete removes the record from
the database
725 - A cancel feature. Clicking Cancel may take the user back to
the mam screen.
730 -The "New Activity Type" Screen shows the key information
needed to make activities work.
735 -The "Activity Type Name" is the name of the activity type.
Note that this may be the name of all instances (activities) that a
user creates. The name is what is displayed to users, so it should
be named appropriately. Duplicates should be avoided when
creating names as this may create confusion for users.
740 -"Parent Activity Type" is an activity that this activity inherits
the rules it will satisfy from. If this activity will not satisfy all
rules that the parent will, don't use Parent. Parent may often be
left blank <None>.
745 - "User Can Edit" is a flag that indicates that an end user can
make changes to activities of this type after the fact.
750 - "Office Can Edit" is a flag that indicates that a back office
user (example: manager) can edit activities of this type.
-55-
7259508
Date Recue/Date Received 2022-02-07
755 - "User Days Edit Available" is the number of days after the
activity is created that the end user may be able to edit activities of
this type.
760 - "Office Days Edit Available" is the number of days after the
activity is created that a back office user (example: manager) may
be able to edit activities of this type.
765 - "User Approval Required" is a flag that indicates that an end
user must review and approve any changes made by a back office
user.
770 - "Office Approval Required" is a flag that indicates that a
back office user must review and approve any changes made by an
end user. 775 - "Connected Rules" indicates all rules that the
activity may satisfy. If activities are created for a reason other than
rules, like to record work that was done, they should not be tied to
a rule. An example of how this would be used is if an activity
named "Break" is created, it may be attached to the Hours of
Service 30 minute break rule, California 10 minute Break rule and
California lunch break rule. All activities of this type could then
be used to satisfy those rules provided they are for the correct
duration.
777 - When the user clicks the "Save" button, either a new activity
is created, or update an existing activity, depending on how the
user came to the page.
779 - The next set of information may be created for each Activity
Type, Rule combination. When all are processed, the application
may return to the main page.
-56-
7259508
Date Recue/Date Received 2022-02-07
781 - An activity prompt is a feature that can permits the
configuration of an end user prompt, or the automated creation of
and. By adding prompts to an activity, it works with the overall
activity configurator and displays a popup covering most of the
screen.
783 - "Prompt Time Before Required (minutes)" is the number of
minutes before an activity is due to be done that the application
creates a popup to the user or auto generates an activity.
785 - "Prompt Location Radius (miles)" is the radius of a circle
around a specific geocode (latitude/ longitude) that when that
radius is crossed, a popup to the user may be created or auto
generates an activity
787 - "Prompt Event Trigger" is a list of triggers that can be used
to trigger, a popup to the user may be created or auto generates an
activity. For the trucking industry, the connection to the truck is
leveraged to bring in events such as, e.g., wheels in motion.
789 - "Auto Create Activity" is a flag that, if yes, indicates that
when the time, location or event occurs, an activity is auto created
for the user.
791 - "Cut and Paste Prompt Code Here" is a text box in which the
user may paste all code for a popup. This may be injected into the
main page when the event occurs. This feature permits tailoring to
the end user's experience.
793 -Any HTML! Javascript tool can be used to create the code so
long as it permits the user to cut and paste it into the text box of
791.
-57-
7259508
Date Recue/Date Received 2022-02-07
795 - Save the current record.
797 - Skip this record. No prompts are needed for this rule/
activity type combo.
[0132] The activity logger 220 and editor 215 encompasses the tools which
create
activities, including start and finish times in which to measure compliance
against. As these
activities are configured to show breaks taken as well as specific work
performed, they can also
be used to feed compensation and billing systems to ensure accurate pay or
invoicing for work.
[0133] The Activity Logger 220 is a tool that may be used by a user
associated with a
mobile unit 105a-1 05c to log activities. The activity logger 220 is primarily
an API (Application
Program Interface) that may be accessed by prompts. Fig. 8A is an illustration
of functional
block diagram of an activity logger, configured according to principles.
[0134] In Fig. 8A, the functions include:
821 - Create Activity (see Fig. 8B for example flow diagram)
a. This provides the ability to create an activity. This method
may be used to create activities that are already complete.
b. If the log the activity is being created for does not permit
overlap, this method prevents the user from creating
overlapping activities.
c. As the activity is now created, Call Set Rules to Satisfied
816 - Start Activity (see Fig. 8C for example flow
digram)
a. This may create an incomplete activity and mark the
Current flag to True. Only one activity per Log can have
current flag set to True. If Start Activity is called and there
is a current activity, the application may return an error that
may be handled by the UI. Most common may be a
-58-
7259508
Date Recue/Date Received 2022-02-07
question "Do you want to complete your previous
activity?" However, based on the activity, each situation
can be scripted by the developer of the UI to provide the
best user experience.
b. If the log the activity is being created for does not permit
overlap, this method may throw an error that a future
activity has been recorded and must be changed before this
activity can be started.
c. This method may Create an activity using the current
information. It may require a Log and activity type to be
passed in.
d. It may set Start Time to the current timestamp
e. It may set the Start Lat and Long to the current GPS
location (provided the GPS is providing an accurate
position. Otherwise, it may wait for an accurate location or
request one from the user)
817 - End Activity (see Fig. 8D for an example flow diagram)
a. This method may complete the current activity by setting
the End time to current and End Lat and Long to the current
GPS location (provided the GPS is providing an accurate
position.
Otherwise, it may wait for an accurate location or request one from
the user).
b. It may set the current flag to False
c. As the activity is now created, Call Set Rules to Satisfied
826 - Search Activity (see Fig. 8E for an example flow
diagram)
-59-
7259508
Date Recue/Date Received 2022-02-07
a. This is a method that may find all Activities that match a
set of parameters provided by the user. The result may be
returned as complete Activity Objects.
b. Search Activity may also be callable as a web service from
other applications. This is expected to be used to pass
activities that are compensable and/or billable activities as a
part of the users work process to external systems.
831 - Update Activity (see Fig. 8F for an example flow
diagram)
a. This method may update the activity
b. If the log the activity is being created for does not permit
overlap, this method may prevent the user from creating
overlapping activities.
c. After the update, Call Remove Satisfied and Set Rules to
Satisfied.
832 - Delete Activity (see Fig. 8G for an example flow
diagram)
a. This method may Delete the activity
b. Call Remove Satisfied
840 - Set Rules to Satisfied (Activity) (see Fig. 8H for an example
flow diagram)
a. This method may find and update all rules that are satisfied
by a new or updated activity.
845 - Remove Satisfied (Activity) (see Fig. 81 for an example flow
diagram)
-60-
7259508
Date Recue/Date Received 2022-02-07
a. This rule may identify any rules that need to have the
satisfied flag removed. After the flag is removed, on an
update, the application may attempt to rematch rules.
850 - Manage Approvals (see Fig. 8J for an example flow diagram)
a. Identify who needs to be notified
b. Notify the correct users based on their desired method
i. Email
ii. SMS
iii. Activity Popup Prompt (see Activity Configurator #24)
[May create event]
iv. Web Client Application (Your notifications) [See Activity Editor]
805 - Get Event (see Fig. 8K for an example flow diagram)
a. Get event is a function that leverages the event
functionality. It is
a query to the Event Table to identify if a specific event occurred.
836 - Approve Activity (List of Activities) (see Fig. 8L for an
example flow diagram)
a. This may allow a user to approve one or more
activities. It may
accept a list of activities to provide the developers of interfaces the
ability to have an "Approve All" feature.
837 -Disapprove Activity (List of Activities) (see Fig. 8M for
an example flow diagram)
-61-
7259508
Date Recue/Date Received 2022-02-07
a. This may allow a user to disapprove one or more
activities. It may
accept a list of activities to provide the developers of interfaces the
ability to have an "Approve All" feature.
800 -Location Prompt Helper (Lat, Long, Radius) (see Fig. 8N for
an example flow diagram)
a. This simple function takes a Target Lat, Long and mile radius as
parameters.
b. It then leverages the GPS to determine current Lat, Long.
c. It may return one if the current location is in the radius
d. It may return zero if the current location is outside the radius
e. It may return nine if the GPS accuracy is poor
838 - Get GeoCode (Location Name) (see Fig. 80 for an example
flow diagram)
a. This function may return Null if the service is down. It may make
a call to a Geocoding service (Example: Google Maps)
b. If the function is available, the application may return the Geo
Code for the location found, or a request for more information if
more than one location is found.
[0135] Fig. 8B is a flow diagram showing an example process for a create
activity,
performed according to principles of the disclosure, starting at step 850.
This flow corresponds
to the create activity function 821 shown in Fig. 8A. At step 855, a check is
made to determine
if a user has permission to create an activity. If the user does not have
permission, then at step
875, an error code may be returned. If the user does have permission, then at
step 860 a check is
-62-
7259508
Date Recue/Date Received 2022-02-07
made to determine if the log permits overlap. If so, then the process
continues at step 880. If
not, then at step 865, a query may be made for existing activities with an
overlapping start and
end date. At step 870, a check may be made to determine if there are any
conflicts found. If
there are conflicts, an error code may be returned. Otherwise, if no conflicts
are found, then at
step 880 an activity may be created. At step 840, the rule or rules may be set
to satisfy. At step
850, a check is made to determine if the activity requires approval. If not,
then the process
completes at step 897. If the activity requires approval, then at step 875
approvals are managed
and obtained. At step 897, the process may end.
[0136] Fig. 8C is a flow diagram showing an example process for a start
activity,
performed according to principles of the disclosure, starting at step 900.
This flow corresponds
to the start activity function 816 shown in Fig. 8A. At step 902, a check may
be made to
determine if the user has permission to create activity. If not, then an error
code may be returned
at step 912. If the user does have permission, then at step 904, a check may
be made to see if
there is current activity in the log. If not, then at step 905 a return error
code of "Only 1 Current
Activity Allowed" indicating there is already a current activity in the log
may be set and the
process may complete at step 930.
[0137] However, if there is no current activity at step 904, then at step
906 a check may
be made to determine if the log allows overlap. If so, then processing
continues at step 914. If
overlap is not permitted, then at step 908 a query may be made for existing
activities with
overlapping start and end times. At step 910, a check may be made to determine
if any conflicts
are found. If yes, then return an error code at step 912. If, however, there
are no conflicts found
at step 910, then at step 914 a check may be made to determine if a location
was provided with
this request. If not, then at step 918 a current location of the mobile units
105a-105c may be
determined using GPS 1 13a-1 13c. Processing may continue at step 920. If at
step 914, a current
location was passed into this function, then at step 916, the current time may
be acquired from a
clock 265. At step 920, a check may be made to determine if the GPS data is
accurate. If the
GPS data is deemed not accurate, one or more attempts to acquire accurate GPS
data may be
attempted at step 924. If the GPS data is deemed accurate then processing
continues at step 922,
-63-
7259508
Date Recue/Date Received 2022-02-07
otherwise if the GPS data is deemed not accurate an error code may be set at
step 228 and the
process may complete at step 930. If the GPS data is deemed accurate at step
922, then an
activity may be created with current location and time. The process may
complete at step 930.
[0138] Fig. 8D is a flow diagram showing an example process for an end
activity,
performed according to principles of disclosure, starting at step 932. This
flow corresponds to the
end activity function 817 shown in Fig. 8A. At step 934 a check is made to
determine if a user
has permissions to create an activity. If not, then an error code may be
returned at step 946. If the
user has permissions, then at step 936 a check may be made if there is a
current activity in the
log. If not, then at step 938 a no current activity error code may be
returned. However, if there is
a current activity at step 936, then at step 940 a check may be made to
determine if the log
allows overlap. If so, then processing continues at step 948. If overlap is
not permitted, then at
step 942 a query may be made for existing activities with overlapping starting
and end times. At
step 944, a check may be made to determine if any conflicts are found. If yes,
then return an
error code at step 946. If, however, there are no conflicts found at step 944,
then at step 948 a
check may be made to determine if a location was provided with this request.
If not, then at step
952 a current location of the mobile units 105a-105c may be determined using
GPS 113a-113c.
Processing may continue at step 956. If at step 948, a current location was
passed into this
function, then at step 950, the current time may be acquired from a clock 265.
At step 954, a
check may be made to determine if the GPS data is accurate. If the GPS data is
deemed not to be
accurate, one or more attempts to acquire accurate GPS data may be attempted
at step 956. If the
GPS data is deemed accurate at step 958, then processing continues at step
962; otherwise, if the
GPS data is deemed not to be accurate at step 958, an error code may be set at
step 960 and the
process may complete at step 968. If the GPS data is deemed accurate at step
962, then an
activity may be created with current location and time. The rules may be
satisfied at step 840.
The process may complete at step 930.
[0139] Fig. 8E is a flow diagram showing an example process for a search
activity,
performed according to principles of the disclosure, starting at step 1270.
This flow corresponds
to the search activity function 826 shown in Fig. 8A. At step 1272 using
criteria provided, locate
-64-
7259508
Date Recue/Date Received 2022-02-07
all activities that match. At step 1274, for each log activity, a check is
made to determine if the
user has permission to view the log. If not, then no activity is added to the
result. If the user
does have permission, then at step 1278, the activity or activities may be
added to the result. At
step 1282, a check is made to determine if there are more activities in the
search result. If there
are, processing continues at step 1276. If not, the process completes at step
284 returning the
result.
[0140] Fig. 8F is a flow diagram showing an example process for an update
activity,
performed according to principles of the disclosure, starting at step 1300.
This flow corresponds
to the update activity function 831 shown in Fig. 8A. At step 1302 a check may
be made to
determine if the user has permission to update activity. If not, then an error
may be returned at
step 1310. If the user has permission, then at step 1304 a check may be made
to determine if the
log allows overlap. If not, then at step 1306 a query for existing activities
may be made with
overlapping start and end points. At step 1308, a check may be made to
determine if any
conflicts are found. If there are any conflicts, then at step 1310 an error
result may be returned.
If, however, there are no conflicts at step 1308, then processing continues at
step 1314. If at step
1304, the log allows overlap, then at step 1314 a check may be made to
determine if the update
requires approval. If not, then at step 1322 the activity may be updated, and
processing
continues at step 1324. If at step 1314, the update requires approval, then at
step 1316, a new
activity may be created with information for the update. At step 1318, update
existing activity
with a new ID in pending approval field. At step 850, the approval is managed.
At step 845
satisfied may be removed for the activity. At step 840, the rules may be set
to satisfy. At step
1312 the process may complete.
[0141] Fig. 8G is a flow diagram showing an example process for a delete
activity,
performed according to principles of the disclosure, starting at step 1330.
This flow corresponds
to the delete activity function 832 shown in Fig. 8A. At step 1332 a check is
made to determine
if the user has permission to update activity. If not, then an error may be
returned at step 1344.
If the user has permission, then at step 1334 a check may be made to determine
if the delete
requires approval. If not, then at step 1340 the activity may be deleted. If,
however, approval is
-65-
7259508
Date Recue/Date Received 2022-02-07
required, then at step 1336 update to the existing activity is marked by a "0"
indicating pending
approval for deletion. At step 850 the approval for deletion is managed. At
step 845, the
removal may be satisfied, the activity effectively deleted. The process ends
at step 1346.
[0142] Fig. 8H is a flow diagram showing an example process for set rules
to satisfied,
performed according to principles of the disclosure, starting at step 1350.
This flow corresponds
to the set rules to satisfied function 840 shown in Fig. 8A. Every time an
activity is created or
updated, this function may be called. The remove satisfied function (Fig. 81)
should be called
before this set rules to satisfied function for every update. At step 1352,
all rules that apply are
obtained. This may include a query for rules for period where a valid start is
before activity
start; a valid end is after activity start and through join, the rules should
be associated to this
activity type. Rules should not already be marked satisfied. At step 1354 a
check may be made
to determine whether or not any rules were found. If not, then at optional
step 1360 there is
nothing to do and the process returns at step 1370. If there is at least one
rule found, then at step
1356 a check is made to determine if more than one rule was found. If no, then
at step 1358 for
the rule found set satisfied flag to yes. The process completes at step 370.
If at step 1356, more
than one rule was found, then at step 1362 a check may be made to determine if
any of the rules
are in the same family. If not, then at step 1364 the satisfied flag may be
set to yes for all rules
found, and the process completes at step 1370. If at step 1362 there are rules
in the same family,
then at step 1366 the satisfied flag may be set for all rules not in the same
family. At step 1368,
for each family set found, locate the rule with the longest duration in the
respective family and
set the satisfied flag to yes. The process ends at step 1370.
[0143] Fig. 81 is a flow diagram showing an example process for remove
satisfied,
performed according to principles of the disclosure starting at step 1372.
This flow corresponds
to the remove satisfied function 845 shown in Fig. 8A. Every time an activity
is created or
updated, this function may be called. At step 1374, all rules with the
Activity may be obtained
which may include querying for rules with that Activity from the rules for
period. At step 1376 a
check may be made to determine if the activity was deleted. If yes, then at
step 1378 satisfied
may be set to no and update Activity on all rules to null. At step 1380, all
activities that could
-66-
7259508
Date Recue/Date Received 2022-02-07
satisfy the rule are obtained. At step 1382, a check may be made to determine
if any activities
were found. If not, processing continues at step 1394. If an activity was
found, then at step 1382
all rules having the Activity may be extracted. At step 1386, a check may be
made to determine
whether or not the extracted rule is in the same family as this rule. If yes,
then at step 1388 a
check is made to determine if there are more activities. If yes then
processing continues at step
1384, if not, then processing continues at step 1394. If at step 1386, the
rule is not in the same
family as this rule, then at step 1390 the rule is updated to satisfied and
Activity may be updated.
Processing continues at step 1394.
[0144] If at step 1376 the activity was determined not to be deleted,
then at step 1377 for
each rule, compare the rule with the updated activity. At step 1392, a check
may be made to
determine if the activity still satisfies the rule. If not, the processing
continues at step 1378.
However, if the activity still satisfies the rule, then at step 1394 a check
may be made to
determine if all rules have been evaluated. If not, then processing continues
at step 1377 with
the next rule. If all rules have been evaluated, then at step 1396, the
process may end.
[0145] Fig. 8J is a flow diagram showing an example process for manage
approval
performed according to principles of the disclosure, starting at step 1400.
This flow corresponds
to the manage approvals function 850 shown in Fig. 8A. At step 1402 obtain
users selected
preferred notification mode, for sending notifications to the user's device
110a, or user interface
114a. At step 404, a check is made to determine whether or not the user wants
a pop-up prompt.
If yes, then at step 1406 an event may be created with type "approval
required." At step 1420
the process end. If no at step 1404, then at step 1410 a check is made to
determine if the user
wants email notification. If yes, then at step 1412 an email may be prepared
and sent such as via,
e.g., simple mail transport protocol (SMTP), and processing continues at step
1414. If no at step
1416, then at step 1418 may want web notification, the notification may be
saved in the web
notifications table at step 1414 for eventual display to the user on, e.g.,
user interface 114a.
Alternatively, if the user elected for no notifications, the process ends at
step 1420
-67-
7259508
Date Recue/Date Received 2022-02-07
[0146] Fig. 8K is a flow diagram showing an example process for get event
performed
according to principles of the disclosure, starting at step 1416. This flow
corresponds to the get
event function 805 shown in Fig. 8A. At step 1418 the events database 225 may
be queried to
retrieve events that have not yet been reported. Reported acts is a control to
ensure that events
are only reported one time, preventing duplicate activities or prompts being
provided to the user.
At step 1420 a check is made to determine if an event has been found with the
event type. If yes,
then set reported to true for events and return event(s). At step 1426 the
process ends.
[0147] Fig. 8L is a flow diagram showing an example process for approve
activity
performed according to principles of the disclosure, starting at step 1428. As
an action may be
approved or disapproved by a user at a later time, the state of the activity
for approval could be
stored with an "Approval ID". The Approval ID could indicate 3 possible
states. If the
Approval ID is 0, the user is approving a delete, if the Approval ID is the
same as the Activity
ID, then the user is approving a create, lastly if the Approval ID is the ID
of another activity, this
is an update. This flow corresponds to the approve activity function 836 shown
in Fig. 8A. At
step 1430, for all activities provided as parameters, at step 1432 a check is
made to determine if
the user has permission to approve the activity. If not, at step 1446 an error
is returned and the
process completes at step 1448. If the user does have permission, then at step
1434 a check may
be made to determine whether the Approval ID is zero. If yes, then at step
1442, the activity
may be deleted and the process continues at step 1444. If, however, the
Approval ID is not zero,
then at step 1436 a check may be made to determine whether or not the Approval
ID is the same
as the Activity ID. If the Approval ID is not the same as the Activity ID,
then the activity with
the ID equal to the pending Approval ID may be deleted. Processing continues
at step 1440.
Otherwise, if the approval ID is the same as the Activity ID, then at step
1440 the pending
Approval ID is removed. At step 1448 the process ends.
[0148] Fig. 8M is a flow diagram showing an example process for
disapprove activity
performed according to principles of the disclosure, starting at step 1450. As
an action may be
approved or disapproved by a user at a later time, the state of the activity
for approval could be
stored with an "Approval ID". The Approval ID could indicate 3 possible
states. If the
-68-
7259508
Date Recue/Date Received 2022-02-07
Approval ID is 0, the user is approving a delete, if the Approval ID is the
same as the Activity
ID, then the user is approving a create, lastly if the Approval ID is the ID
of another activity, this
is an update. This flow corresponds to the Disapprove activity function 837
shown in Fig. 8A.
At step 452, control is established to process all activities provided. At
step 1454 a check may
be made to determine whether or not the user has permission to approve an
activity. If not, an
error may be returned at step 1462. If the user has permission, then at step
1456 a check may be
made to determine whether or not the Approval ID is zero. If not 0, then the
activity should be
deleted as it represents an unapproved create or updated activity, processing
continues at step
1464. If the Approval ID is zero, then the pending Approval ID is removed to
reflect the
unapproved delete of the activity. At step 1464 a check may be made to see if
there are more
activities. If so, then processing continues at step 1454 for the next
activity. If not, then
processing ends at step 1466.
[0149] Fig. 8N is a flow diagram showing an example process for a
location prompt
helper performed according to principles of the disclosure starting at step
1468. The location
prompt may be used to compare the position of a mobile unit 105a-105c and
another location.
The process would determine if the mobile unit is within a specific configured
distance, which
could be done using the Haversine formula or other geographic distance formula
to determine if
a point falls within a radius of another point. This flow corresponds to the
location prompt
helper function 800 shown in Fig. 8A. At step 1470, the current location of
the mobile unit
105a-105c may be obtained using GPS 1 13a-1 13c. A check may be made at step
1472 to
determine if the GPS data is accurate. If not accurate, then at step 1474
retries may be attempted
to acquire accurate GPS data. If the GPS data is deemed accurate at step 1472
or step 1476, then
at step 1480 the Haversine formula may be used to determine if the GPS point
falls inside the
radius of a given location. If not, then at step 1486 false may be returned.
If within radius, a true
may be returned, the process ends at step 1486.
[0150] Fig. 80 is a flow diagram showing an example process for a get
geocode
performed according to principles of the disclosure, starting at step 1488.
This flow corresponds
to the get geocode function 838 shown in Fig. 8A. At step 1490, a check may be
made to
-69-
7259508
Date Recue/Date Received 2022-02-07
determine whether or not a network link 130 is available. If not, an error is
returned at step 1492
and processing ends at step 1499. If a network link 130 is available, then a
GIS service may be
called at step 1494 providing a name of a location, e.g., an address, a city,
a county or a zip code.
At step 1496, a check may be made to determine if a single point geocode was
returned. If not,
an error may be returned indicating more information required. The process may
end at step
1499.
[0151]
Fig. 9 is a functional block diagram of an event API 232 to provide an example
of
how an activity such as Drive Time Start Event could be processed to manage an
activity. This
Figure shows how a vehicle 112a could interact with a mobile device 135
including a set of
methods to permit an external system 1600 to interact with an activity engine
1611 of Mobile
Device 135, configured according to principles of the disclosure. The external
system 1600 may
be a separate platform for a transportation company or other entity for which
logging, tracking
and services provided by system 100 is desired, or may be a Vehicle 112a -
112c. In this
example, a vehicle 1 12a-1 12c which may be equipped with onboard monitoring
electronics 1602
which may include a CAN bus that may sense and provide real-time information
related to the
status and state of the vehicle 1 12a-1 12c that may sense the PTO engaged
with a speedometer
indicating a speed greater than zero and the odometer may be changing. This
information or the
like may be communicated to the respective computing device 110a-110c. At step
1605 the on-
board monitoring electronics has detected that the vehicle has switched to a
drive state. The
onboard control logic, may be interpreted by a broadband router 121 or other
device, which
could then call "publish event" with a "drive time start" event at step 1610
using event API 232
which creates a "drive time start event" at step 1615 for entry into event
table 225. An event
listener 1620 may query the event table 225 for an event on a predetermined
schedule, such as,
e.g., every 1, 5 or 10 secs, or other configurable time period. Once the event
listener 1620
discovers an event, the methods in the Activity Engine 1561 may be called to
find out what to do
with the event. At step 1625, a check may be made to determine if an event
occurred. If not, the
event listener 1620 continues to query for an event. If an event has occurred,
at step 1630 a
search for prompt for the event type may be initiated using a prompt user
table 1514. At step
-70-
7259508
Date Recue/Date Received 2022-02-07
1635, a check may be made to determine if a prompt was found for the event
type. If not, the
event listener 1620 continues to query for an event. If found, at step 1640
the prompt for start
driving may be retrieved from the prompt user action table 1514. A check may
be made to
determine if this is an auto create activity at step 1645. If yes, then at
step 1650 a check may be
made to determine if this is a start of event. If yes, then call activity
start function 816, which
updates the activity table 235. If not a start of event then call activity end
817, which updates the
activity table 235. If at step 1645 it was determined that this is not an auto
create activity, then at
step 1654 a screen pop-up may be created for the user interface. At step 1658,
the action
(created in 791) from the prompt table may be used to create the pop-up
content, which may be
returned to the computing device 110a-110c. The process may continue as the
event listener
continues to scan the event table 225 for a new event.
[0152] In the example of Fig. 9, the event API 232 may create a new Event
with the
following example information (note the Event Type should already exist).
TABLE 14
illustrates an event type table. TABLE 15 illustrates an event table.
TABLE 14
Event Type Table
Event Type ID Name
543 Drive Time Start
TABLE 15
Event Table
Event ID Event Type ID Event Time Activity ID Event Reported
101 543 8/22/2016 <null> False
14:06:00
[0153] In Table 15, Event ID is a system generated number. Event Type ID
may be
looked up based on the name provided to create. Event Time is a time stamp. If
the time is
provided by the calling application, that time is used. If none is provided,
the timestamp is the
current time. Activity ID may be populated after an activity is created. Event
Reported is set to
false to indicate to the event listener 1620 that this event has not yet been
found.
-71-
7259508
Date Recue/Date Received 2022-02-07
[0154] When the activity engine 1611 finds an event, it sets Event
Reported to True, this
is shown below in TABLE 16.
TABLE 16
Event Table
Event ID Event Type ID Event Time Activity ID
Event Reported
101 543 8/22/2016 <null> True
14:06:00
[0155] The Activity Engine 1611 may search the prompt user action table
1514 for an
Event Type. TABLE 17 illustrates an example of the prompt user action table
1514. An
example of a record is shown below. The Activity Name is Driving. Auto create
is true.
TABLE 17
Prompt User Action
Rule Id Action Prompt Prompt Event Auto Is Activity
Time Location Type Create Start Type
Minutes Miles ID Activity Event ID
947 <null> <null> <null> 543 True True 2
Activity Type
Activity Parent Act'ty User User Office Office User
Office Log
Type Id ID Name Can Edit Edit Can Edit Approv Approv. Type
Days Edit Days Req'd Req'd Id
2 <null> Driving True 90 True 365 True False 33
[0156] Events can start or end an activity. In this example this is a
start event so it may
be used to create an activity. This is accomplished by calling Activity Create
816 in the Activity
Logger API. An activity may be created that looks like that looks like TABLE
18.
TABLE 18
Activity Table
Activity ID Log ID Activity Type Start Time End Time User
Version
ID Created
325 888 2 8/22/2016 <null> False 1
14:06:00
Activity Table (Continued)
-72-
7259508
Date Recue/Date Received 2022-02-07
Approved Start Lat Start Long End Lat End Long Current Pending
Approval
ID
True 40.784405 -73.9856644 <null> <null> True <null>
i. Activity ID may be a random number
ii. Log ID may be the user's log that matches the Log Type in
the Activity Log Type (33)
iii. Activity Type ID is the ID of the type of activity that is
being created. In this example that is 2 (Driving) as seen in the
Activity Type table above.
iv. Start Time: the timestamp is used on the event shown
above.
v. End Time: As this activity is not completed, just being
started the end time is null. Note, this is not a valid activity until
this ends.
vi. User Created: This was created by the system not the user
or by the back office.
vii. Version: The activity may show version 1 to indicate that
it has not been changed.
viii. Approved: drivers not expected to approve automated
action.
ix. Start Lat & Long: These are the Lat & Long of the position
at time Start Activity was called.
-73-
7259508
Date Recue/Date Received 2022-02-07
x. End Lat & Long: These are null as we have not ended the
activity yet.
xi. Current: As this is the Current Activity (can only have 1 at
a time per log), set it to True.
[0157] xii. Pending Approval: The activity doesn't need to be approved
so this is set
to <null>.The system 100 may also record driver data including identification
data and
authentication data. In this way a historical record of the driver may be
maintained. The record
may include which mobile units were driven by the driver, geographic route,
date, times and
duration of driver activity. The record may comprise an aggregated historical
record to
consolidate a driver's history over multiple mobile units. Driver activity may
be maintained in a
central database and may be collected via satellite or wireless communication
link. A driver's
recorded historical activities may also be employed to compute billing, pay,
and taxes.
[0158] This system provides a geographic regulatory compliance toolset to
manage a
mobile workforce. By leveraging the power of a Global Positioning System and a
Geographic
Information System, our tool provides a powerful geographic business rules
engine to use real-
time location tracking to determine specific regulations and policies that a
mobile user must
comply with. The system combines expected user tasks, route, optimized break
plan and user
input to develop an organized plan that will be managed though a common view,
that clearly
depicts all activities expected of the user. Workday plans are fluid and can
be updated by end
users or back office to ensure clear communication of expectations.
[0159] The system and methods according to principles of this disclosure
may include
compliance management processes to increase organizational compliance to
regulations and
policies, which may include notifications to a user of upcoming actions
required to improve
personnel compliance with jurisdictional regulations and company policies.
Multiple
notification methods may be provided, including methods that provide a safe
experience for a
driver. The system and methods according to principles of this disclosure may
notify a user and
-74-
7259508
Date Recue/Date Received 2022-02-07
others of real-time compliance issues in order that the situation may be
managed, rectified, or
dealt with as they occur or before they occur.
[0160] The optimizer according to principles of this disclosure maximizes
workforce
productivity by recommending, e.g., optimal time blocks to take a breaks based
on the driver
current previous, current and future locations and the regulations and
associated policies. The
optimizer integrates a work plan to provide a singular experience for a user
to manage and track
their day
[0161] The system according to principles of this disclosure includes
standard inputs to
create events and activities. To reduce the need for end user data entry,
events provide a way to
assist or automate activity creation. Standard event processing for geo-
position is provided
using a GPS device to provide the ability to create an event based on the
user's current physical
location. Another standard event generator may originate from a vehicle
connection with key
event interpretation and management. The system may also include a standard
method to
connect to external inputs for expanded capability.
[0162] In one aspect, according to principles of this disclosure, an
activity management
system may provide a centralized record of activities for a multiplicity of
users, and related
regulations to maintain regulatory compliance verification. The activity
management system
may simplify compensation and maximize billing processes by using individuals'
activities
extracted from the centralized records, such as a database.
[0163] In one aspect, the system and methods according to principles of
this disclosure
system may provide maximum flexibility by providing a simple configuration
process for rules,
activities and events. Configurations may be sent to end user devices without
requiring software
updates or installs to simplify and expedite the process of rolling out.
[0164] Activity Types, Event Types and Rules can be created, updated and
deleted on a
server, and passed to one or more mobile units. Upon receiving these changes,
the end user
application at the one or more mobile units can enforce new rules, permit new
activity types and
-75-
7259508
Date Recue/Date Received 2022-02-07
automate or prompt new actions, based on events. The operation of the
application at the mobile
unit may be dynamically modified by these changes, providing a dynamic nature
of its
configuration, while keeping foundational abilities as described herein.
[0165] The system configured according to principles of the disclosure
may employ
several transactional elements that may be dynamically used to create and
monitor rules,
activities, and events to provide a record of what was required, and what was
done. Beyond
recording, the system configured according to principles of the disclosure may
use this
information to provide feedback to a user to enable the user to improve
performance. To do this,
rules that need to be complied with may be dynamically identified from the set
of configured
rules, based on a user's role, and location. These rules may be assigned a
time period in which
the rules need to be enforced based on when the user entered that location.
The system
configured according to principles of the disclosure may also include events,
which are moments
in time that something occurred; these events may be trigged by, e.g., time,
location, server
communication, or a vehicle. The events may be used to create activities, and
as the activates are
created, activities are applied to the rule set to which a user must comply,
to show compliance as
it occurs.
[0166] In some embodiments, it may be desirable to have tasks performed
by a user (e.g.,
driver) operating the mobile unit based on customer preferences or other
configurable actions.
These tasks may be referred to as "dynamic tasks" and may be in addition to
the tasks (e.g., work
shifts, breaks, etc.) being performed by the user as discussed above in FIGS.
1-9. To generate
dynamic tasks for the user to complete, in some embodiments, the rules engine
240 may define
rules based on the customer preferences or the other configurable actions.
These rules may be
associated with one or more tasks or activities that the user may be required
to complete. In
some embodiments, a compilation of these dynamic tasks may be considered a
"dynamic task
list." The dynamic task list or the compilation of tasks that the user needs
to perform may be
injected into an existing workflow or workplan of the user resulting in a
dynamic task injection.
The compliance module 252 may receive input (e.g., activities) from the user
and determine
compliance of rules, as discussed above.
-76-
7259508
Date Recue/Date Received 2022-02-07
[0167] Referring now to FIG. 10, an example flow diagram outlining the
operations of a
process 1660 is shown, in accordance with some embodiments of the present
disclosure. In
some embodiments, the process 1660 may be implemented by the server 115 to
generate a
dynamic task list for a user (e.g., driver) based on a specific customer
preference, inject the
dynamic task list into a workflow of the user, and monitor for compliance with
the specific
customer preference. In some embodiments, a particular customer may have
certain preferences
(e.g., requirements, conditions, instructions, and/or tasks) that the customer
may desire the user
(e.g., driver) to follow or implement. For example, in some embodiments, a
customer may
request that the user notify the customer when the user is en route and within
a predetermined
distance (e.g., 50 miles) of the customer's delivery/pickup location. Another
customer may
desire the user to postpone or prepone pick-up or delivery by a certain amount
of time. Yet
another customer may desire that the user unload the cargo in a certain manner
or order, that the
user follow specific delivery instructions (e.g. "no contact delivery", "bring
to second dock", "do
not ring doorbell", "notify when you arrive" etc.), and so on. Thus, different
customers may
have different customer preferences that the user may be requested to follow.
[0168] To ensure compliance with a customer preference of a particular
customer, in
some embodiments, a dynamic task list may be generated for that particular
customer. The
dynamic task list may include one or more tasks for the user (e.g., driver) to
complete to comply
with the customer preference. Without the dynamic task list, the customer
preference may need
to be communicated through a telephone call, word of mouth, or another manual
mechanism
directly from the customer to the user or from the customer to another
personnel who would then
need to contact the user. Compliance of the customer preference in such cases
may be
contingent upon the customer successfully conveying the customer preference to
the user, and
upon the user to remember the specific customer preference and comply with
them. Such a
method may be undesirable due to potential for miscommunication and confusion,
as well as
tasks not being completed to the satisfaction of all parties involved. The
dynamic task injection
avoids the downsides mentioned above.
-77-
7259508
Date Recue/Date Received 2022-02-07
[0169] Further, in some embodiments, a particular customer may have a
single location
or multiple locations. In some embodiments, the particular customer may have a
customer
preference that applies to all locations of that customer, while in other
embodiments, the
particular customer may have separate customer preferences for one or more
locations. The
dynamic task injection and the process 1660 may be used for implementing
customer preferences
for a single location or for multiple locations. To generate the dynamic task
list, upon starting at
operation 1665, the identity of the customer is determined at operation 1670.
[0170] Specifically, as discussed above, different customers may have
different customer
preferences. Thus, to generate a dynamic task list that is tailored for a
particular customer
preference of a particular customer, the identity of that particular customer
needs to be known.
The identity of the customer may be determined in different ways. For example,
in some
embodiments, the customer identity may be determined by the current location
of the mobile unit
105a-105c (e.g., based on data received from the GPS 113a-113c or the GIS tool
280, or broken
geofences). For example, if the current location of the mobile unit 105a-105c
indicates that the
mobile unit is in Plano, TX, the server 115 may identify which customers are
located in Plano,
TX. If there is a single customer in Plano, TX, the server 115 may identify
the identity of that
single customer. If there are multiple customers in the current location of
the mobile unit 105a-
105c, in some embodiments, the server 115 may use other or additional ways to
confirm the
identity of the customer.
[0171] In some embodiments, the server 115 may determine the customer
identity based
upon origin-destination pairs for the current route of the mobile unit 115a-
115c. For example, in
some embodiments, the server 115 may identify all customers between, and
including, the origin
(e.g., where the mobile unit 115a-115c is starting from) and the destination
(e.g., where the
mobile unit is headed to). If there are multiple customers between a
particular origin-destination
pair, the server 115 may use other or additional ways to confirm the identity
of the customer. In
some embodiments, the server 115 may identify the customer identity from order
details of a
particular order. In some embodiments, the order details may be accessible to
the server. From
the order details, the server 115 may determine where the mobile unit 115a-
115c is headed to
-78-
7259508
Date Recue/Date Received 2022-02-07
and the identity of the customer. In some embodiments, the server 115 may
determine the
customer identity based upon communication (e.g., phone call, email, etc.)
from the customer.
In other embodiments, the server 115 may determine the customer identity in
other ways. Thus,
the server 115 may identify the customer in many ways.
[0172] In some embodiments, "customer identity" means the name of the
customer and
the location of the customer. For example, in some embodiments, a customer may
have a
plurality of locations. In such cases, simply knowing the name of the customer
may not be
enough, particularly in those embodiments in which different locations of the
customer have
different customer preferences. Thus, in some embodiments, "customer identity"
may include at
least the name and/or the location of the customer. In other embodiments, the
"customer
identity" may include other or additional information that may be needed or
considered useful to
have in performing the functions described herein. Generally speaking, the
term "customer" is
intended to correspond to any pickup and/or delivery location, including rail
yards, shipment
yards, and other types of locations from where freight may be picked up or
freight may be
dropped off.
[0173] Upon determining the identity (e.g., name and/or location) of the
customer at the
operation 1670, the server 115 identifies the customer preference for that
customer at operation
1675. In some embodiments, the server 115 may have previously received (e.g.,
before the
mobile unit 115a-115c departs for picking up/delivering load to the customer)
the customer
preference from the customer. In other embodiments, the customer preference
may be received
from the customer in real time while the mobile unit 115a-115c is on its way
to the customer to
pick-up or drop-off a load. The customer preference, whether received
previously or in real
time, may be stored within the server 115. In some embodiments, a mapping
between customer
identity and customer preference may be stored within the server 115. For
example, in some
embodiments, the mapping may indicate that for Customer A, location Li,
customer preference
is X. Thus, by identifying the customer identity, the server 115 may map that
customer identity
to the customer preference. In some embodiments, the server 115 may determine
the customer
-79-
7259508
Date Recue/Date Received 2022-02-07
preference from order details. In other embodiments, the server 115 may
determine customer
preference in other ways.
[0174] Further, in some embodiments, the server 115 may convert the
customer
preference into rules. For example, in some embodiments, the rule configurator
210 and the
rules engine 240 may define one or more rules based on each customer
preference. In some
embodiments, the defined rules may be stored within the rules database 205. In
some
embodiments, each rule may be associated with one or more tasks that the user
(e.g., driver) may
need to perform to comply with that rule. For example, in some embodiments, if
a customer
preference requires a notification from the user when the mobile unit 105a-
105c is within 50
miles of the customer location, the server 115 may generate a rule based on
that customer
preference. The server 115 may also associate a task with the rule. The task
may require the
user to send a notification to the customer when the mobile unit 105a-105c
associated with the
user is within 50 miles of the customer's location. In some embodiments, the
rule/task may also
indicate the manner of notification (e.g., call, email, text etc.) to the
customer. In some
embodiments, the customer preference may indicate a preferred mode of
notification, which may
then be incorporated into the rule/task that is generated for the customer
preference. In some
embodiments, the rule/task may also indicate the contact information of the
customer. The
rule/task may include other or additional information that the user may need
to complete the task
and comply with the rule/customer preference.
[0175] In some embodiments, the server 115 may associate a time period
with the rule
within which the task associated with that rule is to be completed. For
example and continuing
with the example above of notifying the customer when the user is within 50
miles of the
customer location, the server 115 may require that the user contact the
customer when the user is
between 10-50 miles from the customer location. In some embodiments, the rule
may require
the user to contact the customer within a particular time period (e.g., 30
minutes) of the task
showing up on the user's workflow. In some embodiments, the server 115 may
associate other
conditions with the rule/task. For example, in some embodiments, the rule may
require the user
to pull over before contacting the customer to avoid distractions while
driving. As another
-80-
7259508
Date Recue/Date Received 2022-02-07
example, if a customer requests delivery within certain hours, the rule may
indicate that the
delivery is to occur within those certain hours. In some embodiments, the rule
may indicate that
the tasks are to be completed in a specific location (e.g. deliver packages at
the back door instead
of the front door). Generally speaking, the rules may define conditions or
instructions on how a
particular task is to be completed. Thus, the server 115 may define one or
more rules for each
customer preference, and associate one or more tasks with each rule. The
server 115 may also
associate time period, conditions, or other constraints with each rule.
[0176] At operation 1680, the server 115 creates a dynamic task list for
the user. The
dynamic task list may include one or more tasks (also referred to herein as
activities)
corresponding to the one or more rules for satisfying the customer preference.
Although
compiled as a list herein, in other embodiments, the dynamic task list may
assume
configurations. The dynamic task list is considered "dynamic" because the
applicable rules and
associated tasks therein may change as necessary throughout a user's work
period. For example,
a user going through a work period might start out with a certain number of
tasks on their
dynamic task list and as time passes, the server 115 may add and/or remove
tasks from the
dynamic task list. In some embodiments, the server 115 may receive the
customer preference in
real time (e.g., while the driver is en route to the customer location). The
server 115 may, in real
time, define rules for the customer preference, and update the dynamic task
list of the user to add
task(s) to comply with those customer preference. Similarly, in some
embodiments, the dynamic
task list may include tasks to comply with a first customer preference. After
creating the
dynamic task list, the customer may change (e.g., modify, update, or delete)
the first customer
preference to a second customer preference. Because the dynamic task list is
dynamic in nature,
the server 115 may update the tasks in the dynamic task list to remove the
task(s) associated with
the first customer preference and add task(s) associated with the second
customer preference.
Additionally, in some embodiments, as the user completes tasks, the server 115
may delete those
tasks from the dynamic task list, such that the dynamic task list includes
only those tasks that the
user has yet to complete. Thus, the server 115 may continually and dynamically
update the
dynamic task list based up varying circumstances.
-81-
7259508
Date Recue/Date Received 2022-02-07
[0177] Upon creating the dynamic task list at the operation 1680, the
server 115 injects
the dynamic task list into a workflow of the user. In some embodiments, and as
discussed above
with respect to FIGS. 1-9, a user may have an existing workflow having a
certain number of
tasks (e.g., to comply with rules associated with meal breaks, rest breaks,
sick leave, work
activity, etc.) to complete within each work period. In some embodiments, the
server 115 may
assimilate or integrate the dynamic task list within this existing workflow.
In other words, the
server 115 may remotely update the existing workflow of the user to add the
tasks from the
dynamic task list therein. In some embodiments, the server 115 may create a
separate section in
the existing workflow for the dynamic task list. Thus, the server 115 may
inject the dynamic
task list into the existing workflow in any suitable way. The existing
workflow is already
established so it is beneficial to add the dynamic task list to the existing
workflow so that the
driver's experience is more seamless. In some embodiments, the dynamic task
list may be
injected into a new workflow if an existing workflow is not available or
suitable. Upon injecting
the dynamic task list into the existing workflow (or a separate work flow),
the task(s) in the
dynamic task list are visible to the user (e.g., via the computing device 110a-
110c). In some
embodiments, the server 115 may send the user may a notification (e.g., text,
email, or beep) to
indicate that the existing workflow has been updated with the dynamic task
list.
[0178] Optionally, the server 115 prioritizes the tasks in the existing
workflow at
operation 1690. In some embodiments, the operation 1690 may be performed
before the
operation 1685. In some embodiments, prioritizing the tasks in the existing
workflow may entail
prioritizing both - the tasks that previously existed in the workflow and the
tasks added from the
dynamic task list. In other embodiments, the server 115 may prioritize only
the tasks of the
dynamic task list. By prioritizing a task, the server 115 may indicate the
relative importance of a
task. For example, if a task is considered more important, is to be completed
immediately or
relatively quickly, then that task may be injected at a higher priority. In
some embodiments,
tasks that are considered more important may be placed higher on the existing
workflow for the
user to complete. Thus, in some embodiments, the server 115 may sort the
various tasks in the
-82-
7259508
Date Recue/Date Received 2022-02-07
work flow based on a priority, such that higher priority tasks are displayed
before lower priority
tasks.
[0179] In other embodiments, tasks that are more important or time
sensitive may be
marked with a notation (e.g., exclamation mark, color coded, etc.) to indicate
the importance of
that task to the user. In other embodiments, the server 115 may prioritize
tasks in other ways. In
some embodiments, in addition to prioritizing tasks, a notification (e.g.,
email, text, phone call,
etc.) may be sent to the user that they have an urgent task that needs to be
completed by a
specific time. In other embodiments, the server 115 may prioritize tasks in
other ways. In yet
other embodiments, no prioritization of the tasks may be done. In such cases,
the server 115 may
simply insert the dynamic task list at the beginning of the existing workflow,
at the end of the
existing work flow, or at any other predetermined location of the existing
workflow.
[0180] At operation 1695, the server 115 determines compliance with the
rule, and
therefore with the customer preference. As indicated above, each customer
preference may be
associated with one or more rules, and each rule may be associated with one or
more tasks which
may form the dynamic task list that is inserted into the existing work flow of
the user. Upon
injecting the dynamic task list, the server 115 monitors for completion of
those tasks. As the
user completes a certain task, the user may provide an input (e.g., via the
computing device
110a-110c). The input may be indicative of a task completion. For example, in
some
embodiments, upon the user contacting the customer within the 50 miles of the
customer
location, the user may interact with (e.g., click) on a "complete" button,
enter a specific time or
location when the user contacted the customer, and/or provide other type of
input verifying that
the user contacted the customer as required by the task. Upon receiving the
input from the user,
the server 115 may determine whether the task was completed. Upon determining
that the task
was completed, the server 115 may update the existing workflow of the user and
remove the
completed task from the existing workflow at operation 1700.
[0181] In some embodiments, upon removing the task from the existing
workflow, the
server 115 may send a notification (e.g., text, email, phone call, beep,
message on the computing
-83-
7259508
Date Recue/Date Received 2022-02-07
device 110a-110c, etc.) to the user indicating that the task has been deemed
completed. In some
embodiments, the server 115 may also send notifications to the user upon
determining that a task
is ready to be completed and that the user has not yet completed that task.
For example, in some
embodiments, the server 115 may determine that the user is within 20 miles of
the customer
location and the user has not yet completed the task of contacting the
customer within 50 miles
of the customer location. In such cases, the server 115 may send a
notification (e.g., text, beep,
change text color of task to red, etc.) indicating to the user that the task
is to be completed. In
some embodiments, the server 115 may also send a notification to the customer
indicating that
the customer preference has been satisfied based upon compliance with the rule
associated with
the completed task. Thus, the server 115 may monitor tasks for completion and
update the
existing workflow based upon completed tasks.
[0182] The process 1660 ends at operation 1705. The process 1660 may be
repeated for
each customer preference.
[0183] Turning now to FIG. 11, an example flow diagram outlining
operations of a
process 1710 is shown, in accordance with some embodiments of the present
disclosure. The
process 1710 may be used for dynamic task injection similar to the process
1660. In contrast to
the process 1660 which performs dynamic task injection based on customer
preferences, the
process 1710 may be used for dynamic task injection when certain conditions
are satisfied.
Thus, upon starting at operation 1715, the server 115 monitors for
satisfaction of a condition at
operation 1720, which may trigger dynamic task injection.
[0184] In some embodiments, it may be desirable to have a user (e.g.,
driver) complete
tasks when certain conditions are satisfied. In some embodiments, conditions
may be based
upon a particular line of business (e.g., long haul, regional, expedited,
etc.) or transportation
mode (e.g., intermodal, bulk, refrigerated, flatbed, etc.). For example, in
some embodiments, in
case of refrigerated transportation mode, it may be desirable to maintain the
temperature within a
particular range. In such cases, a rule for dynamic task injection may be
generated for the user to
periodically check the temperature of the load and adjust the temperature
within the trailer if
-84-
7259508
Date Recue/Date Received 2022-02-07
needed. In some embodiments, a condition may be based upon a current location
of the mobile
unit 105a-105c, a broken geo-fence, and/or origin-destination pairs. For
example, in some
embodiments, if the server 115 determines that the mobile unit 105a-105c is
headed to a
particular east coast state where the spotted lanternfly is prevalent, state
regulations may dictate
that the user check for the presence of the spotted lanternfly on the mobile
unit 105a-105c upon
entering that state and kill the bug upon finding it. In some embodiments,
evidence of killing the
spotted lanternfly may also be required by state regulations. In yet other
embodiments, it may be
desirable for a user (e.g., driver) to perform an action when the mobile unit
105a-105c of the user
breaks a particular geo-fence.
[0185] Thus, in some embodiments, a variety of conditions may be defined
based on
which the user may need to perform one or more actions. It is to be understood
that the
conditions mentioned above are only an example, and are not intended to be
limiting in any way.
Therefore, at the operation 1720, the server 115 monitors for satisfaction of
a condition for
dynamic task injection. In some embodiments, the condition may have been
previously received
(e.g., before the mobile unit 105a-105c is in en route) by the server 115,
while in other
embodiments, the condition may be received in real time (e.g., while the
mobile unit is in en
route). In some embodiments, the server 115 may identify the condition based
upon monitoring
the current location of the mobile unit 105a-105c. For example, in some
embodiments, if the
current location of the mobile unit 105a-105c indicates that the mobile unit
is headed to a
particular eastern state, the server 115 may determine that the condition is
satisfied. Similarly, in
some embodiments, if the server 115 receives an indication that the mobile
unit 105a-105c has
broken a particular geo-fence, the server may determine that a condition for
dynamic task
injection has been satisfied. Thus, the server 115 may be configured to
monitor for various
conditions.
[0186] Further, similar to the customer preference, each condition may be
associated
with one or more rules, and each rule may be associated with one or more tasks
to be completed
by the user. For example, the server 115 may define a spotted lanternfly rule
that may be
associated with certain eastern states. When the mobile unit 105a-105c enters
one of those
-85-
7259508
Date Recue/Date Received 2022-02-07
eastern states, the server 115 may determine that the spotted lanternfly rule
is to be invoked. In
some embodiments, the spotted lanternfly rule may be associated with a first
task of stopping
within a predetermined distance of entering the state to check for spotted
lanternfly in defined
locations (e.g., grill) of the mobile unit. In some embodiments, the spotted
lanternfly rule may
be associated with a second task of killing the spotted lanternfly. In some
embodiments, the rule
may also define how to kill the spotted lanternfly. In some embodiments, the
spotted lanternfly
rule may be further associated with a third task of collecting evidence (e.g.,
taking a picture) that
the user has killed the spotted lanternfly. In some embodiments, the spotted
lanternfly rule may
define what evidence to collect and how.
[0187] Thus, upon determining that the mobile unit 105a-105c has
satisfied a condition
by entering a particular state, the server 115 may invoke the spotted
lanternfly rule. Again, it is
to be understood that the examples used herein are only for illustration
purposes, and not
intended to be limiting in any way.
[0188] At operation 1725, upon determining that a condition has been
satisfied, the
server 115 generates a dynamic task list. The dynamic task list of FIG. 11 is
similar to the
dynamic task list (e.g., created at the operation 1680) of FIG. 10, and
therefore not described
again. Using the spotted lanternfly example above, the server 115 may create a
dynamic task list
having the first, second, and third tasks therein. As discussed above in FIG.
10, the dynamic task
list may include other criteria (e.g., time period, conditions, etc.) that the
user may need to
comply with to complete the tasks. At operation 1730, the dynamic task list is
injected into a
workflow of the user. The operation 1730 is similar to the operation 1685.
Optionally, the
server 115 prioritizes the tasks in the workflow of the user at operation
1735, similar to the
operation 1690. At operations 1740 and 1745, the server 115 monitors for
compliance with the
tasks and updates the workflow, respectively. The operations 1740 and 1745 are
similar to the
operations 1695 and 1700, respectively, and therefore not described again. The
process 1710
ends at operation 1750.
-86-
7259508
Date Recue/Date Received 2022-02-07
[0189] Turning now to FIG. 12, an example flow diagram outlining
operations of a
process 1755 is shown, in accordance with some embodiments of the present
disclosure. The
process 1755 may be used for dynamic task injection similar to the process
1660. The process
1755 may be used for dynamic task injection based on certain load types. In
some embodiments,
the user (e.g., driver) may be transporting a load that requires certain
conditions be met in order
for the load to be transported safely and successfully. Thus, upon starting at
operation 1760, the
server 115 determines the load type at operation 1765.
[0190] As mentioned above, users (e.g., drivers) may be carrying loads
that require
specific conditions be met based on the load type. For example, in some
embodiments the load
type may be dangerous biohazardous material that need to be transported at a
certain temperature
for safety. In other embodiments, the load type may be perishable goods (e.g.
food or medicine)
that also need to be transported within a certain temperature range to ensure
that the goods do not
spoil before reaching their destination. In yet other embodiments, the load
may consist of fragile
goods (e.g., glass furniture) that require extra caution be taken to ensure
that the load reaches the
desired destination without breakage, and so on.
[0191] The load type may be determined in different ways. For example, in
some
embodiments, the load type may be determined and communicated by an
administrator (e.g., a
manager) to the server 115 before the mobile unit 105a-105c begins travel. In
other
embodiments, the load type may be determined by the order details of a
particular order. In
some embodiments, the order details may be accessible to server 115. From the
order details, the
server 115 may determine the type of freight the mobile unit 105a-105c is
intended to carry. In
yet other embodiments, the load may be determined by the user (e.g., the
driver) who may
determine the load manually by inspecting the contents of the load and convey
the information
related to the load type to the server 115. In some embodiments, the load type
may be
determined based upon sensors (e.g., cameras) mounted in the trailer of the
mobile unit 115a-
115c. In other embodiments, the server 115 may determine the load type in
other ways.
-87-
7259508
Date Recue/Date Received 2022-02-07
[0192] In some embodiments, it may be desirable to have a user (e.g.,
driver) complete
tasks based on the load type. For example, if the mobile unit 105a-105c is
intended to carry
biohazardous material or perishable goods, it may be desirable to maintain the
temperature of
that biohazardous material or perishable goods within a particular temperature
range. In such
cases, the server 115 may define a rule for dynamic task injection for the
user (e.g., driver) to
periodically check the temperature of the biohazardous material or perishable
goods and adjust
the temperature within the trailer if needed to maintain the desired
temperature range. In other
embodiments, such as when transporting fragile goods, it may be desirable to
ensure that the load
is properly secured. In such cases, the server 115 may define a rule for
dynamic task injection
for the user to periodically check the bindings to ensure that the load is
still secure. Further, in
some embodiments, the server 115 may define another rule for dynamic task
injection to avoid
routes that the server may have determined to be turbulent in order to avoid
damaging the fragile
load.
[0193] Thus, in some embodiments, the server 115 may define a variety of
rules based on
the load type. It is to be understood that the load types mentioned above are
only an example,
and are not intended to be limiting in any way. Generally speaking, the
process 1755 may be
used for dynamic task injection based on any load type. Further, similar to
the customer
preference of the process 1660, each load type may be associated with one or
more rules, and
each rule may be associated with one or more tasks to be completed by the
user. For example,
the server 115 may define a temperature rule that may be associated with
certain load types.
When the mobile unit 105a-105c is transporting temperature sensitive materials
(e.g.,
biohazardous material), the server 115 may invoke the temperature rule. In
some embodiments,
the temperature rule may be associated with a first task of stopping every few
hours to check the
temperature of the load. In some embodiments, the temperature rule may be
associated with a
second task of recording and reporting temperature to the server 115 upon
checking. In some
embodiments, the temperature rule may define appropriate temperature ranges
and assign further
tasks if the checked temperature is not within an allowed range. In some
embodiments, the
-88-
7259508
Date Recue/Date Received 2022-02-07
temperature rule may specific how to measure the temperature, how frequently
to check the
temperature, etc.
[0194] At operation 1770, upon determining a load type and any rules
associated with
that load type, the server 115 generates a dynamic task list. The dynamic task
list of FIG. 12 is
similar to the dynamic task list (e.g., created at the operation 1680) of FIG.
10, and therefore not
described again. Using the temperature example above, the server 115 may
create a dynamic
task list having the first and second tasks therein. As discussed above in
FIG. 10, the dynamic
task list may include other criteria (e.g., time period, frequency, etc.) that
the user may need to
comply with to complete the tasks. At operation 1775, the dynamic task list is
injected into a
workflow of the user. The operation 1775 is similar to the operation 1685.
Optionally, the
server 115 prioritizes the tasks in the workflow of the user at operation
1780, similar to the
operation 1690. At operations 1785 and 1790, the server 115 monitors for
compliance with the
tasks and updates the workflow, respectively. The operations 1785 and 1790 are
similar to the
operations 1695 and 1700, respectively, and therefore not described again. The
process 1755
ends at operation 1795.
[0195] Turning now to FIG.13, an example flow diagram outlining
operations of a
process 1800 is shown, in accordance with some embodiments of the present
disclosure. The
process 1800 may be used for dynamic task injection similar to the process
1660. The process
1800 may be used for dynamic task injection based on feedback or information
received from the
mobile unit 105a-105c. For example, in some embodiments, the mobile unit 105a-
105c may
have various sensors installed thereon. For example, in some embodiments, the
sensors may be
configured to determine the current location of the mobile unit 105a-105c. In
other
embodiments, the mobile unit 105a-105c may have sensors installed thereon to
monitor
operation of the various electronic and/or mechanical components of the mobile
unit. In yet
other embodiments, the mobile unit 105a-105c may have sensors mounted thereon
that
measure/record certain driving related events (e.g., hard braking, speed),
environmental
conditions within and outside of the mobile unit (e.g., inside and outside
temperature, etc.). In
other embodiments, the mobile unit 105a-105c may have other mechanisms that
monitor,
-89-
7259508
Date Recue/Date Received 2022-02-07
measure, and/or record data related to the mobile unit. In other embodiments,
the user (e.g.,
driver) may notify (e.g., call in) an issue associated with the mobile unit
105a-105c. In some
embodiments, such sensor data or any other data (collectively referred to
herein as "data") from
the mobile unit 105a-105c may be transmitted to the server 115. In some
embodiments, the data
may be sent periodically to the server 115 or continuously as the data is
gathered.
[0196] Upon receiving the data from the mobile unit 105a-105c, the server
115 may
interpret that data. For example, based upon the data, the server 115 may
determine that a
particular electrical component of the mobile unit 105a-105c is
malfunctioning. As another
example, based upon the data, the server 115 may determine that the
temperature within the
trailer is outside a desired temperature range. Based upon the interpreted
data, the server 115
may perform dynamic task injection. Thus upon starting at operation 1800, the
server 115
monitors for data from the mobile unit 105a-105c at operation 1810 and
interprets this data to
create a course of action which may trigger dynamic task injection.
[0197] In some embodiments, each interpretation of the data may be
associated with one
or more rules, and each rule may be associated with one or more tasks for the
user (e.g., driver)
to complete. For example, if the server 115 interprets (e.g., from the data
received from the
mobile unit 105a-105c) that the mobile unit is experiencing a degraded
performance or
malfunction in a certain component, the server 115 may define/invoke a
maintenance rule. In
some embodiments, the maintenance rule may be associated with a first task of
requiring the user
to pull over and inspect the impacted component. The maintenance rule may
include a second
task for the user to collect evidence (e.g., take pictures or record data) of
the malfunction or
degraded performance. In some embodiments, the maintenance rule may include a
third task that
requires the user to seek roadside assistance. The maintenance rule may
include other or
additional tasks.
[0198] As another example, the server 115 may interpret the data received
from the
mobile unit 105a-105c to determine that the user is consistently driving above
a desired speed
limit, that the user is hard braking frequently, and/or the mobile unit 105a-
105c is frequently
-90-
7259508
Date Recue/Date Received 2022-02-07
departing from the lane. In some embodiments, the server 115 may invoke a
driving rule having
a task requesting the driver to drive at a certain speed limit, take a breath
alcohol test, etc. In
some embodiments, the server 115 may interpret the data from the mobile unit
105a-105c along
with other available information. For example, the server 115 may determine
that the mobile
unit 105a-105c is also carrying fragile goods. Based on the mobile unit 105a-
105c carrying
fragile goods and the data indicating erratic driving, the server may invoke a
rule based on load
type as discussed above (e.g., to check the load) and a driving rule to
address the erratic driving.
[0199] Thus, based upon interpreted data, the server 115 may
define/invoke rules having
one or more tasks for the user to complete. At operation 1815, the server 115
generates a
dynamic task list based on the interpreted data and the defined/invoked rules.
The dynamic task
list of FIG. 13 is similar to the dynamic task list (e.g., created at the
operation 1680) of FIG. 10,
and therefore not described again. At operation 1820, the server 115 injects
the dynamic task list
into a workflow of the user (e.g., driver). The operation 1820 is similar to
the operation 1685.
Optionally, the server 115 prioritizes the tasks in the workflow of the user
at operation 1825,
similar to the operation 1690. At operations 1830 and 1835, the server 115
monitors for
compliance with the tasks and updates the workflow, respectively. The
operations 1830 and
1835 are similar to the operations 1695 and 1700, respectively, and therefore
not described
again. The process 1800 ends at operation 1840.
[0200] Turning now to FIG. 14 an example flow diagram outlining
operations of a
process 1845 is shown, in accordance with some embodiments of the present
disclosure. The
process 1845 may be used for dynamic task injection similar to the process
1660. The process
1845 may be used for dynamic task injection based on alerts received on the
back end by the
server 115. In some embodiments, the server 115 may receive alerts from
various sources. For
example, in some embodiments, the server 115 may receive weather alerts from
the National
Weather Service. In some embodiments, the server 115 may receive traffic
alerts from a third
party vendor. In some embodiments, the server 115 may receive indication of
social unrest at a
location that the mobile unit 105a-105c is headed to, and so on. Based on
these alerts, the server
115 may perform dynamic task injection.
-91-
7259508
Date Recue/Date Received 2022-02-07
[0201] To determine the alerts that may be applicable to the mobile unit
105a-105c, upon
starting at operation 1850, the server 115 determines the location of the
mobile unit at operation
1855. In some embodiments, the server 115 may determine the current location
of the mobile
unit 105a-105c based on data received from the GPS 113a-113c or the GIS tool
280, or broken
geofences. In other embodiments, the server 115 may determine the current
location of the
mobile unit 105a-105c in other ways. Upon determining the location of the
mobile unit 105a-
105c at operation 1855, the server 115 determines the alerts impacting the
current location of the
mobile unit 105a-105c at operation 1860. In some embodiments, the server 115
may also
monitor for alerts along the route that the mobile unit 105a-105c is
travelling on. By monitoring
for alerts along the route, the server 115 may be able to take proactive
action.
[0202] For example, if the server 115 determines that the mobile unit
105a-105c is
headed to a particular location having heavy traffic, the server may determine
that an alternate
route may be preferable to save time. In such cases, the server 115 may
define/invoke an
alternate route rule. In other embodiments, the server 115 may determine that
the mobile unit
105a-105c is headed to an area with inclement weather. In such a case, the
server 115 may
define/invoke an alternate route rule or alternate plan rule. For example, via
the alternate route
rule, the server 115 may inject one or more tasks requiring the user to take a
different route than
the route that the mobile unit 105a-105c is currently on. By the alternate
plan route, the server
115 may direct the user to either pull over and wait for the adverse condition
(e.g., inclement
weather, heavy traffic, etc.) to pass, take a break, etc.
[0203] Thus, based upon alerts received and interpreted by the server
115, the server may
define/invoke one or more rules. At operation 1865, the server 115 generates a
dynamic task list
based on the interpreted alerts. The dynamic task list of FIG. 14 is similar
to the dynamic task
list (e.g., created at the operation 1680) of FIG. 10, and therefore not
described again. At
operation 1870, the dynamic task list is injected into a workflow of the user.
The operation 1870
is similar to the operation 1685. Optionally, the server 115 prioritizes the
tasks in the workflow
of the user at operation 1875, similar to the operation 1690. At operations
1880 and 1885, the
server 115 monitors for compliance with the tasks and updates the workflow,
respectively. The
-92-
7259508
Date Recue/Date Received 2022-02-07
operations 1880 and 1885 are similar to the operations 1695 and 1700,
respectively, and
therefore not described again. The process 1845 ends at operation 1890.
[0204] Thus, the present disclosure provides a mechanism by which the
server 115 may
monitor for certain actions (e.g., customer preferences, conditions, load
type, data, alerts, etc.),
define rules based on the monitored actions, and dynamically inject tasks for
the user to complete
and comply with those rules. It is to be understood that the examples used
above are only for
explanation purposes and are not intended to be limiting in any way. Further,
it is also to be
understood that the server 115 may be monitoring for, and invoking rules for,
multiple actions
simultaneously. For example, in some embodiments, the server 115 may be
invoking rules based
on customer preferences and load type, while also monitoring for alerts and
invoking rules as
needed based on the alerts. Thus, dynamic task injection provides a convenient
mechanism to
require compliance with desired actions without hindering the user or
distracting the user from
driving.
[0205] While the disclosure has been described in terms of exemplary
embodiments,
those skilled in the art will recognize that the disclosure can be practiced
with modifications in
the spirit and scope of the appended claims. These examples are merely
illustrative and are not
meant to be an exhaustive list of all possible designs, embodiments,
applications or
modifications of the disclosure.
-93-
7259508
Date Recue/Date Received 2022-02-07
