Patent Application
20200265038
This invention relates in general to a mutual data resolution system. This invention also relates to a system for uniquely distinguishing one user from another user. Furthermore, this invention relates to a system for providing user suggestions based on a determined profile. In addition, this invention relates in general to a system for providing user suggestions, which may be used by a particular entity. The invention also relates to a database for use by such a system, and to an associated data structure of the database.
Previous approaches to user tracking systems use UNYSIS or IBM platforms programmed using TPF or FORTRAN programming languages. Such systems typically utilize username records to store a user's route or journey. However, in previous approaches, it is difficult to programmatically distinguish between different users having the same username (or other title) and to determine whether different usernames relate to the same or a different user. This is often the case when a user has not consented to a frequent user program, or the like, because less data is available to differentiate between different users having the same username.
Furthermore, previous systems typically provide services at an agent-level, as opposed to a user level, and, thus are configured to differentiate between different users having the same username. Also, in previous approaches, when a user's journey is completed, the pertinent data for that journey is purged from the tracking system, resulting in a lack of tracked user events. Also, with previous systems, entities are only able to compute a value for users who consent to a frequent user program which may categorize users as Silver, Bronze and so on. Such systems require active permission by users, and as a consequence, only a smaller number of users permit frequent user programs.
The described mutual data resolution systems and processes aim to address these problems by providing a system for uniquely distinguishing a user account based on data, such as personal data provided by the user. The data may comprise one or more of usernames, addresses, and other identifying data. Embodiments of the mutual data resolution systems and processes may use a combination of the deterministic processing logic and probabilistic processing logic or algorithms. In some aspects, if a user provides sufficient data, then the system or process may determine an exact match to a profile. However, if a user does not provide sufficient data for an exact match, then the system or process may return a plurality of profiles, and embodiments of the system or process may use a probabilistic approach and request further data from a user to uniquely distinguish a user from a plurality of different users.
Embodiments of the mutual data resolution systems and processes include a transmission means for receiving input in response to a user interacting with an environment, a means for determining identifier data corresponding to the input, and a means for associating the input with the user.
Embodiments of the mutual data resolution systems and processes, wherein the associating means is configured to relate the input with a profile associated with the identifier data.
Embodiments of the mutual data resolution systems and processes include a means for determining whether a particular element is associated with the profile.
Embodiments of the mutual data resolution systems and processes, further comprising storage means for storing the input and the association between the input and the user.
Embodiments of the mutual data resolution systems and processes, wherein a storage means further stores a plurality of different profiles associated with different users, and further comprising means for probing the storage means for a profile comprising identification data corresponding to a search key.
Embodiments of the mutual data resolution systems and processes, wherein the transmission means is further configured to receive identification data comprising a string associated with the user or one or more of user number, or transit number.
Embodiments of the mutual data resolution systems and processes may determine a profile value based on one or more of a user importance code, a user frequency value, and a user history.
Embodiments of the mutual data resolution systems and processes may determine a number of different transport types corresponding to the profile and for determine the user value for the user based on a sum of weighted values corresponding to each transport type.
Embodiments of the mutual data resolution systems and processes, wherein the importance code comprises a tiered importance code and wherein a different numerical value corresponds to each importance code tier.
Embodiments of the mutual data resolution systems and processes may include a user frequency value that comprises a tiered frequency value and wherein a different numerical value is associated with each frequency value tier, wherein the history comprises a plurality of different designators, each designator corresponding to a segment of a journey.
Embodiments of the mutual data resolution systems and processes may determine a profile value based on an equal biasing of a value corresponding to an importance code and a tier value corresponding to a tier level or a value corresponding to a history for a segment of a journey.
According to various embodiments, each input of the mutual data resolution systems and processes may include associated data defining the input and preferably data defining the input origin such as one of an agent input or system input or profile input.
Embodiments of the mutual data resolution systems and processes may store a relational profile database and preferably wherein a processor is configured to provide a web-based platform.
Embodiments of the mutual data resolution systems and processes may match the input to a profile by matching one or more identifiers associated with the profile to one or more references to corresponding identifiers associated with the input.
Embodiments of the mutual data resolution systems and processes may determine a user value on a numerical scale such as 1 to 100 based on a profile element and particular element or history element and preferably storing the determined value in a profile database associated with the user.
Embodiments of the mutual data resolution systems and processes may determine a whether a profile comprises a profiling link entity linking a profile to a different user profile and preferably wherein the at least one computing device determines whether the profile link entity is a link to a nearest neighbor profile and further preferably adjusting the user value based on the user value associated with the linked profile.
Embodiments of the mutual data resolution systems and processes may select a suggestion from a plurality of predetermined suggestions, and preferably wherein the suggestion is selected based on the determined value and determined input and preferably further causes the at least one computing device to render the suggestion on a display.
Embodiments of the mutual data resolution systems and processes may determine whether one or more suggestion have previously been received by the user and preferably wherein the at least one computing device is configured to dynamically generate one or more suggestions at a mid-tier processing level based on received inputs.
Embodiments of the mutual data resolution systems and processes may match a suggestion to a profile based on one or more elements associated with the suggestion which correspond to one or more elements associated with the profile.
Embodiments of the mutual data resolution systems and processes may determine whether an input is an adverse input such as one or more of an offload input, disruption input, delay input, cancel input or re-route input based on the input.
An embodiment of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:
The following description is of a system for use in the aviation industry, but this is exemplary and other applications of the invention will also be discussed. For example, the system may be used in any environment where a product or service is provided to a user or customer, or indeed in any environment where user profiling is performed. Thus, embodiments of the invention find application in the travel industry in general (for example rail, air, coach and the like), but also in the ticketing industry, such as ticketing for theatre, cinema, and the like. The ticket relates to a journey between an origin and destination, for example, two airports.
The system may be embodied in a hosted system (for example hosted by an airline) which may use API communications protocols to communicate with external systems such as reservation systems.
In this embodiment, recommendations are built on an SOA suite Oracle BPEL platform. However, other platforms known to the skilled person may be used. For example, other platforms or programming languages may be used such as C++, JAVA, and .xml may be used as well as other programming languages which will be known to the skilled person. For example, embodiments of the invention may use one of these programming languages to provide a web-based service.
The system 200 may comprise one or more of the following components: a server 103 such as an SRDT computer server which is communicatively coupled, via wired or wireless transmission means which will be known to the skilled person, to an Oracle BPEL process manager residing on computer or server 101. In the schematic diagram of
In the schematic diagram of
When a profile is retrieved, the system may use mid-tier architecture to obtain the value of the customer based on the profile and generates the recommendations by applying a rule that may be configured by an airline, to the profile that has been retrieved. Determination of the customer value is described in detail below with particular reference to
The rules and recommendations will be described in further detail with reference to
An entity may also be referred to as a table, while an attribute may be referred to as columns or fields. Entities are uniquely identified by Primary Keys while relationships between different entities or attributes may be determined by one or more Foreign keys i.e. a key in an entity that is not the identifying Primary Key of the entity, but is rather a reference to the identifying Primary Key of a related Foreign entity.
One example of an entity is a booking history value entity that a subscriber (such as an airline) assigns by Distance (International/Domestic), Cabin Class and Reservations/Booking Designator (RBD) list, and so on. A
The booking history value entity may comprise one or more attributes or characteristics.
For example, the attributes may comprise a profile attribute, a frequent flyer attribute or a booking history attribute, as described in further detail with reference to
Profile attributes are shown within the dashed line 301 in
Each of these sub-entities may comprise an IMPORTANCE_CODE attribute. This attribute may comprise code representing the importance of the Customer for use in the Value Calculation algorithm. Values include VIP=Very Important, VVIP=Extremely Important, CIP=Commercially Important.
Each of these sub entities may further comprise a CUSTOMER_VALUE attribute. This attribute may comprise a value which has been assigned to the Individual by or on behalf of the subscriber. It may represent the value of the Individual to the Subscriber.
Further each of these sub-entities may further comprise a LINK_ADJUSTED_CUSTOMER_VALUE. This value may be determined by adjusting the CUSTOMER_VALUE to take into account the value of any linked Profiles.
Embodiments of the invention may copy a profile identifier into a profile link. In this way, embodiments of the invention may only consider links where the profile identifier is present in profile link. A link usually comprises two different profile identifiers and individual customer profiles may be additionally be linked to corporate or travel agency profiles.
Shown within a dashed line 303 in
The SUBSCR_VALUE_CALC_CONFIG entity may define weightings within a Value Calculation Rule Configuration for a Subscriber. Each Subscriber may have a different set of rules for each Profile Type. As part of the rule the contribution of each attribute to the overall value calculation may be specified. This will be described in further detail below with particular reference to
The IMPORTANCE_VALUE attribute may comprise a value defined for the IMPORTANCE_CODE by the Subscriber for each Profile Type, as a contribution to the calculation of Profile Value.
The FF_TIER_VALUE logical entity may comprise a value defined for the FF_Tier by the Subscriber for each Profile Type, as a contribution to the calculation of Profile Value.
The BOOKING_HISTORY_VALUE logical entity may comprise values that a Subscriber assigns by Distance (International/Domestic), Cabin Class and RBD list, as a contribution to the Value Calculation algorithm, subject to the weighting defined in SUBSCR_VALUE_CALC_CONFIG.FF_BOOKING_HISTORY_WEIGHTING_PCT. These values may be multiplied by the values in WEGHTED_FLIGHTS_TAKEN to determine the contribution of a Customers booking history to their value. In some examples, the information in this table and in WEIGHTED_FLIGHTS_TAKEN is only used as an alternative to FF Tier when the Subscriber has no Frequent Flyer Scheme or when the Customer is not a member of the Subscribers FF scheme.
The WEIGHTED_FLIGHTS_TAKEN logical entity may comprise values that a Subscriber can define any number of ranges, each of which is a range of total flights flown, and may define values multipliers for each of those ranges to be used in the Customer Value Calculation algorithm. Only the upper bound of the range needs to be stored in order for the service to derive the actual ranges. The first range starts at 0, all subsequent ranges may be contiguous and the last range has no upper bound. For example, if a Customer has flown 20 flights and there is a range defined as 16 to 21 then the Value associated with that range is incorporated into the Value Calculation algorithm to be multiplied by the Distance/Cabin Class/RBD values in BOOKING_HISTORY_VALUE and then subjected to the FF_BOOKING_HIST_WEIGHTING+PCT stored in the parent Rule in SUBSCR_VALUE_CALC_CONFIG. In some examples, the information in this table and in BOOKING_HISTORY_VALUE is only used as an alternative to FF Tier when the Subscriber has no Frequent Flyer Scheme or when the Customer is not a member of the Subscribers FF scheme. Shown within a dashed line 305 is a profile recommendation table, entity or data, PROFILE_RECOMMENDATION. This may comprise a list of Recommendations that have been acted upon for the Profile i.e. an Agent has noticed a recommendation relevant to a Profile and has followed or actioned the Recommendation. The Agent who actioned the Recommendation is recorded along with the date and time of actioning and if Customer acceptance of the Recommendation is needed (as determined by the ACCEPTANCE_REQUIRED_IND in SUBSCRIBER_RECOMMENDATION) then whether or not the Recommendation was accepted should also be recorded by setting the ACCEPTED_IND.
Also shown within dashed line 305 of
Also shown within dashed line 305 is a RECOMMENDATION_EVENT_TYPE entity. This may comprise data which enables Subscribers to associate Recommendations with Event Types for the purpose of matching Recommendations to Profiles, for example, to offer service recovery for an adverse Event Type such as an Offload, or flight disruption event such as delay, cancellation, or re-route event.
Finally, also shown within dashed line 305 of
Logical entities associated with events are also shown within figure the dashed line 307 of
As can be seen from
The following section describes how the link between a particular event and a particular customer is made. When a PNR or Customer Journey (i.e. booking) is created the Customer Profile ID of the Customer(s) is included in the booking information so when an event is generated for the booking it is passed to the Customer Profile service with the Customer Profile Id(s) included in the Event message. This allows the Event to be matched to the Customer Profile(s) on the unique identifier(s) of the Profile. The creation of a Booking and the subsequent generation of a Booking Event are not described in the CP data dictionary because those functions are not part of the Customer Profile domain—they are part of the Customer Journey domain.
Other (non-booking) Events can also be matched to Customer Profiles usually this relies on the Customer Profile ID(s) being known by the Service generating the Event at the time of
Event Creation and included in the Event message. Customers only have to identify themselves to a Service for the Service to retrieve their Customer Profile(s), complete with ID(s), and subsequently generate Events that can be uniquely matched to the Customer Profile(s) by way of the Customer Profile ID(s).
The event may be associated with a profile or user based on a link between a Profile Identifier and a Reference to that Identifier within the Event.
The link may be a direct or indirect link, and in the example shown in
Thus, regarding the association described in the previous paragraph, it should be noted that the attribute in question is the Identifier of the Profile (the Customer Profile ID). The Event message may contain a list of Customer Profile identifiers which is what enables the Event to be linked to the Profiles.
Thus it will be appreciated that an Identifier of an Entity is not an attribute in the context of the Entity it identifies (it is an Identifier and not an attribute) but it may be an attribute in the context of other entities—an attribute of type “Foreign Key” or “Reference”.
From the foregoing, it will be apparent that according to the previously described relational data model, the way in which events are matched to profiles is somewhat different to the way in which recommendations are matched to profiles.
The matching of Recommendations to Profiles is done on the basis of matching attributes of Recommendation to attributes of Profiles while the matching of Events to Profiles is done on the basis of matching the Identifiers of the Profiles to one or more references to those Identifiers contained within the Events. One CP Identifier within the Event can match to only one Customer Profile which is the most direct and accurate form of matching there can be in databases, whereas with Recommendations, one attribute within the Recommendation could match to many hundreds or even thousands of Profiles which is a much less direct and (intentionally) less accurate form of matching—the intention is that any attribute within a recommendation should indeed match to hundreds or perhaps thousands of Profiles. By using more than one attribute within a Recommendation the intersection of the sets of Customer Profiles that the attributes match to reduces the final matched set of Profiles for a Recommendation to tens or perhaps hundreds of Customer Profiles.
In one example, a particular customer profile identifier, for example the identifier of a profile associated with a first customer, such as the daughter of an executive of a company, may be included in a profile link, wherein the link comprises two different profile identifiers, one associated with the first customer and the other associated with a second customer for example an executive of a company.
For example, the processor may determine a link-adjusted customer value based on data associated with the profile link. In some specific examples, a link-adjusted customer value may be determined by determining the customer value associated with a profile identifier, for a second customer, stored in a profile link. In one specific example, the processor may increase a customer value by a predetermined value if the processor determines that the customer value associated with the customer profile for the second customer is greater than the customer value associated with the second customer profile.
Next nearest neighbor links may be taken into account when determining the link adjusted value. For example, a first customer profile associated with a customer may comprise a profile link. The profile link may comprise first and second profile identifiers associated with the first customer and a second customer respectively.
A second customer profile may be associated with the second customer. The second customer profile may have a further profile link. The further profile link may comprise two different profile identifiers, one associated with the second customer and a third profile identifier associated with a further, third customer.
In this example, the processor may determine a link-adjusted customer value based on data associated with the profile link and data associated with the further profile link.
In one specific example, a link-adjusted customer value may be determined by determining the customer value associated with a profile identifier stored in the profile link and the customer value associated with a profile identifier stored in the further profile link.
In one specific example, a link-adjusted customer value may be determined by determining the customer value associated with a profile identifier, for a second customer, stored in a profile link, and the customer value associated with a further profile identifier, for a third customer stored in a further profile link where the third profile link is associated with the first customer and a third customer, and not the second customer.
The processor may increase a customer value by a predetermined value if the processor determines that the customer value associated with the customer profile for the third customer is greater than the customer value associated with the first customer profile, irrespective of whether the processor has increased the customer value for the first customer, as previously described with reference to nearest neighbor links.
In addition, even if the processor has previously increased the customer value for a first customer by a predetermined amount, the processor may make a determination of whether the customer value associated with the customer profile for the third customer is greater than the customer value associated with the second customer profile. The processor may then increase or further increase the customer value for the first customer by a predetermined amount. Any of these values may be stored in storage means.
In this way, recommendations may be provided to a subscriber airline based on an event or/value or both.
In one example, a Horizon Customer Profile system embodying the invention may either calculate a value itself with an algorithm or it may store a value calculated by another source such as an external CRM system. In the example shown in
The algorithm for customer value calculation within Horizon Customer Profile may be performed with the following options but configured and weighted by an airline.
The value may be a number between 1-100 with 100 being the highest value. The items that are included in this value calculation are:
1. Frequent Flier tier level;
2. No. and value of bookings (by RBD) in a 12 month period; and
3. Profile attributes (e.g. VIP, Commercially important)
Each area has a percentage of the total and a value associated with it. The value may be determined by adding of all the factors provides a value to be used in processes throughout the Passenger Service System (PSS).
In the Customer Value Rules there may be 5 tables which may be used to calculate the Customer's Value to the airline or subscriber. The tables are described in further detail below:
In the following examples, one uses frequent flyer data and one using booking history data.
The passengers in these examples are made up on 50% Customer Profile Attribute and 50% FF Tier Level/Booking History
Example 1: Passenger 1: Normal and Blue
1. Normal has an Attribute Value of 10.
2. The Weighted Value of the CP Attribute is 50%. Multiply 10 by 50%=5.
3. Blue Tier has a value of 10.
4. Weighted Value of the FF Tier is 50%. Multiply 10 by 50% =5.
5. Weighted CP Attribute +Weighted FF Tier=Customer Value 5+5=10
6. 10 is the Customer Value which would be entered into the Customer Profile.
Example 2: Passenger 6: Normal, 1 Int'l economy, 4 Domestic economy.
1. Normal has an Attribute Value of 10.
2. The Weighted Value of the CP Attribute is 50%. Multiply 10 by 50%=5.
3. Int'l economy has a value weighting of 1.5. Multiply the number of flights 1) by the multiplier ( 1.5 )=1.5
4. Domestic economy has a value weighting of 1. Multiply the number of Domestic economy (4) by the multiplier (1)=4.
5. Total the weighted flights to get the total weighted value of the distance/cabin 1.5+4=5.5.
6. The answer in Step 5 is greater than 3 but less than 15. The Booking Value is 10.
7. Weighted Value for Booking History is 50%. Multiply 10 by 50%=5.
8. CP Attribute+Booking History =Customer Value. 5+5=10
9. 10 is the Customer Value which would be entered into the Customer Profile.
In one example, a customer profile value rules simulator may be provided.
The simulator may allow customers such as airlines to determine how customisation of their value calculation rules impacts the actual values calculated for a range of typical customers.
The simulator may determine a customer profile value as previously described to produce a table which may be displayed in a Graphical User Interface running on a computer or server. The Graphical User Interface may display the data shown in Table 1 below.
In the example table of values shown in Table 1 below, the current value is determined as a 50% weighting of CP Attribute and 50% weighting of Frequent Flyer (FF) tier Level/Booking History. Note that Passenger 4 calculates to 100. However, due to a mainframe restriction, it is shown as 99. Further note that Passenger 8 calculates to 62.5. However, due to a mainframe limitation, it is rounded off, in this case rounded up to 63.
Thus, in this example, the agent originally created the Value Rules for Individual Customer Profiles with a 50/50 split. In order to see what impact an 80/20 and a 70/30 split have on the customer value, an agent may use the simulator to run these scenarios without changing the actual settings.
In the example table of value shown in Table 2 below, the current value is determined as an 80% weighting of CP Attribute and 20% weighting of FF Tier Level/Booking History as listed in the Current Value column. Note that Passenger 4 calculates to 100 at both 50/50 and at 80/20. However, due to a mainframe restriction, it is shown as 99.
In the example table of value shown in Table 3 below, the current value is determined as a 30% weighting of CP Attribute and 70% weighting of FF Tier Level/Booking History is in the Current Value column and 80/20 figures are in the Previous Value column. Note that Passenger 4 calculates to 100. However, due to a mainframe restriction, it is shown as 99. Also note that Passenger 8 calculates to 47.5. However, due to a mainframe limitation, it is rounded off, in this case rounded up to 48.
In the specific example shown in
Once a recommendation has been entered in the text box adjacent “recommendation”, for example “Upgrade to business class” or “Complementary ticket”. Other recommendations may comprise text which may prompt a customer service executive to wish the customer a happy birthday, apologize for offloading them last time on a previous flight, offer free 1st class lounge access, offer cheap ticket to a sporting or cultural event in their place of destination, offer free upgrade to a high-value customer and so on.
The user may then save the recommendation rule by clicking the “Save” button shown in
The acknowledgement may be stored as an attribute and may be associated with one or more entities by way of the relationships previously described with reference to
In this way, a feedback loop between recommendations proposed to a customer by an airline user or subscriber may be made by storing data associated with a recommendation, which is indicative as to whether one or more recommendations have been accepted by a user.
In this way, an airline subscriber can manage recommendations based on whether a customer has accepted one or more recommendations, and
In this example, a rule is associated with a denied boarding event and involuntary offload event. The rule is also associated with a customer value range of 10 to 50, which may be determined as previously described. Furthermore, in this example, the rule is also associated with a particular validity period from 3 Jul. 2014 to 31 Jul. 2014. Furthermore, in this example, the recommendation is “Offer lounge access” and an acknowledge field is also associated with the recommendation. This may mean that if a customer wishes to accept the recommendation, that an acknowledgement is sent from the server running the GUI and that the acknowledgement may indicate that the recommendation has been accepted.
As previously noted, with reference to
A system embodying the invention may first check for a recommendation by calling the Recommendation Service in the Mid-Tier. The system then receives a recommendation for each event and non-event type. The system responds with all the recommendations, usually, up to a maximum of 30 recommendations that apply to a passenger. These may be both event and non-event based. If none of the recommendations apply to the passenger, no recommendation will be returned. The recommendations are usually displayed in groups of 5 until all 30 have been displayed. In this way, the system responds with the recommendation associated to the customer profile matching the event/non-event types.
In the example shown in
If the recommendation requires acknowledgement—the agent selects to accept/reject the recommendation. If the customer rejects the recommendation, then a user selects the reject button in the GUI, and this may be recorded in the activity profile. The recommendation is then not shown again to the user.
Recommendations may be recorded in the profile activity and this can show what recommendations are being accepted and what are being rejected. In this way, an airline can change rules to provide better control of their service situations.
In some examples, recommendations may be linked to merchandising to utilize recommendations to drive selling directly to customers based on profile attributes, events and value to differentiate—e.g. a higher value customer can buy an ancillary service but with a higher discount.
For example, as shown in
In this embodiment, a trigger event is received by a computer server or system embodying the invention. The event may be processed as previously described to produce an event recommendation, or according to the flow diagram of
Events may be notified from various sources to the Customer Profile system where they are processed and recorded against related customer profiles. Some of these events may be rejected by the system based on business rules or system failures. The rejected events may be logged in the Event Error Log. Usually, rejected events are manually processed.
In the specific example of
In this example, a plurality of different records are associated with this user. Each record may be identified by a record locator identifier which may comprise an alpha-numeric sequence of characters. Each record locator identifier may be associated with a departure date identifier and preferably a travel identifier. The departure date may be in the form of DAY/MONTH/YEAR. The travel identifier may identify a journey between two airports such as Bengaluru (BLR) to London Heathrow (LHR). The journey may be a non-stop flight or may comprise one or more stops between the passenger's origin and destination. Thus, in the specific example of
In the Profile activity screen shown in
The results shown in the results pane of
In the specific example shown in
Various process steps that may be performed by an embodiment of the invention will now be described with reference to
Referring now to
At step 905, a particular customer or user profile may be retrieved from the storage means on the basis of matching Frequent Flyer number, if the processor determines that the customer has a Frequent Flyer number stored in a database. In this way, a profile may be retrieved from the storage means by means of definitive search criteria. Definitive search criteria may include one or more of Customer Number/Reference, Frequent Flyer Number, and so on. When such details are available the system will retrieve a single profile matching the search criteria.
If the processor determines that the customer does not have a Frequent Flyer number stored in the database, then a profile is retrieved from the storage means on the basis of name plus any or more of the following personal details comprising credit card details, postal address, business address, mobile phone number and email address. Thus, a search key may be used to retrieve one or more profiles from the database. The key may comprise information such as name and optionally one or more further details outlined above.
If a single profile entry matches the key, then that single profile is returned to the mid tier processing. If a number of records match the search key, then a message is sent to an airline's agent (travel agent or check-in agent) or directly to the customer requesting the customer to provide more information in order to match them uniquely to a single profile.
Accordingly, one or more of customer names plus any of the fields mentioned above may be used to search for a customer. Usually, only when multiple matches are retrieved (for example same name and same address) embodiments of the invention request more details to deterministically and usually uniquely match the customer to a stored customer profile. However, in some specific examples, only the previously described details are used in the search, and embodiments of the invention do not necessarily search for Age or any other details not previously described.
In either case, at step 907, a get profile request is made to retrieve the profile which is uniquely associated with the user from a database.
A value, for example, a customer value may be calculated or determined. This may be performed at any stage before the customer value is used when recommendations are generated. For example, the value may be determined after a profile is retrieved at step 905 but before recommendations are generated at step 913. The value may be calculated using value rules 911 as previously described. At step 913, one or more recommendations are generated as previously described based on the determined value and based on one or more recommendation rules retrieved from a storage means, at step 915. A value may also be determined by retrieving a previously determined value associated with the profile from a database.
At step 917, one or more of the profile, value and recommendations may be displayed, for example, using a GUI as shown in
At step 923, the activity is displayed along with the recorded recommendation. The agent will usually then take any action implied by the recommendation if it was accepted. Finally, at step 925, the process ends.
From the foregoing, it will be appreciated that the mobile communication or client device may include a computing device, such as a desktop computer, a laptop computer, a tablet computer, a personal digital assistant, a mobile telephone, a smartphone, an internet enabled television, an internet enabled television receiver, an internet enabled games console or portable games device.
The server may comprise a computer processor running one or more server processes for communicating with client devices. The server processes comprise computer-readable program instructions for carrying out the operations of the present invention. The computer-readable program instructions may be or source code or object code written in or in any combination of suitable programming languages including procedural programming languages such as C, object-orientated programming languages such as C#, C++, Java, scripting languages, assembly languages, machine code instructions, instruction-set-architecture (ISA) instructions, and state-setting data.
The wired or wireless communication s networks described above may be public, private, wired or wireless network. The communications network may include one or more of a local area network (LAN), a wide area network (WAN), the Internet, a mobile telephony communication system, or a satellite communication system. The communications network may comprise any suitable infrastructure, including copper cables, optical cables or fibers, routers, firewalls, switches, gateway computers and edge servers.
The system described above may comprise a Graphical User Interface.
Embodiments of the invention may include an on-screen graphical user interface. The user interface may be provided, for example, in the form of a widget embedded in a web site, as an application for a device, or on a dedicated landing web page. Computer-readable program instructions for implementing the graphical user interface may be downloaded to the client device from a computer-readable storage medium via a network, for example, the Internet, a local area network (LAN), a wide area network (WAN) and/or a wireless network. The instructions may be stored in a computer-readable storage medium within the client device.
As will be appreciated by one of skill in the art, the invention described herein may be embodied in whole or in part as a process, a data processing system, or a computer program product including the computer-readable instructions. Accordingly, the invention may take the form of an entirely hardware embodiment or an embodiment combining software, hardware and any other suitable approach or apparatus.
The computer-readable program instructions may be stored on a non-transitory, tangible computer-readable medium. The computer-readable storage medium may include one or more of an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk.
Exemplary embodiments of the invention may be implemented as a circuit board which may include a CPU, a bus, RAM, flash memory, one or more ports for operation of connected I/O apparatus such as printers, display, keypads, sensors and cameras, ROM, a communications sub-system such as a modem, and communications media.
The flowchart of
Referring now to
The SCA layer may be used to construct applications based on Service-Oriented Architecture (SOA) by assembling and composing existing Services to create new Services.
The mediator uses the underlying Event Driven Network to publish subscribe events between components. The VETRO pattern is a common composite pattern that combines multiple actions taken on a message when it is received.
When the mid-tier calculate value process determines that the customer value is same as an existing value, it is not necessary to call the create profile component 1103 or update profile component 1105.
In the example shown in
The customer affinity mediator service component 1101 may perform a VETRO pattern and may route to the create/update components 1103/1105 or the retrieve component 1107 depending on the particular HTTP request which has been received.
The create component 1103 and update components 1105 flow into the Customer Value process component 1109. The update component 1105, during the Customer Value process compares a newly determined customer value to a previously determined customer value. Based on the comparison, the customer value may be updated in the database.
Similarly, the booking event component 1111 and frequent flyer event component 1113 flow into the customer value component. The customer value component 1109 may determine a customer value based on data received from each of these components. Furthermore, from the foregoing, it will be appreciated that embodiments of the invention may also be used by airport infrastructure operators who may wish to use a profiling system.
For example, if a user registers with an airport infrastructure provider to use a free wireless internet service by providing an email address and password, provided, of course, customer privacy is respected, airport operators may target offers or services to particular users.
Based on a reason provided by the user for being at the airport such as picking-up, travelling, dropping off, airport infrastructure provides may transmit, usually via wireless communications protocols which will be known to the skilled person, particular data to the customer. A system embodying the invention may also be used to send (usually via a wireless communication protocol) information or discounts to use retail establishments in the airport. For example, if the user's propose at the airport is to pick up, then details of the arrival process, or an alert when plane has landed, baggage in hall etc may be transmitted to a user's portable communication device.
Further, merchandising processes may use embodiments of the invention to push offers directly to the customer based on the information known about the customer—attributes of the profile or activity.
From the foregoing, it will be appreciated that embodiments of the invention may relate to a Customer Profiling system for example where a Customer may be a passenger, a travel or airline agent, or a company or other organization. It also relates to a travel customer profiling system
Embodiments of the invention find particular application for use within the Travel Industry but also finds application in the retail industry or other customers.
For example, it may find application for customers by providing a system capable of taking orders, such as a booking, from identifiable customers and which generates events that are linked to, or associated with, their Customer Profile.
Preferences may be extended to include the ability to define any type of preference. The preferences may be user-definable. The value calculation algorithm may be extended to be specific to the retail industry sectors.
Moreover, embodiments of the invention do not necessarily determine a customer value calculation or events since embodiments of the invention may relate to a profiling system.
Embodiments of the invention may not only capture preferences but may also capture a customer's hobbies and interests, their birthday and their frequent flyer tier information.
The following examples describe some additional ways in which the determined customer value may be used.
In a further example, a modified customer value, which is referred to as an Operational Customer Value (OCV) may be determined. As described in further detail below, this may be determined as an alternative or additional value to the Customer Profile Value previously described. However, usually, a key parameter for determining the OCV is the CPV. In cases where CPV has been used as an OCV parameter and the customer has not subscribed to Customer Profile or if a customer's profile Value cannot be retrieved, the value will be considered as 0. Both the Operational Customer Value (OCV) and the Customer Profile Value (CPV) may provide a unique and flexible and way for Airlines to rank their customers in a departure control system, DCS.
The OCV may be the customer value used for specific operations in a DCS. The Customer Profile Value (CPV) will usually be one of the key parameter used in OCV. Other parameters used for computing OCV may be operational in nature such as the Check-in Time and so on.
An OCV of a customer may be a whole number that reflects weights for different parameters.
a. The range of OCV for customer is between 0 and 9999999999 inclusive.
b. Parameter weights may be within a scale of 0 to 99, both inclusive.
c. A single-digit weight is converted to a 2 digit string by adding a leading 0.
d. A maximum of 5 parameters is supported initially.
In the example shown in
For example, a lower value for parameter 2 may indicate a passenger is a less valued customer, a lower parameter for value 3 may indicate a lower ticket class, while a lower value for parameter 4 may indicate that a passenger has not booked early or checked in early and may be regarded as less valuable. Other parameters which may be used to compute the OCV are listed in the table below.
It will be appreciated that other parameters known to the skilled person may be used to determine the OCV.
When setting up the OCV, airlines usually select one or more of the above attributes. Airlines usually select a subset of the parameters listed above. Once airlines have selected a set or subset of parameters, the order of the parameters in the OCV may be selected. This is usually an important step because it usually has a major influence on the ranking, and comparison of OCV's. For example, if the CPV is set as the first parameter, customers with a higher CPV will have a higher ranking than customers with a lower CPV. Finally, airlines may define a default value or weight of the parameter, if for example, no value is present for a particular parameter.
Operational Customer Values associated with different customers may be compared as numerical values. The greater the OCV number, the higher the value. For example, as shown in
Further, a minimum, or maximum or average of a plurality of OCV's associated with different customers may be determined.
For example, when more than one customer is considered the minimum, maximum or average is determined from the whole OCV. Suppose that a first customer has an OCV=504030 and second customer has an OCV=402030. In this scenario, the minimum of the two OCV values, Min=402030 and is applied to both customers. Similarly, the maximum of the two OCV values, Max,=504030. This may also be applied for both customers. The average of the two OCV values may also be determined, and computed as Ave=453030. This may also be applied to both customers. Thus, a group OCV may be determined for a plurality of customers, and the group OCV may be associated with the plurality of customers
Further, the processed OCV values may be compared by ranking them in ascending or descending order of the processed OCV values.
Once the OCV has been setup, the OCV may be activated for passenger acceptance by means of an airline option. For example, the OCV may be used for all airports and flights during passenger acceptance, or the OCF may be used only in conjunction with particular flights, such as MH100, and all flights from London Heathrow (LHR).
In an alternative example, the OCV may not be used for assisting acceptance anywhere. Alternatively, the OCV may not be used for assisting in acceptance when the departing airport is Kuala Lumpur (KUL) and the flight is MH200.
When more than one customer checks in together two airline options may control the acceptance behavior. In one example, group logic may be applied when 2 to 4 customers check-in together. Alternatively, customers in a group may share the maximum, minimum or average OCV of other customers.
From the foregoing, it will be appreciated that the operational customer value, OCV, may:
The following numbered clauses provide further detail of the invention:
This application is a continuation-in-part of U.S. application Ser. No. 15/510,178, filed Mar. 9, 2017, and entitled “IMPROVED CUSTOMER PROFILING SYSTEM AND METHOD THEREFOR,” which is: a National Phase Entry of PCT/EP15/68682, filed Aug. 13, 2015, and entitled “IMPROVED CUSTOMER PROFILING SYSTEM AND METHOD THEREFOR”; and a continuation-in-part of U.S. application Ser. No. 14/481,378, filed Sep. 9, 2014, and entitled “USER PROFILING SYSTEM AND METHOD THEREFOR,” each of which is incorporated herein by reference in its entireties.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15510178 | Mar 2017 | US |
| Child | 16868606 | US | |
| Parent | 14481378 | Sep 2014 | US |
| Child | 15510178 | US |
