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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/26/2025 was filed before the mailing of the first office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 9 is objected to because of the following informalities: the applicant recites a medium that is inactive in the claims (I.e. “executable”). It is recommended to the applicant to recite “the instructions, when executed by the computer system causes the computer system to perform operations comprising…” or something of the like. Appropriate correction is required.
Allowable Subject Matter
Claim 5, 13, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: the prior art, either alone or in combination does not expressly disclose a data transmission method or system such that in addition to sending session state information corresponding to the created session to the client device comprises: encrypting, by using one or more encryption keys, the session state information corresponding to the created session, to generate encrypted session state information; and sending the encrypted session state information to the client device and wherein encrypting the session state information corresponding to the created session to obtain the encrypted session state information comprises: encrypting, by using each encryption key of the one or more encryption keys in sequence, the session state information to obtain the encrypted session state information, wherein a kth encryption key encrypts the session state information that is encrypted using a (k-1)th encryption key, where k≤N, the system further encompasses wherein encrypting the session state information corresponding to the created session comprises: encrypting, by using the kth encryption key, the session state information that is encrypted using the (k-1)th encryption key to obtain basic encrypted session state information; and permuting, by using at least one predetermined permutation method, the basic encrypted session state information to obtain the session state information encrypted by using the kth encryption key, wherein the at least one predetermined permutation method comprises at least one of nonlinear permutation, linear permutation, or reverse permutation.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-4, 6-12 and 14-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over White (US 6,065,117) in view of Rouault (US 2004/0122961).
Regarding claim 1, 9, and 16, White discloses a data transmission method, a non-transitory, computer readable medium storing one or more instructions executable by a computer system to perform operation, and a computer-implemented system, comprising: one or more computers; and one or more computer memory devices interoperably coupled with the one or more computers and having tangible, non-transitory, machine-readable media storing one or more instructions that, when executed by the one or more computers, perform one or more operations comprising [column 3 lines 12-24]:
in response to receiving a connection request from a client device, determining, by a server, whether the connection request comprises session state information, wherein the session state information comprises parameters and a session identifier, wherein data transmission between the server and the client device is performed through a session based on the parameters [column 5 lines 63-column 6 lines 12] (operations for executing stateful client requests on a stateless server using an encrypted token containing state information are schematically illustrated. When a client requests an action to be performed by the server (Block 200), a determination is made whether the request is accompanied by an encrypted token (Block 202). If the client request is not accompanied by an encrypted token, the server may perform any necessary steps required before execution of the action can occur. These steps are specific to the particular client-server application and may be as simple as assuming some default values for state before performing the action or as complex as initiating an authentication sequence through dialog with the client (Block 204). When the outcome of these steps allows execution of the action (Block 206), the action is performed, a token is created, and the state of the server after execution is stored in the token (Block 208));
in response to determining that the connection request is absent of the session state information: creating a session between the server and the client device; and sending session state information corresponding to the created session to the client device [column 6 lines 48-67] (once a seed value is selected (Block 210), a symmetric key is generated by supplying the seed to the pseudo random number generator which is used in key generation (Block 212). As is known to those with skill in the art, a symmetric key is a key that can be used for both encryption and decryption. According to the present invention, the server receiving the client request performs both encryption and decryption of the token. Once a symmetric key is generated (Block 212), the token containing the state information (Block 208) is encrypted using the generated key (Block 214). The encrypted token is returned to the client along with the output of the requested action (Block 216).).
However, White does not expressly disclose but Rouault discloses: in response to determining that the connection request comprises the session state information: resuming the session between the server and the client device based on the session state information; and performing data transmission with the client device through the resumed session [0022-0023] (The client 15 will make a request to a failover server and the security assertion is included in the request (step 600). (The client 15 will typically be pre-configured with the location of fail-over server 25 that the request 600 is sent to. Additionally, there can be more than one fail-over server.) Since there is a failover situation, the client 15 is not sending a session token to a failover server. Instead, the client 15 is sending the security assertion in the request to the failover server. The security assertion permits the failover server 25 to detect that there is a failover situation and that the failover server 25 should attempt to establish a new local session with the particular client 15.).
It would have been obvious to one of ordinary skill in the art at to create the invention as claimed for the following reasons. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of White by resuming the session, for the purpose of allowing a consistent connection, based upon the beneficial teachings provided by Ref2, see for example [0023]. These modifications would result in ease of use and increased security, both of which are obvious benefits to the skilled artisan. Additionally, the cited references are in the field of computer security, as is the current application, and thus, are in analogous arts.
Regarding claims 2, 10, and 17, White and Rouault disclose all the limitations of independent claims 1, 9, and 16. White further discloses wherein sending session state information corresponding to the created session to the client device comprises: encrypting, by using one or more encryption keys, the session state information corresponding to the created session, to generate encrypted session state information; and sending the encrypted session state information to the client device [column 6 lines 48-60, fig 2] (once a seed value is selected (Block 210), a symmetric key is generated by supplying the seed to the pseudo random number generator which is used in key generation (Block 212). As is known to those with skill in the art, a symmetric key is a key that can be used for both encryption and decryption. According to the present invention, the server receiving the client request performs both encryption and decryption of the token. Once a symmetric key is generated (Block 212), the token containing the state information (Block 208) is encrypted using the generated key (Block 214). The encrypted token is returned to the client along with the output of the requested action (Block 216).).
Regarding claims 3, 11, and 18, White and Rouault disclose all the limitations of independent claims 1, 9, and 16. White further discloses wherein the one or more encryption keys are determined based on: obtaining an initial key and N key parameters, wherein N is a positive integer; and generating a first encryption key based on the initial key and a first key parameter of the N key parameters; and generating an Nth encryption key based on an (N–1)th encryption key and an Nth key parameter of the N key parameters [column 6 lines 48-60, fig 2] (once a seed value is selected (Block 210), a symmetric key is generated by supplying the seed to the pseudo random number generator which is used in key generation (Block 212). As is known to those with skill in the art, a symmetric key is a key that can be used for both encryption and decryption. According to the present invention, the server receiving the client request performs both encryption and decryption of the token. Once a symmetric key is generated (Block 212), the token containing the state information (Block 208) is encrypted using the generated key (Block 214). The encrypted token is returned to the client along with the output of the requested action (Block 216).).
Regarding claims 4, 12, and 19, White and Rouault disclose all the limitations of independent claims 1, 9, and 16. White further discloses wherein encrypting the session state information corresponding to the created session to obtain the encrypted session state information comprises: encrypting, by using each encryption key of the one or more encryption keys in sequence, the session state information to obtain the encrypted session state information, wherein a kth encryption key encrypts the session state information that is encrypted using a (k-1)th encryption key, where k≤N [column 6 lines 48-60, fig 2] (once a seed value is selected (Block 210), a symmetric key is generated by supplying the seed to the pseudo random number generator which is used in key generation (Block 212). As is known to those with skill in the art, a symmetric key is a key that can be used for both encryption and decryption. According to the present invention, the server receiving the client request performs both encryption and decryption of the token. Once a symmetric key is generated (Block 212), the token containing the state information (Block 208) is encrypted using the generated key (Block 214). The encrypted token is returned to the client along with the output of the requested action (Block 216).).
Regarding claims 6 and 14, White and Rouault disclose all the limitations of independent claims 1, 9, and 16. White further discloses wherein resuming the session between the server and the client device based on the session state information comprises: performing, based on a predetermined integrity verification algorithm, verification on the session state information comprised in the connection request; and in response to determining that the session state information passes verification, resuming the session between the server and the client device based on the session state information [column 6 lines 61-67, column 7 lines 1-18] (Once the received token is decrypted, a determination is made if the token is valid (Block 224) by examining the state information. A forged token could not be decrypted correctly and would have invalid state information. Similarly, the token may contain valid state information, but when the symmetric key used to encrypt the token differs from the key used to decrypt it, then the state information will not appear valid. For example, in the case where the day of the year is used to select the seed value for symmetric key generation, when the day of the year changes on the server system at midnight, any previously encrypted tokens will no longer be valid because the symmetric key generated using the new seed value will be different from the one used to encrypt it. If the state information is not valid or appears invalid because of a changed decryption key, then the requested action is not performed by the server and some appropriate response is provided to the client indicating the failure condition (Block 226).).
Regarding claims 7 and 15, White and Rouault disclose all the limitations of independent claims 1, 9, and 16. White further discloses wherein resuming the session between the server and the client device comprises: determining, based on a key identifier comprised in the session state information, one or more decryption keys corresponding to the session state information; decrypting the session state information by using each of the one or more decryption keys, to obtain decrypted session state information; and resuming the session between the server and the client device based on the decrypted session state information [column 6 lines 61-67, column 7 lines 1-18] (Once the received token is decrypted, a determination is made if the token is valid (Block 224) by examining the state information. A forged token could not be decrypted correctly and would have invalid state information. Similarly, the token may contain valid state information, but when the symmetric key used to encrypt the token differs from the key used to decrypt it, then the state information will not appear valid. For example, in the case where the day of the year is used to select the seed value for symmetric key generation, when the day of the year changes on the server system at midnight, any previously encrypted tokens will no longer be valid because the symmetric key generated using the new seed value will be different from the one used to encrypt it. If the state information is not valid or appears invalid because of a changed decryption key, then the requested action is not performed by the server and some appropriate response is provided to the client indicating the failure condition (Block 226).).
Regarding claims 8, White and Rouault disclose all the limitations of independent claims 1, 9, and 16. White further discloses determining, by a client device, a target server, wherein the target server is configured to perform data transmission with the client device through a session; determining whether the client device stores session state information of the session; and in response to determining that the client device stores the session state information, sending a connection request comprising the session state information to the target server, or in response to determining that the client device is absent of the session state information, sending a connection request to the target server, wherein the connection request indicates to create a session between the server and the client device [column 6 lines 48-67] (once a seed value is selected (Block 210), a symmetric key is generated by supplying the seed to the pseudo random number generator which is used in key generation (Block 212). As is known to those with skill in the art, a symmetric key is a key that can be used for both encryption and decryption. According to the present invention, the server receiving the client request performs both encryption and decryption of the token. Once a symmetric key is generated (Block 212), the token containing the state information (Block 208) is encrypted using the generated key (Block 214). The encrypted token is returned to the client along with the output of the requested action (Block 216).).
However, White does not expressly disclose but Rouault discloses: wherein the connection request indicates to resume the session between the server and the client device based on the session state information [0022-0023] (The client 15 will make a request to a failover server and the security assertion is included in the request (step 600). (The client 15 will typically be pre-configured with the location of fail-over server 25 that the request 600 is sent to. Additionally, there can be more than one fail-over server.) Since there is a failover situation, the client 15 is not sending a session token to a failover server. Instead, the client 15 is sending the security assertion in the request to the failover server. The security assertion permits the failover server 25 to detect that there is a failover situation and that the failover server 25 should attempt to establish a new local session with the particular client 15.).
The motivation to combine is the same as disclosed in point (11) above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Stapleton (US 2023/0421364) : discloses a method for protecting Sensitive Personal Information (SPI) from Multi-Party Access (MPA), including receiving a request for access to a data record, the request comprising an encrypted device identifier identifying the client device, encrypting the data record using a random symmetric key to generate an encrypted data record, encrypting the data record using a second symmetric key to generate a second encrypted data record, the second symmetric key being different from the random symmetric key, encrypting the random symmetric key to generate an encrypted symmetric key by using a public key associated with the client device or a key encryption key associated with the one or more processors, and transmitting a message comprising the encrypted symmetric key and the encrypted device identifier. The message causing the client device to access the data record using a database, the encrypted device identifier, and the encrypted symmetric key.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENDALL DOLLY whose telephone number is (571)270-1948. The examiner can normally be reached Monday-Friday 7am-3pm (EST).
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, Shewaye Gelagay can be reached at (571)272-4219. 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.
/KENDALL DOLLY/Primary Examiner, Art Unit 2436
Prosecution Insights