TWI839610B - System and method for return fraud detection and prevention - Google Patents

Abstract

A computer-implemented systems and methods for return fraud detection and prevention are disclosed. The computer-implemented system may comprise a memory storing instructions and at least one processor. The at least one processor may be configured to receive a refund request from a device, identify a content status from a return package, and associate the refund request with the content status, determine a customer associated with the refund request and the content status, aggregate a profile of the customer from the refund request, the device, and the content status, assign a refund status and a fraudulent member status associated with the refund request from at least one rule definition and the profile of the customer, determine an approval or rejection of the refund request from the refund status, the fraudulent member status, and at least one business rule, and provide the device with the approval or rejection of the request refund.

Description

System and method for detecting and avoiding return fraud

The present invention generally relates to computerized systems and methods for evaluating and blocking chargeback requests. In particular, embodiments of the present invention relate to inventive and non-known systems and methods for detecting and stopping fraudulent chargebacks.

Fulfillment companies may currently be subject to a great deal of abuse by customers who may request refunds for orders that the customer falsely claims were damaged or returned back to the fulfillment company or its sellers. Some customers claim that an order was returned but after a lengthy investigation, the fulfillment company discovers that the package was returned; however, the package was blank or partially filled with some of the items from the order. These investigations associated with fraudulent refund requests may cost the fulfillment company a great deal of resources and capital, which may discourage and prevent the fulfillment company from competing to provide excellent customer service to its customers. Furthermore, customers who actively make fraudulent refund requests may use different modes of communication with the fulfillment company in order to hide their true identity so that the fulfillment company may not identify those customers as habitual offenders of abusing refund requests. These repeat abusers of chargeback requests can also cost the fulfillment company a lot of resources and capital because the fulfillment company may not be able to detect those abusers.

In an attempt to overcome customer issues associated with fraudulent refund requests, fulfillment companies may work to coordinate with sellers to minimize confusion regarding customer claims that orders were returned to the fulfillment company or the seller. Other fulfillment companies may have decided to simply quit competing for good customer service with respect to refund requests. Additionally, fulfillment companies may have attempted to reduce the volume of abusive and fraudulent refund requests by setting long lead times for refunds to customers in the hope that the delay will deter abusers from attempting to make fraudulent refund requests.

Additionally, some fulfillment companies may have attempted to address the issues of customers associated with fraudulent refund requests and their abuse and fraudulent refund requests by implementing systems that can automate the investigation process. However, automation of current systems can be fraught with problems because current systems may not be able to cope with interruptions in communication between customers and the current systems. Interruptions in communication between customers and fulfillment companies and the current systems can adversely impact the fulfillment center's customer service regarding refund requests because customers may have to initiate additional calls to start the process of requesting a refund from the beginning.

Another shortcoming of current systems is that they cannot properly identify customers who use multiple identities to repeat their fraudulent refund requests. This inability of current systems to detect customers with multiple identities ultimately consumes more resources than current systems, which may defeat the purpose of those current systems, since customers know that current systems may not detect multiple identities of the same customer.

Yet another problem that the fulfillment company may find with the current system may be its inability to integrate with the seller's system or its own legacy system. This lack of integration capability may cause the fulfillment company to delay or lack effective investigation of customers or fraudulent refund requests associated with fraudulent refund requests due to loss of communication between the seller's system, the current system, and the fulfillment legacy system. The current system may not be versatile enough to easily integrate with the legacy system in order to provide a good customer service experience for refund requests, which may require long lead times for integration and testing to resolve all possible issues with the integration of the current and legacy systems.

Yet another problem with current systems may be that laymen cannot change the rules in determining the definition of a customer associated with a fraudulent refund request or abusive refund requests. Current systems may require the rules for investigation to be hard-coded, where professionals in the field of computer programming may be required to make such changes. The need to use computer programmers to change the code associated with the rules for investigating customers associated with fraudulent refund requests and their fraudulent refund requests may demonstrate the impossibility of adapting the current system to changing requirements based on market forces or changes. Fulfillment companies may not be left with remedial measures to quickly adapt to and compete for changing market demands in customer services for refund requests. Thus, if, for example, a product is known to be defective, the current system requires a general improvement in its code to be able to handle legitimate refund requests from customers, even if some customers are associated with fraudulent refund requests. The impossibility of the current system being easily upgraded by laymen (such as business people) in a very short amount of time to quickly respond to market demands can also cost the performance company its reputation with its customers.

Therefore, there is a need for improved methods and systems for detecting customers associated with fraudulent refund requests and their fraudulent refund requests without losing communications with the customers or with its own systems, properly detecting customer identities with multiple pseudonyms, and easily investigative by laymen for rule changes to adapt to changing market demands.

One aspect of the present invention is directed to a computer-implemented system for detecting and preventing return fraud. The computer-implemented system may include a memory storing instructions and at least one processor configured to execute the instructions to perform the following operations: receiving a refund request associated with an order identifier from a device, identifying a content status associated with a return package associated with the order identifier from the device, and associating the refund request associated with the order identifier with the content status associated with the return package. In addition, at least one processor may be configured to determine a customer associated with a refund request and a content status, aggregate a customer profile based on the refund request, device, and content status, and specify a refund status and a fraudulent member status associated with the customer's refund request based on at least one rule definition and the customer profile. In addition, at least one processor may be configured to determine approval or denial of a refund request based on the refund status, fraudulent member status, and at least one business rule, and provide approval or denial of the refund request to the customer's device.

Another aspect of the present invention is directed to a computer-implemented system for detecting and avoiding return fraud. The computer-implemented system may include a memory storing instructions and at least one processor configured to execute instructions to perform the following operations: receiving a refund request associated with an order identifier from a device, determining a customer associated with the refund request, aggregating a customer's profile based on the refund request and the device, and specifying a refund status and a fraud member status associated with the customer's refund request based on at least one rule definition and the customer's profile. In addition, at least one processor may be configured to determine approval or denial of the refund request based on the refund status, the fraud member status, and at least one business rule, and provide approval or denial of the refund request to the customer's device.

Yet another aspect of the invention is directed to a computer-implemented method for detecting and avoiding return fraud. The computer-implemented method may include the steps of receiving a refund request associated with an order identifier from a device, identifying a content status associated with a return package associated with the order identifier from the device, and associating the refund request associated with the order identifier with the content status associated with the return package. Additionally, the method may include determining a customer associated with the refund request and the content status, aggregating a profile of the customer based on the refund request, the device, and the content status, and specifying a refund status and a fraudulent member status associated with the refund request of the customer based on at least one rule definition and the profile of the customer. Additionally, the method may include determining approval or denial of a refund request based on the refund status, the fraudulent member status, and at least one business rule, and providing the approval or denial of the refund request to the customer's device.

Other systems, methods, and computer-readable media are also discussed herein.

100, 400: System

101: Shipping authorization technology system

102A: Mobile device/user device

102B: Computer/User Device

103: External front-end system

105: Internal front-end system

107:Transportation system

107A, 107B, 107C: Mobile devices

109: Seller portal

111: Shipping and order tracking system

113: Implementation of optimization system

115: Implement communication gateway

117: Supply Chain Management System

119:Warehouse management system

119A: Mobile device/tablet

119B: Mobile device/PDA

119C: Mobile devices/computers

121A, 121B, 121C: Third-party fulfillment system

123: Fulfillment Center Authorization System

125: Labor management system

200: Fulfillment Center

201, 222: Truck

202A, 202B, 208: Objects

203: Arrival area

205: Buffer zone

206:Forklift

207: Unloading area

209: Picking area

210: Storage unit

211: Packaging area

213: Hub

214:Transportation Agency

215: Camp area

216: Wall

218, 220: Package

224A, 224B: Delivery workers

226:Car

300:Introducing subsystem

302: Source API

304: Endpoint API

306a, 306b, 306c, 306d, 306e: controller

308: Authenticator

310: Abnormal processor

312:Data Aggregator

314: Recording & Tracking Module

316: Tracker

318:Tracking Analyzer

325: Output subsystem

327: Cretaceous Domain Module

329a: Cancel service

329b: Return service

329c:Exchange service

329d: Discounted service

331: External service proxy module

333: External service worker

335: External API requester

337:Generator

339a: Order service

339b: Performance services

339c: Shipping services

339d: Welfare services

339e:Ticket service

350: Control subsystem

351:Rule management module

352: Event Management Module

353: Workflow management module

355: Subsystem/Graphical Representation

361: Return event storage area

362:Rule Engine

363:Rule database

370: External data sources

371: Event storage area

372:Write to database

373, 373A, 373B: Read database

374:Administrator database

375: Workflow subsystem

377:Framework module

379a: Return module/programmed module

379b:Exchange module/programmed module

379c: Unmod/Programmable Module

381: Crayon Workflow Launcher

383a:Cancel process workflow/Cancel process

383b: Return process workflow/return process

383c: Exchange process

383d: Delivery tracking/delivery tracking process

383e: Collection process

383f: Refund process

383g: Undo process

385: Workflow service module

387: Clayton Workflow Service Module

389a: Retail returns submodule

389b: Third-party return submodule

391: Workflow Arrangement Module:

402:Processor

404: Client Device

406: Asynchronous communication module

408: Return management module

410: Fraud detection module

412: Abuse Refund Control Database

414: Crayon Module

416: Virtual Enterprise Rules Module

500, 600, 700: Method

506, 508, 510, 512, 516, 606, 608, 610, 612, 614, 616, 618, 620, 622, 624, 626, 628, 630, 632, 634, 636, 638, 640, 642, 644, 670, 672, 674, 676, 678, 680, 682, 706, 708, 710, 712, 714, 716, 718, 720, 722, 724, 726, 770, 772, 774, 776, 778, 780, 782: Steps

FIG. 1A is a schematic block diagram showing an exemplary embodiment of a network including a computerized system for communicating to implement shipping, transportation, and logistics operations consistent with the disclosed embodiments.

FIG. 1B depicts a sample search result page (SRP) including one or more search results satisfying a search request and an interactive user interface element consistent with the disclosed embodiments.

FIG. 1C depicts a sample single display page (SDP) including a product and information about the product and interactive user interface elements consistent with the disclosed embodiments.

FIG. 1D depicts a sample shopping cart page including items in a virtual shopping cart and interactive user interface elements consistent with the disclosed embodiments.

FIG. 1E depicts a sample order page including items from a virtual shopping cart and information about purchase and shipping and interactive user interface elements consistent with the disclosed embodiments.

FIG. 2 is a diagrammatic illustration of an exemplary fulfillment center configured to utilize the disclosed computerized system consistent with the disclosed embodiments.

FIG. 3A shows an exemplary graphical representation of an intake subsystem 300 consistent with the disclosed embodiments.

FIG. 3B shows an exemplary graphical representation of an output subsystem 325 consistent with the disclosed embodiments.

FIG3C shows a graphical representation of an exemplary control subsystem, an exemplary return event storage area, an exemplary rule engine, and an exemplary external data source consistent with the disclosed embodiments.

FIG. 3D shows an exemplary graphical representation of a workflow subsystem 375 consistent with the disclosed embodiments.

FIG. 4 is a block diagram illustrating an exemplary system 400 for fraud detection and customer abuse consistent with disclosed embodiments.

FIG5 is a flow chart of an exemplary method 500 for determining the content status of a return package consistent with the disclosed embodiment. The processor 402 may receive the return package

6A and 6B are flow charts of an exemplary method 600 for determining refund status and membership status based on rule definitions for retail goods or fresh food consistent with the disclosed embodiments.

FIG. 7A and FIG. 7B are flow charts of an exemplary method 700 for determining a final refund status or final member status based on corporate rules for retail goods or fresh food consistent with the disclosed embodiments.

The following detailed description refers to the accompanying drawings. Whenever possible, the same figure numbers are used in the drawings and the following description to refer to the same or similar parts. Although several illustrative embodiments are described herein, modifications, adaptations, and other embodiments are possible. For example, the components and steps shown in the drawings may be replaced, added, or modified, and the illustrative methods described herein may be modified by replacing, reordering, removing, or adding steps to the disclosed methods. Therefore, the following detailed description is not limited to the disclosed embodiments and examples. Instead, the proper scope of the invention is defined by the scope of the accompanying patent applications.

Embodiments of the present invention are directed to systems and methods configured to maintain communications with customer and fulfillment company systems by using an implemented asynchronous communication system and application programming interface that integrates with external systems (such as seller or legacy systems) to provide backup redundancy between systems to minimize interruptions and time in processing and investigating refund requests.

Additionally, embodiments of the present invention are directed to systems and methods configured to detect customers with multiple pseudonyms or identities to continue to proliferate fraudulent refund requests, where, for example, the customer may use different usernames or registered identifiers (IDs), different devices, different names, or different physical addresses.

In addition, embodiments of the present invention are directed to systems and methods configured to easily change rule definitions for investigating customers associated with fraudulent refund requests and their abuse and fraudulent refund requests by implementing a virtual interface that allows laymen to create new rules to determine customers associated with fraudulent refund requests and their abuse and fraudulent refund requests. Implementation of a virtual interface that allows laymen to create new rules can allow fulfillment companies to quickly respond to market forces in customer service of refund requests.

1A, a schematic block diagram 100 is shown illustrating an exemplary embodiment of a system including a computerized system for implementing communications for shipping, transportation, and logistics operations. As shown in FIG1A, the system 100 may include a variety of systems, each of which may be connected to each other via one or more networks. The systems may also be connected to each other via direct connections (e.g., using cables). The depicted systems include a shipment authority technology (SAT) system 101, an external front-end system 103, an internal front-end system 105, a transportation system 107, mobile devices 107A, 107B, and 107C, a seller portal 109, a shipment and order tracking (SOT) system 111, a fulfillment optimization (FO) system 113, a fulfillment messaging gateway (FMG) 115, a supply chain management (SCM) system 117, a warehouse management system 119, mobile devices 119A, 119B, and 119C (depicted as being located at a fulfillment center). center; FC) 200), third-party fulfillment system 121A, third-party fulfillment system 121B and third-party fulfillment system 121C, fulfillment center authorization system (FC Auth) 123 and labor management system (LMS) 125.

In some embodiments, the SAT system 101 may be implemented as a computer system that monitors order status and delivery status. For example, the SAT system 101 may determine whether an order has exceeded its promised delivery date (PDD) and may take appropriate action, including placing a new order, reshipping items in an undelivered order, canceling an undelivered order, initiating contact with the ordering customer, or the like. The SAT system 101 may also monitor other data, including output (such as the number of packages shipped during a specific time period) and input (such as the number of empty cardboard boxes received for shipping). The SAT system 101 may also act as a gateway between different devices in the system 100, thereby enabling communication between devices such as the external front-end system 103 and the FO system 113 (e.g., using store and forward or other techniques).

In some embodiments, the external front-end system 103 may be implemented as a computer system that enables external users to interact with one or more systems in the system 100. For example, in an embodiment where the system 100 enables the presentation of the system to allow a user to place an order for an item, the external front-end system 103 may be implemented as a web server that receives a retrieval request, presents an item page, and requests payment information. For example, the external front-end system 103 may be implemented as a computer or a computer running software such as Apache HTTP Server, Microsoft Internet Information Service (IIS), NGINX, or the like. In other embodiments, the external front-end system 103 may run customized web server software designed to receive and process requests from external devices (e.g., mobile device 102A or computer 102B), obtain information from databases and other data repositories based on those requests, and provide responses to the received requests based on the obtained information.

In some embodiments, the external front-end system 103 may include one or more of a web cache system, a database, a retrieval system, or a payment system. In one embodiment, the external front-end system 103 may include one or more of these systems, and in another embodiment, the external front-end system 103 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

The exemplary set of steps shown in Figures 1B, 1C, 1D, and 1E will help describe some operations of the external front-end system 103. The external front-end system 103 can receive information from systems or devices in the system 100 for presentation and/or display. For example, the external front-end system 103 can host or provide one or more web pages, including a search result page (SRP) (e.g., Figure 1B), a single detail page (Single Detail Page; SDP) (e.g., Figure 1C), a shopping cart page (e.g., Figure 1D), or an order page (e.g., Figure 1E). A user device (e.g., using a mobile device 102A or a computer 102B) can navigate to the external front-end system 103 and request a search by entering information into a search box. The external front-end system 103 can request information from one or more systems in the system 100. For example, the external front-end system 103 may request from the FO system 113 information to satisfy the search request. The external front-end system 103 may also request and receive (from the FO system 113) a promised delivery date or "PDD" for each product included in the search results. In some embodiments, the PDD may represent an estimate of when a package containing the product will arrive at the user's desired location or a date on which the product is promised to be delivered to the user's desired location if ordered within a specific time period, such as before the end of the day (11:59 p.m.). (PDD is further discussed below with respect to the FO system 113.)

The external front-end system 103 may prepare an SRP based on the information (e.g., FIG. 1B ). The SRP may include information that satisfies the search request. For example, this may include images of products that satisfy the search request. The SRP may also include individual prices for each product, or information related to enhanced delivery options, PDDs, weights, sizes, quotes, discounts, or the like for each product. The external front-end system 103 may send the SRP to the requesting user device (e.g., via a network).

The user device may then select a product from the SRP, such as by clicking or tapping on a user interface or using another input device to select a product represented on the SRP. The user device may formulate and send a request for information about the selected product to the external front-end system 103. In response, the external front-end system 103 may request information related to the selected product. For example, the information may include additional information beyond that presented for the product on the respective SRP. This may include, for example, a shelf life, country of origin, weight, size, number of items in a package, disposal instructions, or other information about the product. The information may also include recommendations of similar products (based on, for example, big data and/or machine learning analysis of customers who purchased the product and at least one other product), answers to frequently asked questions, reviews from customers, manufacturer information, images, or the like.

The external front-end system 103 may prepare an SDP (single detail page) (e.g., FIG. 1C ) based on the received product information. The SDP may also include other interactive elements, such as a “buy now” button, an “add to cart” button, a quantity column, an image of the item, or the like. The SDP may further include a list of sellers that offer the product. The list may be sorted based on the price offered by each seller, so that the sellers that offer the product at the lowest price may be listed at the top. The list may also be sorted based on seller rankings, so that the highest-ranked sellers may be listed at the top. The seller rankings may be developed based on a number of factors, including, for example, the seller's past tracking record of compliance with the promised PDD. The external front-end system 103 may deliver the SDP to the requesting user device (e.g., via a network).

The requesting user device may receive an SDP listing product information. After receiving the SDP, the user device may then interact with the SDP. For example, a user of the requesting user device may click or otherwise interact with an "add to cart" button on the SDP. This adds the product to a shopping cart associated with the user. The user device may transmit this request to add the product to the shopping cart to the external front-end system 103.

The external front-end system 103 may generate a shopping cart page (e.g., FIG. 1D ). In some embodiments, the shopping cart page lists products that the user has added to a virtual “shopping cart.” The user device may request the shopping cart page by clicking on or otherwise interacting with an icon on the SRP, SDP, or other page. In some embodiments, the shopping cart page may list all products that the user has added to the shopping cart, as well as information about the products in the shopping cart (e.g., the quantity of each product, the price per item of each product, the price of each product based on the associated quantity), information about the PDD, the delivery method, the shipping cost, a user interface element for modifying the products in the shopping cart (e.g., deleting or modifying the quantity), an option for ordering additional products or setting up recurring deliveries of products, an option for setting up interest payments, a user interface element for proceeding to purchase, or the like. A user at the user device may click on or otherwise interact with the user interface element (e.g., a button that says "Buy Now") to initiate a purchase of the products in the shopping cart. After doing so, the user device may transmit the request to initiate the purchase to the external front-end system 103.

The external front-end system 103 may generate an order page (e.g., FIG. 1E ) in response to receiving a request to initiate a purchase. In some embodiments, the order page re-lists the items from the shopping cart and requests entry of payment and shipping information. For example, the order page may include a portion requesting information about the purchaser of the items in the shopping cart (e.g., name, address, email address, phone number), information about the recipient (e.g., name, address, phone number, delivery information), shipping information (e.g., speed/method of delivery and/or pickup), payment information (e.g., credit card, bank transfer, check, stored points), a user interface element requesting a cash receipt (e.g., for tax purposes), or the like. The external front-end system 103 can send the order page to the user device.

The user device may enter information on the order page and click or otherwise interact with user interface elements that send information to the external front end system 103. From there, the external front end system 103 may send information to different systems in the system 100 to enable the creation and processing of a new order with the products in the shopping cart.

In some embodiments, the external front-end system 103 may be further configured to enable the seller to transmit and receive order-related information.

In some embodiments, the internal front-end system 105 may be implemented as a computer system that enables internal users (e.g., employees of an organization that owns, operates, or leases the system 100) to interact with one or more systems in the system 100. For example, in embodiments where the system 100 enables the presentation of the system to allow a user to place an order for an object, the internal front-end system 105 may be implemented as a web server that enables an internal user to view diagnostic and statistical information about an order, modify object information, or review statistics related to an order. For example, the internal front-end system 105 may be implemented as a computer or a computer running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, or the like. In other embodiments, the internal front-end system 105 may run customized web server software designed to receive and process requests from the systems or devices depicted in the system 100 (as well as other devices not depicted), obtain information from databases and other data repositories based on those requests, and provide responses to the received requests based on the obtained information.

In some embodiments, the internal front-end system 105 may include one or more of a web cache system, a database, a retrieval system, a payment system, an analysis system, an order monitoring system, or the like. In one embodiment, the internal front-end system 105 may include one or more of these systems, and in another embodiment, the internal front-end system 105 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

In some embodiments, the transport system 107 may be implemented as a computer system that implements communication between the systems or devices in the system 100 and the mobile devices 107A to 107C. In some embodiments, the transport system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smart phones, PDAs, or the like). For example, in some embodiments, the mobile devices 107A to 107C may include devices operated by delivery workers. The delivery workers (who may be permanent employees, temporary employees, or shift employees) may utilize the mobile devices 107A to 107C to implement the delivery of packages containing products ordered by users. For example, to deliver a package, a delivery worker may receive a notification on a mobile device indicating which package to deliver and where to deliver the package. Upon arriving at the delivery location, the delivery worker may locate the package (e.g., in the back of a truck or in a crate of packages), use the mobile device to scan or otherwise capture data associated with an identifier on the package (e.g., a barcode, image, text string, RFID tag, or the like), and deliver the package (e.g., by leaving it at the front door, leaving it with a guard, giving it to the recipient, or the like). In some embodiments, the delivery worker may use the mobile device to capture a photo of the package and/or may obtain a signature. The mobile device may send information to the transport system 107, including information about the delivery, including, for example, the time, date, GPS location, photo, an identifier associated with the delivery worker, an identifier associated with the mobile device, or the like. The transport system 107 may store this information in a database (not depicted) for access by other systems in the system 100. In some embodiments, the transport system 107 may use this information to prepare and send tracking data to other systems indicating the location of a particular package.

In some embodiments, some users may use one type of mobile device (e.g., a permanent worker may use a dedicated PDA with customized hardware such as a barcode scanner, stylus, and other devices), while other users may use other types of mobile devices (e.g., temporary or shift workers may utilize off-the-shelf cell phones and/or smartphones).

In some embodiments, the transportation system 107 may associate a user with each device. For example, the transportation system 107 may store an association between a user (represented by, for example, a user identifier, an employee identifier, or a phone number) and a mobile device (represented by, for example, an International Mobile Equipment Identity (IMEI), an International Mobile Subscription Identifier (IMSI), a phone number, a Universal Unique Identifier (UUID), or a Globally Unique Identifier (GUID)). The transportation system 107 may use this association in conjunction with data received during delivery to analyze data stored in a database to determine, among other things, the location of a worker, the efficiency of a worker, or the speed of a worker.

In some embodiments, seller portal 109 may be implemented as a computer system that enables sellers or other external entities to communicate electronically with one or more systems in system 100. For example, a seller may utilize a computer system (not depicted) to upload or provide product information, order information, contact information, or the like for products that the seller wishes to sell via system 100 using seller portal 109.

In some embodiments, shipping and order tracking system 111 may be implemented as a computer system that receives, stores, and transmits information about the location of packages containing products ordered by customers (e.g., by a user using device 102A to device 102B). In some embodiments, shipping and order tracking system 111 may request or store information from a web server (not depicted) operated by a shipping company that delivers packages containing products ordered by customers.

In some embodiments, the shipping and order tracking system 111 can request and store information from the systems depicted in the system 100. For example, the shipping and order tracking system 111 can request information from the transportation system 107. As discussed above, the transportation system 107 can receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, PDAs, or the like) associated with one or more of a user (e.g., a delivery worker) or a vehicle (e.g., a delivery truck). In some embodiments, the shipping and order tracking system 111 can also request information from a warehouse management system (WMS) 119 to determine the location of individual products within a fulfillment center (e.g., fulfillment center 200). Shipping and order tracking system 111 may request data from one or more of transportation system 107 or WMS 119, process the data upon request, and present the data to a device (e.g., user device 102A and user device 102B).

In some embodiments, the fulfillment optimization (FO) system 113 may be implemented as a computer system that stores information about customer orders from other systems (e.g., external front-end system 103 and/or shipping and order tracking system 111). The FO system 113 may also store information describing where specific items are kept or stored. For example, some items may be stored in only one fulfillment center, while some other items may be stored in multiple fulfillment centers. In still other embodiments, some fulfillment centers may be designed to store only a specific set of items (e.g., freshly produced or frozen products). The FO system 113 stores this information as well as related information (e.g., quantity, size, receipt date, expiration date, etc.).

The FO system 113 may also calculate a corresponding PDD (promised delivery date) for each product. In some embodiments, the PDD may be based on one or more factors. For example, the FO system 113 may calculate the PDD for a product based on past demand for the product (e.g., how many times the product was ordered during a period of time), expected demand for the product (e.g., how many customers are predicted to order the product during an upcoming period of time), network-wide past demand indicating how many products were ordered during a period of time, network-wide expected demand indicating how many products are expected to be ordered during an upcoming period of time, one or more counts of the product stored in each fulfillment center 200, which fulfillment center stores each product, expected or current orders for the product, or the like.

In some embodiments, the FO system 113 may determine the PDD for each product periodically (e.g., every hour) and store it in a database for retrieval or sending to other systems (e.g., external front-end system 103, SAT system 101, shipping and order tracking system 111). In other embodiments, the FO system 113 may receive electronic requests from one or more systems (e.g., external front-end system 103, SAT system 101, shipping and order tracking system 111) and calculate the PDD on demand.

In some embodiments, fulfillment gateway (FMG) 115 may be implemented as a computer system that receives requests or responses in one format or protocol from one or more systems in system 100 (such as FO system 113), converts them into another format or protocol, and forwards them in the converted format or protocol to other systems (such as WMS 119 or 3rd party fulfillment system 121A, 3rd party fulfillment system 121B, or 3rd party fulfillment system 121C), and vice versa.

In some embodiments, the supply chain management (SCM) system 117 may be implemented as a computer system that performs forecasting functions. For example, the SCM system 117 may forecast the level of demand for a particular product based on, for example, past demand for the product, expected demand for the product, past demand across the network, expected demand across the network, counted products stored in each fulfillment center 200, expected or current orders for each product, or the like. In response to this forecast level and the volume of each product across all fulfillment centers, the SCM system 117 may generate one or more purchase orders to purchase and reserve sufficient quantities to meet the forecasted demand for the particular product.

In some embodiments, a warehouse management system (WMS) 119 may be implemented as a computer system that monitors workflow. For example, the WMS 119 may receive event data indicating discrete events from individual devices (e.g., devices 107A to 107C or devices 119A to 119C). For example, the WMS 119 may receive event data indicating that a package was scanned using one of the devices. As discussed below with respect to fulfillment center 200 and FIG. 2 , during the fulfillment process, a package identifier (e.g., barcode or RFID tag data) may be scanned or read by a machine at a particular stage (e.g., an automated or handheld barcode scanner, RFID reader, high-speed camera, device such as tablet 119A, mobile device/PDA 119B, computer 119C, or the like). WMS 119 may store each event indicating a scan or read of a package identifier in a corresponding database (not depicted) along with the package identifier, time, date, location, user identifier, or other information, and may provide this information to other systems (e.g., shipping and order tracking system 111).

In some embodiments, WMS 119 may store information associating one or more devices (e.g., devices 107A to 107C or devices 119A to 119C) with one or more users (the one or more users are associated with system 100). For example, in some cases, a user (such as a part-time employee or a full-time employee) may be associated with a mobile device because the user owns the mobile device (e.g., the mobile device is a smartphone). In other cases, a user may be associated with a mobile device because the user temporarily keeps the mobile device (e.g., the user picks up the mobile device at the beginning of the day, will use the mobile device during the day, and will return the mobile device at the end of the day).

In some embodiments, the WMS 119 may maintain a work log for each user associated with the system 100. For example, the WMS 119 may store information associated with each employee, including any specified process (e.g., unloading from a truck, picking items from a pickup area, rebin wall work, packaging items), a user identifier, a location (e.g., a floor or area in a fulfillment center 200), a number of units moved through the system by the employee (e.g., number of items picked, number of items packaged), identifiers associated with devices (e.g., devices 119A-119C), or the like. In some embodiments, WMS 119 may receive login and logout information from a timing system, such as a timing system operating on devices 119A-119C.

In some embodiments, 3rd party fulfillment (3PL) systems 121A-121C represent computer systems associated with third-party providers of logistics and products. For example, while some products are stored in fulfillment center 200 (as discussed below with respect to FIG. 2 ), other products may be stored off-site, may be produced on demand, or may otherwise not be available for storage in fulfillment center 200. 3PL systems 121A-121C may be configured to receive orders from FO system 113 (e.g., via FMG 115), and may provide products and/or services (e.g., delivery or installation) directly to customers. In some embodiments, one or more of 3PL systems 121A-121C may be part of system 100, while in other embodiments, one or more of 3PL systems 121A-121C may be external to system 100 (e.g., owned or operated by a third-party provider).

In some embodiments, fulfillment center Auth system (FC Auth) 123 may be implemented as a computer system having various functions. For example, in some embodiments, FC Auth 123 may act as a single-sign on (SSO) service for one or more other systems in system 100. For example, FC Auth 123 may enable a user to record, determine via internal front-end system 105 that the user has similar privileges to access resources at shipping and order tracking system 111, and enable the user to obtain those privileges without requiring a second record-keeping process. In other embodiments, FC Auth 123 may enable a user (e.g., an employee) to associate themselves with a specific task. For example, some employees may not have electronic devices (such as devices 119A-119C) and may actually move from task to task and zone to zone within fulfillment center 200 during the course of a day. FC Auth 123 may be configured to enable such employees to indicate what task they are working on and what zone they are in at different times of the day.

In some embodiments, the labor management system (LMS) 125 may be implemented as a computer system that stores attendance and timeout information for employees (including full-time employees and part-time employees). For example, the LMS 125 may receive information from the FC Auth 123, the WMS 119, the devices 119A to 119C, the transportation system 107, and/or the devices 107A to 107C.

The specific configuration depicted in FIG. 1A is merely an example. For example, although FIG. 1A depicts FC Auth system 123 connected to FO system 113, not all embodiments require this specific configuration. In practice, in some embodiments, the systems in system 100 may be connected to each other via one or more public or private networks, including the Internet, an enterprise intranet, a wide area network (WAN), a metropolitan area network (MAN), a wireless network compliant with IEEE 802.11a/b/g/n standards, a leased line, or the like. In some embodiments, one or more of the systems in system 100 may be implemented as one or more virtual servers implemented at a data center, a server cluster, or the like.

FIG. 2 depicts a fulfillment center 200. A fulfillment center 200 is an example of a physical location where items are stored for shipment to customers upon ordering. A fulfillment center (FC) 200 may be divided into a plurality of zones, each of which is depicted in FIG. 2. In some embodiments, these "zones" may be thought of as virtual divisions between different stages of the process of receiving items, storing items, retrieving items, and shipping items. Thus, while "zones" are depicted in FIG. 2, other divisions are possible, and the zones in FIG. 2 may be omitted, duplicated, or modified in some embodiments.

Inbound area 203 represents an area of FC 200 where items are received from sellers who wish to sell products using system 100 from FIG. 1A. For example, a seller may use truck 201 to deliver item 202A and item 202B. Item 202A may represent a single item large enough to occupy its own shipping pallet, while item 202B may represent a collection of items that are stacked together on the same pallet to save space.

The worker will receive the objects in the inbound area 203, and may use a computer system (not depicted) to check the objects for damage and correctness as appropriate. For example, the worker may use a computer system to compare the quantity of object 202A and object 202B with the ordered quantity of the objects. If the quantity does not match, the worker may reject one or more of object 202A or object 202B. If the quantity does match, the worker may move those objects to the buffer area 205 (using, for example, a dolly, a hand truck, a forklift, or manually). The buffer area 205 may be a temporary storage area for the objects that do not need to be in the picking area at present (e.g., because there is a sufficiently high quantity of objects in the picking area to meet the predicted demand). In some embodiments, forklift 206 operates to move objects around buffer area 205 and between inbound area 203 and unloading area 207. If object 202A or object 202B in the picking area is needed (e.g., due to predicted demand), the forklift can move object 202A or object 202B to unloading area 207.

Unloading area 207 may be an area of FC 200 where objects are stored before being moved to picking area 209. A worker assigned to a picking task (a "picker") may approach object 202A and object 202B in the picking area, use a mobile device (e.g., device 119B) to scan a barcode of the picking area, and scan the barcode associated with object 202A and object 202B. The picker may then take the object to picking area 209 (e.g., by placing the object on a cart or carrying the object).

The picking area 209 may be an area of the FC 200 where objects 208 are stored on storage units 210. In some embodiments, the storage units 210 may include one or more of physical shelves, shelves, boxes, totes, refrigerators, freezers, cold storage areas, or the like. In some embodiments, the picking area 209 may be organized into multiple floors. In some embodiments, workers or machines may move objects into the picking area 209 in a variety of ways, including, for example, forklifts, elevators, conveyor belts, carts, hand trucks, dollies, automated robots or devices, or manually. For example, the picker may place the object 202A and the object 202B on a hand cart or a trolley in the unloading area 207, and move the object 202A and the object 202B to the picking area 209.

A picker may receive instructions to place (or "stack") an object at a specific point in a picking area 209, such as a specific space on a storage unit 210. For example, a picker may use a mobile device (e.g., device 119B) to scan object 202A. The device may, for example, use a system indicating aisles, shelves, and locations to indicate where the picker should stack object 202A. The device may then prompt the picker to scan a barcode at the location before stacking object 202A at the location. The device may send data (e.g., via a wireless network) to a computer system such as WMS 119 in FIG. 1A, indicating that object 202A has been stacked at the location by a user using device 119B.

Once the user places an order, the picker may receive instructions on device 119B to retrieve one or more objects 208 from storage unit 210. The picker may retrieve the object 208, scan the barcode on the object 208, and place the object 208 on a transport mechanism 214. Although the transport mechanism 214 is shown as a slide, in some embodiments, the transport mechanism may be implemented as one or more of a conveyor belt, an elevator, a cart, a forklift, a hand truck, a dolly, or the like. The object 208 may then arrive at a packaging area 211.

The packing area 211 may be an area of the FC 200 where the pick-up area 209 receives items and packages them into boxes or bags for final shipment to customers. In the packing area 211, a worker assigned to receive items (a "merge worker") receives the item 208 from the pick-up area 209 and determines which order the item 208 corresponds to. For example, the merge worker may use a device such as a computer 119C to scan a barcode on the item 208. The computer 119C may visually indicate which order the item 208 is associated with. This may include, for example, a space or "cell" on the wall 216 that corresponds to the order. Once the order is complete (e.g., because the cell contains all the items for the order), the merge worker may indicate to the packing worker (or "packer") that the order is complete. The packer may retrieve items from the cell and place them in boxes or packages for shipping. The packer may then send the boxes or packages to a hub zone 213, for example, via a forklift, cart, trolley, hand truck, conveyor belt, manually, or otherwise.

Hub 213 may be the area of FC 200 that receives all boxes or packages ("parcels") from packaging area 211. Workers and/or machines in hub 213 may retrieve parcels 218 and determine which part of the delivery area each parcel is intended to go to, and deliver the parcels to the appropriate camp zone 215. For example, if the delivery area has two smaller sub-areas, the parcels will go to one of the two camp zones 215. In some embodiments, a worker or machine may (e.g., using one of devices 119A-119C) scan the parcel to determine its final destination. Delivering the parcel to camp zone 215 may include, for example, determining (e.g., based on a postal code) a portion of a geographic area to which the parcel is destined, and determining a camp zone 215 associated with the portion of the geographic area.

In some embodiments, the camp area 215 may include one or more buildings, one or more physical spaces, or one or more areas where packages are received from the hub 213 for sorting into routes and/or sub-routes. In some embodiments, the camp area 215 is physically separate from the FC 200, while in other embodiments, the camp area 215 may form part of the FC 200.

Workers and/or machines in the camp area 215 may determine which route and/or sub-route a package 220 should be associated with, for example, based on a comparison of the destination with existing routes and/or sub-routes, a calculation of the workload for each route and/or sub-route, the time of day, the method of transportation, the cost of transporting the package 220, the PDD associated with the items in the package 220, or the like. In some embodiments, a worker or machine may scan a package (e.g., using one of the devices 119A-119C) to determine its final destination. Once a package 220 is assigned to a particular route and/or sub-route, the worker and/or machine may move the package 220 to be transported. In exemplary FIG. 2 , the camp area 215 includes a truck 222, a car 226, and a delivery worker 224A and a delivery worker 224B. In some embodiments, truck 222 may be driven by delivery worker 224A, where delivery worker 224A is a full-time employee delivering packages for FC 200, and truck 222 is owned, rented, or operated by the same company that owns, rents, or operates FC 200. In some embodiments, car 226 may be driven by delivery worker 224B, where delivery worker 224B is a "flexible" or temporary worker who delivers on an as-needed basis (e.g., seasonally). Car 226 may be owned, rented, or operated by delivery worker 224B.

FIG. 3A shows an exemplary graphical representation of an ingestion subsystem 300. Ingestion subsystem 300 may be designated for initial processing of communications from a source application program interface (API) 302. Source API 302 may be any of a number of APIs that may be specifically configured for use by consumers, delivery personnel, administrators, and/or sellers. Source API 302 may be implemented on a computing device having a processor, a memory component, and/or a communication component, such as a mobile device, a desktop computer, an adapter, a controller, a server, or any other device capable of sending and/or receiving API communications. In some embodiments, ingestion subsystem 300 and/or components of ingestion subsystem 300 may be communicatively coupled to other subsystems (e.g., as described in FIGS. 3B-3D).

The ingestion subsystem 300 may also include a plurality of endpoint APIs 304 to which the source API 302 may be communicatively coupled. In some embodiments, the endpoint API 304 may be only a single endpoint API. The endpoint API 304 may include a plurality of controllers, adapters, and/or other computing devices, which may be managed by an API provider (not shown). For example, the endpoint API 304 may be implemented by a combination of controllers, such as controller 306a, controller 306b, controller 306c, controller 306d, and/or controller 306e. In some embodiments, the controller may be designated to handle operations for a particular entity, such as a seller. The controller may be a hardware device or a software program that may manage the flow of data between different entities, such as between the source API 302 and the data aggregator 312. For example, the controller may be, but is not limited to, a flash controller, an application delivery controller, a primary domain controller, a baseboard management controller, and/or a session boundary controller. In some embodiments, communications from a source API 302 may be directed to a specific endpoint API or controller based on a source associated with the communication. For example, an API provider may receive communications from a source API 302 and may determine the source and/or type of the communication (e.g., based on a message identifier, an IP address, a MAC address, a communication format, and/or other unique identifiers). Based on the identified source of the communication and/or type of communication, the API provider may direct the communication to a specific controller that may be configured for communications having a specific source and/or type. By way of other examples, the API provider may determine that a communication from source API 302 has a consumer device as its communication source and a return request as its communication type, and may direct the communication to endpoint API 304 (e.g., controller 306b), which may be configured to handle communications having the source and/or type of the received communication (e.g., configured for return request communications).

The ingestion subsystem 300 may also include a validator 308 that may validate communications from the source API 302 and may be communicatively coupled to the endpoint API 304. The validator 308 may exist within the endpoint API 304 (e.g., as part of a controller), or may exist as a separate component such as a server to which the endpoint API 304 may be connected. The validator 308 may include various components (e.g., modules, devices, processors, etc.) configured to perform a validation process (e.g., a process for validating communications received from the source API 302). For example, the validator 308 may include a validator caller, a validation pre-processor (e.g., for reformatting data from a communication), a validator processor (e.g., for performing validation operations on the data), a validator post-processor (e.g., for reformatting the validated data into a format understandable by another entity (such as the rule engine 362 in FIG. 3C )), a validation manager, and/or a message publisher (which may direct messages to another subsystem).

The ingestion subsystem 300 may also include an anomaly handler 310 to which the verifier 308 may be communicatively coupled. The anomaly handler 310 may be part of the verifier 308, or may be a separate device or component, such as a server or a mobile device. In some embodiments, the verifier 308 may direct the communication to the anomaly handler 310 based on the verification result of the communication that may have been determined by the verifier 308. For example, if the communication invalidates at least one rule or algorithm implemented by the verifier 308, the verifier may direct the communication to the anomaly handler 310. In some embodiments, the anomaly handler 310 may be configured to reformat, split, parse, tag, and/or otherwise reconfigure or transmit information from the communication (e.g., to alert an administrator device) based on at least one rule or algorithm that is a failure of the communication. The anomaly handler 310 may be communicatively coupled to the data aggregator 312 and/or the logging & tracking module 314.

Ingestion subsystem 300 may also include data aggregator 312, which may aggregate data from different sources, such as endpoint API 304, exception handler 310, and/or logging & tracking module 314. Data aggregator 312 may be communicatively coupled to any device and/or component of subsystem 300, as well as devices and/or components of other systems, including subsystem 325 in FIG. 3B, subsystem 355 in FIG. 3C, and subsystem 375 in FIG. 3D. Data aggregator 312 may be part of a device having another purpose, such as authenticator 308, or may be a separate device or component, such as a server or mobile device. In some embodiments, data aggregator 312 may include various components (e.g., modules, devices, processors, etc.) configured to perform data aggregation processes (e.g., processes for aggregating and/or analyzing data from sources such as source API 302 and/or exception handler 310). For example, data aggregator 312 may include a data cache component, a data aggregator component, a data transformation component, a data mapping component, and/or a service router.

The ingestion subsystem 300 may also include a logging & tracking module 314 that can log and/or track data associated with communications (e.g., communications from the API source 302). The logging & tracking module 314 may be part of a device that has another purpose (e.g., the data aggregator 312), or may be a separate device or component, such as a server or a mobile device. In some embodiments, the logging & tracking module 314 may include various components (e.g., modules, devices, processors, etc.) configured to perform a data aggregation process (e.g., a process for tracking and/or logging data from sources such as the source API 302 and/or the anomaly handler 310). For example, the logging & tracking module 314 may include a tracker 316 and/or a tracking analyzer 318.

The tracker 316 can perform functions to track data, such as data associated with communications from the API source 302, the validator 308, and the like. In some embodiments, the tracker 316 can be configured to add a tracking identifier and/or a span identifier to the data associated with the communications. In some embodiments, the tracker 316 can maintain definitions related to logging and tracing (e.g., user-defined, machine-defined, and/or a combination of user-defined and machine-defined), such as definitions for transmitting tracing and/or logging data, a threshold number of tracing and/or log files to maintain, data formats, specific combinations of identifiers transmitted, and/or specific libraries for tracing. In some embodiments, the tracker 316 may implement a functionality provider such as a service link tracker (Spring Cloud Sleuth).

The trace analyzer 318 may perform functions for analyzing data (e.g., trace data and/or log data) that may be associated with communications from a device (e.g., a device implementing the source API 302). For example, the trace analyzer 318 may aggregate timing data (e.g., time when anomalies occur, frequency of anomalies, etc.), tags, rule failure data, rule satisfaction data, device identifiers, message identifiers, and/or any data associated with the source API 302. In some embodiments, the trace analyzer 318 may generate a visual representation of the trace and/or log data (e.g., a chart of filterable data, a line graph, recommendations generated by statistical and/or machine learning algorithms, etc.). In some embodiments, the trace analyzer 318 may implement a function provider such as Zipkin.

FIG. 3B shows an exemplary graphical representation of an output subsystem 325. The output subsystem 325 may be designated to process the output of the workflow subsystem 375 in FIG. 3D. The output subsystem 325 may pass the processed output to the external data source 370 in FIG. 3C, pass the processed output to be recorded and/or tracked by one or more of the recording & tracking module 314 and/or external service 339a to external service 339e in FIG. 3A. The output subsystem 325 may be specifically configured for use by consumers, delivery personnel, administrators, and/or vendors. The output subsystem 325 may be implemented on a computing device having a processor, a memory component, and/or a communication component. In some embodiments, output subsystem 325 and/or components of output subsystem 325 may be communicatively coupled to other subsystems (e.g., as described in FIGS. 3A-3D ).

The output subsystem 325 may include a plurality of Creturns domain modules 327, which may be communicatively coupled to the workflow subsystem 375 in FIG. 3D. In some embodiments, the Creturns domain module 327 may include various services 329a to 329d. Examples of services as shown in FIG. 3B may include a cancellation service 329a, a return service 329b, an exchange service 329c, and/or a price reduction service 329d. Each of the services 329a to 329d may be responsible for processing the output of a respective workflow task in the workflow subsystem 375 in FIG. 3D. For example, the cancel process workflow 383a in FIG. 3D may pass output to the cancel service 329a, and the return process workflow 383b in FIG. 3D may pass output to the return service 329b. The architecture of the Cretaceous domain module 327 is modified to add additional services as needed.

The Cretaceous domain module 327 can pass the processed information to the external data source 370 in FIG. 3C for recording and tracking by the record & track module 314 and/or the external service proxy module 331 in FIG. 3A . The information passed to the external data source 370 is stored as described in the section with reference to FIG. 3C . The information passed to the record & track module 314 is recorded and processed as described earlier in the section with reference to FIG. 3A .

The external service proxy module 331 (which is part of the output subsystem 325) can receive processed output from the Cretaceous domain module 327 for further guidance to the appropriate external services 339a to 339e. The output subsystem 325 can use the external service proxy module 331 to repeatedly connect to the same service without spending the time and computing resources required to initialize the service proxy more than once. The external service proxy module 331 can be implemented as a software or hardware system between the Cretaceous domain module 327 and the external services 339a to 339e. The external service proxy module 331 can exist on the same machine as the output subsystem 325 or on a separate server. The external service proxy module 331 can be specifically configured for use by consumers, administrators and/or sellers. The external service agent module 331 can be implemented on a computing device having a processor, a memory component and/or a communication component.

The external service proxy module 331 may also include an external service worker 333, which may receive data directly from the Creturn WorkflowStarter 381 in FIG. 3D and may be communicatively coupled to the workflow subsystem 375 in FIG. 3D. The external service worker 333 may exist within the external service proxy module 331, or may exist as a separate component such as a server to which the external service proxy module 331 may be connected. The external service worker 333 may include various components (e.g., modules, devices, processors, etc.) configured for output processing. For example, the external service worker 333 may process data that is not processed by the Creturn domain module 327.

The external service proxy module 331 may also include an external API requester 335 to which the external service worker 333 may be communicatively coupled. The external API requester 335 may be part of the external service proxy module 331, or may be a separate device or component, such as a server or a virtual entity. In some embodiments, the external service proxy module 331 may have direct communication with the external API requester 335 based on which of the external services 339a to 339e is required to pass output to the external API requester 335, which may have been determined by the Cretaceous domain module 327 or the external service worker 333. For example, if the external service requires an API for communication, the external API requester 335 may request appropriate API information to establish a connection with the required external service. In some embodiments, the external API requester 335 may be configured to reformat, split, parse, tokenize, and/or otherwise reconfigure or transmit information from the communication based on at least one rule or algorithm used by the external service.

The external service proxy module 331 may also include a generator 337 to which the external service worker 333 may be communicatively coupled. The generator 337 may be part of the external service proxy module 331, or may be a separate device or component, such as a server or a virtual execution entity. The generator 337 is used to publish messages to a topic. A topic may be divided into several partitions, which contain messages. Each message in a partition is assigned and identified by its unique offset. The message itself contains information about which topic and partition to publish to so that data can be published to different topics using the same generator. In some embodiments, Kafka may be used to implement the generator 337.

The external service proxy module 331 can pass the processed information to the record & tracking module 314 and/or external services 339a to external services 339e in Figure 3A. The information passed to the record & tracking module 314 is recorded and processed as described in the section earlier with reference to Figure 3A. External services 339a to external services 339e initiate actions based on requests. Examples of services as shown in Figure 3B may include ordering services 339a, fulfillment services 339b, shipping services 329c, benefits services 339d and/or ticket services 339e. Each of services 329a to 329d may be responsible for initiating a specific action. For example, in the event that workflow subsystem 375 in FIG. 3D passes output for processing by exchange service 329c, which may initiate several external services. The exchange of an item may involve output to ordering service 339a to order (the ordering instructions may include instructions to purchase the item from a supplier, tell a picker to prepare the item, purchase the item online, go to a third-party storage area and pick up the item, or other instructions for obtaining the item) a new item, output to shipping service 339c to generate a return shipping label, and/or output to fulfillment service 339b to process the returned item. The architecture of output subsystem 325 may be modified to add additional external services as needed.

FIG. 3C shows a graphical representation 355 of an exemplary control subsystem 350, an exemplary return event storage area 361, an exemplary rules engine 362, and an exemplary external data source 370 consistent with the disclosed embodiments.

Control subsystem 350 may be configured to create, update, maintain and/or manage data used by various components of system 300 in FIG. 3A , system 325 in FIG. 3B , and system 375 in FIG. 3D . For example, control subsystem 350 may be configured to create, update and/or modify parameters for managing customer returns (e.g., rules for approving and denying customer returns), manage parameters for workflows for processing returns, and/or store parameters for specific return events.

As shown in FIG. 3C , the control subsystem 350 may include a rule management module 351, an event management module 352, and a workflow management module 353.

The rules management module 351 can be configured to manage rules for processing returns from customers. For example, the rules management module 351 can be configured to create and/or modify rules for denying return requests from customers. By way of example, the rules management module 351 can be configured to create and/or modify rules for denying return requests from customers based on various parameters, including, for example, data related to previous returns by the customer, the monetary amount involved in the return request, the type of goods to be returned, etc. For example, if a customer returns an empty (or partially empty) box within the past predetermined number of days (e.g., 180 days), the rules management module 351 can create a rule for denying a customer's return request, which can indicate that the customer may have attempted to defraud the system.

In some embodiments, the rule management module 351 can be configured to create and/or modify rules based on input from a user of the control subsystem 350. For example, the rule management module 351 can receive input from a user for modifying one or more parameters of a rule for validating a return request and modify the parameters of the rule accordingly.

The event management module 352 may be configured to create, modify, and/or manage events stored in the return event storage area 361. For example, the event management module 352 may create a series of events for a return request initiated by a customer or the system and store the events in the return event storage area 361. By way of example, a customer may initiate a return of an order via a user device associated with the customer. The event management module 352 may create an event for receiving a return request and store the event in the return event storage area 361. In some embodiments, the event may include information related to the return, the customer, and the order associated with the return. For example, the event management module 352 may create a first event for a return requested by a customer, which may include information of the return request, a timestamp of receiving the return request, information related to the customer, or the like, or a combination thereof. The event management module 352 may create a second event when receiving one or more items from a customer that have undergone a return, which may include information related to the received items (e.g., quantity, condition, etc.), a timestamp of receiving the items, etc. The event management module 352 may also store the first event and the second event as a series of events related to the return in the return event storage area 361.

In some embodiments, the return event storage area 361 may include ^, for example, an Oracle ^TM database, ^a Sybase ^TM database, or other relational databases or non-relational databases, such as Hadoop ^TM sequence files, HBase ^TM , or Cassandra ^TM . The return event storage area 361 may include a NoSQL database, such as HBase, MongoDB ^TM , or Cassandra ^TM . Alternatively, the return event storage area 361 may include a relational database, such as Oracle, MySQL, and Microsoft SQL Server. In some embodiments, the return event storage area 361 may be in the form of a server, a general-purpose computer, a mainframe computer, or any combination of these components.

The workflow management module 353 can be configured to create, modify and/or manage workflows used by various components of the system 300 in FIG. 3A , the system 325 in FIG. 3B , and the system 375 in FIG. 3D . For example, the workflow management module 353 can be configured to create, modify and/or manage the cancellation process 383a, the return process 383b, the exchange process 383c, the delivery tracking 383d, the collection process 383e, the refund process 383f, and the revocation process 383g used by the workflow subsystem 375 (shown in FIG. 3D ).

In some embodiments, the control subsystem 350 may be configured to create, modify, and/or manage services used by the Cretaceous domain module 327 (shown in FIG. 3B ). For example, the control subsystem 350 may be configured to create, modify, and/or manage a cancellation service 329a, a return service 329b, an exchange service 329c, and/or a price reduction service 329d. The Cretaceous domain module 327 may obtain one or more services from the control subsystem 350.

The rules engine 362 may be configured to obtain rules for processing returns from the control subsystem 350 and store and/or manage rules for other components of the workflow subsystem 375 in FIG. 3D . For example, the workflow subsystem 375 in FIG. 3D may be configured to obtain rules for verifying return requests from the rules engine 362 . In some embodiments, the rules engine 362 may include a rules database 363 for storing rules for managing and/or processing returns.

The external data source 370 can be configured to store data for various components of the system including the subsystem 300 in FIG. 3A , the subsystem 325 in FIG. 3B , and the subsystem 375 in FIG. 3D . For example, the external data source 370 can store various services created and/or updated by the control subsystem 350 , including, for example, a cancellation service 329a , a return service 329b , an exchange service 329c , and/or a price reduction service 329d . The Cretaceous domain module 327 can obtain one or more services from the external data source 370 .

As another example, the external data source 370 may include an event storage area 371 configured to store data related to an event (e.g., a return event). In some embodiments, the event storage area 371 may include a write database 372 configured to write data in response to a write command. The event storage area may also include one or more read databases 373 (e.g., read database 373A, read database 373B, etc.) configured to read data only in response to a query command. In some embodiments, the read database 373 may include the same data as the data included in the write database 372. For example, if data stored in write database 372 is updated in response to a write command, corresponding data in read database 373 may be updated accordingly, so that write database 372 and read database 373 may include the same data. In some embodiments, external data source 370 may include an administrator database 374 configured to store management data for controlling subsystem 350.

In some embodiments, the event store 371 and/or the administrator database 374 may include, for example, an Oracle ^™ database, a Sybase ^™ database, or other relational or non-relational databases such as Hadoop ^™ sequence files, HBase ^™ , or Cassandra ^™ . The event store 371 and/or the administrator database 374 may include a NoSQL database such as HBase, MongoDB ^™ , or Cassandra ^™ . Alternatively, the event store 371 and/or the administrator database 374 may include a relational database such as Oracle, MySQL, and Microsoft SQL Server. In some embodiments, the event store 371 and/or the administrator database 374 may be in the form of a server, a general-purpose computer, a mainframe computer, or any combination of such components.

FIG. 3D shows an exemplary graphical representation of a workflow subsystem 375. The workflow subsystem 375 may be designated to process the output of the inbound subsystem 300. The workflow subsystem 375 may pass the output of the validator 308 to the output subsystem 325. The workflow subsystem 375 may be specifically configured for use by consumers, delivery personnel, administrators, and/or sellers. The workflow subsystem 375 may be implemented on a computing device having a processor, a memory component, and/or a communication component. In some embodiments, the workflow subsystem 375 and/or components of the workflow subsystem 375 may be communicatively coupled to other subsystems (e.g., as described in FIGS. 3A-3D).

The workflow subsystem 375 may include a framework module 377. Framework module 377 Spring WebFlux or similar technology may be utilized. Framework module 377 may provide a non-blocking web page stack to handle concurrency with a small number of threads and scale with fewer hardware resources. Framework module 377 may include various programmatic modules. An example of a module as shown in FIG. 3D may include a return module 379a, an exchange module 379b, and a cancellation module 379c. Modules 379a to 379c may contain processing logic for retail, third-party, and ticket supply. Modules 379a to 379c may also include APIs for communicating with subsystems responsible for respective data.

The workflow subsystem 375 may also include a workflow initiator 381, which may be communicatively coupled to the framework module 377. The workflow initiator 381 may include a list of processes 383a to 383g that may initiate a workflow based on input received from the framework module 377. Examples of processes as shown in FIG. 3D may include a cancellation process 383a (containing instructions for initiating a workflow initiated by canceling an order by a consumer, a supplier, or another order processor), a return process 383b (containing instructions for initiating a workflow initiated by returning a full or partial order by a consumer, a supplier, or another order processor), an exchange process 383c (containing instructions for initiating a workflow initiated by exchanging a full or partial order initiated by a consumer, a supplier, or another order processor), a delivery tracking process 383d (containing instructions for initiating a workflow initiated by exchanging a full or partial order initiated by a consumer, a supplier, or another order processor), and a return process 383b (containing instructions for initiating a workflow initiated by returning a full or partial order by a consumer, a supplier, or another order processor). ), a collection process 383e (containing instructions for initiating a workflow initiated by a request from a consumer, supplier, or another order processor for information tracking a complete or partial order), a refund process 383f (containing instructions for initiating a workflow initiated by a request for a refund for a complete or partial order initiated by a consumer, supplier, or another order processor), and a cancel process 383g (containing instructions for initiating a workflow initiated by revoking a complete or partial order initiated by a consumer, supplier, or another order processor).

In addition, each of the programmed modules 379a to 379c of the framework module 377 may initiate a plurality of processes 383a to 383g. For example, the cancellation module 379c may initiate a delivery tracking process 383d to determine whether the canceled item has been delivered or is still owned by the delivery person. The same cancellation module 379c may also initiate a refund process 383f to issue a refund to the customer.

Various combinations may be programmed and may be specifically configured for use by consumers, delivery personnel, administrators, and/or sellers. Workflow initiator 381 may be implemented on a computing device having a processor, a memory component, and/or a communication component. In some embodiments, workflow initiator 381 and/or components of workflow initiator 381 may be communicatively coupled to other portions of workflow subsystem 375 (e.g., as described in FIG. 3D ). In addition, the architecture of workflow subsystem 375 is modified to add additional processes and programmable modules as needed.

The workflow subsystem 375 may also include a workflow service module 385, which may be communicatively coupled to the workflow initiator 381 and the output subsystem 325. The workflow service module 385 may be designated for workflow control and design. The workflow service module 385 may include a Crayon workflow service module 387 and a workflow orchestration module 391. The workflow service module 385 may provide output for processing by the output subsystem 325.

The Clayton workflow service module 387 may include a number of submodules 389a-389b that may control the workflow based on input received from the workflow initiator 381. An example of a process as shown in FIG. 3D may include a retail returns submodule 389a (which allows for the design and/or control of workflows for returns of retail items) and a third-party returns submodule 389b (which allows for the design and/or control of workflows for returns of third-party items). The architecture of the Clayton workflow service module 387 is modified to add additional submodules as needed. The workflow within the Clayton workflow service module 387 may be controlled and/or designed by consumers, couriers, administrators, and/or sellers. The Clayton workflow service module 387 may be implemented on a computing device having a processor, a memory component, and/or a communication component, and may be communicatively coupled to other portions of the workflow subsystem 375.

The workflow orchestration module 391 may include a collection of workflow controls that can be accessed by consumers, delivery personnel, administrators, and/or sellers. The workflow orchestration module 391 may be implemented with a business process management (BPM) engine and supporting framework, an example of which may be Activiti using Spring Boot/Docker. The workflow orchestration module 391 engine has the following core goals: taking a process definition consisting of human tasks and service calls and executing the human tasks and service calls in an order, while exposing various APIs to start, manage, and query data about the processing instances of the definition. The workflow orchestration module 391 may be implemented on a computing device having a processor, a memory component, and/or a communication component. The workflow orchestration module 391 may be communicatively coupled to other parts of the workflow subsystem 375.

4 is a block diagram showing an exemplary system 400 for fraud detection and customer abuse consistent with the disclosed embodiments. The system 400 can generate a profile of customers requesting refunds to determine whether the customer is likely making fraudulent refund requests that are blocked or approved. The system 400 may include one or more processors 402 (referred to herein as processor 402), a client device 404, an asynchronous communication module 406 (referred to herein as asynchronous communication 406), a return management (RM) module 408 (referred to herein as RM 408), a fraud detection (FD) module 410 (referred to herein as FD 410), an abuser refund control database (ARC) 412 (referred to herein as ARC 412), a Creturn module 414 (referred to herein as Creturn 414), and a virtual enterprise rule module 416 (referred to herein as virtual enterprise rule 416). The client device 404 may communicate with the system 400 to request a refund associated with an order. The client device 404 may communicate with the system 400 using asynchronous communication 406, which may allow the system 400 to continue processing the refund request of the client device 404 in the event that communication between the client device 404 and the system 400 may be lost. The RM 408 may check whether there may be a return package and its contents associated with the refund request of the client device 404. The FD 410 may determine whether to block or approve a refund associated with the client device 404 based on rules (described below) that may determine that the client may be making a fraudulent refund request or abusing a refund request. Regardless of the device used by the customer, regardless of whether FD 410 has blocked or approved the customer's current and past refund requests, ARC 412 uses the customer device 404 to continuously store information or data related to refund requests associated with the customer. ARC 412 can use the customer device 404 to store and generate data files related to refund requests associated with the customer. Clayton 414 can make a final decision to approve or block a refund request of a customer using the customer device 404 based on enterprise rules (described below) using virtual enterprise rules 416. System 400 can obtain additional information related to refund requests associated with the customer device 404 in system 100.

System 400 may determine whether a refund request associated with a return package of a product such as a retail item or a fresh food item received from a client device 404 may be fraudulent based on a current order identifier or a previous order and/or refund request associated with a customer using client device 404. In some embodiments, a retail item may be any product that may not be consumed or ingested by a customer, while a fresh food item may be consumed or ingested by a customer.

In some embodiments, if the return package associated with the refund request of the client device 404 may be designated as a blank identifier (the package may be received, but the package may not have the items associated with the current order identifier), designated as a partial identifier (the package may be received, but the package may only contain some of the items associated with the current order identifier), or designated as a non-returned identifier (the package may not have been received at all), then the current order identifier or the previous order may be identified as fraudulent. If the return package associated with the refund request of the client device 404 may be a complete identifier (a package with all of its items may be received), then the current order identifier or the previous order may be identified as non-fraudulent. Previous orders and/or refund requests of the customer using the customer device 404 may be based on the customer's profile, from which the system 400 may identify that the customer using the customer device 404 may be associated with fraudulent refund requests due to fraudulent or abusive refund requests. After the system 400 may identify the customer as being associated with fraudulent refund requests or abusive refund requests, the customer using the customer device 404 may be designated as a fraudulent member, and refund requests or future refund requests associated with the order identifier may be designated as blocked refunds, thereby preventing the customer using the customer device 404 from receiving a refund.

System 400 can utilize the functionality of system 100, subsystem 300, subsystem 325, subsystem 355, and subsystem 375 via processor 402. Processor 402 can access, control, and execute all processors and functionality in system 100, subsystem 300, subsystem 325, subsystem 355, and subsystem 375. Processor 402 can be configured to identify whether a refund request may be fraudulent and/or whether a customer using client device 404 may abuse the refund request. Processor 402 can receive a refund request from client device 404 associated with an order identifier. Client device 404 can be a mobile device, tablet/personal digital assistant (PDA), computer, or the like that can access external front-end system 103 or its applications. Processor 402 may be communicatively coupled to client device 404 using inbound subsystem 300, where, for example, client device 404 may be API 302 and system 400 may be API 304. In addition, processor 402 may also be communicatively coupled to client device 404 using asynchronous communication 406 in the event that there may be a loss of communication with client device 404. Processor 402 may access functionality of output subsystem 325 using asynchronous communication 406, where, for example, external service proxy module 331 may be executed by processor 402 for asynchronous communication between the device of client device 404 and system 400. In addition, the processor 402 in the system 400 can be communicatively coupled to the system 100 via the import subsystem 300, where, for example, the system 100 and the system 400 can be API 302 and API 304, respectively, or vice versa. In the event that the system 400 and the system 100 lose communication, the processor 402 can execute the functions of the output subsystem 325, where, for example, the external service proxy module 331 can be executed by the processor 402 for asynchronous communication between the system 400 and the system 100.

When the processor 402 may receive a refund request associated with the order identifier from the customer device 404, the processor 402 may receive a content status associated with a return package from the customer from the RM 408 (described below with respect to FIG. 5 ). The return package from the customer using the customer device 404 may be associated with the refund request of the customer device 404. The processor 402 may determine whether the content status of the return package may be a blank identifier, a partial identifier, or a non-returned identifier. In one embodiment, the processor 402 may execute the event management module 352 to determine the content status of the return package associated with the customer device 404 from the system 100 to be stored in the return event storage area 361. Processor 402 may retrieve the content status of the return package associated with client device 404 in return event storage area 361 and store the content status of the return package in RM 408. Processor 402 may send the content status to FD 410. RM 408 may be communicatively coupled to FD 410 via import subsystem 300, where, for example, FD 410 and RM 408 may be API 302 and API 304, respectively, or vice versa. In the event that RM 408 and FD 410 may lose communication, processor 402 may execute the function of output subsystem 325, where, for example, external service proxy module 331 may be executed by processor 402 for asynchronous communication between FD 410 and RM 408.

FD 410 may receive from RM 408 a content status associated with a return package of a customer using customer device 404 (described below with respect to FIGS. 6A and 6B ), and may also receive a refund request from customer device 404. In FD 410, processor 402 may associate the content status of the return package with the order identifier of the refund request. Based on the client device 404, the order identifier of the refund request, and the content status of the return package, the processor 402 in the FD 410 can execute the rule definition (described below with respect to FIG. 6A and FIG. 6B) to determine whether the refund request of the client device 404 can be denied/blocked, where the FD 410 can designate a label of the refund request as "block refund"), or "granted"/"approved", where the FD 410 can designate a label of the refund request as "approved refund". The client device 404 can receive a notification from the system 400 that the refund request is blocked or approved. In one embodiment, the processor 402 can execute the rule engine 362, the rule database 363, and the control subsystem 350 for determining the rule definition for blocking a refund or approving a refund for a refund request. If the processor 402 in the FD 410 determines that the tag of the refund request is designated as a block refund, the processor 402 also determines that the tag of the customer using the customer device 404 is designated as a fraud member (described below with respect to FIG. 6A and FIG. 6B), thereby preventing the customer using the customer device 404 from receiving any approve refund designation tags for current and future refund requests. In another embodiment, if the processor 402 in the FD 410 determines that the tag of the refund request is designated as an approve refund, the processor 402 also determines that the customer is designated as a non-fraud member tag, thereby allowing the customer using the customer device 404 to receive approve refund tags for current and future refund requests. The block refund designation tag or the approve refund designation tag of the refund request may be a refund status. The designated label of a fraudulent member or non-fraudulent member of a customer using customer device 404 may be a member fraud status. Even though the customer using customer device 404 may have received a previous refund status and a previous member fraud status and may attempt to disguise a new refund request by using another device or a different name, processor 402 in FD 410 may execute logging and tracking module 314 to identify the customer associated with the previous refund status and the previous member fraud status. Processor 402 may store the refund status and member fraud status associated with the customer using customer device 404 and the refund request to ARC 412 (described below with respect to FIGS. 6A and 6B). FD 410 may be communicatively coupled to ARC 412 via ingress subsystem 300, where, for example, ARC 412 and FD 410 may be API 302 and API 304, respectively, or vice versa. In the event that FD 410 and ARC 412 may lose communication, processor 402 may execute functions of output subsystem 325, where, for example, external service proxy module 331 may be executed by processor 402 for asynchronous communication between ARC 412 and FD 410.

The processor 402 may continuously and automatically build a profile of a customer using the client device 404 from the refund status and member fraud status of the current order identifier associated with the device or from the refund status and member fraud status from previous orders associated with previous devices in the ARC 412. In one embodiment, the ARC 412 may be the external data source 370. The processor 402 may continuously update or aggregate the profile of the customer using the client device 404 in the ARC 412 based on the customer's current and previous orders, current and previous devices, current and previous refund requests, current and previous fraud status, and/or current and previous member fraud status. Processor 402 may send the fraud status and member fraud status to Clayton 414 (described below with respect to FIGS. 7A and 7B ) for final determination of refund request fraud status and member status. Clayton 414 may be communicatively coupled to ARC 412 via inbound subsystem 300, where, for example, ARC 412 and Clayton 414 may be API 302 and API 304, respectively, or vice versa. In the event that Clayton 414 and ARC 412 may lose communication, processor 402 may execute the functions of output subsystem 325, where, for example, external service proxy module 331 may be executed by processor 402 for asynchronous communication between ARC 412 and Clayton 414.

Crayon 414 may receive and/or request fraud status and member status from ARC 412. Processor 402 in Crayon 414 may modify FD 410 fraud status and member status determination to block a refund or approve a refund for a refund request from a client device 404 associated with an order identifier. In another embodiment, Crayon 414 may perform FD 410 fraud status and member status determination to block a refund or approve a refund for a refund request from a client device 404 associated with an order identifier.

The processor 402 can be communicatively coupled with the client device 404 using the ingress subsystem 300, where, for example, the client device 404 can be the API 302 and the Crayon 414 can be the API 304. In addition, in the event that the Crayon 414 and the client device 404 can lose communication, the processor 402 can perform the functions of the egress subsystem 325, where, for example, the external service proxy module 331 can be executed by the processor 402 via the asynchronous communication 406 for asynchronous communication between the ARC 412 and the Crayon 414. In addition, in the case where there may be no data associated with the refund request of the client device 404 in the ARC 412, the processor 402 may be communicatively coupled to the FD 410 via the inbound subsystem 300, where, for example, the FD 410 and the Crayon 414 may be the API 302 and the API 304, respectively, or vice versa. In the case where the Crayon 414 and the FD 410 may lose communication, the processor 402 may perform the functions of the output subsystem 325, where, for example, the external service proxy module 331 may be executed by the processor 402 for asynchronous communication between the FD 410 and the Crayon 414. In addition, in the case where data associated with the refund request of the client device 404 in the FD 410 may not exist, the processor 402 may be communicatively coupled to the RM 408 via the import subsystem 300, where, for example, the RM 408 and the Crayon 414 may be API 302 and API 304, respectively, or vice versa. In the case where the Crayon 414 and the RM 408 may lose communication, the processor 402 may execute the functions of the output subsystem 325, where, for example, the external service proxy module 331 may be executed by the processor 402 for asynchronous communication between the CRMS 410 and the Crayon 414.

The processor 402 in the Crayon 414 may execute the functions of the control subsystem 350 to modify or change the rule definition in the FD 410 to determine whether the client device 404 refund request may be to block a refund or approve a refund. In yet another embodiment, the processor 402 in the Crayon 414 may execute the virtual enterprise rules 416 via the workflow subsystem 375 to modify or change the rule definition in the FD 410. The virtual enterprise rules 416 may allow an administrator or enterprise user to create new rules based on new enterprise requirements, and the new rules will designate a label of the client as a fraudulent member even though the ARC 412 has a client using the client device 404 as a non-fraudulent member. In another embodiment, virtual enterprise rules 416 may allow an administrator or enterprise user to create a new rule based on a new enterprise requirement that specifies a label of a customer using client device 404 as a non-fraudulent member despite ARC 412 having the customer as a fraudulent member. In yet another embodiment, virtual enterprise rules 416 may allow an administrator or enterprise user to create a new rule based on a new enterprise requirement that specifies a label of a refund request as a blocked refund despite ARC 412 having the refund request as a approved refund. In yet another embodiment, virtual enterprise rules 416 (described below with respect to FIGS. 7A and 7B ) may allow an administrator or enterprise user to create new rules based on new enterprise requirements that would label a refund request as an approved refund despite the ARC 412 having the refund request as a blocked refund. An administrator or enterprise user may interact with the workflow service module 385 to create new rules based on new enterprise requirements without requiring an experienced programmer to hard code rule definitions in FD 410. An administrator or enterprise user may be a layman in programming, where an administrator or business person may virtually create a refund submodule similar to the retail return submodule 389a or the third party return submodule 389b to create new rules based on enterprise requirements. The processor 402 may then execute the virtual enterprise rules 416 to modify or change the refund status or member fraud status associated with the refund request of the client device 404 to block a refund or approve a refund based on the new rules.

The virtual enterprise rules 416 may be communicatively coupled to the Crayon 414 via the ingress subsystem 300, where, for example, the virtual enterprise rules 416 and the Crayon 414 may be API 302 and API 304, respectively, or vice versa. In the event that the Crayon 414 and the virtual enterprise rules 416 may lose communication, the processor 402 may execute the functions of the output subsystem 325, where, for example, the external service proxy module 331 may be executed by the processor 402 for asynchronous communication between the Crayon 414 and the virtual enterprise rules 416.

In another embodiment, processor 402 may execute and access all functions of system 100 and subsystems 300, 325, 355, and 375 for concurrent execution of each asynchronous communication 406, RM 408, FD 410, ARC 412, Clayton 414, and/or virtual enterprise rules 416.

FIG5 is a flow chart of an exemplary method 500 for determining the content status of a return package consistent with the disclosed embodiments. The steps of method 500 describe an embodiment of the steps in RM 408. The steps of method 500 may be performed by processor 402 executing inbound subsystem 300, wherein the determination of the content status and order identifier associated with the return package in system 100 may be performed by validator 308, exception handler 310, data aggregator 312, and logging and tracking module 314. At step 506, processor 402 may determine whether a return package has been received from system 100. At step 506, if processor 402 determines that a return package is received (step 506--yes), processor 402 further determines at step 508 that an order identifier is associated with the return package. Processor 402 may store the order identifier associated with the return package in a database.

At step 510, the processor 402 may check the content status of the return package from the system 100, wherein the processor 402 may determine whether the return package may be a blank label, a partial label, an unreturned label, or a completed label.

At step 512, processor 402 may store the content status of the return package in a database. However, if processor 402 determines that the return package has not been received (step 506—No), processor 402 stores the content status of the return package in the database as a non-returned identifier. The database may aggregate all content statuses associated with all return packages for all current and previous order identifiers.

At step 516, processor 402 may send the content status and order identifier associated with the return package stored in the database to FD 410.

6A and 6B are flow charts of an exemplary method 600 for determining refund status and member status based on rule definitions of retail goods or fresh food consistent with the disclosed embodiments. The steps of method 600 depict an embodiment of the steps in FD 410. The steps of method 600 may be performed by processor 402 executing inbound subsystem 300, wherein the identification of the customer associated with the refund request, the order identifier, whether the return package can be a retail product or fresh food, and the content status in system 100, asynchronous communication 406, and RM 408 may be performed by validator 308, exception handler 310, data aggregator 312, and record & track module 314. The steps of method 600 may be executed by processor 402 of rule engine 362, rule database 363 and control subsystem 350 to determine the refund status and member fraud status associated with the refund request. Processor 402 may store the customer's identity, order identifier, customer device 404, whether the return package can be retail goods or fresh food, content status, refund status, and member fraud status associated with the refund request in the database. The processor 402 may aggregate or accumulate data (information) from the current order identifier, the customer device 404, the refund request, the previous order associated with the previous refund request, the previous device, the previous content status, and the return package from the database, the previous refund status, and the previous member fraud status in the database of the customer using the customer device 404.

After executing step 516 in FIG. 5 , at step 606 , processor 402 may receive a refund request from a device of client device 404 . At step 608 , processor 402 may utilize logging & tracking module 314 to determine the identity of a customer using client device 404 that may be stored in a database. Even though a customer using client device 404 may attempt to conceal their identity by using a different device, registration identifier, name, physical address, IP address, MAC address, or communication format, processor 402 may determine the identity of a customer using client device 404 based on information (data files) currently and previously aggregated or accumulated in a database by processor 402 .

At step 610, processor 402 may identify the order identifier associated with client device 404 in RM 408 and the refund request from system 100 and the content status from the database. Processor 402 may store the order identifier in the database.

At step 612, processor 402 may determine from the order identifier whether the refund request may be associated with a retail item or a fresh food item (information determined in system 100). If processor 402 determines that the refund request may be associated with a fresh food item (step 612—No), processor 402 proceeds to FIG. 6B. However, if processor 402 determines that the refund request may be associated with a retail item (step 612—Yes), then at step 614, processor 402 determines the content status of the return package from the database in RM 408. If the processor 402 determines that the content status of the return package that can be associated with the refund request can be a blank identifier, a partial identifier, or an unreturned identifier (step 614--yes), then at step 616, the processor 402 determines whether the customer's return package is at least the third return package of all return packages from the customer. If the processor 402 determines that the return package may not be at least the third return package (step 616--no), then at step 618, the processor 402 determines that the customer's designated label may not be "fraud member", and the processor 402 may determine that the refund request designated label may be approved refund. The processor 402 may store the designated label non-fraud member and approved refund (respectively, member fraud status and refund status) in the database.

However, if processor 402 determines that the return package may be at least the third return package (step 616—yes), then at step 620, processor 402 determines that the total value of all return packages from the customer may be greater than the first threshold price of $30,000 as an example. If processor 402 determines that the total value of all return packages from the customer using customer device 404 may be less than or equal to the first threshold price of $30,000 as an example, processor 402 executes step 618.

However, if processor 402 determines that the total value of all return packages from the customer using client device 404 may be greater than the first threshold price (step 620—yes), then at step 622, processor 402 determines the number of return packages from the customer using client device 404 that have been above the first threshold percentage (as an example, 20%) of all orders requested by the customer within the past first threshold time (as an example, 180 days). If processor 402 determines that within the past first threshold time (as an example, 180 days), customers using customer device 404 may have had a number of return packages that is less than or equal to the first threshold percentage (as an example, 20%) of all orders requested by customers using customer device 404 (step 622 - No), processor 402 executes step 618.

However, if processor 402 determines that the customer using customer device 404 may have had a number of return packages greater than the first threshold percentage of all orders requested by the customer using customer device 404 within the past first threshold time (step 622--yes), then at step 624, processor 402 determines whether the customer's refund requests within the past first threshold time may have totaled to exceed the first threshold percentage of all refund requests of the customer. If processor 402 determines that the customer's refund requests within the past first threshold time may have totaled to less than or equal to the first threshold percentage of all refund requests of the customer (step 624--no), processor 402 executes step 618.

However, if the processor 402 determines that the refund requests from the client device 404 may have totaled to be greater than the first threshold percentage of all refund requests from the customers using the client device 404 within the past first threshold time (step 624--yes), then at step 626, the processor 402 assigns a label to the customer using the client device 404 as a fraudulent member and stores the assigned label in the database. At step 628, the processor 402 may assign a label to the refund request associated with the order identifier as a blocked refund and may store the assigned label in the database. At step 630, the processor 402 may store the member fraud status and the refund status in the ARC 412. Additionally, processor 402 may store all information in the database in ARC 412.

However, if processor 402 determines that the content status of the return package associated with the refund request may be a completion indicator (step 614--no), then at step 632, processor 402 determines whether the customer using client device 404 may have had a number of refund requests that is higher than the second threshold percentage (as an example, 40%) of all orders of the customer within the past second threshold time (as an example, 6 months). If processor 402 determines that the customer using client device 404 may have had a number of refund requests that are higher than the second threshold percentage (as an example, 40%) of all orders of the customer within the past second threshold time (as an example, 6 months) (step 632--yes), then at step 634, processor 402 determines that the customer's designated label may be a fraudulent member, and processor 402 may determine that the refund request designated label may be a blocked refund. Processor 402 may store the designated labels fraudulent member and blocked refund (member fraud status and refund status, respectively) in the database.

However, if processor 402 determines that the customer may have had a number of refund requests less than or equal to the second threshold percentage of all orders of the customer during the past second threshold time (step 632--no), then at step 636, processor 402 determines whether the customer's refund requests during the past second threshold time may have totaled to a second threshold percentage greater than all refund requests of the customer. If processor 402 determines that the customer's refund requests during the past second threshold time may have totaled to a second threshold percentage greater than all refund requests of the customer (step 636--yes), processor 402 executes step 634.

However, if processor 402 determines that the customer's refund requests may have totaled less than or equal to the second threshold percentage of all refund requests for the customer within the past second threshold time (step 636 - No), then at step 638, processor 402 determines whether the customer may have had outstanding refund requests totaling the second threshold price or greater than the second threshold price (as an example, $2,000,000 or greater) within the past third threshold time (as an example, 3 months). If processor 402 determines that customers who used client device 404 within the past third threshold time (as an example, 3 months) may have outstanding refund requests totaling the second threshold price or more (as an example, $2,000,000 or more) (step 638--yes), processor 402 executes step 634.

However, if the processor 402 determines that the customer who used the customer device 404 within the past third threshold time may have pending refund requests totaling less than the second threshold price (step 638--no), then at step 640, the processor 402 assigns a label to the customer as a non-fraudulent member and stores the assigned label in the database. At step 642, the processor 402 may assign a label as an approved refund to the refund request associated with the order identifier and may store the assigned label in the database. At step 644, the processor 402 may store the member fraud status and the refund status in the ARC 412. In addition, the processor 402 may store all information in the database in the ARC 412.

Referring to FIG. 6B , after executing step 612 in FIG. 6A , the processor 402 may determine that there may not be a return package because the system 400 may limit return packages associated with fresh food. The client device 404 may only request a refund request for fresh food. At step 670 , the processor 402 may store the order identifier associated with the refund request as fresh food in the database.

At step 672, the processor 402 may determine whether the refund request of the client device 404 may total to be greater than or equal to the third threshold price of all orders from the client associated with fresh food (as an example, $150,000). The database may have the client's current and aggregated/accumulated previous orders associated with fresh food. If the processor 402 determines that the refund request of the client device 404 may total to be greater than or equal to the third threshold price of all orders from the client associated with fresh food (as an example, $150,000) (step 672--yes), then at step 674, the processor 402 determines that the designated tag of the client may be a fraudulent member, and the processor 402 may determine that the refund request designated tag may be a block refund. Processor 402 can store the designated label fraud member and blocked refund (respectively, member fraud status and refund status) in the database.

However, if the processor 402 determines that the total refund requests from the client device 404 is less than the third threshold price of all orders from the client associated with fresh food (step 672--no), then at step 676, the processor 402 determines whether the number of refund requests associated with fresh food in the past fourth threshold time (as an example, 30 days) can be greater than or equal to the first threshold number of all orders from the client associated with fresh food (as an example, 10). If the processor 402 determines that the number of requests associated with fresh food in the past fourth threshold time can be greater than or equal to the first threshold number of all orders from the client associated with fresh food (step 676--yes), the processor 402 executes step 674.

However, if the processor 402 determines that the number of requests associated with fresh food within the past fourth threshold time may be less than the first threshold number of all orders associated with fresh food for the customer (step 676--no), then at step 678, the processor 402 assigns a label to the customer as a fraudulent member and stores the assigned label in the database. At step 680, the processor 402 may assign a label as a block refund to the refund request associated with the order identifier and may store the assigned label in the database. At step 682, the processor 402 may store the member fraud status and the refund status in the ARC 412. In addition, the processor 402 may store all information in the database in the ARC 412.

7A and 7B are flow charts of an exemplary method 700 for determining a final refund status or final member status based on corporate rules for retail goods or fresh food consistent with the disclosed embodiments. The steps of method 700 describe an embodiment of steps in Clayton 414 and virtual corporate rules 416 in detail. The steps of method 700 may be performed by a processor 402 that executes an import subsystem 300 to communicate with the system 100, client device 404, asynchronous communication 406, RM 408 and database, FD 410 and database, ARC 412 via API 302, wherein a validator 308, an exception handler 310, a data aggregator 312, and a logging & tracking module 314 may process data received from API 302. In one embodiment, the steps of method 700 may be performed by processor 402 that executes rule management module 351, workflow management module 353, framework module 377, workflow initiator 381, workflow service module 385, discount service 329d in Crestron domain module 327, external service agent module 331, and welfare service 339d in external service 339a to external service 339e.

Processor 402 may execute steps of method 700 to receive the refund status and member fraud status determination of FD 410 and may approve the refund or block the refund based on the determination of FD 410. In another embodiment, processor 402 may execute steps of method 700 to receive the refund status and member fraud status determination of FD 410 and may change the refund status and member fraud status determination of FD 410 to approve the refund for fraudulent members if the refund request is designated as blocking the refund. In yet another embodiment, the processor 402 may execute the steps of method 700 to receive the refund status and member fraud status determination of FD 410, and may change the refund status and member fraud status determination of FD 410 to block refund for non-fraud members if the refund request is designated as approved refund. In yet another embodiment, the processor 402 may execute the steps of method 700 to receive the refund status and member fraud status determination of FD 410, and may change the member fraud status determination of FD 410 to approve refund for another blocked refund by changing the fraud member to a non-fraud member. In yet another embodiment, the processor 402 may execute the steps of method 700 to receive the refund status and member fraud status determination of FD 410, and may change the member fraud status determination of FD 410 to block the refund by changing the non-fraud member to a fraud member for another approved refund. The processor 402 in the steps of method 700 may change the refund status and member status of FD 410 based on the enterprise rules, which the processor 402 receives from the virtual enterprise rules 416 in the workflow service module 385.

When, for example, a product in the market associated with a refund request from a customer device 404 may not generate high revenue in the system 100, the business rules may be determined by an administrator or business user, and the administrator or business user may wish to increase sales by changing all refund statuses to approved regardless of the customer's member fraud status to promote the purchase of the product in the system 100. In addition, when, for example, a product in the system 100 associated with a refund request from a customer device 404 may be considered defective by its manufacturer, the business rules may be determined by an administrator or business user, and the administrator or business user may therefore change all refund statuses to approved regardless of the customer's member fraud status. In addition, enterprise rules can be changed by administrators or enterprise users to promote products in system 100, which generates more purchases by customers, or to discourage fraudulent activities related to products in system 100 by customers. In addition, enterprise rules can be changed by administrators or enterprise users to attract customers to purchase more products in system 100 or to discourage customers from purchasing more products in system 100.

If the processor 402 receives a refund request from the customer device 404 while executing the steps for Cretaceous 414 of method 700, but the processor 402 may not communicate with ARC 412, FD 410, and RM 408, the processor 402 requests the content status of the retail item associated with the customer device 404 directly from the database and requests the customer's identity and order identifier directly from the database. In addition, the processor 402 can use the content status, customer identity and order identifier to determine the refund status and member status by executing the refund program 383f in the rule management module 351, the framework module 377 and the workflow launcher 381 to block the refund or approve the refund by notifying the client device 404 of the refund status to the discount service 329d in the Cretaceous domain module 327, the external service agent module 331 and the external service 339a to the welfare service 339d in the external service 339e. In yet another embodiment, the processor 402 may continue to perform the enterprise rules (virtual enterprise rules 416) received from the workflow service module 385 to determine the refund status and member fraud status after executing the refund process 383f in the rule management module 351, the framework module 377, and the workflow initiator 381. Subsequently, the processor 402 in the step of method 700 may notify the client device 404 by sending the refund status to the price reduction service 329d in the Crescent domain module 327, the external service proxy module 331, and the welfare service 339d in the external service 339a to the external service 339e. In yet another embodiment, the processor 402 may completely bypass the RM 408, FD 410, and ARC 412 when executing the steps of the method 700 to determine the refund status and member fraud status based on the enterprise rules received from the virtual enterprise rules 416 to notify the refund status to the client device 404 via the price reduction service 329d in the Cretaceous domain module 327, the external service proxy module 331, and the welfare service 339d in the external services 339a to 339e.

At step 706, processor 402 may receive a refund request from customer device 404. Processor 402 may recognize the order identifier associated with the customer and the refund request (from system 100).

At step 708, processor 402 may determine whether the order identifier or refund request can be associated with retail goods or fresh food (information determined in system 100). In yet another embodiment, processor 402 in step 708 may receive a determination of whether the order identifier or refund request can be associated with retail goods or fresh food from FD 410 and/or its database. If processor 402 determines that the refund request can be associated with fresh food (step 708--No), processor 402 proceeds to FIG. 7B.

However, if the processor 402 determines that the refund request can be associated with the retail item (step 708--yes), then at step 710, the processor 402 determines whether the ARC 412 can be accessible. If the processor 402 determines that the ARC 412 can be accessible (step 710--yes), then at step 712, the processor 402 extracts the refund status and member fraud status associated with the refund request from the ARC 412 and stores the refund status and member fraud status in the database. The processor 402 can store the refund status and member fraud status of previous orders from the customer in the database. The processor 402 can store all the information in the database in the ARC 412.

At step 714, processor 402 may use the refund status and member fraud status from FD 410 or may utilize enterprise rules in virtual enterprise rules 416 to change the refund status and/or member fraud status. At step 716, processor 402 may approve a refund of the customer's refund request, where a notification may be sent to customer device 404, or at step 718, processor 402 may block a refund of the customer's refund request using customer device 404, where a notification may be sent to customer device 404.

However, if the processor 402 determines that the ARC 412 may not be accessible (step 710—No), then at step 720, the processor 402 determines whether the database may be accessible. If the processor 402 determines that the database may be accessible (step 720—Yes), the processor 402 executes step 712 and step 716 or step 718.

However, if the processor 402 determines that the database is not accessible (step 720—No), then at step 722, the processor 402 searches the database for previous refund status and member fraud status from previous orders associated with the customer.

At step 724, processor 402 may determine whether the database is accessible. If processor 402 determines that the database is accessible (step 724--yes), then at step 726, processor 402 retrieves the content status of the return package associated with the refund request of client device 404 and stores the content status to the database. At step 714, processor 402 may determine the refund status and member fraud status of the refund request by executing existing rule definitions in FD 410 and/or using enterprise rules in virtual enterprise rules 416. Processor 402 may then proceed to step 716 or step 718.

However, if processor 402 determines that the database is not accessible (step 724--no), then at step 714, processor 402 determines the refund status and member fraud status associated with the refund request based on the customer's previous refund status and member fraud status. Processor 402 may execute existing rule definitions in FD 410 and/or enterprise rules in virtual enterprise rules 416 to determine the refund status and member fraud status associated with the refund request of customer device 404. Processor 402 may then proceed to step 716 or step 718.

Referring to FIG. 7B , after executing step 708, the processor 402 may determine whether the ARC 412 is accessible at step 770. If the processor 402 determines that the ARC 412 is accessible (step 770—yes), then at step 772, the processor 402 retrieves the refund status and member fraud status associated with the refund request from the ARC 412 and stores the refund status and member fraud status in the database.

At step 774, processor 402 may use the refund status and member fraud status from FD 410 or may change the refund status and/or member fraud status based on the enterprise rules in virtual enterprise rules 416. At step 776, processor 402 may approve a refund of a refund request of a customer using customer device 404, where a notification may be sent to customer device 404, or at step 778, processor 402 may block a refund of a refund request of a customer using customer device 404, where a notification may be sent to customer device 404.

However, if the processor 402 determines that the ARC 412 may not be accessible (step 770—No), then at step 780, the processor 402 determines whether the database may be accessible. If the processor 402 determines that the database may be accessible (step 780—Yes), the processor 402 executes step 772 and step 776 or step 778.

However, if the processor 402 determines that the database is not accessible (step 780--no), then at step 782, the processor 402 retrieves the database for previous refund status and member fraud status from previous orders associated with the customer.

At step 774, processor 402 determines the refund status and member fraud status associated with the refund request based on the customer's previous refund status and member fraud status. Processor 402 may execute existing rule definitions in FD 410 and/or enterprise rules in virtual enterprise rules 416 to determine the refund status and member fraud status associated with the refund request of customer device 404. Processor 402 may then proceed to step 776 or step 778.

Although the present disclosure has been shown and described with reference to specific embodiments of the present disclosure, it should be understood that the present disclosure may be practiced in other environments without modification. The foregoing description has been presented for illustrative purposes. The foregoing description is not exhaustive and is not limited to the precise forms or embodiments disclosed. Modifications and adaptations will be apparent to those having ordinary skill in the art from consideration of this specification and practice of the disclosed embodiments. In addition, although the disclosed embodiments are described as being stored in memory, a person skilled in the art will appreciate that such embodiments may also be stored on other types of computer-readable media, such as secondary storage devices, such as hard disks or CD ROMs, or other forms of RAM or ROM, USB media, DVDs, Blu-rays, or other optical media.

Computer programs based on the written description and disclosed methods are within the skills of experienced developers. Various programs or program modules can be created using any of the techniques known to those of ordinary skill in the art or can be designed in conjunction with existing software. For example, program sections or program modules can be designed with or by means of .Net Framework, .Net Compact Framework (and related languages, such as Visual Basic, C, etc.), Java, C++, Objective-C, HTML, HTML/AJAX combination, XML, or HTML including Java applets.

Furthermore, although illustrative embodiments have been described herein, a person of ordinary skill in the art will understand the scope of any and all embodiments with equivalent elements, modifications, omissions, combinations (e.g., of aspects in various embodiments), adaptations, and/or changes based on this disclosure. Limitations in the claims should be interpreted broadly based on the language employed in the claims and are not limited to the examples described in this specification or during the prosecution of this application. Examples should be considered non-exclusive. Furthermore, the steps of the disclosed methods may be modified in any manner, including by reordering the steps and/or inserting or deleting steps. Therefore, it is intended that this specification and examples be considered illustrative only, with the true scope and spirit being indicated by the full scope of the claims below and their equivalents.

100:System

400:System

402:Processor

404: Client Device

406: Asynchronous communication module

408: Return management module

410: Fraud detection module

412: Abuse Refund Control Database

414: Crayon Module

416: Virtual Enterprise Rules Module

Claims (19)

A computer-implemented system for detecting and avoiding return fraud, the system comprising: a memory storing instructions; and at least one processor configured to execute the instructions to perform steps including: receiving a refund request associated with an order identifier from a device; identifying from the device a content status associated with a return package associated with the order identifier, wherein the content status includes a blank identifier; , a partial identifier, a non-returned identifier, and a completed identifier; associating the refund request associated with the order identifier with the content status associated with the return package; determining a customer associated with the refund request and the content status; aggregating the customer's data file based on the refund request, the device, and the content status; and determining a refund request based on at least one rule definition and the customer's The data file specifies a refund status and a fraudulent member status associated with the refund request of the customer, wherein the refund status includes one of approving a refund and blocking a refund; determining approval or denial of the refund request based on the refund status, the fraudulent member status, and at least one business rule; providing the approval or denial of the refund request to the device of the customer, wherein the customer associated with the refund request is determined to be an aggregate of the data file based on tracking identifiers or span identifiers added to data associated with communications used to generate the aggregated data file, so that the customer can be determined even when previous customer activities are associated with different devices, user identifiers (IDs), names, entity addresses, IP addresses, MAC addresses, or communication formats. A system as described in claim 1, wherein the device comprises a mobile phone, a computer, or a personal digital assistant. A system as claimed in claim 1, wherein the device is connected to a user interface. A system as described in claim 1, wherein the return package contains one or more items. A system as described in claim 1, wherein the return package contains retail goods. A system as described in claim 1, wherein the return package does not include fresh food. A system as described in claim 1, wherein the data file of the customer is stored in at least one database. A system as claimed in claim 1, wherein the data file of the customer includes at least one or more previous orders. A system as described in claim 1, wherein the at least one enterprise rule overrides the at least one rule definition. A computer-implemented system for detecting and avoiding return fraud, the system comprising: a memory storing instructions; and at least one processor configured to execute the instructions to perform the following steps: Receive a refund request associated with an order identifier from a device; associate the refund request with the order identifier, the device, and a content status associated with a return package, wherein the content status includes one of a blank identifier, a partial identifier, a non-returned identifier, and a completed identifier; determine a customer associated with the refund request and the content status; aggregate the customer's data file based on the refund request, the device, and the content status; specify the refund request associated with the customer based on at least one rule definition and the customer's data file; A refund status and a fraudulent member status associated with a refund request, wherein the refund status includes one of approving a refund and blocking a refund; determining approval or denial of the refund request based on the refund status, the fraudulent member status, and at least one business rule; providing the approval or denial of the refund request to the device of the customer, wherein the customer associated with the refund request is determined to be an aggregated data file based on a tracking identifier or a span identifier added to data associated with a communication used to generate the aggregated data file by analyzing the aggregated data file, so that the customer can be determined even when previous customer activities are associated with different devices, user identifiers (IDs), names, entity addresses, IP addresses, MAC addresses, or communication formats. A system as described in claim 10, wherein the device comprises a mobile phone, a computer, or a personal digital assistant. A system as claimed in claim 10, wherein the device is connected to a user interface. A system as described in claim 10, wherein the return package contains one or more items. A system as described in claim 10, wherein the refund request includes fresh food or retail goods. A system as described in claim 10, wherein the data file of the customer is stored in at least one database. A system as claimed in claim 10, wherein the data file of the customer includes at least one or more previous orders. A system as described in claim 10, wherein the at least one enterprise rule overrides the at least one rule definition. A system as described in claim 10, wherein the at least one enterprise rule is the rule definition. A computer-implemented method for detecting and avoiding return fraud, the method comprising: receiving a refund request associated with an order identifier from a device; identifying a content status associated with a return package associated with the order identifier from the device, wherein the content status includes one of a blank identifier, a partial identifier, a non-returned identifier, and a completed identifier; associating the refund request associated with the order identifier with the content status associated with the return package; determining a customer associated with the refund request and the content status; aggregating a data file of the customer based on the refund request, the device, and the content status; assigning the refund request to the customer based on at least one rule definition and the data file of the customer associated refund status and fraudulent member status, wherein the refund status includes one of approving a refund and blocking a refund; determining approval or denial of the refund request based on the refund status, the fraudulent member status, and at least one business rule; providing the approval or denial of the refund request to the device of the customer, wherein the customer associated with the refund request is determined to be an aggregated data file based on a tracking identifier or a span identifier added to data associated with the communication used to generate the aggregated data file by analyzing the aggregated data file, so that the customer can be determined even when previous customer activities are associated with different devices, user identifiers (IDs), names, entity addresses, IP addresses, MAC addresses, or communication formats.