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 .
Status of Claims
This Office action is in response to correspondence received February 12, 2026.
Claim 1 is amended. Claims 1-2 are pending and have been examined.
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 February 12, 2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-2 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Per claim 1, the following is new matter.
Applicant claims: recording, in the block chain, the lender information using a hash function,
Applicant cites support as follows:
(Paragraphs from published application):
Par 029: At step SS1, to receive the provision of the present service, the lending user UL operates the lender terminal 2 to apply, to the service provider M, user registration to the present service. As the service provider M receives the application from the lending user UL, the service provider M registers individual information of the lending user UL in the block chain B, and notifies, to the lending user UL, that the registration has been completed.
Par 027: the block chain B causes pieces of data such as transaction information to be synchronized with each other and records the synchronized pieces of data. In a case of the block chain B, pieces of transaction data acquired in a certain period of time are gathered with each other in a unit of block, the computers together evaluate the pieces of transaction data, and correct records are coupled to each other to form a chain, for example, and are accumulated…. In the block chain B, units of data called blocks are generated, and the units are coupled to each other in a chronological order to form a chain, for example, to serve as a database. Each block has a hash value (a value calculated using a hash function) of a previous block coupled to the block. By tracing back the hash values, it is possible to know how the blocks are coupled to each other. When there has been an attempt of falsifying a piece of information in a block generated in the past, which is managed in the block chain B, a hash value calculated from the block in which there is a change differs from the hash value of the previous block, resulting in that hash values in all the subsequent blocks need to be changed. However, it is difficult to change hash values in all the subsequent blocks in fact. Therefore, there is taken a falsification prevention measure.
Par 076: “In the block chain B, information regarding users having undergone user registration to the present service (the lending users UL and the borrowing users UB) (hereinafter referred to as the “user information 401”) is stored and managed. The user information includes information uniquely identifying the users having undergone user registration to the present service (for example, identification information) and information including their names, addresses, contact information, ownership change history, and reviews by other users. Such history information as described below may be integrated with the user information 401, and the integrated information may be managed.”
However, there is nothing shown that the lender information is recorded in the blockchain using a hash function. Only that in par 027 each block has a hash value, a value calculated using a hash function. The recordation step is not connected to the hash value element. Because there is no specific support for recording the lender information in a blockchain with a hash function, this is new matter.
Per limitation recording, in the block chain, the offer information using the hash function and in response to determining that the offer application corresponds to the first user, Applicant cites the same paragraph, par 027, as was cited for the specific support for recording lending information in the blockchain. However, nowhere in par 027 is the hash function connected to recordation.
Therefore, this is new matter.
Per the limitation recording, in the block chain, the user information using a hash function, par 027 is used as it was previously. But, as par 027 only recites that blocks have hash values, there is no teaching that the user information is recorded in the block chain using a hash function. Therefore, this is new matter.
Per the limitation, displaying, within a graphical user interface on the borrower terminal, a plurality of offered items in the block chain, Fig. 6 is cited, Par 015 is cited, as well as pars 089-090. However, nowhere describing Fig. 6 are the offered items in Fig. 6 described as in the blockchain, and nowhere are the item numbers from the blockchain described as the item numbers in Fig. 6. Therefore, while Fig. 6 describes offered items, it does not link them to the block chain. Par 077 describes offered items in the block chain, but does not describe that they are displayed, just that information about offered items is stored in the block chain. But, there is nothing linking the teaching of offered item information stored in par 077, in the blockchain, with the display of that information. For instance, the offer information in the blockchain is given an item number, item 402. But, that item is not referred to in any description of Fig. 6. Therefore, it is not clear that item 402 (the teaching of offer information stored in the blockchain) is then displayed in Fig. 6.
A review of Pars 084-089 shows no connection to the blockchain. Note that Par 084 starts, “Next, specific examples of operations to offer an item or to make a borrow application will now be described herein with reference to FIGS. 6 to 11. FIG. 6 is a view illustrating an example case of making a borrow application via a GUI displayed on each of the lender terminals 2 and the borrower terminals 3.” No reference to Item number 402 or blockchain is present. Therefore when the generic term “offer information is used in these paragraphs it is in reference to the “captured images of men’s jackets” see par 089.
Therefore, this is new matter.
Per the limitation, receiving, from the borrower terminal, a borrow application for a predetermined item in response to displaying the plurality of offered items within the graphical user interface, Applicant cites par 0158, par 078, and par 015. However, here the receiving of the borrow application must happen in response to displaying the plurality of offered items within the graphical user interface and nowhere is this described that 1) the plurality of offered items is displayed and then in response to this, the borrow application is received for a predetermined item. Therefore, this is new matter.
Per the limitation, receiving, from the block chain, a result of the inquiry indicating that the transaction based on the borrow application is permissible, Applicant cites pars 074, 0157, however there is nothing shown that the result of the inquiry indicating…permissible is received from the block chain. Information is used in the blockchain, see par 0157, “using the rental information in the block chain” but the result of the inquiry is not received from the block chain.
Therefore, this is new matter.
Per the limitation, wherein determining that the transaction is permissible is based on matching the user information in the block chain with transaction history of the offered item and the offer information in the block chain, Applicant cites par 047, 048, and 074. Here three data items must be matched: user information (borrower); “transaction history of the offered item,” (transaction history) and offer information (par 077: “Furthermore, in the block chain B, information regarding the offered items offered in the present service (characteristics, rental prices, and others of the offered items) is stored and managed as the offer information 402.”). However, in par 048 the matching is described in terms of the matching of users (borrower and lender) and in par 074, the matching of the borrower and the transaction history. The matching of the offer information and the user information (borrower) is not described in these paragraphs. Therefore, this is new matter.
Per the limitation, displaying, within a graphical user interface on the borrower terminal and using the block chain, an indication that the borrow application for the offered item is granted in response to the offered item matching the borrow application based on the result of the inquiry, because the limitation is based on a result of the inquiry which comes from the previous limitation where there was insufficient support shown for the different matching elements, (see above), this is also new matter.
Per the limitation, and receiving, from a payment server, a payment indication in response to the borrower terminal transmitting a payment to the payment server, Applicant cites pars 036-037 and Fig. 3. However, in these paragraphs, the borrowing user makes a request “to a payment service provider” (the payment server see par 026, to perform payment processing. There is nothing that describes the borrower terminal transmitting a payment to the payment server, as the payment server is being requested to perform the payment processing. Therefore, this is new matter.
Per the limitation, wherein the payment indication indicates that payment processing is complete for borrowing the offered item by the second user from the first user, pars 036-037 are cited but it is not clear where the indication that payment processing is complete is taught. The payment processing is described but no indication that the payment is complete is taught. Therefore, this is new matter.
Claim 2 is rejected for being dependent on claim 1.
Therefore, claims 1-2 are rejected under 35 USC 112.
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 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s):
receiving a first user registration application associated with a first user, wherein the first user registration application comprises lender information; recording, the lender information wherein receiving, an offer application comprising offer information for an offered item; determining whether the offer application corresponds to the first user based on the lender information recording, , the offer information and in response to determining that the offer application corresponds to the first user; receiving, , a second user registration application associated with a second user, wherein the second user registration application comprises user information; recording, the user information ; [presenting] , a plurality of offered items ; receiving, a borrow application for a predetermined item in response to displaying the plurality of offered items ; transmitting, an inquiry based on whether a transaction is permissible for the offered item between the first user and the second user; receiving, , a result of the inquiry indicating that the transaction based on the borrow application is permissible, wherein determining that the transaction is permissible is based on matching the user information with transaction history of the offered item and the offer information ; an indication that the borrow application for the offered item is granted in response to the offered item matching the borrow application based on the result of the inquiry; and receiving, , a payment indication in response to transmitting a payment, wherein the payment indication indicates that payment processing is complete for borrowing the offered item by the second user from the first user.
The abstract idea, identified above and drawn directly from Applicant’s claim language, is a certain method of organizing human activity – commercial interaction. This is because making payments in order to borrow something is a commercial interaction between two parties. The steps above define how this borrow for money will go. Therefore, as the abstract idea above defines how borrowing for money will take place, claim 1 recites an abstract idea that is a certain method of organizing human activity.
This judicial exception is not integrated into a practical application. The elements alone and in combination are apply it elements because they are instructions to apply the above identified abstract idea to a computer or other machinery. This includes:
Servers, distributed network, blockchain, hash function, terminals, graphical user interfaces.
In combination, Applicant has recited several generic computing devices joined by a network. Servers and “terminals” (generic computing device) on a network are apply it per TLI Communications and Ultramercial, see MPEP 2106.05(f)(2). Blockchain and the related “hash function” is recited in a generic manner and is being used in its ordinary capacity, to store information. The combination of blockchain, hash function, and the generic computing elements amounts to running blockchain on a distributed network, which would be how blockchain is ordinarily used (as opposed to a toy scenario of using it on one computer). Therefore, the combination of elements amounts to a network of computers running blockchain. Further, these elements are recited at a high level of generality which shows that they are intended to be applied to the abstract idea. For these reasons, a practical application of the abstract idea is not recited.
The additional elements of claim 1 are:
A system comprising: a management server communicably coupled to a plurality of computers forming a block chain in a distributed network; a lender terminal communicably coupled to the management server via a network; and a borrower terminal communicably coupled to the management server via the network, wherein the management server is configured to perform a method comprising:
from the lender terminal
in the block chain using a hash function,
the block chain comprises a first block with a first hash value that is generated by the hash function and based on a second block of the block chain;
from the lender terminal/from the borrower terminal
displaying, within a graphical user interface (on the borrower terminal)
to/from/in/using the block chain,
displaying, within a graphical user interface on the borrower terminal
from/to a payment server
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because for the same reason that they are not a practical application, the combination of elements is not significantly more than the abstract idea. This is because apply it limitations alone and in combination are not significantly more than the abstract idea.
Claim 2 further recites recording and managing information about individuals on the blockchain. This further defines the abstract idea of claim 1 (recording and managing information about individuals) and applies the blockchain as “in the blockchain” only recites that somehow the blockchain is involved in this, with no further detail as to how the blockchain is used.
For these reasons, claims 1-2 are rejected under 35 USC 101.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Switzer et al., US PGPUB 20210209518 A1 ("Switzer") in view of Sliwka et al., US PGPUB 20210082044 A1 ("Sliwka").
Per claim 1, Switzer teaches A system comprising: a management server communicably coupled to a plurality of computers forming a block chain in a distributed network in par 15: server; Pars 034-037, Fig 1.
Switzer then teaches a lender terminal communicably coupled to the management server via a network in Par 040 and Item 204, a user device.
Switzer then teaches and a borrower terminal communicably coupled to the management server via the network, wherein the management server is configured to perform a method comprising in par 049: iOT device that accepts the bid.
Switzer then teaches receiving, from the lender terminal, a first user registration application associated with a first user, wherein the first user registration application comprises lender information in par 048: "The controllers record transactions using digital signatures to provide verifiability that a particular controller did indeed create a transaction. An IoT device may be pre-configured to ONLY accept authorized transactions from a particular controller that they are associated with so that the IoT device has a public key for the controller and can verify the controller's digital signatures made with the controller's private key. This way the IoT device only needs to know one public key."
Switzer then teaches recording, in the block chain, the lender information using a hash function, wherein the block chain comprises a first block with a first hash value that is generated by the hash function and based on a second block of the block chain in par 049: "Another blockchain may be designated for granting/recording access rights and access information. The User device 204 may access the controller for the first block chain to get information on availability of rental objects 208. The user device can receive an input from a user which then places a bid. The bid can be accepted by either the IoT device 206 or a manager of the rental object 208 based on the bid. A transaction record is written to a second block chain to record access rights. The IoT device 206 may access the controller 202 to confirm from the second blockchain that the access rights are correct. Based on confirming the access rights, the IoT device 206 can allow access by the user device 204." See par 053 for hash function.
Switzer then teaches receiving, from the lender terminal, an offer application comprising offer information for an offered item in par 44: “In one or more embodiments, the IoT device 206 can be an electronic lock for the rental object 208 that allows access to the rental object 208. The transaction record is stored in the database 210 which can be accessed by the IoT device 206. A customer, once verified by the IoT device 206, can access the rental object 208 (e.g., hotel room or apartment). The IoT device 206 can access the database to obtain transaction record or the IoT device 206 can be sent the transaction record including a customer identity along with reservation information such as rental duration.” See also par 048: “The controllers record transactions using digital signatures to provide verifiability that a particular controller did indeed create a transaction. An IoT device may be pre-configured to ONLY accept authorized transactions from a particular controller that they are associated with so that the IoT device has a public key for the controller and can verify the controller's digital signatures made with the controller's private key. This way the IoT device only needs to know one public key.” See also par 049: “The bid can be accepted by either the IoT device 206 or a manager of the rental object 208 based on the bid. A transaction record is written to a second block chain to record access rights. The IoT device 206 may access the controller 202 to confirm from the second blockchain that the access rights are correct. Based on confirming the access rights, the IoT device 206 can allow access by the user device 204.” See also par 051: “In one or more embodiments, a rental object 208 owner and a potential customer are verified by the database 210 or by a third party verification server prior to gaining access to the database 210. Once verified, an owner 208 can publish rental data to the database 210 regarding one or more rental objects 208 the owner wishes to rent to the public.”
Switzer then teaches determining whether the offer application corresponds to the first user based on the lender information in the block chain in par 051: “In one or more embodiments, a rental object 208 owner and a potential customer are verified by the database 210 or by a third party verification server prior to gaining access to the database 210. Once verified, an owner 208 can publish rental data to the database 210 regarding one or more rental objects 208 the owner wishes to rent to the public.”
Switzer then teaches recording, in the block chain, the offer information using the hash function and in response to determining that the offer application corresponds to the first user in par 42: “The system 200 operates as a peer-to-peer reservation system where users can upload details about rental objects such as availability, location, room type, retail rate, property information, and the like.” See also par 046-047 for using hash function and determining offer application corresponds to the first user.
Switzer then teaches receiving, from the borrower terminal, a second user registration application associated with a second user, wherein the second user registration application comprises user information in par 42: “For the user to search the database 210, the user would utilize a user device 204, such as a smartphone or tablet, and send a request to a controller 202 for access to the rental data stored on the database 210. The request can include authentication information about the user to confirm the identity of the user. Once the user's identity is confirmed, the user can then access the database 210 and search for rental objects 208 (e.g., hotel rooms, rental vehicles, etc.).”
Switzer then teaches recording, in the block chain, the user information using the hash function in par 43: “For example, if a bid for a hotel room is less than the price minimum established by the hotel manager but within a certain threshold, the controller 202 could send the bid information to the manager to override the price minimums included in the rental data about the rental object 208 (i.e., hotel room). When the bid is accepted, a transaction record is generated and stored in the distributed database 210. The transaction record includes the identity of the user along with reservation data associated with the rental object 208.”
Switzer then teaches transmitting, to the block chain, an inquiry based on whether a transaction is permissible for the offered item between the first user and the second user in par 55: “The method 300 includes storing, in a server, a distributed database that includes a plurality of data records, wherein the plurality of data records comprise rental data associated with rental items, as shown in block 302. … At block 312, the method 300 includes receiving, from the requestor, bid data for a first rental location from the plurality of rental locations, wherein the bid data comprises an ask price for the first rental location. And, at block 314, the method 300 includes comparing the ask price to the price minimum associated with the first rental location to determine an action for the first rental location.”
Switzer then teaches receiving, from the block chain, a result of the inquiry indicating that the transaction based on the borrow application is permissible in par 49: “The bid can be accepted by either the IoT device 206 or a manager of the rental object 208 based on the bid. A transaction record is written to a second block chain to record access rights. The IoT device 206 may access the controller 202 to confirm from the second blockchain that the access rights are correct. Based on confirming the access rights, the IoT device 206 can allow access by the user device 204.”
Switzer then teaches wherein determining that the transaction is permissible is based on matching the user information in the block chain with transaction history of the offered item and the offer information in the block chain in par 47: ”Identification and authentication can be done by including identifiers in the blockchain record that indicate who created the record, who provided which part of the record. (i.e., if someone places a bid, who submitted the bid? if someone accepts the bid, who accepted it? if someone included identification information for the guest reserving the hotel room, who is the guest and who submitted the information on behalf of the guest?). Systems that then consume the block chain record would indicate whether additional transactions were done on top. For example, was the payment remitted? Are access rights being granted? Is the reservation bid accepted/rejected? The IoT device or controller 202 can review all of these transaction inputs and verify the identities before allowing access to the rental object 208.”
Switzer then teaches and receiving, from a payment server, a payment indication in response to the borrower terminal transmitting a payment to the payment server in par 43: “The user would then submit payment information to a third party payment server.”
Switzer then teaches wherein the payment indication indicates that payment processing is complete for borrowing the offered item by the second user from the first user in par 43: “Payment can be confirmed by the third party payment server and submitted to the database to be stored in the transaction record or in an additional transaction record.”
Switzer does not teach displaying, within a graphical user interface on the borrower terminal, a plurality of offered items in the block chain; receiving, from the borrower terminal, a borrow application for a predetermined item in response to displaying the plurality of offered items within the graphical user interface; displaying, within a graphical user interface on the borrower terminal and using the block chain, an indication that the borrow application for the offered item is granted in response to the offered item matching the borrow application based on the result of the inquiry.
Sliwka teaches decentralized loan using distributed ledger. See abstract.
Sliwka teaches displaying, within a graphical user interface on the borrower terminal, a plurality of offered items in the block chain in par 97: "] In embodiments, the platform includes or supports a virtual world presence system 114 that provides presents virtual representations of items in virtual world environments. For example, the virtual world presence system 114 may present a virtual reality store to a user, whereby virtual representations of items are presented in the store and users can “shop” for the virtual items in the virtual world environment. In these embodiments, the virtual world presence system 114 may render a virtual world environment, which may be displayed at a client application." Par 94: "In embodiments, the platform 100 includes a transaction system 108 that supports any suitable transactions relating to the platform, including the buying, selling, trading, renting, leasing, exchanging, swapping, transferring, and/or redeeming of tokens that represent corresponding items." Par 038: distributed ledger and blockchain taught. See also par 114, 116.
Sliwka then teaches receiving, from the borrower terminal, a borrow application for a predetermined item in response to displaying the plurality of offered items within the graphical user interface in par 113: “In embodiments, when the consumer elects to purchase an item, the buyer marketplace system 204 may notify the ledger management system 104 regarding the purchase. The buyer marketplace system 204 may provide the ledger management system 104 with the public address of the user and an identifier of the virtual representation of the selected item. The ledger management system 104 may effectuate the transaction by assigning a token from the set of tokens corresponding to the virtual representation to the account associated with the public address of the user and updating the distributed ledger to indicate the change of ownership of the assigned token to the public address of the user.”
Sliwka then teaches displaying, within a graphical user interface on the borrower terminal and using the block chain, an indication that the borrow application for the offered item is granted in response to the offered item matching the borrow application based on the result of the inquiry in par 142: “In this example, the redemption system 404 may email a link to download the digital item to the user's email account or may attach a copy of the digital item in an email that is sent to the user's email account. In another scenario, the user may be redeeming a token corresponding to a physical good (e.g., clothing, food, electronics, etc.) or a physical service (e.g., maid service). In the case of a physical good, the redemption system 404 may determine a workflow for satisfying the physical item. For example, the redemption system 404 may present a GUI to the user that allows the user to enter shipping information of the user. Alternatively, the redemption system 404 may look up the shipping information of the user from, for example, the distributed ledger or a user database. The redemption system 404 may then initiate shipment of the physical good. For example, the redemption system 404 (or a logistics system) may transmit a shipping request to a warehouse that handles shipments of the good indicating the shipping information. The foregoing are examples of how a token may be redeemed”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the blockchain item rental teaching of Switzer with the using a GUI for the borrowing application teaching of Sliwka because one would be motivated to include a GUI in order to facilitate communication between parties. This would enable communication on rentals that facilitates choice by renters and has clear UI that a renter is used to in non blockchain transactions. For these reasons one would be motivated to combine Switzer with Sliwka.
Per claim 2, Switzer and Sliwka teach the limitations of claim 1, above. Switzer further teaches wherein the method further comprises: recording and managing, in the block chain, information regarding individuals who, respectively, are the first user and the second user in par 47: “Identification and authentication can be done by including identifiers in the blockchain record that indicate who created the record, who provided which part of the record. (i.e., if someone places a bid, who submitted the bid? if someone accepts the bid, who accepted it? if someone included identification information for the guest reserving the hotel room, who is the guest and who submitted the information on behalf of the guest?). Systems that then consume the block chain record would indicate whether additional transactions were done on top. For example, was the payment remitted? Are access rights being granted? Is the reservation bid accepted/rejected? The IoT device or controller 202 can review all of these transaction inputs and verify the identities before allowing access to the rental object 208. Verifying identities can include verifying digital signatures that are contained inside of a transaction record that are separate from the actual block-chain mechanism that ensures a transaction record on the chain is kept intact and is verified as being intact.”
See also par 48: “In one or more embodiments, access to the blockchain may be limited to specific controllers 202—in this sense it is a public blockchain but only public to a limited set of controllers who are allowed to record to the blockchain. The controllers are managed by entities in the rental market who know each other and can identify each other by their respective controllers. The controllers record transactions using digital signatures to provide verifiability that a particular controller did indeed create a transaction. An IoT device may be pre-configured to ONLY accept authorized transactions from a particular controller that they are associated with so that the IoT device has a public key for the controller and can verify the controller's digital signatures made with the controller's private key. This way the IoT device only needs to know one public key.”
Therefore, claims 1-2 are rejected under 35 USC 103.
Response to Remarks:
35 USC 112
The remarks were responded to in the rejection above. Examiner notes that Applicant refers MPEP 2163(I), generally, which is not applicable to a new matter rejection. The only rejections being made are for new matter. See MPEP 2163.06: “If new matter is added to the claims, the examiner should reject the claims under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph - written description requirement. In re Rasmussen, 650 F.2d 1212, 211 USPQ 323 (CCPA 1981).” This is not a question of whether the written description is “sufficient” for “claims… as filed” See MPEP 2163.01. That is an entirely different question that has no bearing on new matter. “Sufficient detail” is not the test for new matter. In fact, the term “new matter” is not even found in MPEP 2163(I). Repeatedly, this section discusses originally filed claims. This would only apply for “written description” rejections where the sufficiency of the written description for claims as filed. Applicant did not cite an applicable MPEP section, nor an applicable standard, and therefore this argument is unpersuasive. Applicant’s issue is New Matter.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD W. CRANDALL whose telephone number is (313)446-6562. The examiner can normally be reached M - F, 8:00 AM - 5:00 PM.
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, Anita Coupe can be reached at (571) 270-3614. 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.
/RICHARD W. CRANDALL/ Primary Examiner, Art Unit 3619