DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/5/2026 has been entered. Claims 1, 6, and 7 are amended. Claims 3, 9, and 13 are cancelled. Claims 1, 2, 4-8, 10-12, 14-22 are pending and have been rejected as follows.
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.
Step 1: The claims 1-2, 5, 16, 19, and 20 are a system, claims 6, 8, 10, 11, 17, and 21 are a method, and claims 7, 12, 14, 15, 18, and 22 are a computer readable medium. Thus, each independent claim, on its face, is directed to one of the statutory categories of 35 U.S.C. §101. However, the claims 1, 2, 4, 5, 6, 7, 8, 10, 11, 12, 14, 15, 16, 17, 18, 19, and 20-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2A Prong 1: The independent claims (1, 6 and 7 taking claim 1 as a representative claim) recite:
A real-time product exchange system, comprising:
one or more first computing devices at one or more purchasers one or more second computing devices at one or more suppliers and one or more servers comprising a network interface connected to the one or more first computing devices and the one or more second computing devices, a storage, and one or more processors configured to:
receive purchase requests from the one or more first computing devices over a network, each purchase request including a bidding price for a first product, a first identification code identifying the first product, and delivery destination information, wherein the bidding price includes a shipping cost for delivering the first product;
reserve, from a corresponding purchaser's account, a value determined based on the bidding price included in the purchase request after reserving the value, store the received purchase requests in a request queue;
receive sales requests from the one or more second computing devices over the network, each sales request including an asking price for a second product and a second identification code to identify the second product;
store the received sales requests in the request queue algorithmically calculate the shipping cost for delivering the first product based on a shipping cost definition and a distance, based on the delivery destination information in each purchase request; and
determine a matching of the purchase request and the sales request among the purchase requests and the sales requests that match each other regarding (i) the bidding price and a sum of the asking price and the corresponding shipping cost and (ii) a product identified by the first identification code and the second identification code; and
provide a visual representation of respective price distributions of the purchase requests in the request queue
wherein: the first identification code and the second identification code are within a code system used for identifying products among a plurality of countries, the code system having standardized external interoperability, the determination of the purchase request and the sales request starts when the purchase request or the sales request is added to the request queue or when the purchase request or the sales request stored in the request queue is updated, and the determination of the purchase request and the sales request comprises:
setting, when the purchase request is added or when the purchase request is updated, the added or updated purchase request as a matching target purchase request and comparing the matching target purchase request and a candidate sales request, and
setting, when the sales request is added or when the sales request is updated, the added or updated sales request as a matching target sales request and comparing the matching sales request and a candidate purchase request.
These limitations, except for the italicized portions, under their broadest reasonable interpretations, recite certain methods of organizing human activity for managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) as well as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). The claimed invention recites steps for matching purchase and sales requests based on asking price, the sum of the suggested sales price and shipping price, and identification codes of the products. Once matched, setting the request as a match candidate request. The steps under its broadest reasonable interpretation specifically fall under sales activities. The Examiner notes that although the claim limitations are summarized, the analysis regarding subject matter eligibility considers the entirety of the claim and all of the claim elements individually, as a whole, and in ordered combination.
Prong 2: This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of
A real-time product exchange system, comprising: one or more first computing devices at one or more purchasers one or more second computing devices at one or more suppliers and one or more servers comprising a network interface connected to the one or more first computing devices and the one or more second computing devices, a storage, and one or more processors configured to:
(claim 1)
A real-time product transaction method comprising: (claim 6)
A non-transitory storage medium storing thereon a real-time product exchange program causing one or more processors to perform: (claim 7)
one or more first computing devices over a network,
the one or more second computing devices over the network
The additional elements emphasized above are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of processing data) such that it amounts no more than mere instructions to apply the exception using a generic computer component. The limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application – MPEP 2106.05(f).
Accordingly, these additional elements when considered individually or as a whole do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The independent claims are directed to an abstract idea.
Step 2B: The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A Prong two, the additional elements in the claims amount to no more than mere instructions to apply the judicial exception using a generic computer component.
Dependent claims 2, 4, 5, 8, 10, 11, 12, 14, 15, 16, 17, 18, 19, and 20-22 when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitations fail to establish that the claims are not directed to the same abstract idea of Independent Claims 1, 6 and 7 without significantly more.
Claim 2 recites the storage comprises a request queue for temporarily storing the purchase requests and the sales requests. The limitations merely further limits the abstract idea and does not recite additional elements that integrate the judicial exception into a practical application.
Claim 4 recites wherein the one or more processors are further programmed to: manage an economic value held by each of the purchaser and the supplier. The limitations merely further limits the abstract idea and does not recite additional elements that integrate the judicial exception into a practical application.
Claim 5 recites wherein the one or more processors are further configured to collect a usage fee from the purchaser's account corresponding to the purchase request when the matching of the purchase request and the sales request is determined. The limitations merely further limits the abstract idea and does not recite additional elements that integrate the judicial exception into a practical application.
Claim 16 recites wherein the purchase request is generated without referring to a database that manages product information. The limitations merely further limits the abstract idea and does not recite additional elements that integrate the judicial exception into a practical application.
Claim 19 recites wherein the one or more processors are further configured to automatically provide a supplier corresponding to the sales request of matched pair of a sales request and a purchase request with the delivery destination information corresponding to the purchase request of the matched pair. The limitations merely further limits the abstract idea and does not recite additional elements that integrate the judicial exception into a practical application.
Claim 20 recites wherein the one or more processors are further configured to remove from the request queue the matched sales request and purchase request as candidates, change a status of each of the matched sales request and the matched purchase request to a status of waiting for completion of delivery. The limitations merely further limits the abstract idea and does not recite additional elements that integrate the judicial exception into a practical application.
Claim 8, 10, 11, 12, 14, 15, 17, 18, 19, 21, and 22 recite parallel claim language and are rejected for the reasons set forth above. For these reasons claims 1, 2, 4, 5, 6, 7, 8, 10, 11, 12, 14, 15, 16, 17, 18, 19, and 20-22 are rejected under 35 U.S.C. 101.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claims 1, 2, 4, 5, 6, 7, 8, 10, 11, 12, 14, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Greak (US 20050289039) in view of Geva (US 10817522) in further view of Pappas (US 20080215495).
Regarding claims 1, 6, and 7, Greak discloses:
A real-time product exchange system, comprising: one or more first computing devices at one or more purchasers one or more second computing devices at one or more suppliers and one or more servers comprising a network interface connected to the one or more first computing devices and the one or more second computing devices, a storage, and one or more processors configured to: (claim 1) (Figure 1 computer 11, processor 12, memory device 14)
A real-time product transaction method comprising: (claim 6)
A non-transitory storage medium storing thereon a real-time product exchange program the product transaction program causing one or more processors to perform: (claim 7) (Figure 1 computer 11, processor 12, memory device 14)
receive purchase requests from the one or more first computing devices over a network (purchase request record 132), each purchase request including a bidding price (pricing data 184) for a first products a first identification code identifying the first product (a listing identifier 182) and delivery destination information (shipping data 194), wherein the bidding price includes a shipping cost for delivering the first product ([0319] This may require that the purchase request record 132 have an offering price equal to or higher than the asking price of the product record 134. The criteria may include transaction costs such as shipping or funds transfer fees.);
receive sales requests from the one or more second computing devices one or more suppliers over the network (seller workstation 80 and product record 134), each sales request including an asking price for a second product ([0159] A product record 134 may include pricing data 220.) and a second identification code to identify the second product ([0150] A product record 134 may include a listing identifier 212. A listing identifier 212 may uniquely identify a product. A listing identifier 212 may be assigned based on the model number and manufacturer or a product or other information that distinguishes a product from other products.);
store the received sales requests in the request queue (Listing Record 262 in Listing Database 252);
algorithmically calculate the shipping cost for delivering the first product based on a shipping cost definition and a distance based on the delivery destination information in each purchase request; and ([0219] Referring to FIG. 17, a cost calculation module 290 may calculate the costs associated with a transaction between a seller at a seller workstation 80 and a buyer at a buyer work station 82. The cost calculation module 290 may include a shipping cost module 330. The shipping cost module 330 may calculate the cost of shipping a product from the user associated with a product record 134 to a user associated with a purchase request record 132. The shipping cost module 330may calculate the shipping cost based on the weight and size of the product being shipped as well as on the addresses and carrier options stored in the shipment data 158 of the user records 130 associated with the buyer and the seller. and [0117] A user record 130 may include shipment data 158. Shipment data 158 may indicate a postal address, or the like, for the shipment of products and information. Shipment data may also be used to calculate shipping costs for a particular transaction. The shipment data 158 may also indicate what method of shipment is to be used.)
determine a matching of the purchase request and the sales request among the purchase requests and the sales requests that match each other ([0228] The matching module 340 may match records 130,134 with one another only where the pricing data 189, 220 is identical, or may match records 130, 134 when the pricing data 189, 220 are within a certain tolerance of one another.)
regarding (i) the bidding price and a sum of the suggested asking price and the corresponding shipping cost ([0319] This may require that the purchase request record 132 have an offering price equal to or higher than the asking price of the product record 134. The criteria may include transaction costs such as shipping or funds transfer fees.) and ii a product identified by the first identification code and the second identification code (a listing identifier 182) ;
And wherein: the first identification code and the second identification code are within a code system used for identifying products (listing identifier 182; see [0134] and [0150])
the determination of the purchase request and the sales request starts when the purchase request or the sales request is added to the request queue or when the purchase request or the sales request stored in the request queue is updated, and [0177] In another example, a purchase request record 132 or product record 134 may be created in response to the matching, expiration, or removal of another purchase request record 132 or a product record 134. And see [0169]
the determination of the purchase request and the sales request comprises: setting, when the purchase request is added or when the purchase request is updated, the added or updated purchase request as a matching target purchase request and comparing the matching target purchase request and a candidate sales request, and setting, when the sales request is added or when the sales request is updated, the added or updated sales request as a matching target sales request and comparing the matching sales request and a candidate purchase request. [0027] The matching module 340 may search through purchase request records 132 and product records 134 and identify purchase request records 132 that have met criteria specified in a product record 134. For example, the matching module 340 may match a purchase request record 132 with a product record 134 based on the pricing data 184 of the purchase request 130 and the pricing data 220 of the product record 134. [0238]The buyer notification module 342 may notify a buyer that the matching module has matched a purchase request record 132 created by the buyer with a product record 134.
provide a visual representation of respective price distributions of the purchase requests in the request queue (shown as Price over Time in Figure 16 and [0213] In some embodiments a user at a workstation 80, 82 may be presented a user interface 324 as illustrated. The interface 324 may include a plurality of user interface elements 325a-325q. For example, the interface 324 may include the product name 325a, or other identifying information 325a indicating the product, or listing 262, to which information in displayed in the interface 324 relates. The interface 324 may include a last sale price 325b indicating the price and quantity most recently sold, a lowest sell order 325c indicating the price and quantity of the lowest priced product record 134, a highest buy order price 325c indicating the price and quantity of the highest priced purchase request record 132, and shipping cost 325d indicating how much buying a unit of the product of the lowest priced product record 134 will cost for shipping. The interface 324 may include a graph 325e indicating the sales price history. Also discussed in [0214-0218].
While Greak discloses the process for matching the purchase request to a product record based on a set of identifying information, the reference does not explicitly disclose:
reserve, from a corresponding purchaser's account, a value determined based on the bidding price included in the purchase request; after reserving the value, store the received purchase requests in a request queue;
a code system used for identifying products among a plurality of countries, the code system having standardized external interoperability
Hoever Geva teaches:
a code system used for identifying products among a plurality of countries, the code system having standardized external interoperability [Col. 14 lines 28-35] The product description attributes in attribute sections 206 may include globally recognized unique identifiers, such as universal product code (UPC), International article number (EAN), global trade item number (GTIN) or International Standard Book Number (ISBN) and/or non-unique identifiers, such as model names or other identifiers, manufacturer, brand, product line, web-site internal identifiers, supplier identifiers and manufacturer identifiers.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the identification information in Greak to include a code system used for identifying products among a plurality of countries, the code system having standardized external interoperability, as taught in Geva, in order to provide quick and simpler attribute comparison to match products with product records (Col. 14 lines 45-60).
While Greak discloses the process for matching the purchase request to a product record based on a set of identifying information and Geva teaches a code system for identifying products matching product records, the references do not explicitly disclose:
reserve, from a corresponding purchaser's account, a value determined based on the bidding price included in the purchase request; after reserving the value, store the received purchase requests in a request queue;
However Pappas teaches:
reserve, from a corresponding purchaser's account, a value determined based on the bidding price included in the purchase request; after reserving the value, store the received purchase requests in a request queue; [0075] In one embodiment, buy and sell offers for electronic options are recorded for use in keeping track of current and former price and status of all electronic options. And see (see example scenario in [0069-0071] for reserve value and see Figure 4A and 4C)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction of Greak in view of Geva to include reserve, from a corresponding purchaser's account, a value determined based on the bidding price included in the purchase request; after reserving the value, store the received purchase requests in a request queue, as taught in Pappas, in order to allow a customer to lock in a favorable price (paragraph 004).
Regarding claims 2, 8 and 12, Greak in view of Geva in further Pappas teaches the limitations set forth above. Greak further discloses:
wherein: the storage comprises a request queue for temporarily storing the purchase requests and the sales requests. [0273] The archiving module 298 may include an updating module 422. The updating module 422 may update the transaction database 106 once the matching module 340 has identified a purchase request record 132 and a product record 134 that match. The updating module 422 may remove the matched records 132, 134 from the transaction database 106, so the matching module 340 will not subsequently match one of the matched record 132,134 with another record 134, 132. In some embodiments, the updating module 422 may simply mark or otherwise indicate that a record 132, 134 is no longer available to be matched while leaving the record 132, 134 stored in the transaction database 106.
Regarding claim 4, 10, and 14, Greak in view of Geva in further Pappas teaches the limitations set forth above. While the combination teaches the facilitation of executing a purchase request for the product, the reference does not expressly disclose:
wherein the one or more processors are further programmed to: manage an economic value held by each of the purchaser and the supplier.
However Pappas teaches
wherein the one or more processors are further programmed to: manage an economic value held by each of the purchaser and the supplier. (see example scenario in [0069-0071] and see Figure 4A and 4C)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction of Greak in view of Geva to include wherein the one or more processors are further programmed to: manage an economic value held by each of the purchaser and the supplier, and reserve a value determined based on the asking purchase price included in the purchase request from a corresponding purchaser's account, as taught in Pappas, in order to allow a customer to lock in a favorable price (paragraph 004).
Regarding claim 5, 11, and 15, Greak in view of Geva in further Pappas teaches the limitations set forth above. Greak further discloses:
wherein the one or more processors are further programmed to collect a usage fee from the purchaser's account corresponding to the purchase request when the matching of the purchase request and the sales request is determined. [0243] Fees assessed may include a transaction fee that is either fixed or a function of the purchase price. For example, a transaction fee charged by a host may be a log(X)/X function where X is the purchase price. And see [0235]
Regarding claim 19, Greak in view of Geva in further Pappas teaches the limitations set forth above. Greak further discloses:
wherein the one or more processors are further configured to automatically provide a supplier corresponding to the sales request of matched pair of a sales request and a purchase request with the delivery destination information corresponding to the purchase request of the matched pair. [0140] A purchase request 132 may include shipping data 194. Shipping data 194 may include an address or like information sufficient to allow a sender to ship a package to the user identified by the buyer identifier 192. Shipping data 194 may also indicate the shipping method to be used (e.g. air, ground, FEDEX, or other courier).
Claims 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Greak (US 20050289039) in view of Geva (US 10817522) in view of Pappas (US 20080215495) in further view of Bishop (US 20080086392).
Regarding claim 16, 17, and 18, Greak in view of Geva in further Pappas teaches the limitations set forth above. While the combination teaches the facilitation of executing a purchase request for the product, the reference does not expressly disclose:
wherein the purchase request is generated without referring to a database that manages product information.
However Bishop teaches:
wherein the purchase request is generated without referring to a database that manages product information. (automated purchase request for replenishment see [008], [0020], [0021])
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction of Greak in view of Geva in further view of Pappas to include wherein the purchase request is generated without referring to a database that manages product information, as taught in Bishop, in order to ensure effective inventory of products (paragraph 0021).
Claims 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over Greak (US 20050289039) in view of Geva (US 10817522) in view of Pappas (US 20080215495) in further view of Katakawa (US 20150356654).
Regarding claims 20-22, Greak in view of Geva in further view of Pappas teaches the limitations set forth above. Greak further discloses:
wherein the one or more processors are further configured to remove from the request queue the matched sales request and purchase request as the candidates, and change a status of each of the matched sales request and the matched purchase request. […] [0273] The archiving module 298 may include an updating module 422. The updating module 422 may update the transaction database 106 once the matching module 340 has identified a purchase request record 132 and a product record 134 that match. The updating module 422 may remove the matched records 132, 134 from the transaction database 106, so the matching module 340 will not subsequently match one of the matched record 132,134 with another record 134, 132. In some embodiments, the updating module 422 may simply mark or otherwise indicate that a record 132, 134 is no longer available to be matched while leaving the record 132, 134 stored in the transaction database 106.
While Greak teaches the removal of a matched record from the database and the item is them prepared for shipment, Greak in view of Geva in further view of Pappas does not expressly disclose
[…] changing […] to a status of waiting for completion of delivery.
However Katakawa teaches:
[…] changing […] to a status of waiting for completion of delivery. [0125]The status controller 144 that has received the shipping status update request changes the shipping status to “waiting to be shipped” (Step S49), and sends a completion response to the store terminal 2. Then, the store terminal 2 changes the shipping status on the received order management page to “waiting to be shipped”. FIG. 15B shows a display example of the received order list page after the shipping status is updated to “waiting to be shipped”.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction process of Greak in view of Geva in further view of Pappas to include […] changing […] to a status of waiting for completion of delivery, as taught in Katakawa, in order to provide as easy to follow procedure of executing the order and shipping transaction (paragraph 006).
Relevant Art Not Cited
Pritikin (US 20110082771) discloses the process of removing orders from a queue and modifying and executing the auto-shipment procedure based on a set of parameters.
Response to Arguments
Applicant's arguments filed 2/5/2026 have been fully considered but they are not persuasive.
With respect to the remarks directed to 35 USC 101, the examiner asserts the claims do still recite an abstract idea. The addition of the limitation “provide a visual representation of respective price distributions of the purchase requests in the request queue” merely provides the output of results from the abstract idea and thereby is part of the abstract idea. The examiner does not agree that the added language is an additional element. Further those limitations of “A real-time product exchange system, comprising: one or more first computing devices at one or more purchasers; one or more second computing devices at one or more suppliers; and one or more servers comprising a network interface connected to the one or more first computing devices and the one or more second computing devices ...reserve, from a corresponding purchaser's account, a value determined based on the bidding price included in the purchase request; [and] the first identification code and the second identification code are within a code system used for identifying products among a plurality of countries, the code system having standardized external interoperability" and now further "providing a visual representation of respective price distributions of the purchase requests in the request queue." indicated in the remarks as additional elements are not additional elements and do recite sales activities. This is shown in the 101 analysis above. The elements of the A real-time product exchange system, comprising: one or more first computing devices at one or more purchasers one or more second computing devices at one or more suppliers and one or more servers comprising a network interface connected to the one or more first computing devices and the one or more second computing devices, a storage, and one or more processors configured to: (claim 1); A real-time product transaction method comprising: (claim 6); A non-transitory storage medium storing thereon a real-time product exchange program causing one or more processors to perform: (claim 7); one or more first computing devices over a network, the one or more second computing devices over the network are the only additional elements recited in the claims. These are recited are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of processing data) such that it amounts no more than mere instructions to apply the exception using a generic computer component. The limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application – MPEP 2106.05(f)
With respect to the remarks directed to the alleged non-obvious improvements. The examiner first asserts per MPEP 2106.05 Although the courts often evaluate considerations such as the conventionality of an additional element in the eligibility analysis, the search for an inventive concept should not be confused with a novelty or non-obviousness determination. … In addition, the search for an inventive concept is different from an obviousness analysis under 35 U.S.C. 103. See, e.g., BASCOM Global Internet v. AT&T Mobility LLC, 827 F.3d 1341, 1350, 119 USPQ2d 1236, 1242 (Fed. Cir. 2016) ("The inventive concept inquiry requires more than recognizing that each claim element, by itself, was known in the art. . . . [A]n inventive concept can be found in the non-conventional and non-generic arrangement of known, conventional pieces."). Specifically, lack of novelty under 35 U.S.C. 102 or obviousness under 35 U.S.C. 103 of a claimed invention does not necessarily indicate that additional elements are well-understood, routine, conventional elements. Because they are separate and distinct requirements from eligibility, patentability of the claimed invention under 35 U.S.C. 102 and 103 with respect to the prior art is neither required for, nor a guarantee of, patent eligibility under 35 U.S.C. 101. The distinction between eligibility (under 35 U.S.C. 101 ) and patentability over the art (under 35 U.S.C. 102 and/or 103 ) is further discussed in MPEP § 2106.05(d). Thereby, the consideration of a non-obvious arrangement is not persuasive.
With respect to the cited PTAB decision, the examiner asserts this is a non-precedential decision and the examiner does not find the fact pattern of the cited PTAB decision to follow the same fact pattern of the instant application. The remarks are not found to be persuasive. The examiner continues to follow the guidance set for in the MPEP 2106 in the analysis above.
With respect to the remarks directed to the “apply it” consideration, the examiner asserts that the details of how the product exchange system matches the requests lies in the abstract idea and not in the additional elements (step 2A prong 2). Therefore, these limitations do not integrate the judicial exception into a practical application. The output of the visualization now claimed, again, is part of the abstract idea and not an additional element. Thereby, the consideration under prong 2 is moot.
With respect to the remarks directed to reduced computing resources, the examiner asserts that even if the claimed invention reduced the resources needed by the computer, the result is merely a consequence of the abstract idea. That it, the claimed limitations that are part of the abstract idea, improve the abstract idea and therefore consequentially require less computer resources. The claimed invention is not improving the computer technology itself and thereby improving the manner in which the computer technology operates. Less data or better data to input into the process requiring less computational resources is not an integration into a practical application.
Lastly, the implementation in real time of the claimed invention does not integrate the judicial exception into a practical application. In the claimed invention, real time is a result of carrying out the abstract idea on a computer platform, rather than manually performing the process. The real time operation is therefore merely a consequence of using the computer tool to implement the abstract idea and not an integration into a practical application.
With respect to the prior art rejections, the rejections are maintained. The amended language is shown in at least Figure 16 of the Greak reference showing the price over time of the product sales/requests. The remarks only conclusory state that the combination of references could not teach the claim limitations without particularly pointing out the difference of the claimed invention and the combination of prior art. The remarks are not found to be persuasive.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VICTORIA E. FRUNZI whose telephone number is (571)270-1031. The examiner can normally be reached Monday- Friday 7-4 (EST).
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.
VICTORIA E. FRUNZI
Primary Examiner
Art Unit TC 3689
/VICTORIA E. FRUNZI/Primary Examiner, Art Unit 3689 3/18/2026