DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the America Invents Act (AIA ).
Response and Claim Status
The instant Office action is responsive to the response received January 29, 2026 (the Response). Applicants’ election without traverse of Species I is acknowledged. See Response 10 (reciting “Species I is elected without traverse.”)
Claims 1–10, 12–15, and 17–52 are currently pending.
Joint Inventors
This application currently names joint inventors. In considering patentability of the claims the Examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicants are advised of the obligation under 37 C.F.R. § 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the Examiner to consider the applicability of 35 U.S.C. § 102(b)(2)(C) for any potential § 102(a)(2) prior art against the later invention.
Information Disclosure Statement (IDS)
The IDS filed December 17, 2025 complies with the provisions of 37 C.F.R. §§ 1.97, 1.98 and MPEP § 609. The IDS has been placed in the application file, and the information referred to therein has been considered.
The following is a quotation of 37 C.F.R. § 1.98(a): “Any information disclosure statement filed under § 1.97 shall include the items listed in paragraphs (a)(1), (a)(2) and (a)(3) of this section. (2) A legible copy of: (i) Each foreign patent; [and] (ii) Each publication or that portion which caused it to be listed.” See MPEP § 609 (citing 37 C.F.R. § 1.98(a)).
The IDS filed August 20, 2024 fails to comply with the provisions of 37 C.F.R. § 1.98, which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. The IDS has been placed in the application file, but the information referred to therein has not been considered.
Moreover, the Examiner is unable to locate a foreign patent document with number “201995691” and name of patentee or applicant “Lerner.”
Drawings
37 C.F.R. § 1.84(u)(2) recites “The view numbers must be larger than the numbers used for reference characters.” See MPEP § 608.02.
The drawings are objected to under 37 C.F.R. § 1.84(u)(2) for failing to include view numbers larger than numbers used for reference characters. See Figs. 11–18.
37 C.F.R. § 1.84(t) recites “These [numbering of sheets of drawings], if present, must be placed in the middle of the top of the sheet, but not in the margin. . . . The drawing sheet numbering must be clear and larger than the numbers used as reference characters to avoid confusion.” See MPEP § 608.02.
The drawings are objected to under 37 C.F.R. § 1.84(t) for failing to include the numbering of sheets of drawings larger than the numbers used as reference characters to avoid confusion.
Corrected drawing sheets in compliance with 37 C.F.R. § 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Applicants are advised to employ the services of a competent patent draftsperson outside the Office, as the USPTO does not prepare new drawings. The corrected drawings are required in reply to the Office action to avoid abandonment of the application. The requirement for corrected drawings will not be held in abeyance.
Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 C.F.R. § 1.121(d). If the changes are not accepted by the Examiner, Applicants will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The following is a quotation of 37 C.F.R. § 1.57(e):
Other material (“Nonessential material”) may be incorporated by reference to U.S. patents, U.S. patent application publications, foreign patents, foreign published applications, prior and concurrently filed commonly owned U.S. applications, or non-patent publications. An incorporation by reference by hyperlink or other form of browser executable code is not permitted.
The Specification is objected to under 37 C.F.R. § 1.57(e) because it contains an embedded hyperlink and/or other form of browser-executable code. See Spec. ¶ 121. Applicants are required to delete the embedded hyperlink and/or other form of browser-executable code; references to websites should be limited to the top-level domain name without any prefix such as http:// or other browser-executable code. See MPEP § 608.01.
The Specification cites “‘Wood, Gavin, “PoA Private Chains”, Github, November 2015, website: https://github.com/ethereum/guide/blob/master/poa.md.” Spec. ¶ 121. The Examiner notes the listing of references in the Specification is not a proper IDS. See 37 C.F.R. § 1.98(b) (requiring a list of all patents, publications, applications, or other information submitted for consideration by the Office); see also MPEP § 609.04(a)(I) (citing “the list may not be incorporated into the specification but must be submitted in a separate paper.”). Therefore, unless the references have been cited by the Examiner on form PTO-892, they have not been considered. This is not an objection to the Specification.
The lengthy Specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicants’ cooperation is requested in correcting any errors of which Applicants may become aware in the Specification.
Series of Singular Dependent Claims
A series of singular dependent claims is permissible in which a dependent claim refers to a preceding claim which, in turn, refers to another preceding claim.
A claim which depends from a dependent claim should not be separated by any claim which does not also depend from said dependent claim. It should be kept in mind that a dependent claim may refer to any preceding independent claim. In general, Applicant’s sequence will not be changed. See MPEP § 608.01(n).
This is not an objection to the claims.
Nonstatutory Double Patenting1
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s).2
A timely filed terminal disclaimer in compliance with 37 C.F.R. § 1.321(c) or § 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 C.F.R. § 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
The ‘331 Patent
Claims 1, 4–7, 9, 10, 13–15, 17, 21, and 22 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 38, 42–44, 47–52, 55, 59, and 70 of Rathi et al. (US 12,267,331 B2; filed Mar. 11, 2022; the ‘331 Patent).
Regarding claims 1, 4–7, 9, 10, 13–15, 17, 21, and 22 of the instant App., although the conflicting claims are not identical, they are not patentably distinct from each other because:
Instant Application
the ‘331 Patent
Claim 1: An access control method, comprising:
presenting, by a client device to a node of a local network, a token on a blockchain layer for authentication of the token by way of proof of authority authentication,
accessing, after the authentication of the token, a master node on the local network,
wherein the master node includes a storage device configured to store data.
Claim 38: An access control method, comprising:
sending, from a physical proximity interface of a token dispenser device to a client device, a token on a blockchain layer;
receiving, at a node of a local network from the client device, presentation of the token;
requesting, from the node, authentication of the token using proof of authority authentication;
sending, from the node to the client device, successful authentication of the token;
authorizing, after the successful authentication of the token, access of the client device to a device on the local network,
wherein the device is a security monitoring device, a television, a lock, a light, a heating, ventilation and air conditioning (HVAC) device, an appliance, a computer, and/or a vehicle,
wherein the device is connected to a network switch which is configured to access the local network,
wherein the network switch has power activated from a relay, the access control method further comprising the node activating the relay after the successful authentication of the token; and
performing, using a master device on the local network, the proof of authority authentication and generating, by the master device, an immutable log on the blockchain layer.
Claim 4. The access control method as claimed in claim 1, wherein the node is an authorization service provider.
Claim 42. The access control method as claimed in claim 38, wherein the node is an authorization service provider.
Claim 5. The access control method as claimed in claim 1, further comprising receiving, from a physical proximity interface of a token dispenser device, the token on the blockchain layer.
Claim 38. receiving, from a physical proximity interface of a token dispenser device, a token on a blockchain layer;
Claim 6. The access control method as claimed in claim 5, wherein the physical proximity interface includes a radiofrequency identification (RFID) interface or a Near-Field Communication (NFC) interface.
Claim 43. The access control method as claimed in claim 38, wherein the physical proximity interface includes a radiofrequency identification (RFID) interface or a Near-Field Communication (NFC) interface.
Claim 7. The access control method as claimed in claim 5, wherein the physical proximity interface includes a physical port interface.
Claim 44. The access control method as claimed in claim 38, wherein the physical proximity interface includes a physical port interface.
Claim 9. The access control method as claimed in claim 5, further comprising receiving, by the token dispenser device, the token from a master node through the physical proximity interface.
Claim 47. The access control method as claimed in claim 38, further comprising receiving, by the token dispenser device, the token from the master device through the physical proximity interface.
Claim 10. The access control method as claimed in claim 9, wherein the token dispenser device is directly wiredly connected to the master node.
Claim 48. The access control method as claimed in claim 47, wherein the token dispenser device is directly wiredly connected to the master device, and the master device is on the local network.
Claim 13. The access control method as claimed in claim 5, wherein the receiving the token on the blockchain layer includes receiving a private key associated with the token.
Claim 49. The access control method as claimed in claim 38, wherein the sending the token on the blockchain layer includes sending a private key associated with the token.
Claim 14. The access control method as claimed in claim 13, wherein the proof of authority authentication includes the client device starting a transaction on the blockchain layer using the private key.
Claim 50. The access control method as claimed in claim 49, wherein the proof of authority authentication includes the client device starting a transaction on the blockchain layer using the private key.
Claim 15. The access control method as claimed in claim 1, wherein the local network includes a wired local network, wherein the node is connected to the wired local network.
Claim 51. The access control method as claimed in claim 38, wherein the local network includes a wired local network, wherein the node is connected to the wired local network.
Claim 17. The access control method as claimed in claim 1, wherein the local network includes a wireless local network, wherein the node is on the wireless local network.
Claim 52. The access control method as claimed in claim 38, wherein the local network includes a wireless local network, wherein the node is on the wireless local network.
Claim 21. The access control method as claimed in claim 5, wherein the receiving the token does not require any identification or credentials of the client device.
Claim 59. The access control method as claimed in claim 38, wherein the sending the token does not require any identification or credentials of the client device.
Claim 22. The access control method as claimed in claim 1, wherein access to the specific node is disabled after a specified period of time.
Claim 70. The access control method as claimed in claim 38, wherein the access is until expiration of a time period.
Means-plus-Function Language
The following is a quotation of 35 U.S.C. § 112(f):
ELEMENT IN CLAIM FOR A COMBINATION.—An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof
The claims in the instant application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the Specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the Specification when 35 U.S.C. § 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. § 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step for”) in a claim with functional language creates a rebuttable presumption that the claim element is to be treated in accordance with 35 U.S.C. § 112(f). The presumption that § 112(f) is invoked is rebutted when the function is recited with sufficient structure, material, or acts within the claim itself to entirely perform the recited function.
Absence of the word “means” (or “step for”) in a claim creates a rebuttable presumption that the claim element is not to be treated in accordance with 35 U.S.C. § 112(f). The presumption that § 112(f) is not invoked is rebutted when the claim element recites function but fails to recite sufficiently definite structure, material or acts to perform that function.
Claim elements in the instant application that use the word “means” (or “step for”) are presumed to invoke 35 U.S.C. § 112(f) except as otherwise indicated in an Office action. Similarly, claim elements that do not use the word “means” (or “step for”) are presumed not to invoke § 112(f) except as otherwise indicated in an Office action.
The instant application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. § 112(f) because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations3 are:
“client device” (claim 1, line 2; claim 26, line 2; claim 47, line 2);
“node” (claim 1, line 2; claim 26, line 2; claim 28, line 2; claim 37, line 2; claim 43, line 2);
“storage device” (claim 1, line 5; claim 30, line 2; claim 31, line 2; claim 43, lines 5–6);
“token dispenser device” (claim 9, line 2; claim 29, line 2); and
“master node” (claim 9, line 2; claim 12, line 2; claim 18, line 2; claim 32, line 2; claim 33, line 2; claim 46, line 2; claim 52, line 2).
Since the claim limitations invoke 35 U.S.C. § 112(f), claims 1–10, 12–15, and 17–52 have been interpreted to cover the corresponding structure described in the Specification that achieves the claimed function, and equivalents thereof.
With respect to the claimed function corresponding to claim element “client device” (claim 1, line 2; claim 26, line 2; claim 47, line 2), the Specification discloses a client device that achieves the claimed function. Spec. ¶ 281 (reciting “At step 1104, the client device 118 presents, to a node 112 of the local network, the token 120.”). Figure 1A illustrates client device 118 as being a smartphone.
With respect to the claimed function corresponding to claim element “storage device” (claim 1, line 5; claim 30, line 2; claim 31, line 2; claim 43, lines 5–6), the Specification discloses a “storage device” that achieves the claimed function. Spec. ¶ 173 (reciting “the storage device 104 is configured to store data”). According to the Specification, “the device 104 can be a computer.” Id. ¶ 125.
With respect to the claimed function corresponding to claim element “token dispenser device” (claim 9, line 2; claim 29, line 2), the Specification discloses a “token dispenser device” that achieves the claimed function. Spec. ¶ 128. According to the Specification, “the token dispenser device 106 is a stand-alone dedicated computer device.” Id.
If Applicants do not intend to have the claim limitations treated under 35 U.S.C. § 112(f), Applicants may amend the claims so that they will clearly not invoke § 112(f), or present a sufficient showing that the claims recite sufficient structure, material, or acts for performing the claimed function to preclude application of § 112(f).
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011) (available at https://www.govinfo.gov/content/pkg/FR-2011-02-09/pdf/2011-2841.pdf).
Claim Rejections – 35 U.S.C. § 112
35 U.S.C. § 112(a)
The following is a quotation of 35 U.S.C. § 112(a):
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.
Claims 28 and 35–42 are rejected under 35 U.S.C. § 112(a) as failing to comply with the enablement requirement. The claims contain subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Notably, as discussed above, the claim element “node” (claim 28, line 2; claim 37, line 2; claim 43, line 2) is a limitation that invokes 35 U.S.C. § 112(f). Claims 28 and 35–42, therefore, are single-means claims. “A single means claim, i.e., where a means recitation does not appear in combination with another recited element of means, is subject to an enablement rejection under 35 U.S.C. 112(a).” MPEP § 2164.08(a) (citing In re Hyatt, 708 F.2d 712, 714-715(Fed. Cir. 1983)).
35 U.S.C. § 112(b)
The following is a quotation of 35 U.S.C. § 112(b): “The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.”
The MPEP recites “[d]uring examination, after applying the broadest reasonable interpretation consistent with the specification to the claim, if the metes and bounds of the claimed invention are not clear, the claim is indefinite and should be rejected.” MPEP § 2173.02(I) (citing In re Packard, 751 F.3d 1307, 1311 (Fed. Cir. 2014)). “For example, if the language of a claim, given its broadest reasonable interpretation, is such that a person of ordinary skill in the relevant art would read it with more than one reasonable interpretation, then a rejection under 35 U.S.C. 112(b) . . . is appropriate.” Id. See also id. § 2173.05(e)(discussing indefiniteness arising for terms lacking proper antecedent basis).
Claims 1–10, 12–15, and 17–52 are rejected under 35 U.S.C. § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention. In particular,
(i) As discussed above, claim element “node” (claim 1, line 2; claim 26, line 2; claim 28, line 2; claim 37, line 2; claim 43, line 2) is a limitation that invokes 35 U.S.C. § 112(f). The Specification is devoid of adequate structure to perform the claimed function. In particular, the Specification states the claimed function of receiving a presented token is performed by a “node.” There is no disclosure of any particular structure, either explicitly, implicitly, or inherently, to receive the presented token. The use of the term “node” is not adequate structure for receiving the presented token because it does not describe a particular structure for performing the function. As would be recognized by those of ordinary skill in the art, the term “node” can be performed in any number of ways in hardware, software or a combination of the two. The Specification does not provide sufficient details such that one of ordinary skill in the art would understand which filter structure or structures perform(s) the claimed function.
(ii) As discussed above, claim element “master node” (claim 9, line 2; claim 12, line 2; claim 18, line 2; claim 32, line 2; claim 33, line 2; claim 46, line 2; claim 52, line 2) is a limitation that invokes 35 U.S.C. § 112(f). The Specification is devoid of adequate structure to perform the claimed function. There is no disclosure of any particular structure, either explicitly, implicitly, or inherently, to perform the claimed function. The use of the term “master node” is not adequate structure for performing the claimed function because it does not describe a particular structure for performing the function. As would be recognized by those of ordinary skill in the art, the term “master node” can be performed in any number of ways in hardware, software or a combination of the two. The Specification does not provide sufficient details such that one of ordinary skill in the art would understand which filter structure or structures perform(s) the claimed function.
(iii) Regarding elements (i) and (ii) above, the written description, therefore, fails to clearly link or associate the disclosed structure, material, or acts to the claimed function such that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function. Accordingly, the claim is indefinite and is rejected under 35 U.S.C. § 112(b).
Applicants may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. § 112(f); or
(b) Amend the written description of the Specification such that it clearly links or associates the corresponding structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. § 132(a)); or
(c) State on the record where the corresponding structure, material, or acts are set forth in the written description of the Specification and linked or associated to the claimed function. For more information, see 37 CFR § 1.175(d) and MPEP §§ 608.01(o) and 2181.
(iv) The MPEP recites
[i]f the trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of the 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982).
MPEP §2173.5(u).
Claims 2, 30, and 43 recite the trademark ETHEREUM to identify or describe a particular material or product. Thus, claims 2, 30, and 43–52 are rejected under 35 U.S.C. § 112(b).
(v) claim 25, line 1, “A client device” adds ambiguity to the claim because the Examiner is uncertain as to whether the limitation refers to the client device introduced in claim 1, line 2 or not.
It is assumed for examination purposes that the limitation refers to the client device introduced in claim 1, line 2. See MPEP § 2173.06 (reciting “When making a rejection over prior art in these circumstances, it is important that the examiner state on the record how the claim term or phrase is being interpreted with respect to the prior art applied in the rejection.”; emphasis omitted).
(vi) claim 26, lines 4–5, “sending . . . confirmation of access to a specific node on the local network” adds ambiguity to the claim because the Examiner is uncertain as to whether the limitation refers to
(a) a confirmation of access being sent to a specific node; or
(b) a confirmation of access to a specific node is sent somewhere.
It is assumed for examination purposes that the limitation refers to (b).
Claim 28, line 6 by analogy.
Claim Rejections – 35 U.S.C. § 1024
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Agrawal
Claims 43 and 49–51 are rejected under 35 U.S.C. § 102 as being anticipated by Agrawal et al. (US 2018/0302222 A1; filed Apr. 18, 2018).
Regarding claim 43, Agrawal discloses an access control method (fig. 8, item 800), comprising:
receiving, at a node (“user devices present in any of the zones A, B and C” at ¶ 93) on a local network (zones A, B, and C at fig. 2A) from a client device (“multiple IoT tokens are generated by the token generator 304” at ¶ 93; fig. 3A, item 304 within node item 206; “The nodes in each of the zones A, B and C include home security devices, lighting systems, speakers, television sets, phones, faucets, and the like.” at ¶ 58), presentation of a token (“For each node and each zone in the IoT network 220, a unique IoT token is generated. The user 250, upon registration with an enrollment certificate authority (such as the query controller 301) is provided with multiple IoT tokens, each IoT token corresponding to a node or a zone.” at ¶ 93) on a blockchain layer (fig. 2A, item 202), wherein authentication of the token (“The approach in the method 800 is that of dynamic token authentication.” at ¶ 95) is performed by way of proof of authority authentication (“The approach in the method 800 is that of dynamic token authentication.” at ¶ 95; “In blockchain-based technology used for cryptographic currencies such as Bitcoin™ or Ethererum™, proof of work (PoW) systems require the nodes to provide a proof of work for a block of transactions to be accepted by the network participants.” at ¶ 99) or by exactly one node (fig. 3A, item 304 within node item 206) on the local network; and
instructing, by the node, as a consequence to the authentication of the token, a storage device (“Referring to FIG. 2B, the electronic device requests access to the zone A.” at ¶ 61) on the local network to perform a transaction (“The electronic device transmits a request and an IoT token to the node 206A for a transaction.” at ¶ 62) on a public blockchain layer (fig. 2A, item 202),
wherein the storage device is configured to store one or more of, for the public blockchain layer: wallet private key, token (“the updated IoT tokens are stored on the user device” at ¶ 107; “IoT tokens that are stored in the user device 701” at ¶ 121), distributed ledger token, blockchain token, or Ethereum token.
Regarding claims 49–51, claims 19–21, respectively, recites substantially similar features. Thus, references/arguments equivalent to those present for claims 19–21 are equally applicable to, respectively, claims 49–51.
Claim Rejections – 35 U.S.C. § 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.
Rathi and Rolle
Claims 26 and 28 are rejected under 35 U.S.C. § 103 as being obvious over Rathi et al. (US 2022/0407867 A1; filed Mar. 11, 2022; published Dec. 22, 2022) in view of Rolle (US 2022/0043917 A1; filed Aug. 10, 2020).5
Regarding claim 26, while Rathi teaches an access control method (fig. 11, item 1100), comprising:
receiving, at a node (fig. 3, item 118) on a local network (fig. 3, item 100) from a client device (fig. 3, item 106), presentation (fig. 11, item 1102) of a token (fig. 3, item 120) on a blockchain layer (“At step 1102, the client device 118 receives, from a physical proximity interface of the token dispenser device 106, a token 120 on a blockchain layer.” at ¶ 189) for authentication of the token by way of proof of authority authentication (fig. 11, item 1106; intended use in italics); and
after the authentication of the token, access to a specific node (fig. 11, item 1108; “a device 104 on the local network.” at ¶ 189; “the device 104 can be a computer on the local network, for example a personal computer, a server, or a mobile device.” at ¶ 65) on the local network, wherein the specific node includes a storage device (fig. 11, item 1108; “a device 104 on the local network.” at ¶ 189; “the device 104 can be a computer on the local network, for example a personal computer, a server, or a mobile device.” at ¶ 65) configured to store data,
Rathi does not teach sending confirmation of the access.
Rolle teaches sending confirmation of an access (“statement tracking module sending a confirmation of user access to the information statement” at ¶ 50).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Rathi to send confirmation of access to the specific node as taught by Rolle “to store a record of the user access,” thereby allowing the user or another to keep track of accessing. Rolle ¶ 26.
Regarding claim 28, Rathi teaches an access control system (fig. 11, item 1100), comprising: a node (“access control method 1100 performed by the client device 118” at ¶ 189) configured to perform operations according to claim 26. Thus, references/arguments equivalent to those present for claim 26 are equally applicable to claim 28.
Rathi, Rolle, and Nordstrom
Claims 30 and 31 are rejected under 35 U.S.C. § 103 as being obvious over Rathi in view of Rolle, and in further view of Nordstrom et al. (US 2020/0175138 A1; filed Dec. 2, 2019).6
Regarding claim 30, Rathi does not teach wherein the storage device is configured to store one or more of, for a public ledger: wallet private key, token, distributed ledger token, blockchain token, or Ethereum token.
Nordstrom teaches storing one or more of, for a public ledger: wallet private key, token (“stores a head token”), distributed ledger token, blockchain token, or Ethereum token.
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Rathi’s storage device to store one or more of, for a public ledger: wallet private key, token, distributed ledger token, blockchain token, or Ethereum token as taught by Nordstrom “for digital files management and preservation in digital licenses.” Nordstrom ¶ 10.
Regarding claim 31, Rathi does not teach wherein the storage device is configured to store one or more files, electronic documents, or media files.
Nordstrom teaches storing one or more files (“storage of the files” at ¶ 55), electronic documents, or media files.
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Rathi’s storage device to store one or more files, electronic documents, or media files as taught by Nordstrom “for digital files management and preservation in digital licenses.” Nordstrom ¶ 10.
Agrawal
Claims 1, 2, 20, 25, and 27 are rejected under 35 U.S.C. § 103 as being obvious over Agrawal et al. (US 2018/0302222 A1; filed Apr. 18, 2018).
Regarding claim 1, Agrawal teaches an access control method (fig. 8, item 800), comprising:
presenting, by a client device (“multiple IoT tokens are generated by the token generator 304” at ¶ 93; fig. 3A, item 304 within node item 206; “The nodes in each of the zones A, B and C include home security devices, lighting systems, speakers, television sets, phones, faucets, and the like.” at ¶ 58) to a node (“user devices present in any of the zones A, B and C” at ¶ 93) of a local network (zones A, B, and C at fig. 2A), a token (“For each node and each zone in the IoT network 220, a unique IoT token is generated. The user 250, upon registration with an enrollment certificate authority (such as the query controller 301) is provided with multiple IoT tokens, each IoT token corresponding to a node or a zone.” at ¶ 93) on a blockchain layer (fig. 2A, item 202) for authentication of the token by way of proof of authority authentication (“The approach in the method 800 is that of dynamic token authentication.” at ¶ 95; “In blockchain-based technology used for cryptographic currencies such as Bitcoin™ or Ethererum™, proof of work (PoW) systems require the nodes to provide a proof of work for a block of transactions to be accepted by the network participants.” at ¶ 99; intended use in italics)
accessing a specific node (“The electronic device transmits a request and an IoT token to the node 206A for a transaction.” at ¶ 62; “user device” at ¶ 107; “in a system 700 a user device 701 is the electronic device of the user 250” at ¶ 88; fig. 7, item 701) on the local network, wherein the specific node includes a storage device (“stored on the user device” at ¶ 107) configured to store data (“updated IoT tokens” at ¶ 107) for the client device,
Agrawal does not teach the accessing occurring after the authentication of the token.
It would have been prima facie obvious to one of ordinary skill in the art before the effective date of the invention for Agrawal’s accessing to occur after the authentication of the token since “selection of any order of performing process steps is prima facie obvious in the absence of new or unexpected results.” MPEP § 2144.04 (citing In re Burhans, 154 F.2d 690 (CCPA 1946)).
Regarding claim 2, Agrawal teaches wherein the storage device (“stored on the user device” at ¶ 107) is configured to store one or more of, for a public ledger (intended use in italics), wallet private key, token (“the updated IoT tokens are stored on the user device” at ¶ 107; “IoT tokens that are stored in the user device 701” at ¶ 121), distributed ledger token, blockchain token, or Ethereum token.
Regarding claim 20, Agrawal teaches wherein the presenting is performed through the local network when the client device is on the local network and via the Internet when7 the client device is remote from the local network.
Regarding claim 25, Agrawal teaches a client device (“multiple IoT tokens are generated by the token generator 304” at ¶ 93; fig. 3A, item 304 within node item 206; “The nodes in each of the zones A, B and C include home security devices, lighting systems, speakers, television sets, phones, faucets, and the like.” at ¶ 58), comprising:
a processor (Agrawal at least suggests home security devices and television sets at paragraph 58 including a processor); and
memory (Agrawal at least suggests home security devices and television sets at paragraph 58 including a memory) containing instructions which, when executed by the processor, cause the processor to perform the access control method as claimed in claim 1.
Regarding claim 27, Agrawal teaches a non-transitory memory (“multiple IoT tokens are generated by the token generator 304” at ¶ 93; fig. 3A, item 304 within node item 206; “The nodes in each of the zones A, B and C include home security devices, lighting systems, speakers, television sets, phones, faucets, and the like.” at ¶ 58; Agrawal at least suggests home security devices and television sets at paragraph 58 including a memory) containing instructions which, when executed by one or more processors (Agrawal at least suggests home security devices and television sets at paragraph 58 including a processor), cause the one or more processors to perform the access control method as claimed in claim 1.
Agrawal and Avetisov
Claims 3, 4, 44, and 45 are rejected under 35 U.S.C. § 103 as being obvious over Agrawal in view of Avetisov et al. (US 2020/0351660 A1; filed July 17, 2020).
Regarding claim 3, Agrawal does not teach wherein the storage device is configured to store one or more files, electronic documents, or media files.
Avetisov teaches a storage device configured to store one or more files (“a secured program o[r sic] file stored on the device” at ¶ 88), electronic documents, or media files.
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s storage device to be configured to store one or more files, electronic documents, or media files as taught by Avetisov “to protect native applications, software assets, and other media from unauthorized access.” Avetisov ¶ 45.
Regarding claim 4, Agrawal does not teach wherein the node is an authorization service provider.
Avetisov teaches an authorization service provider (“a wireless service provider” at ¶ 153; “a medical or financial service provider” at ¶ 258; “other service provider” at ¶ 348).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s node to be an authorization service provider as taught by Avetisov “to protect native applications, software assets, and other media from unauthorized access.” Avetisov ¶ 45.
Regarding claims 44 and 45, claims 3 and 4, respectively, recite substantially similar features. Thus, references/arguments equivalent to those present for claims 3 and 4 are equally applicable to, respectively, claims 44 and 45.
Agrawal and Pietrzyk
Claims 5–10, 13–15, 17, 19, 21, 24, and 48 are rejected under 35 U.S.C. § 103 as being obvious over Agrawal in view of Pietrzyk et al. (US 2007/0055470 A1; filed Sept. 8, 2005).
Regarding claim 5, while Agrawal teaches further comprising receiving, from a token dispenser device (“electronic device” at ¶ 62; “user device 701” at ¶ 93), the token on the blockchain layer (“The electronic device transmits . . . an IoT token to the node 206A for a transaction.” at ¶ 62),
Agrawal does not teach a physical proximity interface of the token dispenser device.
Pietrzyk teaches a physical proximity interface (fig. 19, item 1942; “radio frequency identification (RFID)” at ¶ 5) of a device (fig. 19, item 1958).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s token dispenser device to include a physical proximity interface as taught by Pietrzyk “to perform evaluations such as diagnostics, warranty, and troubleshooting.” Pietrzyk ¶ 5.
Regarding claim 6, the Agrawal/Pietrzyk combination does not teach wherein the physical proximity interface includes a radiofrequency identification (RFID) interface or a Near-Field Communication (NFC) interface.
Pietrzyk teaches an RFID interface (“radio frequency identification (RFID)” at ¶ 5) or an NFC interface.
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for the Agrawal/Pietrzyk combination’s physical proximity interface to include an RFID interface or an NFC interface as taught by Pietrzyk “to perform evaluations such as diagnostics, warranty, and troubleshooting.” Pietrzyk ¶ 5.
Regarding claim 7, the Agrawal/Pietrzyk combination does not teach wherein the physical proximity interface includes a physical port interface.
Pietrzyk teaches a physical port interface (fig. 19, item 1942).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for the Agrawal/Pietrzyk combination’s physical proximity interface to include a physical port interface as taught by Pietrzyk “to perform evaluations such as diagnostics, warranty, and troubleshooting.” Pietrzyk ¶ 5.
Regarding claim 8, Agrawal teaches wherein the specific node is a master node (“in a system 700 a user device 701 is the electronic device of the user 250” at ¶ 88; fig. 7, item 701).
Regarding claim 9, while Agrawal teaches further comprising receiving, by the token dispenser device (“electronic device” at ¶ 62; “user device 701” at ¶ 93), the token from a master node (“multiple IoT tokens are generated by the token generator 304 for user devices present in any of the zones A, B and C.” at ¶ 93),
Agrawal does not teach the receiving being through the physical proximity interface.
Pietrzyk teaches receiving data through a physical proximity interface (fig. 19, item 1942; “radio frequency identification (RFID)” at ¶ 5).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s receiving to be through the physical proximity interface as taught by Pietrzyk “to perform evaluations such as diagnostics, warranty, and troubleshooting.” Pietrzyk ¶ 5.
Regarding claim 10, while Agrawal teaches wherein the token dispenser device (“electronic device” at ¶ 62; “user device 701” at ¶ 93) is connected to the master node (“multiple IoT tokens are generated by the token generator 304 for user devices present in any of the zones A, B and C.” at ¶ 93),
Agrawal does not teach directly wiredly connected.
Pietrzyk teaches directly wiredly connected (“wired networks (which use IEEE 802.3 or Ethernet)” at ¶ 103; fig. 19, item 1942).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s connection to be a directly wiredly connection as taught by Pietrzyk “to perform evaluations such as diagnostics, warranty, and troubleshooting.” Pietrzyk ¶ 5.
Regarding claim 13, while Agrawal teaches the receiving the token on the blockchain layer (“The electronic device transmits . . . an IoT token to the node 206A for a transaction.” at ¶ 62),
Agrawal does not teach the receiving includes receiving a private key associated with the token.
Agrawal teaches receiving a private key (“At operation 712, the user device 701 transmits a private key to the IoT network 220.” at ¶ 90; fig. 7, item 712) associated with a token (fig. 7, items 708, 710).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s receiving to include receiving a private key associated with the token as taught by Agrawal “to generate a digital signature for a blockchain transaction” and “to confirm that the transaction is from the user 250.” Agrawal ¶ 90.
Regarding claim 14, Agrawal teaches wherein the proof of authority authentication (“The approach in the method 800 is that of dynamic token authentication.” at ¶ 95; “In blockchain-based technology used for cryptographic currencies such as Bitcoin™ or Ethererum™, proof of work (PoW) systems require the nodes to provide a proof of work for a block of transactions to be accepted by the network participants.” at ¶ 99) includes the client device starting a transaction (“The electronic device transmits a request and an IoT token to the node 206A for a transaction.” at ¶ 62) on the blockchain layer using the private key (“the user device 701 transmits a private key to the IoT network 220. The private key can be used to generate a digital signature for a blockchain transaction. The digital signature is used to confirm that the transaction is from the user 250.” at ¶ 90).
Regarding claim 15, Agrawal does not teach wherein the local network includes a wired local network, wherein the node is connected to the wired local network.
Pietrzyk teaches a local network including a wired local network, wherein a node is connected to the wired local network (“A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3 or Ethernet). Wi-Fi networks operate in the unlicensed 2.4 and 5 GHz radio bands, at an 11 Mbps (802.11a) or 54 Mbps (802.11b) data rate, for example, or with products that contain both bands (dual band), so the networks can provide real-world performance similar to the basic 10BaseT wired Ethernet networks used in many offices.” at ¶ 103).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s local network to include a wired local network, and for Agrawal’s node to be connected to the wired local network as taught by Pietrzyk “to perform evaluations such as diagnostics, warranty, and troubleshooting.” Pietrzyk ¶ 5.
Regarding claim 17, Agrawal does not teach wherein the local network includes a wireless local network, wherein the node is on the wireless local network.
Pietrzyk teaches a local network including a wireless local network, wherein a node is connected to the wireless local network (“wireless communications to one or more remote computers” at ¶ 99; “The adaptor 1956 may facilitate wired or wireless communication to the LAN 1952, which may also include a wireless access point disposed thereon for communicating with the wireless adaptor 1956.” at ¶ 100; “Wi-Fi networks use radio technologies called IEEE 802.11(a, b, g, etc.) to provide secure, reliable, fast wireless connectivity.” at ¶ 103).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s local network to include a wireless local network, and for Agrawal’s node to be connected to the wireless local network as taught by Pietrzyk “to perform evaluations such as diagnostics, warranty, and troubleshooting.” Pietrzyk ¶ 5.
Regarding claim 19, Agrawal teaches wherein the authentication (“The approach in the method 800 is that of dynamic token authentication.” at ¶ 95) authorizes access to only the master node (fig. 7, item 701 represented by fig. 8, item 250) and no other devices on the local network.
Regarding claim 21, Agrawal teaches wherein the receiving the token (“The electronic device transmits . . . an IoT token to the node 206A for a transaction.” at ¶ 62) does not require any identification or credentials of the client device (Agrawal does not teach requiring any identification or credentials of node item 206 when the electronic device at paragraph 62 transmits an IoT token to node item 206).
Regarding claim 24, Agrawal teaches wherein the node (“user devices present in any of the zones A, B and C” at ¶ 93) is the master node (“in a system 700 a user device 701 is the electronic device of the user 250” at ¶ 88; fig. 7, item 701).
Regarding claim 48, claim 15 recites substantially similar features. Thus, references/arguments equivalent to those present for claim 15 are equally applicable to claim 48.
Agrawal and Tobias
Claim 22 is rejected under 35 U.S.C. § 103 as being obvious over Agrawal in view of Tobias et al. (US 2019/0138621 A1; filed Nov. 7, 2019).
Regarding claim 22, Agrawal does not teach wherein access to the specific node is disabled after a specified period of time.
Tobias teaches access to a specific node is disabled after a specified period of time (“disable access to files after a period of time without user interaction” at ¶ 25).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s access to the specific node to be disabled after a specified period of time as taught by Tobias for “protect[ing] stored credentials from hackers who attempt to use old keys.” Tobias ¶ 36.
Agrawal and Rolle
Claims 26, 28, and 30 are rejected under 35 U.S.C. § 103 as being obvious over Agrawal in view of Rolle (US 2022/0043917 A1; filed Aug. 10, 2020).
Regarding claim 26, while Agrawal teaches an access control method (fig. 8, item 800), comprising:
receiving, at a node (“user devices present in any of the zones A, B and C” at ¶ 93) on a local network (zones A, B, and C at fig. 2A) from a client device (“multiple IoT tokens are generated by the token generator 304” at ¶ 93; fig. 3A, item 304 within node item 206; “The nodes in each of the zones A, B and C include home security devices, lighting systems, speakers, television sets, phones, faucets, and the like.” at ¶ 58), presentation of a token (“For each node and each zone in the IoT network 220, a unique IoT token is generated. The user 250, upon registration with an enrollment certificate authority (such as the query controller 301) is provided with multiple IoT tokens, each IoT token corresponding to a node or a zone.” at ¶ 93) on a blockchain layer (fig. 2A, item 202) for authentication of the token (“a flow diagram 820 pertaining to dynamic token authentication is depicted” at ¶ 93) by way of proof of authority authentication (“The approach in the method 800 is that of dynamic token authentication.” at ¶ 95; “In blockchain-based technology used for cryptographic currencies such as Bitcoin™ or Ethererum™, proof of work (PoW) systems require the nodes to provide a proof of work for a block of transactions to be accepted by the network participants.” at ¶ 99; intended use in italics); and
access to a specific node (“in a system 700 a user device 701 is the electronic device of the user 250” at ¶ 88; fig. 7, item 701) on the local network, wherein the specific node includes a storage device (“stored on the user device” at ¶ 107 at least suggests the user device including memory configured to store data) configured to store data,
Agrawal does not teach (A) send confirmation of the access; and (B) the sending occurring after the authentication of the token.
(A)
Rolle teaches sending confirmation of an access (“statement tracking module sending a confirmation of user access to the information statement” at ¶ 50).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal to send confirmation of access to the specific node as taught by Rolle “to store a record of the user access,” thereby allowing the user or another to keep track of accessing. Rolle ¶ 26.
(B)
It would have been prima facie obvious to one of ordinary skill in the art before the effective date of the invention for Agrawal’s access of the specific node to occur after the authentication of the token since “selection of any order of performing process steps is prima facie obvious in the absence of new or unexpected results.” MPEP § 2144.04 (citing Burhans).
Regarding claim 28, Agrawal teaches an access control system (fig. 8, item 800), comprising: a node (“user devices present in any of the zones A, B and C” at ¶ 93) on a local network (zones A, B, and C at fig. 2A) configured to perform operations according to claim 26. Thus, references/arguments equivalent to those present for claim 26 are equally applicable to claim 28.
Regarding claim 30, claim 2 recites substantially similar features. Thus, references/arguments equivalent to those present for claim 2 are equally applicable to claim 30.
Agrawal, Rolle, and Avetisov
Claim 31 is rejected under 35 U.S.C. § 103 as being obvious over Agrawal in view of Rolle, and in further view of Avetisov.
Regarding claim 31, claim 3 recites substantially similar features. Thus, references/arguments equivalent to those present for claim 3 are equally applicable to claim 31.
Agrawal, Rolle, and Pietrzyk
Claims 29, 35, 36, and 42 are rejected under 35 U.S.C. § 103 as being obvious over Agrawal in view of Rolle, and in further view of Pietrzyk.
Regarding claim 29, while Agrawal teaches further comprising a token dispenser device (“electronic device” at ¶ 62; “user device 701” at ¶ 93), the token dispenser device configured to send to the client device the token (“The electronic device transmits . . . an IoT token to the node 206A for a transaction.” at ¶ 62) on the blockchain layer (fig. 2A, item 202),
Agrawal does not teach a physical proximity interface of the token dispenser device.
Pietrzyk teaches a physical proximity interface (fig. 19, item 1942; “radio frequency identification (RFID)” at ¶ 5) of a device (fig. 19, item 1958) that sends data to a device (fig. 19, item 1948).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Agrawal’s token dispenser device to include a physical proximity interface as taught by Pietrzyk “to perform evaluations such as diagnostics, warranty, and troubleshooting.” Pietrzyk ¶ 5.
Regarding claims 35, 36, and 42, claims 15, 8, and 24, respectively, recite substantially similar features. Thus, references/arguments equivalent to those present for claims 15, 8, and 24 are equally applicable to, respectively, claims 35, 36, and 42.
Agrawal, Rolle, and Tobias
Claim 39 is rejected under 35 U.S.C. § 103 as being obvious over Agrawal in view of Rolle, and in further view of Tobias.
Regarding claim 39, claim 22 recites substantially similar features. Thus, references/arguments equivalent to those present for claim 22 are equally applicable to claim 39.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicants’ disclosure: US-20240129123-A1; US-20210243028-A1; US-20170295157-A1; WO-2022266744-A1; and WO-2024254692-A1.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to DAVID P. ZARKA whose telephone number is (703) 756-5746. The Examiner can normally be reached Monday–Friday from 9:30AM–6PM ET.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Vivek Srivastava, can be reached at (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, Applicants are encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
/DAVID P ZARKA/PATENT EXAMINER, Art Unit 2449
1 The Examiner will determine whether Applicants’ reply to the nonstatutory double patenting rejection is compliant under 37 C.F.R. § 1.111(b). See MPEP § 804(I)(B)(1) (reciting
[a] complete response to a nonstatutory double patenting (NSDP) rejection is either a reply by applicant showing that the claims subject to the rejection are patentably distinct from the reference claims, or the filing of a terminal disclaimer in accordance with 37 CFR 1.321 in the pending application(s) with a reply to the Office action (see MPEP § 1490 for a discussion of terminal disclaimers). Such a response is required even when the nonstatutory double patenting rejection is provisional.
). In the event the reply is non-compliant under 37 C.F.R. § 1.111(b), the Examiner will issue a Notice of Non-Compliant Response.
2 See, e.g., In re Berg, 140 F.3d 1428 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046 (Fed. Cir. 1993); In re Longi, 759 F.2d 887 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937 (CCPA 1982); In re Vogel, 422 F.2d 438 (CCPA 1970); In re Thorington, 418 F.2d 528 (CCPA 1969).
3 The Examiner notes “Applicants are free to invoke § 112 ¶ 6 for a claim term nested in a method claim. We have never held otherwise.” Rain Computing, Inc. v. Samsung Elecs. Am. Inc., 989 F.3d 1002, 1006 (Fed. Cir. 2021). See also Media Rights Technologies, Inc. v. Capital One Financial Corp., 800 F.3d 1366, 1374 (Fed. Cir. 2015) (holding that the term “compliance mechanism” in a method claim was a means-plus-function term); see also MPEP § 2181.
4 The Examiner notes claims 12, 18, 20, 23, 32–34, 37, 38, 40, 41, 46, 47, and 52 are not prior-art rejected under 35 U.S.C. §§ 102, 103 in the instant Office action. The instant Office action does not indicate these claims as being allowable since the Examiner is not satisfied that the prior art has been fully developed. See MPEP § 707.07(j) (reciting “Where the examiner is satisfied that the prior art has been fully developed and some of the claims are clearly allowable, the allowance of such claims should not be delayed.”).
5 “An obviousness rejection is ordinarily based on a disclosure that qualifies as prior art under 35 U.S.C. 102.” MPEP § 2141.01(I). The rejection under 35 U.S.C. § 103 relies on 35 U.S.C. § 102(a), which recites “A person shall be entitled to a patent unless—(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.” MPEP 2152.01 recites
If the application is a continuation-in-part of an earlier U.S. application or international application, any claims in the new application not supported by the specification and claims of the parent application have an effective filing date equal to the actual filing date of the new application. Any claims which are fully supported under 35 U.S.C. 112 by the earlier parent application have the effective filing date of that earlier parent application.
Rathi is a parent application of the instant application. The instant application is a CIP of Rathi. Thus, any claims in the instant application not supported by the Specification and claims of Rathi have an effective filing date equal to the actual filing date of the instant application (August 20, 2024). Therefore, any claims in the instant application rejected under 35 U.S.C. § 103 involving Rathi that are not fully supported by the Specification and claims of Rathi have an effective filing date equal to the actual filing date of the instant application (August 20, 2024).
Accordingly, claims 26, 28, 30, and 31 in the instant application have an effective filing date equal to the actual filing date of the instant application (August 20, 2024).
6 See n. 5 supra.
7 The presenting method-step is conditional and, therefore, need not be satisfied to meet claim 20. See Ex parte Schulhauser, No. 2013-007847, 2016 WL 6277792, at *3–5 (PTAB Apr. 28, 2016) (precedential) (holding that in a method claim, a step reciting a condition precedent does not need to be performed if the condition precedent is not met) (available at https://www.uspto.gov/sites/default/files/documents/Ex%20parte%20Schulhauser%202016_04_28.pdf; last visited May 13, 2026); see also MPEP § 2111.04(II) (citing Schulhauser).
Prosecution Insights