CN111066053B

CN111066053B - System and method for approving and tracking taxi-taking

Info

Publication number: CN111066053B
Application number: CN201880042407.7A
Authority: CN
Inventors: 乌兰托娅; 闫磊
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2018-08-23
Filing date: 2018-08-23
Publication date: 2021-03-02
Anticipated expiration: 2038-08-23
Also published as: WO2020037595A1; CN111066053A

Abstract

A computer-implemented method of approving and tracking taxi trips comprising: acquiring planned trip information submitted through an applicant account; in response to receiving approval of the planned itinerary, enabling the applicant account to order one or more itineraries for an actual itinerary; tracking information of an applicant computing device associated with the applicant account during the actual trip to determine at least one of: whether a start time of the journey is within the approved time period, whether an end time of the journey is within the approved time period, whether an origin of the journey is within a first threshold distance from the approved origin, whether a destination of the journey is within a second threshold distance from the approved destination, whether a cost of the journey is within the approved budget, or whether a number of journeys of the journey is within the approved number of journeys.

Description

System and method for approving and tracking taxi-taking

Technical Field

The present application relates generally to computer technology and more particularly to systems and methods for approving and tracking taxi trips.

Background

Corporate employees often require traffic related services. Traditionally, employees would have to spend personal funds to pay for the transportation and apply for reimbursement from the company. This process is complex and time consuming.

Disclosure of Invention

Various embodiments of the present application include systems, methods, and non-transitory computer-readable media for approving and tracking taxi trips.

According to one aspect of the present application, a computer-implemented method of approving and tracking a taxi cab, comprising: obtaining future planned travel information submitted via an applicant account, the information including at least one of: a planned time period, a planned departure location, a planned destination, a budget, or a number of planned journeys in the planned time period; responsive to receiving approval for the future planned itinerary from one or more approval computing devices, authorizing the applicant account to be able to order one or more itineraries for an actual itinerary, the approval including at least one of the following conditions: an approved time period, an approved origin, an approved destination, an approved budget, or an approved number of journeys in the approved time period; tracking information of an applicant computing device associated with the applicant account during the actual trip to determine at least one of: whether a start time of the journey is within the approved time period, whether an end time of the journey is within the approved time period, whether an origin of the journey is within a first threshold distance from the approved origin, whether a destination of the journey is within a second threshold distance from the approved destination, whether a cost of the journey is within the approved budget, or whether a number of journeys of the journey is within the approved number of journeys; and in response to any unsatisfactory determination, sending the tracking information to the one or more approval computing devices to review the approval.

In some embodiments, tracking information of the applicant computing device related to the applicant account during the actual trip comprises: obtaining a Global Positioning System (GPS) location of the applicant computing device associated with the applicant account corresponding to a get-on location as the origin of the journey, and obtaining a GPS location of the applicant computing device associated with the applicant account corresponding to a get-off location as the destination of the journey.

In some embodiments, the method further comprises: in response to determining that the applicant computing device is ordering a current trip for the actual trip, and determining at least one of: prohibiting the applicant computing device from ordering the current trip through the applicant account if a current time is not within the approved time period, a current location of the applicant's computing device is not within the first threshold distance from the approved origin, or a past trip number of the actual trip in the approved time period is not within the approved trip number.

In some embodiments, the method further comprises: in response to any unsatisfied determination, a non-matching explanation is obtained by the applicant account and transmitted to the one or more approval computing devices along with the tracking information to review the approval.

In some embodiments, the one or more approval computing devices comprise a first approval computing device and a second approval computing device. Receiving the approval of the future planned itinerary from one or more approval computing devices comprises: receiving a first approval from the first reviewing computing device; forwarding the future planned itinerary to the second approval computing device; and receiving a second approval from the second reviewing computing device.

In some embodiments, the applicant account is used by an applicant associated with an entity, the approval computing device is used by an approver of the entity, and the method further comprises paying for the actual trip from funds of the entity.

In some embodiments, prior to obtaining the information of the future planned itinerary submitted via the applicant account, the method further comprises: obtaining, from a configuration computing device, a threshold as the upper budget limit, an area definition as a geographic boundary of the planned trip, and information for one or more approvers to determine one or more approver accounts, wherein the approver computing device is respectively associated with the approver accounts.

According to another aspect of the present application, a system for approving and tracking a taxi trip includes a processor and a non-transitory computer-readable storage medium storing instructions that, when executed by the processor, cause the processor to perform a method. The method comprises the following steps: obtaining future planned travel information submitted via an applicant account, the information including at least one of: a planned time period, a planned departure location, a planned destination, a budget, or a number of planned journeys in the planned time period; responsive to receiving approval for the future planned itinerary from one or more approval computing devices, authorizing the applicant account to be able to order one or more itineraries for an actual itinerary, the approval including at least one of the following conditions: an approved time period, an approved origin, an approved destination, an approved budget, or an approved number of journeys in the approved time period; tracking information of an applicant computing device associated with the applicant account during the actual trip to determine at least one of: whether a start time of the journey is within the approved time period, whether an end time of the journey is within the approved time period, whether an origin of the journey is within a first threshold distance from the approved origin, whether a destination of the journey is within a second threshold distance from the approved destination, whether a cost of the journey is within the approved budget, or whether a number of journeys of the journey is within the approved number of journeys; and in response to any unsatisfactory determination, sending the tracking information to the one or more approval computing devices to review the approval.

According to another aspect of the application, a non-transitory computer-readable storage medium stores instructions that, when executed by the processor, cause the processor to perform a method. The method includes obtaining future planned travel information submitted via an applicant account, the information including at least one of: a planned time period, a planned departure location, a planned destination, a budget, or a number of planned journeys in the planned time period; responsive to receiving approval for the future planned itinerary from one or more approval computing devices, authorizing the applicant account to be able to order one or more itineraries for an actual itinerary, the approval including at least one of the following conditions: an approved time period, an approved origin, an approved destination, an approved budget, or an approved number of journeys in the approved time period; tracking information of an applicant computing device associated with the applicant account during the actual trip to determine at least one of: whether a start time of the journey is within the approved time period, whether an end time of the journey is within the approved time period, whether an origin of the journey is within a first threshold distance from the approved origin, whether a destination of the journey is within a second threshold distance from the approved destination, whether a cost of the journey is within the approved budget, or whether a number of journeys of the journey is within the approved number of journeys; and in response to any unsatisfactory determination, sending the tracking information to the one or more approval computing devices to review the approval.

These and other features of the systems, methods and non-transitory computer readable media disclosed herein, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the invention.

Drawings

Certain features of various embodiments of the technology are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present technology will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings of which:

fig. 1 illustrates an exemplary environment for approving and tracking a taxi trip, in accordance with various embodiments.

Fig. 2 illustrates exemplary system interactions for approving and tracking a taxi ride, in accordance with various embodiments.

Fig. 3A illustrates an exemplary interface for configuring a taxi cab application, in accordance with various embodiments.

FIG. 3B illustrates an exemplary interface for configuring an approver, according to various embodiments.

FIG. 3C illustrates an exemplary interface for applying for a trip approval, in accordance with various embodiments.

FIG. 3D illustrates an exemplary interface displaying an application state in accordance with various embodiments.

Fig. 3E illustrates an exemplary interface for approving an application according to various embodiments.

Fig. 3F illustrates an exemplary interface displaying an approved application, in accordance with various embodiments.

Fig. 4 illustrates a flow diagram of an exemplary method of approving and tracking a taxi trip, in accordance with various embodiments.

FIG. 5 illustrates a block diagram of an exemplary computer system in which any of the embodiments described herein may be implemented.

Detailed Description

Corporate employees often require traffic related services. Traditionally, employees must apply reimbursement approval, spend personal funds to pay for the transportation fee, and submit travel documents for reimbursement. Some corporate approvers may screen these applications and make reimbursement decisions. This process is complex and time consuming. In addition, an approver may approve an application for a particular shipment with certain conditions that are difficult to validate based on the proof of submission with only limited information (e.g., time and expense). Thus, with more and more staff, managing reimbursement programs becomes burdensome. The lack of a verification mechanism further creates room for misuse, abuse, and fraud.

The systems and methods disclosed herein may at least alleviate the above-mentioned technical problems of current general practice. Various embodiments of the present application include systems, methods, and non-transitory computer-readable media for approving and tracking taxi trips. The exemplary method may be implemented by software having server-side and/or client-side functionality to enable entities to simplify employee taxi requisitions, approvals, and tracking. Clients may have different interfaces and functions for different user groups: an enterprise manager, an approver, an applicant, etc. The client may interact with the server to implement various functions. The reimburseable itinerary application may be configured by an enterprise administrator to define various fields (e.g., time period, location, approver) for collecting application information for a planned itinerary. The employee applicant may submit a planned trip, but subject to approval by one or more approvers. The approver may review and approve/reject the application. Once the application is approved, the applicant can order the transportation service directly according to the authorized approval, and the transportation cost is borne by the entity. By tracking the applicant's computing devices, it can be ensured that the ordered transportation service conforms to the approved plan. Thus, traffic reimbursements can be effectively handled, tracked, and managed, and improper use and abuse of company funds can be prevented.

Fig. 1 illustrates an exemplary environment 100 for approving and tracking a taxi, according to various embodiments. As shown in FIG. 1, the exemplary environment 100 may include at least one computing system 102 including one or more processors 104 and memory 106. Memory 106 may be non-transitory and computer-readable. The memory 106 may store instructions that, when executed by the one or more processors 104, cause the one or more processors 104 to perform various operations described herein. The system 102 may be implemented on or as various devices such as a mobile phone, a tablet, a server, a computer, a wearable device, and so forth. The system 102 may be equipped with appropriate software and/or hardware (e.g., wires, wireless connections, etc.) to access other devices of the environment 100.

The environment 100 may include one or more data stores (e.g., data store 108) and one or more computing devices (e.g., computing device 109) accessible to the system 102. In some embodiments, the system 102 may be configured to retrieve data (e.g., map data, user data) from the data store 108 and/or store data in the data store 108 (e.g., user data set, map database) and/or the computing device 109 (e.g., computer, server, mobile phone).

Environment 100 may also include one or more computing devices (e.g.,

computing devices

107, 110, 111, and 112) coupled to system 102. For example, each computing device may be a mobile phone, tablet, computer, wearable device (smart watch), and the like. The computing devices may each transmit data to the system 102 and/or receive data from the system 102. The transmitted data may include user information data, time data, location data, and the like. The location data may include GPS (global positioning system) coordinates. Computing device 107 may be associated with an individual of the entity that oversees the reimbursement for the itinerary (e.g., a business manager responsible for finance and budgeting). The computing device 110 may be associated with an applicant (e.g., a corporate employee who applies for a trip reimbursement and is also the passenger of the actual trip). The computing device 111 may be associated with an approver (e.g., an administrator of an enterprise). The computing device 112 may be associated with another approver (e.g., another administrator of the enterprise).

Computing devices

107, 110, 111, and 112 may have different interfaces and functionality customized for respective user groups.

In some embodiments, the system 102 may implement an online information or service platform (e.g., in the form of a software application). The platform may be referred to as a vehicle platform (or a taxi-taking service platform, a bus order dispatching platform). The service may be associated with a vehicle (e.g., an automobile, a bicycle, a boat, an airplane, etc.). The platform may accept requests for transportation, identify vehicles that satisfy the requests, arrange for pickup, and process the transaction. For example, a user may use a computing device 110 (e.g., a mobile phone installed with a software application associated with the platform) to request a shipment from the platform. The system 102 may receive the request (e.g., including the time of the pick-up, the pick-up location, and the destination) and forward it to the individual vehicle drivers (e.g., by issuing the request to a mobile phone carried by the driver). The vehicle driver may use a computing device (e.g., another mobile phone installed with an application associated with the platform) to accept the issued transportation request, travel to the pick-up location, and ship the user to the destination. Fees (e.g., transportation fees) may be traded between the system 102, the computing device 110, and the driver's computing device. Some platform data may be stored in memory 106 or may be read from data storage 108 and/or

computing devices

107, 109, 110, and 111. For example, for each trip, the location of the origin and destination (e.g., sent by the computing device 110 and/or the driver's computing device), the cost (e.g., determined by the system 102), and the time may be obtained by the system 102.

In some embodiments, the software application may provide various user modes. For one user mode, the user may use the vehicle platform without authorization and without reimbursement from a third party (e.g., the user's corporate employer). The user may order the itinerary and pay with his own funds. For another user mode described herein, the user may apply for reimbursement planned (future) trips using the vehicle platform. Upon approval, the user may order a partial or full trip reimbursed by a third party directly through the software application.

In some embodiments, system 102 and one or more computing devices (e.g., computing device 109) may be integrated in a single device or system. Alternatively, the system 102 and one or more computing devices may be separate devices. The data store may be located anywhere accessible to the system 102, e.g., in the memory 106, in the computing device 109, in another device coupled to the system 102 (e.g., a network storage device), or other storage location (e.g., a cloud-based storage system, a network file system, etc.), and so forth. Although system 102 and computing device 109 are shown as separate components in this figure, it should be understood that system 102 and computing device 109 may be implemented by separate devices or multiple devices coupled together. System 102 may be implemented by a stand-alone system or multiple systems coupled together. Generally, system 102, computing device 109, data store 108, and

computing devices

110, 111, and 112 are capable of communicating with each other to transfer data over one or more wired or wireless networks (e.g., the Internet). Various aspects of the environment 100 are described below with reference to fig. 2-5.

Fig. 2 illustrates exemplary system interactions for approving and tracking a taxi ride, in accordance with various embodiments. The operations shown in fig. 2 and presented below are intended for illustration. Depending on the implementation, the operations illustrated in fig. 2 and presented below may include additional, fewer, or alternative steps, which may be performed in various orders or in parallel. Throughout this application, companies and enterprises are defined broadly and may include any type of organization or organizations. Although employee applicants are used as an example throughout this application, other types of applicant-organizational relationships may also be applied.

Fig. 2 illustrates the system 102 (e.g., a server), the configuration computing device 107 (e.g., a laptop used by an enterprise administrator or controller), the applicant computing device 110 (e.g., a mobile phone used by an enterprise employee applicant), the first approval computing device 111 (e.g., a mobile phone used by an enterprise administrator), and the second approval computing device 112 (e.g., a computer of another enterprise administrator) described above with reference to fig. 1. To access

computing devices

107, 110, 111, or 112, a user may need to log into a corresponding account or otherwise verify identity. For example, account authentication may need to be configured to perform various steps by configuring computing device 107 (described below), applicant account authentication may need to be performed to perform various steps by applicant computing device 110 (described below), a first administrator account authentication may need to be performed to perform various steps by first approving computing device 111 (described below), and a second administrator account authentication may need to be performed to perform various steps by second approving computing device 112 (described below). Thus, the

computing devices

107, 110, 111, or 112 shown in this figure may each represent one or more computing devices, and a user may access any computing device to perform the described steps as long as authentication is performed through the corresponding account. For example, the applicant may apply for a trip reimbursement from a personal laptop (e.g., step 202) and then order the actual trip from a personal mobile phone (e.g., after step 206).

In some embodiments,

computing devices

107, 110, 111, and 112 may each be installed with software for a vehicle platform (e.g., mobile phone APP, desktop software). The software may have different interfaces and functionality for different user groups. For example, computing device 107 may install an enterprise-side software version, and an enterprise administrator may access the software by logging into a configuration account. Computing device 110 may install the applicant/passenger side software version and the applicant may access the software by logging into the applicant's account.

Computing devices

111 and 112 may install the approver-side software version and the approver may access the software by logging into the approver account. Software installed on the computing device 110 may provide the taxi taking functionality described above. A computing device (not shown) of the transportation provider, such as the driver's mobile phone, may install a driver-side software version. System 102 may host a server-side of a software application. Software installed on the system 102 and various computing devices may provide application, approval, and tracking functions discussed in more detail below.

FIG. 2 illustrates the interaction between system 102 and

computing devices

107, 110, 111, and 112. The interaction presented below is intended for illustrative purposes. Depending on the implementation, the operations may include additional, fewer, or alternative steps, which may be performed in various orders or in parallel.

In some embodiments, a user (e.g., an enterprise administrator) may access a configuration account via configuration computing device 107 to configure settings for an application for an itinerary reimbursement at step 201. For example, the system 102 may obtain, from the configuration computing device 107, a threshold as an upper budget limit, a region definition as a geographic boundary of a planned trip, and information for one or more approvers for determining one or more approver accounts. The approver selected in this configuration will be delegated the review and approval application. Further details of an exemplary interface for configuration are described below with reference to fig. 3A and 3B. The system 102 can cause the applicant/passenger side software on the applicant computer device 110 to display a corresponding interface for obtaining application information. At step 202, system 102 can obtain information of future planned itineraries submitted via the applicant's account. The information may include: a planned time period, a planned departure location, a planned destination, a budget, and/or a number of planned trips within the planned time period. Further details of an exemplary interface for obtaining information are described below with reference to FIG. 3C. System 102 may automatically compile the application based on the obtained information and forward the application to one or more approvers. For example, at step 203, system 102 forwards the application to a first reviewer account. Based on an exemplary approval configuration, if the first approver approves the application from computing device 111 and notifies system 102 at step 204, system 102 may forward the application to a second approver account at step 205. Further details of an exemplary interface for viewing the application status at the applicant's end are described below with reference to FIG. 3D. Further details of an exemplary interface for approval of an application at the approver end are described below with reference to FIG. 3E. If the second approver also approves the application at step 206, system 102 may notify the applicant account of the approval at step 207. Further details of an exemplary interface based on approving an order itinerary are described below with reference to FIG. 3F.

Still referring to FIG. 2, in response to receiving approval for a future planned itinerary from one or more

approval computing devices

111 and 112, system 102 may enable an applicant account to order one or more itineraries for an actual itinerary. The approval may include one or more of the following conditions: an approved time period, an approved origin, an approved destination, an approved budget, and a number of trips approved during the approved time period. These conditions can be verified by tracing the applicant's computing device. At step 208, system 102 can track applicants 'computing device (e.g., applicants computing device 110) information relating to applicants' account during an actual trip to determine: whether a start time of the journey is within the approved time period, whether an end time of the journey is within the approved time period, whether an origin of the journey is within a first threshold distance from the approved origin, whether a destination of the journey is within a second threshold distance from the approved destination, whether a cost of the journey is within the approved budget, or whether a number of journeys of the journey is within the approved number of journeys. If there are any determinations not satisfied, the system 102 can notify the applicant's account and seek an explanation of the discrepancy at step 209a and send tracking information to one or more

approval computing devices

111 and 112 for approval at steps 209b and 209 c. That is, system 102 can obtain an explanation of the mismatch through the applicant account and send the explanation to one or more approval computing devices along with the tracking information to review the approval. The approver may determine whether the unmatched application is allowed based on the interpretation. If the ordered itinerary is eligible, the system 102 may pay the cost of the actual itinerary from the entity's funds to the driver's account.

In some embodiments, if the system 102 determines that the applicant computing device 110 is ordering a current trip for an actual trip and determines at least one of: the system 102 may prohibit the applicant's computing device from ordering the current trip through the applicant account if the current time is not within the approved time period, the applicant's computing device's current location is not within the first threshold distance from the approved origin, or the past trip times of the actual trip in the approved time period are not within the approved trip times. That is, the applicant may not be able to order reimbursement itineraries that do not comply with the approval conditions. Nevertheless, the applicant may order the journey through a personal account, without reimbursement.

In some embodiments, to track information of the applicant's computing device 110 associated with the applicant's account during an actual trip, the system 102 may obtain a Global Positioning System (GPS) location of the applicant's computing device 110 associated with the applicant corresponding to an getting-on location as a starting point for the trip and a GPS location of the applicant's computing device 110 associated with the applicant's account corresponding to a getting-off location as a destination for the trip. For example, when an order is placed for an actual trip, the computing device 110 may indicate a planned pick-up location and send the location to the system 102. The planned position may be used as the actual vehicle position. Additionally or alternatively, when the user is picked up, the driver may indicate through the driver terminal software that the user has been picked up, and the current location of the computing device 110 or the driver's computing device may also be used as the origin of the trip. When the destination is reached, the driver may indicate through the driver terminal software that the user is dropped, and the current location of the computing device 110 or the driver's computing device may be used as the destination for the trip.

Fig. 3A-3F illustrate exemplary interfaces of an approval and tracking taxi-taking application according to various embodiments. The operations shown in fig. 3A-3F and presented below are intended to be illustrative.

Fig. 3A illustrates an exemplary interface 300 for configuring a taxi cab application, in accordance with various embodiments. The interface 300 may be provided on the enterprise-side software configuring the computing device 107. Thus, an enterprise administrator with access to configuration account rights can configure settings at this interface to reflect enterprise standards for the application and approval of the trip reimbursement. As shown in FIG. 3A, interface 300 may provide configuration settings for various employee travel scenarios that a business may reimburse, such as overtime, commuting to work, business travel, airport pickup, and business car rental, among others. In this figure, configuration settings for reimbursing a business trip are shown. Other scenarios may have similar configuration settings.

The configuration settings may include: application type, number of trips planned, trip threshold, personal restrictions, time period planned, route planned, area definition, available vehicle type, approver, etc. The application type may include, for example, "apply for a trip" or "time period". The "applications by trip" may be applicable to a single day trip where the applicant may require one or more trips. The "application by time period" may be applicable to a multi-day trip. As indicated by the thickened boundary line, "number of journeys" is chosen as an example in this example. Other application types and configuration settings may additionally or alternatively be used. Each application may apply for an advanced "trip," which may include one or more trips between various locations. The number of planned journeys may be input by the applicant or limited by the business administrator. The trip threshold may be used as an upper limit for the reimbursement budget for each trip. Personal limits may refer to a maximum amount that can be reimbursed for a single person, e.g., for each trip, for each time period, etc. The planning period may be filled in by the applicant or limited by an enterprise administrator. The planned route (e.g., in terms of origin and destination locations) may be filled in by the applicant or restricted by an enterprise administrator. For example, a business administrator may limit the origin to a range of one mile from the business company location. The area definition may provide the option of limiting the start and end points of the same city to prevent high costs from long distance travel between cities. The available vehicle types may define one or more types of vehicles approved for ordering by the applicant. The approver configuration may be used to configure information for one or more approvers responsible for reviewing the application. Each approver has an approver account to which applications may be forwarded for approval.

FIG. 3B illustrates an

exemplary interface

311 and 313 for configuring an approver, according to various embodiments. Interface 311 may be provided 313 on the enterprise-side software from configuring computing device 107. As shown in FIG. 3B, interface 311 may provide an option to configure one or more approvers. The approver may consist of different levels. For example, for a two-tier architecture, an application may need to be approved by a first tier approver before being forwarded to a second tier approver for approval. At each level, the approver may be configured as a "superordinate approver" or a "special approver". For the superior approvers, the enterprise administrator may set up a library of approvers, and the applicant may select the appropriate approver when preparing for application. For a particular approver, the enterprise administrator may configure the approver for the applicant. As shown, at a first level, John Doe is configured by the enterprise administrator as a special approver. If the enterprise administrator attempts to delete John Doe,

interface

312 or 313 may be triggered. If John Doe has an application pending for approval, interface 312 may provide an option to return the application to the applicant or to remind John Doe. If John Doe does not have an application for approval, interface 313 may indicate that John Doe is the only remaining approver and provide the option of adding a replacement approver to keep the configuration valid.

FIG. 3C illustrates an exemplary interface 320 for applying for a trip approval, in accordance with various embodiments. Interface 320 may be provided on applicant's side software of applicant computing device 110. Thus, an applicant having access to an applicant account may submit an application for approval. As shown in FIG. 3C, interface 320 can obtain future planned itinerary information submitted via the applicant's account. The acquired information may include: a planned time period (e.g., at a date period and/or time period), a planned departure location, a planned destination, a round trip setting, a budget (not shown), a number of journeys (e.g., two departures and two returns), a reason for application, etc. within the planned time period. On interface 320, cost center information may be automatically generated, for example, to instruct a department within the enterprise to reimburse the shipment. The approver may be a special approver automatically generated or a superior approver selected by the applicant.

FIG. 3D illustrates an exemplary interface 330 for displaying an application state according to various embodiments. Interface 330 may be provided on applicant's side software of applicant computing device 110. Thus, an applicant having access to an applicant account may view the application approval program. As shown in fig. 3D, interface 330 may indicate details of the filed application and the approval phase to complete and approve. As shown, John Doe has approved XYZ's application after filing the application, and is currently awaiting approval by James Smith.

Fig. 3E illustrates an exemplary interface 340 for approving an application according to various embodiments. Interface 340 can be provided on approver-side software of applicants' computing device 112. Thus, an approver who has access to the approver's account may view the pending application. As shown in FIG. 3E, interface 340 may indicate details of the filed application and the approver (John Doe) who approved the application. Through this interface, James Smith can approve the application or refund to the applicant. Since James Smith is the last approver to approve the application, he does not need to forward the application to the next approver after approving the application.

Fig. 3F illustrates an exemplary interface 350 displaying approved applications, in accordance with various embodiments. Interface 350 may be provided on the applicant's side software of applicant computing device 110. As shown in fig. 3F, the interface 350 may indicate details of the approved application, which may be the same as details of the submitted planned trip. Through this interface, XYZ can order the actual trip directly through approved authorizations and reimbursements, or switch to a personal account and use a personal funds ordering trip.

As described above, a software system having a server and a client may implement a trip reimbursement program. The enterprise can easily configure and manage the trip reimbursement application, approval and tracking from the enterprise-side software and ensure that the computing system validates the trip order against approved conditions. The employee applicant and the approver can conveniently simplify the application and approval process. Thus, reimbursement can be prevented from being misused, abused and used for fraud. Company resources previously spent on reimbursement project management can now be saved and used elsewhere.

Fig. 4 illustrates a flow diagram of an exemplary method 400 of approving and tracking a taxi cab according to various embodiments of the present application. Method 400 may be implemented in various environments, including, for example, environment 100 of FIG. 1. The example method 400 may be implemented by one or more components of the system 102 (e.g., the processor 104, the memory 106). Exemplary system 102 may include a server. The exemplary method 400 may be implemented by a plurality of systems similar to the system 102. The operations of method 400 presented below are intended for illustration. Depending on the implementation, the exemplary method 400 may include additional, fewer, or alternative steps, which may be performed in various orders or in parallel.

Block 402 includes obtaining information for a planned itinerary submitted via an applicant account, the information including at least one of: a planned time period, a planned departure location, a planned destination, a budget, or a number of journeys planned during the planned time period. Block 404 includes enabling the applicant account to order one or more itineraries for an actual itinerary in response to receiving approval for a future planned itinerary from one or more approval computing devices, the approval including at least one condition: an approved time period, an approved departure point, an approved destination, an approved budget, or an approved number of journeys in an approved time period. Block 406 includes tracking information of the applicant computing device related to the applicant account during the actual trip to determine at least one of: whether the start time of the trip is within an approved time period, whether the end time of the trip is within an approved time period, whether the origin of the trip is within a first threshold distance from the approved origin, whether the destination of the trip is within a second threshold distance from the approved destination, whether the cost of the trip is within an approved budget, or whether the number of trips of the trip is within an approved number of trips. Block 408 includes, in response to any determination that is not satisfied, sending tracking information to one or more approval computing devices to review for approval.

In some embodiments, tracking information of the applicant computing device related to the applicant account during the actual shipment includes: the method further includes obtaining a Global Positioning System (GPS) location of the applicant computing device associated with the applicant account corresponding to the get-on location as a point of departure for the trip, and obtaining a GPS location of the applicant computing device associated with the applicant account corresponding to the get-off location as a destination for the trip.

In some embodiments, the method further comprises: in response to determining that the applicant's computing device is ordering a current trip for an actual trip, and determining at least one of: the applicant's computing device is prohibited from ordering the current trip through the applicant's account if the current time is not within the approved time period, the applicant's computing device's current location is not within a first threshold distance from the approved origin, or the number of past trips of the actual trip in the approved time period is not within the approved number of trips.

In some embodiments, the method further comprises: in response to any unsatisfied determination, an explanation of the mismatch is obtained by the applicant account and sent, along with the tracking information, to one or more approval computing devices for approval.

In some embodiments, the one or more approval computing devices comprise a first approval computing device and a second approval computing device. Obtaining approval of a future planned trip from one or more approval computing devices includes: receiving a first approval from a first reviewing computing device; forwarding the future planned itinerary to a second approval computing device; and receiving a second approval from the second reviewing computing device.

In some embodiments, the applicant account is used by an applicant associated with the entity, the approval computing device is used by an approver of the entity, and the method further comprises paying for the actual itinerary from funds of the entity.

In some embodiments, prior to obtaining information for future planned trips submitted via the applicant account, the method further comprises: obtaining, from a configuration computing device, a threshold as an upper limit of a budget, an area definition as a geographic boundary of a planned trip, and information for one or more approvers for determining one or more approver accounts, wherein the approver computing device is respectively associated with the approver accounts. Further details of method 400 may be found in fig. 1-3F above.

The techniques described herein are implemented by one or more special-purpose computing devices. A special-purpose computing device may be a desktop computer system, a server computer system, a portable computer system, a handheld device, a network device, or any other device or combination of devices that contain hardwired and/or program logic to implement the techniques. Computing devices are typically controlled and coordinated by operating system software. Conventional operating systems control and arrange computer processes for performing, performing memory management, providing file systems, networking, input/output services, and providing user interface functions, such as graphical user interfaces ("GUIs"), among others.

FIG. 5 is a block diagram illustrating an exemplary computer system 500 that may implement any of the embodiments described herein. The system 500 may correspond to the system 102 described above. Computer system 500 includes a bus 502 or other communication mechanism for communicating information, and one or more hardware processors 504 coupled with bus 502 for processing information. Hardware processor 504 may be, for example, one or more general-purpose microprocessors. The processor 504 may correspond to the processor 104 described above.

Computer system 500 also includes a main memory 506, such as a Random Access Memory (RAM), cache, and/or other dynamic storage device, coupled to bus 502 for storing information and instructions to be executed by processor 504. Main memory 506 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 504. When stored in a storage medium accessible to processor 504, the instructions may cause computer system 500 to become a special-purpose machine that is customized to perform the operations specified in the instructions. Computer system 500 further includes a Read Only Memory (ROM)508 or other static storage device coupled to bus 502 for storing static information and instructions for processor 504. A memory 510, such as a magnetic disk, optical disk, or USB thumb drive (flash drive), is provided and coupled to bus 502 for storing information and instructions. Main memory 506, ROM508, and/or storage 510 may correspond to memory 106 described above.

Computer system 500 may implement the techniques described herein using custom hardwired logic, one or more Application Specific Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs), firmware, and/or program logic that, in combination with the computer system, causes computer system 500 to become or be programmed as a special purpose machine. According to one embodiment, the techniques of this disclosure may be performed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions may be read into main memory 506 from another storage medium, such as memory 510. Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

Main memory 506, ROM508, and/or memory 510 may include non-transitory storage media. The term "non-transitory medium" and similar terms as used herein refer to a medium that stores data and/or instructions that cause a machine to operate in a specific manner. The medium does not include a transitory signal. Such non-transitory media may include non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as memory 510. Volatile media includes dynamic memory, such as main memory 506. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a compact disc read only drive (CD-ROM), any other optical data storage medium, any physical medium with patterns of holes, a RAM, a Programmable Read Only Memory (PROM), and Erasable Programmable Read Only Memory (EPROM), a FLASH-EPROM, a non-volatile random access memory (NVRAM), any other memory chip or cartridge, and networked versions thereof.

Computer system 500 also includes a network interface 518 coupled to bus 502. Network interface 518 provides a two-way data communication coupling to one or more network links that are connected to one or more local networks. For example, network interface 518 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, network interface 518 may be a Local Area Network (LAN) card to provide a data communication connection to a compatible LAN (or a WAN component to communicate with a WAN). Network interface 518 may also implement a wireless link. In any such implementation, network interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Computer system 500 can send messages and receive data, including program code, through the network(s), network link(s) and network interface 518. Using the internet for example, a server might transmit a requested code for an application program through the internet, an Internet Service Provider (ISP), local network and network interface 518.

The received code may be executed by processor 504 as it is received, and/or stored in memory 510, or other non-volatile storage for later execution.

Each of the processes, methods, and algorithms described in the preceding sections can be implemented by, and through, code modules, either fully automated or semi-automated. The code modules are executed by one or more computer systems or computer processors, which include computer hardware. The above-described processes and algorithms may be implemented in part or in whole by application specific circuitry.

The various features and processes described above may be used independently of one another or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of the present application. In addition, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the blocks or states associated therewith may be performed in other suitable orders. For example, described blocks or states may be performed in an order different than that specifically disclosed, or multiple blocks or states may be combined into a single block or state. The exemplary blocks or states may be performed serially, in parallel, or in other manners. Blocks or states may be added to or removed from the disclosed exemplary embodiments. The exemplary systems and components described herein may be configured differently than described herein. For example, elements may be added, removed, or rearranged as compared to the disclosed exemplary embodiments.

Various operations in the example methods described herein may be performed, at least in part, by algorithms. The algorithm may be embodied in program code or instructions stored in a memory (e.g., the non-transitory computer-readable storage medium described above). Such algorithms may include machine learning algorithms. In some embodiments, the machine learning algorithm may not explicitly program the computer to perform a certain function, but may learn the training data to generate a predictive model that performs the function.

Various operations of the example methods described herein may be performed, at least in part, by one or more processors that are temporarily configured (e.g., via software) or permanently configured to perform the relevant operations. Whether temporarily configured or permanently configured, the processor may constitute an engine implemented by the processor that operates to perform one or more operations or functions described herein.

Similarly, the methods described herein may be implemented at least in part by a particular processor or group of processors (as hardware examples). For example, at least a portion of the operations of a method may be performed by one or more processors or processor-implemented engines. Further, the one or more processors may also operate to leverage support capabilities for related operations in a "cloud computing" environment or to implement "software as a service" (SaaS).

Any process descriptions, elements, or blocks in flow diagrams described herein and/or depicted in the drawings should be understood as potentially representing modules, components, or portions of code which include one or more executable instructions for implementing specific logical functions or process steps. It will be understood by those within the art that alternative implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted or performed out of the order shown or discussed, including substantially concurrently or in the reverse order, depending on the functionality involved.

As used herein, the term "or" may be interpreted in an inclusive or exclusive sense. Furthermore, multiple instances may be provided for a resource, operation, or structure described herein as a single instance. In addition, the boundaries between the various resources, operations, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. The allocation of other functions contemplated may fall within the scope of the various embodiments of the present application. In general, the structures and functionality presented as separate resources in the exemplary configurations may be implemented in a combined structure or a combined resource. Similarly, the structure and functionality presented as separate resources may be implemented in multiple separate resources. These and other variations, modifications, additions, and improvements may fall within the scope of the embodiments of the application, as represented by the claims that follow. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Although the subject matter herein has been summarized with reference to specific exemplary embodiments, various modifications and changes may be made to the embodiments without departing from the broader scope of the embodiments of the application. Such embodiments of the subject matter herein may be referred to, individually or collectively, by the term "invention" merely for convenience of description and without intending to voluntarily limit the scope of this application to any single disclosure or concept if more than one is in fact disclosed.

The embodiments illustrated herein have been described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be derived from the teachings disclosed, and utilized, such that structural and logical substitutions and changes may be made to the embodiments herein without departing from the scope of this disclosure. The detailed description is, therefore, not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Claims

1. A computer-implemented method of approving and tracking a taxi, comprising:

obtaining, from a configuration computing device, a threshold as an upper budget limit, an area definition as a geographic boundary of a future planned trip;

obtaining the future planned itinerary information submitted via an applicant account, the information including at least one of: a planned time period, a planned departure location, a planned destination, a budget, or a number of planned journeys in the planned time period;

responsive to receiving approval for the future planned itinerary from one or more approval computing devices, authorizing the applicant account to be able to order one or more itineraries for an actual itinerary, the approval including at least one of the following conditions: an approved time period, an approved origin, an approved destination, an approved budget, or an approved number of journeys in the approved time period;

tracking information of an applicant computing device associated with the applicant account during the actual trip to determine at least one of: whether a start time of the journey is within the approved time period, whether an end time of the journey is within the approved time period, whether an origin of the journey is within a first threshold distance from the approved origin, whether a destination of the journey is within a second threshold distance from the approved destination, whether a cost of the journey is within the approved budget, or whether a number of journeys of the journey is within the approved number of journeys; and

in response to any unsatisfactory determination, sending the tracking information to the one or more approval computing devices to review the approval.

2. The method of claim 1, wherein tracking information of the applicant computing device related to the applicant account during the actual trip comprises:

obtaining a Global Positioning System (GPS) location of the applicant computing device associated with the applicant account corresponding to a boarding location, the boarding location serving as a starting point for the journey.

3. The method of claim 1, wherein tracking information of the applicant computing device related to the applicant account during the actual trip comprises:

obtaining a GPS location of the applicant computing device associated with the applicant account corresponding to a drop-off location as a destination for the trip.

4. The method of claim 1, further comprising:

in response to determining that the applicant computing device is ordering a current trip for the actual trip, and determining at least one of: inhibiting the applicant computing device from ordering the current journey through the applicant account if a current time is not within the approved time period, a current location of the applicant's computing device is not within the first threshold distance from the approved origin, or a past number of journeys of the actual journey in the approved time period is not within the approved number of journeys.

5. The method of claim 1, further comprising:

in response to any unsatisfied determination, a non-matching explanation is obtained by the applicant account and transmitted to the one or more approval computing devices along with the tracking information to review the approval.

6. The method of claim 1, wherein:

the one or more approval computing devices comprise a first approval computing device and a second approval computing device; and

receiving the approval of the future planned itinerary from one or more approval computing devices comprises:

receiving a first approval from the first reviewing computing device;

forwarding the future planned itinerary to the second approval computing device; and

receiving a second approval from the second reviewing computing device.

7. The method of claim 1, wherein:

the applicant account is used by an applicant associated with the entity;

the approval computing device is used by an approver of the entity; and

the method also includes paying a fee for the actual trip from funds of the entity.

8. The method of claim 1, further comprising, prior to obtaining the information of the future planned itinerary submitted via the applicant account:

obtaining, from a configuration computing device, information of one or more approvers for determining one or more approver accounts, wherein the approver computing device is respectively associated with the approver accounts.

9. A system for approving and tracking a taxi-taking, comprising a processor and a non-transitory computer-readable storage medium storing instructions that, when executed by the processor, cause the processor to perform a method comprising:

obtaining future planned travel information submitted via an applicant account, the information including at least one of: a planned time period, a planned departure location, a planned destination, a budget, or a number of planned journeys in the planned time period;

10. The system of claim 9, wherein the tracking information of the applicant computing device related to the applicant account during the actual trip comprises:

obtaining a Global Positioning System (GPS) location of the applicant's computing device associated with the applicant account corresponding to a boarding location, the boarding location serving as a starting point for the journey.

11. The system of claim 9, wherein the tracking information of the applicant computing device related to the applicant account during the actual trip comprises:

12. The system of claim 9, further comprising:

in response to determining that the applicant computing device is ordering a current trip for the actual trip, and determining at least one of: prohibiting the applicant's computing device from ordering the current trip through the applicant account if a current time is not within the approved time period, a current location of the applicant's computing device is not within the first threshold distance from the approved origin, or a past trip number of the actual trip in the approved time period is not within the approved trip number.

13. The system of claim 9, further comprising:

14. The system of claim 9, wherein:

receiving, from one or more approval computing devices, the approval of the future planned itinerary comprising:

receiving a first approval from the first reviewing computing device;

receiving a second approval from the second reviewing computing device.

15. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform a method of approving and tracking a taxi, the method comprising:

16. The storage medium of claim 15, wherein the tracking information of the applicant computing device related to the applicant account during the actual trip comprises:

17. The storage medium of claim 15, wherein the tracking information of the applicant computing device related to the applicant account during the actual trip comprises:

18. The storage medium of claim 15, further comprising:

19. The storage medium of claim 15, further comprising:

20. The storage medium of claim 15, wherein:

receiving a first approval from the first reviewing computing device;

receiving a second approval from the second reviewing computing device.