WO2020122810A1 - Appareil serveur de communication, procédé et système de communication de gestion de codes d'autorisation pour des services associés au transport, appareil serveur de communication et procédé de traitement de code d'autorisation pour la réservation d'un service associé au transport, et dispositif de communication, procédé et système de communication de gestion de réservation d'un service associé au transport - Google Patents

Appareil serveur de communication, procédé et système de communication de gestion de codes d'autorisation pour des services associés au transport, appareil serveur de communication et procédé de traitement de code d'autorisation pour la réservation d'un service associé au transport, et dispositif de communication, procédé et système de communication de gestion de réservation d'un service associé au transport Download PDF

Info

Publication number
WO2020122810A1
WO2020122810A1 PCT/SG2018/050610 SG2018050610W WO2020122810A1 WO 2020122810 A1 WO2020122810 A1 WO 2020122810A1 SG 2018050610 W SG2018050610 W SG 2018050610W WO 2020122810 A1 WO2020122810 A1 WO 2020122810A1
Authority
WO
WIPO (PCT)
Prior art keywords
authorisation
data
code
codes
server apparatus
Prior art date
Application number
PCT/SG2018/050610
Other languages
English (en)
Inventor
Sriram Raghunath IYER
Wendy Japutra JAP
Jiaqi NIE
Chee Ming CHEW
Yee Chien Adeline QUEK
Guan LI
Original Assignee
Grabtaxi Holdings Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Grabtaxi Holdings Pte. Ltd. filed Critical Grabtaxi Holdings Pte. Ltd.
Priority to PCT/SG2018/050610 priority Critical patent/WO2020122810A1/fr
Priority to MYPI2021003215A priority patent/MY196382A/en
Priority to SG11202012022XA priority patent/SG11202012022XA/en
Publication of WO2020122810A1 publication Critical patent/WO2020122810A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G06Q20/145—Payments according to the detected use or quantity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/343—Cards including a counter
    • G06Q20/3437—Cards including a counter the counter having non-monetary units, e.g. trips
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Definitions

  • COMMUNICATIONS SERVER APPARATUS METHOD AND COMMUNICATIONS SYSTEM FOR MANAGING AUTHORISATION CODES FOR TRANSPORT-RELATED SERVICES, COMMUNICATIONS SERVER APPARATUS AND METHOD FOR PROCESSING AUTHORISATION CODE FOR BOOKING OF TRANSPORT-RELATED SERVICE, AND COMMUNICATIONS DEVICE, METHOD AND COMMUNICATIONS SYSTEM FOR
  • the invention relates generally to the field of communications.
  • One aspect of the invention relates to a communications server apparatus for managing authorisation codes for transport-related services.
  • Other aspects of the invention relate to a method for managing authorisation codes for transport-related services, a communications system for managing authorisation codes for transport-related services, a communications server apparatus for processing an authorisation code provided by a user making a request for booking of a transport-related service, a method for processing an authorisation code provided by a user making a request for booking of a transport-related service, a communications device for managing a request for booking of a transport-related service, a method for managing a request for booking of a transport-related service, and a communications system for managing a request for booking of a transport-related service.
  • Further aspects relate to a computer program product, a computer program and a non-transitory storage medium having instructions for implementing any one of the methods described herein.
  • One aspect of the invention has particular, but not exclusive, application to managing authorisation codes for bookings of transport-related services.
  • the authorisation codes may be generated, redeemed, revoked and remain valid for a time period and expire thereafter.
  • validation of the authorisation codes Prior to successful bookings of transport-related services, validation of the authorisation codes is carried out. Each authorisation code is redeemable once, i.e., the code is valid for a single redemption.
  • promo codes are typically loaded with a credit value to offset the cost of the ride, and in this case, a 100% credit offset of the ride is provided, which is then consolidated and billed to the company at the end month (corporate billing).
  • promo codes are issued by a service provider to companies. Companies have to approach the service provider for the promo codes by batch request and the service provider then has to manually generate these codes with a standard turnaround time. Thereafter, the promo codes are manually disbursed (e.g., via CSV (comma- separated values) format file) to the company who requested for the codes, which then disburses these codes to their employees.
  • CSV common- separated values
  • the service provider manually generates a large number of 100% off promo codes, link the promo codes to a list of employees provided by the corporate administrator, and then send the codes to the corporate administrator via email.
  • a service provider may provide such services to thousands of companies, and, on average, a service provider may be required to issue thousands of such 100% off promo codes per month to each company.
  • the companies are unable to generate the codes directly themselves, and, the service provider has to incur thousands of man hours generating the promo codes. As most of the steps are managed with manual operation and offline communication, it is error-prone with low productivity.
  • promo codes are open to abuse as each has a credit value to offset 100% of the ride.
  • promo codes will often be generated to reduce manual work, and, as there is no spending limit applied to those promo codes, companies have concerns on the lack of control on total corporate ride spending.
  • Another current approach includes having a company issue a hardcopy voucher for an employee that gives the employee both a budget (amount to spend on rides) and a fixed amount of rides that the employee can take in a month.
  • a budget amount to spend on rides
  • a fixed amount of rides that the employee can take in a month.
  • Implementation of the techniques disclosed herein may provide significant technical advantages. This includes generation of one or more data records, which may enable proper management of authorisation codes, including generation of authorisation codes, and monitoring/tracking of the authorisation codes, including redemption of the authorisation codes.
  • the techniques disclosed herein may include generation of authorisation codes for transport-related services for use by persons associated with a non-human entity for which the authorisation codes are generated.
  • the authorisation codes may be generated on-demand.
  • the authorisation codes are valid for corresponding periods and each authorisation code is redeemable once.
  • Each authorisation code acts as a permission code for the purpose of booking of a transport-related service.
  • each authorisation code is devoid of a monetary value (or credit value), or in other words, there is no monetary value associated with each authorisation code.
  • the techniques disclosed herein may provide for a process for validating authorisation codes for the purpose of bookings of transport- related services. This is to determine that the authorisation code to be redeemed is a valid code and remains redeemable, the user providing the authorisation code is a person associated with a non-human entity that is, in turn, associated with the authorisation code, etc. Such a validation process may help to prevent non- authorised persons from outside of the non-human entity from using authorisation codes associated with the non-human entity.
  • the techniques disclosed herein may allow for implementation of conditions or company policies to govern use or redemption of authorisation codes for transport-related services.
  • the techniques disclosed herein allow for tracking of authorisation codes and their corresponding status, including redeemed authorisation codes and details of the specific transport-related service associated with a particular redeemed authorisation code.
  • FIG. 1 is a schematic block diagram illustrating an exemplary communications system involving a communications server apparatus.
  • FIG. 2A shows a schematic block diagram illustrating a communications server apparatus for managing authorisation codes for transport-related services.
  • FIG. 2B shows a schematic block diagram illustrating a data record.
  • FIG. 2C shows a flow chart illustrating a method performed in a communications server apparatus for managing authorisation codes for transport-related services.
  • FIG. 2D shows a schematic block diagram illustrating a communications server apparatus for processing an authorisation code provided by a user making a request for booking of a transport-related service
  • FIG. 2E shows a flow chart illustrating a method performed in a communications server apparatus for processing an authorisation code provided by a user making a request for booking of a transport-related service.
  • FIG. 2F shows a schematic block diagram illustrating a communications device for managing a request for booking of a transport-related service.
  • FIG. 2G shows a flow chart illustrating a method performed in a communications device for managing a request for booking of a transport-related service.
  • FIG. 3 shows a flow chart illustrating a comparison between the techniques disclosed herein relating to authorisation codes, and the known approach relating to promo codes.
  • FIGS. 4A to 4D show a series of screenshots of a "Group Settings" page for setting of authorisation code (or trip code) usage.
  • FIG. 5 shows a flow chart illustrating the generation of authorisation codes.
  • FIGS. 6A to 6M show a series of screenshots illustrating the "Voucher Code” page of the portal for generating authorisation codes and the process of generating the authorisation codes.
  • FIG. 7 shows an example of downloaded authorisation codes in a CSV (Comma- separated values) format.
  • FIG. 8 shows a flow chart illustrating the redemption of authorisation codes.
  • FIGS. 9A to 9D show a series of screenshots illustrating an App for booking a corporate ride.
  • FIG. 10 shows a schematic diagram illustrating data fields or records of entities stored in the database corresponding to the management of the authorisation codes.
  • Various embodiments may relate to authorisation codes or trip voucher codes for corporate rides, including, for example, an authorisation (permission) code generation and redemption mechanism which manages trip permission for companies requiring employees to apply an authorisation code (or trip voucher code) before taking a corporate ride in line with their company policy.
  • Each authorisation code may be a single trip permission code.
  • the authorisation code may be used as a form of pre-trip permission, limiting abuse / fraud by employees. Non-employees may also be prevented from using the authorisation codes, further reducing abuse / fraud.
  • the present techniques may address these problems with the following addressing issues (a) and/or (b) mentioned above.
  • the present techniques may provide a solution for companies with an online/web portal that may enable them to set policies and they may be enforceable and validated instantly in the corresponding mobile App of employees, via their communications devices, when they book an on-demand business ride.
  • One of the policies is the ability for companies to mandate certain employee groups (e.g., teams/departments) to require an authorisation (or trip voucher) code to be inputted in the mobile App before they can proceed with a business transport booking. Further, this may enable the employee to pick one of the payment methods associated with the company (if available) within the mobile App, e.g., corporate billing option, which is a direct post-paid billing charged to the company so that the employee does not need to pay upfront.
  • a company administrator may, on the portal, enable a policy that employees must input an authorisation or trip voucher code permitting them to take a ride only (single trip) before they can proceed with a business ride booking (tagged to a company account).
  • Companies may be able to create their required list of authorisation or voucher codes for the current month and up to 2 months in advance with a variable quantity of the codes within the portal.
  • the companies may then assign one or more codes to one or more groups of employees who may require an authorisation code in order to make a valid booking for a ride. All trips taken by the employees will be logged online on the portal, indicating the exact authorisation or trip voucher code used for the companies to do their end month checks and reconciliation.
  • the present techniques automate the generation and redemption of trip authorisation or permission codes, resolving the operational overhead associated with the current known manual solutions, while reducing errors in the redemption process.
  • the codes generated function as permission codes with no credit value, only authorising the employee to take a single business or corporate ride that is in line with the company policy. All this is done digitally via the online/web portal for the companies and the corresponding mobile App for the employees.
  • the present techniques provide for the creation of a mechanism for companies to generate and download a set of "authorisation codes” or “trip voucher codes” that function only as permission codes with no credit value. These codes may then be managed by the company using their existing employee management process, and distributed in the company's preferred way to their employees as needed. Each trip voucher code grants an employee permission to take exactly one (single) ride.
  • Authorisation codes are also constrained to the company that generated the codes, and cannot be used by non-employees of the company, such as employees of other companies.
  • An extension of the above-mentioned mechanism may be to allow a company to generate its own custom named list of "authorisation codes", the difference being that these lists can have customer specific meaning, like a list of expense center codes that are used for categorisation of corporate rides by employees.
  • an enhancement to the mechanism may be on-demand generation and digital distribution of authorisation codes by individual employees instead of in bulk (e.g., by a corporate administrator).
  • the present techniques may provide one or more of the following: (i) separating the trip permission from the payment mechanism (no credit value attached to authorisation or trip voucher codes); (ii) allowing companies to generate the authorisation codes anytime; (iii) reducing operational burden for the service provider providing the corresponding services to the company; or (iv) digitising an offline and error-prone mechanism.
  • the communications system 100 includes a communications server apparatus 102, a first user (or client) communications device 104 and a second user (or client) communications device 106. These devices 102, 104, 106 are connected in or to the communications network 108 (for example, the Internet) through respective communications links 110, 112, 114 implementing, for example, internet communications protocols.
  • the communications devices 104, 106 may be able to communicate through other communications networks, such as public switched telephone networks (PSTN networks), including mobile cellular communications networks, but these are omitted from FIG. 1 for the sake of clarity. It should be appreciated that there may be one or more other communications devices similar to the devices 104, 106.
  • PSTN networks public switched telephone networks
  • the communications server apparatus 102 may be for managing authorisation codes for transport-related services and/or for processing an authorisation code provided by a user making a request for booking of a transport-related service.
  • the communications server apparatus 102 may be a single server as illustrated schematically in FIG. 1, or have the functionality performed by the communications server apparatus 102 distributed across multiple server components.
  • the communications server apparatus 102 may include a number of individual components including, but not limited to, one or more microprocessors (mR) 116, a memory 118 (e.g., a volatile memory such as a RAM (random access memory)) for the loading of executable instructions 120, the executable instructions 120 defining the functionality the server apparatus 102 carries out under control of the processor 116.
  • the communications server apparatus 102 may also include an input/output (I/O) module 122 allowing the server apparatus 102 to communicate over the communications network 108.
  • I/O input/output
  • User interface (Ul) 124 is provided for user control and may include, for example, one or more computing peripheral devices such as display monitors, computer keyboards and the like.
  • the communications server apparatus 102 may also include a database (DB) 126, the purpose of which will become readily apparent from the following discussion.
  • DB database
  • the user communications device 104 may include a number of individual components including, but not limited to, one or more microprocessors (mR) 128, a memory 130 (e.g., a volatile memory such as a RAM) for the loading of executable instructions 132, the executable instructions 132 defining the functionality the user communications device 104 carries out under control of the processor 128.
  • User communications device 104 also includes an input/output (I/O) module 134 allowing the user communications device 104 to communicate over the communications network 108.
  • a user interface (Ul) 136 is provided for user control. If the user communications device 104 is, say, a smart phone or tablet device, the user interface 136 may have a touch panel display as is prevalent in many smart phone and other handheld devices. Alternatively, if the user communications device 104 is, say, a desktop or laptop computer, the user interface may have, for example, one or more computing peripheral devices such as display monitors, computer keyboards and the like.
  • the user communications device 106 may be, for example, a smart phone or tablet device with the same or a similar hardware architecture to that of the user communications device 104.
  • the user communications device 104 and/or the user communications device 106 may be for managing a request for booking of a transport-related service.
  • FIG. 2A shows a schematic block diagram illustrating a communications server apparatus 202a for managing authorisation codes for transport-related services
  • FIG. 2B shows a schematic block diagram illustrating a data record 240 that may be generated by the communications server apparatus 202a.
  • the communications server apparatus 202a includes a processor 216a and a memory 218a, where the communications server apparatus 202a is configured, under control of the processor 216a to execute instructions in the memory 218a to, in response to receiving user request data including a data field indicative of a number of authorisation codes to be generated and a data field indicative of a period for which the authorisation codes are valid, determine whether a maximum number of authorisation codes predefined for the period has been exceeded, by comparison of the maximum number with a total number including the number of the authorisation codes to be generated for the period and, if there are existing authorisation codes previously generated for the period, a sum number of the existing authorisation codes, and, if the total number is less than or equal to the maximum number, the communications server apparatus 202a is further configured to generate one or more code data records 240 including a period data field 242 having data 244 corresponding to the period for which the authorisation codes are valid, and code data fields 246a, 246b, 246c, to 246n, wherein a
  • the processor 216a and the memory 218a may be coupled to each other (as represented by the line 217a), e.g., physically coupled and/or electrically coupled.
  • the processor 216a may be as described in the context of the processor 116 (FIG. 1) and/or the memory 218a may be as described in the context of the memory 118 (FIG. 1).
  • a communications server apparatus 202a for managing authorisation codes for transport-related services.
  • the server apparatus 202a may receive user request data relating to a request by a user for generating authorisation codes.
  • the request may be made, for example, via an online/web portal, where a connection or communication channel may be established between the communications server apparatus 202a and the portal.
  • the communications server apparatus 202a may check whether a maximum number (N max ) of authorisation codes that may be set corresponding to the period has been exceeded, by comparing the maximum number (N max ) with a total number (/V toto/ ) including the number (N nU m) of the authorisation codes to be generated for the period and, if there are existing authorisation codes previously generated for the period, a sum number (N SU m) of the existing authorisation codes.
  • N max may be one, two, three, ten, one hundred, or any higher number (e.g., up to thousands) that the user desires as the number
  • the communications server apparatus 202a may generate one or more data records 240 having a (time) period data field 242 with
  • IB data 244 indicative of the period for which the authorisation codes are valid
  • code data fields 246a, 246b, 246c, to 246n wherein a number of the code data fields that is generated corresponds to N nUm , and wherein, for each code data field 246a, 246b, 246c, to 246n, the communications server apparatus 202a may further generate a respective authorisation code (e.g., 248a, 248c) of the authorisation codes and data (e.g., 249a, 249c) indicative of a status of the respective authorisation code.
  • the code data fields 246a, 246b, 246c, to 246n may be associated with the period data field 242.
  • each code data field 246a, 246b, 246c, to 246n may have a generated respective authorisation code (e.g., 248a, 248c), and, therefore, the number of code data fields that are generated in the one or more code data records 240 is the same as the number, N nUm , of the authorisation codes that are generated.
  • the status associated with the authorisation code may be indicated, for example, as "Available”, “Unused”, “Active” or the like, to indicate that the authorisation code is redeemable.
  • the authorisation codes may be usable for authorising bookings of transport-related services.
  • Each authorisation code may act as a permission code for a booking.
  • Each authorisation code may also be defined as a trip voucher code.
  • each authorisation code can be redeemed only once, i.e., each authorisation code is usable for single redemption.
  • each authorisation code is a single-use code or a single-trip authorisation code for travel from an origin location to a destination location.
  • the communications server apparatus 202a may provide an alert to the user.
  • the alert may be provided without generating all of the number of the code data fields and the corresponding number of authorisation codes.
  • the alert may be provided without the communications server apparatus 202a proceeding to generate the code data fields and the authorisation codes, or, in other words, without generating any code data fields and any corresponding authorisation codes.
  • the alert may include at least one of an error message, a message that the maximum number of authorisation codes predefined for the month has been exceeded, or a message to request the user to modify the number of authorisation codes to be generated. Any other suitable messages or alerts may be provided.
  • each authorisation code (including authorisation codes 248a, 248c) may be valid for (a period of) one month, e.g., a defined single month. Nevertheless, it should be appreciated that each authorisation code may be valid for any suitable (time) period.
  • each authorisation code (including authorisation codes 248a, 248c) may be devoid of a monetary value (credit value). In other words, no monetary value is associated with each authorisation code.
  • the communications server apparatus 202a may further (under control of the processor 216a executing instructions (stored) in the memory 218a) generate one or more travel history data records, wherein, in response to an authorisation code (e.g., 248a, 248c) being redeemed for a particular transport-related service, the communications server apparatus 202a may further generate, in the one or more travel history data records, a redeemed code data field having the authorisation code that is redeemed, generate, in the one or more travel history data records, a travel data field having data corresponding to the particular transport-related service, and associate the redeemed code data field and the travel data field to each other. In this way, there may be records of the transport-related services that have been used or engaged and the exact authorisation code redeemed for each of the transport-related services engaged.
  • an authorisation code e.g., 248a, 248c
  • the data corresponding to the particular transport-related service may include at least one of time, day, starting (or origin) location, destination location, type of transport-related service, cost of the transport-related service, the person booking the transport-related service, etc.
  • the communications server apparatus 202a may further (under control of the processor 216a executing instructions (stored) in the memory 218a) update, in the code data field (e.g., 246a, 246b, 246c, to 246n) corresponding to the authorisation code, the data (e.g., 249a, 249c) indicative of the status in accordance with the change.
  • the data relating to the status of the authorisation code may be updated when the authorisation code, for example, has been redeemed, or revoked, or has expired, etc.
  • the communications server apparatus 202a may further (under control of the processor 216a executing instructions (stored) in the memory 218a) generate one or more entity data records including an entity data field having data corresponding to a non-human entity, and may further associate the one or more code data records 240 and the one or more entity data records to each other.
  • the authorisation codes may be associated with the non-human entity and usable (only) by the personnel or staff of the non-human entity.
  • the data corresponding to the non-human entity may include at least one of a name of the non-human entity or an identifier for the non-human entity.
  • the entity data field may also include data corresponding to corresponding persons or employees of the non-human entity.
  • non-human entity may mean, for example, a juridical person, company, corporation, organisation, association, or the like, as opposed to a natural person.
  • the communications server apparatus 202a may further (under control of the processor 216a executing instructions (stored) in the memory 218a) generate, in the one or more entity data records, a person data field having data corresponding to the persons. In this way, certain persons or groups of persons of the non-human entity may be required to use authorisation codes for transport-related services.
  • the communications server apparatus 202a may further (under control of the processor 216a executing instructions (stored) in the memory 218a) generate, in the one or more entity data records, a condition data field having data corresponding to the at least one condition.
  • one or more conditions or restrictions may be imposed to govern use of the authorisation codes.
  • one or more conditions that may be imposed may include time, day, vehicle type, location, type of transport-related service, etc.
  • the transport-related services may include or may be ride- hailing transportation services. This may include, for example, car-hailing, and (motor)bike-hailing services.
  • each of the authorisation codes e.g., 248a, 248c
  • each authorisation code may include or may be an alphanumeric code (e.g., a 6-character alphanumeric code). As such, each authorisation code may include a combination of one or more numbers and one or more letters.
  • the communications server apparatus 202a may be suitable for managing authorisation codes for transport-related services in a corporate setting, i.e., for corporate or business travels.
  • FIG. 2C shows a flow chart 250 illustrating a method, performed in a communications server apparatus for managing authorisation codes for transport- related services, and under control of a processor of the communications server apparatus.
  • a maximum number of authorisation codes predefined for the period is determined by comparison of the maximum number with a total number including the number of the authorisation codes to be generated for the period and, if there are existing authorisation codes previously generated for the period, a sum number of the existing authorisation codes.
  • one or more code data records are generated, including a period data field having data corresponding to the period for which the authorisation codes are valid, and code data fields, wherein a number of the code data fields that is generated corresponds to the number of the authorisation codes, and wherein, for each code data field, a respective authorisation code of the authorisation codes is generated and data indicative of a status of the respective authorisation code is generated, wherein the authorisation codes are usable for authorising bookings of transport- related services, and wherein each authorisation code is redeemable once.
  • the method may further include generating one or more travel history data records, wherein, in response to an authorisation code being redeemed for a particular transport-related service, a redeemed code data field having the authorisation code that is redeemed may be generated in the one or more travel history data records, a travel data field having data corresponding to the particular transport-related service may be generated in the one or more travel history data records, and the redeemed code data field and the travel data field may be associated to each other.
  • the data indicative of the status may be updated, in the code data field corresponding to the authorisation code, in accordance with the change.
  • the method may further include generating one or more entity data records including an entity data field having data corresponding to a non human entity, and associating the one or more code data records and the one or more entity data records to each other.
  • a person data field having data corresponding to the persons in response to receiving user request data including a data field indicative of persons associated with the non-human entity that are required to use the authorisation codes, a person data field having data corresponding to the persons may be generated in the one or more entity data records.
  • a condition data field having data corresponding to the at least one condition in response to receiving user request data including a data field indicative of at least one condition to be imposed on the transport-related services to be used with the authorisation codes, a condition data field having data corresponding to the at least one condition may be generated in the one or more entity data records.
  • the transport-related services may include or may be ride- hailing transportation services.
  • each of the authorisation codes may include or may be an alphanumeric code.
  • FIG. 2D shows a schematic block diagram illustrating a communications server apparatus 202d for processing an authorisation code provided by a user making a request for booking of a transport-related service.
  • the transport-related service may include or may be a ride-hailing transportation service.
  • the authorisation code may be provided by the user via a communications device, e.g., via an App installed on the communications device.
  • the communications server apparatus 202d includes a processor 216d and a memory 218d, where the communications server apparatus 202d is configured, under control of the processor 216d to execute instructions in the memory 218d to, in response to receiving user request data including a data field indicative of the provided authorisation code, data indicative of the user and data indicative of a non human unit, determine validity of the provided authorisation code against data 250d stored in the communications server apparatus 202d, wherein the data 250d includes first data 251d corresponding to a non-human entity and corresponding persons associated with the non-human entity, second data 252d corresponding to authorisation codes generated for the non-human entity and corresponding status of the generated authorisation codes, and third data 253d corresponding to corresponding periods for which the generated authorisation codes are valid.
  • the user making the request may be associated with the non-human unit.
  • the non human unit may be for the purpose for association with the provided authorisation code.
  • the data indicative of the non-human unit may be (pre-)provided or (pre-)set in the App and/or in the user communications device.
  • the communications server apparatus 202d is further configured to generate a booking of the transport-related service, wherein the matched generated authorisation code is redeemable once.
  • the matched generated authorisation code may be redeemed.
  • the matched generated authorisation code may be devoid of a monetary value (credit value). If the provided authorisation code is determined to be invalid in relation to at least one of the first data 251d, second data 252d, or third data 253d, the communications server apparatus 202d is further configured to provide an alert to the user without booking of the transport-related service.
  • the processor 216d and the memory 218d may be coupled to each other (as represented by the line 217d), e.g., physically coupled and/or electrically coupled.
  • the processor 216d may be as described in the context of the processor 116 (FIG. 1) and/or the memory 218d may be as described in the context of the memory 118 (FIG. 1).
  • the validity of the provided authorisation code may be determined or checked against the first data 251d to determine whether the non-human unit matches the non-human entity (in other words, whether the non-human unit and the non-human entity are the same) and the user is part of or belongs to the non human entity (e.g., an employee of the non-human entity).
  • the validity of the provided authorisation code may be determined or checked against the second data 252d to determine whether the provided authorisation code matches a pre-generated or existing authorisation code associated with the non human entity, and whether the matched generated authorisation code remains active and usable/redeemable, e.g., not previously redeemed, has not expired or revoked.
  • the validity of the provided authorisation code may be determined or checked against the third data 253d to determine whether the provided authorisation code is usable or valid for the period (e.g., month) in which the request for the transport- related service is made (e.g., matches the current real-time period).
  • the first data 251d may be comprised in, or is part of data in an entity data field of a data record stored in the communications server apparatus 202d.
  • the second data 252d may be comprised in, or is part of data in code data fields of a data record stored in the communications server apparatus 202d.
  • the third data 253d may be comprised in, or is part of data in a period data field of a data record stored in the communications server apparatus 202d.
  • the code data fields and the period data field may be comprised in one or more code data records (e.g., 240, FIG. 2B), and/or the entity data field may be comprised in one or more entity data records.
  • the first data 251d, the second data 252d, and the third data 253d may be separate data or part of respective separate data sets, or the first data 251d, the second data 252d, and the third data 253d may be part of a (same) larger data set.
  • the communications server apparatus 202d may be separate or a different server apparatus from the communications server apparatus 202a, or may be part of the communications server apparatus 202a, or may be a larger server apparatus that includes the communications server apparatus 202a, or may be the communications server apparatus 202a (i.e., a server communications server apparatus that may perform the functions of the communications server apparatus 202a and the communications server apparatus 202d).
  • the communications server apparatus 202a and the communications server apparatus 202d may have a similar hardware or architecture.
  • FIG. 2E shows a flow chart 260 illustrating a method, performed in a communications server apparatus for processing an authorisation code provided by a user making a request for booking of a transport-related service, and under control of a processor of the communications server apparatus.
  • user request data including a data field indicative of the provided authorisation code, data indicative of the user and data indicative of a non-human unit
  • validity of the provided authorisation code is determined against data stored in the communications server apparatus, wherein the data include first data corresponding to a non-human entity and corresponding persons associated with the non-human entity, second data corresponding to authorisation codes generated for the non-human entity and corresponding status of the generated authorisation codes, and third data corresponding to corresponding periods for which the generated authorisation codes are valid.
  • the provided authorisation code is determined to be valid in relation to the first data in that the non-human unit matches the non-human entity and the user is a person associated with the non-human entity
  • the second data in that the provided authorisation code matches a generated authorisation code for the non-human entity and the corresponding status is indicative that the matched generated authorisation code is redeemable
  • the third data in that the period for which the matched generated authorisation code is valid matches the period in which the request is made, a booking of the transport-related service is generated (in which the matched generated authorisation code may be redeemed), wherein the matched generated authorisation code is redeemable once.
  • the transport-related service may include or may be a ride- hailing transportation service.
  • FIG. 2F shows a schematic block diagram illustrating a communications device 204 for managing a request for booking of a transport-related service.
  • the transport-related service may include or may be a ride-hailing transportation service.
  • the communications device 204 includes a processor 228 and a memory 230, where the communications device 204 is configured, under control of the processor 228 to execute instructions in the memory 230 to, in response to receiving user request data including a data field indicative of an origin location, a data field indicative of a destination location, and a data field indicative of an authorisation code for the transport-related service, generate data 255 corresponding to the origin location, the destination location, the authorisation code and the user making the request, wherein the authorisation code is usable for authorising booking of the transport- related service, and is redeemable once, and transmit the data to a communications server apparatus (e.g., 202d, FIG. 2D) for processing for booking of the transport- related service.
  • a communications server apparatus e.g., 202d, FIG. 2D
  • the processor 228 and the memory 230 may be coupled to each other (as represented by the line 229), e.g., physically coupled and/or electrically coupled.
  • the processor 228 may be as described in the context of the processor 128 (FIG. 1) and/or the memory 230 may be as described in the context of the memory 130 (FIG. 1).
  • additional data indicative of a non-human unit may be transmitted together with the data 255 to the communications server apparatus for processing for booking of the transport-related service.
  • the authorisation code may be devoid of a monetary value (credit value).
  • the user request data may be provided by the user via an App installed on the communications device 204.
  • FIG. 2G shows a flow chart 270 illustrating a method, performed in a communications device for managing a request for booking of a transport-related service, and under control of a processor of the communications device.
  • user request data including a data field indicative of an origin location, a data field indicative of a destination location, and a data field indicative of an authorisation code for the transport-related service
  • data corresponding to the origin location, the destination location, the authorisation code and the user making the request are generated, wherein the authorisation code is usable for authorising booking of the transport-related service, and is redeemable once, and, at 274, the data are transmitted to a communications server apparatus for processing for booking of the transport-related service.
  • the transport-related service may include or may be a ride- hailing transportation service.
  • a user communications device may include, but not limited to, a smart phone, tablet, handheld/portable communications device, desktop or laptop computer, terminal computer, etc.
  • an "App” or an “application” may be installed on a user communications device and may include processor-executable instructions for execution on the device.
  • booking of a transport-related service may be carried out via an App.
  • a computer program product having instructions for implementing at least one of method for managing authorisation codes for transport-related services, method for processing an authorisation code provided by a user making a request for booking a transport-related service, or method for managing a request for booking of a transport-related service as described herein.
  • a computer program having instructions for implementing at least one of method for managing authorisation codes for transport-related services, method for processing an authorisation code provided by a user making a request for booking a transport-related service, or method for managing a request for booking of a transport-related service as described herein.
  • Non-transitory storage medium storing instructions, which, when executed by a processor, cause the processor to perform at least one of method for managing authorisation codes for transport-related services, method for processing an authorisation code provided by a user making a request for booking a transport-related service, or method for managing a request for booking of a transport-related service as described herein.
  • Various embodiments may further provide a communications system for managing authorisation codes for transport-related services, having a communications server apparatus, at least one user communications device and communications network equipment operable for the communications server apparatus and the at least one user communications device to establish communication with each other therethrough, wherein the at least one user communications device includes a first processor and a first memory, the at least one user communications device being configured, under control of the first processor, to execute first instructions in the first memory to, in response to receiving first request data including a data field indicative of a number of authorisation codes to be generated and a data field indicative of a period for which the authorisation codes are valid, generate data corresponding to the number of authorisation codes and the period, and transmit the data for receipt by the communications server apparatus for processing, and wherein the communications server apparatus includes a second processor and a second memory, the communications server apparatus being configured, under control of the second processor, to execute second instructions in the second memory to, in response to receiving second request data indicative of the data transmitted by the at least one user communications device, determine whether a maximum number of authorisation
  • Various embodiments may further provide a communications system managing a request for booking of a transport-related service, having a communications server apparatus, at least one user communications device and communications network equipment operable for the communications server apparatus and the at least one user communications device to establish communication with each other therethrough, wherein the at least one user communications device includes a first processor and a first memory, the at least one user communications device being configured, under control of the first processor, to execute first instructions in the first memory to, in response to receiving user request data including a data field indicative of an origin location, a data field indicative of a destination location, and a data field indicative of an authorisation code provided for the transport-related service, generate data corresponding to the origin location, the destination location, the provided authorisation code, the user making the request, wherein the data further includes additional data indicative of a non-human unit, wherein the authorisation code is usable for authorising booking of the transport-related service, and is redeemable once, and transmit the data for receipt by the communications server apparatus for processing for booking of the transport-related service, and wherein
  • the techniques disclosed herein may offer a much higher level of security, as the usage of authorisation or trip voucher codes may be limited to the employees of the company authorised to use the code, and the company's administrators generate the codes directly.
  • Each code also may have no credit value attached and may serve as a permission code only, and cannot be used as a promo code. This is in contrast to known promo codes and hard copy vouchers that can be used by anyone.
  • the administrators of the company have a centralised online/web portal (offered by a code service provider) with trip policies feature that enables them to
  • BO generate the authorisation or trip voucher codes directly and enable other transport policies (e.g., time, day, vehicle type, location, etc.) jointly.
  • the administrators are able to track all employees who have taken corporate rides with an authorisation code anytime, anywhere. This is an improvement over known approaches where the company's administrator is unable to track rides online until the code service provider sends a month-end report which becomes a hassle in month-end reconciliation. This is also an improvement from some other known approaches which do not have the combination of trip policies with trip permissions checks for employees.
  • the administrators can choose to generate their own codes anytime for a corresponding period, for example, for the current month and up to 2 months in advance compared to known approaches which require the code service provider to supply the promo codes to the administrators instead.
  • the administrators can download the authorisation voucher codes that they have generated, e.g., in CSV (comma-separated values) format, and disseminate these codes (e.g., unique alphanumeric codes) in their preferred method anytime.
  • CSV code-separated values
  • the techniques disclosed herein may incorporate the process for approval of a business ride and/or digital distribution of authorisation codes to individual employees. As such, the approval procedure and/or distribution of the codes may be automated.
  • the permission may be an authorisation code to be filled into the trip code field (e.g., in a "tag this trip” section) in the corresponding App.
  • the corporate administrators can generate batches of codes according to their need by themselves, e.g., via an online/web portal provided/administered by a code service provider, then download and distribute those codes to the respective administrators of different departments. The employees will follow the established procedure to apply for corporate ride approval, then get the code from the department administrator.
  • FIG. 3 shows a flow chart 360 illustrating a comparison between the techniques disclosed herein relating to authorisation (permission) codes, and the known approach relating to promo codes.
  • the company's administrator may set the trip code to be mandatory as authorisation code in the company's settings, to indicate that employees need a permission code for each business ride;
  • the company's administrator may generate the authorisation codes, which may be either uploaded to an internal system or be downloaded to a CSV file for later distribution;
  • Trip code to be mandatory as a ride categorisation information Some companies might require the employees to input some predefined codes, such as project codes, cost center codes, etc., to categorise the trip.
  • the company employees will be required to input a valid authorisation code into the "Trip Code" field to take a corporate ride.
  • trip code usage may be set up from the company settings in the online portal.
  • categorisation and permission code some companies may need to make trip code to be mandatory only for specified groups instead of applying to all groups. Therefore, if any one of these two options is chosen, the relevant groups (or employees) have to be specified.
  • the BB always have to input a trip code for taking corporate rides.
  • the trip code can be free text and there is no validation on the code. However, inputting the trip code will be optional for the employees who do not belong to any of the chosen groups.
  • a company administrator may log into the online portal provided/administered by a code service provider to set up the trip code usage for the company.
  • the company administrator may access a "Group Settings" page, where the administrator may enable the relevant policy for "Trip Code” and, where necessary, may assign the policy to one or more employee groups.
  • FIGS. 4A to 4D show a series of screenshots of a "Group Settings" page for setting of authorisation code (or trip code) usage, illustrating the trip authorisation code (voucher code) setting flow.
  • FIG. 4A illustrating an initial view of the "Group Settings", there may be three sections, including a "General" group tag section 460, a "Trip code” field section 462, and a “Trip description” field section 464.
  • the "General" group tag section 460 may provide two selection options for the company administrator.
  • the first option 460a is for a "General" option to be shown or visible (which, therefore, may allow employees to select the "General” option), which may be selected by the company administrator if the company does not have any employee groups, and another option 460b for the "General" option to be hidden (which, therefore, may restrict employees from selecting it), which may be selected by the company administrator if the company has employee groups with policies settings.
  • codes may be assigned to the employee groups. Otherwise, the option 460a may be selected to apply to all employees, if there are no employee groups.
  • the "Trip code” field section 462 may provide three options that may be selected or set by the company administrator. These selection options include “Optional” 462a where it is up to the employee whether or not to fill in anything in the "Trip Code” field of the PAX App, "Mandatory for trip categorisation” 462b where the employee has to input a certain code (e.g., an expense code) in the "Trip Code” field of the PAX App, and "Mandatory as voucher code” 462c where the employee has to input an authorisation code into the "Trip Code” field of the PAX App to be validated before taking a corporate ride. Each of the options 462a, 462b, 462c may be assigned to one or more employee groups.
  • Each employee group can only belong to one of the options 462a, 462b, 462c, i.e., assigned to one policy (e.g., either trip code as trip voucher code (authorisation code) per option 462c, or trip code as categorisation (mandatory free text field) per option 462b.
  • one policy e.g., either trip code as trip voucher code (authorisation code) per option 462c, or trip code as categorisation (mandatory free text field) per option 462b.
  • the "Trip description” field section 464 may provide two options that may be selected or set by the company administrator. These selection options include “Optional” 464a where it is up to the employee whether or not to fill in a description for the trip in the "Trip Description” field of the PAX App, and “Mandatory” 464b where the employee has to input a description of the trip in the "Trip Description” field of the PAX App. Each of the options 464a, 464b may be assigned to one or more employee groups. Each employee group can only belong to one option.
  • FIG. 4B shows a screenshot of the "Group Settings” page where the "Mandatory as voucher code” option 462c has been selected, and an additional field 463 is made available or active for selection of one or more employee groups to which the option 462c is to be applied to.
  • FIGS. 4C and 4D show examples of screenshots illustrating selection of some employee groups in the selection field 463.
  • a company administrator may be placed in charge of trip permission code management, and the code management tasks may include code generation, revoking, downloading and code usage viewing (including the particular code used for a specific trip/ride).
  • Trip authorisation codes may be alphanumeric codes, for example, a series of 6- character alphanumeric codes, which are unique for the same company.
  • Authorisation codes generated for a particular month will be valid only for that month. This may mean that codes generated for a particular month will be valid only till the last day of that month and will expire at midnight on the last day of that month. For example, codes generated on January 1 for January will be valid till January 31; code generated on January 29 for January will be valid until January 31, code generated on January 29 for March will be valid from March 1 to March 31.
  • Authorisation codes can only be used by the employees whose group requires trip authorisation codes. Where an employee whose group does not require an authorisation, even when a valid trip authorisation code is inputted in the App for his/her corporate ride, the code will not be redeemed.
  • the status for a code may be as follows:
  • the generation of trip authorisation codes may be performed via the portal frontend, in accordance with the flowchart as illustrated in FIG. 5.
  • a user e.g., a corporate administrator
  • a determination is made as to whether the sum of the number of the codes to be generated and any previously generated number of codes for the same month Y, exceeds the maximum number allowable for that month. If the response is "Yes” an error prompt is provided at 566. If the response is "No", the job of generating the codes is sent to an async worker who, at 570, picks up the job.
  • DB database
  • an "async worker” refers to a software program that runs asynchronously (as opposed to on-demand) and performs a task assigned to it, for example, generating codes in this case in the disclosed techniques.
  • the corporate administrator shall be able to generate codes to be distributed to different groups.
  • Some features relating to code generation may include, but not limited to the following.
  • the corporate administrator may be able to generate codes for the current month, as well as for the next 2 months (i.e., in advance for up to 2 months from the current month). Since the authorisation or permission code may be valid for a calendar month; the corporate administrator may need to generate the codes month-by- month (e.g., codes valid for January, codes valid for February, etc.), but the codes need not be created during the respective months the codes are to be valid for, but may be, for example, 2 months in advance of the current real-time month.
  • the corporate administrator shall be able to download the authorisation codes after the codes have been generated.
  • the corporate administrator shall be able to revoke a batch of unused authorisation codes which have been generated (e.g., due to breach or other reasons).
  • the corporate administrator shall be able to view the authorisation codes generated for the current month, the next 2 months, as well as the code generation history of the last 12 months.
  • a tab page of "Voucher Code” is added to the "Policies" Tab that is part of a Menu available to the corporate administrator.
  • the corporate administrator may select the "Voucher Code” page, where the corporate administrator can manage the codes (for example, see FIGS. 6A and 6B as part of a series of screenshots illustrating the "Voucher Code” page of the portal for generating authorisation codes, and the process of generating the authorisation codes, i.e., trip authorisation code (voucher code) flow.
  • a code generation page 664 is displayed, as shown in FIG. 6D.
  • a number of fields are provided, for example, a field 666 for the "Issue Month” (or the month in which the codes are valid), a field 668 for inputting the number of codes to be generated, and a field 670 for inputting of a description (which is optional).
  • a “Generate Codes” button 672 which upon clicking, will lead to generation of the codes in accordance with the request.
  • the specified number of codes will be generated for the chosen month. For this page 664, only the current month and the next (subsequent) 2 months may be chosen from the drop down list of months in the field 666.
  • the generated codes shall be valid for all groups which require permission or authorisation codes. Further, the maximum number of codes per month may be set to be 10,000.
  • an error message (e.g., "Error in code generation !) may be shown to the user, as may be seen in FIG. 61.
  • the generated codes may now be available for download.
  • the generated codes are unique codes listed in an alphanumeric format, and the document to be downloaded, containing the codes, may be in the Excel (spreadsheet) format or CSV format.
  • the document may be shared via various communication channels, e.g., SMS (short message service), email, etc.
  • the "Voucher Code” page 660 shows a section 676 listing batches of codes that are active, and another section 678 listing batches of codes that have expired.
  • the expired code batches in the section 678 may be shown (see FIG. 6J) or hidden (see FIG. 6K) by toggling the button 680. All the previous code batches may be listed in the "Voucher Code” page 660. Filtering may be carried out to show particular code batches of interest. As a non limiting example, referring to FIGS. 6L and 6M, the code batches may be filtered according to the month or range of months in which requests for code generation 5 were made ("Creation Time"). The month(s) may be selected in the field 682 for filtering.
  • the corporate administrator can download the codes generated for each batch whenever he/she wants.
  • the codes may be downloaded in CSV (Comma-separated values) format, and the default name of the csv file may be [MMM YYYY]- [DDMMYYYY-HHmmSS].csv. For example, if a batch of codes for April 2018 is 20 downloaded on 2018-03-27 at 17:03:22, the file name is "Apr 2018 - 27032018- 170322. csv".
  • a non-limiting example of a CSV file 760 may be as shown in FIG. 7.
  • the header part 762 of the CSV file 760 may contain information of the code creator, creation 25 time, valid month, creation note, as well as download time.
  • the main body 764 of the CSV file 760 may contain 2 columns, where the first column 766 may include the codes, and the second column 768 may include the corresponding status of each code.
  • the employee For an employee taking a corporate ride, the employee has to enter the authorisation code in the corresponding App for booking the corporate ride.
  • the trip code field in the App shall be displayed as "Trip voucher (mandatory)".
  • the backend system (including server) checks the validity of the authorisation code that is inputted, based on the employee group and the code. If the code is invalid, the employee shall be prevented from booking the corporate ride.
  • the employee or user requiring a corporate ride enters, in the App, the relevant booking details, e.g., origin (or starting point), destination (or ending point), the type of transport- related services (e.g., the type of ride-hailing transportation service).
  • the user selects the relevant employee group tag and keys in the 6-character authorisation code in the "Trip Code field" within the App.
  • the employee may choose "Options" 962 within the App 960 and subsequently tag the ride (in the "Tag” field 964) to a "group” under the company account, for example, by clicking on "Personal" 966.
  • the group "Design" 964a is tagged.
  • the authorisation code (or trip voucher code) may then be inputted in the "Trip Code” field 968 within the App 960.
  • the employee may click on "Payment" option 970 and come to a Payment menu 972, as shown in FIG. 9D, to proceed with the booking, where the employee may be able to choose a payment method from a number of personal payment options 974, or corporate billing 976 (this option is shown selected in FIG. 9D) to be charged to the company.
  • Corporate billing 976 only appears if this is enabled for the specific employee, which enables the employee to charge the cost of the ride direct to the company. Otherwise, the employee may choose one of the personal payment options 974.
  • the authorisation code provided by the user in the mobile App is sent to a "Passenger API (Application Programming Interface)" (which refers to a common set of APIs called by the App), which then passes it to a "Booking Service API” (which refers to an internal set of APIs that are used to invoke transport booking functions, e.g., book a ride, cancel a ride, etc.), which will verify with the "Business API” (which refers to an internal set of APIs that determine, for example, if a ride being booked is a business ride, if it matches rules set-up by the administrator, etc.) to ensure that the authorisation or permission code is valid.
  • the authorisation code is kept as a Unicode (Universal Coded Character Set) string format to ensure there is no data corruption as it passes through the different systems.
  • the validation may include one or more of checking whether the code exists, whether the code belongs to the company which the user is in, whether the code is valid for the period or month when the booking is created, and whether code is still available (i.e., not previously used/redeemed).
  • the authorisation code is determined to be invalid, at 868, an error prompt is provided, where the booking is disallowed. If the authorisation code is found to be valid, the ride booking may proceed at 870. The process then proceeds to 872 to end the process.
  • the code shall be redeemed.
  • the redeemed code may appear in a "trip code field" in "trip statements" (CSV) downloaded from a "Trips Page" within the online/web portal.
  • CSV trip statements
  • the employee may access the online/web portal, search for the trip and click on "download” to retrieve a ride statement, where the code appears under a "Trip Code” Field.
  • the company employee may also go to the "History” page of the employee's App and find the ride booking.
  • the employee may click on a "tag this ride” section and may be able to see if there's a trip code applied in the trip code field.
  • a report may be generated or provided to the administrators, where they may be able to see the issued, used, revoked and available permission codes for each generated batch of authorisation codes.
  • An administrator is also able to download the authorisation codes for processing in external systems in CSV format.
  • Eligible payment methods may include one or more payments to be made by the company (if available to the employee) or one or more personal payment methods.
  • TripVoucherBatch data field 1062 where a record of this entity represents a generation job submitted on the portal, where the company administrator specifies how many codes to be generated for a selected month.
  • data 1062a for "id" data 1062a for "id"
  • TripVoucherCode data field 1064 where a record of this entity represents a code that can be used on the App to authorise a single trip.
  • data 1064a for "id” data 1064a for "id"
  • trip_voucher_batchJd data 1064b that provides a link of the "TripVoucherBatch” data field 1062
  • a "companyjd” data 1064c that provides a link of the "TripVoucherCode” data field 1064 to the "Company” data field 1060.
  • the "id” data 1062a and the “trip_voucher_batchJd” data 1064b may contain similar data.
  • the "id” data 1060a, the "companyjd” data 1062b, and the "companyjd” data 1064c may contain similar data.
  • Each "TripVoucherBatch" record may have many "TripVoucherCode” records (e.g., 1064) created and linked thereto.
  • techniques e.g., including use of an online/web portal
  • authorisation codes or trip voucher codes
  • the authorisation voucher code is filled in as part of the booking details, and the validity of the code may be checked before allowing the booking to proceed, and consequently, the code may be redeemed.
  • Such authorisation codes effectively act as permission codes.
  • Company policies may be set to govern management of the authorisation codes, e.g., restrictions in terms of time, day, vehicle type (or fleet type), location, etc. for the business rides for booking using the codes.
  • the techniques may provide one or more of the following:
  • Generating authorisation codes (e.g., alphanumeric codes) in batches and up to 2 months in advance, with codes being valid only for a particular period or month.
  • An authorisation code or a batch of authorisation codes may be requested, e.g., via a user interface of a portal, to be generated.
  • An asynchronous task may be spun off. This task creates one or more immutable authorisation codes, including an immutable batch of authorisation codes, and the user interface may be updated with a "Download" link that allows the generated code(s) to be obtained or downloaded.
  • Each generated authorisation code may have no value or no credit value, and, as such, may serve as a permission code only to authorise a (business) trip, and the code is also dissociated from the payment mechanism. This is in contrast to known "100% off promo code" which has a credit value to nullify the payment charge an end user has to make, effectively making it a zero-fare ride for the end user.
  • Each authorisation code is applicable only for a single (business) ride/trip (i.e., one time redemption). Accordingly, if an employee requires a return trip, the employee requires 2 codes, one code for an outbound journey and another code for an inbound journey.
  • Authorisation codes are unique to the company for which the codes are generated for, or the company that generates the codes. This means that only employees of said company may use and redeem the codes. Company employees need to be registered before they can take corporate/business rides. While a non-employee who is not registered may attempt to use such an authorisation code, the code will not be validated for use/redemption by the non-employee.
  • Custom software was written to generate the "Authorisation (or Trip Voucher) Codes", and the management of the mentioned codes.
  • the generated codes are unique per company that is registered in the system.
  • each authorisation code is a one-time permission code
  • the custom software has to ensure that codes that were used (or redeemed) before could not be used again, taking into consideration race conditions. Also, for situations for ride cancellations and non-allocations, the codes need to be usable again immediately, and, therefore, the system requires custom software to be written to ensure the correct behaviour.
  • a corporate or company administrator may be any employee of the company who may have access to the online/web portal provided/administered by the code service provider in order to generate the authorisation codes.
  • the corporate administrator may also be able to set company policies relating to travels via the portal and may be able to track the status of various past and present authorisation codes, amongst others.
  • the present techniques may be suitable for companies who have requirements on strict control on corporate rides.
  • the present techniques may provide one or more of the following: (i) centralised control of corporate rides, (ii) full control of trip authorisation code creation and distribution, (iii) spent limit control, and (iv) no more offline communication for trip authorisation code.
  • the present techniques there may be better control on code usage. Further, the present techniques may remove the need for the low-productivity and error-prone manual code generation, and may manage work from the flow.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Telephonic Communication Services (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un appareil serveur de communication permettant de gérer des codes d'autorisation pour des services associés au transport, qui est configuré pour, en réponse à la réception de données de demande d'utilisateur, déterminer si un nombre maximal de codes d'autorisation prédéfini pour une période a été dépassé et, si le nombre maximal n'a pas été dépassé, l'appareil serveur est configuré pour produire un ou plusieurs enregistrements de données de code ayant un champ de données de période comportant des données correspondant à la période, et des champs de données de code, où, pour chaque champ de données de code, l'appareil serveur de communication est aussi configuré pour produire un code d'autorisation respectif des codes d'autorisation et des données représentant un état du code d'autorisation respectif, les codes d'autorisation étant utilisables pour autoriser des réservations de services associés au transport, et chaque code d'autorisation étant échangeable une fois, et, si le nombre maximal a été dépassé, l'appareil serveur de communication est configuré pour fournir une alerte à l'utilisateur.
PCT/SG2018/050610 2018-12-13 2018-12-13 Appareil serveur de communication, procédé et système de communication de gestion de codes d'autorisation pour des services associés au transport, appareil serveur de communication et procédé de traitement de code d'autorisation pour la réservation d'un service associé au transport, et dispositif de communication, procédé et système de communication de gestion de réservation d'un service associé au transport WO2020122810A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/SG2018/050610 WO2020122810A1 (fr) 2018-12-13 2018-12-13 Appareil serveur de communication, procédé et système de communication de gestion de codes d'autorisation pour des services associés au transport, appareil serveur de communication et procédé de traitement de code d'autorisation pour la réservation d'un service associé au transport, et dispositif de communication, procédé et système de communication de gestion de réservation d'un service associé au transport
MYPI2021003215A MY196382A (en) 2018-12-13 2018-12-13 Communications Server Apparatus, Method and Communications System for Managing Authorisation Codes for Transport-Related Services, Communications Server Apparatus and Method for Processing Authorisation Code for Booking of Transport-Related Service, and Communications Device, Method and Communications System for Managing Request for Booking of Transport-Related Service
SG11202012022XA SG11202012022XA (en) 2018-12-13 2018-12-13 Communications server apparatus, method and communications system for managing authorisation codes for transport-related services, communications server apparatus and method for processing authorisation code for booking of transport-related service, and communications device, method and communications system for managing request for booking of transport-related service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2018/050610 WO2020122810A1 (fr) 2018-12-13 2018-12-13 Appareil serveur de communication, procédé et système de communication de gestion de codes d'autorisation pour des services associés au transport, appareil serveur de communication et procédé de traitement de code d'autorisation pour la réservation d'un service associé au transport, et dispositif de communication, procédé et système de communication de gestion de réservation d'un service associé au transport

Publications (1)

Publication Number Publication Date
WO2020122810A1 true WO2020122810A1 (fr) 2020-06-18

Family

ID=71077438

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2018/050610 WO2020122810A1 (fr) 2018-12-13 2018-12-13 Appareil serveur de communication, procédé et système de communication de gestion de codes d'autorisation pour des services associés au transport, appareil serveur de communication et procédé de traitement de code d'autorisation pour la réservation d'un service associé au transport, et dispositif de communication, procédé et système de communication de gestion de réservation d'un service associé au transport

Country Status (3)

Country Link
MY (1) MY196382A (fr)
SG (1) SG11202012022XA (fr)
WO (1) WO2020122810A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020010627A1 (en) * 2000-05-17 2002-01-24 Gilles Lerat System and method for creation, distribution, exchange, redemption and tracking of digitally signed electronic coupons
US20110313839A1 (en) * 2010-06-22 2011-12-22 Michael Walsh Controlling coupon printing using a delegated image client
US20130024257A1 (en) * 2011-06-23 2013-01-24 Savingstar Systems and methods for electronic coupon cap control
US20130085817A1 (en) * 2011-09-29 2013-04-04 Michael Collins Pinkus Discount offer system and method for use with for hire vehicles
US20140129302A1 (en) * 2012-11-08 2014-05-08 Uber Technologies, Inc. Providing a confirmation interface for on-demand services through use of portable computing devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020010627A1 (en) * 2000-05-17 2002-01-24 Gilles Lerat System and method for creation, distribution, exchange, redemption and tracking of digitally signed electronic coupons
US20110313839A1 (en) * 2010-06-22 2011-12-22 Michael Walsh Controlling coupon printing using a delegated image client
US20130024257A1 (en) * 2011-06-23 2013-01-24 Savingstar Systems and methods for electronic coupon cap control
US20130085817A1 (en) * 2011-09-29 2013-04-04 Michael Collins Pinkus Discount offer system and method for use with for hire vehicles
US20140129302A1 (en) * 2012-11-08 2014-05-08 Uber Technologies, Inc. Providing a confirmation interface for on-demand services through use of portable computing devices

Also Published As

Publication number Publication date
MY196382A (en) 2023-03-27
SG11202012022XA (en) 2021-01-28

Similar Documents

Publication Publication Date Title
CN1633650B (zh) 用户认证方法及用户认证系统
US20190156307A1 (en) Agent access portal to money transfer system
US20040019542A1 (en) Timesheet reporting and extraction system and method
US20040243428A1 (en) Automated compliance for human resource management
US20180032750A1 (en) Integrated credential data management techniques
KR101635573B1 (ko) 인사 급여 통합 관리 시스템
CN108475268A (zh) 知识产权公文管理系统
WO2019064920A1 (fr) Système de réception de salaire, procédé de réception de salaire et programme
US20190180384A1 (en) Methods and systems for setting and sending reminders
US20070225998A1 (en) Systems and Methods for Providing, Marketing, and Supporting Integrated Web-Based Software
US20140281917A1 (en) Review portal
US20210150514A1 (en) Systems and methods for authenticated trust distribution using blockchain
JP2006004263A (ja) 給与前払システム、給与前払方法及びプログラム
US8498910B1 (en) Payroll change alert
JP7409445B2 (ja) 情報処理装置、申告支援方法及びプログラム
WO2020122810A1 (fr) Appareil serveur de communication, procédé et système de communication de gestion de codes d'autorisation pour des services associés au transport, appareil serveur de communication et procédé de traitement de code d'autorisation pour la réservation d'un service associé au transport, et dispositif de communication, procédé et système de communication de gestion de réservation d'un service associé au transport
AU2012264600B2 (en) Method and system for dynamic user profile handling and management
US20060235826A1 (en) Tasking, invoicing, and reporting methods
JP6793275B1 (ja) システム、方法、及びプログラム
US20160162789A1 (en) Event driven behavior predictor
US10887305B1 (en) Method and apparatus for generating and providing a temporary password to control access to a record created in response to an electronic message
JP7414470B2 (ja) サーバー装置、プログラム、利用者端末装置、およびシステム
CN113255012B (zh) 乘车码的管理方法、装置、设备及存储介质
US11587098B2 (en) Automated consent management systems and methods for using same
US20170053354A1 (en) Licensing manager

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18943101

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 06/09/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18943101

Country of ref document: EP

Kind code of ref document: A1