DETAILED ACTION
The present application 18/117,209 titled, SYSTEM AND METHOD FOR SECURE APPROVAL OF OPERATIONS REQUESTED BY A DEVICE MANAGEMENT SYSTEM, with claims 1-9 and 11-24 with an effective filing date of 03/03/2023. The claims are drawn to a system, an apparatus, and a method for managing secure device operations are being examined under the first inventor to file provisions of the AIA .
This action is in response to the claims and remarks filed 8/27/2025. Claims 1-9 and 11-24 are pending. Claims 1 (a machine), 14 (a method), and 21 (a machine) are independent.
Response to Arguments
Applicant’s arguments, see page 7, filed 8/27/2025, with respect to the 112(b) rejection of claims 12, 19, 20, and 24 have been fully considered and are persuasive. The rejection has been withdrawn.
Applicant’s arguments, see page 7, filed 8/27/2025, with respect to the rejection(s) of claim(s) 1, 2, 4, 6, 7, 9, 10, 12-15, 18, 20, 21, 23, and 24 under Stern (US 9,819,661) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Stern (US 9819661 B2 filed: 09/12/2013), in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019).
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “management module configured to” on line 4 and “the signatory module configured to” on line 6 in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim(s) 1-2, 4, 6-7, 9, 12-15, 18, 21 and 23-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 filed: 09/12/2013), in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019).
Regarding claim 1, Stern teaches the system for device management and authorization.
Stern teaches:
A system for secure approval of an operation requested by a device management system, the system comprising:
a managed device having information indicative of an authorization key; (Col. 4 line 61 – Col. 5 line 8 discloses a device with secure element 64 used as a keystore for PKI, encryption keys and passwords.), the information indicative of the authorization key is associated with a public key infrastructure (PKI) environment; (Col. 12 line 24 – Col. 13 line 49 and Col. 17 lines 4-15 disclose a PKI environment for communication between device, manager, and authentication server.)
a management module configured to manage operations performed by the managed device, the management module configured to communicate with a signatory module; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will generate and transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
the signatory module configured to receive an operation request associated with the operation, the signatory module further configured to enable authorization of the operation request through the association of the authorization key with the operation request and generate an authorized operation request; and (Col. 12 line 24 – Col. 13 line 49 discloses an authorization server that after receive the request will verify the signature and determine operation parameters align with policies. The authorization server will then generate a response that includes: the initial request, an authorization token and signature by the server.)
upon receipt and verification of the authorized operation request by the managed device, the managed device is responsive to the authorized operation request. (Col. 12 line 24 – Col 13 line 49 disclose that the device will be responsive to the authorization response if all signatures are valid.)
Stern does not explicitly disclose:
…
Wherein elements of the signatory module are remote to the management module;
The management module configured to delegate a signature operation to a local authorization device integrated with the PKI environment, and the local authorization device configured to store or hold the authorization key;
Takagi discloses:
…
Wherein elements of the signatory module are remote to the management module; (see Takagi Figure 3 showing an “external authenticator”).
The management module configured to delegate a signature operation to a local authorization device integrated with the PKI environment, (“the signature request unit 282 notifies the signature unit 44 of the external authenticator 400 of the process name and the front display application information. When the process name with the signature and the front display application information with the signature, which are signed in the signature unit 44, are received, the signature request unit 282 transmits the received information to the server verification cooperation unit 242.” Takagi ¶ 52) and the local authorization device configured to store or hold the authorization key; (“The key management unit 42 manages the private key. The key management unit 42 may, as the private key, separately manage a private key used for the above-described authentication processing (FIG. 2)” Takagi ¶ 41. “As illustrated in FIG. 2, in the authentication system 10, (1) the external authenticator 400 generates a new key pair (public key, private key) at the time of registration to an online service, the private key is held by the external authenticator 400, and the public key is registered in the authentication server 300 in advance.” Takagi ¶ 36. Public key transferred via the “terminal device” the claimed management application. See also Takagi ¶ 48 describing ID correlations between authenticator and client application on terminal)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stern with Takagi by providing the external authenticator of Takagi to perform signature operations (e.g. Takagi Fig. 2). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stern with Takagi in order to perform multi-factor-authentication using an external token, thereby increasing security of the authentication and signature.
Regarding claim 2, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein the authorized operation request includes information indicative of the operation request and a proof of authorization. (Col. 12 line 24 – Col. 13 line 49 disclose the authorized operation request includes: the initial request, an authorization token and signature by the server. The initial request includes: identification of device, the operation to be performed, time period, and location.)
Regarding claim 4, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein communication between at least some of the managed device, management module and signatory module is performed using a cellular communication network. (Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose a mobile device 10 in communication with an administrative computer, device manager 302. The device manager 302 communicates with the authorization server 304. These communications would require cellular communication between the mobile device, the device manager and the authorization server.)
Regarding claim 6, Stern in view of Takagi further teaches the system of claim 2 as detailed above.
Stern further teaches:
The system according to claim 2, wherein verification of the proof of authorization is performed by the managed device using the information indicative of the authorization key. (Col. 13 lines 35-49 disclose when the mobile device receives the authorization response it will verify the signatures with its private key. The response can also include a certificate chain to an authorization root of trust for additional proof of authorization.)
Regarding claim 7, Stern in view of Takagi further teaches the system of claim 2 as detailed above.
Stern further teaches:
The system according to claim 2, wherein verification of the proof of authorization is performed at least in part using a certificate chain. (Col. 13 lines 35-49 disclose when the mobile device receives the authorization response the signatures with its private key. The response can also include a certificate chain to an authorization root of trust for additional proof of authorization.)
Regarding claim 9, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein elements of the signatory module are remote to the managed device. (Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose a mobile device 10 in communication with an administrative computer, device manager 302. The device manager 302 communicates with the authorization server 304. These communications would require cellular communication between the mobile device, the device manager and the authorization server where each are remote from the others)
Regarding claim 10, claim 10 is canceled.
Regarding claim 12, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein the authorization key is stored on one or more of a smart card, a universal serial bus (USB) stick, a dongle. (Col. 4 line 61 – Col. 5 line 8 and Col. 12 Lines 39-54 disclose that a request can be transmitted via UICC, microSD, or removable media encompassing a USB, dongle, or YubiKey. In order for a request to be transmitted the authorization key would have to present on the media. Since the device is presented with USB adapter the storage devices above would qualify to be used as secure storage for the mobile device.)
Regarding claim 13, Stern in view of Takagi further teaches the system of claim 1 as detailed above.
The system according to claim 1, wherein the authorization key is associated with a particular system user. (Col. 17 lines 4-15 disclose the device manager when a system persona is created will the device manager will generate a public encryption key which is then signed by the persona with is CA which is then stored in in the devices secure element. Each persona will have their own PEK signed by their respective CA.)
Regarding claim 14, Stern teaches the method for device management and authorization.
A method for secure approval of an operation requested by a device management system, the method comprising:
receiving, by a management module, an operation request associated with an operation to be performed; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will receive or generate then transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
transmitting, by the management module to a signatory module, the operation request associated with the operation; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will receive or generate then transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
receiving, by the management module from the signatory module, an authorized operation response, the authorized operation response including information indicative of the operation and an authorization key; (Col. 12 line 24 – Col. 13 line 49 discloses an authorization server that after receive the request will verify the signature and determine operation parameters align with policies. The authorization server will then generate and send a response to the manager that includes: the initial request, an authorization token and signature by the server.) the information indicative of the authorization key associated with the PKI environment (Col. 12 line 24 – Col. 13 line 49 and Col. 17 lines 4-15 disclose a PKI environment for communication between device, manager, and authentication server.)
transmitting, by the management module to a managed device, an authorized operation request that includes information indicative of the operation and the authorization key, the managed device responsive to the authorized operation request upon verification of the authorized operation request. (Col. 12 line 24 – Col. 13 line 49 discloses that the device manager will transmit the authorized operation request and related data to the managed device. The managed device will verity the authenticity of the response and if valid will perform the requested operation.)
Stern does not explicitly disclose:
Wherein elements of the signatory module are remote to the management module and wherein the transmitting includes delegating a signature operation to a local authorization device integrated with a public key infrastructure (PKI) environment, and wherein the local authorization device is configured to store or hold an authorization key;
Takagi discloses:
Wherein elements of the signatory module are remote to the management module (see Takagi Figure 3 showing an “external authenticator”) and wherein the transmitting includes delegating a signature operation to a local authorization device integrated with a public key infrastructure (PKI) environment, (“the signature request unit 282 notifies the signature unit 44 of the external authenticator 400 of the process name and the front display application information. When the process name with the signature and the front display application information with the signature, which are signed in the signature unit 44, are received, the signature request unit 282 transmits the received information to the server verification cooperation unit 242.” Takagi ¶ 52) and wherein the local authorization device is configured to store or hold an authorization key; (“The key management unit 42 manages the private key. The key management unit 42 may, as the private key, separately manage a private key used for the above-described authentication processing (FIG. 2)” Takagi ¶ 41)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stern with Takagi by providing the external authenticator of Takagi to perform signature operations (e.g. Takagi Fig. 2). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stern with Takagi in order to perform multi-factor-authentication using an external token, thereby increasing security of the authentication and signature.
Regarding claim 15, Stern in view of Takagi further teaches the method of claim 14 as detailed above.
Stern further teaches:
The method according to claim 14, wherein the authorized operation request includes information indicative of the operation request and a proof of authorization. (Col. 12 line 24 – Col. 13 line 49 disclose the authorized operation request includes: the initial request, an authorization token and signature by the server. The initial request includes: identification of device, the operation to be performed, time period, and location.)
Regarding claim 18, Stern in view of Takagi further teaches the method of claim 14 as detailed above.
Stern further teaches:
The method according to claim 14, further comprising receiving a certificate chain associated with the authorization key. (Col. 13 lines 35-49 disclose when the mobile device receives the authorization response the signatures with its private key. The response can also include a certificate chain to an authorization root of trust for additional proof of authorization.)
Regarding claim 21, Stern teaches the apparatus for device management and authorization.
Stern teaches:
An apparatus comprising:
a processor; and
a non-transient memory for storing instructions that when executed by the processor cause the apparatus to be configured to:
receiving, by a management module, an operation request associated with an operation to be performed; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will receive or generate then transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
transmitting, by the management module to a signatory module, the operation request associated with the operation; (Col. 12 line 24 – Col 13 line 49, Fig. 6 disclose a device manager that facilitates communication with the authorization server, equated to applicant’s signatory module. The device manager will receive or generate then transmit a request to the authorization server. The request includes: identification of device, the operation to be performed, time period, and location. The request is further signed by private key.)
receiving, by the management module from the signatory module, an authorized operation response, the authorized operation response including information indicative of the operation and an authorization key; (Col. 12 line 24 – Col. 13 line 49 discloses an authorization server that after receive the request will verify the signature and determine operation parameters align with policies. The authorization server will then generate and send a response to the manager that includes: the initial request, an authorization token and signature by the server.) the information indicative of the authorization key associated with the PKI environment (Col. 12 line 24 – Col. 13 line 49 and Col. 17 lines 4-15 disclose a PKI environment for communication between device, manager, and authentication server.)
transmitting, by the management module to a managed device, the authorized operation request that includes information indicative of the operation and the authorization key, the managed device responsive to the authorized operation request upon verification of the authorized operation request. (Col. 12 line 24 – Col. 13 line 49 discloses that the device manager will transmit the authorized operation request and related data to the managed device. The managed device will verity the authenticity of the response and if valid will perform the requested operation.)
Stern does not explicitly disclose:
Wherein elements of the signatory module are remote to the management module and wherein the transmitting includes delegating a signature operation to a local authorization device integrated with a public key infrastructure (PKI) environment, and wherein the local authorization device is configured to store or hold an authorization key;
Takagi discloses:
Wherein elements of the signatory module are remote to the management module (see Takagi Figure 3 showing an “external authenticator”) and wherein the transmitting includes delegating a signature operation to a local authorization device integrated with a public key infrastructure (PKI) environment, (“the signature request unit 282 notifies the signature unit 44 of the external authenticator 400 of the process name and the front display application information. When the process name with the signature and the front display application information with the signature, which are signed in the signature unit 44, are received, the signature request unit 282 transmits the received information to the server verification cooperation unit 242.” Takagi ¶ 52) and wherein the local authorization device is configured to store or hold an authorization key; (“The key management unit 42 manages the private key. The key management unit 42 may, as the private key, separately manage a private key used for the above-described authentication processing (FIG. 2)” Takagi ¶ 41)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Stern with Takagi by providing the external authenticator of Takagi to perform signature operations (e.g. Takagi Fig. 2). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Stern with Takagi in order to perform multi-factor-authentication using an external token, thereby increasing security of the authentication and signature.
Regarding claim 23, Stern in view of Takagi further teaches the apparatus of claim 21 as detailed above.
Stern further teaches:
The apparatus according to claim 21, wherein instructions when executed by the processor cause the apparatus to be further configured to receive a certificate chain associated with the authorization key. (Col. 13 lines 35-49 disclose when the mobile device receives the authorization response the signatures with its private key. The response can also include a certificate chain to an authorization root of trust for additional proof of authorization.)
Regarding claim 24, Stern in view of Takagi further teaches the apparatus of claim 23 as detailed above.
Stern further teaches:
The apparatus according to claim 23, wherein instructions when executed by the processor cause the apparatus to be further configured to store the authorization key and the certificate chain on one or more of a smart card, a universal serial bus (USB) stick, a dongle and a YubiKey. (Col. 4 line 61 – Col. 5 line 8 and Col. 12 Lines 39-54 disclose that a request can be transmitted via UICC, microSD, or removable media encompassing a USB, dongle, or YubiKey. In order for a request to be transmitted the authorization key would have to present on the media. Since the device is presented with USB adapter the storage devices above would qualify to be used as secure storage for the mobile device.)
Claims 8, 11, 17, 19, 20 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 filed: 09/12/2013), in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019), and Nadalin (US 20050278534 A1 filed: 05/27/2004).
Regarding claim 8, Stern in view of Takagi further teach the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, prior to verification of the authorization key. (Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose verification of the authorization key.)
Stern in view of Takagi does not teach:
wherein the signatory module performs a revocation status check
Nadalin teaches:
wherein the signatory module performs a revocation status check (Fig.4 and Paragraph [0044] discloses a system for preforming revocation status check.)
Both Stern and Nadalin are directed towards device authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include the certificate revocation status check as taught by Nadalin for the purpose of providing extra security and allowing authorization verification to only be undergone on transactions proven valid by the associated certification. (Nadalin Paragraph [0044]) This change would be a simple procedure which would not require any extra experimentation to perform this check prior to verification and would yield predictable results.
Regarding claim 11, Stern in view of Takagi further teach the system of claim 1 as detailed above.
Nadalin teaches:
The system according to claim 10, wherein the PKI environment is a X. 509 environment. (Paragraph [0007] discloses that an X.509 environment is an International Telecommunications Union (ITU) standard in the art for a PKI environment.)
Both Stern and Nadalin are directed towards device authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include the X.509 PKI environment as taught by Nadalin for the purpose of conforming to the ITU and cryptographically binds the holder and key. (Nadalin Paragraph [0007]) This change would be a simple procedure which would not require any extra experimentation and would yield predictable results.
Regarding claim 17, Stern in view of Takagi further teach the method of claim 14 as detailed above.
Stern further teaches:
The method according to claim 14, prior to verification of the authorization key. (Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose verification of the authorization key.)
Stern does not teach:
further comprising performing a revocation status check
Nadalin teaches:
further comprising performing a revocation status check (Fig. 4 and Paragraph [0044] discloses a system for preforming revocation status check.)
Both Stern and Nadalin are directed towards device authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include the certificate revocation status check as taught by Nadalin for the purpose of providing extra security and allowing authorization verification to only be undergone on transactions proven valid by the associated certification. (Nadalin Paragraph [0044]) This change would be a simple procedure which would not require any extra experimentation to perform this check prior to verification and would yield predictable results.
Regarding claim 19, Stern in view of Takagi and Nadalin further teach the method of claim 17 as detailed above.
Stern further teaches:
The method according to claim 17, further comprising storing a certificate chain. (Col. 4 line 61 – Col. 5 line 8, Col. 9 lines 51-58 and Col. 15 lines 10-20 disclose a secure storage contains slots for each persona which would operate as a keystore for PKI, encryption keys, passwords and configuration information. Stern discloses trust anchors which are equated to applicants’ certificates, theses anchors would be stored within secure storage. When the proof of authorization is sent to the device a certificate chain is also sent and would be further stored in the secure storage.)
Regarding claim 20, Stern in view of Takagi and Nadalin further teaches the method of claim 19 as detailed above.
Stern further teaches:
The method according to claim 19, wherein the authorization key and the certificate chain are stored on one or more of a smart card, a universal serial bus (USB) stick, a dongle and a YubiKey. (Col. 4 line 61 – Col. 5 line 8 and Col. 12 Lines 39-54 disclose that a request can be transmitted via UICC, microSD, or removable media encompassing a USB, dongle, or YubiKey. In order for a request to be transmitted the authorization key would have to present on the media. Since the device is presented with USB adapter the storage devices above would qualify to be used as secure storage for the mobile device.)
Regarding claim 22, Stern in view of Takagi further teach the apparatus of claim 21 as detailed above.
Stern further teaches:
The apparatus according to claim 21, wherein instructions when executed by the processor cause the apparatus prior to verification of the authorized operation request.
(Fig. 6 and Col. 12 line 24 – Col. 13 line 49 disclose verification of the authorization key.)
Stern does not teach:
to be further configured to perform a revocation status check
Nadalin teaches:
to be further configured to perform a revocation status check (Fig. 4 and Paragraph [0044] discloses a system for preforming revocation status check.)
Both Stern and Nadalin are directed towards device authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include the certificate revocation status check as taught by Nadalin for the purpose of providing extra security and allowing authorization verification to only be undergone on transactions proven valid by the associated certification. (Nadalin Paragraph [0044]) This change would be a simple procedure which would not require any extra experimentation to perform this check prior to verification and would yield predictable results.
Claims 3, 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Stern (US 9819661 B2 A1 filed: 09/12/2013) in view of Takagi et al. (US 2020/0186533 A1 filed: 12/04/2019), and Sherkin (US 20090161876 A1 filed: 07/28/2009).
Regarding claim 3, Stern in view of Takagi further teach the system of claim 2 as detailed above.
Stern further teaches:
The system according to claim 2, wherein the proof of authorization is one or more of and a signature. (Col. 12 line 24 – Col. 13 line 49 disclose the authorized operation request includes: the initial request, an authorization token and signature by the server. The initial request includes: identification of device, the operation to be performed, time period, and location.)
Stern in view of Takagi does not teach:
A password
Sherkin teaches:
A password (Paragraphs [0038] and [0042] disclose a response sent by the server to the client the response contains the client and server certificates or the client’s user name, password, and server certificates. The received information is verified for the authenticity of the information.)
Both Stern and Sherkin are directed towards device and client authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include a password in the response as a form of proof of authorization as taught by Sherkin for the purpose of providing an additional element to show proof of authorization. (Sherkin Paragraphs [0038] and [0042])
Regarding claim 5, Stern in view of Takagi further teach the system of claim 1 as detailed above.
Stern further teaches:
The system according to claim 1, wherein the information indicative of an authorization key is one or more of a root certificate authority certificate (Col. 6 lines 38-65 disclose trust anchors, cryptographic signatures, that are used to verify persona authenticity and are directly tied to personas individual keys for PKI. Each trust anchor root traces back to the root certificate authority. Each persona has their own slot within the secure element to store sensitive information including the information indicative of an authorization key; the root of trust, used to by the trust platform modules to provide isolation of the personas, and the user credentials.)
Stern in view of Takagi does not teach:
And a password
Sherkin teaches:
And a password (Paragraphs [0038] and [0042] disclose that the client credentials comprise a user name and password that are sent to the server as a form of information indicative of an authorization key.)
Both Stern and Sherkin are directed towards device and client authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include a password in the operation request as an authorization key as taught by Sherkin for the purpose of providing an additional element to show proof of identity of a request initializer. (Sherkin Paragraphs [0038] and [0042]) This change would be a simple procedure which would not require any extra experimentation to include the password as part of the information indicative of an authorization key, which is stored in secure element as taught by Stern, and would yield predictable results.
Regarding claim 16 Stern in view of Takagi further teach the method of claim 15 as detailed above.
Stern further teaches:
The method according to claim 15, wherein the proof of authorization is one or more of and a signature. (Col. 12 line 24 – Col. 13 line 49 disclose the authorized operation request includes: the initial request, an authorization token and signature by the server. The initial request includes: identification of device, the operation to be performed, time period, and location.)
Stern does not teach:
A password
Sherkin teaches:
A password (Paragraphs [0038] and [0042] disclose a response sent by the server to the client the response contains the client and server certificates or the client’s user name, password, and server certificates. The received information is verified for the authenticity of the information.)
Both Stern and Sherkin are directed towards device and client authorization. It would have been obvious to a PHOSITA before the effective filing date to modify the teaching of Stern in view of Takagi to include a password in the response as a form of proof of authorization as taught by Sherkin for the purpose of providing an additional element to show proof of authorization. (Sherkin Paragraphs [0038] and [0042])
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
1. US 2022/0166623 A1 – Alfonso Reyes et al.
- Hardware authentication token with remote validation.
2. US 10931663 B2 – Roper et al.
- Terminal authentication access.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Rupal Dharia whose telephone number is (571)272-3880. The examiner can normally be reached M, W-F 8-5.
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.
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.
/RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492