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 su