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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 24 September 2024 and 13 January 2026 have been considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 20 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 20 recites “A chip, comprising: a processor, wherein the processor is configured to execute one or more computer programs stored from a memory, which causes a device equipped with the chip to perform the method of claim 1.” The element being claimed is a chip with hardware that is configured to perform the method of Claim 1. Claim 20 does not actually require the performance of the method of claim 1, only that the chip be configured to perform the method. Thus, claim 20 does not require all the limitations of its parent claim 1 and is an improper dependent claim under 35 USC 112(d). Claim 20 is a malformed independent claim masquerading as a dependent claim. Applicant may cancel the claim, amend the claim to place the claim in proper dependent form, rewrite the claim in independent form, or present a sufficient showing that the dependent claim complies with the statutory requirements.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claims 1-3 and 5-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication No. 2021/0176039 by Fang et al.
As to claims 1, 9 and 20, Fang discloses a method for implementing security, applicable to a first device, the method comprising:
acquiring an authorization certification of a first network element (Fang: Page 4, Sec 30; External device 110), wherein the authorization certification is used to verify whether the first network element is authorized to receive data, the data being originated from at least one second device associated with the first device (Fang: Page 4, Sec 30; “When the external device 110 is requesting the data for an IoT device 108, the blockchain node 102 may receive the data request. In some cases, the external device 110 or a user thereof may be authenticated prior to identifying permission for the external device 110 (e.g., or user, as applicable). In such cases, the data request may include authentication data and the blockchain node 102 may perform an authentication check using the included authentication data. Any suitable type of authentication may be performed. For instance, in one example, the external device 110 may have a cryptographic key pair and may generate a digital signature using the private key of the cryptographic key pair, where the blockchain node 102 may validate the digital signature using a public key of the cryptographic key pair.”); and
the authorization certification comprises a first digital signature (Fang: Page 4, Sec 30; “When the external device 110 is requesting the data for an IoT device 108, the blockchain node 102 may receive the data request. In some cases, the external device 110 or a user thereof may be authenticated prior to identifying permission for the external device 110 (e.g., or user, as applicable). In such cases, the data request may include authentication data and the blockchain node 102 may perform an authentication check using the included authentication data. Any suitable type of authentication may be performed. For instance, in one example, the external device 110 may have a cryptographic key pair and may generate a digital signature using the private key of the cryptographic key pair, where the blockchain node 102 may validate the digital signature using a public key of the cryptographic key pair.”); and
determining that the first network element is authorized to receive the data from the at least one second device based on a successful verification on the authorization certification based on the first digital signature (Fang: Page 4, Sec 31; “f the external device 110 and/or user are successfully authenticated, if applicable, then, the blockchain node 102 may verify the permission of the external device 110 (e.g., or user, if applicable) to access the data associated with the IoT device 108 (e.g., if specified using a device identifier, or all IoT devices 108 whose data is stored in the blockchain). Verification of the permission may include performing a check to see if the external identifier is approved for access to the IoT device's data in the data store. In cases where the system 100 includes an active directory system 112, the active directory system 112 may be queried for the verification”).
As to claims 9 and 20 only, Fang additionally discloses a processor; and a memory (Fang: Fig 5).
As to claim 14, Fang discloses a first network element, comprising:
a processor(Fang: Fig 5); and
a memory storing one or more computer programs, which, when executed by the processor(Fang: Fig 5), cause the first network element to:
transmit second request information to a first device, wherein the second request information is used to request the first device to authorize the first network element to acquire data from at least one second device, the at least one second device being associated with the first device (Fang: Page 4, Sec 30; External device 110), wherein the authorization certification is used to verify whether the first network element is authorized to receive data, the data being originated from at least one second device associated with the first device (Fang: Page 4, Sec 30; “When the external device 110 is requesting the data for an IoT device 108, the blockchain node 102 may receive the data request. In some cases, the external device 110 or a user thereof may be authenticated prior to identifying permission for the external device 110 (e.g., or user, as applicable). In such cases, the data request may include authentication data and the blockchain node 102 may perform an authentication check using the included authentication data. Any suitable type of authentication may be performed. For instance, in one example, the external device 110 may have a cryptographic key pair and may generate a digital signature using the private key of the cryptographic key pair, where the blockchain node 102 may validate the digital signature using a public key of the cryptographic key pair.”);
wherein the second request information comprises an authorization certification, the authorization certification being used for the first device to verify whether the first network element is authorized to receive the data from the at least one second device; and the authorization certification being verified based on a first digital signature included in the authorization certification (Fang: Page 4, Sec 31; “f the external device 110 and/or user are successfully authenticated, if applicable, then, the blockchain node 102 may verify the permission of the external device 110 (e.g., or user, if applicable) to access the data associated with the IoT device 108 (e.g., if specified using a device identifier, or all IoT devices 108 whose data is stored in the blockchain). Verification of the permission may include performing a check to see if the external identifier is approved for access to the IoT device's data in the data store. In cases where the system 100 includes an active directory system 112, the active directory system 112 may be queried for the verification”).
As to claims 2, 11 and 15, Fang further discloses wherein the authorization certification comprises at least one of: service identification information, wherein the service identification information indicates a service type of the data; data identification information, wherein the data identification information indicates a data type of the data; identification information of a certification issuing device; a public key of the certification issuing device; identification information of the first network element; a public key of the first network element; or an RSA accumulator parameter corresponding to the first network element (Fang: Page 4, Sec 30-31; public key).
As to claim 3, Fang further discloses wherein the first digital signature is acquired by signing with a private key of a certification issuing device (Fang: Page 4, Sec 30-31; public/private key pair); and the method further comprises:
acquiring first verification information by verifying the first digital signature using a public key of the certification issuing device (Fang: Page 4, Sec 30-31; “For instance, in one example, the external device 110 may have a cryptographic key pair and may generate a digital signature using the private key of the cryptographic key pair, where the blockchain node 102 may validate the digital signature using a public key of the cryptographic key pair); and
determining that the authorization certification is verified successfully in a case that the first verification information is consistent with information other than the first digital signature in the authorization certification (Fang: Page 4, Sec 30-31; “In a second example, the authentication data may be a username and password for a registered user, which may be checked by the blockchain node 102. In a third example, biometric data may be supplied by a user of the external device 110, which may be checked against a database of registered users' biometric information”).
As to claim 5, Fang further discloses wherein the authorization certification comprises service identification information and/or data identification information, the service identification information indicating a service type of the data, and the data identification information indicating a data type of the data; and the method further comprises: verifying the authorization certification based on the first digital signature in a case that any one of the at least one second device supports the service type and/or the data type (Fang: Page 7, Sec 51; “ In step 402, a data message may be received by a receiver (e.g., the receiving device 202) of a node (e.g., blockchain node 102) in a blockchain network (e.g., the blockchain network 104) from an internet of things (IoT) device (e.g., IoT device 108), the data message being formatted according to an IoT messaging protocol and including at least a device identifier associated with the IoT device and encrypted data. In step 404, a new block may be generated by a processor (e.g., the generation module 216) of the node, where the new block includes a block header and one or more data values, the one or more data values including the received data message and the block header including at least a timestamp, a block reference value, and a data reference value based on the one or more data values. In step 406, the generated new block may be transmitted by a transmitter (e.g., the transmitting device 224) of the node to one or more additional nodes in the blockchain network.”).
As to claim 6, Fang further discloses wherein upon determining that the first network element is authorized to receive the data from the at least one second device, the method further comprises: receiving first indication information from the first network element, wherein the first indication information indicates at least one second device that needs to transmit data to the first network element in the at least one second device; and transmitting first request information to the at least one second device indicated by the first indication information, wherein the first request information is used to request data of the at least one second device indicated by the first indication information (Fang: Page 4, Sec 31; “If the external device 110 and/or user are successfully authenticated, if applicable, then, the blockchain node 102 may verify the permission of the external device 110 (e.g., or user, if applicable) to access the data associated with the IoT device 108 (e.g., if specified using a device identifier, or all IoT devices 108 whose data is stored in the blockchain). Verification of the permission may include performing a check to see if the external identifier is approved for access to the IoT device's data in the data store. In cases where the system 100 includes an active directory system 112, the active directory system 112 may be queried for the verification. For instance, in one example, the blockchain node 102 may transmit the device identifier and external identifier to the active directory system 112, where the active directory system 112 may perform the check and provide a result (e.g., approved or denied) to the blockchain node. In another example, the blockchain node 102 may transmit the device identifier for the IoT device 108 to the active directory system 112, which may return a list of all external identifiers approved for access to the IoT device's data, where the blockchain node 102 may check the list to determine if the external device 110 is authorized.”).
As to claim 7, Fang further discloses further comprising: receiving data from the at least one second device indicated by the first indication information; and transmitting the data to the first network element (Fang: Pages 4-5, Sec 33; “The methods and systems discussed herein enable data transfers from IoT devices 108 to external devices 110 in a manner that is secured via the use of a blockchain. A blockchain enables an immutable and scalable solution that provides for protection and auditability of data transfers and access. The use of permissions, either directly by the blockchain network 104 or through an active directory system 112, ensure that only authorized external devices 110 or users can access data of IoT devices 108, where encryption is also used to ensure that transferred data is only readable by external devices 110 with proper keys, to provide for a second layer of security. As such, the methods and systems discussed herein provide for significantly higher security than traditional systems with a solution that is low cost, easy to adopt, and scalable to any size of network and number of IoT devices 108.”).
As to claim 8, Fang further discloses wherein: the authorization certification comprises service identification information and/or data identification information, the service identification information indicating a service type of the data; and transmitting the first request information to the at least one second device indicated by the first indication information comprises: transmitting the first request information to a second device supporting the service type and/or a data type in the at least one second device indicated by the first indication information (Fang: Page 7, Sec 51; “ In step 402, a data message may be received by a receiver (e.g., the receiving device 202) of a node (e.g., blockchain node 102) in a blockchain network (e.g., the blockchain network 104) from an internet of things (IoT) device (e.g., IoT device 108), the data message being formatted according to an IoT messaging protocol and including at least a device identifier associated with the IoT device and encrypted data. In step 404, a new block may be generated by a processor (e.g., the generation module 216) of the node, where the new block includes a block header and one or more data values, the one or more data values including the received data message and the block header including at least a timestamp, a block reference value, and a data reference value based on the one or more data values. In step 406, the generated new block may be transmitted by a transmitter (e.g., the transmitting device 224) of the node to one or more additional nodes in the blockchain network.”).
As to claim 10, Fang further discloses wherein the one or more computer programs, when executed by the processor, further cause the first device to: receive second request information from the first network element, wherein the second request information is used to request the first device to authorize the first network element to acquire the data from the at least one second device, and the second request information comprises the authorization certification; and acquire the authorization certification from the second request information (Fang: Page 4, Sec 31; “If the external device 110 and/or user are successfully authenticated, if applicable, then, the blockchain node 102 may verify the permission of the external device 110 (e.g., or user, if applicable) to access the data associated with the IoT device 108 (e.g., if specified using a device identifier, or all IoT devices 108 whose data is stored in the blockchain). Verification of the permission may include performing a check to see if the external identifier is approved for access to the IoT device's data in the data store. In cases where the system 100 includes an active directory system 112, the active directory system 112 may be queried for the verification. For instance, in one example, the blockchain node 102 may transmit the device identifier and external identifier to the active directory system 112, where the active directory system 112 may perform the check and provide a result (e.g., approved or denied) to the blockchain node. In another example, the blockchain node 102 may transmit the device identifier for the IoT device 108 to the active directory system 112, which may return a list of all external identifiers approved for access to the IoT device's data, where the blockchain node 102 may check the list to determine if the external device 110 is authorized.”).
As to claim 12, Fang further discloses wherein the one or more computer programs, when executed by the processor, further cause the first device to: acquire the authorization certification from the second request information based on a successful verification on an identity of the first network element, wherein the second request information further comprises a second digital signature acquired by signing with a private key of the first network element; and the one or more computer programs, when executed by the processor, further cause the first device to: acquire second verification information by verifying the second digital signature using a public key of the first network element; and determine that the identity of the first network element is verified successfully in a case that the second verification information is consistent with information other than the second digital signature in the second request information (Fang: Page 4, Sec 31; “If the external device 110 and/or user are successfully authenticated, if applicable, then, the blockchain node 102 may verify the permission of the external device 110 (e.g., or user, if applicable) to access the data associated with the IoT device 108 (e.g., if specified using a device identifier, or all IoT devices 108 whose data is stored in the blockchain). Verification of the permission may include performing a check to see if the external identifier is approved for access to the IoT device's data in the data store. In cases where the system 100 includes an active directory system 112, the active directory system 112 may be queried for the verification. For instance, in one example, the blockchain node 102 may transmit the device identifier and external identifier to the active directory system 112, where the active directory system 112 may perform the check and provide a result (e.g., approved or denied) to the blockchain node. In another example, the blockchain node 102 may transmit the device identifier for the IoT device 108 to the active directory system 112, which may return a list of all external identifiers approved for access to the IoT device's data, where the blockchain node 102 may check the list to determine if the external device 110 is authorized.”).
As to claim 13, Fang further discloses wherein the one or more computer programs, when executed by the processor, further cause the first device to: transmit third request information to a blockchain node, wherein the third request information is used to request the authorization certification of the first network element, the authorization certification being stored in a block of the blockchain node; and the third request information comprises storage location information of the authorization certification in the blockchain node; and receive the authorization certification from the blockchain node (Fang: Page 4, Sec 31; “If the external device 110 and/or user are successfully authenticated, if applicable, then, the blockchain node 102 may verify the permission of the external device 110 (e.g., or user, if applicable) to access the data associated with the IoT device 108 (e.g., if specified using a device identifier, or all IoT devices 108 whose data is stored in the blockchain). Verification of the permission may include performing a check to see if the external identifier is approved for access to the IoT device's data in the data store. In cases where the system 100 includes an active directory system 112, the active directory system 112 may be queried for the verification. For instance, in one example, the blockchain node 102 may transmit the device identifier and external identifier to the active directory system 112, where the active directory system 112 may perform the check and provide a result (e.g., approved or denied) to the blockchain node. In another example, the blockchain node 102 may transmit the device identifier for the IoT device 108 to the active directory system 112, which may return a list of all external identifiers approved for access to the IoT device's data, where the blockchain node 102 may check the list to determine if the external device 110 is authorized.”).
As to claim 16, Fang further discloses wherein the one or more computer programs, when executed by the processor, further cause the first network element to: receive data from the first device, wherein the data is transmitted to the first device by the at least one second device; or receive data from the at least one second device (Fang: Page 4, Sec 31; “If the external device 110 and/or user are successfully authenticated, if applicable, then, the blockchain node 102 may verify the permission of the external device 110 (e.g., or user, if applicable) to access the data associated with the IoT device 108 (e.g., if specified using a device identifier, or all IoT devices 108 whose data is stored in the blockchain). Verification of the permission may include performing a check to see if the external identifier is approved for access to the IoT device's data in the data store. In cases where the system 100 includes an active directory system 112, the active directory system 112 may be queried for the verification. For instance, in one example, the blockchain node 102 may transmit the device identifier and external identifier to the active directory system 112, where the active directory system 112 may perform the check and provide a result (e.g., approved or denied) to the blockchain node. In another example, the blockchain node 102 may transmit the device identifier for the IoT device 108 to the active directory system 112, which may return a list of all external identifiers approved for access to the IoT device's data, where the blockchain node 102 may check the list to determine if the external device 110 is authorized.”).
As to claim 17, Fang further discloses wherein the one or more computer programs, when executed by the processor, further cause the first network element to: transmit fourth request information to a blockchain node, wherein the fourth request information is used to request the authorization certification of the first network element, the authorization certification being stored in a block of the blockchain node, and the fourth request information comprises storage location information of the authorization certification in the blockchain node; and receive the authorization certification from the blockchain node (Fang: Pages 4-5, Sec 33; “The methods and systems discussed herein enable data transfers from IoT devices 108 to external devices 110 in a manner that is secured via the use of a blockchain. A blockchain enables an immutable and scalable solution that provides for protection and auditability of data transfers and access. The use of permissions, either directly by the blockchain network 104 or through an active directory system 112, ensure that only authorized external devices 110 or users can access data of IoT devices 108, where encryption is also used to ensure that transferred data is only readable by external devices 110 with proper keys, to provide for a second layer of security. As such, the methods and systems discussed herein provide for significantly higher security than traditional systems with a solution that is low cost, easy to adopt, and scalable to any size of network and number of IoT devices 108.”).
As to claim 18, Fang further discloses wherein the one or more computer programs, when executed by the processor, further cause the first network element to: transmit fifth request information to a certification issuing device, wherein the fifth request information is used to request the authorization certification of the first network element (Fang: Page 4, Sec 30; External device 110), wherein the authorization certification is used to verify whether the first network element is authorized to receive data, the data being originated from at least one second device associated with the first device (Fang: Page 4, Sec 30; “When the external device 110 is requesting the data for an IoT device 108, the blockchain node 102 may receive the data request. In some cases, the external device 110 or a user thereof may be authenticated prior to identifying permission for the external device 110 (e.g., or user, as applicable). In such cases, the data request may include authentication data and the blockchain node 102 may perform an authentication check using the included authentication data. Any suitable type of authentication may be performed. For instance, in one example, the external device 110 may have a cryptographic key pair and may generate a digital signature using the private key of the cryptographic key pair, where the blockchain node 102 may validate the digital signature using a public key of the cryptographic key pair.”).
As to claim 19, Fang further discloses wherein the fifth request information comprises at least one of: service identification information, wherein the service identification information indicates a service type of the data; identification information of the first network element; a public key of the first network element; data identification information; or a third digital signature, wherein the third digital signature is acquired by signing with a private key of the first network element (Fang: Page 4, Sec 30-31; public key).
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 4 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2021/0176039 by Fang et al. in view of U.S. Patent Application Publication No. 2020/0366667 by Cebe et al.
As to claim 4, Fang discloses all recited elements of claim 1 from which claim 4 depends.
Fang does not expressly disclose wherein: the authorization certification comprises an RSA accumulator parameter corresponding to the first network element; and determining that the first network element is authorized to receive the data from the at least one second device based on the successful verification on the authorization certification based on the first digital signature comprises: verifying, based on the first digital signature, whether the authorization certification is revoked based on the RSA accumulator parameter based on the successful verification on the authorization certification; and determining that the first network element is authorized to receive the data from the at least one second device in a case that the authorization certification is not revoked.
Cebe discloses wherein: the authorization certification comprises an RSA accumulator parameter corresponding to the first network element; and determining that the first network element is authorized to receive the data from the at least one second device based on the successful verification on the authorization certification based on the first digital signature comprises: verifying, based on the first digital signature, whether the authorization certification is revoked based on the RSA accumulator parameter based on the successful verification on the authorization certification; and determining that the first network element is authorized to receive the data from the at least one second device in a case that the authorization certification is not revoked (Cebe: Page 3, Sec 21: “Embodiments of the subject invention provide communication-efficient revocation systems and schemes for AMI networks by using RSA accumulators. An RSA accumulator is a cryptographic tool that is able to represent a set of values with a single accumulator value (i.e., digest a set into a single value) (see also Camenisch et al., “Dynamic accumulators and application to efficient revocation of anonymous credentials,” in Crypto, vol. 2442. Springer, 2002, pp. 61-76; which is hereby incorporated by reference herein in its entirety). Moreover, it provides a mechanism to check whether an element is in the set or not, which implicitly means that cryptographic accumulators can be used for efficient membership testing. RSA accumulators are advantageous due to their size, and they can be adapted by introducing several novel elements. Specifically, an accumulator manager within the utility company (UC) can be tasked with collection of CRLs from CAs and accumulating these CRLs (i.e., revoked certificates' serial numbers) to a single accumulator value that can then be distributed to the smart meters. Along with the accumulator value, a customized non-revoked proof can also be introduced and distributed to allow/enable a smart meter to check whether another meter's certificate is revoked without a need to refer to the CRL file.”).
Fang and Cebe are analogous art because they are from the common area of network authentication.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the RSA accumulator of Cebe in the system of Fang. The rationale would have been to check credentials use (Cebe: Page 3, Sec 21).
Double Patenting
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). 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); 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 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 § 2146 et seq. 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 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claims 1-3, 5, 9-11, 14-15 and 17 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/891734 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because thew claims of the instant application and the claims of the copending application are complementary obvious variations of one another.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
As to claims 1, 9, 14 and 20, the ‘734 Application discloses a method/device/network element for implementing security, applicable to a first device, the method comprising (Claim 1: A terminal device, comprising a processor and a memory, wherein the memory is configured to store a computer program, the processor is configured to invoke and execute the computer program stored in the memory, to cause the terminal device to perform):
acquiring an authorization certification of a first network element, wherein the authorization certification is used to verify whether the first network element is authorized to receive data, the data being originated from at least one second device associated with the first device (Claim 1: acquiring an authorization credential of a first network element, wherein the authorization credential is used by the terminal device to verify whether a transmission of sensing data is authorized); and
the authorization certification comprises a first digital signature (Claim 1: and the authorization credential comprises a first digital signature); and
determining that the first network element is authorized to receive the data from the at least one second device based on a successful verification on the authorization certification based on the first digital signature (Claim 1: and authorizing the transmission of the sensing data, in a case where the authorization credential is verified successfully based on the first digital signature).
As to claims 2, 11 and 15, the ‘734 Application discloses the method according to claim 1, wherein the authorization certification comprises at least one of: service identification information, wherein the service identification information indicates a service type of the data; data identification information, wherein the data identification information indicates a data type of the data; identification information of a certification issuing device; a public key of the certification issuing device; identification information of the first network element; a public key of the first network element; or an RSA accumulator parameter corresponding to the first network element (Claim 2: The terminal device according to claim 1, wherein the authorization credential further comprises at least one of: service identification information; identification information of a credential distributing device; a public key of the credential distributing device; identification information of the first network element; a public key of the first network element; an RSA accumulator parameter corresponding to the first network element; or data identification information).
As to claim 3, the ‘734 Application discloses the method according to claim 1, wherein the first digital signature is acquired by signing with a private key of a certification issuing device; and the method further comprises: acquiring first verification information by verifying the first digital signature using a public key of the certification issuing device; and determining that the authorization certification is verified successfully in a case that the first verification information is consistent with information other than the first digital signature in the authorization certification (Claim 3: The terminal device according to claim 1, wherein the first digital signature is signed by a private key of a credential distributing device; the terminal device further performs: verifying the first digital signature by using a public key of the credential distributing device, to obtain first verification information; determining that the authorization credential is verified successfully, if the first verification information is consistent with other information in the authorization credential except the first digital signature).
As to claim 5, the ‘734 Application discloses the method according to claim 1, wherein the authorization certification comprises service identification information and/or data identification information, the service identification information indicating a service type of the data, and the data identification information indicating a data type of the data; and the method further comprises: verifying the authorization certification based on the first digital signature in a case that any one of the at least one second device supports the service type and/or the data type (Claim 4: The terminal device according to claim 1, wherein the authorization credential comprises service identification information and/or data identification information; the service identification information is used to indicate a service type of the sensing data to be authorized; the data identification information is used to indicate a data type of the sensing data; the terminal device further performs: in a case where the terminal device supports the service type and/or the data type, verifying the authorization credential based on the first digital signature).
As to claim 10, the ‘734 Application discloses the first device according to claim 9, wherein the one or more computer programs, when executed by the processor, further cause the first device to: receive second request information from the first network element, wherein the second request information is used to request the first device to authorize the first network element to acquire the data from the at least one second device, and the second request information comprises the authorization certification; and acquire the authorization certification from the second request information (Claim 9: The terminal device according to claim 1, wherein acquiring the authorization credential, comprises: transmitting a second request information to a blockchain node, wherein the second request information is used to request the authorization credential of the first network element; the authorization credential is stored in a block of the blockchain node; the second request information comprises storage location information of the authorization credential in the blockchain node; receiving the authorization credential transmitted by the blockchain node).
As to claim 12, the ‘734 Application discloses the first device according to claim 10, wherein the one or more computer programs, when executed by the processor, further cause the first device to: acquire the authorization certification from the second request information based on a successful verification on an identity of the first network element, wherein the second request information further comprises a second digital signature acquired by signing with a private key of the first network element; and the one or more computer programs, when executed by the processor, further cause the first device to: acquire second verification information by verifying the second digital signature using a public key of the first network element; and determine that the identity of the first network element is verified successfully in a case that the second verification information is consistent with information other than the second digital signature in the second request information (Clam 11: The first network element according to claim 10, wherein the first request information further comprises at least one of: identification information of the first network element; identification information of the terminal device; a channel parameter, wherein the channel parameter is used to establish a trusted channel between the first network element and the terminal device; a public key of the first network element; or a second digital signature, wherein the second digital signature is used by the terminal device to verify an identity of the first network element, the second digital signature is obtained by signing other information in the first request information by a private key of the first network element).
As to claim 13, the ‘734 Application discloses the first device according to claim 9, wherein the one or more computer programs, when executed by the processor, further cause the first device to: transmit third request information to a blockchain node, wherein the third request information is used to request the authorization certification of the first network element, the authorization certification being stored in a block of the blockchain node; and the third request information comprises storage location information of the authorization certification in the blockchain node; and receive the authorization certification from the blockchain node (Claim 12: The first network element according to claim 10, wherein before the first network element transmits the first request information to the terminal device, the first network element further performs: transmitting a third request information to a blockchain node; wherein the third request information is used to request the authorization credential of the first network element; the authorization credential is stored in a block of the blockchain node; the third request information comprises storage location information of the authorization credential in the blockchain node; receiving the authorization credential transmitted by the blockchain node).
As to claim 17, the ‘734 Application discloses the first network element according to claim 14, wherein the one or more computer programs, when executed by the processor, further cause the first network element to: transmit fourth request information to a blockchain node, wherein the fourth request information is used to request the authorization certification of the first network element, the authorization certification being stored in a block of the blockchain node, and the fourth request information comprises storage location information of the authorization certification in the blockchain node; and receive the authorization certification from the blockchain node (Clam 9: The terminal device according to claim 1, wherein acquiring the authorization credential, comprises: transmitting a second request information to a blockchain node, wherein the second request information is used to request the authorization credential of the first network element; the authorization credential is stored in a block of the blockchain node; the second request information comprises storage location information of the authorization credential in the blockchain node; receiving the authorization credential transmitted by the blockchain node).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL S MCNALLY whose telephone number is (571)270-1599. The examiner can normally be reached Monday-Friday, 8:30 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, Jeffrey L Nickerson can be reached at (469)295-9235. 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.
MICHAEL S. MCNALLY
Primary Examiner
Art Unit 2432
/Michael S McNally/Primary Examiner, Art Unit 2432