DETAILED ACTION
Status of Claims
• The following is an office action in response to the communication filed 06/16/2026.
• Claims 1 and 7 have been amended.
• Claims 3-4, 9-10, and 12 have been canceled.
• Claims 13-14 have been added.
• Claims 1-2, 5-8, 11, and 13-14 are currently pending and have been examined.
Priority
The applicant’s claim for benefit of Provisional Patent Application Serial No. 63/742,036 filed 01/06/2025 has been received and acknowledged.
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 .
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-2, 5-8, 11, and 13-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more. The claims recite an abstract idea. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
First, it is determined whether the claims are directed to a statutory category of invention. See MPEP 2106.03(II). In the instant case, claims 1-2, 5-6, and 13 are directed to a process, and claims 7-8, 11, and 14 are directed to a machine. Therefore, claims 1-2, 5-8, 11, and 13-14 are directed to statutory subject matter under Step 1 of the Alice/Mayo test (Step 1: YES).
The claims are then analyzed to determine if the claims are directed to a judicial exception. See MPEP 2106.04. In determining whether the claims are directed to a judicial exception, the claims are analyzed to evaluate whether the claims recite a judicial exception (Prong 1 of Step 2A), as well as analyzed to evaluate whether the claims recite additional elements that integrate the judicial exception into a practical application of the judicial exception (Prong 2 of Step 2A). See MPEP 2106.04.
Taking claim 1 as representative, claim 1 recites at least the following limitations that are believed to recite an abstract idea:
receiving a selection of one or more items listed for sale by a first user account;
generating a bundled purchase offer comprising the selected items and one or more additional items listed by the first user account;
receiving one or more items offered for trade from a second user account in exchange for all or part of the bundled purchase offer;
calculating a net transaction value based on the bundled purchase offer and the trade items;
storing settlement data for the bundled purchase offer and trade items;
storing a PurchaseOfferFinancialSettlement object associated with each user account involved in the transaction, the PurchaseOfferFinancialSettlement object storing financial trade value debit and credit from an associated order, and a PurchaseOfferItem object for each item, the PurchaseOfferItem object storing a unit sale price and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace, wherein, when a key to the PurchaseOfferFinancialSettlement object is present, settlement of orders bypasses conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order;
presenting the bundled purchase offer and trade items to the first user account for acceptance, rejection, or counteroffer;
updating the settlement data in response to acceptance, rejection, or counteroffer by the first user account; and
upon acceptance of the bundled purchase offer, locking related inventory items while the transaction is pending.
The above limitations recite the concept of facilitating trade of bundled items. These limitations, under their broadest reasonable interpretation, fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, enumerated in the MPEP, in that they recite commercial or legal interactions such as advertising, marketing, or sales activities or behaviors. Specifically, facilitating trade is a sales activity. This is further illustrated in paragraph [0002] of the Specification, describing the invention relates to commerce and marketplaces. Further, these limitations, under their broadest reasonable interpretation, fall within the “Mental Processes” grouping of abstract ideas, enumerated in the MPEP, in that they recite concepts performed in the human mind, including observations, evaluations, judgments, and opinions. Specifically, the receiving of data, calculating, and updating are observations, evaluations, and judgements. Independent claim 7 recites similar limitations as claim 1 and as such, claim 7 falls within the same identified grouping of abstract ideas. Accordingly, under Prong One of Step 2A of the Alice/Mayo test, claims 1 and 7 recite an abstract idea (Step 2A, Prong One: YES).
Under Prong Two of Step 2A of the MPEP, claims 1 and 7 recite additional elements, such as a computer-implemented method; a peer-to-peer e-commerce marketplace; a server; a database; a foreign-key; a user interface; and a computer system, the system comprising: a processor; a memory storing instructions executable by the processor, the instructions, when executed, causing the system to. These additional elements are described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration. As such, these computer-related limitations are not found to be sufficient to integrate the abstract idea into a practical application. Although these additional computer-related elements are recited, claims 1 and 7 merely invoke such additional elements as a tool to perform the abstract idea. Implementing an abstract idea on a generic computer is not indicative of integration into a practical application. Similar to the limitations of Alice, claims 1 and 7 merely recite a commonplace business method (i.e., facilitating trade) being applied on a general purpose computer. See MPEP 2106.05(f). Furthermore, claims 1 and 7 generally link the use of the abstract idea to a particular technological environment or field of use. The courts have identified various examples of limitations as merely indicating a field of use/technological environment in which to apply the abstract idea, such as specifying that the abstract idea of monitoring audit log data relates to transactions or activities that are executed in a computer environment, because this requirement merely limits the claims to the computer field, i.e., to execution on a generic computer (see FairWarning v. Iatric Sys.). Likewise, claims 1 and specifying that the abstract idea of facilitating trade is executed in a computer environment merely indicates a field of use in which to apply the abstract idea because this requirement merely limits the claims to the computer field, i.e., to execution on a generic computer. As such, under Prong Two of Step 2A of the MPEP, when considered both individually and as a whole, the limitations of claims 1 and 7 are not indicative of integration into a practical application (Step 2A, Prong Two: NO).
Since claims 1 and 7 recite an abstract idea and fail to integrate the abstract idea into a practical application, claims 1 and 7 are “directed to” an abstract idea (Step 2A: YES).
Next, under Step 2B, the claims are analyzed to determine if there are additional claim limitations that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract idea. See MPEP 2106.05. The instant claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception for at least the following reasons.
Returning to independent claims 1 and 7, these claims recite additional elements, such as a computer-implemented method; a peer-to-peer e-commerce marketplace; a server; a database; a foreign-key; a user interface; and a computer system, the system comprising: a processor; a memory storing instructions executable by the processor, the instructions, when executed, causing the system to. As discussed above with respect to Prong Two of Step 2A, although additional computer-related elements are recited, the claims merely invoke such additional elements as a tool to perform the abstract idea. See MPEP 2106.05(f). Moreover, the limitations of claims 1 and 7 are manual processes, e.g., receiving information, analyzing information, etc. The courts have indicated that mere automation of manual processes is not sufficient to show an improvement in computer-functionality (see MPEP 2106.05(a)(I)). Furthermore, as discussed above with respect to Prong Two of Step 2A, claims 1 and 7 merely recite the additional elements in order to further define the field of use of the abstract idea, therein attempting to generally link the use of the abstract idea to a particular technological environment, such as the Internet or computing networks (see Ultramercial, Inc. v. Hulu, LLC. (Fed. Cir. 2014); Bilski v. Kappos (2010); MPEP 2106.05(h)). Similar to FairWarning v. Iatric Sys., claims specifying that the abstract idea of facilitating trade is executed in a computer environment merely indicates a field of use in which to apply the abstract idea because this requirement merely limits the claim to the computer field, i.e., to execution on a generic computer.
Even when considered as an ordered combination, the additional elements do not add anything that is not already present when they are considered individually. In Alice Corp., the Court considered the additional elements “as an ordered combination,” and determined that “the computer components…‘[a]dd nothing…that is not already present when the steps are considered separately’ and simply recite intermediated settlement as performed by a generic computer.” Id. (citing Mayo, 566 U.S. at 79, 101 USPQ2d at 1972). Similarly, viewed as a whole, claims 1 and 7 simply convey the abstract idea itself facilitated by generic computing components. Therefore, under Step 2B of the Alice/Mayo test, there are no meaningful limitations in claims 1 and 7 that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself (Step 2B: NO).
Dependent claims 2, 5-6, 8, 11, and 13-14, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because they recite an abstract idea, are not integrated into a practical application, and do not add “significantly more” to the abstract idea. More specifically, dependent claims 2, 5-6, 8, 11, and 13-14 further fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, enumerated in the MPEP, in that they further recite commercial or legal interactions such as advertising, marketing, or sales activities or behaviors and managing personal behavior or relationships or interactions between people. These claims additionally fall within the “Mental Processes” grouping of abstract ideas, enumerated in the MPEP, in that they recite concepts performed in the human mind, including observations, evaluations, judgments, and opinions. Dependent claims 5-6, 11, and 13-14 fail to identify additional elements and as such, are not indicative of integration into a practical application. Dependent claims 2 and 8 further identify additional elements, such as in-app and email notifications. Similar to discussion above the with respect to Prong Two of Step 2A, although additional computer-related elements are recited, the claims merely invoke such additional elements as a tool to perform the abstract idea. See MPEP 2106.05(f). As such, under Step 2A, dependent claims 2, 5-6, 8, 11, and 13-14 are “directed to” an abstract idea. Similar to the discussion above with respect to claims 1 and 7, dependent claims 2, 5-6, 8, 11, and 13-14 analyzed individually and as an ordered combination, invoke such additional elements as a tool to perform the abstract idea and merely indicate a field of use in which to apply the abstract idea because this requirement merely limits the claims to the computer field, i.e., to execution on a generic computer, and therefore, do not amount to significantly more than the abstract idea itself. See MPEP 2106.05(f)(2). Accordingly, under the Alice/Mayo test, claims 1-2, 5-8, 11, and 13-14 are ineligible.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1, 5, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Spaulding (US 20150294399 A1), hereafter Spaulding, in view of newly cited Likourezos et al. (US 9852469 B1), hereinafter Likourezos.
In regards to claim 1, Spaulding discloses a computer-implemented method for facilitating bundled multi-item purchase offers with user-to-user trading in a peer-to-peer e-commerce marketplace, the method comprising (Spaulding: [0023-0024]; [0055]):
receiving, by a server, a selection of one or more items listed for sale by a first user account (Spaulding: [0046] – “item management module 306 may be configured to process information relating to items users of item exchange site 110 wish to trade. Items users wish to trade may include items users own and items that users wish to receive in exchange for items that they own. As described above, data associated with items may include an identifier, a title, a description, keywords, images, a value, a status, and/or a location. Item management module 306 may be configured to receive item data from user interface module 302 and provide item data to database 120 in an appropriate format…user interface module 302 may provide graphical user interfaces that enable users to provide information for items they wish to trade”; [0024] and Fig. 1 – “System 100 may include software modules operating on one or more servers”);
generating, by the server, a bundled purchase offer comprising the selected items and one or more additional items listed by the first user account (Spaulding: [0055] – “item data may be used by exchange generator module 308 to present a user with possible transactions. For example, exchange generator module 308 may extract keywords from a description in order to match items one user wants with items another user has. In one example, a user may bundle one or more items that they have for a possible transaction. That is, a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; see also [0024] and Fig. 1);
receiving, by the server, one or more items offered for trade from a second user account in exchange for all or part of the bundled purchase offer (Spaulding: [0059] – “upon finding an item matching an item that a user wants, exchange generator module 308 may generate possible transactions based on an item the user of the matching item wants. That is, exchange generator module 308 may determine whether a user having a matching item wants an item matching the item the other user has. In one example, this type of transaction may be referred to as a direct match”; [0055] – “a user may bundle one or more items that they have for a possible transaction”; see also [0024] and Fig. 1);
calculating, by the server, a net transaction value based on the bundled purchase offer and the trade items (Spaulding: [0055] – “item data may be used by exchange generator module 308 to present a user with possible transactions. For example, exchange generator module 308 may extract keywords from a description in order to match items one user wants with items another user has. In one example, a user may bundle one or more items that they have for a possible transaction. That is, a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; [0058] – “exchange generator module 308 may match an item one user wants with items other users have. Exchange generator 308 may be configured to match any and all combination of item data described herein. For example, exchange generator 308 may be configured to match any and all combinations of…approximate values”; see also [0024] and Fig. 1);
storing, by the server, settlement data for the bundled purchase offer and trade items in a database (Spaulding: [0049] and Fig. 3 – “Exchange status module 310 may be configured to receive user data from user interface module 302 and provide trade status data to database 120 in an appropriate format”; [0055] – “a user may bundle one or more items that they have for a possible transaction. That is, a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”);
storing, by the server, a PurchaseOfferFinancialSettlement object associated with each user account involved in the transaction, the PurchaseOfferFinancialSettlement object storing an associated order, and a PurchaseOfferItem object for each item, the PurchaseOfferItem object storing a unit sale price, wherein, when a foreign-key to the PurchaseOfferFinancialSettlement object is present, settlement of orders bypasses conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order (Spaulding: [0041-0042] and Fig. 3 – “database 120 may include the following example types of data: data associated with users, data associated with items, data associated with categories, and data associated with trades… data associated with trades may include data associated with…trade status information…possible trade statuses may include…completed”; [0057] – “graphical user interface 800…approximate value entry field 804, value currency entry field 806, and continue icon 808. In a manner similar to that described above with respect to FIG. 6, a user may associate detailed information with…approximate value entry field 804, and value currency entry field 806. Once a user provides detailed item data, a user may activate continue icon 808. In one example, upon a user activating continue icon 808, detailed item data may be sent to item management module 306 and item management module 306 may process detailed item data in order to generate item data for storage in in database 120”; [0055] – “a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; Examiner note: Consistent with Specification [0005], the examiner interprets settling via trading to be bypassing conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order);
presenting, via a user interface, the bundled purchase offer and trade items to the first user account for acceptance, rejection, or counteroffer (Spaulding: [0059] – “upon finding an item matching an item that a user wants, exchange generator module 308 may generate possible transactions based on an item the user of the matching item wants”; [0055] – “a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; [0061] and Fig. 9 – “exchange generate module 308 may search item data for matches. Once the matching process is complete, user interface module 302 may generate a graphical user interface presenting results to a user. Graphical user interface 900 illustrated in FIG. 9 is an example of a graphical user interface that may be used to present results to a user. As illustrated in FIG. 9, graphical user interface 900 includes…close icons 904A-904B, trade icon 906”; [0067] – “Trade icon 906 is configured to enable a user to pursue a direct match transaction. In one example, upon a user activating trade icon 906, item exchange site 110 may enable a user to communicate with another user (i.e., user Joe in this example) in order to express interest in pursuing a transaction”; the examiner interprets the trade icon to be acceptance and the close icon to be rejection. It is further noted that acceptance, rejection, and counteroffer are recited in the alternate and thus only one need be taught or disclosed);
updating, by the server, the settlement data in response to acceptance, rejection, or counteroffer by the first user account (Spaulding: [0067] and Fig. 9 – “Further, upon activation of trade icon 906, exchange status module 310 may update a trade status. For example, exchange status module 310 may generate data indicating that trade has been proposed”; [0049] and Fig. 3 – “Exchange status module 310 may be configured to receive user data from user interface module 302 and provide trade status data to database 120 in an appropriate format”; the examiner notes acceptance, rejection, and counteroffer are recited in the alternate and thus only one need be taught or disclosed); and
upon acceptance of the bundled purchase offer, locking, by the server, related inventory items while the transaction is pending (Spaulding: [0048] – “possible trade statuses may include…active, completed…An active status may indicate that a user has committed to a trade and/or a portion of a trade has been completed (e.g., one out of two items exchanged). A completed status may indicate that a trade has been completed (e.g., all items exchanged)”; see also [0055]).
Spaulding further discloses trade status that are tracked, including completed trades (Spaulding: [0048]), yet Spaulding does not explicitly disclose storing financial trade value debit and credit from an order and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace.
However, Likourezos teaches a similar exchange method (Likourezos: [abstract]), including
storing financial trade value debit and credit from an order and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace (Likourezos: Col. 5, Ln. 43-50 – “a web server computer including application software for effecting payment by accessing the database and debiting an electronic auction payment account corresponding to the winning bidder and crediting at least one account corresponding to the seller without any intervention by the winning bidder following the conclusion of the electronic auction”; Col. 11, Ln. 4-8 – “funds are withheld by the system 110 to pay the commission fees of the operator of the system 110 and/or the operator of the electronic auction system 112. The withheld funds are preferably stored within the system account maintained by the system account database 120”; Col. 10, Ln. 66 – Col. 11, Ln. 8 – “computerized electronic auction payment system 110 further withholds a predetermined percentage of the funds obtained by debiting the winning bidder's electronic auction payment account while effecting the real-time payment when the automatic payment field 416 is checked. These funds are withheld by the system 110 to pay the commission fees of the operator of the system 110 and/or the operator of the electronic auction system 112. The withheld funds are preferably stored within the system account maintained by the system account database 120”; see also Col. 5, Lns. 34-40 and 59-67; The examiner notes that “to track item offer pricing to an end user versus a calculated commission basis price for the marketplace” is merely an intended use/result and accordingly is granted little to no patentable weight. Nevertheless, the limitation has been fully examined).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included the storing of Likourezos in the method of Spaulding because Spaulding already discloses storing data and Likourezos is merely what may be stored. Additionally, it would have been obvious to have included storing financial trade value debit and credit from an order and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace as taught by Likourezos because storage is well-known and the use of it in an exchange system would have improved the speed of transaction payments between multiple parties (Likourezos: Col. 3, Ln. 52-67).
Examiner note: The limitations “wherein, when a foreign-key to the PurchaseOfferFinancialSettlement object is present, settlement of orders bypasses conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order” and “upon acceptance of the bundled purchase offer, locking, by the server, related inventory items while the transaction is pending” are conditional limitations and thus may not occur. Therefore, these limitations need not be taught or disclosed by the cited art. Nevertheless, the limitations have been fully examined. It is noted that this applies only for the method claims.
In regards to claim 5, Spaulding/Likourezos teaches the method of claim 1. Spaulding further discloses wherein the user interface enables the first user account to add additional items to the bundled offer (Spaulding: [0055] – “item data may be used by exchange generator module 308 to present a user with possible transactions. For example, exchange generator module 308 may extract keywords from a description in order to match items one user wants with items another user has. In one example, a user may bundle one or more items that they have for a possible transaction. That is, a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; the examiner notes multiple items may be added to the bundle).
In regards to claim 13, Spaulding/Likourezos teaches the method of claim 1. Spaulding further discloses wherein the user interface enables a user to selectively enable or disable offer and trade offer features for the user's listed items, wherein enabling the trade offer feature causes trade offer controls to appear with the user's listed items (Spaulding: [0057] and Fig. 6 – “In a manner similar to that described above with respect to FIG. 6, a user may associate detailed information with a desired item using description entry field 802, approximate value entry field 804, and value currency entry field 806. Once a user provides detailed item data, a user may activate continue icon 808. In one example, upon a user activating continue icon 808, detailed item data may be sent to item management module 306 and item management module 306 may process detailed item data in order to generate item data for storage in in database 120”; [0047] – “exchange generator module 308 and/or user interface module 302 may provide a user with a graphical user interface including a list of possible trades. In one example, the graphical user interfaces described with respect to FIGS. 9-13 may be provided to a user to enable a user to facilitate a possible trade”; the examiner notes that enabling and disabling are recited in the alternate and thus only one need by taught or disclosed).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Spaulding, in view of Likourezos, in view of previously cited Haberman (US 20200005369 A1), hereinafter Haberman.
In regards to claim 2, Spaulding/Likourezos teaches the method of claim 1. Spaulding further discloses sending at least one of in-app and email notifications (Spaulding: [0067] – “A user may be able to communicate with another user regarding a possible transaction using one or more of an automated email to another user via item exchange site, an automated message to another user via item exchange site 110, and/or a direct email to another user”),
yet Spaulding does not explicitly disclose notification to the first user account when the bundled purchase offer is created or modified.
However, Haberman teaches a similar exchange method (Haberman: [abstract]), including
notification to the first user account when the bundled purchase offer is created or modified (Haberman: [0039-0040] and Fig. 2 – “The exchange system 220 may compare the value of the selected digital assets 230e for tradable digital asset 230c and determine that the digital assets do not have equivalent values as the value of the tradable digital value is too low. The exchange system 220 may transmit a message G to the requesting client logic device 215 indicating that the selected digital assets 230e and the tradable digital asset 230c do not have equivalent values and suggesting that the combined value of digital asset 230d with the tradable asset may be sufficient to make the exchange. In some embodiments, a user may make up for the value difference between digital assets using money, points, or any other item that may be used as part of an exchange. The requesting client logic device 215 may transmit a message H indicating approval of the suggested exchange of tradable digital assets 230c and 230d for selected digital asset 230e”).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included the notification regarding the bundle of Haberman in the method of Spaulding/Likourezos because Spaulding/Likourezos already discloses an notifications and Haberman is merely demonstrating how the notification may occur. Additionally, it would have been obvious to have included notification to the first user account when the bundled purchase offer is created or modified as taught by Haberman because notifications are well-known and the use of it in an exchange system would have improved user experience (Haberman: [0024]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Spaulding, in view of Likourezos, in view of previously cited Fleming (US 20190172121 A1), hereinafter Fleming.
In regards to claim 6, Spaulding/Likourezos teaches the method of claim 1,
yet Spaulding/Likourezos does not explicitly disclose wherein counteroffers are iteratively exchanged between the first and second user accounts until acceptance or rejection of the offer.
However, Fleming teaches a similar exchange method (Fleming: [abstract]), including
wherein counteroffers are iteratively exchanged between the first and second user accounts until acceptance or rejection of the offer (Fleming: [0055] – “the original match made by the bartering exchange system is neither accepted nor declined. More specifically, the negotiation process begins when either the matching account or the arbitrary account makes a counteroffer based on the potential item trade identified by the remote server and no party involved declined the potential item trade. In one embodiment of the present invention, the method prompts the matching account to enter a counteroffer for the potential item trade through the corresponding PC device, if the arbitrary account declines the potential item trade in Step D and relays the counteroffer from the corresponding PC device of the matching account to the remote server. Subsequently, the method appends the counteroffer into the potential item trade with the remote server and repeats Step D, as seen in FIG. 11. This negotiation process may continue until both parties accept the each other's counteroffer, or either party declines the counteroffer from the other party”).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included the counteroffers of Fleming in the method of Spaulding/Likourezos because Spaulding/Likourezos already discloses trades and Fleming is merely demonstrating how the trades may occur. Additionally, it would have been obvious to have included wherein counteroffers are iteratively exchanged between the first and second user accounts until acceptance or rejection of the offer as taught by Fleming because counteroffers are well-known and the use of it in an exchange system would have improved user contact (Fleming: [0009]).
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Spaulding, in view of Likourezos, in further view of newly cited Lewis et al. (US 12164537 B1), hereinafter Lewis.
In regards to claim 7, Spaulding discloses a computer system for facilitating bundled multi-item purchase offers with user-to-user trading in a peer-to-peer e-commerce marketplace, the system comprising: a processor; a memory storing instructions executable by the processor, the instructions, when executed, causing the system to (Spaulding: [0023-0024]; [0038]; [0055]):
receive a selection of one or more items listed for sale by a first user account (Spaulding: [0046] – “item management module 306 may be configured to process information relating to items users of item exchange site 110 wish to trade. Items users wish to trade may include items users own and items that users wish to receive in exchange for items that they own. As described above, data associated with items may include an identifier, a title, a description, keywords, images, a value, a status, and/or a location. Item management module 306 may be configured to receive item data from user interface module 302 and provide item data to database 120 in an appropriate format…user interface module 302 may provide graphical user interfaces that enable users to provide information for items they wish to trade”; [0024] and Fig. 1 – “System 100 may include software modules operating on one or more servers”);
generate a bundled purchase offer comprising the selected items and one or more additional items listed by the first user account (Spaulding: [0055] – “item data may be used by exchange generator module 308 to present a user with possible transactions. For example, exchange generator module 308 may extract keywords from a description in order to match items one user wants with items another user has. In one example, a user may bundle one or more items that they have for a possible transaction. That is, a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; see also [0024] and Fig. 1);
receive one or more items offered for trade from a second user account in exchange for all or part of the bundled purchase offer (Spaulding: [0059] – “upon finding an item matching an item that a user wants, exchange generator module 308 may generate possible transactions based on an item the user of the matching item wants. That is, exchange generator module 308 may determine whether a user having a matching item wants an item matching the item the other user has. In one example, this type of transaction may be referred to as a direct match”; [0055] – “a user may bundle one or more items that they have for a possible transaction”; see also [0024] and Fig. 1);
calculate a net transaction value based on the bundled purchase offer and the trade items (Spaulding: [0055] – “item data may be used by exchange generator module 308 to present a user with possible transactions. For example, exchange generator module 308 may extract keywords from a description in order to match items one user wants with items another user has. In one example, a user may bundle one or more items that they have for a possible transaction. That is, a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; [0058] – “exchange generator module 308 may match an item one user wants with items other users have. Exchange generator 308 may be configured to match any and all combination of item data described herein. For example, exchange generator 308 may be configured to match any and all combinations of…approximate values”; see also [0024] and Fig. 1);
store settlement data for the bundled purchase offer and trade items in a database (Spaulding: [0049] and Fig. 3 – “Exchange status module 310 may be configured to receive user data from user interface module 302 and provide trade status data to database 120 in an appropriate format”; [0055] – “a user may bundle one or more items that they have for a possible transaction. That is, a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”);
store a PurchaseOfferFinancialSettlement object associated with each user account involved in the transaction, the PurchaseOfferFinancialSettlement object storing an associated order, and a PurchaseOfferItem object for each item, the PurchaseOfferItem object storing a unit sale price, wherein, settlement of orders bypasses conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order (Spaulding: [0041-0042] and Fig. 3 – “database 120 may include the following example types of data: data associated with users, data associated with items, data associated with categories, and data associated with trades… data associated with trades may include data associated with…trade status information…possible trade statuses may include…completed”; [0057] – “graphical user interface 800…approximate value entry field 804, value currency entry field 806, and continue icon 808. In a manner similar to that described above with respect to FIG. 6, a user may associate detailed information with…approximate value entry field 804, and value currency entry field 806. Once a user provides detailed item data, a user may activate continue icon 808. In one example, upon a user activating continue icon 808, detailed item data may be sent to item management module 306 and item management module 306 may process detailed item data in order to generate item data for storage in in database 120”; [0055] – “a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; Examiner note: Consistent with Specification [0005], the examiner interprets settling via trading to be bypassing conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order);
present the bundled purchase offer and trade items via a user interface for acceptance, rejection, or counteroffer by the first user account (Spaulding: [0059] – “upon finding an item matching an item that a user wants, exchange generator module 308 may generate possible transactions based on an item the user of the matching item wants”; [0055] – “a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user”; [0061] and Fig. 9 – “exchange generate module 308 may search item data for matches. Once the matching process is complete, user interface module 302 may generate a graphical user interface presenting results to a user. Graphical user interface 900 illustrated in FIG. 9 is an example of a graphical user interface that may be used to present results to a user. As illustrated in FIG. 9, graphical user interface 900 includes…close icons 904A-904B, trade icon 906”; [0067] – “Trade icon 906 is configured to enable a user to pursue a direct match transaction. In one example, upon a user activating trade icon 906, item exchange site 110 may enable a user to communicate with another user (i.e., user Joe in this example) in order to express interest in pursuing a transaction”; the examiner interprets the trade icon to be acceptance and the close icon to be rejection. It is further noted that acceptance, rejection, and counteroffer are recited in the alternate and thus only one need be taught or disclosed);
update the settlement data in response to acceptance, rejection, or counteroffer by the first user account (Spaulding: [0067] and Fig. 9 – “Further, upon activation of trade icon 906, exchange status module 310 may update a trade status. For example, exchange status module 310 may generate data indicating that trade has been proposed”; [0049] and Fig. 3 – “Exchange status module 310 may be configured to receive user data from user interface module 302 and provide trade status data to database 120 in an appropriate format”; the examiner notes acceptance, rejection, and counteroffer are recited in the alternate and thus only one need be taught or disclosed);
upon acceptance of the bundled purchase offer, while the transaction is pending (Spaulding: [0048] – “possible trade statuses may include…active, completed…An active status may indicate that a user has committed to a trade and/or a portion of a trade has been completed (e.g., one out of two items exchanged). A completed status may indicate that a trade has been completed (e.g., all items exchanged)”; see also [0055]).
Spaulding further discloses trade status that are tracked, including completed trades (Spaulding: [0048]) and the PurchaseOfferFinancialSettlement object (Spaulding: [0041-0042] and Fig. 3), yet Spaulding does not explicitly disclose storing financial trade value debit and credit from an order and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace; when a foreign-key to the object is present, settlement; and upon acceptance, lock related inventory items.
However, Likourezos teaches a similar exchange method (Likourezos: [abstract]), including
storing financial trade value debit and credit from an order and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace (Likourezos: Col. 5, Ln. 43-50 – “a web server computer including application software for effecting payment by accessing the database and debiting an electronic auction payment account corresponding to the winning bidder and crediting at least one account corresponding to the seller without any intervention by the winning bidder following the conclusion of the electronic auction”; Col. 11, Ln. 4-8 – “funds are withheld by the system 110 to pay the commission fees of the operator of the system 110 and/or the operator of the electronic auction system 112. The withheld funds are preferably stored within the system account maintained by the system account database 120”; Col. 10, Ln. 66 – Col. 11, Ln. 8 – “computerized electronic auction payment system 110 further withholds a predetermined percentage of the funds obtained by debiting the winning bidder's electronic auction payment account while effecting the real-time payment when the automatic payment field 416 is checked. These funds are withheld by the system 110 to pay the commission fees of the operator of the system 110 and/or the operator of the electronic auction system 112. The withheld funds are preferably stored within the system account maintained by the system account database 120”; see also Col. 5, Lns. 34-40 and 59-67; The examiner notes that “to track item offer pricing to an end user versus a calculated commission basis price for the marketplace” is merely an intended use/result and accordingly is granted little to no patentable weight. Nevertheless, the limitation has been fully examined).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included the storing of Likourezos in the method of Spaulding because Spaulding already discloses storing data and Likourezos is merely what may be stored. Additionally, it would have been obvious to have included storing financial trade value debit and credit from an order and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace as taught by Likourezos because storage is well-known and the use of it in an exchange system would have improved the speed of transaction payments between multiple parties (Likourezos: Col. 3, Ln. 52-67).
However, Lewis teaches a similar transaction method (Lewis: [abstract]), including
when a foreign-key to the object is present, settlement (Lewis: Col. 48, Ln. 10-20 – “Relational databases require a predefined schema that specifies the structure of each table. This schema includes information about data types, constraints, and relationships between tables. In the context of the ABT database, the presence of TARs suggests a predefined structure for these repositories, which encompasses ownership details, transaction history”; Col. 48, Ln. 64 – Col. 49, Ln. 10 – “Relational databases: Relational databases organize data in rows and columns which are used to form tables. There are multiple tables within a relational database where a relationship between the two tables can be created using a foreign key. These foreign keys (e.g., unique identifiers) maintain predefined relationships that exist between the tables. These databases are run using relational database management system (RDMS) software and often use such programming languages as SQL standard when processing transactions. It's important to note that due to its reliance on predefined rules and formats. These databases are primarily used to support transactions that include structured or semi-structured types of data such as business transactions which are to be queried for data analysis”); and
upon acceptance, lock related inventory items (Lewis: Col. 18, Ln. 60-66 – “Some transactions can hold payments and products for a limited time (delayed gratification feature) until all products have been selected and depends on the social credit score or relationship with entity 4080. The payment will lock, the product will lock guaranteed sale has been made, and also locks price 4090 of one embodiment”).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included the foreign key and locking of Lewis in the method of Spaulding/Likourezos because Spaulding/Likourezos already discloses data and inventory and Lewis is merely what data may be and how inventory is handled. Additionally, it would have been obvious to have included when a foreign-key to the object is present, settlement; and upon acceptance, lock related inventory items as taught by Lewis because keys and locking are well-known and the use of it in an exchange system would have improved data integrity (Lewis: Col. 10, Ln. 20-25).
In regards to claim 14, Spaulding/Likourezos/Lewis teaches the system of claim 7. Spaulding further discloses wherein the user interface enables a user to selectively enable or disable offer and trade offer features for the user's listed items, wherein enabling the trade offer feature causes trade offer controls to appear with the user's listed items (Spaulding: [0057] and Fig. 6 – “In a manner similar to that described above with respect to FIG. 6, a user may associate detailed information with a desired item using description entry field 802, approximate value entry field 804, and value currency entry field 806. Once a user provides detailed item data, a user may activate continue icon 808. In one example, upon a user activating continue icon 808, detailed item data may be sent to item management module 306 and item management module 306 may process detailed item data in order to generate item data for storage in in database 120”; [0047] – “exchange generator module 308 and/or user interface module 302 may provide a user with a graphical user interface including a list of possible trades. In one example, the graphical user interfaces described with respect to FIGS. 9-13 may be provided to a user to enable a user to facilitate a possible trade”; the examiner notes that enabling and disabling are recited in the alternate and thus only one need by taught or disclosed).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Spaulding, in view of Likourezos, in view of Lewis, in view of Haberman.
In regards to claim 8, Spaulding/Likourezos/Lewis teaches the system of claim 7. Spaulding further discloses send at least one of in-app and email notifications (Spaulding: [0067] – “A user may be able to communicate with another user regarding a possible transaction using one or more of an automated email to another user via item exchange site, an automated message to another user via item exchange site 110, and/or a direct email to another user”),
yet Spaulding/Likourezos/Lewis does not explicitly disclose notification to the first user account when the bundled purchase offer is created or modified.
However, Haberman teaches a similar exchange method (Haberman: [abstract]), including
notification to the first user account when the bundled purchase offer is created or modified (Haberman: [0039-0040] and Fig. 2 – “The exchange system 220 may compare the value of the selected digital assets 230e for tradable digital asset 230c and determine that the digital assets do not have equivalent values as the value of the tradable digital value is too low. The exchange system 220 may transmit a message G to the requesting client logic device 215 indicating that the selected digital assets 230e and the tradable digital asset 230c do not have equivalent values and suggesting that the combined value of digital asset 230d with the tradable asset may be sufficient to make the exchange. In some embodiments, a user may make up for the value difference between digital assets using money, points, or any other item that may be used as part of an exchange. The requesting client logic device 215 may transmit a message H indicating approval of the suggested exchange of tradable digital assets 230c and 230d for selected digital asset 230e”).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included the notification regarding the bundle of Haberman in the method of Spaulding/Likourezos/Lewis because Spaulding/Likourezos/Lewis already discloses an notifications and Haberman is merely demonstrating how the notification may occur. Additionally, it would have been obvious to have included notification to the first user account when the bundled purchase offer is created or modified as taught by Haberman because notifications are well-known and the use of it in an exchange system would have improved user experience (Haberman: [0024]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Spaulding, in view of Likourezos, in view of Lewis, in view of Fleming.
In regards to claim 11, Spaulding/Likourezos/Lewis teaches the system of claim 7,
yet Spaulding/Likourezos/Lewis does not explicitly disclose wherein the user interface allows iterative counteroffer exchanges between the first and second user accounts until acceptance or rejection.
However, Fleming teaches a similar exchange method (Fleming: [abstract]), including
wherein the user interface allows iterative counteroffer exchanges between the first and second user accounts until acceptance or rejection (Fleming: [0055] – “the original match made by the bartering exchange system is neither accepted nor declined. More specifically, the negotiation process begins when either the matching account or the arbitrary account makes a counteroffer based on the potential item trade identified by the remote server and no party involved declined the potential item trade. In one embodiment of the present invention, the method prompts the matching account to enter a counteroffer for the potential item trade through the corresponding PC device, if the arbitrary account declines the potential item trade in Step D and relays the counteroffer from the corresponding PC device of the matching account to the remote server. Subsequently, the method appends the counteroffer into the potential item trade with the remote server and repeats Step D, as seen in FIG. 11. This negotiation process may continue until both parties accept the each other's counteroffer, or either party declines the counteroffer from the other party”).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to have included the counteroffers of Fleming in the method of Spaulding/Likourezos/Lewis because Spaulding/Likourezos/Lewis already discloses trades and Fleming is merely demonstrating how the trades may occur. Additionally, it would have been obvious to have included wherein the user interface allows iterative counteroffer exchanges between the first and second user accounts until acceptance or rejection as taught by Fleming because counteroffers are well-known and the use of it in an exchange system would have improved user contact (Fleming: [0009]).
Response to Arguments
Applicant’s arguments, filed 06/16/2026, have been fully considered.
35 U.S.C. § 101
Applicant argues the claims are integrated into a practical application because the claims “constitute[] a defined improvement as to how the computer system processes transactions…represents an improvement to the functioning of the e-commerce system itself” (Remarks pages 7-9). The examiner disagrees. The MPEP provides guidance on how to evaluate whether claims recite an improvement in the functioning of a computer or an improvement to other technology or technical field. For example, the MPEP states “the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement.” The MPEP further states that “[t]he specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art,” and that, “conversely, if the specification explicitly sets forth an improvement but in a conclusory manner…the examiner should not determine the claim improves technology” (see MPEP 2106.04). That is, the claim includes the components or steps of the invention that provide the improvement described in the specification. Looking to the specification is a standard that the courts have employed when analyzing claims as it relates to improvements in technology. For example, in Enfish, the specification provided teaching that the claimed invention achieves benefits over conventional databases, such as increased flexibility, faster search times, and smaller memory requirements. Enfish LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36 (Fed. Cir. 2016). Additionally, in Core Wireless the specification noted deficiencies in prior art interfaces relating to efficient functioning of the computer. Core Wireless Licensing v. LG Elecs. Inc., 880 F.3d 1356 (Fed Cir. 2018). With respect to McRO, the claimed improvement, as confirmed by the originally filed specification, was “…allowing computers to produce ‘accurate and realistic lip synchronization and facial expressions in animated characters…’” and it was “…the incorporation of the claimed rules, not the use of the computer, that “improved [the] existing technological process” by allowing the automation of further tasks”. McRO, Inc. v. Bandai Namco Games America Inc., 837 F.3d 1299, (Fed. Cir. 2016).
While the examiner acknowledges that improvements to the functioning of a computer or to any other technology or technical field may constitute integration into a practical application (see MPEP 2106.05(a)), the instant claims do not provide a technical improvement. Rather, the claims provide an improvement to the abstract idea of facilitating trade of bundled items. With respect to Applicant’s arguments regarding the foreign key, the examiner notes that the foreign key is recited at a high level and is insufficient to show a technical improvement. Further, it is noted that maintaining inventory consistency is merely an improvement to the abstract idea and not a technical improvement.
Although the claims include computer technology such as a computer-implemented method; a peer-to-peer e-commerce marketplace; a server; a database; a foreign-key; a user interface; and a computer system, the system comprising: a processor; a memory storing instructions executable by the processor, the instructions, when executed, causing the system to, such elements are merely peripherally incorporated in order to implement the abstract idea. Put another way, these additional elements are merely used to apply the abstract idea of facilitating transaction of bundled items in a technological environment without effectuating any improvement or change to the functioning of the additional elements or other technology. This is unlike the improvements recognized by the courts in cases such as Enfish, Core Wireless, and McRO. Unlike precedential cases, neither the specification nor the claims of the instant invention identify such a specific improvement to computer capabilities. The instant claims are not directed to technological improvements but are directed to improving bundled transactions. The claimed process, while arguably resulting in a more efficient process for product ordering, is not providing any improvement to another technology or technical field as the claimed process is not, for example, improving the server and/or computer components that operate the system. Rather, the claimed process is utilizing data sets related to product ordering while still employing the same server and/or computer components used in conventional systems to improve bundled order transactions, e.g. a business method, and therefore is merely applying the abstract idea using generic computing components. As such, the claims are not integrated into a practical application.
Applicant argues that the examiner has not provided Berkheimer evidence to support the position that the claims are well-understood, routine, and conventional (Remarks page 9). The examiner disagrees. The examiner has not commented on whether the claims are well-understood, routine, and conventional, and as such, Berkheimer evidence is not required.
Applicant argues the dependent claims are eligible for the same reasons as the independent claims (Remarks page 9). The examiner disagrees. The 101 rejections of the independent claims have been maintained for the reasons discussed in the 101 rejection and response to remarks paragraphs above. The rejections of the dependent claims are maintained for the same reasons.
Applicant argues the dependent claim 13 and 14 “provid[e] additional support for integration into a practical application (Remarks page 9). The examiner disagrees. The MPEP sets forth, in Step 2A Prong Two, that a claim that recites a judicial exception is not directed to that judicial exception, if the claim as a whole “integrates the recited judicial exception into a practical application of that exception.” The evaluation of Prong Two requires the use of the considerations (e.g. improving technology, effecting a particular treatment or prophylaxis, implementing with a particular machine, etc.) identified by the Supreme Court and the Federal Circuit, to ensure that the claim as a whole ‘integrates [the] judicial exception into a practical application [that] will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception.’ In the instant case, the claims include additional elements. While these elements are recited, they are merely peripherally incorporated in order to implement the abstract idea. Put another way, these additional elements are merely used to apply the abstract idea of providing bundled product transactions in a technological environment without effectuating any improvement or change to the functioning of the additional elements or other technology. Applicant’s disclosure does not articulate or suggest how these additional elements function, individually or in combination, in any manner other than using generic functionality nor does the disclosure articulate how the elements provide a technical improvement. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they merely amount to using the software architecture as a tool to perform the abstract idea.
35 U.S.C. § 102/103
Applicant argues the claims are allowable because the cited art fails to disclose “storing, by the server, a PurchaseOfferFinancialSettlement object associated with each user account involved in the transaction, the PurchaseOfferFinancialSettlement object storing financial trade value debit and credit from an associated order, and a PurchaseOfferItem object for each item, the PurchaseOfferItem object storing a unit sale price and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace, wherein, when a foreign-key to the PurchaseOfferFinancialSettlement object is present, settlement of orders bypasses conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order” (Remarks pages 10-12). The examiner disagrees. Initially, it is noted that the amendments have necessitated a new grounds of rejection and new references have been cited to teach storing financial trade value debit and credit from an order and a unit commission basis unit price to track item offer pricing to an end user versus a calculated commission basis price for the marketplace; and when a foreign-key to the PurchaseOfferFinancialSettlement object is present, settlement. Further, it is noted with respect to the method claim that “when a foreign-key to the PurchaseOfferFinancialSettlement object is present, settlement of orders bypasses conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order” is a conditional limitation and is thus granted little to no patentable weight in the method claim. Further, Spaulding discloses storing, by the server, a PurchaseOfferFinancialSettlement object associated with each user account involved in the transaction, the PurchaseOfferFinancialSettlement object storing an associated order. Spaulding discloses this at least in [0041-0042] and Fig. 3, disclosing a database may include data associated with trades and users, where data associated with trades may include trade status such as completed trades. Spaulding further discloses and a PurchaseOfferItem object for each item, the PurchaseOfferItem object storing a unit sale price at least in [0057] disclosing that a user may input the value of an item for trade and this is stored in a database. Additionally, Spaulding discloses wherein settlement of orders bypasses conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order at least in [0055] disclosing that a user may associate information with multiple items that a user owns and combine the items in order to generate a higher total approximate value. For example, if a wants an item with an approximate value of $20,000 and owns one item with an approximate value of $15,000 and owns a second item with an approximate value of $5,000, the user may be able to indicate that both of the items be included for a possible transaction with another user. It is noted that, consistent with Specification [0005], the examiner interprets settling via trading to be bypassing conventional settlement based on merchandise cost, tax, and shipping by accounting for trade credits in a corresponding trade order. Thus, the cited art teaches this limitation in these claims.
Applicant argues the claims are allowable because the cited art fails to disclose “upon acceptance of the bundled purchase offer, locking, by the server, related inventory items while the transaction is pending” (Remarks pages 10-12). The examiner disagrees. Initially, it is noted that the amendments have necessitated a new grounds of rejection and new references have been cited to teach locking related inventory items. Further, it is noted with respect to the method claim that this limitation is a conditional limitation and is accordingly granted little to no patentable weight in the method claim. Additionally, Spaulding discloses upon acceptance of the bundled purchase offer, while the transaction is pending at least in [0048], disclosing active and completed trade statuses where an active status may indicate that a user has committed to a trade and/or a portion of a trade has been completed (e.g., one out of two items exchanged). A completed status may indicate that a trade has been completed (e.g., all items exchanged). Thus the cited art teaches this limitation in these claims.
Applicant argues the dependent claims are allowable for the same reasons as the independent claims (Remarks pages 12-14). The examiner disagrees. The 103 rejections of the independent claims have been maintained for the reasons discussed in the 103 rejection and response to remarks paragraphs above. The rejections of the dependent claims are maintained for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
NPL Reference U, initially cited in the Office action dated 03/27/2026, teaches an online peer-to-peer bartering systems. Users may negotiate for goods. Alternative trades may be proposed. Exchanges can be made without money.
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 concerning this communication or earlier communications from the examiner should be directed to ANNA MAE MITROS whose telephone number is (571)272-3969. The examiner can normally be reached Monday-Friday from 9:30-6.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Marissa Thein can be reached at 571-272-6764. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANNA MAE MITROS/Examiner, Art Unit 3689
Prosecution Insights