DETAILED ACTION
1. Claims 70-82 are pending in this examination.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
3. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Election/Restrictions
4. Applicant elects Group I without traverse (Claims 70-82) is acknowledged. Claims 83-141 are cancelled.
Specification
5.1. 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. ¶ 122. 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.
5.3. The Specification cites “‘Wood, Gavin, “PoA Private Chains”, Github, November 2015, website: https://github.com/ethereum/guide/blob/master/poa.md.” Spec. ¶ 122. 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.
5.4. 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.
Claim Rejections - 35 USC § 112
6.1. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—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 following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
6.2. Claim 74 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as failing to set forth the subject matter which the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the applicant regards as the invention.
Claim 74, 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 70, line 1 or not.
It is assumed for examination purposes that the limitation refers to the client device introduced in claim 70, line 1. 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).
Double Patenting
7.1. 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 claims at issue 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). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
7.2. Claims 70, 72, 73, 75-80 are provisionally rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1, 5, 39, 52 of copending Application No. 18/809,507.
Although the conflicting claims are not identical, they are not patentably distinct from each other because claims 70, 72, 73, 75-80 are anticipated by claims 1, 5, 39, 52 of the Copending Application.
Claims 1, 5, 39, 52 of the copending Application as shown in the table below contains every element of claims 70, 72, 73, 75-80of the instant application and as such anticipates claims 70, 72, 73, 75-80 of the instant application:
Instant application No. 18931048
Claims: 70, 72, 73, 75-80
Copending Application No. 18/809,507
Claims: 1, 5, 39, 52
70. An access control method performed by a client device, comprising: receiving, from a local proximity interface of a token dispenser device on a local network, a token on a blockchain layer;
presenting, to a node of the local network, a token on a blockchain layer; receiving, from the node, authentication of the token; accessing a local network or a device on the local network;
wherein, as a consequence to the authentication of the token, the device is removed from access to the local network or the device on the local network.
72. (Previously Presented) The access control method as claimed in claim 70, wherein the authentication is proof of authority authentication.
73. (Previously Presented) The access control method as claimed in claim 70, further comprising receiving, from a local proximity interface of a token dispenser device on the local network, the token on the blockchain layer.
Claims 75- 80 same as describe above
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.
1. An access control method, comprising:
presenting, by a client device to a node on a local network, a token on a blockchain layer for authentication of the token by way of proof of authority authentication; and accessing, after the authentication of the token, a specific node on the local network, wherein the specific node includes a storage device configured to store data.
39. (Previously Presented) The access control system as claimed in 38 the access control system as claimed in wherein access to the specific node is disabled after a specified period of time.
52. (Previously Presented) The access control method as claimed in 51 the access control method as claimed in wherein the storage device is a master node which performs the proof of authority authentication.
5. (Original) 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.
Claims: 1, 5, 39, 52 same as describe above
This is a provisional nonstatutory double patenting rejection.
Claim Rejections - 35 USC § 103
8.1. 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.
8.2. Claims 70-82 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application No. 20200351660 to Avetisov et al (“Avetisov”) in view of US Patent Application No. 20150172271 to Barrows et al (“Barrows”).
As per claim 70, Avetisov discloses an access control method performed by a client device, comprising (paragraph [0033]: "access controls"; paragraph [0140]: "client device" and "access control''):
receiving, from a local proximity interface (paragraph [0033], "a user may register the mobile device to a relying device which the user frequently uses, or infrequently uses, while the user is in physical proximity to the relying device) of a token dispenser device on a local network(paragraph [0163]: "Once obtained by the relying device 140, the TGT may be used to obtain one or more service tickets from Ticket Granting Service (TGS), which grant user-level access to network devices or other services. As described above, the authentication server may issue a session to a relying device 140 based on authenticators provided to the authentication server by a mobile device in accordance with a mobile initiated authentication process"),
a token on a blockchain layer (paragraph [0054]: "embodiments may be implemented with a decentralized computing architecture, for instance, on a blockchain-based computing platform, like Ethereum, Cardano, NEO, hyper/edger, or using a similar blockchain-based protocol by which participant entities may be shielded from the risk of a single central authority leveraging a position of lower over the computing architecture to their detriment");
accessing a local network or a device on the local network (paragraph [0156]: "the relying device 140 may control or facilitate control of other devices on a network, which may include the internet or be a local network or physical access infrastructure");
presenting, to a node of the local network, a token on a blockchain layer (paragraph [0048]: "a server or computing node of an authentication system or identity management system performs one or more of these steps in response to receiving credentials operable to identify associated user account information from a remote server or client device")
receiving, from the node, authentication of the token (paragraph [O178]: "the computing environment 200 includes a plurality of computing nodes 201 of a blockchain-based computing platform. In some embodiments, an authority, like the entity operating the authentication server 155, may operate some or all of the computing nodes 201"; paragraph [0316]: "in some cases one or more servers 155, 245 may operate as, or include, a computing node 201, and in some cases, some steps may be peiformed by an authority 130 and some steps by a computing node 201 executing a smart contract'); and
Avetisov does not explicitly disclose however in the same field of endeavor, Barrows discloses wherein, as a consequence to the authentication of the token, the device is removed from access to the local network or the device on the local network ([034] In the instance where confirmed token-A contains valid or expected information, as well as is older than fourteen days, the provider environment
invalidates all tokens that exist for that user and/or client device, deregisters the client device, and authentication fails 318. The user would then be forced to re-register the device and/or re-authenticate by providing any various types of credentials).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Barrows by including the feature of removing a device, in order for Avetisov’s system to ensures that an attacker with a stolen token cannot continue to use the token
indefinitely. in the instance where the actual device is turned off or has no network connection for an extended period of time. Approaches are described for automatically generating new security credentials, such as security tokens, which can involve automatically re-authenticating a user (or client device) using a previous security token issued to that user (or device). The re-authentication can happen without any knowledge and/or action on the part of the user. The re-authentication mechanism can invalidate and/or keep track of the previous security token, such that when a subsequent request is received that includes the previous security token, the new security token can be invalidated, and the user caused to re-authenticate, as receiving more than one request with the previous security token can be indicative that the user's token might have been stolen (Barrows, abstract).
As per claim 71, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 70, wherein the presenting is performed in response to receiving selection of a dedicated button on the client device (Avetisov, [0331], also see [0109], [0044]).
As per claim 72, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 70, wherein the authentication is proof of authority authentication (Avetisov, [0178],[0316]).
As per claim 73, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 70, further comprising receiving, from a local proximity interface of a token dispenser device on the local network, the token on the blockchain layer (Avetisov, [0033],[0054], [0156]).
As per claim 74, the combination of Barrows and Avetisov discloses the client device, comprising: a processor; and memory containing instructions which, when executed by the processor, cause the processor to perform the access control method as claimed in claim 70 (Avetisov, [0012],[0399]).
As per claim 75, Avetisov discloses an access control method, comprising (paragraph [0033]: "access controls"; paragraph [0140]: "client device" and "access control''):
providing, from a node to a client device, access by the client device to a local network or a device on the local network (paragraph [0156], "the relying device 140 may control or facilitate control of other devices on a network, which may include the internet or be a local network or physical access infrastructure", also see paragraph [0033], [0163]);
receiving, at the node of the local network from the client device, presentation of a token on a blockchain layer (paragraph [0048]: "a server or computing node of an authentication system or identity management system performs one or more of these steps in response to receiving credentials operable to identify associated user account information from a remote server or client device", also see [0054])
requesting, from the node, authentication of the token (paragraph [O178]: "the computing environment 200 includes a plurality of computing nodes 201 of a blockchain-based computing platform. In some embodiments, an authority, like the entity operating the authentication server 155, may operate some or all of the computing nodes 201"; paragraph [0316]: "in some cases one or more servers 155, 245 may operate as, or include, a computing node 201, and in some cases, some steps may be peiformed by an authority 130 and some steps by a computing node 201 executing a smart contract').
Avetisov does not explicitly disclose however in the same field of endeavor, Barrows removing, as a consequence to the authentication, the access by the client device ([034] In the instance where confirmed token-A contains valid or expected information, as well as is older than fourteen days, the provider environment
invalidates all tokens that exist for that user and/or client device, deregisters the client device, and authentication fails 318. The user would then be forced to re-register the device and/or re-authenticate by providing any various types of credentials).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Barrows by including the feature of removing a device, in order for Avetisov’s system to ensures that an attacker with a stolen token cannot continue to use the token indefinitely. in the instance where the actual device is turned off or has no network connection for an extended period of time. Approaches are described for automatically generating new security credentials, such as security tokens, which can involve automatically re-authenticating a user (or client device) using a previous security token issued to that user (or device). The re-authentication can happen without any knowledge and/or action on the part of the user. The re-authentication mechanism can invalidate and/or keep track of the previous security token, such that when a subsequent request is received that includes the previous security token, the new security token can be invalidated, and the user caused to re-authenticate, as receiving more than one request with the previous security token can be indicative that the user's token might have been stolen (Barrows, abstract).
As per claim 76, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 75, further comprising sending, from a local proximity interface of a token dispenser device on the local network, to the client device, the token on the blockchain layer (Avetisov, [0033],[0054], [0156]).
As per claim 77, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 75, wherein the authentication is proof of authority authentication (Avetisov, [0178],[0316]).
As per claim 78, Avetisov discloses an access control method, comprising (paragraph [0033], "access controls"; paragraph [0140]: "client device" and "access control''):
receiving, at a node of a local network from the client device, presentation of a token on a blockchain layer (paragraph [0048]: "a server or computing node of an authentication system or identity management system performs one or more of these steps in response to receiving credentials operable to identify associated user account information from a remote server or client device" also see [0033])
requesting, from the node, authentication of the token (paragraph [O178]: "the computing environment 200 includes a plurality of computing nodes 201 of a blockchain-based computing platform. In some embodiments, an authority, like the entity operating the authentication server 155, may operate some or all of the computing nodes 201"; paragraph [0316]: "in some cases one or more servers 155, 245 may operate as, or include, a computing node 201, and in some cases, some steps may be peiformed by an authority 130 and some steps by a computing node 201 executing a smart contract');
receiving, from a user input device (for action) (Avetisov, [0080]).
Avetisov does not explicitly disclose however in the same field of endeavor, Barrows discloses an instruction for removal of the access of the client device on the local network; and removing the access of the client device on the local network ([034] In the instance where confirmed token-A contains valid or expected information, as well as is older than fourteen days, the provider environment
invalidates all tokens that exist for that user and/or client device, deregisters the client device, and authentication fails 318. The user would then be forced to re-register the device and/or re-authenticate by providing any various types of credentials).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Barrows by including the feature of removing a device, in order for Avetisov’s system to ensures that an attacker with a stolen token cannot continue to use the token
indefinitely. in the instance where the actual device is turned off or has no network
connection for an extended period of time. Approaches are described for automatically generating new security credentials, such as security tokens, which can involve automatically re-authenticating a user (or client device) using a previous security token issued to that user (or device). The re-authentication can happen without any knowledge and/or action on the part of the user. The re-authentication mechanism can invalidate and/or keep track of the previous security token, such that when a subsequent request is received that includes the previous security token, the new security token can be invalidated, and the user caused to re-authenticate, as receiving more than one request with the previous security token can be indicative that the user's token might have been stolen (Barrows, abstract).
As per claim 79, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 78, further comprising sending, via a local proximity interface of a token dispenser device to the client device, the token on the blockchain layer (Avetisov, [0033],[0054], [0156]).
As per claim 80, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 78, wherein the authentication is proof of authority authentication (Avetisov, [0178],[0316]).
As per claim 81, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 78, wherein the user input device is at the node or another node of the blockchain layer (Avetisov, [0080]).
As per claim 82, the combination of Barrows and Avetisov discloses the access control method as claimed in claim 78, wherein the user input device is on the local network (Avetisov, [0080]).
9.1. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art discloses many of the claim features (See PTO-form 892).
9.2. a). US Patent Application No. 20180302222 to Agrawal et al., discloses an electronic device is provided. The electronic device includes a memory, a communication circuitry, and a processor configured to transmit, a first signal for requesting to access an external device, to the external device, receive, a second signal for requesting to provide a token stored in the electronic device, from the external device, the token being generated based on at least part of a block chain including at least one block that is respectively associated with at least one external device that has been accessed by the electronic device, in response to the reception, transmit, information on the token, to the external device, receive, a third signal indicating allowed the access, from the external device, the third signal being transmitted from the external device in response to identifying, by the external device, to validate the token in all of the plurality of external devices, and access the external device based on the third signal.
b). US Patent Application No. 20220043917 to Rolle et al., discloses systems and processes for managing information statements for service provider assets are provided herein. A request may be received from a user device to access an asset of a service provider through an application of the user device, and the service provider may send, to a statement tracking module of the user device, data corresponding to an information statement associated with the asset. The service provider may receive, from the statement tracking module of the user device, a response including an indication of user accessibility to the information statement, and store the response from the statement tracking module. Access to the asset through the application of the user device may be selectively allowed based on the response, such that access to the asset is allowed responsive to the response including a signed version of the information statement, a user identifier, and a timestamp.
Conclusion
10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARUNUR RASHID whose telephone number is (571)270-7195. The examiner can normally be reached 9 AM to 5PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
HARUNUR . RASHID
Primary Examiner
Art Unit 2497
/HARUNUR RASHID/Primary Examiner, Art Unit 2497
Prosecution Insights