DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 02/05/2026.
In the instant Amendment: Claims 1-9, 21-31 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants' arguments in the instant Amendment, filed on 02/05/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant Argues: Eutsler and Srivastava fail to disclose “receive ... a first payload having delta changes from the first device, wherein the first payload is signed using the first public key; receive ... a second payload, wherein the second payload is signed using the second public key; verify the second payload against the delta changes from the first payload.” See Remarks at 9 (emphasis added).
The examiner respectfully disagrees because these arguments are not persuasive.
Applicant alleges that Eutsler and Srivastava fail to disclose the above limitations because Eutsler fails to disclose “delta changes.” Id. at 10.
In regards to, “receive ... a first payload having delta changes from the first device, wherein the first payload is signed using the first public key; receive ... a second payload, wherein the second payload is signed using the second public key; verify the second payload against the delta changes from the first payload,” Eutsler discloses:
In some arrangements, the cryptographic key processor 120 can sign the token using a private key and verify the token using a public key. In some examples, signing can include encrypting the token using a particular private key to create a digital signature, and verifying the token can include decrypting the token using a particular public key to verify the digital signature came from the particular private key or private address (e.g., a particular digital wallet of a user, etc.). In some arrangements, the cryptographic key processor 120 can sign the token using a public key and verify the token using a private key. In some examples, signing can include encrypting the token using a particular public key to create a digital signature, and verifying can include decrypting the token using a particular private key to verify the digital signature came from the particular public key or public address (e.g., a particular digital wallet of a user). It should be understood that a public key and a public address are used herein interchangeably, but in some arrangements, the public address may be a hashed version of the public key based on a hash function.
The mobile wallet system 170 can execute a transaction or modify metadata of the wallet token 212 in response to detecting input including the wallet key 214. The wallet keys 214 can, for example, include a wallet public-private key pair, a wallet public key, or a wallet private key compatible with the mobile wallet system 170. The mobile wallet system 170 can permit access to the wallet token 212 based on the wallet key(s) 214, for example, compatible with the encapsulation layer and operable to decrypt the encryption corresponding to the encapsulation layer.
The token generator 370 can modify and delete tokens linked with primary tokens or parent smart contract control structures, to update control of a partial transfer of metadata object control.
See Eutsler ¶ ¶ [0039], [0069], [0107] (emphasis added).
Here, Eutsler’s system teaches a system that can modify or update token content/metadata. The token with modified content or metadata (i.e., delta changes associated with a token payload) can be signed with a signing key (public or private key), and be verified with a corresponding verifying key (also public or private key). Accordingly, Eutsler in view of Srivastava discloses “receive ... a first payload having delta changes from the first device, wherein the first payload is signed using the first public key; receive ... a second payload, wherein the second payload is signed using the second public key; verify the second payload against the delta changes from the first payload” of claim 1.
In conclusion, applicant’s argument is unpersuasive and the rejection of amended claims 1 is maintained. Rejection of claims 21 and 22, which recite similar matters, is similarly maintained.
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 discloses as set forth in section 102 of this title, 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-7, 9, 21-34 are rejected under 35 U.S.C. 103 as being unpatentable over Eutsler et al. (“Eutsler,” US 20240386489, filed May 16, 2023) in view of Srivastava et al. (“Srivastava,” US 20220191025, published June 16, 2022).
Regarding claim 1, Eutsler discloses An Information Handling System (IHS), comprising:
a processor; and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution by the processor, cause the processor to (Eutsler [0021]. The system processor 110 can include an electronic processor, an integrated circuit, or the like including one or more of digital logic, analog logic, digital sensors, analog sensors, communication buses, volatile memory, nonvolatile memory, and the like. The system processor 110 can include a memory operable to store or storing one or more instructions for operating components of the system processor 110 and operating components operably coupled to the system processor 110. For example, the one or more instructions can include one or more of firmware, software, hardware, operating systems, embedded operating systems.):
create a first delegated authority key pair [for a first control plane, wherein the first control plane provides orchestration] for a first device (Eutsler [0023]. For example, the cryptographic key processor 120 can include one or more asymmetric or symmetric key generators, and can generate public-private key pairs. For example, the cryptographic key processor 120 can generate a key compatible with or linked with a particular identifier corresponding to a particular, device, user, customer, account, system, or any combination thereof.);
provide a first public key of the first delegated authority key pair [to the first control plane] (Eutsler [0043]. In some arrangements, the cryptographic key processor 120 can also be configured to generate public and private key pairs and the interface controller 112 can be configured to provide public keys (or public and private key pairs, or private keys) to one or more computing devices (e.g., the client system 103, the token exchange system 104, etc.) for use in a token exchange.);
create a second delegated authority key pair [for a second control plane]; provide a second public key of the second delegated authority key pair [to the second control plane] (Eutsler [0043]. In some arrangements, the cryptographic key processor 120 can also be configured to generate public and private key pairs and the interface controller 112 can be configured to provide public keys (or public and private key pairs, or private keys) to one or more computing devices (e.g., the client system 103, the token exchange system 104, etc.) for use in a token exchange.);
receive [,from the first control plane,] a first payload having delta changes from the first device, wherein the first payload is signed using the first public key (Eutsler [0039], [0069], [0107]. In some arrangements, the cryptographic key processor 120 can sign the token using a private key and verify the token using a public key. In some examples, signing can include encrypting the token using a particular private key to create a digital signature, and verifying the token can include decrypting the token using a particular public key to verify the digital signature came from the particular private key or private address (e.g., a particular digital wallet of a user, etc.). In some arrangements, the cryptographic key processor 120 can sign the token using a public key and verify the token using a private key. In some examples, signing can include encrypting the token using a particular public key to create a digital signature, and verifying can include decrypting the token using a particular private key to verify the digital signature came from the particular public key or public address (e.g., a particular digital wallet of a user). It should be understood that a public key and a public address are used herein interchangeably, but in some arrangements, the public address may be a hashed version of the public key based on a hash function. The mobile wallet system 170 can execute a transaction or modify metadata of the wallet token 212 in response to detecting input including the wallet key 214. The wallet keys 214 can, for example, include a wallet public-private key pair, a wallet public key, or a wallet private key compatible with the mobile wallet system 170. The mobile wallet system 170 can permit access to the wallet token 212 based on the wallet key(s) 214, for example, compatible with the encapsulation layer and operable to decrypt the encryption corresponding to the encapsulation layer. The token generator 370 can modify and delete tokens linked with primary tokens or parent smart contract control structures, to update control of a partial transfer of metadata object control.);
receive, [from the second control plane], a second payload, wherein the second payload is signed using the second public key; verify the second payload against the delta changes from the first payload (Eutsler [0039], [0051], [0069]. In some arrangements, the cryptographic key processor 120 can sign the token using a private key and verify the token using a public key. In some examples, signing can include encrypting the token using a particular private key to create a digital signature, and verifying the token can include decrypting the token using a particular public key to verify the digital signature came from the particular private key or private address (e.g., a particular digital wallet of a user, etc.). In some arrangements, the cryptographic key processor 120 can sign the token using a public key and verify the token using a private key. In some examples, signing can include encrypting the token using a particular public key to create a digital signature, and verifying can include decrypting the token using a particular private key to verify the digital signature came from the particular public key or public address (e.g., a particular digital wallet of a user). It should be understood that a public key and a public address are used herein interchangeably, but in some arrangements, the public address may be a hashed version of the public key based on a hash function. As used herein, “multi-sig” refers to a signature scheme that enforces multiple signatures for an exchange before it may be successfully approved. The mobile wallet system 170 can execute a transaction or modify metadata of the wallet token 212 in response to detecting input including the wallet key 214. The wallet keys 214 can, for example, include a wallet public-private key pair, a wallet public key, or a wallet private key compatible with the mobile wallet system 170. The mobile wallet system 170 can permit access to the wallet token 212 based on the wallet key(s) 214, for example, compatible with the encapsulation layer and operable to decrypt the encryption corresponding to the encapsulation layer.); and
transmit a third payload [to the second control plane], wherein the third payload includes the delta changes and is signed by a private key of the second delegated authority key pair (Eutsler [0052], [0069]. In some embodiments, the blockchain storage 168 may also sign the token (after or before the cold storage private key) to “two-key sign” the token for additional security and protection, such that the destination address must verify (and sometimes in the correct order of signing using the private key) the token with both the cold storage public key and the internal public key. Thus, two-key signing using multiple private keys can improve the security of tokens. The mobile wallet system 170 can execute a transaction or modify metadata of the wallet token 212 in response to detecting input including the wallet.).
Eutsler does not explicitly disclose: a first control plane, wherein the first control plane provides orchestration for a first device; a second control plane.
However, in an analogous art, Srivastava discloses a system, comprising: a first control plane, wherein the first control plane provides orchestration for a first device; a second control plane (Srivastava [0015], [0026]. In one set of embodiments, a framework is provided that employs hardware-based attestation to assign a digital certificate to each VM-based control plane element and computing node (i.e., worker VM) of the workload orchestration platform, where the digital certificate is signed by a trusted entity and provides cryptographic proof that the control plane element/worker VM has been successfully attested by that trusted entity (and thus is correct and secure in accordance with attestation guarantees (a) and (b) noted above). Each control plane element/worker VM is configured to verify the digital certificates of other platform components prior to communicating with those components. Upon successfully completing this, trust authority 202 can securely transmit a digital certificate (such as, e.g., a Transport Layer Security (TLS) certificate) to each control plane element that is signed using a private key of trust authority 202 and provides cryptographic proof that the control plane element has been successfully attested by trust authority 202.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Srivastava and Eutsler to include: a first control plane, wherein the first control plane provides orchestration for a first device; a second control plane. One would have been motivated to provide users with a means to validate virtual computing instances through certificate attestation of hardware and virtual computing nodes. (See Srivastava [0015].)
Regarding claim 2, Eutsler and Srivastava disclose the system of claim 1. Eutsler further discloses wherein the second payload contains content received, [by the second control plane, from the first control plane] in an ownership voucher (Eutsler [0044]. In various arrangements, the sender (e.g., a source party such as a user, a provider, or an entity) can utilize its private key (or public key) to generate a digital signature. The process of signing a message can use a mathematical operation that can be performed by the device (e.g., the client system 103, the token exchange system 104, etc.) of the sender who possesses the private key. The token and the digital signature can then be sent to a recipient. As will be appreciated, the recipient (e.g., destination party) can be a user, provider, and/or an entity (e.g., the data processing system 102) that can use the digital signature and the sender's public key (or private key) to verify that the sender is the signer of the token and that the integrity and origin authenticity of the token has not been compromised. In some arrangements, the tokens on the blockchain storage 168 may be associated with an account (e.g., designated in a field such as an account_ID field in the metadata of the token) (sometimes referred to herein as a “token account”).).
Srivastava further discloses received, by the second control plane, from the first control plane (Srivastava [0020]-[0021]. Each host system 108 includes, in software, a virtualization software layer (i.e., hypervisor) 110 and virtual machines that correspond to the control plane elements and computing nodes of workload orchestration platform 102. In addition, each host system 108 includes a control plane element referred to as a node agent VM (reference numeral 114) and one or more worker VMs 116 (each running a workload component manager 118)…cluster master VM 112 transmits, to the node agent VM of each host system designated to run an execution group of the workload, a specification of that execution group. This execution group specification identifies, among other things, the workload component(s) which are part of the execution group and the name and storage location of the software image needed to run each workload component. In response, the receiving node agent VM retrieves the software image(s) for the workload component(s) identified in the specification, stages the software image(s) on virtual disk(s), and attaches the virtual disk(s) to a newly created and powered-on worker VM.).
The motivation is the same as that of claim 1 above.
Regarding claim 3, Eutsler and Srivastava disclose the system of claim 1. Eutsler further discloses wherein the program instructions to cause the processor to verify the second payload against the delta changes from the first payload includes program instructions to cause the processor to: compare the delta changes from the first payload to contents of the second payload; and determine that the delta changes from the first payload match the contents of the second payload (Eutsler [0039], [0069]. In some arrangements, the cryptographic key processor 120 can sign the token using a private key and verify the token using a public key. In some examples, signing can include encrypting the token using a particular private key to create a digital signature, and verifying the token can include decrypting the token using a particular public key to verify the digital signature came from the particular private key or private address (e.g., a particular digital wallet of a user, etc.). In some arrangements, the cryptographic key processor 120 can sign the token using a public key and verify the token using a private key. In some examples, signing can include encrypting the token using a particular public key to create a digital signature, and verifying can include decrypting the token using a particular private key to verify the digital signature came from the particular public key or public address (e.g., a particular digital wallet of a user). It should be understood that a public key and a public address are used herein interchangeably, but in some arrangements, the public address may be a hashed version of the public key based on a hash function. The mobile wallet system 170 can execute a transaction or modify metadata of the wallet token 212 in response to detecting input including the wallet key 214. The wallet keys 214 can, for example, include a wallet public-private key pair, a wallet public key, or a wallet private key compatible with the mobile wallet system 170. The mobile wallet system 170 can permit access to the wallet token 212 based on the wallet key(s) 214, for example, compatible with the encapsulation layer and operable to decrypt the encryption corresponding to the encapsulation layer.)
Regarding claim 4, Eutsler and Srivastava disclose the system of claim 1. Eutsler further discloses comprising instructions to cause the processor to: extract the delta changes from the first payload, including using a private key of the first delegated authority key pair to read a signature associated with the first payload (Eutsler [0039], [0069]. In some arrangements, the cryptographic key processor 120 can sign the token using a private key and verify the token using a public key. In some examples, signing can include encrypting the token using a particular private key to create a digital signature, and verifying the token can include decrypting the token using a particular public key to verify the digital signature came from the particular private key or private address (e.g., a particular digital wallet of a user, etc.). In some arrangements, the cryptographic key processor 120 can sign the token using a public key and verify the token using a private key. In some examples, signing can include encrypting the token using a particular public key to create a digital signature, and verifying can include decrypting the token using a particular private key to verify the digital signature came from the particular public key or public address (e.g., a particular digital wallet of a user). It should be understood that a public key and a public address are used herein interchangeably, but in some arrangements, the public address may be a hashed version of the public key based on a hash function. The mobile wallet system 170 can execute a transaction or modify metadata of the wallet token 212 in response to detecting input including the wallet key 214. The wallet keys 214 can, for example, include a wallet public-private key pair, a wallet public key, or a wallet private key compatible with the mobile wallet system 170. The mobile wallet system 170 can permit access to the wallet token 212 based on the wallet key(s) 214, for example, compatible with the encapsulation layer and operable to decrypt the encryption corresponding to the encapsulation layer.)
Regarding claim 5, Eutsler and Srivastava disclose the system of claim 1. Srivastava further discloses wherein the program instructions cause the IHS to perform functions of a remote validation service in communication with the first control plane and with the second control plane (Srivastava [0026]. For example, at the time of instantiating/powering-on the control plane elements of workload orchestration platform 102 (i.e., cluster master VM 112 and node agent VMs 114(1)-(N)), trust authority 202 can communicate with the PSPs of the host systems running these control plane elements and carry out (with the assistance of hypervisor-level attestation support logic 206) hardware-based attestation to validate that the control plane elements are authentic and to isolate their guest memories from their respective hypervisors. Upon successfully completing this, trust authority 202 can securely transmit a digital certificate (such as, e.g., a Transport Layer Security (TLS) certificate) to each control plane element that is signed using a private key of trust authority 202 and provides cryptographic proof that the control plane element has been successfully attested by trust authority 202.).
The motivation is the same as that of claim 1 above.
Regarding claim 6, Eutsler and Srivastava disclose the system of claim 1. Srivastava further discloses wherein the program instructions to cause the IHS to transmit the third payload to the second control plane includes program instructions to cause the IHS to: include a public key of the second control plane in the third payload (Srivastava [0026], [0047]. Upon successfully completing this, trust authority 202 can securely transmit a digital certificate (such as, e.g., a Transport Layer Security (TLS) certificate) to each control plane element that is signed using a private key of trust authority 202 and provides cryptographic proof that the control plane element has been successfully attested by trust authority 202. Assuming this decryption is successful (which means that the digital certificate is valid and thus provides proof that node agent VM 114(X) has been successfully attested by trust authority 202), cluster master VM 112 can establish a secure communication channel with node agent VM 114(X) using node agent VM 114(X)'s public key (block 518). Cluster master VM 112 can thereafter transmit the specification for the execution group and a worker VM image to node agent VM 114(X) over the secure communication channel (block 520).).
The motivation is the same as that of claim 1 above.
Regarding claim 7, Eutsler and Srivastava disclose the system of claim 1. Eutsler further discloses comprising instructions to cause the processor to: using a private key of the second delegated authority key pair to read a signature associated with the second payload (Eutsler [0039]. In some arrangements, the cryptographic key processor 120 can sign the token using a private key and verify the token using a public key. In some examples, signing can include encrypting the token using a particular private key to create a digital signature, and verifying the token can include decrypting the token using a particular public key to verify the digital signature came from the particular private key or private address (e.g., a particular digital wallet of a user, etc.). In some arrangements, the cryptographic key processor 120 can sign the token using a public key and verify the token using a private key. In some examples, signing can include encrypting the token using a particular public key to create a digital signature, and verifying can include decrypting the token using a particular private key to verify the digital signature came from the particular public key or public address (e.g., a particular digital wallet of a user).).
Regarding claim 9, Eutsler and Srivastava disclose the system of claim 1. Eutsler further discloses wherein the program instructions to cause the processor to receive the first payload includes firmware instructions to cause the processor to (Eutsler [0021]. The system processor 110 can include a memory operable to store or storing one or more instructions for operating components of the system processor 110 and operating components operably coupled to the system processor 110. For example, the one or more instructions can include one or more of firmware, software, hardware, operating systems, embedded operating systems.):
receive a public key of the [first control plane] in the first payload (Eutsler [0060]. For example, the sender (source) of a token stored in a digital wallet can sign (e.g., “lock”) the token or data package including the token to be exchanged with a private key stored in a digital wallet or on the user device (e.g., 103) of the user and in turn, transmit the token and share the public key for verifying (e.g., “un-locking”) by the receiver, such as the data processing system 102. Additionally in some arrangements, the public key can be used to encrypt tokens and the private key can be used to decrypt the encrypted tokens.).
Srivastava further discloses first control plane (Srivastava [0015]. In one set of embodiments, a framework is provided that employs hardware-based attestation to assign a digital certificate to each VM-based control plane element and computing node (i.e., worker VM) of the workload orchestration platform, where the digital certificate is signed by a trusted entity and provides cryptographic proof that the control plane element/worker VM has been successfully attested by that trusted entity (and thus is correct and secure in accordance with attestation guarantees (a) and (b) noted above). Each control plane element/worker VM is configured to verify the digital certificates of other platform components prior to communicating with those components.).
The motivation is the same as that of claim 1 above.
Regarding claim 21, claim 21 is directed to a method corresponding to the system of claim 1. Claim 21 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 22, claim 22 is directed to a method corresponding to the system of claim 2. Claim 22 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding claim 23, claim 23 is directed to a method corresponding to the system of claim 3. Claim 23 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding claim 24, claim 24 is directed to a method corresponding to the system of claim 4. Claim 24 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding claim 25, claim 25 is directed to a method corresponding to the system of claim 5. Claim 25 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding claim 26, claim 26 is directed to a method corresponding to the system of claim 6. Claim 26 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding claim 27, claim 27 is directed to a non-transitory memory device corresponding to the method of claim 1. Claim 27 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 28, claim 28 is directed to a non-transitory memory device corresponding to the method of claim 7. Claim 28 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding claim 30, claim 30 is directed to a non-transitory memory device corresponding to the method of claim 9. Claim 30 is similar in scope to claim 9 and is therefore rejected under similar rationale.
Regarding claim 31, claim 31 is directed to a non-transitory memory device corresponding to the method of claim 6. Claim 31 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Claims 8 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Eutsler et al. (“Eutsler,” US 20240386489, filed May 16, 2023) in view of Srivastava et al. (“Srivastava,” US 20220191025, published June 16, 2022) and Orlando et al. (“Orlando,” US 20230274002, published Aug. 31, 2023).
Regarding claim 8, Eutsler and Srivastava disclose the system of claim 1. Eutsler and Srivastava do not explicitly disclose: wherein the delta changes indicate firmware or hardware differences of the first device with respect to a factory certificate of the first device.
However, Orlando, in an analogous art, discloses a system comprising: wherein the delta changes indicate firmware or hardware differences of the first device with respect to a factory certificate of the first device (Orlando [0014], [0030]. DICE may also generate one or more certificates that may be signed by the device manufacturer. This may allow other relying devices to trust the keys given by the device. In other examples, at operation 320, the authenticity feature may be enabled. In that instance, the value stored in the secure storage device set during the firmware update may be read at operation 325. A determination is made as to whether the secure storage device is empty (e.g., based upon the value read being an invalid value) at operation 330. If the secure storage device is empty, then either the firmware was not updated, or a malicious firmware was loaded without modifying the value in the secure storage device. In this example, the device may resume normal operations at operation 355, however, in some examples, the alias certificate may not be updated. In some examples, once the authenticity feature is enabled, the alias certificate may only be regenerated after a firmware update in which the value stored in the secure storage device matches the measurement of the firmware on the device. In these examples, if the firmware was updated, but the secure storage device was not properly set, the alias key will not match the alias certificate. Thus, the device will fail attestation.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Orlando with the teachings of Eutsler and Srivastava to include: wherein the delta changes indicate firmware or hardware differences of the first device with respect to a factory certificate of the first device. One would have been motivated to provide users with a means for authenticating the firmware version or update of the computing system. (See Orlando [0030].).
Regarding claim 29, claim 29 is directed to a non-transitory memory device corresponding to the method of claim 8. Claim 29 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Conclusion
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 EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. 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.
/EDWARD LONG/
Examiner, Art Unit 2439
/KARI L SCHMIDT/Primary Examiner, Art Unit 2439
Prosecution Insights