DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The abstract of the disclosure is objected to because the abstract contains phrase “the present disclosure”.
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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, 6-7,8-9 ,13-14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lynn US 2005/0254514 in view of Hsueh et al US 2016/0156646 in view of Inoue et al US 2013/0254335.
As per claim 1. Lunn discloses A method, comprising:
visiting, by a client device, one or more web pages of a domain server ( 0012 /0015 a user at a client computer 100 (described in detail below) manipulates the computer to access a resource, e.g., a web site, web services server, i.e. a domain server or email server, provided by another computer 102 connected to the client computer via a communication path 103. 0052 A person using a browser (user) to access web sites may encounter a web site which restricts access using the present invention. In order for the user to gain access to the web site, i.e. web page of the domain server,, the user first obtains an appropriate token allowing access. This token could be requested in a number of ways similar to those currently used to request a user account at web sites. These include a) requesting access via an email address provided on the web site (this portion of the site allowing access to users without a token), and b) filling out a form on the web site with sufficient information for the web site to determine whether authorization should be granted. This determination may be performed either automatically by a web application or manually by personnel responsible for reviewing the requests. Once the request is approved, the token is emailed to the user as raw data, or in the form of a small installation program storing the token in memory on the user computer system);
storing a security token in a memory of the client device based on the visiting of the client device to the one or more web pages of the domain server (0052 Once the request is approved, the token is emailed to the user as raw data, or in the form of a small installation program storing the token , i.e. a security token, in memory on the user computer system ),
generating, by the client device, a client security token (0040 a token 200 is generated and transmitted to the web site ) that includes (i) a signature of a browser application of the client device based on a certificate issued to the browser application by the domain server (0041 client computer encrypts the data in the provided electronic token preventing unauthorized access to the data. par 0037, digital signature hashes, and encryption may be used singly and 0042 Computer 100 transmits the electronic token to the XYZ Corporation embedded in an email thereby allowing John Doe's email client to screen all incoming email except those bearing a valid electronic token 200) and (ii) the confidence score;
transmitting, by the client device and to a content server that differs from the domain server, the client security token with a request for content (0040 a token 200 is generated and transmitted to the web site i.e. content server, 0042 Computer 100 transmits the electronic token to the XYZ Corporation embedded in an email thereby allowing John Doe's email client to screen all incoming email except those bearing a valid electronic token 200 and 0042 Computer 100 transmits the electronic token to the XYZ Corporation embedded in an email thereby allowing John Doe's email client to screen all incoming email except those bearing a valid electronic token 200. i.e. security token); and
receiving, by the client device and from the content server, a response to the request for content based on an authentication of information included with the request for content and an evaluation of the confidence score by the content server (0023 token grantor identifier 202 identifies, i.e. an authentication of information, that response to the user, i.e. the client device, granting access to a resource, i.e. content server,, e.g., an identifier may include all or a portion of a user email address such as john.doe@isp.net or john.doe. 0021, Based on the contents of the electronic token, the client computer 100 determines whether to retain the email for further processing and possible presentation to the user at the client computer and 0050 Because of the verification of token grantor identifier 202 and token grantee identifier 204 in combination with the resource access control field 206, unrequested resource requests are quickly evaluated and filtered without requiring evaluation of the request content beyond the electronic token 200).
Lunn does not disclose
wherein: the security token includes a confidence score indicating a likelihood of the client device being associated with a malicious entity, and
the security token is signed using a certificate of the domain server.
Hsueh discloses wherein: the security token includes a confidence score indicating a likelihood of the client device being associated with a malicious entity(0040] At 404, the computing device 500 can perform training on the tokens to generate signal tokens that indicate in isolation that malware is present. The signal tokens can be based on groupings of tokens. in one example, each of the tokens can be given a score, i.e. a confidence score, based on the number of times the token is associated with malware and the number of times the token is associated with a benign application. The score can represent how likely the token is indicative of malware. The training can be used to determine which combinations of the tokens are more likely to indicate malware and 0044 a computing device capable of generating signal tokens indicative of malware based on groupings of tokens and the computing device 500 includes, for example, a processor 510, and a machine-readable storage medium 520 including instructions 522, 524 for generating signal tokens indicative of malware. As such the computing device 500 is malware entity).
Lunn and Hsueh are both considered to be analogous to the claimed invention because they are in the same field of token. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lunn to incorporate the teachings of Hsueh and provide a token comparison, Doing so would identify the malicious token, thereby to increase the security of the token exchange between domains.
The combination fails to disclose the security token is signed using a certificate of the domain server. However, Inoue discloses the security token is signed using a certificate of the domain server ([0098] Authentication among domains may be considered mandatory. but each domain that is authenticated on the integration (it may be considered a precondition that each user has been authenticated inside its domain before the integration). Only domain certifications are exchanged among domains. Each domain is authenticated by the security token singed with the certification.).
Lunn and Hsueh and Inoue are considered to be analogous to the claimed invention because they are in the same field of token. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lunn to incorporate the teachings of Hsueh, including the teaching of Inoue, and provide a token comparison, Doing so would identify the malicious token, thereby to increase the security of the token exchange between domains.
As per claim 2. Lunn and Hsueh and Inoue discloses the method of claim 1, the security token is signed using a group signature of a group of servers that includes the domain server (Lynn discloses par 0037, digital signature hashes, and encryption may be used singly or in combination to protect the electronic token information from unauthorized viewing and/or tampering and Inoue discloses 0018 federated gateway within each of multiple independent IT management domains bridges the independent IT management domains. As such, the independent IT management domains are in direct peer interaction. Service information of remote service providers, such as endpoint addresses of remote service providers and security policies, within remote independent IT management domains is automatically converted for use by service consumers in local independent IT management domains).
As per claim 6. Lunn and Hsueh and Inoue disclose the method of claim 1, Hsueh discloses wherein receiving the response to the request for content based on the authentication of information included with the request and the evaluation of the confidence score comprises receiving a first response to the request for content when the confidence score is below a specified threshold level ([0035] At 304, a set of the tokens indicative of malware can be determined. The set can be determined based on machine learning processing of the tokens and their respective associations with clean or malware code. For example, tokens generated largely from both can indicate that the token need not be used in malware analysis, whereas tokens generated more in malware containing code can be considered more indicative of malware. In some examples, a score or other evaluation can be associated with the respective tokens to determine the likeliness that the particular token is indicative of malware).
As per claim 7. Lunn and Hsueh and Inoue disclose the method of claim 1, Hsueh discloses wherein receiving the response to the request for content based on the authentication of information included with the request and the evaluation of the confidence score comprises receiving content selected based on the client security token when the confidence score is above a specified threshold level ([0039] At 402, tokens are retrieved from a database. The tokens can be generated using a static analysis of code. The tokens can also be associated with a malware application or a clean application binary or code. The static analysis can be based on obfuscation tolerant rules. The tokens may also be grouped based on particular applications. In some examples, tokens may be tagged to particular applications from which they were found, In some examples, the amount of times a token is generated can also be counted and recorded with the token. Moreover. the number of times a token is associated with a benign application and/or a malware ridden application can be counted and stored in a data structure associated with the token.[0040] At 404, the computing device 500 can perform training on the tokens to generate signal tokens that indicate in isolation that malware is present. The signal tokens can be based on groupings of tokens. in one example, each of the tokens can be given a score based on the number of times the token is associated with malware and the number of times the token is associated with a benign application. The score can represent how likely the token is indicative of malware. The training can be used to determine which combinations of the tokens are more likely to indicate malware).
As per claims 8-9, System claims are drawn to the system corresponding to the method of using same as claimed in claims 1-2, having limitations similar to those treated in the above rejection(s) Therefore, system claims 8-9 correspond to method claims 1-2, and are rejected for the same reasons of obviousness as used above.
The following limitation system comprising “a system comprising: one or more computer processors; and a memory device connected to the one or more computer processors, wherein the one or more computer processors are configured to perform operations” is further taught by Lynn see 0055 Computer system 100 also includes a main memory 306, such as a random access memory (RAM), 0058, the processor 304 to perform the process steps.. 0062] The received code may be executed by processor 304 as it is received, and/or stored in storage device 310,
As per claims 15-16, a non-transitory computer readable medium storing instructions that, upon execution by one o or more processor of a client device , cause the one or more processor to perform operations comprising: claims are drawn to the a non-transitory computer readable medium corresponding to the method of using same as claimed in claims 1-2, having limitations similar to those treated in the above rejection(s) Therefore, system claims 15-16 correspond to method claims 1-2, and are rejected for the same reasons of obviousness as used above.
The following limitation system comprising “a non-transitory computer readable medium storing instructions that, upon execution by one o or more processor of a client device , cause the one or more processor to perform operations “is further taught by Lynn see 0055 Computer system 100 also includes a main memory 306, such as a random access memory (RAM), 0058 ,the processor 304 to perform the process steps.. 0062] The received code may be executed by processor 304 as it is received, and/or stored in storage device 310,
As per clam 20, this claim is rejected based on the same rational set forth in the claim 6.
Claim(s) 3-5,10-12, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Lynn US 2005/0254514 in view of Hsueh et al US 2016/0156646 in view of Inoue et al US 2013/0254335 and in view of Yonezawa et al US 2009/0089575.
As per claim 3. Lunn and Hsueh and Inoue disclose the method of claim 2, the combination does not explicitly disclose wherein group signature includes an encrypted authentication string that identifies the group of servers upon decryption. However, Yonezawa discloses wherein group signature includes an encrypted authentication string that identifies the group of servers upon decryption (0093, For generating group signature data for a message, the signature apparatus encrypts the member certificate, i.e. authentication string, with a public key corresponding to an open key. The encrypted member certificate is referred to as encrypted data. The signature apparatus then calculates converted data of the member certificate. [0098] The group management apparatus decrypts the encrypted data included in the group signature data using the open key (secret key). Then, the group management apparatus seeks one, which agrees with the decrypted data, of the member certificates of all the signature apparatus that have been left upon issuance of the signature key. The signature apparatus corresponding to the member certificate that agrees with the decrypted data is the signature apparatus which has generated the group signature data). Lunn and Hsueh and Inoue and Yonezawa are considered to be analogous to the claimed invention because they are in the same field of token. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lunn to incorporate the teachings of Hsueh, including the teaching of Inoue, including the teaching of Yonezawa, and provide a token comparison, Doing so would identify the malicious token, thereby to increase the security of the token exchange between domains.
As per claim 4. Lunn and Hsueh and Inoue disclose the method of claim 2, the combination does not explicitly discloses further comprising: receiving, by the client device, a group certificate corresponding to a subgroup of servers among the group of servers; and anonymously signing, by the client device, the request for content using the group certificate.
However, Yonezawa discloses receiving, by the client device, a group certificate corresponding to a subgroup of servers among the group of servers ( [0098] The group management apparatus decrypts the encrypted data included in the group signature data using the open key (secret key). Then, the group management apparatus seeks one, which agrees with the decrypted data, of the member certificates of all the signature apparatus that have been left upon issuance of the signature key. The signature apparatus corresponding to the member certificate that agrees with the decrypted data is the signature apparatus which has generated the group signature data); and anonymously signing, by the client device, the request for content using the group certificate ([0109] Group key generator 101 generates public information, a member registration key (secret key), and an open key (secret key) used in the group signature scheme. The public information includes at least a public key corresponding to the member registration key (secret key), a public key corresponding to the open key (secret key), and common parameters used in the group signature scheme.).
Lunn and Hsueh and Inoue and Yonezawa are considered to be analogous to the claimed invention because they are in the same field of token. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lunn to incorporate the teachings of Hsueh, including the teaching of Inoue, including the teaching of Yonezawa, and provide a token comparison, Doing so would identify the malicious token, thereby to increase the security of the token exchange between domains.
As per claim 5. Lunn and Hsueh and Inoue and Yonezawa disclose the method of claim 4, the combination discloses wherein transmitting the client security token with the request for content comprises transmitting the client security token with the request for content and the group certificate (Hsueh discloses [0039] At 402, tokens are retrieved from a database. The tokens can be generated using a static analysis of code. The tokens can also be associated with a malware application or a clean application binary or code. The static analysis can be based on obfuscation tolerant rules. The tokens may also be grouped based on particular applications. In some examples, tokens may be tagged to particular applications from which they were found, In some examples, the amount of times a token is generated can also be counted and recorded with the token. Moreover. the number of times a token is associated with a benign application and/or a malware ridden application can be counted and stored in a data structure associated with the token and [0094] Then, the signature apparatus calculates certification data for certifying two conditions, i.e., (a) the value (namely, the member certificate) kept secret by the encrypted data and the converted data satisfies a formula for authenticating the digital signature for the converted data of the group signature key, and (b) the encrypted data are data generated by encrypting the value satisfying the condition (a) with the public key corresponding to the open key, using the message, the public information, the member certificate, the group signature key, the encrypted data, and the converted data).
As per claims 10-12, those claims are rejected based on the same rational forth in the claims 3-5 respectively.
As per claims 17-18, those claims are rejected based on the same rational forth in the claims 3-4 respectively.
As per clams 19, this claim is rejected based on the same rational set forth in the claim 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JORGE ORTIZ CRIADO can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496