Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This Final action is in reply to the arguments/amendments filed 7/29/2025.
Claims 1, 5 and 10 have been amended.
Claims 12-20 were previously withdrawn.
Claims 1-11 are pending.
Response to Amendments/Arguments
With respect to the 35USC 112 rejection and claims 1-11, applicant’s amendments to independent claim 1 overcome the rejection; therefore, it has been withdrawn.
Applicant’s arguments regarding the 35USC101 rejection have been considered but are unpersuasive. Applicant argues that the claim recites a specific technological solution for real-time cross-entity transaction and return data integration that improves computer network technology and integrates any judicial exception into a practical application. Applicant subsequently states that, “The Examiner’s analysis fails to properly consider the claim as a whole and incorrectly focuses on individual limitations in isolation”. Applicant then avers, “The Examiner’s comparison to mental processes ignores that the claim requires specific computer network functionality that improves existing technology and that the claim is analogous to eligible claims in Enfish (improving computer technology), McRO (specific technological solution), and BASCOM (unconventional arrangement of known elements). Applicant’s arguments have been re-considered but are unpersuasive. Applicant’s specification evidences that the focus of applicant’s invention is organizing and managing the activities, interactions and relations of entities (retailers, supplier, manufacturer, etc., retail staff operated device/terminal) and consumer by discussing the process by which item return data associated with an item from a retailer is received during a return transaction, an entity other than the retailer is identified from the return data, and an item return workflow is identified an processed causing select data (from the item return data) to be delivered to the entity (see ¶8, ¶14). As discussed in the Final action below, independent claim 1 is directed to the abstract idea for receiving item return data, identifying an entity, obtaining and processing item return workflow, determining that the current item return transaction was purchased at a discounted price, providing the discounted price to the transaction terminal; delivering and adjusting select data to an inventory system of the entity in a computing environment. Applicant’s invention pertains to the following groupings of abstract ideas: (i) mental processes (concepts performed in the human mind (including an observation, evaluation, judgment, opinion) or by a human being with a pen and paper); (ii) commercial or legal interactions including agreements as contracts, legal obligations, advertising, marketing or sales activities or behaviors; business relations; and (iii) managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). The specification only generically teaches a system/platform providing a processing environment using generic computing components. The ‘transaction terminal’, ‘inventory system’, application programming interface (API) [claim 1], ‘data store’ [claim 2]; ‘interfaces’ [claim 4]; ‘schedule/delivery system’[claim10] presented in the claim limitations are general-purpose processing elements, both individually and in combination applied at a high level of generality to implement the abstract ideas– see applicant’s disclosure at least ¶14, ¶37, ¶42. With the exception of generic computing components, the limitations are merely utilizing computing components as a tool to perform the process.
As discussed in the Non-Final action (4/29/25), a human being can…receive item return data …identify an entity other than the retailer …obtain an item return workflow associated with the entity, process the item return workflow, determine item return transaction data provided during the item return transaction and adjust an inventory system of an entity. There is nothing in the claims themselves that foreclose them from being practically performed by a human being with a pen and paper. Hence, the claim limitations are directed to the mental processes grouping of abstract ideas. The claims are also directed to the management of personal behavior, relationships, or interactions between people (including social activities, teaching, and following rules or instructions) (i.e. interactions of retailers (entities, suppliers, manufacturer, retail staff operated terminal/device) and consumer with a terminal/device (and/or consumer device) according to rules or instructions to satisfy entity (retailer) item return workflow and adjust entity inventory system) to facilitate commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) for returning an item during a return transaction within certain methods of organizing human activities grouping. The claim limitations merely tie the abstract idea to a technology and/or a general application of additional elements to process the item return transaction and adjust the inventory system of an entity. There is no specific technological improvement and the claimed invention is generally managing inventory of a business, and/or inter-entity relations and compliance of item workflow rules (certain methods of organizing human activity) for an item return transaction. Further, there is no improvement to the claimed API itself; the addition element is merely used generically to further process/analyze/compare received data via common computing components.
In addition, unlike Enfish, the claims are not directed to an improvement in the way computers operate and are merely using generic computing components (as a tool to perform data manipulations). Further, Example 21 was found to be eligible because the transmission of an alert would automatically activate the application even when offline which rooted the claims to technology. In this case, the instant claims are focused on receiving, identifying, obtaining, processing, determining, delivering and adjusting the data itself”. Considering applicant’s claim(s) both individually and as an ordered combination it fails to add subject matter beyond the judicial exception that is not well-understood, routine, and conventional in the field. Regarding applicant’s remarks that the invention is also analogous to the claims in McRo’s 3D animated rules-based method to automate lip-synchronization (which improved the existing technology), applicant’s claims do not focus on a specific means or method that improves the relevant technology, they are “directed to a result or effect that itself is the abstract idea and merely invoke generic processes and machinery” McRo, Inc. v. Bandai Namco Games Am. Inc., 837F.3d1299,1314 (Fed. Cir.2016). As it relates to applicant’s arguments regarding Bascom’s filtering tool, as discussed in the Non-Final action (4/28/25), applicant’s ‘transaction terminal’, ‘inventory system’, application programming interface (API) [claim 1], ‘data store’ [claim 2]; ‘interfaces’ [claim 4]; ‘schedule/delivery system’[claim10] is/are unlike the (customizable) filtering tool of Bascom and does not integrate the abstract idea (receiving item return data associated with a return of an item from a retailer, processing the item based on an item return workflow associated with an entity, determining and providing purchase transaction data and discounted price to a transaction terminal; and adjustment of entity inventory system) into a practical application because it merely recites generic data processing functions which the specification describes are carried out by conventional computer components operating in their normal, routine and ordinary capacity; therefore, the limitation does not recite an inventive concept to transform the abstract idea into a patent-eligible application. Further, the limitation is no more than additional instructions to apply the exception utilizing a computer or with computing components as a tool and generally linking the abstract idea to a particular technological environment. Hence, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. In view of the above, Examiner maintains that the claimed invention is directed to an abstract idea without significantly more.
With respect to the 35USC 103 rejection, applicant’s amendments necessitated new grounds of rejection, therefore the arguments are moot. Examiner has modified the rejection to address each of the claim limitations and further explains how the claim limitations are being interpreted, as noted below in this Final action.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-11 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1-11 are directed to a process (an act, or series of acts or steps). Thus, each of the claims fall within one of the four statutory categories.
Step 2A-Prong 1: Claim 1 recites in part, “... receiving item return data associated with a return of an item from a retailer during a current item return transaction; identifying an entity other than the retailer from the item return data; obtaining an item return workflow associated with the entity; and processing the item return workflow causing select data from the item return data to be delivered to the entity, wherein the processing includes analyzing the item return data to generate real-time insights into item return patterns, and wherein the real-time insights are used to adjust inventory and supply chain decisions within the entity; wherein processing further includes :determining that the current item return transaction is occurring at a particular transaction terminal associated with a particular retailer and is associated with a particular purchase transaction where a particular item was purchased at a discounted price and causing the particular purchase transaction and the discounted price to be provided to the particular transaction terminal during the current item return transaction; wherein the item return workflow is processed in real-time as the current item return transaction is being processed by the particular transaction terminal, and wherein the processing causes the select data to be automatically delivered to an inventory system of the entity via an application programming interface (API) to enable real-time adjustment of inventory deliveries and pickups by systems of the entity.”
Applicant’s specification emphasizes a method for operating a cross- entity transaction and a return data integration service whereby an item return workflow associated with the entity is obtained and the item return workflow is processed causing select data from the item return data to be delivered to the entity. The specification discusses a system/platform/processing environment by which entities can obtain information from item transaction data associated with item sales and returns permitting entities to query and obtain return item data relationships correlations and insights in a computing environment (¶8, ¶14, ¶19-¶27). The underlined limitations above demonstrate independent claim 1 is directed toward the abstract idea for receiving item return data, identifying an entity, obtaining and processing item return workflow, determining that the current item return transaction was purchased at a discounted price, providing the discounted price to the transaction terminal; delivering and adjusting select data to an inventory system of the entity in a computing environment. Claim 1 is considered an abstract idea because the limitations as claimed pertains to (i) mental processes since the steps for …receiving item return data, …identifying an entity other than the retailer, …obtaining an item return workflow associated with the entity…and processing the item return workflow are directed to concepts performed in the human mind (including an observation, evaluation, judgment, opinion) or by a human being with a pen and paper. The claim limitations are also directed to (ii) certain methods of organizing human activity including commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising; marketing; or sales activities or behaviors; business relations); and managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions); and (iii) commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). With the exception of generic computer/processing components, the limitations are merely utilizing computing components as a tool to perform the process. A human being can …receive item return data, …identify an entity other than the retailer, …obtain an item return workflow associated with the entity… process the item return workflow … analyze item return data to generate item return patterns …adjust inventory system of an entity with a pen and paper. There is nothing in the claims themselves that foreclose them from being practically performed by a human being with a pen and paper. Therefore, the claim limitations are directed to the mental processes grouping of abstract idea - see MPEP 2106.04(II).
The claims are also directed to the management of personal behavior, relationships, or interactions between people (including social activities, teaching, and following rules or instructions) (i.e. interactions of retailers (entities, suppliers, manufacturer, retail staff operated terminal/device) and consumer with a terminal/device (and/or consumer device) according to rules or instructions to satisfy entity (retailer) item return workflow and adjust entity inventory system) to facilitate commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) for returning an item during a return transaction within certain methods of organizing human activities grouping. The claim limitations merely tie the abstract idea to a technology and/or a general application of additional elements to perform the inventory adjustment.
Hence, the steps for receiving, identifying, obtaining, processing, determining, adjusting data/information are related to certain methods of organizing human activity grouping of abstract ideas since the claim limitations are directed toward (ii) managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions (applicant’s item return workflow)), and (iii) commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors, business relations (“receive item return data; identify an entity other than the retailer; obtain and process the item return workflow and item return transaction”). Therefore, the claim limitations are also directed to certain methods of organizing human activity and recites an abstract idea--see MPEP 2106.04(II).
Step 2A-Prong 2: This judicial exception is not integrated into a practical application because the additional elements ‘transaction terminal’, ‘inventory system’, application programming interface (API) [claim 1], ‘data store’ [claim 2]; ‘interfaces’ [claim 4]; ‘schedule/delivery system’[claim10] merely provide an abstract-idea based solution using ‘transaction terminal’, ‘inventory system’, application programming interface (API) [claim 1], ‘data store’ [claim 2]; ‘interfaces’ [claim 4]; ‘schedule/delivery system’[claim10] for data gathering and analysis (receiving, identifying, obtaining, processing, determining, adjusting data/information) and merely to provide instructions for organizing human interactions, and implement the abstract idea recited above utilizing ‘transaction terminal’, ‘inventory system’, application programming interface (API) [claim 1], ‘data store’ [claim 2]; ‘interfaces’ [claim 4]; ‘schedule/delivery system’[claim10] as a tool to perform the abstract idea for receiving item return data, identifying an entity, obtaining and processing item return workflow, determining that the current item return transaction was purchased at a discounted price, providing the discounted price to the transaction terminal; delivering and adjusting select data to an inventory system of the entity in a computing environment, and generally links the abstract idea to a particular technological environment. See MPEP 2106.05 (f-h). These additional elements do not impose any meaningful limits on practicing the abstract idea—see MPEP 2106.05(g).
Independent claim 1 fails to operate the recited, ‘transaction terminal’, ‘inventory system’, application programming interface (API) [claim 1], ‘data store’ [claim 2]; ‘interfaces’ [claim 4]; ‘schedule/delivery system’[claim10] (which are merely standard computer technology and hardware/software components) in any exceptional manner, and there is no evidence in the disclosure to suggest achieving an actual improvement in the computer functionality itself, or improvement in any specific computer technology other than utilizing ordinary computational tools to automate and perform the abstract idea recited above in a computing environment —see MPEP 2106.05(a). Further applicant has not shown an improvement or practical application under the guidance of MPEP section 2106.04(d) or 2106.05(a). Applicant’s limitations as recited above do nothing more than supplement the abstract idea using generic processing and networking components performing generic computer functions (receiving, identifying, obtaining, processing, determining, adjusting data/information) such that it amounts to no more than mere instruction to apply the exception using a generic computer component-see MPEP 2106.05(f) and linking the use of the judicial exception to a particular technological environment or field of use as discussed in MPEP 2106.05(h).
Dependent claims 2-11, fail to cure the deficiencies of the above noted independent claim from which they depend and are therefore rejected under the same grounds. The dependent claims further recite the abstract idea without imposing any meaningful limits on practicing the abstract idea. Dependent claims 2-11 recite additional data gathering and processing steps. For example dependent claim 2 recites in part, “maintaining the item return data in a data store’; claim 3 recites in part, “wherein maintaining further includes…”; claim 4 recites in part, “providing interfaces for querying…”; claim 5 recites in part, “obtaining fraud workflow…”; claim 6 recites in part, “identifying a fraud pattern…”; claim 7 recites in part, “identifying an original purchase transaction…”; claim 8 recites in part, “wherein identifying further includes…”; claim 9 recites in part, “wherein obtaining further includes…”; claims 10 and 11 recite in part, “wherein processing further includes…”, which are still directed toward the abstract idea identified previously and are no more than mere instructions to apply the exception using a computer or with computing components.
The additional elements in the dependent claims only serves to further limit the abstract idea utilizing, ‘transaction terminal’, ‘inventory system’, application programming interface (API) [claim 1], ‘data store’ [claim 2]; ‘interfaces’ [claim 4]; ‘schedule/delivery system’[claim10 as a tool, and generally link the use of the abstract idea to a particular technological environment, and hence are nonetheless directed towards fundamentally the same abstract idea as their respective independent claim since they fail to impose any meaningful limits on practicing the abstract idea. Therefore, the abstract idea fails to integrate into any practical application. Thus, under Step 2A-Prong Two the claims are directed to an abstract idea.
Step 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above, with respect to integration of the abstract idea into a practical application, the additional elements ‘transaction terminal’, ‘inventory system’, application programming interface (API) [claim 1], ‘data store’ [claim 2]; ‘interfaces’ [claim 4]; ‘schedule/delivery system’[claim10] amounts to no more than mere instructions to apply the exception using generic computer components which does not integrate a judicial exception into a practical application nor provide an inventive concept (significantly more than the abstract idea). The transaction terminal, inventory system and schedule/delivery system is generally used to process data using generic computing components- see Fig 1, ¶14: “System/platform 100 (herein after just "system100") provides a processing environment by which entities (e.g., Consumer Product Goods manufacturers (CPGs), item suppliers, item distributors, and item retailers) can obtain valuable item data relationships, correlations, and insights from item transactions and, more particularly item returns that span multiple different or cross entities via a cloud-based service accessible to each of the entities for purposes of modifying and altering decision making by systems of the entities”; while the application programming interface is only generically recited in the disclosure for further processing inventory data associated with an entity’s inventory system via a client device- see ¶42: “Integration service114 may report the totals and information directly to the entity's inventory system144 via an Application Programming Interface (API) associated with the corresponding inventory system144 of the corresponding entity… the workflow may define the format and types of data that is to be reported to inventory system144 via the API by integration service114”, applicant’s ‘data store’ is merely used to store data/information- see ¶37: “Each record in data store115 comprises item return data or transaction details for the corresponding item return transaction or for the corresponding purchase transaction”; the API fails to integrate the abstract idea into a practical application because the specification only generally recites an application programming interface (API), fails to provide details regarding the API, and only recites a solution without providing an explicit description, specific algorithm, rules logic or steps of the manner and/or process for how the API defines format, and types of data that is to be reported, and/or provides the selected data to an inventory system or schedule/delivery system of an entity. Further, there is no improvement to the API itself; the addition element is merely used generically to further process/analyze/compare received data via common computing components. Hence, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Accordingly, even when considered as a whole, the claims do not transform the abstract idea into a patent-eligible invention since the claim limitations do not amount to a practical application or significantly more than an abstract idea for receiving item return data, identifying an entity, obtaining and processing item return workflow, determining that the current item return transaction was purchased at a discounted price, providing the discounted price to the transaction terminal; delivering and adjusting select data to an inventory system of the entity. Hence, claims 1-11 are directed to non-statutory subject matter and are rejected as ineligible subject matter under 35 USC 101. See 2019 PEG and MPEP 2106.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-11 are rejected under 35 U.S.C. 103 as being unpatentable over
Wenneman et al., US Patent No US 9,692,738 B1 in view of MacKinnon, US Patent Application Publication No US2021/0241287 A1 in further view of Hammond et al., US Patent Application Publication No US 2016/0321661 A1.
With respect to claim 1,
Wenneman discloses,
receiving item return data associated with a return of an item from a retailer during a current item return transaction (col 2, lines 50-57: “The item return application 121 is executed to handle requests initiated by a buyer to return and/or exchange a product purchased from a seller via a multi-seller marketplace facilitated by the electronic commerce application 119. The item return application 121 can facilitate communications between a buyer and seller that are related to a request by a customer to return and/or exchange a product to the seller”; col 6, lines 34-42: “FIG. 2, shown is one example of a content page that can be rendered in a browser 161 executed by a client device 106a. The depicted content page represents an item return user interface 201 that can be presented to a buyer for the purpose of initiating a request to return a product purchased from a seller in a multi-seller marketplace facilitated by the electronic commerce application 119”)
identifying an entity other than the retailer from the item return data (Abstract: “facilitate item returns on behalf of a buyer where the seller is a seller in a multi-seller marketplace”; col 2, lines 26-49: “The electronic commerce application 119 can facilitate an electronic commerce site associated with one or more retailers through which customers can purchase, rent, and/or download products. In some embodiments, the electronic commerce application 119 can facilitate an electronic commerce site that provides a marketplace in which multiple sellers can offer products to customers”; col 3, lines 16-18: “customer returns to sellers can be initiated and processed by the item return application 121 without interacting with a carrier system 105”; lines 26-35: “The data store 120 can include product data 129, which can include various information about products available via an electronic commerce system facilitated by the computing device 103. The product data 129 can include information that can include, but is not limited to, product descriptions, product keywords, categories, stock keeping unit, product search terms, information identifying which sellers are offering the product for sale, and other information or meta data as can be appreciated”)
obtaining an item return workflow associated with the entity (col 4, liens 12-15: “Additionally, each seller can define one or more return policy 148 that specifies return rules and/or terms associated with the ability of users to initiate return requests”; col 5, lines 19-35: “the seller may define multiple return policies 148 that are associated with specific items and/or item categories of items offered for sale by the seller in the marketplace. For example, the seller may define a first return policy for a particular item or class of items that specifies that a request to return such an item is automatically approved by the item return application 121 if certain reason codes are associated with the return request. Additionally, the seller may define a second return policy for another item or class of items that specifies that the request to return such an item requires manual intervention or approval by a seller acting through a seller return user interface generated by the item return application 121 and provided to the seller. Continuing this example, the seller can also define a default return policy 148 that applies to any items or classes of items for which a specific return policy 148 has not been defined by the seller”)
processing the item return workflow causing select data from the item return data to be delivered to the entity (col 3, lines 47-63: “The data store 120 can also include returns data 135 that includes various entries associated with requests initiated by a user or buyer to return a product purchased from a seller in an electronic marketplace facilitated by the electronic commerce application 119. Each record can include, for example, an order number 137 that identifies an order with which a return is associated. Returns data 135 further identifies one or more items 139 that are associated with a return request. In other words, the items 139 represent items or products that a user wishes to return to a seller as a part of a return request. The items 139 can identify products in a product catalog and/or product data 129 by a product identifier or other identifier that uniquely identifies a product within the data store 120. Each of the items 139 associated with a return request are also associated with a reason code 141 that identifies a reason the user is requested return of the item 139 to the seller”) Applicant’s disclosure teaches that select data can be a current total of returns for the item- see ¶72. Given the broadest reasonable interpretation of the claim limitation in light of the specification, Examiner interprets the data store including returns data of an item/product of Wenneman as teaching applicant’s select data.
Wenneman discloses all of the above limitations, Wenneman does not distinctly describe the following limitations, but MacKinnon however as shown discloses,
wherein the processing includes analyzing the item return data to generate real-time insights into item return patterns (¶59: “The retailer verification application can automatically verify a consumer's transaction based on the code displayed on the consumer's mobile device. This automatic verification helps to eliminate human error in the first instance, in addition, in certain embodiments the retailer verification application provides visual cues to the retail associate if the secure self-payment system cannot retrieve a legitimate data record corresponding to the displayed QR coded receipt as shown on the consumer's mobile device”; ¶170: “Transaction data 510 includes information regarding a completed purchase this data is connected to all other data described in FIG. 5A”; ¶174: “Transaction data 510 is used with customer profile data 502 when the consumer performs any action relating to a past or present transaction. This is necessary as part of the data in 502 directly relates to completed transactions”; ¶186: “QR code generator 516 is the QR code connected to a transaction and individual consumer history. 516 is used to represent a transaction”; ¶187: “the QR code contains embedded therein a token that can be used to verify the purchase of goods and services; ¶200: “The consumer mobile device interacts with the other devices through a two-way likely wireless connection to 608 for purposes likely relating to payment, item lookup, social media tasks or other features which may not be performed directly by the service provider or are enhanced through the use of a third party service, a two-way likely wireless connection to 604 for purposes relating to the retrieval of consumer account information, promotions and service provider to consumer communications, and real world physical interaction with 610, involving the use of the consumer's secure self-payment application and mobile device screen, and the retailer verification app and electronic device camera or other scanning or image capturing mechanism for the purposes of verifying a consumer's purchase”)
and wherein the real-time insights are used to adjust inventory and supply chain decisions within the entity (¶174: “Transaction data 510 is used with customer profile data 502 when the consumer performs any action relating to a past or present transaction”; ¶175: “Transaction data 510 is used with store inventory 504 to adjust inventory amounts for sales, returns or exchanges. This is a step taken as a transaction is completed so that the retailer may adjust its inventory item counts”; ¶224: “the service provider web API communicate secure self-payment method sales transactions and sales batches for live inventory management”; ¶225: “The QR code displayed on mobile device 602 is captured and interpreted by retailer electronic device 610. Retailer electronic device 610 sends a query to the service provider network 604 asking whether the QR code corresponds to a legitimate purchase (step 428, as discussed in connection with FIGS. 4A and 4B, above). A reply is sent back to 610 retailer scanning device with an answer. The retailer scanning device 610 then displays either a legitimate purchase receipt (per step 430) or a request to reseed the information or a “no match” result (per step 432). Depending on the retailer's individual needs, the scanning device may also transmit some information relating to pricing or inventory updates to the retailer network 606 or third-party network(s) 608”; ¶279: “ server 1004 may also contain a supporting API that permits additional functions such as enhanced inventory descriptions, live inventory updates between the brick and mortar store and an online web presence, or web site updates such as shipping information through third party integration such as an eCommerce toolkit; ¶287: “The LAN portion of the local area network also includes one or more servers 1106. The servers 1106 run software to support the network functionalities described herein. In the case of a retailer network these servers 1106 typically include hardware and software that enables them to perform functions related to inventory management, CRM, payment processing, returns, and transaction history”)
wherein the item return workflow is processed in real-time as the current item return transaction is being processed by the particular transaction terminal, and wherein the processing causes the select data to be automatically delivered to an inventory system of the entity via an application programming interface (API) to enable real-time adjustment of inventory deliveries and pickups by systems of the entity (¶111: “in FIG. 3, the in-store return process flow includes the following steps: retrieve receipt 326, present QR code 328, return or exchange item 330, and refund or exchange honored 332”; ¶114: “the retailer follows its specific return or exchange procedures via its mobile device running the retailer verification app or POS system. This step 328 requires the retailer to select the items being returned or exchanged through the use of its chosen QR code reading method. The consumer may also be asked whether he or she would like the transaction refunded to his or her original payment method, store credit or other as per the retailer and payment method rules”; ¶174: “Transaction data 510 is used with customer profile data 502 when the consumer performs any action relating to a past or present transaction”; ¶175: “Transaction data 510 is used with store inventory 504 to adjust inventory amounts for sales, returns or exchanges. This is a step taken as a transaction is completed so that the retailer may adjust its inventory item counts. Connection may be implemented in a variety of ways depending on data access factors, including through third-party POS integrators, POS API access, or direct connections”; ¶224: “the service provider web API communicate secure self-payment method sales transactions and sales batches for live inventory management”; ¶225: “The QR code displayed on mobile device 602 is captured and interpreted by retailer electronic device 610. Retailer electronic device 610 sends a query to the service provider network 604 asking whether the QR code corresponds to a legitimate purchase (step 428, as discussed in connection with FIGS. 4A and 4B, above). A reply is sent back to 610 retailer scanning device with an answer. The retailer scanning device 610 then displays either a legitimate purchase receipt (per step 430) or a request to reseed the information or a “no match” result (per step 432). Depending on the retailer's individual needs, the scanning device may also transmit some information relating to pricing or inventory updates to the retailer network 606 or third-party network(s) 608”; ¶279: “server 1004 may also contain a supporting API that permits additional functions such as enhanced inventory descriptions, live inventory updates between the brick and mortar store and an online web presence, or web site updates such as shipping information through third party integration such as an eCommerce toolkit”; ¶287: “The LAN portion of the local area network also includes one or more servers 1106. The servers 1106 run software to support the network functionalities described herein. In the case of a retailer network these servers 1106 typically include hardware and software that enables them to perform functions related to inventory management, CRM, payment processing, returns, and transaction history”)
Wenneman discloses various embodiments for facilitating item returns on behalf of customers of an electronic commerce site in a multi-seller marketplace. Wenneman further discloses a method/system for facilitating item returns on behalf of customers in a multi-seller marketplace via various applications and a plurality of computing devices. Wenneman teaches that a seller may define a return policy (or policies) associated with specific items and/or item categories of items offered for sale by the seller in the marketplace via an item return application. MacKinnon teaches techniques for verifying the purchase of retail goods and services via a payment verification system. Wenneman and MacKinnon are directed to the same field of endeavor since they are related to techniques for facilitating product return policy information on purchased products in a computing environment. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the electronic commerce site and multi-seller marketplace of Wenneman with the payment verification system as taught by MacKinnon since it allows for verification of a consumer’s purchase via real world interaction with the consumer’s device, hence supplementing a retailer’s fraud prevention process (Fig 3, Fig 5, Fig 6, ¶59, ¶111, ¶114, ¶170, ¶174, ¶175, ¶186, ¶187, ¶200, ¶224, ¶225, ¶295, ¶308).
Wenneman and MacKinnon disclose all of the above limitations, the combination of Wenneman and MacKinnon does not distinctly describe the following limitations but Hammond however as shown discloses,
wherein processing further includes: determining that the current item return transaction is occurring at a particular transaction terminal associated with a particular retailer and is associated with a particular purchase transaction where a particular item was purchased at a discounted price (Figure 1, Tables 1-10, Table 4 “Example definitions of aggregate data used for generating nominations”: Line Discount and/or Markdown Amount; Line Discount Codes; Transaction Discount Amount (allocated); Original Price, Return Reason, Original Store Number, Original Register Number, Original Transaction Number”; Original Transaction Date; ¶3: “identify potential return abuses and frauds committed against the merchant based on the data, and generate a report detailing the potential return abuses and frauds and the risks to the merchant in an easy-to-digest format… the electronic monitoring system may provide real-time alerts to the merchant, allowing the merchant to take immediate action before the customer suspected of committing a return abuse or fraud walks away from the store. The electronic monitoring system may also be used to identify other patterns or trends in the transaction data so that the merchant can take appropriate action based on the identified pattern or trend”; ¶48: “the electronic monitoring system according to some embodiments may determine client-specific (e.g., based on the data associated with a given merchant) thresholds based on the transaction data and the return authorization data generated by the client, identify a group of related transactions based on shared attributes, and nominate the group of related transactions based on the client-specific thresholds. Nominated transactions may be transmitted to the client in real-time or stored for subsequent review by the client. The nominations may be presented in an easy-to-understand graphical format to facilitate the review by the client”; Fig 15, ¶199; ¶210: “FIG. 19, the alert engine may cause alerts to be created based on nominations generated by the identification service 180 and/or based on a request from the client 120 (block 1910). The transaction data collected by the client 120 (e.g., return data, purchase data, return authorization data, the location of the return request, the clerk processing the return, etc.), together with existing stored data which may comprise information about the customer, the clerk, the store, and/or other stored data (collectively transactions 1920), are processed by the alert engine, and the alert engine performs a real-time analysis based on the processed data (block 1930), triggering alerts 1940-1960. The triggered alerts 1940-1960 may prompt the client 120 to take additional action. For example, the client 120 may deny a return transaction, collect additional information, or immediately visit the scene of the transaction associated with the nominations and further investigate the validity of the transaction”
causing the particular purchase transaction and the discounted price to be provided to the particular transaction terminal during the current item return transaction (Figure 1, Table 1, Table 4, ¶3: “the electronic monitoring system may provide real-time alerts to the merchant, allowing the merchant to take immediate action before the customer suspected of committing a return abuse or fraud walks away from the store. The electronic monitoring system may also be used to identify other patterns or trends in the transaction data so that the merchant can take appropriate action based on the identified pattern or trend”; ¶124: “The dollar amount associated with the return 602 may include a net return dollar amount, for example, the dollar amount of the requested return without tax, or the net amount of the return with any discounts taken into consideration. The dollar amount 602 may additionally or alternatively include a net transaction amount that takes into consideration the amount of the return amount and the amount of any purchases and/or exchanges being made by the customer at the same time”; ¶135: “the process for nominating one or more groups of linked transaction records may be highly customized to the business preferences of the client 120, if desired, and may be tailored to include factors deemed relevant and practical for the client's business”; ¶136: “Tables 1-10 illustrate additional factors that may be used to make the determination 600… some or all of the additional factors may be used for identifying linked transactions, nominating groups of linked transactions, identifying employee fraud, identifying SKU anomalies, generating user interfaces, generating alerts, or any other processes described herein. In some embodiments, any combination of the factors described with reference to FIG. 6 and the factors included in Tables 1-10 may be used to determine whether to create associations between various identifiers and transactions, to identify a group of linked transactions, to nominate a group of linked transactions, to deny or approve a return request, etc. Any number of factors (e.g., two, three, four, or any other number of factors along with corresponding thresholds) may be used for making such a determination. For example, the identification service 180 may nominate a group of linked transactions if Factor A associated with the group satisfies Condition A′, Factor B associated with the group satisfies Condition B′, Factor C associated with the group satisfies Condition C′, and Factor D associated with the group satisfies Condition D′”; Table 1: Example types of data used for generating nominations Data Type Examples Transaction a. Transaction key variables (store number, register number, Data at date, time, transaction number, etc.) SKU Level b. Employee ID (Sales and c. SKU Returns) d. Sequence number e. Line discount amounts f. Line discount codes g. Transaction discount amounts h. Transaction Discount codes i. Codes required to identify when a reward or incentive is redeemed”; Table 4:Example definitions of transaction detail data used for generating nominations: Line Discount Discounts and/or Used for doing discount Important field for and/or markdowns applied to analysis discount analysis Markdown this line (which we have Amount found to be related to return fraud) Line Discount code of Used for doing discount Important field for Codes Discount applied to this analysis discount analysis line (which we have found to be related to return fraud) Transaction Portion of the Used for doing discount Important field for Discount transaction discount analysis discount analysis Amount allocated to this line (which we have (allocated) item found to be related to return fraud) Transaction Code for transaction Used for doing discount Important field for Discount analysis discount analysis Codes (which we have found to be related to return fraud)… Override Price override applied Used for doing discount Important field for Amount to this line analysis discount analysis (which we have found to be related to return fraud) Override Price override code of Used for doing discount Important field for Codes Discount applied to this analysis discount analysis line (which we have found to be related to return fraud) Quantity Number of items This is the primary field for Valuable field in purchased determining purchase doing analysis of quantity and is used to product and determine many fraud individuals. related variables. Original Price Original price of the Used to determine the Important field for merchandise as marked percentage discount of an discount analysis in the store before any item and to reconcile data (which we have discounts or from extended amount found to be related markdowns are applied. with the discounts. to return fraud) and to ensure data quality. Extended Actual price paid by the This is the primary price Valuable field in Amount customer for the field for an item and is used doing analysis of merchandise to determine many fraud product and related variables. Individuals”; Fig 8, ¶179: “the dashboard user interface 800 may also include a graphical illustration of the total return amount (e.g., dollar value) by fraud type. In addition, the dashboard user interface 800 may include a table listing the nominations generated for the retailer. For example, for each nomination, one or more of the following parameters may be displayed: nomination ID, status, purchase amount, return amount, return rate, fraud type, most impacted state, and comments. In some embodiments, the purchase amount is a sum of all the purchase amounts associated with the individual transactions associated with a given nomination, and the return amount is a sum of all the return amounts associated with the individual transactions associated with the given nomination”; ¶180: “The displayed information may be customized by the retailer. The retailer can customize the types of graphical representations and/or statistics to be included in the dashboard user interface 800”; Fig 12, ¶187: “FIG. 12, a table user interface 1200 illustrating a given nomination is described. As shown in FIG. 12, the table user interface 1200 may include a list of IDs and/or transactions associated with the given nomination. The IDs associated with the given nomination may include a credit card number, a mailing or resident address, a driver's license number, a state ID number, a gift card ID, a loyalty card ID, a store credit card ID, and/or any other identifier associated with a consumer making the purchase or return associated with the transaction. Each ID may include one or more of a return amount, a purchase amount, a return rate, a date of last transaction, and/or any other parameters indicative of the nature of the ID”; ¶188: “table user interface 1200 may also include a list of transactions associated with the given nomination. Each transaction may include one or more of a return amount, a purchase amount, a data transaction, and/or any other parameters indicative of the nature of the transaction”; ¶209: “The alerts provided by the identification service 180 may be integrated into a return authorization process to provide a warning to the clerk processing the return transaction at the point of return 125 or to provide recommendations to a manager or administrator associated with the client 120 regarding further action that can be taken based on the triggered alert”; ¶210: “The transaction data collected by the client 120 (e.g., return data, purchase data, return authorization data, the location of the return request, the clerk processing the return, etc.), together with existing stored data which may comprise information about the customer, the clerk, the store, and/or other stored data (collectively transactions 1920), are processed by the alert engine, and the alert engine performs a real-time analysis based on the processed data (block 1930), triggering alerts 1940-1960”)
Hammond discloses an electronic monitoring system for receiving a product return request, generating nomination and providing recommendations as to further action(s) to be taken by a retailer via a user interface/dashboard. Hammond further discloses that customer information (metrics) generated and displayed via a table user interface for a given nomination(s) (including a list of IDS, transactions associated with a given nomination, return amount, purchase amount, loyalty card ID and/or any other parameters) to be included in the dashboard user interface may be customized by the retailer for return authorization policies. Hammond discusses various Tables (1-10) and Figures 1, 6, 8, 12, 14D, 15, 19 providing additional factors that may be used for nominating one or more groups of linked transaction records, identifying employee fraud, generating alerts, user interfaces, and creating associations between various identifiers and transactions deemed relevant and practical for the client’s business. Wenneman, MacKinnon and Hammond are directed to the same field of endeavor since they are related to techniques for facilitating product return policy information on purchased products in a computing environment. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the electronic commerce site and multi-seller marketplace of Wenneman with the payment verification system of MacKinnon and the electronic monitoring system for identifying potential return abuses and/or fraud as taught by Hammond since it allows for providing real-time alerts to the merchant, identifying patterns or trends in transaction data, generating and transmitting recommended actions to the client computing system based on a customized nominated group of linked transaction records (Tables 1-10, Figs 1, 5-8, 12, 14D, 15, 19, 20, Abstract, ¶3, ¶124, ¶136, ¶180, ¶188, ¶199, ¶209, ¶210).
With respect to claim 2,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Wenneman further discloses,
maintaining the item return data in a data store along with other item return data associated with the retailer and associated with other retailers for other returns (Abstract: “ facilitate item returns on behalf of a buyer where the seller is a seller in a multi-seller marketplace”; col 3, lines 20-36: “computing device 103 can include at least one data store 120, which may comprise data and applications operable to provide access to the data stored therein... data store 120 can include product data 129 can include information that can include, but is not limited to, product descriptions, product keywords, categories, stock keeping unit, product search terms, information identifying which sellers are offering the product for sale, and other information or meta data as can be appreciated”; lines 47-64: “The data store 120 can also include returns data 135 that includes various entries associated with requests initiated by a user or buyer to return a product purchased from a seller in an electronic marketplace facilitated by the electronic commerce application 119. Each record can include, for example, an order number 137 that identifies an order with which a return is associated. Returns data 135 further identifies one or more items 139 that are associated with a return request. In other words, the items 139 represent items or products that a user wishes to return to a seller as a part of a return request. The items 139 can identify products in a product catalog and/or product data 129 by a product identifier or other identifier that uniquely identifies a product within the data store 120. Each of the items 139 associated with a return request are also associated with a reason code 141 that identifies a reason the user is requested return of the item 139 to the seller”).
With respect to claim 3,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Wenneman further discloses,
wherein maintaining further includes maintaining purchase transaction data in the data store associated with the retailer and associated with the other retailers for purchase transactions (col3 lines 36-46: “The data store 120 can further include order data 133, which can include information about orders processed by the electronic commerce application 119. Order data 133 can include any information about an order that can facilitate the processing of a return and/or exchange by the item return application 121. In some embodiments, the order data 133 can identify the products in an order as well as the buyer and seller involved in the transaction. The order data 133 can also include an order number of other types of identifiers with which an order can be uniquely identified within the data store 120”)
With respect to claim 4,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Wenneman further discloses,
providing interfaces for querying and mining the data store to the retailer, the other retailers, the entity, and other entities associated with the return, the other returns, and the purchase transactions (Figs 1-8, col 2, lines 26-49: “The electronic commerce application 119 can facilitate an electronic commerce site associated with one or more retailers through which customers can purchase, rent, and/or download products. In some embodiments, the electronic commerce application 119 can facilitate an electronic commerce site that provides a marketplace in which multiple sellers can offer products to customers. Accordingly, an operator of the electronic commerce site may be different than and/or unaffiliated with a seller. To this end, the electronic commerce application 119 can process orders on behalf of customers and transmit network pages or other user interface elements that can be rendered on a client 106. Similarly, the electronic commerce application 119 can receive data from a client 106 pertaining to product selections, payment information, and other data necessary to effectuate an electronic commerce site”; col 3 lines 21-63: “the computing device 103 can include at least one data store 120, which may comprise data and applications operable to provide access to the data stored therein. It should be appreciated that the data store 120 may or may not reside within a computing device 103, but may be accessible via a network to the computing device 103. The data store 120 can include product data 129, which can include various information about products available via an electronic commerce system facilitated by the computing device 103. The product data 129 can include information that can include, but is not limited to, product descriptions, product keywords, categories, stock keeping unit, product search terms, information identifying which sellers are offering the product for sale, and other information or meta data as can be appreciated…”lines 47-63: “The data store 120 can also include returns data 135 that includes various entries associated with requests initiated by a user or buyer to return a product purchased from a seller in an electronic marketplace facilitated by the electronic commerce application 119. Each record can include, for example, an order number 137 that identifies an order with which a return is associated. Returns data 135 further identifies one or more items 139 that are associated with a return request”)
With respect to claim 5,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Wenneman further discloses,
wherein the multiple retailers comprise the retailer and other retailers (Abstract: “facilitate item returns on behalf of a buyer where the seller is a seller in a multi-seller marketplace”; col 2, lines 26-49: “The electronic commerce application 119 can facilitate an electronic commerce site associated with one or more retailers through which customers can purchase, rent, and/or download products. In some embodiments, the electronic commerce application 119 can facilitate an electronic commerce site that provides a marketplace in which multiple sellers can offer products to customers”; col 3, lines 16-18: “customer returns to sellers can be initiated and processed by the item return application 121 without interacting with a carrier system 105…”; lines 26-35: “The data store 120 can include product data 129, which can include various information about products available via an electronic commerce system facilitated by the computing device 103. The product data 129 can include information that can include, but is not limited to, product descriptions, product keywords, categories, stock keeping unit, product search terms, information identifying which sellers are offering the product for sale, and other information or meta data as can be appreciated”)
Hammond further discloses,
obtaining a fraud workflow associated item return transactions that span multiple retailers and associated with purchase transactions that span the multiple retailers, processing the fraud workflow based on the item return data for the current item return transaction at the retailer (Fig 1, ¶60: “The embodiment of the return authorization service 102 that is depicted in FIG. 1 includes a communication interface 130, a decision engine 135, a customer identification data repository 137, a customer return data repository 140, a client data repository 145, and a repository of client return authorization policies 150”; ¶63: “The received information is sent to a decision engine 135 for assessing risk associated with accepting the requested merchandise return and for making an authorization determination that is based on the assessed risk as well as on stored information about the client's return authorization policies 150”; ¶66: “In addition to stored information about the client's return policies 150, warning policies 155, and coupon policies, the decision engine 135 may make determinations based, at least in part, on information from one or more other repositories of data collected and maintained by the return authorization service 102, or from one or more external client or non-client data sources 160. For example, the decision engine 135 may identify the customer 110 requesting the merchandise return, identify customer data associated with the customer 110 (e.g., prior returns and/or prior purchases made by the customer 110), and make a risk assessment, or other determinations, based at least in part on the identified customer data”; ¶70: “The decision engine 135 may use information from a repository of customer return data 140, which includes a wide variety of information about past merchandise return activity associated with the customers 110. The decision engine 135 may also use information from the repository of sales data, which includes a wide variety of information about past purchases associated with the customers 110. Using the customer identification data 137, the customer return data 140, and the sales data, allows the decision engine 135 to link information about past merchandise purchases and returns with the customer 110 requesting the return at the point of return 125”; ¶75: “FIG. 1 has been described as providing merchandise return authorizations and other related services to a single client 120. However, it is to be understood that, in practice, it may be much more common for the return authorization service 102 to serve a plurality of clients 120. When the return authorization service 102 serves a plurality of clients 120, it may maintain an associated plurality of data stores, including, but not limited to: the customer return data repository 140, the client data repository 145, the client returns authorization policies 150, the client warning issuance policies 155, the client coupon issuance policies, and sales data for each of the clients 120 for whom it provides return authorization services. The return authorization service 102 may maintain these data stores separately, either logically and/or physically. Furthermore, the return authorization service 102 may combine some or all of the various data stores described above”; ¶76: “agreements may be implemented allowing clients to share their collected data for risk assessment or return authorization purposes or other determinations… if a customer 110 makes a return request at a particular client, the authorization determination may be based only on data collected in connection with that particular client (e.g., prior purchases and returns made with the particular client), or it can be based on data collected from various clients”; ¶77: “modifications may be made to the systems and methods described herein such that the systems and methods may store data from a plurality of clients together and/or may use data from one client in a return authorization request from another client. Furthermore, data from external third-party data providers, such as government information sources, credit bureaus, police information sources, and the like may be used by the return authorization service 102 to make determinations for the client 120”; ¶78: “Once the decision engine 135 has made an authorization determination for the requested return, the communication interface 130 may send a message to the POR device 126, informing the clerk of the determination. In some embodiments, the point of return device 126 may then print a record of the requested return, indicating that the return has been accepted or denied. The record may include associated explanations, and, in some embodiments, a warning about limitations on the acceptance of future merchandise returns from the customer 110. In some embodiments, the record may include a coupon or other offer for the customer”; Table 8, Example definitions of store master data used for generating nominations… Store Name… allows for linking of stores across multiple sources; Hierarchy (district, division, region, etc… used for calculating return statistics at each level of the hierarchy… Example statistics are return fraud risk score, return rate, return authorization result, return frequency, time-to-return, seasonality of returns, returns by price tier, returns by geography, returns by manufacturer, warranty returns, recall returns, etc.. produce reports by store and hierarchical categories… do risk analysis by store …Improves accuracy of risk models and identification of suspicious returners, tied to the riskiness of stores and store groups”) Examiner interprets the electronic monitoring system including at least a client’s return authorization policy, decision engine, (customer) risk assessment and generated nominations as taught by Hammond as teaching applicant’s fraud workflow.
Hammond discloses a method/system for receiving a product return request, generating nomination and providing recommendations as to further action(s) to be taken by a retailer via a user interface/dashboard. Hammond discusses various Tables (1-10) and Figures 1, 6, 8, 12, 14D, 15, 19 providing additional factors that may be used for nominating one or more groups of linked transaction records, identifying employee fraud, generating alerts, user interfaces, and creating associations between various identifiers and transactions deemed relevant and practical for the client’s business. Hammond additionally discloses that agreements may be implemented allowing clients to share their collected data for risk assessment or return authorization purposes or other determinations, and that the authorization determination may be based on data collected from various clients. Wenneman, MacKinnon and Hammond are directed to the same field of endeavor since they are related to techniques for facilitating product return policy information on purchased products in a computing environment. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the electronic commerce site and multi-seller marketplace of Wenneman with the payment verification system of MacKinnon and the electronic monitoring system as taught by Hammond since it allows for clients to store and share their collected (consumer) data for risk assessment and return authorization policy determinations, hence improving the identifying of potential return abuses and/or frauds for a client (Abstract, ¶60, ¶63, ¶66, ¶70, ¶75-¶78, Fig 1, 2, 5, 6, 8,12).
With respect to claim 6,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Hammond further discloses,
identifying a fraud pattern or a fraud trend from the item return transactions and the purchase transactions based on the processing of the fraud workflow (Abstract: “receive return authorization data associated with the client computing system, determine linked transaction records based on the return authorization data, nominate a group of linked transaction records based on client-specific thresholds indicative of return abuses or frauds, and generate and transmit recommended actions to the client computing system based on the nominated group of linked transaction records”; ¶3: “identify potential return abuses and frauds committed against the merchant based on the data, and generate a report detailing the potential return abuses and frauds and the risks to the merchant in an easy-to-digest format.. The electronic monitoring system may also identify employees who may be colluding with abusive or fraudulent customers to commit return abuses and frauds against the merchant. Further, the electronic monitoring system may provide real-time alerts to the merchant, allowing the merchant to take immediate action before the customer suspected of committing a return abuse or fraud walks away from the store. The electronic monitoring system may also be used to identify other patterns or trends in the transaction data so that the merchant can take appropriate action based on the identified pattern or trend”; ¶47: “a merchant may determine, based on an individual's purchase and return patterns, whether the individual is engaging in abusive or fraudulent activities and take appropriate action based on the determination… if the individual is returning 90% of the clothes that he or she purchased at a clothing shop, the owner of the clothing shop may determine, by reviewing the past purchases and returns by the individual, that the individual is abusing the return policy and deny any additional return request.”; ¶61: “The embodiment of the return authorization service 102 that is depicted in FIG. 1 includes a communication interface 130, a decision engine 135, a customer identification data repository 137, a customer return data repository 140, a client data repository 145, and a repository of client return authorization policies 150. Other embodiments of the return authorization service 102 may include other components (e.g., a repository of client warning issuance policies, a sales data repository, a repository of client coupon policies, etc.) and/or a subset of these components”; ¶66: “in addition to stored information about the client's return policies 150, warning policies 155, and coupon policies, the decision engine 135 may make determinations based, at least in part, on information from one or more other repositories of data collected and maintained by the return authorization service 102, or from one or more external client or non-client data sources 160. For example, the decision engine 135 may identify the customer 110 requesting the merchandise return, identify customer data associated with the customer 110 (e.g., prior returns and/or prior purchases made by the customer 110), and make a risk assessment, or other determinations, based at least in part on the identified customer data”; ¶68: “The decision engine 135 may access information stored in a repository of customer identification data 137… a customer's 110 address may be an indicator that the requested merchandise return is fraudulent if previous fraudulent returns were made in connection with that address”; Table 10, ¶169: “after generating a nomination based on a determination that a group of linked transaction records represents a renter, the identification service 180 (or the client 120 or the return authorization service 102, based on the nomination data) may determine if there is a trend or pattern in the behavior of the individual(s) linked to the nomination. If the identification service 180 further determines that a threshold percentage (e.g., 50%, 60%, 70%, 80%, or any other percentage) of the returns associated with the nomination belong to the same category, SKU category, or SKU (e.g., sporting goods, more specifically snowboarding goods, and even more specifically snowboards), instead of causing all product returns to result in a denial or a warning, the identification service 180 may cause only product returns in such specific category, SKU category, or SKU to result in a denial or a warning and allow other returns to be processed without regard to this nomination”;¶186: “Upon reviewing the map user interface 1100 illustrated in FIG. 11, the retailer may determine that the particular retail fraud associated with the illustrated nomination is spreading eastward, anticipate where future transactions associated with the particular retail fraud are likely to occur, and take appropriate action to prevent or reduce any additional damage caused by the particular retail fraud… the retailer may increase the number of security guards at the store locations the future transactions are expected to occur, and/or review the return transactions in such store locations more closely”; ¶189: “FIG. 13 is a flowchart that illustrates one embodiment of a process 1300 for identifying an employee who may be connected to return frauds… the employee data may include any criminal records or other publicly available information associated with the employees of the client 120”; Fig 16, ¶203: “the identification service 180 updates a return authorization policy based on the identified SKU category… The identification service 180 may store an indication that the identified SKU category may be associated with return frauds (e.g., a problem SKU category”; claim 1: “determine a set of threshold levels associated with the client based on the received return authorization data, the set of threshold levels indicative of whether a group of linked transaction records has an increased likelihood of being associated with an organized retail crime ring …in response to determining that the first group of linked transaction records has an increased likelihood of being associated with an organized retail crime ring, nominate the first group of linked transaction records for presentation to the client and cause the nominated first group of linked transaction records to be stored in the nomination database … transmit the generated organized retail crime ring information over the computer-mediated network to the electronic identify device, thereby enabling the client to take additional action based on the transmitted organized retail crime ring information”)
reporting the fraud pattern or the fraud trend to the multiple retailers, the entity, and other entities associated with the item return transactions and the purchase transactions (Abstract: “generate and transmit recommended actions to the client computing system based on the nominated group of linked transaction records”; ¶3: “identify potential return abuses and frauds committed against the merchant based on the data, and generate a report detailing the potential return abuses and frauds and the risks to the merchant in an easy-to-digest format.. The electronic monitoring system may also identify employees who may be colluding with abusive or fraudulent customers to commit return abuses and frauds against the merchant. Further, the electronic monitoring system may provide real-time alerts to the merchant, allowing the merchant to take immediate action before the customer suspected of committing a return abuse or fraud walks away from the store”; ¶48: “the electronic monitoring system may identify return frauds based on SKU categories not tied to an identifiable set of fraudulent individuals. Real-time alerts can allow the merchant to take immediate action before the evidence of fraud disappears from the scene”; ¶61: “The embodiment of the return authorization service 102 that is depicted in FIG. 1 includes a communication interface 130, a decision engine 135, a customer identification data repository 137, a customer return data repository 140, a client data repository 145, and a repository of client return authorization policies 150. Other embodiments of the return authorization service 102 may include other components (e.g., a repository of client warning issuance policies, a sales data repository, a repository of client coupon policies, etc.) and/or a subset of these components”; ¶68: “The decision engine 135 may access information stored in a repository of customer identification data 137… a customer's 110 address may be an indicator that the requested merchandise return is fraudulent if previous fraudulent returns were made in connection with that address”; ¶72: “a “negative file,” such as a listing of customers 110 who are known to have been involved with past fraudulent returns or past criminal activity, may be maintained and used to make return authorization determinations”; ¶119: “FIG. 5 depicts one embodiment of a nomination model architecture 500 that may be used to provide nominations to the client 120 using the return authorization service 102, the customer identifier extraction service 170, and the identification service 180. In various embodiments, the identification service 180 may accept information available at the time of a merchandise return transaction and provide a risk score or other assessment that represents a relative likelihood that the requested return is abusive or fraudulent”; ¶154: “the identification service 180 determines that a group of linked transaction records represents an organized retail crime (ORC) ring (e.g., a group of individuals committing retail frauds in concert in an organized fashion) if the number of IDs (e.g., the number of individuals or IDs associated with the group of linked transaction records) used over a first specific time period (e.g., past month, past 180 days, past year, past 5 years, etc.) is greater than a first threshold number (e.g., 3, 4, 5, 6, 10, etc.)”; ¶186: FIG. 11, the retailer may determine that the particular retail fraud associated with the illustrated nomination is spreading eastward, anticipate where future transactions associated with the particular retail fraud are likely to occur, and take appropriate action to prevent or reduce any additional damage caused by the particular retail fraud …the retailer may increase the number of security guards at the store locations the future transactions are expected to occur, and/or review the return transactions in such store locations more closely”; ¶189: “FIG. 13 is a flowchart that illustrates one embodiment of a process 1300 for identifying an employee who may be connected to return frauds… the employee data may include any criminal records or other publicly available information associated with the employees of the client 120”; ¶190: “the identification service 180 determines client specific thresholds for identification. The client-specific thresholds may be indicative of whether an employee has an increased likelihood of being connected to a fraudulent customer or performing fraudulent activities herself/himself”; Fig 16, ¶203: “the identification service 180 updates a return authorization policy based on the identified SKU category… The identification service 180 may store an indication that the identified SKU category may be associated with return frauds (e.g., a problem SKU category)”; Table 1, Table 4, claim 1: “transmit the generated organized retail crime ring information over the computer-mediated network to the electronic identify device, thereby enabling the client to take additional action based on the transmitted organized retail crime ring information”)
Hammond discloses a method/system for receiving a product return request, generating nomination and providing recommendations as to further action(s) to be taken by a retailer via a user interface/dashboard. Hammond discusses various Tables (1-10) and Figures 1, 6, 8, 12, 14D, 15, 19 providing additional factors that may be used for nominating one or more groups of linked transaction records, identifying employee fraud, generating alerts, user interfaces, and creating associations between various identifiers and transactions deemed relevant and practical for the client’s business. Hammond additionally discloses that agreements may be implemented allowing clients to share their collected data for risk assessment or return authorization purposes or other determinations, and that the authorization determination may be based on data collected from various clients. Wenneman, MacKinnon and Hammond are directed to the same field of endeavor since they are related to techniques for facilitating product return policy information on purchased products in a computing environment. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the electronic commerce site and multi-seller marketplace of Wenneman with the payment verification system of MacKinnon and the electronic monitoring system as taught by Hammond since it allows for clients to share their collected (consumer) data for risk assessment and return authorization policy determinations, hence identifying potential return abuses and/or frauds and used for identifying client-specific nominations, recommendations, thresholds/return authorization policies (Abstract, ¶60, ¶63, ¶66, ¶70, ¶75-¶78, Fig 1, 2, 5, 6, 8,12).
With respect to claim 7,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Hammond further discloses,
identifying an original purchase transaction for the item based on the processing of the fraud workflow; determining a promotional price was given for the item with the original purchase transaction (¶3: “ identify potential return abuses and frauds committed against the merchant based on the data, and generate a report detailing the potential return abuses and frauds and the risks to the merchant in an easy-to-digest format… the electronic monitoring system may provide real-time alerts to the merchant, allowing the merchant to take immediate action before the customer suspected of committing a return abuse or fraud walks away from the store”; ¶48: “the electronic monitoring system according to some embodiments may determine client-specific (e.g., based on the data associated with a given merchant) thresholds based on the transaction data and the return authorization data generated by the client, identify a group of related transactions based on shared attributes, and nominate the group of related transactions based on the client-specific thresholds. Nominated transactions may be transmitted to the client in real-time or stored for subsequent review by the client. The nominations may be presented in an easy-to-understand graphical format to facilitate the review by the client”; ¶70: “The decision engine 135 may use information from a repository of customer return data 140, which includes a wide variety of information about past merchandise return activity associated with the customers 110. The decision engine 135 may also use information from the repository of sales data, which includes a wide variety of information about past purchases associated with the customers 110. Using the customer identification data 137, the customer return data 140, and the sales data, allows the decision engine 135 to link information about past merchandise purchases and returns with the customer 110 requesting the return at the point of return 125”; ¶75: “FIG. 1 has been described as providing merchandise return authorizations and other related services to a single client 120. However, it is to be understood that, in practice, it may be much more common for the return authorization service 102 to serve a plurality of clients 120. When the return authorization service 102 serves a plurality of clients 120, it may maintain an associated plurality of data stores, including, but not limited to: the customer return data repository 140, the client data repository 145, the client returns authorization policies 150, the client warning issuance policies 155, the client coupon issuance policies, and sales data for each of the clients 120 for whom it provides return authorization services. The return authorization service 102 may maintain these data stores separately, either logically and/or physically. Furthermore, the return authorization service 102 may combine some or all of the various data stores described above”; ¶76: “agreements may be implemented allowing clients to share their collected data for risk assessment or return authorization purposes or other determinations… if a customer 110 makes a return request at a particular client, the authorization determination may be based only on data collected in connection with that particular client (e.g., prior purchases and returns made with the particular client), or it can be based on data collected from various clients”; ¶78: ““Once the decision engine 135 has made an authorization determination for the requested return, the communication interface 130 may send a message to the POR device 126, informing the clerk of the determination”; ¶124: “The dollar amount associated with the return 602 may include a net return dollar amount, for example, the dollar amount of the requested return without tax, or the net amount of the return with any discounts taken into consideration. The dollar amount 602 may additionally or alternatively include a net transaction amount that takes into consideration the amount of the return amount and the amount of any purchases and/or exchanges being made by the customer at the same time”; ¶136: “some or all of the additional factors may be used for identifying linked transactions, nominating groups of linked transactions, identifying employee fraud, identifying SKU anomalies, generating user interfaces, generating alerts, or any other processes described herein. In some embodiments, any combination of the factors described with reference to FIG. 6 and the factors included in Tables 1-10 may be used to determine whether to create associations between various identifiers and transactions, to identify a group of linked transactions, to nominate a group of linked transactions, to deny or approve a return request, etc. Any number of factors (e.g., two, three, four, or any other number of factors along with corresponding thresholds) may be used for making such a determination”; Table 1: Example types of data used for generating nominations Data Type Examples Transaction a. transaction key variables (store number, register number, Data at date, time, transaction number, etc.) SKU Level b. Employee ID (Sales and c. SKU Returns) d. Sequence number e. Line discount amounts f. Line discount codes g. Transaction discount amounts h. Transaction Discount codes i. Codes required to identify when a reward or incentive is redeemed”; Table 4: Example definitions of transaction detail data used for generating nominations: Line Discount Discounts and/or Used for doing discount Important field for and/or markdowns applied to analysis discount analysis… Line Discount code of Used for doing discount Important field for Codes Discount applied to this analysis discount analysis line (which we have found to be related to return fraud) Transaction Portion of the Used for doing discount Important field for Discount transaction discount analysis discount analysis Amount allocated to this line (which we have (allocated) item found to be related to return fraud) Transaction Code for transaction Used for doing discount Important field for Discount analysis discount analysis Codes (which we have found to be related to return fraud)… Override Price override applied Used for doing discount Important field for Amount to this line analysis discount analysis (which we have found to be related to return fraud) Override Price override code of Used for doing discount Important field for Codes Discount applied to this analysis discount analysis line (which we have found to be related to return fraud) Quantity Number of items This is the primary field for Valuable field in purchased determining purchase doing analysis of quantity and is used to product and determine many fraud individuals. related variables. Original Price Original price of the Used to determine the Important field for merchandise as marked percentage discount of a discount analysis in the store before any item and to reconcile data (which we have discounts or from extended amount found to be related markdowns are applied. with the discounts. to return fraud) and to ensure data quality. Extended Actual price paid by the This is the primary price Valuable field in Amount customer for the field for an item and is used doing analysis of merchandise to determine many fraud product and related variables. Individuals”; Fig 8, ¶179: “the dashboard user interface 800 may also include a graphical illustration of the total return amount (e.g., dollar value) by fraud type. In addition, the dashboard user interface 800 may include a table listing the nominations generated for the retailer. For example, for each nomination, one or more of the following parameters may be displayed: nomination ID, status, purchase amount, return amount, return rate, fraud type, most impacted state, and comments. ¶180: “The displayed information may be customized by the retailer. The retailer can customize the types of graphical representations and/or statistics to be included in the dashboard user interface 800”; Fig 12, ¶187: “FIG. 12, a table user interface 1200 illustrating a given nomination is described. As shown in FIG. 12, the table user interface 1200 may include a list of IDs and/or transactions associated with the given nomination. The IDs associated with the given nomination may include a credit card number, a mailing or resident address, a driver's license number, a state ID number, a gift card ID, a loyalty card ID, a store credit card ID, and/or any other identifier associated with a consumer making the purchase or return associated with the transaction. Each ID may include one or more of a return amount, a purchase amount, a return rate, a date of last transaction, and/or any other parameters indicative of the nature of the ID”; ¶188: “table user interface 1200 may also include a list of transactions associated with the given nomination. Each transaction may include one or more of a return amount, a purchase amount, a data transaction, and/or any other parameters indicative of the nature of the transaction”) Examiner interprets the electronic monitoring system including at least a client’s return authorization policy, decision engine, (customer) risk assessment and generated nominations as taught by Hammond as teaching applicant’s fraud workflow.
alerting the retailer to the original purchase transaction and the promotional price during the current item return transaction for the return of the item at a transaction terminal of the retailer (¶78: “Once the decision engine 135 has made an authorization determination for the requested return, the communication interface 130 may send a message to the POR device 126, informing the clerk of the determination. In some embodiments, the point of return device 126 may then print a record of the requested return, indicating that the return has been accepted or denied. The record may include associated explanations, and, in some embodiments, a warning about limitations on the acceptance of future merchandise returns from the customer 110”; ¶124: “The dollar amount associated with the return 602 may include a net return dollar amount, for example, the dollar amount of the requested return without tax, or the net amount of the return with any discounts taken into consideration. The dollar amount 602 may additionally or alternatively include a net transaction amount that takes into consideration the amount of the return amount and the amount of any purchases and/or exchanges being made by the customer at the same time”; ¶180: “The displayed information may be customized by the retailer. The retailer can customize the types of graphical representations and/or statistics to be included in the dashboard user interface 800”; Fig 12, ¶187: “FIG. 12, a table user interface 1200 illustrating a given nomination is described. As shown in FIG. 12, the table user interface 1200 may include a list of IDs and/or transactions associated with the given nomination. The IDs associated with the given nomination may include a credit card number, a mailing or resident address, a driver's license number, a state ID number, a gift card ID, a loyalty card ID, a store credit card ID, and/or any other identifier associated with a consumer making the purchase or return associated with the transaction. Each ID may include one or more of a return amount, a purchase amount, a return rate, a date of last transaction, and/or any other parameters indicative of the nature of the ID”; ¶188: “table user interface 1200 may also include a list of transactions associated with the given nomination”; ¶209: “The alerts provided by the identification service 180 may be integrated into a return authorization process to provide a warning to the clerk processing the return transaction at the point of return 125 or to provide recommendations to a manager or administrator associated with the client 120 regarding further action that can be taken based on the triggered alert”; ¶210: “The transaction data collected by the client 120 (e.g., return data, purchase data, return authorization data, the location of the return request, the clerk processing the return, etc.), together with existing stored data which may comprise information about the customer, the clerk, the store, and/or other stored data (collectively transactions 1920), are processed by the alert engine, and the alert engine performs a real-time analysis based on the processed data (block 1930), triggering alerts 1940-1960”)
Hammond discloses a method/system for receiving a product return request, generating nomination and providing recommendations as to further action(s) to be taken by a retailer via a user interface/dashboard. Hammond discusses various Tables (1-10) and Figures 1, 6, 8, 12, 14D, 15, 19 providing additional factors that may be used for nominating one or more groups of linked transaction records, identifying employee fraud, generating alerts, user interfaces, and creating associations between various identifiers and transactions deemed relevant and practical for the client’s business. Hammond additionally discloses that agreements may be implemented allowing clients to share their collected data for risk assessment or return authorization purposes or other determinations, and that the authorization determination may be based on data collected from various clients. Wenneman, MacKinnon and Hammond are directed to the same field of endeavor since they are related to techniques for facilitating product return policy information on purchased products in a computing environment. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the electronic commerce site and multi-seller marketplace of Wenneman with the payment verification system of MacKinnon and the electronic monitoring system as taught by Hammond since it allows for clients to share their collected (consumer) data for risk assessment and return authorization policy determinations, hence identifying potential return abuses and/or frauds and used for identifying client-specific nominations, recommendations, thresholds/return authorization policies (Abstract, ¶60, ¶63, ¶66, ¶70, ¶75-¶78, Fig 1, 2, 5, 6, 8,12).
With respect to claim 8,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Hammond further discloses,
wherein identifying further includes obtaining an entity identifier for the entity from a Universal Product Code (UPC) included within the item return data for the item (¶112: “the clerk is prompted to scan the products being returned. A bar code on the products can be scanned using the scanner 325, or alternatively, the clerk can user the keypad 315 to enter a Stock Keeping Unit code (SKU), a Universal Product Code (UPC), or other number that identifies the products being returned”; ¶125: “information about items presented for return 603 may include information about one or more item identifiers (bar code, Stock Keeping Unit code (SKU), Universal Product Code (UPC), Radio Frequency Identifier (RFID), and the like), information about individual item prices and merchandise types, as well as a total number of items being returned; ¶136: “Tables 1-10 illustrate additional factors that may be used to make the determination 600. For example, some or all of the additional factors may be used for identifying linked transactions, nominating groups of linked transactions, identifying employee fraud, identifying SKU anomalies, generating user interfaces, generating alerts, or any other processes described herein. In some embodiments, any combination of the factors described with reference to FIG. 6 and the factors included in Tables 1-10 may be used to determine whether to create associations between various identifiers and transactions, to identify a group of linked transactions, to nominate a group of linked transactions, to deny or approve a return request, etc. Any number of factors (e.g., two, three, four, or any other number of factors along with corresponding thresholds) may be used for making such a determination”; Table 4, UPC Universal Product Code number & Transaction detail data used for generating nominations for doing analysis of product and individuals)
Hammond discloses a method/system for receiving a product return request, generating nomination and providing recommendations as to further action(s) to be taken by a retailer via a user interface/dashboard. Hammond discusses various Tables (1-10) and Figures 1, 6, 8, 12, 14D, 15, 19 providing additional factors that may be used for nominating one or more groups of linked transaction records, identifying employee fraud, generating alerts, user interfaces, and creating associations between various identifiers and transactions deemed relevant and practical for the client’s business. Hammond additionally discloses that agreements may be implemented allowing clients to share their collected data for risk assessment or return authorization purposes or other determinations, and that the authorization determination may be based on data collected from various clients. Wenneman, MacKinnon and Hammond are directed to the same field of endeavor since they are related to techniques for facilitating product return policy information on purchased products in a computing environment. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the electronic commerce site and multi-seller marketplace of Wenneman with the payment verification system of MacKinnon and the electronic monitoring system as taught by Hammond since it allows for identifying the product and analysis of returns at the product level to develop product level risk metrics in fraud models, identify fraudulent individuals, potential return abuses and/or frauds, client-specific nominations, recommendations, thresholds/return authorization policies (Tables 1-10, Abstract, ¶112, ¶125, ¶136; Fig 1, 2, 5, 6, 8,12).
With respect to claim 9,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Wenneman further discloses,
wherein obtaining further includes selecting the item return workflow from a plurality of item return workflows associated with the entity based on an item type assigned to the item and included within the item return data (col 4, lines 12-15: “Additionally, each seller can define one or more return policy 148 that specifies return rules and/or terms associated with the ability of users to initiate return requests”; col 5, lines 19-35: “the seller may define multiple return policies 148 that are associated with specific items and/or item categories of items offered for sale by the seller in the marketplace. For example, the seller may define a first return policy for a particular item or class of items that specifies that a request to return such an item is automatically approved by the item return application 121 if certain reason codes are associated with the return request. Additionally, the seller may define a second return policy for another item or class of items that specifies that the request to return such an item requires manual intervention or approval by a seller acting through a seller return user interface generated by the item return application 121 and provided to the seller. Continuing this example, the seller can also define a default return policy 148 that applies to any items or classes of items for which a specific return policy 148 has not been defined by the seller”)
With respect to claim 10,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Wenneman further discloses,
wherein processing further includes providing the select data to the inventory system or a schedule/delivery system of the entity through the API (col 2, line 60- col 3 line 6: “The carrier connector 125 can facilitate communication with an application programming interface 127 provided by the carrier system 105. The carrier connector 125 can facilitate retrieval or tracking data associated with parcels that are in turn associated with customer orders processed by the electronic commerce application 119. In some embodiments, the carrier system 105 can push tracking data associated with parcels handled by a carrier to the carrier connector 125, which can provide the tracking data to subscribing systems and/or applications within an electronic commerce site. In one embodiment, tracking data associated with parcels can be generated whenever a product is scanned by a carrier device, and can be associated with a time, location, and other variables as can be appreciated”; col 4, lines 19-41: “The carrier system 105 can include shipping data 149 that is related to parcels that can be associated with orders in an electronic commerce site. Shipping data 149 can include tracking data 151 related to various parcels that is maintained by a carrier. Tracking data 151 can include a tracking number as well as scan data that tracks each time a parcel is scanned by a carrier in transit to or from a customer as can be appreciated. The carrier system 105 can also provide an API 127 through which tracking data 151 can be retrieved by the carrier connector 125. In some embodiments, the carrier system 105 can push tracking data to the computing device 103 via an API provided therein. It should be appreciated that the carrier system 105 can be representative of multiple carrier systems 105 that may also be associated with various carriers, who may provide varying API's 127 or other ways to retrieve tracking data 151 related to parcels that are associated with customer orders. In other embodiments, a carrier system 105 and the carrier connector 125 can communicate via electronic data interchange messages or other methods to communicate tracking data 151 as can be appreciated”) Examiner interprets the carrier system of Wenneman as teaching applicant’s schedule/delivery system.
With respect to claim 11,
Wenneman, MacKinnon and Hammond disclose all of the above limitations, Wenneman further discloses,
wherein processing further includes providing the select data as a current total of returns for the item that is associated with the entity and that is occurring at the retailer or occurring at a custom aggregation of other retailers within a current period of time, wherein the custom aggregation and the current period of time is defined within the item return workflow for the entity (col 2, lines 50-60: “Each record can include, for example, an order number 137 that identifies an order with which a return is associated. Returns data 135 further identifies one or more items 139 that are associated with a return request. In other words, the items 139 represent items or products that a user wishes to return to a seller as a part of a return request”; col 3, lines 3-6: “tracking data associated with parcels can be generated whenever a product is scanned by a carrier device, and can be associated with a time, location, and other variables as can be appreciated”; col 6, lines 34-49: FIG. 2, shown is one example of a content page that can be rendered in a browser 161 executed by a client device 106a. The depicted content page represents an item return user interface 201 that can be presented to a buyer for the purpose of initiating a request to return a product purchased from a seller in a multi-seller marketplace facilitated by the electronic commerce application 119. In the depicted example item return user interface 201, the item return application 121 can present various options to a user. First, the item return user interface 201 can allow the user to select an order associated with one or more products the user wishes to return to the seller from which the user purchased the products in the order. A user can also select one or more of the items associated with the order that correspond to the items the user wishes to return by manipulating the checkboxes 205a, 205b”)
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Brooks et al., US Patent No US 10,360,548 B2, “Systems and Methods of Managing Perpetual Inventory”, relating to methods/systems for monitoring, tracking and management of a perpetual inventory system whereby inventory adjustments are implemented in substantially real-time based on a plurality of different events associated with different products at a shopping facility.
Burris et al., US Patent Application Publication No US 2022/0230135 A1, “Item Return Architecture and Processing”, relating to customized rules for item return procedures, item return workflow, and/or policies of a given retailer which when evaluated during an item return provides real-time fraud/security compliance, exception processing, notification/alert processing, offer (Customer-Relationship Management (CRM)) processing, and/or Application Programming Interface (API) calls for initiating or interacting with automated programs (i.e. retailer's loyalty system, a retailer's inventory management system, a retailer's security system, a retailer's transaction system; a retailer's workflow management system, a retailer's data warehouse system, etc.).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Kimberly L. Evans whose telephone number is 571.270.3929. The Examiner can normally be reached on Monday-Friday, 9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Lynda Jasmin can be reached at 571.272.6782.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal/pair <http://pair-direct.uspto.gov >. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free). Any response to this action should be mailed to: Commissioner of Patents and Trademarks, P.O. Box 1450, Alexandria, VA 22313-1450 or faxed to 571-273-8300. Hand delivered responses should be brought to the United States Patent and Trademark Office Customer Service Window: Randolph Building 401 Dulany Street, Alexandria, VA 22314.
/KIMBERLY L EVANS/Examiner, Art Unit 3629
/LYNDA JASMIN/Supervisory Patent Examiner, Art Unit 3629
Prosecution Insights