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 .
DETAILED ACTION
The instant application having Application No.18/891,734 is presented for examination by
the examiner. Claims 1, 2, 4, 10, 16 and 17 are amended. Claims 1-20 have been examined.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 10 and 16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1-8, 10-11 and 16-19 is rejected under 35 U.S.C. § 103 as being unpatentable over Bicket (US 9,445,270 B1) in view of Metke (US 20130117558 A1).
Regarding Claim 1
Bicket discloses:
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 credential of a first network element (Bicket Column 22, Line 63 - Column 23, Line 20: discloses that the WSD 115 (terminal device) acquires a certificate (authorization credential) of the gateway device 120 (first network element)), wherein the authorization credential is used by the terminal device to verify whether a transmission of sensing data to the first network element is authorized (Bicket Column 22, Line 63 - Column 23, Line 20: discloses that the authorization credential (certificate) is used by the terminal device (WSD 115) to verify whether a transmission of sensing data to the first network element (gateway device 120) is authorized, as the WSD 115 confirms at operation 3.6 that the gateway device 120 is authorized to offload sensor data based on the certificate and the public key of the management server stored in the WSD.), and the authorization credential comprises a first digital signature (Bicket Column 23, Lines 42-59: discloses that the authorization credential (certificate) comprises a first digital signature, as the certificate is a digital document including data and a digital signature generated by the management server 140 based on the data and a private key of the management server.); and
authorizing the transmission of the sensing data to the first network element, in a case where the authorization credential is verified successfully based on the first digital signature (Bicket Column 24, Lines 8-15: discloses authorizing the transmission of sensing data to the first network element (gateway device 120) only in a case where the authorization credential (certificate) is verified successfully based on the first digital signature, as the WSD 115 uploads sensor measurements to the gateway device only after confirming that the certificate is authenticated using the management server's public key to verify the digital signature.);
Bicket does not teach the following limitation “the authorization credential further comprises at least one of service identification information or data identification information; the service identification information is used to indicate a service type of the sensing data to be authorized; and the data identification information is used to indicate a data type of the sensing data.” However, in an analogous art, Metke teaches this limitation. Metke (¶[0036], [0040], [0045]) teaches that a digitally signed credential (authorization response extension 300) includes service type attribute fields (302a-302n), each of which includes one or more authorization attributes associated with a specific service type embedded within the signed credential, wherein the service type identification information indicates the type of service for which the credential subject is authorized. Metke further teaches that the authorization attribute type within the credential identifies a class of services or data types available at a given relying party, for example specifying "Voice Service," "Data Services," or "database lookup services." (Metke ¶[0036].) The credential including such service type scoping information is digitally signed to guarantee its integrity and authenticity. (Metke ¶[0040]).
It would have been obvious to one of ordinary skill in the art to modify Bicket's sensor network certificate to further include service identification information or data identification information as taught by Metke, such that the authorization credential indicates the specific service type or data type of the sensing data the gateway device is permitted to receive. Both Bicket and Metke are directed to certificate authorization frameworks wherein a digitally signed credential is used to verify whether a requesting entity is authorized to access specific data or services. The combination merely applies Metke's known service type scoping mechanism to Bicket's sensor network certificate structure to provide granular authorization control over the types of sensing data a gateway device is permitted to receive, yielding predictable results.
Regarding Claim 2
Bicket discloses:
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 (Bicket Column 21, Lines 50 - Column 22, Line 12: discloses that the authorization credential (certificate) further comprises identification information of the first network element (gateway device 120), as the data of the certificate includes the identifier of the gateway device 120 (GW_ID).);
a public key of the first network element; or
an RSA accumulator parameter corresponding to the first network element.
Regarding Claim 3
Bicket discloses:
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 (Bicket Column 22, Lines 64 - Column 23, Line 20: discloses that the terminal device (WSD 115) verifies the first digital signature by using the public key of the credential distributing device (management server 140) to obtain first verification information, as the public key of the management server stored in the WSD enables the verification that the digital signature included in the certificate was generated with the private key of the management server.);
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 (Bicket Column 23, Lines 60 - Column 24, Line 8: discloses that the terminal device (WSD 115) determines 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 the WSD checks that the second identifier in the certificate data matches the sensing device identifier stored in the WSD and authenticates the certificate using the public key of the management server.).
Regarding Claim 4
Metke further discloses authorization credential:
The terminal device according to claim 1, wherein
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 (Metke ¶[0041]: Metke teaches that the relying party verifies the authorization credential based on the digital signature only after comparing the authorization attributes present in the status information object with policy attributes associated with the requested service, such that verification and access proceeds only when the authorization attributes in the credential match the service type supported by the relying party.).
It would have been obvious to one of ordinary skill in the art to modify Bicket's sensor network certificate verification framework to incorporate Metke's service type conditional check such that the terminal device verifies the authorization credential based on the first digital signature only in a case where it supports the advertised service type and/or data type. Both Bicket and Metke are directed to certificate based authorization frameworks wherein a digitally signed credential is used to verify whether a requesting entity is authorized to access specific data or services. The combination merely applies Metke's known service type conditional verification mechanism to Bicket's sensor network certificate structure to ensure that credential verification is only triggered when the terminal device supports the relevant service type or data type, yielding predictable results.
Regarding Claim 5
Bicket discloses:
The terminal device according to claim 4, wherein after the terminal device authorizes the transmission of the sensing data, the terminal device further performs:
transmitting the sensing data corresponding to the service type (Bicket Column 24, Lines 8-15: discloses that after the terminal device (WSD 115) authorizes the transmission of the sensing data, the terminal device further transmits the sensing data corresponding to the service type, as the WSD uploads to the gateway device data indicative of a plurality of sensor measurements taken over time only after confirming that the gateway device is authorized to receive the sensor data .).
Regarding Claim 6
Bicket discloses:
The terminal device according to claim 1, wherein acquiring the authorization credential of the first network element, comprises:
receiving first request information transmitted by the first network element, wherein the first request information is used to request the terminal device to authorize to transmit the sensing data (Bicket Column 22, Line 63 - Column 23, Line 20: discloses that the terminal device (WSD 115) receives first request information transmitted by the first network element (gateway device 120), wherein the first request information is used to request the terminal device to authorize transmission of sensing data, as the gateway device 120 transmits the certificate to the WSD 115 at operation 3.4.); the first request information comprises the authorization credential (Bicket Column 23, Lines 41-59: discloses that the first request information comprises the authorization credential (certificate), as the WSD 115 receives from the gateway device 120 a certificate that was generated by the management server 140 upon a determination that the gateway device 120 and the wireless sensing device 115 are associated.); and
acquiring the authorization credential from the first request information (Column 22, Line 63 - Column 23, Line 20: discloses that the terminal device (WSD 115) acquires the authorization credential from the first request information, as the WSD receives and acquires the certificate directly from the transmission by the gateway device at operation 3.4.).
Regarding Claim 7
Bicket discloses:
The terminal device according to claim 6, 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 (Bicket Column 23, Lines 42-59: discloses that the first request information further comprises a second digital signature, wherein the second digital signature is used by the terminal device to verify an identity of the first network element and is obtained by signing other information in the first request information by a private key of the first network element, as the certificate is transmitted to the WSD 115 with a second digital signature that was generated at the gateway device 120 using the private key of the gateway device.).
Regarding Claim 8
The terminal device according to claim 6, wherein acquiring the authorization credential from the first request information, comprises:
in a case where an identity of the first network element is verified successfully, acquiring the authorization credential from the first request information (Bicket Column 23, Lines 7-20: discloses that the terminal device (WSD 115) acquires the authorization credential from the first request information only in a case where the identity of the first network element (gateway device 120) is verified successfully, as the WSD performs an additional verification to confirm the identity of the gateway device using the public key of the gateway device transmitted in the certificate to authenticate the second digital signature, and only upon confirmation that the gateway device is authenticated does the WSD proceed to acquire and use the authorization credential.).
Regarding Claim 10
Claim 10 is directed to a first network element corresponding to the terminal device limitations recited in claim 1. Claim 10 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 11
Claim 11 is directed to a first network element corresponding to the terminal device limitations recited in claim 7. Claim 11 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 16
Claim 16 is directed to a credential distributing device corresponding to the terminal device limitations recited in claim 1. Claim 16 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 17
Claim 17 is directed to a credential distributing device corresponding to the terminal device limitations recited in claim 2. Claim 17 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 18
Claim 18 is directed to a credential distributing device corresponding to the terminal device limitations recited in claim 8. Claim 18 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Regarding Claim 19
Bicket discloses:
The credential distributing device according to claim 18, wherein the fourth request information comprises a third digital signature; the third digital signature is signed by a private key of the first network element (Bicket Column 22, Lines 53-62: discloses that the fourth request information comprises a third digital signature signed by a private key of the first network element (gateway device 120), as the gateway device digitally signs data including the identifier of the gateway device and the public key of the gateway device with the private key of the gateway device to form a digital signature.); the credential distributing device further performs:
verifying the third digital signature based on a public key of the first network element, to obtain third verification information (Bicket Column 16, Lines 1-25: discloses that the credential distributing device (management server 140) verifies the digital signature based on the public key of the first network element (gateway device 120), as the management server stores the public key of the gateway device in the gateway devices database and uses it to authenticate the identity of the gateway device. .);
if the third verification information is consistent with other information in the fourth request information except the third digital signature, determining that the identity of the first network element is verified successfully (Bicket Column 21, Lines 31-50: discloses that the credential distributing device (management server 140) determines that the identity of the first network element is verified successfully when the verification result is consistent with the other information in the request except the digital signature, as the management server verifies the identity of the gateway device by confirming that the public key of the gateway device can be used to authenticate the digital signature confirming that the gateway device is authenticated.).
Claims 9, 12-15 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Bicket (US 9,445,270 B1) and Metke (US 20130117558 A1) as applied to claim 1, 10 and 16 above, and in further view of Sai (US 2024/0364540 A1).
Regarding Claim 9
Bicket and Metke do not teach the following limitation “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”
However, in an analogous art, Sai teaches acquiring the authorization. Sai (¶202, 211, 217) teaches storing authorization credential implemented as digitally verifiable certificates in a publicly accessible blockchain, and requiring a device to transmit a request to the blockchain node to retrieve certificate data stored within a specific block structure, where the request uses certificate path or dependency tree metadata as the storage location information, and the blockchain node responds by returning the requested certificate to the device.
Given the teaching of Sai, a POSITA would have found it obvious to modify the teaching of Bicket and Metke by enabling the terminal device to request and retrieves its authorization credential from a blockchain node rather that a centralized AAA server. It would have been obvious to for a POSITA to incorporate Sai teaching into their own because a blockchain storage provides well known tamper resistance benefits as well as verifiable certificate lineage. A skilled artisan would naturally substitute Sai’s distributed certificate store into the systems of Bicket and Metke to improve reliability and security using known blockchain techniques, and doing so merely represents the predictable application of established blockchain certificate-management practices to an existing authorization framework (Sai ¶202, 211, 217).
Regarding Claim 12
Bicket and Metke do not teach the following limitation “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”
However, in an analogous art, Sai teaches acquiring the authorization. Sai (¶41, 47, 61-62, 90) teaches that a device sends a request to a blockchain node to retrieve a specific certificate used as the authorization credential where the certificate is stored in a blockchain block along with metadata in a certificate store; the request includes the certificate identifier that acts as the storage-location information within the blockchain and the blockchain node returns the requested credential. Sai (¶47 and 90) also teaches that after a device submits a certificate request to the blockchain, the blockchain node returns the resulting certificate response back to the requester.
Given the teaching of Sai, a POSITA would have found it obvious to modify the teachings of Bicket and Metke by enabling the terminal device to request and retrieves its authorization credential from a blockchain node rather that a centralized AAA server. It would have been obvious to for a POSITA to incorporate Sai teaching into their own because a blockchain storage provides well known tamper resistance benefits as well as verifiable certificate lineage. A skilled artisan would naturally substitute Sai’s distributed certificate store for into the systems of Bicket and Metke improve reliability and security using known blockchain techniques, and doing so merely represents the predictable application of established blockchain certificate-management practices to an existing authorization framework (Sai ¶41, 47, 61-62, 90).
Regarding Claim 13
Bicket and Metke do not teach the following limitation “wherein before the first network element transmits the third request information to the blockchain node, the first network element further performs: transmitting fourth request information to a credential distributing device; wherein the fourth request information is used to request the authorization credential of the first network element”
However, in an analogous art, Sai teaches acquiring the authorization. Sai (¶167-169 and 218) teaches that a device sends a certificate request to the certificate issuing system in order to obtain its own authorization certificate, thereby corresponding to the first network element transmitting fourth request information to a credential distributing device for the purpose of requesting the authorization credential of the first network element.
Given the teaching of Sai, a POSITA would have found it obvious to modify the teachings of Bicket and Metke so that the first network element obtains its authorization credential by transmitting a request to a credential issuing component before sending the credential to the terminal device. Sai teaches that a device sends a certificate request to an issuance service to obtain its authorization certificate. It would have been obvious to adopt this known certificate request workflow to provide a standard secure mechanisms for retrieving the authorization credential prior to use.
Regarding Claim 14
Claim 14 is directed to a credential distributing device corresponding to the terminal device limitations recited in claim 7. Claim 14 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 15
Bicket and Metke do not teach the following limitation “receiving the authorization credential transmitted by the credential distributing device, and/or the storage location information of the authorization credential”
However, in an analogous art, Sai teaches acquiring the authorization. Sai (¶176) teaches receiving an issued authorization credential from the credential-distributing system since the output contains certificates containing all credential attributes is returned to the requested immediately after issuance.
Given the teaching of Sai, a POSITA would have found it obvious to modify the teachings of Bicket and Metke so that the first network element obtains its authorization credential by transmitting a request to a credential issuing component before sending the credential to the terminal device. Sai teaches that a device sends a certificate request to an issuance service to obtain its authorization certificate. It would have been obvious to adopt this known certificate request workflow to provide a standard secure mechanisms for retrieving the authorization credential prior to use.
Regarding Claim 20
Bicket and Metke do not teach the following limitation “wherein the credential distributing device is further configured to perform: transmitting the authorization credential to a blockchain node; receiving storage location information of the authorization credential transmitted by the blockchain node.”
However, in an analogous art, Sai teaches acquiring the authorization. Sai (¶202, 211, 217) teaches transmitting certificate data to a blockchain based metadata store for persistence, and having the blockchain node return the storage location metadata indicating where that credential is stored. The system then stores this returned location information to later retrieve the authorization credential from the blockchain.
Given the teaching of Sai, a POSITA would have found it obvious to modify the teachings of Bicket and Metke by retrieving the authorization credential from a blockchain rather than from an AAA server. Sai teaches storing certificates on a blockchain and retrieving them by sending a request containing blockchain location information. Using Sai’s blockchain storage would have been obvious as it improves integrity and variability of the credential store.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/MICHAEL R VAUGHAN/Primary Examiner, Art Unit 2431
Prosecution Insights