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 .
Detail action
Claims 1-4 and 6-13 are pending and being considered.
Claims 1, 3 and 4 are amended.
Claim 6-13 have been newly added.
The double patenting rejection is held in abeyance.
Response to 102/103 rejections
Applicant’s arguments filed on 11/25/2025 have been fully considered and are persuasive but are moot in view of new grounds of rejections the arguments do not apply to the current art being used. For detail see the rejection below.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-4 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-5 of Co-pending application 18/567784. Although the claims at issue are not identical, they are not patentably distinct from each other. The claims of later patent are effectively subset of the claims of earlier patent, a later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896,225 USPQ at 651 (affirming a holding obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus). “ELI LILLY AND COMPANY VBARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ONPETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
This is provisional non-statutory double patenting rejection because the patentably indistinct claims have not in fact bee patented.
Current application 18/526136
Reference application 18/567784
1.a communication system comprising:
a user terminal that transmits and receives a message;
and a server device that manages a public key and a private key;
wherein the user terminal includes: first processing circuitry configured to: when transmitting the message to another user terminal, acquire a public key corresponding to identification information about a recipient of the message, and encrypt the message or a file attached to the message, using the acquired public key;
transmit, to the another user terminal, the message encrypted or the file attached to the message;
when receiving the message from the another user terminal, request the server device to provide a private key for decrypting the message or the file attached to the message, and receive the private key from the server device
and decrypt the message or the file attached to the message, using the private key received
and the server device includes second processing circuitry configured to: when accepting a request for the private key from the user terminal, generate the private key corresponding to the identification information about the recipient of the message, and transmit the private key to the user terminal;
wherein the encrypted message is decrypted only by the first processing circuitry of the user terminal
1.A communication system comprising:
a user terminal that transmits and receives a message;
and a server device that manages a public key and a private key,
wherein the user terminal includes: first processing circuitry configured to: when transmitting the message to another user terminal, acquire a public key corresponding to identification information about a recipient of the message, and encrypt the message or a file attached to the message, using the acquired public key, the identification information being other than the public key;
transmit, to the another user terminal, an encrypted message obtained by encrypting the message or the file attached to the message;
and when receiving the encrypted message from the another user terminal, request the server device to decrypt the encrypted message or the file attached to the encrypted message, and receive a decrypted message or file from the server device,
and the server device includes: second processing circuitry configured to: generate a private key corresponding to the identification information about the recipient of the message;
and when receiving a request for decryption of the message or the file attached to the message from the user terminal, decrypt the encrypted message or the file attached to the message using the private key generated, and transmit [[the]] a decrypted message or file to the user terminal that has made the request for decryption, the decrypted message corresponding to the encrypted message.
3 A user terminal comprising:
processing circuitry configured to:
transmit, to the another user terminal, the message encrypted the file attached to the message;
when receiving the message from the another user terminal, request a server device to provide a private key for decrypting the message or the file attached to the message, and receive the private key from the server device;
and
wherein the private key is generated based on affiliation information corresponding to a recipient of the encrypted message
3 A user terminal comprising:
processing circuitry configured to: when transmitting a message to another user terminal, acquire a public key corresponding to identification information about a recipient of the message, and encrypt the message or a file attached to the message, using the acquired public key, the identification information being other than the public key;
transmit, to the another user terminal, an encrypted message obtained by encrypting the message or the file attached to the message;
and when receiving the encrypted message from the another user terminal, request a server device to decrypt the encrypted message or the file attached to the encrypted message, and receive a decrypted message or file from the server device corresponding to the encrypted message or the file attached to the encrypted message.
4.A communication method implemented by a communication system that includes:
a user terminal that transmits and receives a message;
and a server device that manages a public key and a private key, the communication method comprising:
by the user terminal, when transmitting the message to another user terminal, acquiring a public key corresponding to identification information about a recipient of the message, and encrypting the message or a file attached to the message, using the acquired public key;
by the user terminal, transmitting, to the another user terminal, the message encrypted or the file attached to the message;
by the user terminal, when receiving the message from the another user terminal, requesting the server device to provide a private key for decrypting the message or the file attached to the message, and receiving the private key from the server device;
by the server device, when accepting a request for the private key from the user terminal, generating the private key corresponding to the identification information about the recipient of the message, and transmitting the private key to the user terminal;
by the user terminal, decrypting the message or the file attached to the message, using the private key received
and wherein the encrypted message is decrypted only by the user terminal
5.A communication method implemented by a communication system that includes:
a user terminal that transmits and receives a message;
and a server device that manages a public key and a private key, the communication method comprising:
by the user terminal, when transmitting the message to another user terminal, acquiring a public key corresponding to identification information about a recipient of the message, and encrypting the message or a file attached to the message, using the acquired public key, the identification information being other than the public key;
by the user terminal, transmitting, to the another user terminal, an encrypted message obtained in the encryption in which the message or the file attached to the message has been encrypted;
by the user terminal, when receiving the encrypted message from the another user terminal, requesting the server device to decrypt the encrypted message or the file attached to the encrypted message;
by the server device, generating a private key corresponding to the identification information about the recipient of the message; and by the server device, when receiving a request for decryption of the encrypted message or the file attached to the encrypted message from the user terminal, decrypting the encrypted message or the file attached to the encrypted message using the private key generated, and transmitting a decrypted message or file to the user terminal that has made the request for decryption, the decrypted message corresponding to the encrypted message.
The reference application 18/567784 discloses each and every element of the claimed invention except for the underlined feature of the claims above. Smith discloses the above underlined feature of the claims. One would be motivated to do so in order to protect sensitive information within the message to be exposed to unauthorized entity thereby allowing only the recipient to decrypt the message (Smith [0040]).
Dependent claims
Current application 18/526136
2
Reference application 18/567784
3
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 and 6-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pauker et al (hereinafter Pauker) (US 7266847 B2) in view of Smith et al (hereinafter Smith) (US 20190319964).
Regarding claim 1 Pauker teaches a communication system comprising: (Pauker Fig 1 block 10 and text on [col 5 line 5-10] teaches a secure messaging system);
a user terminal that transmits and receives a message (Pauker Fig 1 block 12 and text on [col 25-50] teaches senders and recipients are individuals. In general, however, senders and recipients may be individuals, groups of individuals, organizations, parts of organizations, or any other suitable parties or entities that exchange messages (i.e., transmit and receive messages). Further teaches users (i.e., sender and recipient) may communicate with each other using equipment 12 (i.e., terminal). Equipment 12 may, for example, include computing equipment such as a personal computer, portable computers, workstations, mainframe computers, networked computers or terminals, handheld computers, or any other suitable electronic equipment. Multiple individuals or organizations may use the same device. For example, a group of workers in an office may share the use of a single computer terminal that is connected to a host computer in a local area network);
and a server device that manages a public key and a private key (Pauker Fig 1 block 24 and text on [col 6 line 14-20] teaches one or more services such as private key service 24 (i.e., server device in view of [col 6 line 53-67] server device co-located with private key generator for managing public keys and private key) may be used to provide private keys. A private key service may include one or more IBE private key generators such as IBE private key generator 16 for generating IBE private keys);
wherein the user terminal includes first processing circuitry configured to: when transmitting the message to another user terminal, acquire a public key corresponding to identification information about a recipient of the message, and encrypt the message or a file attached to the message, using the acquired public key (Pauker Fig 2 block 32, 34 and text on [col 8 line 64-67 and col 9 line 1-10] teaches sender may obtain the PKE public key of a desired recipient. For example, the sender may obtain the PKE public key of a desired recipient from a public database (managed by server associated with private key generator [col 6 line 53-67]). Further teaches the sender may encrypt a message for the recipient using the PKE public key of the recipient and a PKE encryption algorithm in encryption engine 18. All or part of the message content may be encrypted to create the encrypted message. See on [col 12 line 1-9] teaches the sender uses an IBE public key that is generally based on the recipient's identity (i.e., public key corresponding to identification of recipient). The identity of a user in an IBE encryption scheme may be represented by any suitable string, number, or symbol. For example, the identity of a message recipient may be represented by or based on that recipient's email address, name, or social security number);
transmit, to the other user terminal, the message encrypted or the file attached to the message (Pauker Fig 1 block 36 and text on [col 9 line 12-17] teaches the sender may send the encrypted message to the recipient);
when receiving an encrypted message from the other user terminal, request the server device to provide a private key for decrypting the encrypted message or the file attached to the encrypted message, and receive the private key from the server device (Pauker Fig 1 block 38 and text on [col 9 line 18-25] teaches at step 38, the PKE private key of the recipient may be obtained for use by the decryption engine 20 that is to decrypt the encrypted message. The PKE private key may be obtained for use by a local decryption engine 20 or by a decryption engine 20 at a remote decryption service 22. See on [col 6 line 15-22 and col 14 line 4-25] teaches one or more services such as private key service 24 (i.e., server device in view of [col 6 line 53-60]) may be used to provide private keys. Once the IBE private key generator 16 verifies that the recipient is authorized to access the message contents, the private key may be generated by the IBE private key generator, the private key service 24 can release the requested IBE private key);
and decrypt the encrypted message or the file attached to the encrypted message, using the private key received (Pauker Fig 1 block 40 and text on [col 9 line 35-44] teaches after the PKE private key has been obtained, the decryption engine 20 at the recipient or decryption service may be used to decrypt the encrypted message content);
and the server device includes second processing circuitry configured to: when accepting a request for the private key from the user terminal, generate the private key corresponding to the identification information about the recipient of the encrypted message, and transmit the private key to the user terminal (Pauker on [col 6 line 15-22] teaches one or more services such as private key service 24 (i.e., server in view of [col 6 line 53-60]) may be used to provide private keys. A private key service may include one or more IBE private key generators such as IBE private key generator 16 for generating IBE private keys. PKE private keys may be generated using one or more PKE private key generators. After private keys are generated, they may be stored in a PKE private key store such as PKE private key store 26 at key service 24. See on [col 9 line 25-30] teaches during the process of obtaining the PKE private key, the recipient's credentials may be required (e.g., by the decryption service and/or private key service) to prove that the key requester is authorized to obtain the private key. Note that the recipient of the message uses decryption service 22 to decrypt the message (See [col 6 line 25-30]). See on [col 12 line 9-13] teaches IBE private key generator may generate an IBE private key for each of its associated users based on the IBE public keys (the Q's) of each of these users (e.g., based on the users' identities). See on [col 13 line 40-46] teaches only the IBE private key that matches the IBE public key that was used to encrypt the message may be used to decrypt the message. Generation of the IBE private key requires knowledge of the master secret s, so only the appropriate private key generator 16 can generate the recipient's IBE private key based on the recipient's IBE public key Q. See on [col 14 line 4-25] teaches once the IBE private key generator 16 verifies that the recipient is authorized to access the message contents, the private key may be generated by the IBE private key generator. username and password information may be supplied to the private key service 24. If the username and password information that is provided matches username and password information that the private key service has in a database of valid usernames and passwords, the private key service 24 can release the requested IBE private key).
Although Pauker teaches recipient of the message authorized to decrypt the message and wherein decryption service can also decrypt the message, Pauker fails to explicitly teach wherein the encrypted message is decrypted only by the first processing circuitry of the user terminal, however Smith from analogous art teaches wherein the encrypted message is decrypted only by the first processing circuitry of the user terminal (Smith on [0040] teaches only Node N3 decrypts the encrypted data).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Smith into the teaching of Pauker by having the first terminal device to decrypt the encrypted message. One would be motivated to do so in order to protect sensitive information within the message to be exposed to unauthorized entity thereby allowing only the recipient to decrypt the message (Smith [0040]).
Regarding claim 3 Pauker teaches a user terminal comprising: (Pauker Fig 1 block 12 and text on [col 25-50] teaches senders and recipients are individuals. In general, however, senders and recipients may be individuals, groups of individuals, organizations, parts of organizations, or any other suitable parties or entities that exchange messages with each other using equipment 12 (i.e., terminal). Equipment 12 may, for example, include computing equipment such as a personal computer, portable computers, workstations, mainframe computers, networked computers or terminals, handheld computers, or any other suitable electronic equipment. Multiple individuals or organizations may use the same device. For example, a group of workers in an office may share the use of a single computer terminal that is connected to a host computer in a local area network);
processing circuitry configured to: when transmitting a message to another user terminal,(Pauker Fig 2 block 32, 34 and text on [col 8 line 64-67 and col 9 line 1-10] teaches sender may obtain the PKE public key of a desired recipient. For example, the sender may obtain the PKE public key of a desired recipient from a public database (managed by server associated with private key generator [col 6 line 53-67]). Further teaches the sender may encrypt a message for the recipient using the PKE public key of the recipient and a PKE encryption algorithm in encryption engine 18. All or part of the message content may be encrypted to create the encrypted message. See on [col 12 line 1-9] teaches the sender uses an IBE public key that is generally based on the recipient's identity (i.e., public key corresponding to identification of recipient). The identity of a user in an IBE encryption scheme may be represented by any suitable string, number, or symbol. For example, the identity of a message recipient may be represented by or based on that recipient's email address, name, or social security number);
transmit, to the other user terminal, the message encrypted or the file attached to the message (Pauker Fig 1 block 36 and text on [col 9 line 12-17] teaches the sender may send the encrypted message to the recipient);
when receiving an encrypted message from the other user terminal, request a server device to provide a private key for decrypting the encrypted message or the file attached to the encrypted message, and receive the private key from the server device (Pauker Fig 1 block 38 and text on [col 9 line 18-25] teaches at step 38, the PKE private key of the recipient may be obtained for use by the decryption engine 20 that is to decrypt the encrypted message. The PKE private key may be obtained for use by a local decryption engine 20 or by a decryption engine 20 at a remote decryption service 22. See on [col 6 line 15-22 and col 14 line 4-25] teaches one or more services such as private key service 24 (i.e., server device in view of [col 6 line 53-60]) may be used to provide private keys. Once the IBE private key generator 16 verifies that the recipient is authorized to access the message contents, the private key may be generated by the IBE private key generator, the private key service 24 can release the requested IBE private key);
and(Pauker Fig 1 block 40 and text on [col 9 line 35-44] teaches after the PKE private key has been obtained, the decryption engine 20 at the recipient or decryption service may be used to decrypt the encrypted message content).
Although Pauker teaches recipient of the message authorized to decrypt the message and wherein decryption service can also decrypt the message, Pauker fails to explicitly teach wherein the encrypted message is decrypted only by the first processing circuitry of the user terminal, however Smith from analogous art teaches
wherein the private key is generated based on affiliation information corresponding to a recipient of the encrypted message (Smith on [0040] teaches Nodes (e.g., Node N1 605, Node N2 610, and Node N3 615) and Routers (e.g., Router R1 620 and Router R2 625) join the group by completing the join protocol which results in the creation of a group private key that is unique to each node)
and wherein the encrypted message is decrypted only by the first processing circuitry of the user terminal (Smith on [0040] teaches only Node N3 decrypts the encrypted data).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Smith into the teaching of Pauker by having the first terminal device to decrypt the encrypted message. One would be motivated to do so in order to protect sensitive information within the message to be exposed to unauthorized entity thereby allowing only the recipient to decrypt the message (Smith [0040]).
Regarding claim 4 Pauker teaches a communication method implemented by a communication system that includes: (Puker on [col 2 line 10-15] teaches system and method for exchanging messages);
a user terminal that transmits and receives a message (Pauker Fig 1 block 12 and text on [col 25-50] teaches senders and recipients are individuals. In general, however, senders and recipients may be individuals, groups of individuals, organizations, parts of organizations, or any other suitable parties or entities that exchange messages (i.e., transmit and receive messages). Further teaches users (i.e., sender and recipient) may communicate with each other using equipment 12 (i.e., terminal). Equipment 12 may, for example, include computing equipment such as a personal computer, portable computers, workstations, mainframe computers, networked computers or terminals, handheld computers, or any other suitable electronic equipment. Multiple individuals or organizations may use the same device. For example, a group of workers in an office may share the use of a single computer terminal that is connected to a host computer in a local area network);
and a server device that manages a public key and a private key (Pauker Fig 1 block 24 and text on [col 6 line 14-20] teaches one or more services such as private key service 24 (i.e., server device in view of [col 6 line 53-67] server device co-located with private key generator for managing public keys and private key) may be used to provide private keys. A private key service may include one or more IBE private key generators such as IBE private key generator 16 for generating IBE private keys);
the communication method comprising: by the user terminal when transmitting the message to another user terminal, acquiring a public key corresponding to identification information about a recipient of the message, and encrypting the message or a file attached to the message, using the acquired public key (Pauker Fig 2 block 32, 34 and text on [col 8 line 64-67 and col 9 line 1-10] teaches sender may obtain the PKE public key of a desired recipient. For example, the sender may obtain the PKE public key of a desired recipient from a public database (managed by server associated with private key generator [col 6 line 53-67]). Further teaches the sender may encrypt a message for the recipient using the PKE public key of the recipient and a PKE encryption algorithm in encryption engine 18. All or part of the message content may be encrypted to create the encrypted message. See on [col 12 line 1-9] teaches the sender uses an IBE public key that is generally based on the recipient's identity (i.e., public key corresponding to identification of recipient). The identity of a user in an IBE encryption scheme may be represented by any suitable string, number, or symbol. For example, the identity of a message recipient may be represented by or based on that recipient's email address, name, or social security number);
by the user terminal transmitting, to the other user terminal, the message encrypted or the file attached to the message (Pauker Fig 1 block 36 and text on [col 9 line 12-17] teaches the sender may send the encrypted message to the recipient);
by the user terminal when receiving an encrypted message from the other user terminal, requesting the server device to provide a private key for decrypting the encrypted message or the file attached to the encrypted message, and receiving the private key from the server device (Pauker Fig 1 block 38 and text on [col 9 line 18-25] teaches at step 38, the PKE private key of the recipient may be obtained for use by the decryption engine 20 that is to decrypt the encrypted message. The PKE private key may be obtained for use by a local decryption engine 20 or by a decryption engine 20 at a remote decryption service 22. See on [col 6 line 15-22 and col 14 line 4-25] teaches one or more services such as private key service 24 (i.e., server device in view of [col 6 line 53-60]) may be used to provide private keys. Once the IBE private key generator 16 verifies that the recipient is authorized to access the message contents, the private key may be generated by the IBE private key generator, the private key service 24 can release the requested IBE private key);
by the server device when accepting a request for the private key from the user terminal, generating the private key corresponding to the identification information about the recipient of the message, and transmitting the private key to the user terminal, (Pauker on [col 6 line 15-22] teaches one or more services such as private key service 24 (i.e., server in view of [col 6 line 53-60]) may be used to provide private keys. A private key service may include one or more IBE private key generators such as IBE private key generator 16 for generating IBE private keys. PKE private keys may be generated using one or more PKE private key generators. After private keys are generated, they may be stored in a PKE private key store such as PKE private key store 26 at key service 24. See on [col 9 line 25-30] teaches during the process of obtaining the PKE private key, the recipient's credentials may be required (e.g., by the decryption service and/or private key service) to prove that the key requester is authorized to obtain the private key. Note that the recipient of the message uses decryption service 22 to decrypt the message (See [col 6 line 25-30]). See on [col 12 line 9-13] teaches IBE private key generator may generate an IBE private key for each of its associated users based on the IBE public keys (the Q's) of each of these users (e.g., based on the users' identities). See on [col 13 line 40-46] teaches only the IBE private key that matches the IBE public key that was used to encrypt the message may be used to decrypt the message. Generation of the IBE private key requires knowledge of the master secret s, so only the appropriate private key generator 16 can generate the recipient's IBE private key based on the recipient's IBE public key Q. See on [col 14 line 4-25] teaches once the IBE private key generator 16 verifies that the recipient is authorized to access the message contents, the private key may be generated by the IBE private key generator. username and password information may be supplied to the private key service 24. If the username and password information that is provided matches username and password information that the private key service has in a database of valid usernames and passwords, the private key service 24 can release the requested IBE private key).
By the user terminal, decrypting the encrypted message or the file attached to the encrypted message, using the private key received (Pauker Fig 1 block 40 and text on [col 9 line 35-44] teaches after the PKE private key has been obtained, the decryption engine 20 at the recipient or decryption service may be used to decrypt the encrypted message content).
Although Pauker teaches recipient of the message authorized to decrypt the message and wherein decryption service can also decrypt the message, Pauker fails to explicitly teach wherein the encrypted message is decrypted only by the user terminal, however Smith from analogous art teaches
the identification information about the recipient including affiliation information of the recipient (Smith on [0040] teaches Nodes (e.g., Node N1 605, Node N2 610, and Node N3 615) and Routers (e.g., Router R1 620 and Router R2 625) join the group by completing the join protocol which results in the creation of a group private key that is unique to each node i.e., group information of node as affiliation information);
and wherein the encrypted message is decrypted only by the user terminal (Smith on [0040] teaches only Node N3 decrypts the encrypted data).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Smith into the teaching of Pauker by having the first terminal device to decrypt the encrypted message. One would be motivated to do so in order to protect sensitive information within the message to be exposed to unauthorized entity thereby allowing only the recipient to decrypt the message (Smith [0040]).
Regarding claims 2, 8 and 11 the combination of Pauker and Smith teaches all the limitations of claims 1, 3 and 4 respectively, Pauker further teaches wherein the first processing circuitry is further configured to encrypt the message or the file attached to the message, with policy information included in the message or the file, the policy information indicating a condition for allowing decryption (Pauker on [col 12 line 28-50] teaches when a validity period is used as part of an IBE public key Q, it is not permissible to access the contents of a message encrypted using that Q if the current date does not fall within the specified validity period. This policy may be enforced by the private key generators such as private key generator 16. If the current date is not within the validity period specified in the public key, a private key generator will refuse to generate and provide an otherwise authorized key requester (e.g., a message recipient or authorized agent for the message recipient) with a copy of the corresponding private key that is needed to decrypt the message. See on [col 13 line 1-5] teaches a sender desiring to send an IBE-encrypted message may have information sufficient to construct the IBE public key Q of the intended message recipient. This information may include information on an individual recipient's identity (e.g., an email address), information on how to construct the IBE public key Q from suitable access policy information (e.g., validity period, security level, subscription level, content rating, geographic region, etc.), or any other suitable identity information and/or generally-applicable access policy information that specifies which parties are allowed to access the contents of the message and under what conditions such access is permitted. See also on [col 13 line 60-67] teaches the private key generator 16 may use the access policy embodied in the IBE public key (in conjunction with optional additional policy criteria) to determine whether a given recipient is authorized).
Regarding claim 6, 9 and 12 the combination of Pauker and Smith teaches all the limitations of claims 2, 8 and 11 respectively, Pauker further teaches wherein the policy information is determined based on affiliation information of the recipient (Pauker on [col 13 line 1-14 and line 60-67] teaches the information may include information on an individual recipient's identity (e.g., an email address), information on how to construct the IBE public key Q from suitable access policy information (e.g., validity period, security level, subscription level, content rating, geographic region, etc.), or any other suitable identity information and/or generally-applicable access policy information that specifies which parties are allowed to access the contents of the message and under what conditions such access is permitted. The sender may obtain the IBE public parameter information from a recipient, from a directory, from IBE private key generator 16, from an IBE public parameter host service, or from any other suitable entity in system 10).
Regarding claim 7, 10 and 13 the combination of Pauker and Smith teaches all the limitations of claims 6, 9 and 12 respectively, Smith further teaches wherein the affiliation information includes at least one of a group to which the recipient belongs, recipient authority, and recipient position (Smith on [0040] teaches Nodes (e.g., Node N1 605, Node N2 610, and Node N3 615) and Routers (e.g., Router R1 620 and Router R2 625) join the group by completing the join protocol which results in the creation of a group private key that is unique to each node i.e., group information of node as affiliation information).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Smith into the teaching of Pauker by having the first terminal device to decrypt the encrypted message. One would be motivated to do so in order to protect sensitive information within the message to be exposed to unauthorized entity thereby allowing only the recipient to decrypt the message (Smith [0040]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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.
/MOEEN KHAN/Primary Examiner, Art Unit 2436
Prosecution Insights