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 .
The following is a Final Office Action in response to communications received on 6/18/2026. Claims 1-2, 4-8, 10-12, 14-22 are currently pending and have been examined. Claims 3, 9, and 13 have been cancelled. Claims 1, 6, and 7 have been amended.
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, 4, 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:
store, in the storage, a table in which a meta product identification number indicating a meta product is associated with identification numbers indicating each of one or more specific products included in the meta product;
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) when the purchase request includes the first identification code, a product identified by the first identification code and the second identification code, and when the purchase request includes the meta product identification number, a product identified by the second identification code that corresponds to one of the identification numbers associated with the meta product identification number in the table;
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
store in storage […]
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)
store, in the storage (listing database 252), a table in which a meta product identification number indicating a meta product is associated with identification numbers indicating each of one or more specific products included in the meta product; [0151] Alternatively, products may be identified in terms of common functionality. Accordingly, the listing identifier 212 may uniquely identify a narrow class of goods. A listing identifier 212 may simply be descriptive in nature. For example, a single listing identifier 212 may be assigned to all twenty-Gigabyte hard drives or drives near that range.
Examiner note: “a meta product identification number” has been interpreted as the product identification number indicating the meta product based on [0139] in the specification. [0139] states “When the meta product is managed on the management server 100 side, a table in which the product identification number indicating the meta product is associated with the product identification number indicating each of specific one or more products included in the meta product may be stored.” The specification does not expressly name a third identifier of the “a meta product identification number” but rather meta product representing a group of products, like that of the classes and sub classes associated with the listing identifier in the prior art of Greak.
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 (ii) when the purchase request includes the first identification code, a product identified by the first identification code and the second identification code, and when the purchase request includes the meta product identification number, a product identified by the second identification code that corresponds to one of the identification numbers associated with the meta product identification number in the table; and [0172] In some embodiments the transaction system 92 may facilitate the posting of multiple purchase request records 132. For example, a user may be enabled to post a purchase request record 132 for all listings within an entire subclass 268 or class 266 of products. Accordingly, the purchase request record 132 would be matched with any product record 134 within that class 266 or subclass 268. In some embodiments the transaction application may create a purchase request record 132 for each listing within the chosen class 266 or subclass 268. Alternatively, the purchase request record may simply identify the class 266 or subclass 268 in lieu of a listing identifier 182.
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].
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.
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 6/18/2026 have been fully considered but they are not persuasive.
With respect to the remarks directed to 35 USC 101, the examiner has updated the rejection above to address the claim amendments. The examiner asserts that the use of meta product information does not provide a technical solution to a technical problem. At most the improvement lies in the abstract idea. The reduction in data in the request queue is merely consequential to the reduction in information required to be processed by the computer. That is to say, if less information is input then by consequence, less information would be required to be processed. It is not an improvement to the computer operations themselves. Additionally with respect to the remarks directed to the Desjardins decision, as stated above, the improvement at most lies in the abstract idea and not in improving the computer itself and therefore the comparison to Desjardins is not persuasive. As to the Mirza decision, the examiner first asserts the decision is neither precedential nor informative. As to the facts of the decision, the PTAB determined there was a technical solution to a technical problem specific to that of electronic trading systems recited in the claims. As shown in the decision, the electronic trading systems had a technical problem of carrying data for extended durations based on the needs of the contract system and therefore there was a need to reduce the load on the systems. In contrast, the instant applications organization of data in the recited table structures merely condenses the data in manner that consequential requires fewer computing sources of the computer and this could be applied in any field and not a unique solution to a particular technical system (i.e. exchange computing systems). For the reasons discussed above, the examiner asserts that claims still recite the computer elements at the apply it level and when considered alone and in combination do not integrate the judicial exception into a practical application. The elements of the matching requests within the product exchange, how the table and meta product identification are stored, and the presentation of the information are all part of the abstract idea and do not integrate the judicial exception into a practical application. Lastly, the examiner asserts that the test for pre-emption is not a standalone test and while part of the consideration under 35 USC 101, the claims remain rejected for the reasons set forth above in concert with the consideration of the pre-emption (MPEP 2106.07(b)).
With respect to the remarks directed to 35 USC 103, the examiner asserts the Greak reference does teach the claims as amended. As shown in the rejection above, in [0151] Alternatively, products may be identified in terms of common functionality. Accordingly, the listing identifier 212 may uniquely identify a narrow class of goods. A listing identifier 212 may simply be descriptive in nature. For example, a single listing identifier 212 may be assigned to all twenty-Gigabyte hard drives or drives near that range. The examiner notes “a meta product identification number” has been interpreted as the product identification number indicating the meta product based on [0139] in the specification. [0139] states “When the meta product is managed on the management server 100 side, a table in which the product identification number indicating the meta product is associated with the product identification number indicating each of specific one or more products included in the meta product may be stored.” The specification does not expressly name a third identifier of the “a meta product identification number” but rather meta product representing a group of products, like that of the classes and sub classes associated with the listing identifier in the prior art of Greak. Based on this interpretation, the examiner also finds the Greak reference to teach the determining step as Greak teaches [0172] In some embodiments the transaction system 92 may facilitate the posting of multiple purchase request records 132. For example, a user may be enabled to post a purchase request record 132 for all listings within an entire subclass 268 or class 266 of products. Accordingly, the purchase request record 132 would be matched with any product record 134 within that class 266 or subclass 268. In some embodiments the transaction application may create a purchase request record 132 for each listing within the chosen class 266 or subclass 268. Alternatively, the purchase request record may simply identify the class 266 or subclass 268 in lieu of a listing identifier 182. Based on the claim interpretation in light of the specification, the previous combination of prior art is maintained.
For these reasons all pending claims remain rejected under 35 USC 101 and 103.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry 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 8/28/2026
Prosecution Insights