A SYSTEM AND METHOD FOR SECURE EMPLOYEE TIME AND LOCATION TRACKING
FIELD OF INVENTION
The invention relates to a method and a system for a secure employee time and location tracking and time keeping for employers with mobile workforces.
BACKGROUND OF INVENTION
It has been always been imperative and unanimously accepted that for employers in certain sectors like door to door sales, delivery and private security, an employee's presence at a particular location is of vital importance to the functioning of the employer's offering. In the current state of the art, the employer typically does not have exact and timely information about an employee's whereabouts. This knowledge gap impacts the efficiency and efficacy of the company's offerings to its customers.
For example, there has been a dire need for employers of security guards to have an audit tool that provides real time location data, and allows for continued operational improvement. In the end, the security company provides a higher level of service to its customers.
For employees of security guard companies a need is felt to secure a tamperproof way of time keeping, it is meant to supplement and in some cases replace the existing 'attendance register' based record keeping.
As another example, for employers of door to door delivery or pickup sales forces, the tamper proof and timely knowledge that the field agent has actually gone to the customer location has undisputed value.
SUMMARY
The object of the invention is to plug the loopholes as pointed out in the background, by increasing the efficiency, and providing timely and tamper proof location and timekeeping information.
The present invention relates to a system and a method that uses the combination of a mobile phone based application client and a hosted 'in the cloud' web server to provide secure employee location tracking and timekeeping for employers with mobile workforces.
The service is delivered by means of the 'Blue Dolphin' application, which is pre-installed on specially equipped Smartphone running on any operating System, and the Blue Dolphin Portal, which is an access controlled web portal.
In its current realization, the employees use 3G enabled Android Smartphone(s), running the Blue Dolphin Application client, to upload a 'grouping' (consisting of one or more 'check-ins') to the Blue Dolphin web server via a 3G data link. A 'grouping' is initiated by pressing a series of buttons on the 'Blue Dolphin' application home screen. The 'grouping' is complete when it has been uploaded over the 3G (or 2G) mobile data link to the 'cloud'. Here it is stored in the Blue Dolphin Chitrgupt Database, which can be accessed later for analysis and report generation.
Each 'check-in' has at least the time and GPS provided location encoded in it. The Blue Dolphin application can be configured to collect check-in data either "passively" (i.e. without any user intervention) or "actively" (while requiring user intervention) or both. For "active" mode, the check-in may also contain visual images or video recordings, as well as any other relevant information that may be useful to collect. This information is uploaded securely via the 3G Data Network to the 'Blue Dolphin' database. The 'Blue Dolphin' engine automatically analyzes this data, and generates reports and alerts (if necessary). The alerts and reports can be generated in a variety of forms, including emails, SMS and web pages.
The Blue Dolphin Portal is a self service portal, which provides summary reports and analyses of the data collected via the Blue Dolphin Smartphone application. It is an 'access controlled' portal, which means that ONLY authorized users can access it. We provide below some sample screens from the Blue Dolphin Portal. The most common type of report available is the so called 'shift summary report'. This displays a map view of all the employee check-ins during a particular shift, as well the picture logs for each employee. The Blue Dolphin Portal may also be used to map the movement of a particular employee during a particular time period. It may also be used to generate tabular reports of data and metadata which may then be downloaded.
The 'cloud' based Blue Dolphin engine also automatically analyzes the uploaded data, and based on certain heuristics which are predetermined, raises alerts if any deviations or irregularities are found.
The 'cloud' based Blue Dolphin engine also generates periodic summary reports, providing information that can be used for both audit and billing purposes by the employer.
BRIEF DESCRIPTION OF DRAWINGS
Fig 1 illustrates network topology of Blue Dolphin Service.
Fig 2 illustrates the data model for Chitrgupt database.
DETAILED DESCRIPTION
The present invention relates to a service using a combination of a mobile phone based application client and a hosted 'in the cloud' web server to provide secure employee location tracking and timekeeping for employers with mobile workforces, the employees use 3G enabled Android Smartphone(s), running the Blue Dolphin Application client, to upload a 'grouping' (consisting of one or more 'check-ins') to the Blue Dolphin web server via a 3G data link. The Blue Dolphin Portal is an access controlled web server and 'in the cloud' database. As a preferred embodiment of the instant invention, the Blue Dolphin Portal comprises a login screen, which displays the Blue Dolphin service logo prominently, as well as provide a helpful link to a video. Clicking the log in screen should prompt the user to enter their sub-domain name (i.e. their organization name), which will then bring up the domain specific login page. The user must be allowed to enter any sub domain they like (even if it is not a valid one) to prevent users from 'phishing' for names of existing customers.
The user is assumed to be an employee or an administrator of the subdomain (organization) entered in the previous page and the Dashboard they see has one extra level of information .Essentially, there is a list of all organizations that use the blue dolphin service. Clicking any given link will bring up the organization admin user dashboard.
The per organization admin user dashboard will allow the administrator to quickly analyze and generate reports for various end users and places. It will also allow the admin to quickly jump to the statistics or the alerts page (any pre-configured alerts generated are simultaneously sent, via email, to the list of key contacts).
There is present a places landing page that shows a map view of all the active (registered) places associated with the organization. It should also allow the user to search for places, view favorite places, add or remove a place from the list of favorites. Clicking any of the buttons should bring up a suitable form, optimized for speed and ease of use (especially for mobile users).
Clicking on a particular place should bring up the same form as the one reached by pressing the 'search' button (except with the 'place' filled in). The user should be asked to specify a date range to display groupings of check-ins associated with the particular place. Once the date range has been specified, and assuming that there was activity in the place for that particular day, the groupings detail page is displayed.
The places landing page shows a table view of all the active persons associated with the organization. The default view should show the most recent 'active' persons first. (An active person is a person who has just checked in). It should also allow the user to search for persons, view favorite persons, add or remove a place from the list of favorites. Clicking any of the buttons should bring up a suitable form, optimized for speed and ease of use (especially for mobile users) for filling in salient details of the person.
Clicking on a particular person should bring up the same form as the one reached by pressing the 'search' button (except with the 'person' filled in). The user should be asked to specify a date range to display groupings of check-ins associated with the particular person. Once the date range has been specified, and assuming that there was activity in the place for that particular day, the groupings detail page is displayed.
The groupings listing page provides a 'calender view' for a particular date range, given a set of search criteria (all the groupings associated with a particular place or person, are some examples of search criteria). If the date range specified is one day, then the listing page shows the list of groupings in an 'hourly' view.
Clicking on an individual grouping should bring up a detail page, showing the location and times (as well as all photos) associated with the grouping. The first part of the web page shows a map overlay of all the pictures, along with their geo-coordinates. The second part of the web page shows a 'time' grid.
The 'Person' details page should show the relevant details of the person (photograph, organization specific meta data, mobile phone, places associated with this person) as well as a summary of this person's most recent month's activity.
The 'Place' details page should show the location (on a map) of this place, as well as any relevant details (photograph, organization specific metadata, address, and name) as well as a summary of the places most recent month's activity.
The Alerts page is used to set up 'push' email alerts, to automate the navigation to a particular groupings detail page.
In one non limiting embodiment of the present invention Fig 1 presents a high level schematic view of the key components of the service, as well as the interplay between them. The service requires that the end user have a GPS (preferably 'Α', or 'assisted' GPS) enabled Smartphone (101), with a valid 3G (or 2G) data plan. The Smartphone must run Android version 2.2 or higher. It should also have the following applications pre-installed. There is also an in built camera so that he end user can take pictures as part of a check-in.
A QR code is a Quick Response code which has a fast readability and a large storage capacity. An employee QR code is a unique 2D bar code, typically printed on the front of every employee's ID card/badge. It is a conventionally kept at least 10 cm squares.
A bar code scanner operable by the end user is thus provided to scan either 'person' or 'location' QR codes from employee ID cards or site labels. In the current realization, this bar code scanner is present as a pre-installed software application on the Android Smartphone that is running the Blue Dolphin Application.
The Blue Dolphin application (110) provides all of the client side functionality of the service. Here are some of the key functions it performs.
Employee/Location Identification: The application uses QR code based xml data to identify the employee/location pair whose duty roster is being uploaded. As mentioned above, the QR code scanning may be performed by some third party application in some realizations. Alternatively, the application may also identify the locations automatically, based on comparing the currently reported GeoLocation with a previously known location. Picture Log: The application uses the built in Smartphone camera to create a 'picture log' of the duty roster. Each checkin may thus be associated with a single image.
Employee Location Tracking: The application uses the built in GPS (or A-GPS) capabilities of the Smartphone to 'tag' every check-in (whether associated with an image or not). It also computes the distance from the desired to the actual location being tracked. (This number should be as low as possible for every check-in). The application periodically 'wakes up' and records the device's current location, and stores it in a local database.
Employee Time Tracking: The application allows for the tracking of an employee's 'working hours', by virtue of the fact that every check-in is time stamped.
Duty Roster 'Upload': The application uses the Smartphone 3G data connectivity to upload the entire duty roster (including any images) to the Blue Dolphin Database (via the Blue Dolphin web server).
The service requires a highly available 3G data network (102) to transport duty roster data in a timely fashion. The network speed and bandwidth must allow for close to real time monitoring of employee location.
The Blue Dolphin server (103) provides all of the server side functionality of the service. It is shown here as a homogenous (and singular) element for ease of understanding. In practice, it may be spread across multiple physical web server hardware 'instances'. Furthermore, any (or all) of its components can reside in separate hardware instances, without loss of functionality.
Mentioned below are some of its key components.
Blue Dolphin Database (104): This is a highly scalable, fast access database. Its actual internal structure (whether relational or not, object or not) is not germane to this discussion. It stores all of the raw data that is being generated by various Smartphone running the Blue Dolphin application. In addition, it also contains the details of every employee and location that needs to be tracked. The details of the employee include an identifying photograph, as well any employer generated ID.
Blue Dolphin Engine (105): This is an efficient and tunable analytics engine, which constantly analyzes check-in data, correlates it with the 'known' employee and location details, and looks for any deviations or error conditions. If an error pattern occurs (due to an employee wandering off too far from their required location, or an employee not check-ing in frequently enough) the engine generates an 'alert'. The alert is sent out via Email (108) to list of predetermined email addresses (and mobile numbers, via SMS (109)). In addition, the engine also generates 'daily summary reports' for any given location or employee, for a specified time period
The service relies on the internet (106) to transport all reports and alarms to the employer (or administrators). Blue Dolphin Portal (107) is access controlled web site that provides all of the administrative as well as reporting functionality for the Blue Dolphin service. Here are some of its key features:
Employee/Location Detail Management: The portal allows authenticated users to add/remove/edit the details of any employee and/or location to the Blue Dolphin Database. In addition, the portal can be used to retrieve images of either the employee/location or generate fresh QR codes (which may then be reprinted to various portable media) on demand.
Employee/Location Duty Roster Report Generation: The portal allows authenticated users to generate summary reports for any given employee and/or location, within a specified time period. Each report can also be used to 'drill down' into the details, down to the individual check-ins (with their associated details).
Automated Alarm/Alert/Summary Report Generation: The portal also allows authenticated users to register to receive alarms and/or summary reports (at a user specified frequency) either via email (108) or SMS (109). Furthermore, users are allowed to tweak the parameters associated with alert/alarm generation on a per location/per employee basis.
In another non limiting embodiment of the instant invention Fig 2 illustrates an exemplary data model for the Chitrgupt database. The service object (201) is the highest level object in the Chitrgupt database. It is used to differentiate between various types of service offerings from Rare Media Company. For example, 'Blue Dolphin' is an enterprise service offering for employee time and location tracking. In the future, it is expected that more diverse offerings, revolving around the check-in/grouping model will be offered on top of this database.
The service object contains the following required elements:
• ID: The database specific uuid for the service. The term UUID is short for 'Universally Unique Identifier'. It allows for any of the distributed components of the Blue Dolphin Network (the smartphone application, the Blue Dolphin portal or the Chitrgupt database itself) to generate a unique Identifier. The UUID standard specifies an algorithm by which these 128 bit identifiers can be generated by disparate network elements with very low likely hood of collision.
• Name: The full name of the service
• Description: A brief description of the service.
The organization object (201) typically (although not always) corresponds to a real organization (like an employer, or a group of associated users). Every organization is associated with at least one service. An organization may be associated with more than one service.
The organization object contains the following required elements: • ID: The database specific uuid for the organization
• Name: The full name of the organization
• Web Page: The web page for the organization
• Address: The (physical) address of the organization's head quarters
• Service(s): The ID(s) of the services that this organization is associated with
The following elements are optional:
• Service Specific Data (SSD): These elements are used to describe one or more extra data types that are unique to the services that this organization belongs to. Every organization that is associated with a particular service must have all the SSD's for that service specified.
The person object (203) corresponds to individual end users in the database. Every person must be associated with at least one organization. A person may be associated with more than one organization. Note: If a person organization affiliation is not known, it is automatically added to the DEFAULT organization. This organization should be automatically added to the database at create time. The person object contains the following required elements:
• ID: The database specific uuid for the person
• Name: The name of the person (matching the name on their identifying documents)
• Organization(s): The IDs of the organization this person belongs to. A Person may be part of many different organizations.
• The following elements are considered optional (for this version of the API).
• UID: The globally unique identifier (or number) for this person. Wherever possible, this identifier should be one that is issued by a competent governmental authority (like SSN or driver license number in the US, or Aadhar, PAN card no or voter ID in India).
• Email address: The person's primary email address
• Mobile Number: The person's primary phone number
• Organization Specific Data (OSD): Any number of OSD entries. These are dependant on the organization, and can be obtained via the API call for obtaining the details of a particular organization. • Photo: The ID of photo object associated with this person, with enough detail that they can be uniquely identified and indexed via some well-known facial recognition API (like those available from face.com)
The device object (204) is a 'peer' of the person object. It corresponds to any mobile device capable of interacting with the Rare Media Network (via the Blue Dolphin API). A device MUST be associated with at least one organization.
The device object has the following required elements:
• IMEI/MEID: The unique 15 numeric identifier of any GSM or CDMA device.
• Mobile Number: The mobile number (if any) associated with this device
• Organization(s): The organization(s) that this device belongs to.
The following elements are considered optional:
• Organization Specific Data (OSD): Any number of OSD entries. Again dependant on the organization in question.
• Service Specific Data (SSD): Any number of service specific entries.
The place object (205) is also a peer of the person object (203). This object generally represents a specific location. However, it may also represent something transient (like the inside of a moving bus, which does not have a fixed geolocation).
The following elements are required:
• ID: A generated UUID for the place
• Name: The given name of the place
• Address: The physical address (if any) of the location
• Latitude: The geo latitude of the place
• Longitude: The geo longitude of the place
• Altitude: The altitude (above mean sea level) of this place
• Organization(s): The organizations that this place belongs to.
The following elements are optional:
• Organization Specific Data (OSD): Any number of OSD entries. The 'thing' object (206) is also a peer of the person object. This object is used to represent any entity that is not a person, place or device. It is generally used to represent something that must be tracked via a 'check-in'.
The following elements are required:
· ID: A generated UUID for the thing
• Name: The given name for the thing
• Description: A description of the 'thing'
• Organization(s): The organizations that this 'thing' belongs to.
The following elements are optional:
· Organization Specific Data (OSD): Any number of OSD entries.
A grouping (207) is a logical group of check-ins (208) that together convey information about the location (and appearance, if necessary) of a particular person. A grouping MUST be associated with EXACTLY ONE device. A grouping MAY be associated with more than ONE person and/or place.
The following elements are required:
• ID: A generated UUID for the grouping
• Person ID: The id of the person(s) associated with this grouping
• Device ID: The id of the device associated with this grouping
• Place ID(s): The id of the place(s) associated with this grouping
· Start time: The start time of this particular grouping.
• End time: The end time of this particular grouping.
The check-in (208) represents the 'leaves' of the data model. It uniquely represents a point in time (and space). It is always associated with a device (since the check-in is made via the device). The check-in MAY be associated with a person, place or thing (or any combination thereof). A check-in MUST be associated with exactly ONE grouping.
The following elements are required:
• ID: The generated UUID for the check-in
• Grouping ID: The grouping that this check-in is associated with.
• Time: The timestamp (in UTC format) for this check-in • Latitude: The latitude for this check-in
• Longitude: The longitude for this check-in
• Accuracy: The accuracy (in meters) for the geolocation obtained on this check-in
• Device ID: The ID of the device associated with this check-in
The following elements are optional:
• Photo ID: The ID of the photo associated with this check-in
• Person ID: The ID of the specific person associated with this check-in
• Place ID: The ID of the specific place associated with this check-in
• Thing ID: The ID of the specific 'thing' associated with this check-in
The photo object (209) is the most mportant data object in the chitrgupt database. It can be associated with many different types of objects, but this relation is always a one-one relationship. For example, a photo object may be associated with a person. It MUST be associated with ONLY a single person. Similarly, it may be associated with either a place or a check-in.
The following elements are required:
· ID: The generated UUID for the photo
• Parent Object ID: The ID of the parent object (person, place or check-in)
The present invention is not to be limited in scope by the specific embodiments and examples which are intended as illustrations of a number of aspects of the invention and all embodiments which are functionally equivalent are within the scope of this invention. Those skilled in the art will know, or will be able to ascertain using no more than routine experimentation, many equivalents to the specific embodiments of the invention described herein.