DETAILED ACTION
This Office Action is in response to the application 18/812,970 filed on 08/22/2024.
Claims 1-20 have been examined and are pending.
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 . This Action is made Non-FINAL.
Priority
This application is a continuation of international patent application No. PCT/CN2022/087886, filed on April 20, 2022, which itself claims priority to Chinese patent application No. 202210318463.7, filed on March 29, 2022.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 08/22/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
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.
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
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. Such claim limitation(s) is/are: “means for calling,” “means for acquiring,” “means establishing” of claim 8.
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: “apparatus… configured to” of claim 8.
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they 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 the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 16-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Regarding claims 16-20; claims 16-20 are rejected under 35 U.S.C. 101 because the claims is directed to non-statutory subject matter. Claims 19-20 are directed to “[a] computer-readable storage medium.” The specification does not limit the claimed “computer-readable medium” to non-transitory medium. Under a recent precedential opinion, the scope of the recited “computer readable storage medium” encompasses transitory media such as signals or carrier waves, where, as here the Specification does not limit the computer readable storage medium to non-transitory forms. See Ex parte Mewherter, 107 USPQ2d 1857, 1862 (PTAB 2013) (precedential) (holding recited machine-readable storage medium ineligible under § 35 U.S.C. 101 since it encompassed transitory media). The Examiner respectfully suggests that the claim be amended to either “A non-transitory computer-readable storage medium” or “a computer-readable storage device,” or the like to make the claim statutory under 35 USC 101; (emphasis added).
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-4, 8, 9-12, 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Sprague et al. (“Sprague,” US 20160275461, published Sep. 22, 2016) in view of Sarangdhar et al. (“Sarangdhar,” US 20160142212, published May 19, 2016).
Regarding claim 1, Sprague discloses
A TEE-based method to establish trusted and secure channel between the user and public cloud environment, configured to establish a secure communication channel between the user and a TEE (Trusted Execution Environment) in a cloud server (Sprague [0038], [0043], [0061], [0080]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. Server computers 160 may be configured to provide a user device authentication system 100 which communicates with authenticators to confirm a requestor's identity prior to allowing the requestor to access resources protected by the authentication system. The server computers may not be separate server computers but part of cloud network 170. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. The TEE Adapter 216 may be configured as the interface between the Device Rivet/TEE applet 208 bolted into the TEE and the outside world of partner apps and online services.), comprising:
after the TEE is started, calling a trusted measurement mechanism of the TEE to perform security measurement on an operation environment and an operation content of a computing node operated in the TEE, and sending a measurement result to a trusted verification module, wherein the trusted verification module is operated in a [second] TEE (Sprague [0038], [0061], [0114]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. Verification can be done locally or remotely and may include additional user verification, confirmation or signature from logging systems, other critical process steps, location or time.);
acquiring relevant verification information from a remote verification server of the TEE, and controlling the trusted verification module to verify the measurement result according to the relevant verification information, so as to determine whether the operation environment of the computing node is credible and whether the operation content of the computing node is secure (Sprague [0038], [0061], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. This measurement may be requested directly of the Device Adaptor or fetched by the server through a persistent sockets connection with the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.); and
when it is confirmed that the operation environment of the computing node is credible and the operation content of the computing node is secure, establishing a communication channel between the user and the computing node (Sprague [0038], [0043], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. Server computers 160 may be configured to provide a user device authentication system 100 which communicates with authenticators to confirm a requestor's identity prior to allowing the requestor to access resources protected by the authentication system. The server computers may not be separate server computers but part of cloud network 170. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.).
Sprague does not explicitly disclose: wherein the trusted verification module is operated in a second TEE.
However, in an analogous art, Sarangdhar discloses a method, comprising: wherein the trusted verification module is operated in a second TEE (Sarangdhar [0019], [0022]. FIG. 1 illustrates an example system for TPM certification and attestation utilizing an anonymous key system in accordance with at least one embodiment of the present disclosure. System 100 may comprise, for example, at least device 102 and remote resource 104. A cloud computing architecture may comprise, for example, a plurality of data servers operating individually or in unison to provide various data processing-related services to user device 102. For example, TPM FW module 200 may be loaded into trusted execution environment (TEE) 202 and AKS FW module 204 may be loaded into TEE 206. TEEs 204 and 206 may comprise protected areas of memory in which known-good programs may execute, confidential information may be stored in a secure manner, etc.).
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 Sarangdhar and Sprague to include the step of: wherein the trusted verification module is operated in a second TEE. One would have been motivated to provide user with a means of gaining authenticated access to a program or service that is operated in a plurality of TEE environments. (See Saranghar [0022].)
Regarding claim 2, Sprague and Sarangdhar disclose the method of claim 1. Sprague further discloses
wherein when it is confirmed that the operation environment of the computing node is credible and the operation content of the computing node is secure, establishing the communication channel between the user and the computing node further comprises (Sprague [0038], [0043], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. Server computers 160 may be configured to provide a user device authentication system 100 which communicates with authenticators to confirm a requestor's identity prior to allowing the requestor to access resources protected by the authentication system. The server computers may not be separate server computers but part of cloud network 170. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.):
when it is confirmed that the operation environment of the computing node is credible and the operation content of the computing node is secure, controlling the trusted verification module to sign a public key of the computing node to generate a digital certificate, and sending the digital certificate to the computing node (Sprague [0094]. An embodiment may be a method for creating a birth certificate for a user device in a block chain communication network comprising: establishing a device identity for the user device by generating a public/private key pair that is locked to the user device; signing of the public key of the device by an endorsement key established during manufacturing or creation of the device, manufacturing or creation of the execution environment of the device and/or manufacturing or creation of an application on the device; and enrolling the device with a trusted third party including: requesting and obtaining the generated public key from the device; requesting and obtaining a device measurement record of the device containing attributes related to the device Platform Configuration Registers (PCR), BIOS, OS and/or GPS; endorsing of the device measurement record by the third party and the device; and registering the device into the block chain including posting the endorsed device measurement record into a public cryptographic ledger.); and
establishing the communication channel between the user and the computing node by the digital certificate (Sprague [0038], [0094]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. An embodiment may be a method for creating a birth certificate for a user device in a block chain communication network comprising: establishing a device identity for the user device by generating a public/private key pair that is locked to the user device; signing of the public key of the device by an endorsement key established during manufacturing or creation of the device, manufacturing or creation of the execution environment of the device and/or manufacturing or creation of an application on the device; and enrolling the device with a trusted third party including: requesting and obtaining the generated public key from the device; requesting and obtaining a device measurement record of the device containing attributes related to the device Platform Configuration Registers (PCR), BIOS, OS and/or GPS; endorsing of the device measurement record by the third party and the device; and registering the device into the block chain including posting the endorsed device measurement record into a public cryptographic ledger.).
Regarding claim 3, Sprague and Sarangdhar disclose the method of claim 1. Sprague further discloses wherein calling the trusted measurement mechanism of the TEE to perform security measurement on the operation environment and the operation content of the computing node operated in the TEE, and sending the measurement result to the trusted verification module further comprises: calling the trusted measurement mechanism of the TEE to perform security measurement on the operation environment and the operation content of the computing node operated in the TEE (Sprague [0061], [0075]. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. This measurement may be requested directly of the Device Adaptor or fetched by the server through a persistent sockets connection with the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.),
generating a measurement report based on the measurement result, and sending the measurement report to the trusted verification module (Sprague [0038], [0061], [0075]. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The TEE offers an execution space that provides a higher level of security than a Rich OS. In another example embodiment, the TEE may be implemented as a virtual machine. This measurement may be requested directly of the Device Adaptor or fetched by the server through a persistent sockets connection with the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.).
Regarding claim 4, Sprague and Sarangdhar disclose the method of claim 3. Sprague further discloses wherein controlling the trusted verification module to verify the measurement result according to the relevant verification information further comprises: controlling the trusted verification module to verify the measurement report according to the relevant verification information (Sprague [0038], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered. Every time a measurement matches, the device registration record can be updated with a success count.)
Regarding claim 8, claim 8 is directed to an apparatus corresponding to the method of claim 1. Claim 8 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 9, claim 9 is directed to a computer device corresponding to the method of claim 1. Claim 9 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 10, claim 10 is directed to a computer device corresponding to the method of claim 2. Claim 10 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding claim 11, claim 11 is directed to a computer device corresponding to the method of claim 3. Claim 11 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding claim 12, claim 12 is directed to a computer device corresponding to the method of claim 4. Claim 12 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed to a computer-readable storage medium corresponding to the method of 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 computer-readable storage medium corresponding to the method of 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 computer-readable storage medium corresponding to the method of claim 3. Claim 18 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a computer-readable storage medium corresponding to the method of claim 4. Claim 19 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Claims 5-7, 13-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sprague et al. (“Sprague,” US 20160275461, published Sep. 22, 2016) in view of Sarangdhar et al. (“Sarangdhar,” US 20160142212, published May 19, 2016) and Li et al. (“Li,” US 20220188146, filed Dec. 16, 2020).
Regarding claim 5, Sprague and Sarangdhar disclose the method of claim 1.
Sprague and Sarangdhar do not explicitly disclose: receiving a connection request for the TEE from the user, and creating or starting the TEE.
However, in an analogous art, Li discloses a method, comprising the step of: wherein before calling the trusted measurement mechanism of the TEE to perform security measurement on the operation environment and the operation content of the computing node operated in the TEE, the method further comprises: receiving a connection request for the TEE from the user, and creating or starting the TEE (Li [0031], [0044]. In an embodiment, these services requests may be made using system calls to the TEE backend module 234 inside the VMkernel 224. In response to these service requests, the hardware TEE mechanism 214 is engaged by the TEE backend module 234 to fulfill the requested services or operations. In an embodiment, this engagement or interaction may involve issuing appropriate TEE commands for the requested services to the hardware TEE mechanism 214, which would cause the hardware TEE mechanism to execute the requested services or operations, such as TEE creation, TEE configuration, TEE execution and TEE removal operations. The TEE migration process begins at step 502, where a request to migrate the source TEE 402A in the source host computer 404A to another host computer in the cluster 102 is received at the migration runtime 438A in the source TEE. In an embodiment, the request may be sent from the hypervisor 416A to the migration runtime 438A in the source TEE 402A in response to user request or in response to instructions from the cluster management server 106.).
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 Sprague, Sarangdhar and Li to include: receiving a connection request for the TEE from the user, and creating or starting the TEE. One would have been motivated to provide users with a means for creating a TEE service instance for providing services according to user requests. (See Li [0031].)
Regarding claim 6, Sprague, Sarangdhar and Li disclose the method of claim 5.
Sprague further discloses wherein the connection request comprises at least one of private data uploading, private calculation algorithm uploading, private machine-learning model uploading, protected operation request of private calculation task, or private data downloading (Sprague [0051], [0078]. In another embodiment, at least a portion of the system software instructions 115 may be downloaded over a cable, communication and/or wireless connection via, for example, a browser SSL session1 or through an app (whether executed from a mobile or other computing device). In an example embodiment, Authentication Web Site 206 may be a JSON API written in Python, which uses the Third Party Agent/Process private key to enroll the identity keys of Devices 205 and Service Providers 204. During enrollment, the public key of the User Device 205 or Service Provider 204 is recorded by the TEE applet 208.).
Regarding claim 7, Sprague, Sarangdhar and Li disclose the method of claim 5. Sprague further discloses further comprising: when it is confirmed that the operation environment of the computing node is not credible or the operation content of the computing node is not secure, returning a result of connection insecurity to the user (Sprague [0038], [0075]. Example embodiments may be founded on the principles of the Trusted Network Connect (TNC) standards under which the integrity of a device may be verified prior to actual enablement of the connection to a network switch. According to TNC, a device performs a series of measurements that are securely stored on the device. The measurements typically would include validation of the BIOS image, the operating system (OS) and any applications that need to be verified that they have not been altered. Upon connection to the network, the switch would perform a validation process verifying that the measurement data matches a reference value that was computed when the device was either previously connected or in a current known good condition or state. The Trusted Execution Environment (TEE) is also capable of self-measurement processes and remote attestation of the health of the device. The current measurement is compared against the gold measurement or Reference Value in the block chain. If the measurements match the transaction is signed. If the measurements do not match, the request is rejected. If the measurements do not match, the device may be put through a registration renewal where a new measurement is gathered.).
Regarding claim 13, claim 13 is directed to a computer device corresponding to the method of claim 5. Claim 13 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a computer device corresponding to the method of claim 6. Claim 14 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a computer device corresponding to the method of claim 7. Claim 15 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a computer-readable storage medium corresponding to the method of claim 5. Claim 20 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Conclusion
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
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
1 An SSL session may incorporate encryption protocols (e.g., certificate, symmetric encryption, digital signature) to protect the privacy and authenticity of data communication.