Computerized systems and methods for fraud detection and user account deduplication

Abstract

This invention provides a system and method for fraud detection and deduplication of user accounts. One method includes: receiving a request from a user to register a third user account; receiving user information associated with the third user account, wherein the user information includes a second attribute; modifying a first database at a third time entry by: searching for a plurality of first entries in the first database; comparing the second attribute with a first attribute of each first entry; determining that at least one first entry includes a first attribute consistent with the second attribute; adding a second entry and a third entry, wherein the second entry includes the first user account and the third user account, the second attribute, and the first and third time entries, and the third entry includes the second user account and the third user account, the second attribute, and the second and third time entries.

Description

Technical Field

[0001] This disclosure generally relates to computerized systems and methods for fraud detection and deduplication of user accounts. Specifically, embodiments of this disclosure relate to an inventive and non-traditional system for registering new user accounts with low computational load by searching for entries in an initial data store and modifying the data store by incrementally adding new entries for each newly registered user account. Prior Technology

[0002] Many organizations (such as businesses) provide online platforms for consumers to interact with the organization. These online platforms often allow consumers to register user accounts to interact with the organization. For example, a business may allow consumers to register user accounts that include user profiles and allow users to purchase or monitor products sold online.

[0003] Many consumers prefer the simple registration process for their user accounts. However, typical registration processes often struggle to control user account abuse (e.g., fraud, misinformation, content censorship) because banned users can easily register new accounts to continue their illegal activities, thus harming organizations and other users. For example, some niche interest groups use social media to spread misinformation. A typical registration process may ban users spreading misinformation, but the same process may not prevent banned users from registering new user accounts using the same personal information (e.g., mobile phone number, email address, home address, etc.). This problem can be exacerbated by the increase in the number of user accounts. Furthermore, for organizations, manually searching each user account to identify fraudulent user accounts is often difficult and time-consuming.

[0004] Furthermore, duplicate accounts can cause unexpected losses for organizations. For example, online shoppers may register multiple accounts to perform duplicate functions and repeatedly utilize promotional transactions. Sellers may register multiple accounts to leverage promotional incentives or upgrade product rankings. Such abuse can quickly deplete an organization's campaign budget and cause campaigns to miss a large portion of their intended audience.

[0005] When an online platform contains fraudulent users with duplicate accounts, it severely degrades the quality of the organization's online platform and consequently significantly reduces the user experience for consumers. If the online platform automatically detects duplicate accounts, identifies fraudulent users who should be banned, and permanently removes the user accounts of fraudulent users, the quality of the organization's online platform will be significantly improved.

[0006] Therefore, there is a need for adjustable, automated, and accurate improved systems and methods for fraud detection and deduplication of user accounts. Summary of the Invention

[0007] One aspect of this disclosure relates to a system for fraud detection and deduplication of user accounts. The system may include: a first data store including a plurality of first entries, wherein each first entry includes a pair of first user accounts and a second user account, at least one first attribute shared between the pair of first user accounts and the second user account, and a first time entry and a second time entry; memory for storing instructions; and at least one processor configured to execute instructions. The instructions may include: receiving a request from the user to register a third user account; receiving user information associated with the third user account, wherein the user information includes a second attribute; modifying the first database at a third time entry by: searching for multiple first entries in the first database; comparing the second attribute with the first attribute of each first entry; determining that at least one first entry includes a first attribute consistent with the second attribute; adding a second entry and a third entry, wherein the second entry includes the first user account and the third user account, the second attribute, and the first time entry and the third time entry, and the third entry includes the second user account and the third user account, the second attribute, and the second time entry and the third time entry; assigning a registration status to the third user account based on the second attribute; and sending a notification indicating the registration status of the third user account to the user.

[0008] Another aspect of this disclosure relates to a method for fraud detection and deduplication of user accounts. The method may include a first database comprising a plurality of first entries, each first entry including a pair of first and second user accounts, at least one first attribute shared between the pair of first and second user accounts, and a first and second time entries. The method may include: receiving a request from a user to register a third user account; receiving user information associated with the third user account, wherein the user information includes a second attribute; modifying the first database at a third time entry by: searching the first database for a plurality of first entries; comparing the second attribute with the first attribute of each first entry; determining that at least one first entry includes a first attribute consistent with the second attribute; adding a second and a third entry, wherein the second entry includes the first and third user accounts, the second attribute, and the first and third time entries, and the third entry includes the second and third user accounts, the second attribute, and the second and third time entries; assigning a registration status to the third user account based on the second attribute; and sending a notification indicating the registration status of the third user account to the user.

[0009] Another aspect of this disclosure relates to a system for fraud detection and deduplication of user accounts. The system may include: a first database comprising a plurality of first entries, each first entry including a pair of first and second user accounts, at least one first attribute shared between the pair of first and second user accounts, and a first and second time entries; memory storing instructions; and at least one processor configured to execute the instructions. The instructions may include: receiving a request from a user to register a third user account; receiving user information associated with the third user account, wherein the user information includes a second attribute; at a third time entry, modifying the first database by: searching the first database for a plurality of first entries; comparing the second attribute with the first attribute of each first entry; determining that at least one first entry includes a first attribute consistent with the second attribute; adding a second and a third entry, wherein the second entry includes the first and third user accounts, the second attribute, and the first and third time entries, and the third entry includes the second and third user accounts, the second attribute, and the second and third time entries. The instruction may further include: classifying the first attribute and the second attribute into attributes of a first type and attributes of a second type; determining, based on the attributes of the first type, that the third user account has been registered; determining, based on the attributes of the second type, that the third user account has not been registered; specifying a registration status to the third user account based on the second attribute; and sending a notification indicating the registration status of the third user account to the user.

[0010] Other systems, methods, and computer-readable media are also discussed in this paper. Simple Explanation of the Diagram

[0011] Figure 1A is a schematic block diagram illustrating an exemplary embodiment of a network including communications for implementing delivery, transport, and logistics operations, consistent with the disclosed embodiments. Figure 1B depicts a sample Search Result Page (SRP) consistent with the disclosed embodiment, containing one or more search results that satisfy the search request and interactive user interface elements. Figure 1C depicts a sample Single Display Page (SDP) consistent with the disclosed embodiment, which includes information about the product and interactive user interface elements. Figure 1D depicts a sample shopping cart page that includes items in a virtual shopping cart and interactive user interface elements, consistent with the disclosed embodiment. Figure 1E depicts a sample order page consistent with the disclosed embodiment, including items from a virtual shopping cart, information about purchase and delivery, and interactive user interface elements. Figure 2 is a schematic diagram of an exemplary implementation center configured to utilize the disclosed computerized system, consistent with the disclosed embodiment. Figure 3 depicts an exemplary network of devices and systems for fraud detection and deduplication of user accounts consistent with the disclosed embodiments. Figure 4 depicts an exemplary table of fraud detection and user account deduplication databases consistent with the disclosed embodiments. Figure 5 depicts an exemplary table of a database for fraud detection and deduplication of user accounts consistent with the disclosed embodiments. Figure 6 illustrates a fraud detection and user account deduplication process consistent with the disclosed embodiments. Implementation

[0012] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numerals 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, components and steps shown in the drawings may be substituted, added, or modified, and the illustrative method described herein may be modified by replacing, reordering, removing, or adding steps to the disclosed method. Therefore, the following detailed description is not limited to the disclosed embodiments and examples. In fact, the proper scope of the invention is defined by the appended claims.

[0013] This disclosure relates to systems and methods configured for fraud detection and deduplication of user accounts. The disclosed embodiments enable the registration of new user accounts with low computational load. For example, a user (e.g., an internal user or an employee of an organization that owns, operates, or rents the disclosed system) can submit a request to initialize a database via an internal front-end system. The system can initialize the database by searching for multiple edits within the database. Each edit may include, for example, a user account identifier, at least one attribute, and a time entry. The user account identifier may be associated with a registered user account. Attributes may include, for example, a name, address, phone number, email address, Internet Protocol (IP) address, computer identifier, social security number, date of birth, or credit card information associated with the user. Time entries may include, for example, the time (e.g., month, date, year, hour, minute, second, etc.) when the associated user account was registered with the system. For each edit, the system can identify attributes and identify edit pairs that share said attributes. For each edit pair that shares attributes, the system can create an entry that can be stored in the database. Each entry stored in the database may contain, for example, a pair of user account identifiers, attributes shared by the pair of user account identifiers, and a pair of time entries associated with the user account. Multiple entries can be created for edit pairs that share more than one attribute. For example, if a pair of user accounts shares three attributes, three different entries can be created, one entry for each of the attributes.

[0014] In some embodiments, a user (e.g., a consumer) may submit a request to register a user account via an external front-end system, which may be implemented as a web server that receives user account registration requests, search requests, displays object pages, and requests payment information. The information entered by the user may include at least one attribute (e.g., a name, address, phone number, email address, IP address, computer identifier, social security number, date of birth, or credit card information associated with the user). The system may assign categories to the attributes. For example, if the attribute includes a phone number, email address, IP address, computer identifier, social security number, or credit card information, the system may assign a first category to the attribute. If the attribute includes a user name, user address, or date of birth, the system may assign a second category to the attribute.

[0015] The system can search an indexed database based on information received from the user. Because the database is indexed, the system can identify and retrieve entries containing attributes that match those received from the user. For example, the database can be initialized at a first time and searched at a second time after the first time. If the attributes of a retrieved entry from the database contain at least one attribute of a first category (e.g., phone number, email address, IP address, computer identifier, social security number, or credit card information), the system can determine that the request to register a user account is a duplicate and reject the request. If the attributes of a retrieved entry from the database contain attributes of a second category (e.g., username, user address, or date of birth) but not attributes of the first category, the system can determine that the request to register a user account is a credible request to register a new user account and approve the request.

[0016] The database can be initialized at the first instance and the indexed database can be searched at a second instance after the first instance. The database can be initialized only once, allowing subsequent requests for registered user accounts to be processed with low computational load. For example, the initialization of the database may require quadratic complexity, while processing each request after initialization may only require linear complexity, because approved requests received after initialization can be added to the database without re-indexing existing entries.

[0017] Referring to Figure 1A, a schematic block diagram 100 illustrating an exemplary embodiment of a computerized system including communications for realizing delivery, transport, and logistics operations is shown. As shown in Figure 1A, system 100 may include various systems, each of which may be interconnected via one or more networks. The systems may also be interconnected via direct connections (e.g., using cables). The described system includes 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 (described as being within a fulfillment center (FC) 200), third-party fulfillment systems 121A, 121B, and 121C, a fulfillment center authorization (FC Auth) system 123, and a labor management system (LMS) 125.

[0018] In some embodiments, the SAT system 101 may be implemented as a computer system for monitoring 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 actions, including initiating a new order, reshipping items in an undelivered order, canceling an undelivered order, initiating contact with the ordering customer, or similar actions. The SAT system 101 may also monitor other data, including outputs (such as the number of packages shipped during a specific time period) and inputs (such as the number of empty cardboard boxes received for shipment). The SAT system 101 may also act as a gateway between different devices in system 100, thereby enabling communication between devices such as external front-end system 103 and FO system 113 (e.g., using store and forward or other technologies).

[0019] 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 system 100. For example, in an embodiment where system 100 enables the presentation of the system to allow users to place orders for items, the external front-end system 103 may be implemented as a web server that receives search requests, presents item pages, and requests payment information. For example, the external front-end system 103 may be implemented as a computer or computer operating 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 custom web server software designed to receive and process requests from external devices (e.g., mobile device 102A or computer 102B), retrieve information from databases and other data stores based on such requests, and provide responses to received requests based on the retrieved information.

[0020] In some embodiments, the external front-end system 103 may include one or more of a web caching system, a database, a search system, or a payment system. In one embodiment, the external front-end system 103 may include one or more of these systems, while 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.

[0021] The set of illustrative 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 may receive information from systems or devices within system 100 for presentation and / or display. For example, the external front-end system 103 may host or provide one or more web pages, including a Search Results Page (SRP) (e.g., Figure 1B), a 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 mobile device 102A or computer 102B) may navigate to the external front-end system 103 and request a search by entering information into the search box. The external front-end system 103 may request information from one or more systems within system 100. For example, the external front-end system 103 may request information from the FO system 113 to satisfy a search request. External front-end system 103 may also (from FO system 113) request and receive the 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 the promised delivery date, for an order placed within a specific time period (e.g., before the end of the day (11:59 PM)). (PDD is further discussed below with respect to FO system 113.)

[0022] External front-end system 103 can prepare a Search Request Plan (SRP) based on information (e.g., Figure 1B). The SRP may contain 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, Product Delivery Date (PDD), weight, size, price quote, discount, or similar details for each product. External front-end system 103 may send the SRP to the requesting user's device (e.g., via a network).

[0023] The user device can then select a product displayed on the SRP, for example, by clicking or tapping the user interface or using another input device. The user device can make a request for information about the selected product and send it to the external front-end system 103. In response, the external front-end system 103 can request information related to the selected product. For example, the information may include additional information beyond what is presented for the product on each individual SRP. This may include, for example, shelf life, country of origin, weight, size, number of items in the package, disposal instructions, or other information about the product. The information may also include recommendations for similar products (based on, for example, massive data and / or machine learning analysis of customers who have purchased this product and at least one other product), answers to frequently asked questions, customer reviews, manufacturer information, images, or similar items.

[0024] External front-end system 103 can prepare an SDP (Single Detail Page) based on received product information (e.g., Figure 1C). The SDP may also include other interactive elements such as a "Buy Now" button, an "Add to Cart" button, a quantity bar, an image of the item, or similar. The SDP may further include a list of sellers offering the product. The list can be sorted based on the price offered by each seller, so that sellers offering the product at the lowest price are listed at the top. The list can also be sorted based on seller ranking, so that the highest-ranked seller is listed at the top. Seller ranking can be based on multiple factors, including, for example, a seller's past track record of fulfilling the promised PDD. External front-end system 103 can deliver the SDP to the requesting user's device (e.g., via a network).

[0025] The request allows the user device to receive an SDP listing product information. Upon receiving the SDP, the user device can then interact with it. For example, the request allows the user on the user device to click or otherwise interact with the "Add to Cart" button on the SDP. This adds the product to the shopping cart associated with the user. The user device can then transmit this request to add the product to the shopping cart to the external front-end system 103.

[0026] External front-end system 103 may generate a shopping cart page (e.g., Figure 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 an SRP, SDP, or other page. In some embodiments, the shopping cart page may list all products that the user has added to the cart, as well as information about the products in the cart (such as the quantity of each product, the price per item for each product, the price per product based on the associated quantity), information about the PDD (Product Items), delivery method, shipping costs, user interface elements for modifying products in the cart (e.g., deleting or modifying the quantity), options for ordering other products or setting up recurring delivery of products, options for setting up interest payments, user interface elements for proceeding to the purchase, or similar. The user on the user device may initiate a purchase of the products in the cart by clicking on or otherwise interacting with a user interface element (e.g., a button that says "Buy Now"). After doing so, the user device may transmit this purchase request to external front-end system 103.

[0027] External front-end system 103 may generate an order page (e.g., Figure 1E) in response to receiving a request to initiate a purchase. In some embodiments, the order page relists the items from the shopping cart and requests input for payment and shipping information. For example, the order page may include sections 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., delivery and / or picking speed / method), payment information (e.g., credit card, bank transfer, check, stored points), user interface elements requesting a cash receipt (e.g., for tax purposes), or similar. External front-end system 103 may send the order page to the user's device.

[0028] The user device can input information about the order page and interact with user interface elements that send information to the external front-end system 103 by clicking or otherwise. From there, the external front-end system 103 can send information to different systems in system 100 to enable the creation and processing of new orders with products in the shopping cart.

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

[0030] 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 rents system 100) to interact with one or more systems in system 100. For example, in embodiments where system 100 enables the presentation of the system to allow users to place orders for items, the internal front-end system 105 may be implemented as a web server that allows internal users to view diagnostic and statistical information about orders, modify item information, or review statistics related to orders. For example, the internal front-end system 105 may be implemented as a computer or computer operating 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 custom web server software designed to receive and process requests from systems or devices depicted in system 100 (and other devices not depicted), retrieve information from databases and other data stores based on such requests, and provide responses to received requests based on the retrieved information.

[0031] In some embodiments, the internal front-end system 105 may include one or more of a web caching system, a database, a search system, a payment system, an analytics 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, while 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.

[0032] In some embodiments, the transportation system 107 may be implemented as a computer system enabling communication between systems or devices in system 100 and mobile devices 107A to 107C. In some embodiments, the transportation system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, PDAs, or the like). For example, in some embodiments, mobile devices 107A to 107C may include devices operated by delivery workers. Delivery workers (who may be permanent employees, temporary employees, or shift workers) may use mobile devices 107A to 107C to deliver packages containing products ordered by users. For example, to deliver a package, the delivery worker may receive notifications on the mobile device instructing which package to deliver and where to deliver it. Upon arrival at the delivery location, the delivery worker may (e.g., in the back of a truck or in a crate of the package) locate the package, scan it using a mobile device, or otherwise extract information associated with an identifier on the package (e.g., a barcode, image, text string, RFID tag, or similar), and deliver the package (e.g., by leaving it at the front door, leaving it with a security guard, handing it to the recipient, or similar). In some embodiments, the delivery worker may use a mobile device to capture a photograph of the package and / or obtain a signature. The mobile device may send information to the transportation system 107, including information about the delivery, such as time, date, GPS location, photograph, identifier associated with the delivery worker, identifier associated with the mobile device, or similar. The transportation system 107 may store this information in a database (not depicted) for access by other systems in system 100. In some embodiments, the transportation system 107 may use this information to prepare tracking data and send the tracking data to other systems to indicate the location of a specific package.

[0033] In some embodiments, some users may use one type of mobile device (e.g., permanent workers may use a dedicated PDA with custom hardware such as barcode scanners, pens, and other devices), while other users may use other types of mobile devices (e.g., temporary workers or shift workers may utilize readily available mobile phones and / or smartphones).

[0034] In some embodiments, the transportation system 107 may associate a user with each device. For example, the transportation system 107 may store associations between users (represented by, for example, user identifiers, employee identifiers, or telephone numbers) and mobile devices (represented by, for example, International Mobile Equipment Identity (IMEI), International Mobile Subscription Identifier (IMSI), telephone number, Universal Unique Identifier (UUID), or Globally Unique Identifier (GUID)). The transportation system 107 may use these associations, combined with data received during delivery, to analyze data stored in a database, in particular to determine the worker's location, worker efficiency, or worker speed.

[0035] In some embodiments, the seller portal 109 may be implemented as a computer system that enables the seller or other external entity to communicate electronically with one or more systems in system 100. For example, the seller may use the 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 through system 100 using seller portal 109.

[0036] In some embodiments, the shipping and order tracking system 111 may be implemented as a computer system that receives, stores, and forwards information about the location of a package containing products ordered by a customer (e.g., a user of device 102A to device 102B). In some embodiments, the shipping and order tracking system 111 may request or store information from a web server (not depicted) operated by a shipping company that is authorized to deliver the package containing products ordered by the customer.

[0037] In some embodiments, the shipping and order tracking system 111 may request and store information from the systems depicted in system 100. For example, the shipping and order tracking system 111 may request information from transportation system 107. As discussed above, transportation system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, PDAs, or similar devices) associated with one or more users (e.g., delivery workers) or vehicles (e.g., delivery trucks). In some embodiments, the shipping and order tracking system 111 may also request information from warehouse management system (WMS) 119 to determine the location of individual products within a fulfillment center (e.g., fulfillment center 200). The shipping and order tracking system 111 may request data from one or more of transportation system 107 or WMS 119, process the data after the request, and present the data to devices (e.g., user devices 102A and 102B).

[0038] 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 stored or held. For example, some items may be stored in only one fulfillment center, while others 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., fresh produce or frozen products). The FO system 113 stores this information along with associated information (e.g., quantity, size, receipt date, expiration date, etc.).

[0039] The FO system 113 can also calculate the corresponding PDD (Promised Delivery Date) for each product. In some embodiments, the PDD can be based on one or more factors. For example, the FO system 113 can calculate the PDD of a product based on: past demand for the product (e.g., how many times the product has been ordered over a period of time), expected demand for the product (e.g., how many customers are predicted to order the product in the upcoming period of time), total network past demand indicating how many products have been ordered over a period of time, total network expected demand indicating how many products are expected to be ordered in the 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 similar.

[0040] In some embodiments, the FO system 113 may periodically (e.g., hourly) determine the Product Development Date (PDD) for each product and store it in a database for retrieval or transmission 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.

[0041] In some embodiments, the Facto Gateway (FMG) 115 may be implemented as a computer system that receives a request or response in one format or protocol from one or more systems in system 100 (such as FO system 113), converts it to another format or protocol, and forwards it in the converted format or protocol to other systems (such as WMS 119 or third-party fulfillment system 121A, third-party fulfillment system 121B or third-party fulfillment system 121C) and vice versa.

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

[0043] In some embodiments, the warehouse management system (WMS) 119 may be implemented as a computer system for monitoring workflows. 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 the use of one of these devices to scan a package. As discussed below with respect to fulfillment center 200 and FIG. 2, during the fulfillment process, package identifiers (e.g., barcode or RFID tag data) may be scanned or read by machines at specific stages (e.g., automatic or handheld barcode scanners, RFID readers, high-speed cameras, devices such as tablet computer 119A, mobile device / PDA 119B, computer 119C, or the like). WMS 119 can store each event indicating a scan or package identifier reading, along with the package identifier, time, date, location, user identifier, or other information, in a corresponding database (not depicted), and can provide this information to other systems (e.g., shipping and order tracking system 111).

[0044] In some embodiments, WMS 119 may store information that associates one or more devices (e.g., devices 107A to 107C or devices 119A to 119C) with one or more users (who are associated with system 100). For example, in some cases, a user (such as a part-time or full-time employee) may be associated with a mobile device because the user owns the mobile device (e.g., a smartphone). In other cases, a user may be associated with a mobile device because the user temporarily holds the mobile device (e.g., the user receives 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).

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

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

[0047] In some embodiments, the Fulfillment Center Auth system (FC Auth) 123 may be implemented as a computer system with various functionalities. For example, in some embodiments, FC Auth 123 may act as a single-sign-on (SSO) service for one or more other systems within system 100. For example, FC Auth 123 may enable a user to log in via internal front-end system 105, determine if the user has similar privileges to access resources at shipping and order tracking system 111, and enable the user to obtain those privileges without a second login 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 to 119C) and may actually move from task to task and from zone to zone within fulfillment center 200 throughout the day. FC Auth 123 may be configured so that such employees can indicate what task they are performing and which zone they are in at different times of the day.

[0048] In some embodiments, the Labor Management System (LMS) 125 may be implemented as a computer system that stores attendance and overtime information of employees (including full-time and part-time employees). For example, the LMS 125 may receive information from FC Auth 123, WMS 119, devices 119A to 119C, transportation system 107 and / or devices 107A to 107C.

[0049] The specific configuration depicted in Figure 1A is merely an example. For instance, although Figure 1A depicts an FC Auth system 123 connected to FO system 113, not all embodiments require this specific configuration. In fact, in some embodiments, the systems in system 100 may be interconnected via one or more public or private networks, including the Internet, intranets, wide-area networks (WANs), metropolitan-area networks (MANs), wireless networks compliant with IEEE 802.11a / b / g / n standards, leased lines, or the like. In some embodiments, one or more of the systems in system 100 may be implemented as one or more virtual servers at a data center, server cluster, or the like.

[0050] Figure 2 depicts a fulfillment center 200. A fulfillment center 200 is an instance of a physical location storing items for delivery to a customer upon ordering. A fulfillment center (FC) 200 may be divided into multiple zones, each of which is depicted in Figure 2. In some embodiments, these "zones" may be considered as virtual divisions between different stages of the processes of receiving, storing, retrieving, and delivering items. Therefore, although "zones" are depicted in Figure 2, other zone divisions are possible, and in some embodiments, the zones in Figure 2 may be omitted, copied, or modified.

[0051] The entry area 203 represents the area where a seller wishing to sell products from the system 100 of Figure 1A receives items from FC 200. For example, the seller may use truck 201 to deliver items 202A and 202B. Item 202A may represent a single item large enough to occupy its own transport pallet, while item 202B may represent a collection of items stacked together on the same pallet to save space.

[0052] Workers will receive items in inbound area 203 and may use a computer system (not depicted) to check for damage and correctness of the items as needed. For example, workers may use the computer system to compare the quantities of items 202A and 202B with the ordered quantities. If the quantities do not match, workers may reject one or more of items 202A or 202B. If the quantities do match, workers may move those items to buffer 205 (using, for example, a trolley, handcart, forklift, or manually). Buffer 205 may be a temporary storage area for items that are not currently (e.g., due to a sufficiently high number of items in the picking area to meet predicted demand) not in the picking area. In some embodiments, forklift 206 operates to move items around buffer 205 and between inbound area 203 and unloading area 207. If (for example, due to anticipated demand) item 202A or item 202B is needed in the picking area, the forklift can move item 202A or item 202B to the unloading area 207.

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

[0054] Picking area 209 may be the area of ​​FC 200 where items 208 are stored on storage unit 210. In some embodiments, storage unit 210 may include one or more of physical shelves, bookshelves, boxes, handbags, refrigerators, freezers, cold storage areas, or the like. In some embodiments, picking area 209 may be organized into multiple floors. In some embodiments, workers or machines may move items to picking area 209 in various ways, including, for example, forklifts, elevators, conveyors, trolleys, handcarts, automated robots or devices, or manually. For example, a picker may place items 202A and 202B on a handcart or trolley in unloading area 207 and move items 202A and 202B to picking area 209.

[0055] Pickers can receive instructions to place (or "stack") items at specific points in picking area 209 (such as specific spaces on storage unit 210). For example, a picker can use a mobile device (e.g., device 119B) to scan item 202A. The device can, for example, use a system indicating aisles, shelves, and locations to instruct the picker where to stack item 202A. The device can then prompt the picker to scan a barcode at the location before stacking item 202A there. The device can transmit data (e.g., via a wireless network) to a computer system such as WMS 119 in Figure 1A, thereby instructing the user of device 119B to stack item 202A at the location.

[0056] Once a user places an order, the picker receives instructions on device 119B to retrieve one or more items 208 from storage unit 210. The picker can retrieve item 208, scan the barcode on item 208, and place item 208 on transport mechanism 214. Although transport mechanism 214 is referred to as a slider, in some embodiments, transport mechanism may be implemented as one or more of a conveyor belt, elevator, trolley, forklift, handcart, trolley, or the like. Item 208 can then arrive at packaging area 211.

[0057] Packaging area 211 is an area where the self-picking area 209 of FC 200 receives items and packages them into boxes or bags for final delivery to the customer. In packaging area 211, a worker designated to receive items ("merging worker") receives item 208 from self-picking area 209 and determines which order item 208 corresponds to. For example, the merging worker can use a device such as computer 119C to scan a barcode on item 208. Computer 119C can visually indicate which order item 208 is associated with. This may include, for example, space or "cell" on wall 216 corresponding to the order. Once the order is completed (e.g., since the cell contains all the items for the order), the merging worker can instruct the packaging worker (or "packer") to complete the order. The packer can retrieve the item from the cell and place it in a box or bag for delivery. Packers can then send boxes or packages to hub zone 213, for example, via forklifts, trolleys, wheelbarrows, handcarts, conveyors, manually or otherwise.

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

[0059] In some embodiments, camp area 215 may include one or more buildings, one or more physical spaces, or one or more zones, wherein packages are received from hub area 213 for sorting into routes and / or subroutines. In some embodiments, camp area 215 is physically separate from FC 200, while in other embodiments, camp area 215 may form part of FC 200.

[0060] Workers and / or machines in camp area 215 may determine which route and / or sub-route 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, the method of delivery, the cost of delivering package 220, the PDD associated with the items in package 220, or similar factors. In some embodiments, workers or machines may (e.g., using one of devices 119A to 119C) scan packages to determine their final destination. Once package 220 is assigned to a specific route and / or sub-route, workers and / or machines can move the package 220 to be delivered. In illustrative Figure 2, camp area 215 includes truck 222, vehicle 226, and delivery workers 224A and 224B. In some embodiments, truck 222 may be driven by delivery worker 224A, who is a full-time employee delivering packages for FC 200, and truck 222 is owned, leased, or operated by the same company that owns, leases, or operates FC 200. In some embodiments, vehicle 226 may be driven by delivery worker 224B, who is a "flexible" or temporary worker making deliveries on an as-needed basis (e.g., seasonally). Vehicle 226 may be owned, leased, or operated by delivery worker 224B.

[0061] Referring to Figure 3, an exemplary network of devices and systems for fraud detection and deduplication of user accounts is illustrated. As shown in Figure 3, system 300 may include an edge system 330 and a logging system 340, each of which can communicate via network 310 with user device 320 associated with user 320A or user device 322 associated with user 322A. In some embodiments, edge system 330 and logging system 340 may communicate with other components of system 300 via a direct connection (e.g., using a cable). In some other embodiments, system 300 may be part of system 100 of Figure 1A and may communicate with other components of system 100 via network 310 or via a direct connection (e.g., using a cable). Edge system 330 and logging system 340 may each include a single computer, or may each be configured as a distributed computer system comprising multiple computers that interact to perform one or more of the processes and functionalities associated with the disclosed example.

[0062] As shown in Figure 3, the edge system 330 may include a processor 332, memory 334, and a database 336. The logging system 340 may include a processor 342, memory 344, and a database 346. Processors 332 and 342 may be one or more known processing devices, such as microprocessors from the Pentium™ series manufactured by Intel™ or the Turion™ series manufactured by AMD™. Processors 332 and 342 may constitute a single-core processor or a multi-core processor that executes parallel processes simultaneously. For example, processors 332 and 342 may use logical processors to execute and control multiple processes simultaneously. Processors 332 and 342 may implement virtual machine technology or other known technologies to provide the ability to execute, control, run, manipulate, and store multiple software processes, applications, programs, etc. In another example, processors 332 and 342 may include a multi-core processor configuration configured to provide parallel processing capabilities, allowing edge system 330 and log system 340 to execute multiple processes simultaneously. Those skilled in the art will understand that other types of processor configurations providing the capabilities disclosed herein can be implemented.

[0063] Memory 334 and memory 344 can store one or more operating systems that perform known operating system functions when executed by processor 332 and processor 342, respectively. By way of example, the operating system can include Microsoft Windows, Unix, Linux, Android, Mac OS, iOS, or other types of operating systems. Therefore, embodiments of the disclosed invention can be operated and run using a computer system running any type of operating system. Memory 334 and memory 344 can be volatile or non-volatile, magnetic, semiconductor, magnetic tape, optical, removable, non-removable, or other types of storage devices or tangible computer-readable media.

[0064] Databases 336 and 346 may contain, for example, Oracle™ databases, Sybase™ databases, or other related or unrelated databases, such as Hadoop™ sequential archives, HBase™, or Cassandra™. Databases 336 and 346 may contain computing components (e.g., a database management system, a database server, etc.) configured to receive and process requests for data stored in the database's memory and to provide data from the database. Databases 336 and 346 may contain NoSQL databases, such as HBase, MongoDB™, or Cassandra™. Alternatively, databases 336 and 346 may contain related databases such as Oracle, MySQL, and Microsoft SQL Server. In some embodiments, databases 336 and 346 may be in the form of a server, a general-purpose computer, a mainframe computer, or any combination of such components.

[0065] Databases 336 and 346 can store data that can be used by processors 332 and 342, respectively, to perform methods and processes associated with the disclosed examples. Databases 336 and 346 can be located in edge system 330 and log system 340, respectively, as shown in FIG3, or alternatively, they can be located in external storage devices outside edge system 330 and log system 340. The data stored in 336 and 346 can contain any suitable data associated with users (e.g., each user's name, address, telephone number, email address, IP address, computer identifier, social security number, date of birth, credit card information, etc.).

[0066] User devices 320 and 322 may be tablet computers, mobile devices, computers, or the like. User devices 320 and 322 may include a display. For example, the display may include a liquid crystal display (LCD), a light-emitting diode screen (LED), an organic light-emitting diode screen (OLED), a touch screen, and other known display devices. The display may show the user various information. For example, it may display a modified webpage containing modified user interface elements, said modified user interface elements including options to submit a request to register a new user account. User device 320 may include one or more input / output (I / O) devices. The I / O devices may include one or more devices that allow user devices 320 and 322 to send and receive information from user 320A and user 322A or another device. The I / O device may include various input / output devices: camera, microphone, keyboard, mouse-like device, gesture sensor, motion sensor, physical button, verbal input, etc. The I / O device may also include one or more communication modules (not shown) for sending and receiving information from editing system 330 or logging system 340 by establishing, for example, wired or wireless connectivity between user device 320 and user device 322 and network 310.

[0067] In some embodiments, user 320A or user 322A may be an internal user (e.g., an employee of an organization that owns, operates, or rents system 100 or system 300). The internal front-end system 105 may be implemented as a computer system enabling user 320A or user 322A to interact with system 300. For example, in embodiments where system 100 or system 300 enables the presentation of the system to allow users to place orders for items, the internal front-end system 105 may be implemented as a web server enabling user 320A or user 322A to view diagnostic and statistical information about a user account, modify a user account, or review statistics related to a user account. In some embodiments, the internal front-end system 105 may run custom web server software designed to receive and process requests from the systems or devices depicted in system 100 or system 300, retrieve information from databases (e.g., database 336 or database 346) and other data stores based on such requests, and provide responses to received requests based on the retrieved information.

[0068] For example, user 320A or user 322A may submit a request to initialize database 336 or database 346 via internal front-end system 105. Edge system 330 and log system 340 may receive the request to initialize database 336 or database 346 respectively via internal front-end system 105 over network 310. Edge system 330 may initialize database 336 by searching for multiple edits in database 336. Each edit may contain a user account identifier, at least one attribute, and a time entry. The user account identifier may be associated with a registered user account. Attributes may include, for example, a name, address, phone number, email address, IP address, computer identifier, social security number, date of birth, or credit card information associated with the user. The time entry may contain the time (e.g., month, date, year, hour, minute, second, etc.) when the associated user account was registered to system 100 or system 300. For each edit, edge system 330 may identify attributes and identify edit pairs that share said attributes. For each edit pair sharing a common attribute, edge system 330 can create an entry that can be stored in database 336. Each entry stored in database 336 can include a pair of user account identifiers, attributes shared by the pair of user account identifiers, and a pair of time entries associated with the user account. Multiple entries can be created for edit pairs sharing more than one attribute. For example, if a pair of user accounts shares three attributes, three different entries can be created, one entry for each of the attributes.

[0069] In some embodiments, creating each entry may involve the edge system 330 creating a table of entries stored in database 336 and indexing the table. For example, each column in the table may correspond to an entry in database 336. Each entry may contain an edit pair, wherein each edit contains a user account identifier, attributes, and a time entry. The first row of the table may contain a first edit of the entry, and the second row of the table may contain a second edit of the entry.

[0070] In some embodiments, the logging system 340 may initialize database 346 by searching for multiple edits in database 346. Databases 336 and 346 may be linked so that the multiple edits in databases 336 and 346 are identical. In some embodiments, databases 336 and 346 may be independent but contain the same multiple edits. Each edit may contain a user account identifier, at least one attribute, and a time entry. The user account identifier may be associated with a registered user account. Attributes may include, for example, a name, address, phone number, email address, IP address, computer identifier, social security number, date of birth, or credit card information associated with the user. The time entry may contain the time (e.g., month, date, year, hour, minute, second, etc.) when the associated user account was registered to system 100 or system 300. For each edit, the logging system 340 may create an entry that can be stored in database 346. Each entry stored in database 346 may contain a user account identifier associated with the user account, attributes, and a time entry.

[0071] In some embodiments, creating each entry may involve the log system 340 creating a table of entries stored in a database 346 and indexing the table. For example, each column of the table may correspond to an entry in the database 346. Each entry may contain edits, wherein each edit contains a user account identifier, attributes, and a time entry.

[0072] In some embodiments, user 320A or user 322A may be a consumer. User 320A or user 322A may submit a request to register a user account via an external front-end system 103, which may be implemented as a web server that receives requests to register user accounts, searches, presents object pages, and requests payment information. External front-end system 103 may run custom web server software designed to receive and process requests from external devices (e.g., user device 320 or user device 322), retrieve information from databases (e.g., database 336 or database 346) and other databases based on such requests, and provide responses to received requests based on the retrieved information. For example, user 320A or user 322A may use user device 320 or user device 322 to navigate to external front-end system 103 and submit a request to register a user account by entering information into a submit box. External front-end system 103 may request information from one or more of systems 100 or 300. For example, the external front-end system 103 can request information from the edge system 330 or the logging system 340. The edge system 330 or the logging system 340 can receive requests for registered user accounts via the external front-end system 103 through the network 310.

[0073] In some embodiments, the information entered by user 320A or user 322A may include at least one attribute (e.g., a name, address, phone number, email address, IP address, computer identifier, social security number, date of birth, or credit card information associated with the user). System 300 may assign categories to the attributes. For example, if the attribute includes a phone number, email address, IP address, computer identifier, social security number, or credit card information, system 300 may assign a first category to the attribute. If the attribute includes a user name, user address, or date of birth, system 300 may assign a second category to the attribute.

[0074] Edge system 330 or log system 340 can search indexed database 336 or indexed database 346 based on information received from user 320A or user 322A. Since databases 336 and 346 are indexed, system 330 or system 340 can identify and retrieve entries containing attributes matching those received from user 320A or user 322A. For example, databases 336 and 346 can be initialized at a first time, and indexed databases 336 and 346 can be searched at a second time after the first time.

[0075] If the attributes of a retrieved entry from database 336 or database 346 contain at least one attribute of the first category (e.g., phone number, email address, IP address, computer identifier, social security number, or credit card information), system 300 may determine that the request to register a user account is a duplicate user account and reject the request. If the attributes of a retrieved entry from database 336 or database 346 contain attributes of the second category (e.g., username, user address, or date of birth) but do not contain attributes of the first category, system 300 may determine that the request to register a user account is a credible request to register a new user account and approve the request. System 300 may send a notification indicating the registration status of the requested user account to user 320A or user 322A.

[0076] The edge system 330 or the log system 340 can record the time when user 320A or user 322A submits a request and the time when the request is approved and a new user account is registered. The edge system 330 or the log system 340 can assign a user account identifier to user 320A or user 322A.

[0077] Systems 330 and 340 can add new edits to databases 336 and 346, respectively. These new edits include a user account identifier for an approved registration request, at least one attribute, and a time entry indicating when the user account was registered with system 100 or system 300. Edge system 330 can create new entries containing edit pairs by adding new columns to tables in database 336 and indexing the new columns. Each new entry may contain the new edit and the edits of the retrieved entry. Each new entry may contain a pair of user account identifiers, attributes shared by the pair of user account identifiers, and a pair of time entries associated with the user account.

[0078] The logging system 340 can create new entries containing new edits by adding new columns to the tables of the database 346 and indexing the new columns. New entries may include a new user account identifier, at least one attribute, and a time entry.

[0079] Databases 336 and 346 can be initialized at the first time, and the indexed databases 336 and 346 can be searched at a second time after the first time. Databases 336 and 346 can be initialized only once, allowing subsequent requests for registered user accounts to be processed with low computational load. For example, initializing databases 336 and 346 may require quadratic complexity, while processing each request after initialization may only require linear complexity. This is because approved requests received after initialization can be added to the tables of databases 336 and 346 without re-indexing existing entries in the databases.

[0080] In some embodiments, user 320A or user 322A may be a consumer using user device 320 or user device 322 to select a product from the SRP, for example, by clicking or tapping a user interface, or using another input device to select a product presented on the SRP. User device 320 or user device 322 may make a request for information about the selected product and send it to external front-end system 103. In response, external front-end system 103 may send user account information associated with user 320A or user 322A to system 300 and request information from system 300 related to the user account of user 320A or user 322A. Edge system 330 or logging system 340 may receive user account information and identify at least one attribute contained in the user account information. Edge system 330 or logging system 340 may search indexed database 336 or indexed database 346 to retrieve entries containing attributes that match the received attributes.

[0081] If the attributes of a retrieved entry from database 336 or database 346 include at least one attribute of the first category (e.g., phone number, email address, IP address, computer identifier, social security number, or credit card information), system 300 may determine that the user account interacting with SRP is a duplicate user account, remove the entry associated with the user account from databases 336 and 346, and prohibit users associated with the removed user account. For example, system 300 may prohibit users associated with the removed user account by blocking requests from the IP address associated with the user. If the attributes of a retrieved entry from database 336 or database 346 include attributes of the second category (e.g., username, user address, or date of birth) but do not include attributes of the first category, system 300 may determine that the user account interacting with SRP is a trusted user account and allow the user to continue interacting with SRP.

[0082] In some embodiments, the system 300 may determine whether a user account interacting with the SDP or any other user interface element (e.g., a button that says "Buy Now", a webpage associated with product purchase, etc.) is a trusted user account in a process similar to that described above, so as to remove duplicate registered user accounts or remove and prohibit fraudulent user accounts with low computational load.

[0083] Referring to Figure 4, an exemplary table of a database for fraud detection and deduplication of user accounts is illustrated. As shown in Figure 4, database 336 may contain table 400. Edge system 330 may initialize database 336 by creating columns of entries 410, 411, 412, and 413. Each entry may contain a pair of rows containing edits 401 and 402. Each edit may be associated with different users. For example, entry 410 may contain user A and user B, entry 411 may contain user B and user A, and entry 412 may contain user A and user C. Each edit may contain a user account identifier "u", an attribute "a" shared by the pair of user account identifiers, and a time entry "t" associated with the user account. Multiple entries may be created for edit pairs that share more than one attribute. In some embodiments, entries 410 and 411 may contain the same user A and user B and their associated user account identifiers, attributes, and time entries. Entry 410 may include user A in edit 401 and user B in edit 402, while entry 411 may include user B in edit 401 and user A in edit 402. This organization of entries allows edge system 330 to efficiently retrieve edits (e.g., edit 402) associated with a user (e.g., user A) by searching edits in a single row (e.g., edit 401). For example, edge system 330 may search edit 401 to determine whether user B and user C are associated with user A or whether user A is associated with user B.

[0084] In some embodiments, database 336 may be initialized at a first time t = 1, and new entries may be added to database 336 at a second time t = 2. For example, at time t = 2, edge system 330 may search the indexed database 336 based on information received from user 320A or user 322A. Since database 336 is indexed, system 330 may identify and retrieve whether at least one of entries 410, 411, 412, or 413 contains an attribute that matches the attribute received from user 320A or user 322A.

[0085] System 330 can add new edits to database 336, the new edits including a user account identifier for an approved registration request, at least one attribute, and a time entry for when the approved user account was registered to system 100 or system 300. Edge system 330 can create new entries containing edit pairs by adding new columns to tables in database 336 and indexing the new columns. For example, new entries 414 and 415 can be added to table 400 at t = 2. Each new entry can contain the new edit and the edits of the retrieved entry. For example, user D can be associated with a newly registered user account, while user B can be associated with a retrieved entry already indexed at t = 1. Each new entry can contain a pair of user account identifiers, attributes shared by the pair of user account identifiers, and a pair of time entries associated with the user account.

[0086] Database 336 can be initialized at t = 1, and the indexed database 336 can be searched at t = 2 after t = 1. Database 336 can be initialized only once, allowing subsequent requests for registered user accounts to be processed with low computational load. For example, initializing database 336 at t = 1 might require quadratic complexity, while processing each request after initialization might only require linear complexity at t = 2, because approved requests received after initialization can be added to table 400 without re-indexing existing entries in the database.

[0087] Referring to Figure 5, an exemplary table of a database for fraud detection and deduplication of user accounts is shown. As shown in Figure 5, database 346 may contain table 500. Log system 340 may initialize database 346 by creating columns of entries 510, 511, 512, and 513. Each entry may contain a row containing edit 501. Each edit may be associated with a different user. For example, entry 510 may contain user A, entry 511 may contain user B, and entry 512 may contain user C. Each edit may contain a user account identifier "u", an attribute "a" shared by the pair of user account identifiers, and a time entry "t" associated with the user account.

[0088] In some embodiments, database 346 may be initialized at a first time t = 1, and new entries may be added to database 346 at a second time t = 2. For example, at time t = 2, log system 340 may search the indexed database 346 based on information received from user 320A or user 322A. Since database 346 is indexed, system 340 may identify and retrieve whether at least one of entries 510, 511, 512, or 513 contains an attribute that matches the attribute received from user 320A or user 322A.

[0089] System 340 can add new edits to database 346, the new edits including a user account identifier for an approved registration request, at least one attribute, and a time entry for when the approved user account registered with system 100 or system 300. Log system 340 can create new entries by adding new columns to tables in database 346 and indexing the new columns. For example, new entry 514 can be added to table 500 at t = 2. Each new entry can contain new edits. For example, user D can be associated with a newly registered user account. Each new entry can contain a user account identifier, attributes, and a time entry associated with the user account.

[0090] Database 346 can be initialized at t = 1, and the indexed database 346 can be searched at t = 2 after t = 1. Database 346 can be initialized only once, allowing subsequent requests for registered user accounts to be processed with low computational load. For example, initializing database 346 at t = 1 might require quadratic complexity, while processing each request after initialization might only require linear complexity at t = 2, because approved requests received after initialization can be added to table 500 without re-indexing existing entries in the database.

[0091] Referring to Figure 6, the process of fraud detection and deduplication of user accounts is illustrated. While in some embodiments, the edge system 330 may perform some of the steps described herein, other embodiments are possible. For example, any of the systems and components described and illustrated herein (e.g., system 100, log system 340, etc.) may perform the steps described in this disclosure.

[0092] In step 601, edge system 330 may receive a request to register a third user account from user 320A or user 322A via network 310 through external front-end system 103. User 320A or user 322A may submit the request to register a third user account through external front-end system 103, which may be implemented as a web server that receives user account registration requests, search requests, displays object pages, and requests payment information. External front-end system 103 may run customized web server software designed to receive and process requests from external devices (e.g., user device 320 or user device 322). For example, user 320A or user 322A may use user device 320 or user device 322 to navigate to external front-end system 103 and submit the request to register a user account by entering information into a submit box. Database 336 may contain multiple first entries, wherein each first entry includes a pair of first user accounts and second user accounts, at least one first attribute shared between the pair of first user accounts and second user accounts, and a first time entry and a second time entry.

[0093] In step 603, the edge system 330 may receive user information associated with the requested third user account, wherein the user information includes a second attribute. The second attribute may include a name, address, phone number, email address, IP address, computer identifier, social security number, date of birth, or credit card information associated with the user. In some embodiments, the system 300 may specify a first category for the attribute if the attribute includes a phone number, email address, IP address, computer identifier, social security number, or credit card information, or specify a second category for the attribute if the attribute includes a user name, user address, or date of birth.

[0094] In step 605, the edge system 330 may modify the first data store at the third time entry by: searching multiple first entries in the first data store; comparing a second attribute with the first attribute of each first entry; determining that at least one first entry includes a first attribute consistent with the second attribute; adding a second entry and a third entry, wherein the second entry includes a first user account and a third user account, a second attribute, and a first time entry and a third time entry, and the third entry includes a second user account and a third user account, a second attribute, and a second time entry and a third time entry. The edge system 330 may search the indexed database 336 based on information received from user 320A or user 322A. Since the database 336 is indexed, the system 330 may identify and retrieve entries containing attributes that match the attributes received from user 320A or user 322A. For example, the database 336 may be initialized at the first time, and the indexed database 336 may be searched at a second time after the first time. If the attributes of the retrieved entry from database 336 include attributes of the second category (e.g., username, user address, or date of birth) but do not include attributes of the first category (e.g., phone number, email address, IP address, computer identifier, social security number, or credit card information), then system 300 may determine that the request to register a user account is a credible request to register a new user account and approve the request.

[0095] System 330 can add new edits to database 336, the new edits including a user account identifier for an approved registration request, at least one attribute, and a time entry for when the user account with the approved registration request was registered to system 100 or system 300. Edge system 330 can create new entries containing edit pairs by adding new columns to tables in database 336 and indexing the new columns. Each new entry may contain the new edit and the edits of the retrieved entry. Each new entry may contain a pair of user account identifiers, attributes shared by the pair of user account identifiers, and a pair of time entries associated with the user account.

[0096] In step 607, system 330 may assign a registration status to the third user account based on the second attribute. For example, if the attributes of a retrieved entry from database 336 include attributes of the second category (e.g., username, user address, or date of birth) but do not include attributes of the first category (e.g., phone number, email address, IP address, computer identifier, social security number, or credit card information), system 300 may determine that the request to register a user account is a credible request to register a new user account and approve the request. If the attributes of a retrieved entry from database 336 or database 346 include at least one attribute of the first category, system 300 may determine that the user account interacting with SRP is a duplicate user account, remove the entry associated with the user account from databases 336 and 346, and prohibit users associated with the removed user account. For example, system 300 may prohibit users associated with the removed user account by blocking requests from IP addresses associated with the user.

[0097] In step 609, system 330 may send a notification indicating the registration status of a third user account to the user.

[0098] Although this disclosure has been illustrated and described with reference to specific embodiments thereof, it should be understood that this disclosure can be practiced in other settings 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 skilled in the art from consideration of this specification and practice of the disclosed embodiments. Furthermore, although the disclosed embodiments are described as being stored in memory, those skilled in the art will understand that such embodiments can also be stored on other types of computer-readable media, such as secondary storage devices, like hard drives or CD-ROMs, or other forms of RAM or ROM, USB media, DVDs, Blu-rays, or other optical disc drive media.

[0099] Computer programs based on the written descriptions and disclosed methods are within the skill level of experienced developers. Various programs or modules can be created using any of the techniques known to a person of ordinary skill in the art, or can be designed in conjunction with existing software. For example, program segments or modules can be designed using the .NET Framework, the .NET Compact Framework (and related languages ​​such as Visual Basic, C, etc.), Java, C++, Objective-C, HTML, HTML / AJAX combinations, XML, or HTML containing Java applets.

[0100] Furthermore, although illustrative embodiments have been described herein, those skilled in the art will understand the scope of any and all embodiments with equivalent elements, modifications, omissions, (e.g., variations in the various embodiments) combinations, adaptations, and / or alterations based on this disclosure. Limitations in the claims should be interpreted broadly based on the language used in the claims and are not limited to the examples described herein or during the examination of this application. Examples should be considered non-exclusive. Additionally, the steps of the disclosed methods may be modified in any way by reordering the steps and / or inserting or deleting steps. Therefore, it is intended that this specification and examples be considered illustrative only, wherein the true scope and spirit are indicated by the full scope of the following claims and their equivalents. [] []

[0101] 100, 300: System 101: Delivery Authorization Technology System 102A, 107A, 107B, 107C, 119A, 119B, 119C: Mobile Devices 102B: Computer 103: External Front-End System 105: Internal Front-End System 107: Transportation System 109: Seller Portal 111: Shipping and Order Tracking System 113: Implementing the optimal system 115: Execute communication reporting channel 117: Supply Chain Management System 119: Warehouse Management System 121A, 121B, 121C: Third-Party Execution Systems 123: Fulfillment Center Authorization System 125: Labor Management System 200: Fulfillment Center 201, 222: Trucks 202A, 202B, 208: Objects 203: Entrance Area 205: Buffer 206: Forklift 207: Unloading Area 209: Picking Area 210: Storage unit 211: Packaging Area 213: Hub Area 214: Transportation agencies 215: Camp Area 216: Wall 218, 220: Packages 224A, 224B: Delivery workers 226: Cars 310: Internet 320, 322: User equipment 320A, 322A: Users 330: Edge System 332, 342: Processors 334, 344: Memory 336, 346: Database 340: Log System 400, 500: Table 401, 402, 501: Edit 410, 411, 412, 413, 414, 415, 510, 511, 512, 513, 514: Entries 601, 603, 605, 607, 609: Steps

Claims

1. A computer implementation method for fraud detection and deduplication of user accounts, comprising: A first data store includes a plurality of first entries, each first entry including a pair of first user accounts and second user accounts, at least one first attribute shared by the pair of first user accounts and second user accounts, and a first time entry and a second time entry; a processor receives a request from a user to register a third user account; at the third time entry, the first data store is modified by the following operations: the processor compares a second attribute associated with the third user account with the first attribute of each first entry; the processor determines that the at least one first attribute is consistent with the second attribute; the processor adds a second entry and a third entry, wherein the second entry includes the first user account and the third user account, the second attribute, and the first time entry and the third time entry; and the third entry includes the second user account and the third user account, the second attribute, the second time entry and the third time entry; the processor determines that the third user account is a duplicate user account based on the second attribute; the processor disables the third user account; wherein the first data store is initialized before the time of the third time entry; and the processor sends a notification indicating that the registration status of the third user account is disabled to the user. This results in the computational load of modifying the first data repository at the third time entry being lower than the computational load of initializing the first data repository.

2. The computer implementation method as described in claim 1, wherein the first attribute and the second attribute include at least one of telephone number, email address, username, user address, Internet Protocol address, computer identifier, social security number, or date of birth.

3. The computer implementation method as described in claim 1, wherein the processor modifies the first data repository to include an index table and each column of the table includes one of the plurality of first entries.

4. The computer-implemented method as described in claim 1, further comprising: The processor receives a second request from the second user to register a fourth user account; At the fourth time entry, the first data store is modified by the following operations: the processor compares the third attribute associated with the fourth user account with the first attribute of each first entry and the second attribute of the second entry and the third entry; and if the third attribute matches the second attribute, the processor adds a combination including the first user account, the second user account, the third user account, the fourth user account, the third attribute, the first time entry, the second time entry, the third time entry, and the fourth time entry to the first data store; The processor also sends a notification indicating the registration status of the fourth user account to the second user.

5. The computer implementation method as described in claim 1 further includes a second data store containing a plurality of fourth entries, wherein each fourth entry includes a fourth user account, at least one third attribute, and a fourth time entry.

6. The computer implementation method as described in claim 5, wherein after initializing the first data store: the plurality of fourth entries are searched in the second data store; each third attribute is compared; and pairs of fourth user accounts having consistent third attributes are identified.

7. The computer implementation method as described in claim 6, wherein each of the plurality of first entries includes an identified pair of fourth user accounts.

8. The computer-implemented method as described in claim 6, wherein at the third time entry, only the second attribute is compared by the processor with the first attribute of each first entry.

9. The computer-implemented method as described in claim 6, further comprising: The processor modifies the second data store by means of an index table, wherein the table includes multiple columns corresponding to the plurality of fourth entries; The processor modifies the second data repository by adding a first column that includes the third user account, the second attribute, and the third time entry.

10. The computer implementation method as described in claim 1, wherein the registration status is specified to the third user account based on the second attribute.

11. A computer system for fraud detection and deduplication of user accounts, comprising: Memory stores instructions; And at least one processor, configured to execute the instructions to perform the operations of request items 1-10.

Images