WO2022101387A1

WO2022101387A1 - Product ownership verification

Info

Publication number: WO2022101387A1
Application number: PCT/EP2021/081478
Authority: WO
Inventors: Jan LOVMAND; Lars Torp; Rasmus Bækgård HOLM
Original assignee: Detectsystem Lab A/S
Priority date: 2020-11-13
Filing date: 2021-11-12
Publication date: 2022-05-19

Abstract

Insurance fraud utilising a free return period is a growing problem within the insurance industry. This is alleviated by providing a method (100) of verifying ownership of a product comprising the steps: - in response to a transaction event (1) in which a purchaser acquires the rights to the product being a goods or a service, generate a transaction identifier (110) that uniquely identifies the transaction event (1) based on transaction data (111), the transaction identifier (110) further having a status parameter (130) indicating purchaser ownership of the product, and - transmitting the transaction identifier (110) to a database (120), - in response to receiving a first status request signal (2) comprising transaction data (111) from a first requester system (20), identify the transaction identifier (110) in the database, then transmitting a verification signal indicating purchaser ownership of the product to the first requester system (20), then changing the status parameter (130) in the database to indicate purchaser non-ownership, and - in response to receiving subsequent status request signals (3) comprising transaction data (111) from a subsequent requester system (30), the request relating to consumption of the ownership of the product, identify the transaction identifier (110) in the database, then transmitting an alert signal (140) indicating that the status parameter indicates a purchaser non-ownership or non-possession incompatible with the request as well as potential fraud to either of the requester systems (20, 30).

Description

PRODUCT OWNERSHIP VERIFICATION

FIELD OF THE INVENTION

The invention relates to a method of verifying the ownership status of a product, a device instructed to perform the method, and a program and a computer-readable medium with instructions for carrying out the method.

BACKGROUND OF THE INVENTION

Fraud is a global problem that affects not least the insurance industry. It is estimated that 10% of all insurance pay-outs are made to fraudsters. To receive an insurance pay-out, various documents must be presented to validate the insurance claim. Even then, there are loopholes. Fraudsters seek to cheat insurers in a plethora of ways and today, fraud has moved into the digital arena too.

Digital documents introduce a variety of new ways to cheat and commit fraud, not least insurance fraud. Verifying the uniqueness, ownership and authenticity of documents and items is very difficult when documents are digital files. In the past, digital rights management has been used on some file types to ensure that they were not copied, although the inconvenience thereof made it infeasible, and so insecure documents are here to stay. Verifying the uniqueness, ownership and authenticity of documents and items is the job of insurance investigators, who make value-judgments about documents throughout their workday. The more serotinous they are, the slower and more expensive insurance pay-outs and premiums get. Some insurance companies have decided to solve this by being slack with verification and accepting as high as 20% fraud, since this allows them to have fewer investigators and so retain operative costs low.

An area of fraud relates to utilizing the return period of new items when shopping, prevalent for online and physical stores. A person can claim to its insurance company that the newly bought item has been stolen, and is able to present all relevant documents, and then - still within the return period - return the item to the store. This is a problem for insurance companies as well as the online stores where quick and inexpensive shipping is a cost of doing business, and returns are an expense. There is a thus a need for increased security and counter-fraud measures when it comes to shopping.

SUMMARY OF THE INVENTION

In an aspect of the invention, there is provided a method of verifying ownership of a product comprising the steps:

- in response to a transaction event which a purchaser acquires the rights to the product being a goods or a service, generate a transaction identifier that uniquely identifies the transaction event based on transaction data, the transaction identifier further having a status parameter indicating purchaser ownership of the product, and

- transmitting the transaction identifier to a database,

- in response to receiving a first status request signal comprising transaction data from a first requester system, identify the transaction identifier in the database, then transmitting a verification signal indicating purchaser ownership of the product to the first requester system, then changing the status parameter in the database to indicate purchaser non-ownership, and

- in response to receiving subsequent status request signals comprising transaction data from a subsequent requester system, the request relating to consumption of the ownership of the product, identify the transaction identifier in the database, then transmitting an alert signal indicating that the status parameter indicates a purchaser non-ownership or non-possession incompatible with the request as well as potential fraud to either of the requester systems.

Thereby fraud can be avoided, and it becomes possible to avoid pay-outs on non- legitimately used transaction documents. One reason it is so difficult to identify this kind of fraud is that the relevant information belongs with different organisations. However, it is also a lot of documents that needs to be reviewed. Although it is conceptually possible to compare all documents, it is nevertheless technically infeasible, especially when some documents may belong to other organisations/persons than the handler of the newly received document. The list of transaction identifiers is furthermore more persistent than original documents which may be lost or damaged. It is also impossible to know if all relevant places have been investigated.

Furthermore, saving transaction identifiers takes up only little space in a database, and thus the method is energy-saving.

Furthermore, by comparing a document through using a document identifier with a list of historically used/generated document identifiers, a portion of fraud attempts can be stopped in their tracks, freeing up (insurance) investigators to investigate other cases, such as more complicated cases. Yet further, the investigators need to perform fewer mouse-clicks on average to process an insurance claim.

Furthermore, policy holders that have the uniqueness of their documents successfully verified through the method are allowed a user-friendly method that can be performed with fewer mouse-clicks by either insurance investigator or the policy holder. Even when the confidence test of the step of identifying and extracting fails, the insurance investigator is left with a partially completed investigation, which reduces the number of mouse-clicks needed to finish the process.

By product is meant a physical item, an intellectual or intangible item, or a service or right of use. It can thus be watches, jewellery, ownership of intellectual rights such as patents, trademarks or companies, software licenses, software products or vouchers for services such as legal services or financial services.

By an alert signal being transmitted is meant that whoever prompted the method to be performed for a document will receive an alert signal indicative of the document being a duplicate of a previously used document. It is also possible that the alert signal is transmitted to previous such requesters of document uniqueness verification for the specific document. For example, previous insurers may be interested to know that a pay-out might have been fraudulent.

In an embodiment, the alert signal is transmitted to at least the first requester system. Thereby, the first requester receives information not otherwise possible and they may be allowed to identify and act on fraud that has hitherto gone undetected, or, be notified and be able to act much faster in such events. At the very least, when fraud happens, it is possible to correct the situation with fewer mouse clicks.

In an embodiment, the alert signal is transmitted to at least the second requester system. Thereby, the second requester receives information not otherwise possible and they may be allowed to identify and act on fraud that has hitherto gone undetected, or, be notified and be able to act much faster in such events. At the very least, when fraud happens, it is possible to correct the situation with fewer mouse clicks.

In an embodiment, the status parameter being updated in response to receiving the first status request signal comprises it being updated to indicate nonownership. Thereby,

In an embodiment, the transaction identifier is a hash value. Thereby, it is energyefficient and fast to make searches through the list of transaction identifiers. The database is responsive in a timely manner. This ensures that policy holders do not have to wait an inordinate amount of time when requesting a pay-out.

In an embodiment, the transaction data used to generate the transaction identifier is purchaser-impersonal data such as invoice number, date, seller identity and so on, whereby the data can be safely stored in a remote database belonging to a third party without the risk of compromising privacy. In a preferred embodiment, the impersonal data is further hashed to generate a space-saving and energysaving method.

In an aspect of the invention, there is provided a computing device having a processor adapted to perform the steps of the invention.

In an aspect of the invention, there is provided a computer program comprising instructions which cause the computer to carry out the method of the invention, when the program is executed by a computer.

In an aspect of the invention, there is provided a computer-readable medium comprising instructions which cause the computer to carry out the method of any of the invention, when executed by a computer. Any convenient hashing algorithm may be used. For example, MD5 may be considered to be sufficiently effective. However, in another embodiment, SHA-2 may be used, even further SHA-256. In any case, such hashing allows fast and easy comparison and allows comparisons to require only handling of databaselight hash codes which is significantly faster and more energy-saving than retrieving image or document files.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, example embodiments are described according to the invention, where

Fig. 1 illustrate an event sequence of an embodiment the invention, and

Fig. 2 illustrate a method of avoiding fraud of an embodiment of the invention, and

Fig. 3 illustrates a computing device according to an embodiment of the invention.

DETAILED DESCRIPTION

In the following the invention is described in detail through embodiments hereof that should not be thought of as limiting to the scope of the invention.

One conventional process of fraud that is alleviated with the invention can play out as follows, described from the consumer perspective. The consumer/purchaser purchases a product, such as a watch. Later on, but still within the return period in which it is hassle-free to return the watch, the purchaser finds out that the watch is not to his liking, and he returns the watch to the retail store for a full refund. So far there is no problem, and everything is legal. However, the purchaser may, in the months that follow, feel strapped for money and may start contemplating insurance fraud. He may in fact inform the insurance company that the watch has been stolen. By providing the payment invoice, images of his wearing the watch as well as any other necessary documents, he may in fact present seemingly valid documentation to achieve a pay-out of the insurance sum, even though he no longer owns the watch. In this way, he has achieved a net gain at or around the value of the product with which he has committed his fraud. There are of course also situations where the fraudster has planned the whole fraud ahead of time. Fig. 1 illustrate a method 100 of product ownership verification according to an embodiment of the invention. Let us now look at the method of the invention in contrast to the above described scenario.

The purchase of the product, such as a watch, marks a transaction event 1 handled by a retail system 10. Payment is processed and any transactional documents are generated by the retail system 10. An invoice, a bill and/or any other such financial documents may be involved to document and identify the transaction.

The retail system 10 then transmits a generation request 11 to a computing device 150, including any necessary transaction event data. The computing device 150 generates a transaction identifier charactering the transaction event 1 based on transaction specific data, and stores the transaction identifier in a database 120 for later use. The transaction identifier importantly comprises a status parameter which, upon generation, indicates purchaser ownership.

Later on, when the purchaser performs a payment petition 2 in the form of returning the watch to a retail store, a retail system 20 handles the payment petition 2. The payment petition has as objective to get money back for the product or in other ways derive benefit for ‘trading’ the ownership status of the product. Further than looking at documentation provided by the purchaser, the retail system 20 is instructed as part of the handling of the payment petition 2, to transmit a status request 12 to the computing device 150. The computing device 150 retrieves the transaction identifier from the database 120. The retail system 20 will receive a signal from the computing device 150 verifying that the status parameter indicates purchaser ownership of the product, such as a watch.

Thereby, the retail system 20 receives a verification that the purchaser does indeed own the watch, and the return is thus processed. When the return has been processed, the status parameter of the transaction identifier is then modified to indicate that the purchaser no longer owns the watch, i.e. , the status parameter is modified to indicate purchaser non-ownership. It is now the retail store that owns the watch, and it can be resold to another purchaser. The computing device 150 preferably retains on file the specific retail system 20 identity for later use in association with the transaction identifier.

When the purchaser later decides to commit insurance fraud by performing a second payment petition 3 in the form of providing an insurance claim on the watch with an insurer system 30, the insurer system 30 performs a second request 13 to the computing device 150 to identify the status of the status parameter of the transaction identifier.

However, instead of finding that the transaction identifier has a status parameter indicating that the purchaser owns the watch, the insurer system 30 is instead alerted 140 by the computing device 150 that the status parameter already indicates purchaser non-ownership. This translates to the purchaser no longer owning the watch. In other words, since the purchaser does not own the watch, by trying to make the insurer make a pay-out on the watch, the purchaser may be considered to be trying to sell a watch that is not his I he is caught committing insurance fraud.

Many different scenarios can be envisioned that rely on this inventive method.

For example, instead of returning the watch to the retail store first, and then afterwards requesting an insurance pay-out on the watch, the purchaser may perform the first payment petition 2 with an insurer to gain an insurance pay-out within the return period. In this case the insurer system acts as a first requester 20. Only later does the purchaser in this scenario perform the second payment petition 3 to the second requester 30 by trying to return the watch to the retail store, at which point the status parameter already indicates non-ownership. In this situation, it may not be trivial to resolve the case, since the fraud is identified while the purchaser is trying to hand the product back, perhaps in person. In this situation, the retail store may refuse to take the watch back citing its already having been legally transferred to the insurance company. However, the insurance company may prefer that the retail store confiscates the watch.

In any regard, in this reversed situation, it is preferable to transmit the alert signal 140 at least to the first requester 20 of the status parameter change, being the insurance company. This makes sense since the first requester 20 is the legal owner of the product, and the insurer who made an insurance pay-out on the watch can now be informed that a policy holder has tried to return a supposedly stolen watch to a retail store/system. While this scenario has the added intricacy of which party of the retail store or the insurer ends up owning the product/watch, the fraudster is caught red-handed, and the watch may be confiscated depending on local laws. Thereby a crime is stopped, and a criminal can be identified.

It is also possible that the product is reported damaged for legitimate reasons to the insurer 20 and later returned to the producer 30 for a replacement as well. Depending on the specific circumstances, this may be illegal as well.

In these cases, the purchaser is essentially asking the respective party to purchase the product from the purchaser.

The transaction event 1 can be the purchase of an expensive watch, shoes, or other consumer goods, the procurement of services such as legal counselling, or immaterial goods such as software licenses. In all of these cases, a receipt is generated and a right to a product is attained where the receipt indicates the ownership.

Fig. 2 illustrates a method 100 of avoiding fraud according to an embodiment of the invention.

The method involves receiving a generation request 11 for transaction identifier generation, such as from a retail system, then generating 101 the transaction identifier 110 based on transaction data, the transaction identifier 130 having a status parameter 130 initially indicating the purchaser ownership.

The transaction identifier 110 is then transmitted 102 to a database 120 for storage.

Later, in response to a first status request 12, the transaction identifier 130 is retrieved from the database and the status is verified 103 as indicating purchaser ownership, which verification is then transmitted to the requester, that can then accept the ownership change, such as return or pay-out. The status parameter is then updated to indicate that the purchaser ownership has been consumed/used 104. The status parameter then indicates non-ownership. Yet later, in response to subsequent status requests 13, the transaction identifier 130 is retrieved from the database 120 and the status parameter is identified 105 as indicating purchaser non-ownership. An alert signal 140 is transmitted in response thereto, either the first or second requester (or both).

In a bit more detail, the method may be carried out at follows.

The transaction identifier 110 is generated at the request of a retail system or other system which is instructed to create transaction event data for a transaction event. The retail system transmits the generation request 11 along with information that identifies the transaction event. Preferably, the transaction identifier 110 is generated without the use of personally identifying information. The inventors have found that a sufficiently unique transaction identifier 110 may be generated without such identifying information. By using transaction specific data such as transaction date, transaction number and optionally seller identity/name, a unique combined data set is achieved.

Preferably, this combined data is then appended to create a string which is then hashed. The hash code is then transmitted 102 and stored along with the status parameter 130 in the database 120. This allows fast retrieval and even more secure data storage.

When a first payment petition is later begun, the transaction data is transmitted along with a first status request 12 to the computing device from a first requester system such as a retail system or insurer system. Alternatively, the first requester system is instructed to hash the transaction data itself, then transmit the hash.

The specific status of the status parameter 130 can be a document type, or an ownership status or any other indication otherwise deterministic about the legal status of the product. For example, the transaction identifier 110 may start out with a status parameter 130 being ‘invoice’, then later have this changed to ‘delivered’ if the shipping status is also useful to store.

In any regard, when the computing device is to retrieve the transaction identifier 110 from the database 120, if the transaction identifier 110 is stored as a hash, it can be retrieved using an identical hash. This is fast and secure, and is much less storage intensive, thus saving both storage space and energy during handling. Thereby the first payment petition can be processed quickly, securely and without doubt that it is legitimate. Conventionally, when an insurer is asked to make a payout, one step that is sometimes performed by insurance investigators is to call the retail store to ask whether the transaction is legitimate. By instead performing the first status request 12, when it successfully resolves, the first requester knows that the transaction event is indeed legitimate. Then the purchaser ownership status is consumed to indicate non-ownership. This may for example take the shape of modifying the document type from ‘delivered’ to ‘insurance request’, then ‘credit note’, then ‘insurance pay-out’. These may all indicate further useful information to the insurance investigators and system administrators that at the very least indicates the status of the original purchaser ownership.

When a second and any other subsequent status requests 13 are received, preferably along with a hash or transaction data from which to form such hash, the transaction identifier 110 is retrieved again. Instead of verifying that the status parameter 130 indicates purchaser ownership, such as ‘delivered’, the status instead already indicates non-ownership, such as by having the document type I status ‘insurance pay-out’ if an insurer has paid out for the product, or ‘returned’ if a retail store has taken the product back.

Depending on the legal desires of the different actors implementing the invention, the second payment petition may either be rejected completely, or further declarations of return verification may be required from the purchaser, where the fraudster is asked to make certain statements. The latter may allow parties to pursue the fraudster easier for the fraud. It is also useful to allow potential false positives to make any arguments to be take into consideration if a legitimate dual payment petition has been filed. This is indeed sometimes the case. In any case, an alert signal 140 is transmitted either to of the requesters of the first and/or the second status request. They can react and implement the follow up in many different ways.

Fig. 3 illustrates a computing device according to an embodiment of the invention. The computing device 150 has a processor 151 , a networking interface 152 and a database 120. The networking interface 152 receives all requests for transaction identifier generation and all status requests as signals, and routes them to the processor 151 for processing. As the processor 151 interprets and processes these request signals, it accesses the database 120 which comprises at least the transaction identifiers 110 that are generated and used by the invention with individual status parameters. Optionally, transaction data 111 can be stored in the database for the transaction identifiers as well. It is preferable to also have a hashing algorithm in the database that the processor can execute to create the transaction identifiers 110, as well as to then later generate hashes for searching for the transaction identifiers 110. It is important that the same transaction data 111 supplied results in identical hashes to find the relevant transaction identifiers in the database when status request are received by the computing system. Thereby it is not possible for a fraudster to cheat by supplying even slightly modified transaction data 111 to avoid detection, because in this case no transaction identifier will be identified. Using a hash the processor 151 is then quickly able to determine that no such transaction identifier exists.

Claims

1. A method (100) of verifying ownership of a product comprising the steps:

- in response to a transaction event (1 ) in which a purchaser acquires the rights to the product being a goods or a service, generate a transaction identifier (110) that uniquely identifies the transaction event (1 ) based on transaction data (111 ), the transaction identifier (110) further having a status parameter (130) indicating purchaser ownership of the product, and

- transmitting the transaction identifier (110) to a database (120),

- in response to receiving a first status request signal (2) comprising transaction data (111 ) from a first requester system (20), identify the transaction identifier (110) in the database, then transmitting a verification signal indicating purchaser ownership of the product to the first requester system (20), then changing the status parameter (130) in the database to indicate purchaser non-ownership, and

- in response to receiving subsequent status request signals (3) comprising transaction data (111 ) from a subsequent requester system (30), the request relating to consumption of the ownership of the product, identify the transaction identifier (110) in the database, then transmitting an alert signal (140) indicating that the status parameter indicates a purchaser nonownership or non-possession incompatible with the request as well as potential fraud to either of the requester systems (20, 30).

2. A method according to claim 1 , wherein the alert signal (140) is transmitted to at least the first requester system (20).

3. A method according to any of claims 1-2, wherein the alert signal (140) is transmitted to at least the second requester system (30).

4. A method according to any of claims 1-3, where the status parameter being updated in response to receiving the first status request signal (2) comprises it being updated to indicate non-ownership.

5. A method according to any of claims 1-4, where the transaction identifier is a hash value.

6. A computing device (150) having a processor (151 ) adapted to perform the steps of any of claims 1 -5.

7. A computer program comprising instructions which cause the computer to carry out the method of any of claims 1-5, when the program is executed by a computer.

8. A computer-readable medium comprising instructions which cause the computer to carry out the method of any of claims 1-5, when executed by a computer.