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 .
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.
DETAILED ACTION
This action is in response to applicant’s original submittal made on 01/31/2025. Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement filed 01/31/2025 fails to comply with 37 CFR 1.98(a)(1), which requires the following: (1) a list of all patents, publications, applications, or other information submitted for consideration by the Office; (2) U.S. patents and U.S. patent application publications listed in a section separately from citations of other documents; (3) the application number of the application in which the information disclosure statement is being submitted on each page of the list; (4) a column that provides a blank space next to each document to be considered, for the examiner’s initials; and (5) a heading that clearly indicates that the list is an information disclosure statement. The information disclosure statement has been placed in the application file, but the information referred to therein has not been considered.
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 8 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 7 and 13 of U.S. Patent No. 12,278,910 and 910’ hereinafter. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are drawn to the following:
(19/043141) Claim 1 receive, using an application executed within a web browser, an input comprising a message from a user addressed to a group, wherein the user is a member of the group; retrieve, from web browser storage, a first key generation secret generated by a key generation algorithm for the user, wherein the key generation algorithm generates, using a key generation secret, a new key generation secret and a new encryption key for message encryption; receive, from the key generation algorithm based on inputting the first key generation secret, a second key generation secret and a first encryption key; encrypt the message using the first encryption key into an encrypted message; store the second key generation secret within the web browser storage, wherein the second key generation secret is stored in association with the user; generate an encrypted message object, wherein the encrypted message object comprises the encrypted message and metadata associated with the encrypted message object; generate a cryptographic signature for the encrypted message object; add the cryptographic signature to the encrypted message object; generate a hypertext transport protocol request for the encrypted message object; and transmit the encrypted message object over hypertext transfer protocol to a serve; maps to (910’) Claim 1 one or more processors; and a non-transitory computer-readable storage medium storing instructions, which when executed by the one or more processors cause the one or more processors to: receive, using an application executed within a web browser, an input comprising a message from a user addressed to a group, wherein the user is a member of the group; retrieve, from web browser storage, a first key generation secret generated by a key generation algorithm for the user, wherein the key generation algorithm generates, using a key generation secret, a new key generation secret and a new encryption key for message encryption; receive, from the key generation algorithm based on inputting the first key generation secret, a second key generation secret and a first encryption key; encrypt the message using the first encryption key into an encrypted message; store the second key generation secret within the web browser storage, wherein the second key generation secret is stored in association with the user; determine a plurality of name-value pairs from metadata associated with the encrypted message; generate an encrypted message object, wherein the encrypted message object comprises a name-value pair for the encrypted message and the plurality of name-value pairs; generate a cryptographic signature for the encrypted message object; add the cryptographic signature as a new name-value pair to the encrypted message object; encode name-value pairs associated with the encrypted message object into one or more transport representations; generate a hypertext transport protocol request for each transport representation of the one or more transport representations; and transmit each hypertext transport protocol request to a server.
(19/043141) Claim 8 A method for providing encryption for group messages, the method comprising: receiving an input comprising a message from a user addressed to a group; retrieving a first key generation secret generated by a key generation algorithm for the user, wherein the key generation algorithm generates, using a key generation secret, a new key generation secret and a new encryption key for message encryption; receiving, from the key generation algorithm based on inputting the first key generation secret, a second key generation secret and a first encryption key; encrypting the message using the first encryption key into an encrypted message; storing the second key generation secret in association with the user; determining a plurality of name-value pairs from metadata associated with the encrypted message; generating an encrypted message object, wherein the encrypted message object comprises a name-value pair for the encrypted message and the plurality of name-value pairs; encoding name-value pairs associated with the encrypted message object into one or more transport representations; and transmitting the one or more transport representations to a server. maps to (910’) Claim 7 A method for providing end-to-end message encryption over hypertext transfer protocol, the method comprising: receiving an input comprising a message from a user addressed to a group, wherein the user is a member of the group; retrieving a first key generation secret generated by a key generation algorithm for the user, wherein the key generation algorithm generates, using a key generation secret, a new key generation secret and a new encryption key for message encryption; receiving, from the key generation algorithm based on inputting the first key generation secret, a second key generation secret and a first encryption key; encrypting the message using the first encryption key into an encrypted message; storing the second key generation secret in association with the user; determining a plurality of name-value pairs from metadata associated with the encrypted message; generating an encrypted message object, wherein the encrypted message object comprises a name-value pair for the encrypted message and the plurality of name-value pairs; encoding name-value pairs associated with the encrypted message object into one or more transport representations; generating a hypertext transport protocol request for each transport representation of the one or more transport representations; and transmitting each hypertext transport protocol request to a server.
(19/043141) Claim 15 receive a plurality of hypertext transport protocol requests, wherein the plurality of hypertext transport protocol requests comprises an encrypted message for a group in a format of an encrypted message object; store the encrypted message object in a database; determine a plurality of recipients associated with the encrypted message; generate one or more hypertext transport protocol messages comprising the encrypted message object; transmit the one or more hypertext transport protocol messages to a subset of the plurality of recipients that are currently active; determining that a first user device associated with a first recipient is inactive; based on determining that the first user device is inactive, identifying, based on prior communications with the first user device, a server within a server network for communicating with the first user device; and transmitting, to the server, a command to store the encrypted message object until the first user device is active. maps to (910’) Claim 13 receive a plurality of hypertext transport protocol requests, wherein the plurality of hypertext transport protocol requests comprises one or more binary representations associated with an encrypted message object, the encrypted message object comprising a message from a user within a group to the group; store the one or more binary representations in a database; decode the one or more binary representations into a plurality of name-value pairs associated with the encrypted message object; determine, using the plurality of name-value pairs, a plurality of recipients associated with the encrypted message object; generate one or more hypertext transport protocol messages comprising the one or more binary representations; transmit the one or more hypertext transport protocol messages to a subset of the plurality of recipients that are currently active; determine that a client device associated with a recipient of the plurality of recipients has become active; generate one or more new hypertext transport protocol messages comprising the one or more binary representations; and transmit the one or more new hypertext transport protocol messages to the client device.
Allowable Subject Matter
Claims 1, 8 and 15 would be allowable if rewritten or amended to overcome the rejection(s) under Double Patenting set forth in this Office action. The applicant is advised that an approved Terminal Disclaimer will overcome the rejection(s) set forth under Double Patenting.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRYAN F WRIGHT whose telephone number is (571)270-3826.
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, Eleni Shiferaw can be reached on (571)272-3867. 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.
/BRYAN F WRIGHT/Examiner, Art Unit 2497
Prosecution Insights