DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the amendment filed 13 February 2026.
Claims 1-3, 5, 9-12, 18, and 19 were amended.
Claim 20 was cancelled.
Claims 1-19 are pending in this Office Action.
Response to Amendment
The objection to the specification regarding the title was addressed and is withdrawn.
The objection to claim 14 regarding a lack of antecedent basis was addressed and is withdrawn.
The rejection of claims 1-17 and 19 under 35 U.S.C. § 101 regarding non-statutory subject matter was addressed and is withdrawn.
Applicant’s amendments and arguments with respect to claims 1-19 filed on 13 February 2026 have been fully considered but they are deemed to be moot in view of the new grounds of rejection.
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.
Claims 1, 2, 5-8, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al. (U.S. 10,084,734) and further in view of Fried (U.S. 2012/0042017).
With respect to claim 1, Lu teaches a server comprising at least one processor and a memory storing instructions, which when executed by the at least one processor, cause the at least one processor to operate as: a receiver to receive an electronic mail addressed to a user (at step 504, one or more email messages are received for delivery to the user's inbox – see Lu, col. 12, lines 4-6); a classifier to classify the received electronic mail into one of (at step 504, one or more email messages are received for delivery to the user's inbox. At step 506, the information from the database is examined against the one or more rule-based criteria that have been configured or otherwise specified. In particular, the system and the mail client exchange information (namely, the output of the logic component) to update the email client spam filter(s). Thus, typically, any domain identified by the logic component is added to the whitelist and the associated email (from which that domain originates) is placed in the user's inbox. From this point onward, non-spam mail from this website is placed in the user's inbox – see Lu, col. 12, lines 4-18) a plurality of classes including (store email messages received by clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a "junk" (or "spam") folder, and an outbox folder – see Lu, col. 7, lines 22-25) a first class (an inbox folder – see Lu, col. 7, line 24) and a second class (a "junk" (or "spam") folder – see Lu, col. 7, line 25); a first storer to store (email server process 304 stores email messages for the different client email processes in email message database 320. The client email processes may store messages locally. For example, client email process 308 may store email messages in message file 322, client email process 310 may store email messages in message file 324, and client email process 312 may store email messages in message file 326. These message files store email messages received by the clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a "junk" (or "spam") folder, and an outbox folder – see Lu, col. 7, lines 14-25) a first-class email that is classified into the first class among other received electronic mails in a mailbox (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16) for reading assigned to the user (email messages are used by individuals to keep in touch with an communicate with others. Additionally, email messages provide a medium to collaborate and exchange documents. Email messages are often received by users in their inboxes. Users find the [email messages] that they wish to read – see Lu, col. 1, lines 13-23); an acceptor to accept a permission instruction from the user (user 336 interacts with browser application 340 and performs registration activities 338. Registration activities 338 identify websites from which user 336 desires to receive email messages – see Lu, col. 7, lines 61-63; col. 8, lines 14-15 and 28-29); a setter to set, after the acceptor accepts the permission instruction, a permission period (registration activities 338 are ones in which user 336 desires a relationship with the entity. This relationship may be a continuing relationship in which user 336 may receive information from the entity for some period of time. The continuing relationship may last until the user 336 performs an action to discontinue the relationship – see Lu, col. 8, lines 14-21 and 28-29) including an instruction time at which the permission instruction is accepted, wherein the permission period includes (registration activities 338 identified by plug-in 342 are sent to message process 328 in email server process 304 on server computer 306. Registration activities 338 are added to history of registration activities 348 for user 336. Message process 328 uses history of registration activities 348 and may be used to create email processing profile 334. Registration activities 338 also may be used to update email processing profile 334. History of registration activities 348 is used by message process 328 to generate email processing profile 334, update email processing profile 334, or perform a combination of the two – see Lu, col. 8, lines 55-65); and a second storer to store (email server process 304 stores email messages for the different client email processes in email message database 320. The client email processes may store messages locally. For example, client email process 308 may store email messages in message file 322, client email process 310 may store email messages in message file 324, and client email process 312 may store email messages in message file 326. These message files store email messages received by the clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a "junk" (or "spam") folder, and an outbox folder – see Lu, col. 7, lines 14-25) a notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) to make the extracted permitted email (the system is trained to un-spam (or "de-spam") a message – see Lu, col. 11, lines 30-31) readable (the system is trained to un-spam (or "de-spam") a message – see Lu, col. 11, lines 24-28 and 30-31) in the mailbox for reading (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16).
Lu does not explicitly teach a preceding period that starts before the instruction time; an extractor to retroactively extract, based on a reception time, a permitted email that was received during the preceding period before the instruction time from second-class emails that are classified into the second class.
However, Fried teaches a preceding period that starts before (email filter may cause an email application to store an incoming email to a particular directory of a storage device. The first input provides a first indication of whether a received email is a junk email, e.g., by the folder (e.g., a spam folder associated with an implemented email application) – see Fried, pages 2-3, paragraph 22) the instruction time (the agent also receives a second input from an application. The second input provides an indication of information of interest to a user – see Fried, pages 2-3 paragraph 22; the agent then reclassifies the received email based on the first or second indications – see Fried, page 3, paragraph 23); an extractor to retroactively extract (when an email is not classified correctly, agent 116 causes an incorrectly classified email to be reclassified – see Fried, Fig. 2, element 210; page 4, paragraph 31), based on a reception time (in decision block 208, agent 116 determines whether an email (received by client 110) has been classified correctly by email filter 121 of email application 120. Agent 116 may examine files stored on an hard disk drive (HDD) of data storage subsystem 104 to determine if the stored files have been stored in a correct folder (i.e., an inbox folder or a spam folder) – see Fried, page 4, paragraph 30), a permitted email (email 310, which has been reclassified (by agent 116) as an email in which the user has an interest – see Fried, Fig. 4, element 310; page 4, paragraph 32; agent 116 has caused email 310 to be redirected from spam folder 306 (see Fig. 3) to inbox folder 606 based on input (Fig. 4) – see Fried, page 4, paragraph 34) that was received during the preceding period (email filter may cause an email application to store an incoming email to a particular directory of a storage device. The first input provides a first indication of whether a received email is a junk email, e.g., by the folder (e.g., a spam folder associated with an implemented email application) – see Fried, pages 2-3, paragraph 22) before the instruction time (the agent also receives a second input from an application. The second input provides an indication of information of interest to a user – see Fried, pages 2-3 paragraph 22; the agent then reclassifies the received email based on the first or second indications – see Fried, page 3, paragraph 23) from second-class emails classified into (the first input provides a first indication of whether a received email is a junk email – see Fried, pages 2-3, paragraph 22) the second class (email 310 was saved in spam folder 306 due to the respective content of email 310 – see Fried, Fig. 3, element 310; page 4, paragraph 32).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lu in view of Fried in order to enable a preceding period that starts before the instruction time; an extractor to retroactively extract, based on a reception time, a permitted email that was received during the preceding period before the instruction time from second-class emails that are classified into the second class. One would be motivated to do so in order to enable the use of an email filter that may cause an email application to store an incoming email to a particular directory of a storage device and an agent may examine files on the storage device to determine if the files are stored in a correct directory based on interests of the user (Fried, pages 2-3, paragraph 22).
With respect to claim 2, the combination of Lu and Fried teaches the invention described in claim 1, including the server wherein the permission period further includes a following period that starts after the instruction time, and wherein the extractor prospectively extracts another permitted email that is received during the following period after the instruction time from the second-class emails classified into the second class (agent 116 has caused both emails 308 and 310 to be redirected from spam folder 306 (see FIG. 3) to inbox folder 606 based on input (e.g., that the user is interested in any drug manufactured by the Canadian Drug Company) received by agent 116 from one or more applications – see Fried, Fig. 6; page 4, paragraph 34).
The combination of references is made under the same rationale as claim 1 above.
With respect to claim 5, the combination of Lu and Fried teaches the invention described in claim 1, including the server wherein when no permission period includes a reception time at which a second-class email is received is set, the second-class email is temporarily kept (an entry in an email filter blacklist (i.e., an entry that was previously considered to be spam) – see Lu, col. 2, lines 41-43), and when the permission period is newly set (based on the user's navigation as determined by the tracking component – see Lu, col. 2, lines 39-40), the second-class email, which has been temporarily kept and is received at a reception time within the newly set permission period, is extracted as the permitted email (based on the user's navigation as determined by the tracking component, the logic component may generate an update command to cause an entry in an email filter blacklist (i.e., an entry that was previously considered to be spam) to be moved to the whitelist. In this manner, in effect the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 2, lines 39-44).
The combination of references is made under the same rationale as claim 1 above.
With respect to claim 6, the combination of Lu and Fried teaches the invention described in claim 1, including the server wherein by the user executing a control program in a control terminal (email processing profile 334 may be associated with user 336 at client computer 316 – see Lu, Fig. 3, elements 336, 334, 314; col. 7, lines 54-55), the permission instruction is transmitted from the control terminal to the server (registration activities 338 performed by user 336 is detected by plug-in 342 for browser application 340. Registration activities 338 identified by plug-in 342 are sent to message process 328 in email server process 304 on server computer 306. Registration activities 338 are added to history of registration activities 348 for user 336. Message process 328 uses history of registration activities 348 and may be used to create email processing profile 334. Registration activities 338 also may be used to update email processing profile 334. History of registration activities 348 is used by message process 328 to generate email processing profile 334, update email processing profile 334, or perform a combination of the two – see Lu, col. 8, lines 5-7 and 55-65).
The combination of references is made under the same rationale as claim 1 above.
With respect to claim 7, the combination of Lu and Fried teaches the invention described in claim 6, including the server wherein for the user to read an electronic mail stored (identify email messages that a user desires to read – see Lu, col. 8, lines 66-67) in the mailbox for reading (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16), using a reading (email system such as described above may be implemented in known commercial products and systems such as IBM® Notes®, Microsoft® Outlook®, Google® web-based Gmail®, and many others – see Lu, col. 9, lines 30-33) terminal (client computer 316 – see Lu, Fig. 3, element 316; col. 7, line 55), the control program is required to be executed in the control terminal (email processing profile 334 may be associated with user 336 at client computer 316. Email processing profile 334 may be located locally at client computer 314 – see Lu, Fig. 3, elements 336, 334, 316, 314; col. 7, lines 54-55 and col. 9, lines 28-29).
The combination of references is made under the same rationale as claim 1 above.
With respect to claim 8, the combination of Lu and Fried teaches the invention described in claim 1, including the server wherein the notice email has a same content as (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) the permitted email (the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 11, lines 30-31).
The combination of references is made under the same rationale as claim 1 above.
With respect to claim 16, the combination of Lu and Fried teaches the invention described in claim 1, including the server wherein the plurality of classes further includes (store email messages received by clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a “junk’ (or “spam”) folder, and an outbox folder – see Lu, col. 7, lines 22-25) a third class, and a third-class email classified into the third class among the received electronic mails is discarded or refused to be received (a deleted folder – see Lu, col. 7, lines 24-25).
The combination of references is made under the same rationale as claim 1 above.
With respect to claim 17, the combination of Lu and Fried teaches the invention described in claim 1, including the server wherein the mailbox for reading (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16) is prepared in a mail server different from (distributed data processing system 100 may include additional servers, clients, and other devices not shown – see Lu, Fig. 1, element 106; col. 3, lines 62-64) the server (server computer 306 may be, for example, server computer 104 in FIG. 1 implemented using data processing system 200 in FIG. 2 – see Lu, Fig. 1, element 104; col. 6, lines 62-64).
The combination of references is made under the same rationale as claim 1 above.
With respect to claim 18, Lu teaches a service method comprising: a reception step of receiving, by a server, an electronic mail addressed to a user (at step 504, one or more email messages are received for delivery to the user's inbox – see Lu, col. 12, lines 4-6); a classification step of classifying, by the server, the received electronic mail into one of (at step 504, one or more email messages are received for delivery to the user's inbox. At step 506, the information from the database is examined against the one or more rule-based criteria that have been configured or otherwise specified. In particular, the system and the mail client exchange information (namely, the output of the logic component) to update the email client spam filter(s). Thus, typically, any domain identified by the logic component is added to the whitelist and the associated email (from which that domain originates) is placed in the user's inbox. From this point onward, non-spam mail from this website is placed in the user's inbox – see Lu, col. 12, lines 4-18) a plurality of classes including (store email messages received by clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a “junk’ (or “spam”) folder, and an outbox folder – see Lu, col. 7, lines 22-25) a first class (an inbox folder – see Lu, col. 7, line 24) and a second class (a “junk” (or “spam”) folder – see Lu, col. 7, line 25); a first storage step of storing, by the server (email server process 304 stores email messages for the different client email processes in email message database 320. These message files store email messages received by the clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a “junk” (or “spam”) folder, and an outbox folder – see Lu, col. 7, lines 14-25), a first-class email that is classified into the first class among other received electronic mails in a mailbox (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16) for reading assigned to the user (email messages are used by individuals to keep in touch with an communicate with others. Additionally, email messages provide a medium to collaborate and exchange documents. Email messages are often received by users in their inboxes. Users find the [email messages] that they wish to read – see Lu, col. 1, lines 13-23); an acceptance step of accepting, by the server, a permission instruction from the user (user 336 interacts with browser application 340 and performs registration activities 338. Registration activities 338 identify websites from which user 336 desires to receive email messages – see Lu, col. 7, lines 61-63; col. 8, lines 14-15 and 28-29); a setting step of setting, by the server after the permission instruction is accepted, a permission period (registration activities 338 are ones in which user 336 desires a relationship with the entity. This relationship may be a continuing relationship in which user 336 may receive information from the entity for some period of time. The continuing relationship may last until the user 336 performs an action to discontinue the relationship – see Lu, col. 8, lines 14-21 and 28-29) including an instruction time at which the permission instruction is accepted, wherein the permission period includes (registration activities 338 identified by plug-in 342 are sent to message process 328 in email server process 304 on server computer 306. Registration activities 338 are added to history of registration activities 348 for user 336. Message process 328 uses history of registration activities 348 and may be used to create email processing profile 334. Registration activities 338 also may be used to update email processing profile 334. History of registration activities 348 is used by message process 328 to generate email processing profile 334, update email processing profile 334, or perform a combination of the two – see Lu, col. 8, lines 55-65); and a second storage step of storing, by the server (email server process 304 stores email messages for the different client email processes in email message database 320. These message files store email messages received by the clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a “junk” (or “spam”) folder, and an outbox folder – see Lu, col. 7, lines 14-25), a notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) to make the extracted permitted email (the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 11, lines 30-31) readable (the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 11, lines 24-28 and 30-31) in the mailbox for reading (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16).
Lu does not explicitly teach a preceding period that starts before the instruction time; an extraction step of retroactively extracting, by the server, based on a reception time, a permitted email that was received during the preceding period before the instruction time from second-class emails that are classified into the second class.
However, Fried teaches a preceding period that starts before (email filter may cause an email application to store an incoming email to a particular directory of a storage device. The first input provides a first indication of whether a received email is a junk email, e.g., by the folder (e.g., a spam folder associated with an implemented email application) – see Fried, pages 2-3, paragraph 22) the instruction time (the agent also receives a second input from an application. The second input provides an indication of information of interest to a user – see Fried, pages 2-3 paragraph 22; the agent then reclassifies the received email based on the first or second indications – see Fried, page 3, paragraph 23); an extraction step of retroactively extracting, by the server (when an email is not classified correctly, agent 116 causes an incorrectly classified email to be reclassified – see Fried, Fig. 2, element 210; page 4, paragraph 31), based on a reception time (in decision block 208, agent 116 determines whether an email (received by client 110) has been classified correctly by email filter 121 of email application 120. Agent 116 may examine files stored on an hard disk drive (HDD) of data storage subsystem 104 to determine if the stored files have been stored in a correct folder (i.e., an inbox folder or a spam folder) – see Fried, page 4, paragraph 30), a permitted email (email 310, which has been reclassified (by agent 116) as an email in which the user has an interest – see Fried, Fig. 4, element 310; page 4, paragraph 32; agent 116 has caused email 310 to be redirected from spam folder 306 (see Fig. 3) to inbox folder 606 based on input (Fig. 4) – see Fried, page 4, paragraph 34) that was received during the preceding period (email filter may cause an email application to store an incoming email to a particular directory of a storage device. The first input provides a first indication of whether a received email is a junk email, e.g., by the folder (e.g., a spam folder associated with an implemented email application) – see Fried, pages 2-3, paragraph 22) before the instruction time (the agent also receives a second input from an application. The second input provides an indication of information of interest to a user – see Fried, pages 2-3 paragraph 22; the agent then reclassifies the received email based on the first or second indications – see Fried, page 3, paragraph 23) from second-class emails classified into (the first input provides a first indication of whether a received email is a junk email – see Fried, pages 2-3, paragraph 22) the second class (email 310 was saved in spam folder 306 due to the respective content of email 310 – see Fried, Fig. 3, element 310; page 4, paragraph 32).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lu in view of Fried in order to enable a preceding period that starts before the instruction time; an extraction step of retroactively extracting, by the server, based on a reception time, a permitted email that was received during the preceding period before the instruction time from second-class emails that are classified into the second class. One would be motivated to do so in order to enable the use of an email filter that may cause an email application to store an incoming email to a particular directory of a storage device and an agent may examine files on the storage device to determine if the files are stored in a correct directory based on interests of the user (Fried, pages 2-3, paragraph 22).
With respect to claim 19, Lu teaches a non-transitory computer-readable information recording medium recording a program for causing a computer to function as: a receiver to receive an electronic mail addressed to a user (at step 504, one or more email messages are received for delivery to the user's inbox – see Lu, col. 12, lines 4-6); a classifier to classify the received electronic mail into one of (at step 504, one or more email messages are received for delivery to the user's inbox. At step 506, the information from the database is examined against the one or more rule-based criteria that have been configured or otherwise specified. In particular, the system and the mail client exchange information (namely, the output of the logic component) to update the email client spam filter(s). Thus, typically, any domain identified by the logic component is added to the whitelist and the associated email (from which that domain originates) is placed in the user's inbox. From this point onward, non-spam mail from this website is placed in the user's inbox – see Lu, col. 12, lines 4-18) a plurality of classes including (store email messages received by clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a “junk’ (or “spam”) folder, and an outbox folder – see Lu, col. 7, lines 22-25) a first class (an inbox folder – see Lu, col. 7, line 24) and a second class (a “junk” (or “spam”) folder – see Lu, col. 7, line 25); a first storer to store (email server process 304 stores email messages for the different client email processes in email message database 320. The client email processes may store messages locally. For example, client email process 308 may store email messages in message file 322, client email process 310 may store email messages in message file 324, and client email process 312 may store email messages in message file 326. These message files store email messages received by the clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a “junk” (or “spam”) folder, and an outbox folder – see Lu, col. 7, lines 14-25) a first-class email that is classified into the first class among other received electronic mails in a mailbox (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16) for reading assigned to the user (email messages are used by individuals to keep in touch with an communicate with others. Additionally, email messages provide a medium to collaborate and exchange documents. Email messages are often received by users in their inboxes. Users find the [email messages] that they wish to read – see Lu, col. 1, lines 13-23); an acceptor to accept a permission instruction from the user (user 336 interacts with browser application 340 and performs registration activities 338. Registration activities 338 identify websites from which user 336 desires to receive email messages – see Lu, col. 7, lines 61-63; col. 8, lines 14-15 and 28-29); a setter to set, after the acceptor accepts the permission instruction, a permission period (registration activities 338 are ones in which user 336 desires a relationship with the entity. This relationship may be a continuing relationship in which user 336 may receive information from the entity for some period of time. The continuing relationship may last until the user 336 performs an action to discontinue the relationship – see Lu, col. 8, lines 14-21 and 28-29) including an instruction time at which the permission instruction is accepted, wherein the permission period includes (registration activities 338 identified by plug-in 342 are sent to message process 328 in email server process 304 on server computer 306. Registration activities 338 are added to history of registration activities 348 for user 336. Message process 328 uses history of registration activities 348 and may be used to create email processing profile 334. Registration activities 338 also may be used to update email processing profile 334. History of registration activities 348 is used by message process 328 to generate email processing profile 334, update email processing profile 334, or perform a combination of the two – see Lu, col. 8, lines 55-65); and a second storer to store (email server process 304 stores email messages for the different client email processes in email message database 320. The client email processes may store messages locally. For example, client email process 308 may store email messages in message file 322, client email process 310 may store email messages in message file 324, and client email process 312 may store email messages in message file 326. These message files store email messages received by the clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a “junk” (or “spam”) folder, and an outbox folder – see Lu, col. 7, lines 14-25) a notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) to make the extracted permitted email (the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 11, lines 30-31) readable (the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 11, lines 24-28 and 30-31) in the mailbox for reading (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16).
Lu does not explicitly teach a preceding period that starts before the instruction time; an extractor to retroactively extract, based on a reception time, a permitted email that was received during the preceding period before the instruction time from second-class emails that are classified into the second class.
However, Fried teaches a preceding period that starts before (email filter may cause an email application to store an incoming email to a particular directory of a storage device. The first input provides a first indication of whether a received email is a junk email, e.g., by the folder (e.g., a spam folder associated with an implemented email application) – see Fried, pages 2-3, paragraph 22) the instruction time (the agent also receives a second input from an application. The second input provides an indication of information of interest to a user – see Fried, pages 2-3 paragraph 22; the agent then reclassifies the received email based on the first or second indications – see Fried, page 3, paragraph 23); an extractor to retroactively extract (when an email is not classified correctly, agent 116 causes an incorrectly classified email to be reclassified – see Fried, Fig. 2, element 210; page 4, paragraph 31), based on a reception time (in decision block 208, agent 116 determines whether an email (received by client 110) has been classified correctly by email filter 121 of email application 120. Agent 116 may examine files stored on an hard disk drive (HDD) of data storage subsystem 104 to determine if the stored files have been stored in a correct folder (i.e., an inbox folder or a spam folder) – see Fried, page 4, paragraph 30), a permitted email (email 310, which has been reclassified (by agent 116) as an email in which the user has an interest – see Fried, Fig. 4, element 310; page 4, paragraph 32; agent 116 has caused email 310 to be redirected from spam folder 306 (see Fig. 3) to inbox folder 606 based on input (Fig. 4) – see Fried, page 4, paragraph 34) that was received during the preceding period (email filter may cause an email application to store an incoming email to a particular directory of a storage device. The first input provides a first indication of whether a received email is a junk email, e.g., by the folder (e.g., a spam folder associated with an implemented email application) – see Fried, pages 2-3, paragraph 22) before the instruction time (the agent also receives a second input from an application. The second input provides an indication of information of interest to a user – see Fried, pages 2-3 paragraph 22; the agent then reclassifies the received email based on the first or second indications – see Fried, page 3, paragraph 23) from second-class emails classified into (the first input provides a first indication of whether a received email is a junk email – see Fried, pages 2-3, paragraph 22) the second class (email 310 was saved in spam folder 306 due to the respective content of email 310 – see Fried, Fig. 3, element 310; page 4, paragraph 32).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lu in view of Fried in order to enable a preceding period that starts before the instruction time; an extractor to retroactively extract, based on a reception time, a permitted email that was received during the preceding period before the instruction time from second-class emails that are classified into the second class. One would be motivated to do so in order to enable the use of an email filter that may cause an email application to store an incoming email to a particular directory of a storage device and an agent may examine files on the storage device to determine if the files are stored in a correct directory based on interests of the user (Fried, pages 2-3, paragraph 22).
Claims 3, 4, 9, 10, and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Fried and further in view of Polis et al. (U.S. 7,908,647).
With respect to claim 3, Lu teaches the invention described in claim 2, including a server comprising at least one processor and a memory storing instructions, which when executed by the at least one processor, cause the at least one processor to operate as: a receiver to receive an electronic mail addressed to a user (at step 504, one or more email messages are received for delivery to the user's inbox – see Lu, col. 12, lines 4-6); a classifier to classify the received electronic mail into one of (at step 504, one or more email messages are received for delivery to the user's inbox. At step 506, the information from the database is examined against the one or more rule-based criteria that have been configured or otherwise specified. In particular, the system and the mail client exchange information (namely, the output of the logic component) to update the email client spam filter(s). Thus, typically, any domain identified by the logic component is added to the whitelist and the associated email (from which that domain originates) is placed in the user's inbox. From this point onward, non-spam mail from this website is placed in the user's inbox – see Lu, col. 12, lines 4-18) a plurality of classes including (store email messages received by clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a "junk" (or "spam") folder, and an outbox folder – see Lu, col. 7, lines 22-25) a first class (an inbox folder – see Lu, col. 7, line 24) and a second class (a "junk" (or "spam") folder – see Lu, col. 7, line 25); a first storer to store (email server process 304 stores email messages for the different client email processes in email message database 320. The client email processes may store messages locally. For example, client email process 308 may store email messages in message file 322, client email process 310 may store email messages in message file 324, and client email process 312 may store email messages in message file 326. These message files store email messages received by the clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a "junk" (or "spam") folder, and an outbox folder – see Lu, col. 7, lines 14-25) a first-class email that is classified into the first class among other received electronic mails in a mailbox (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16) for reading assigned to the user (email messages are used by individuals to keep in touch with an communicate with others. Additionally, email messages provide a medium to collaborate and exchange documents. Email messages are often received by users in their inboxes. Users find the [email messages] that they wish to read – see Lu, col. 1, lines 13-23); an acceptor to accept a permission instruction from the user (user 336 interacts with browser application 340 and performs registration activities 338. Registration activities 338 identify websites from which user 336 desires to receive email messages – see Lu, col. 7, lines 61-63; col. 8, lines 14-15 and 28-29); a setter to set, after the acceptor accepts the permission instruction, a permission period (registration activities 338 are ones in which user 336 desires a relationship with the entity. This relationship may be a continuing relationship in which user 336 may receive information from the entity for some period of time. The continuing relationship may last until the user 336 performs an action to discontinue the relationship – see Lu, col. 8, lines 14-21 and 28-29) including an instruction time at which the permission instruction is accepted, wherein the permission period includes (registration activities 338 identified by plug-in 342 are sent to message process 328 in email server process 304 on server computer 306. Registration activities 338 are added to history of registration activities 348 for user 336. Message process 328 uses history of registration activities 348 and may be used to create email processing profile 334. Registration activities 338 also may be used to update email processing profile 334. History of registration activities 348 is used by message process 328 to generate email processing profile 334, update email processing profile 334, or perform a combination of the two – see Lu, col. 8, lines 55-65); and a second storer to store (email server process 304 stores email messages for the different client email processes in email message database 320. The client email processes may store messages locally. For example, client email process 308 may store email messages in message file 322, client email process 310 may store email messages in message file 324, and client email process 312 may store email messages in message file 326. These message files store email messages received by the clients and may be organized into various mailboxes. Examples of various mailboxes include an inbox folder, a sent folder, a deleted folder, a "junk" (or "spam") folder, and an outbox folder – see Lu, col. 7, lines 14-25) a notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) to make the extracted permitted email (the system is trained to un-spam (or "de-spam") a message – see Lu, col. 11, lines 30-31) readable (the system is trained to un-spam (or "de-spam") a message – see Lu, col. 11, lines 24-28 and 30-31) in the mailbox for reading (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16); and the server wherein the preceding period is updated according to an elapsed time from the reception time at which the permitted email (based on the user's navigation as determined by the tracking component, the logic component may generate an update command to cause an entry in an email filter blacklist (i.e., an entry that was previously considered to be spam) to be moved to the whitelist. In this manner, in effect the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 2, lines 39-44) that is; the notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60); notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) is received to the instruction time (generate an update command to cause an entry in an email filter blacklist (i.e., an entry that was previously considered to be spam) to be moved to the whitelist. In this manner, in effect the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 2, lines 41-44).
Lu does not explicitly teach a preceding period that starts before the instruction time; an extractor to retroactively extract, based on a reception time, a permitted email that was received during the preceding period before the instruction time from second-class emails that are classified into the second class.
However, Fried teaches a preceding period that starts before (email filter may cause an email application to store an incoming email to a particular directory of a storage device. The first input provides a first indication of whether a received email is a junk email, e.g., by the folder (e.g., a spam folder associated with an implemented email application) – see Fried, pages 2-3, paragraph 22) the instruction time (the agent also receives a second input from an application. The second input provides an indication of information of interest to a user – see Fried, pages 2-3 paragraph 22; the agent then reclassifies the received email based on the first or second indications – see Fried, page 3, paragraph 23); an extractor to retroactively extract (when an email is not classified correctly, agent 116 causes an incorrectly classified email to be reclassified – see Fried, Fig. 2, element 210; page 4, paragraph 31), based on a reception time (in decision block 208, agent 116 determines whether an email (received by client 110) has been classified correctly by email filter 121 of email application 120. Agent 116 may examine files stored on an hard disk drive (HDD) of data storage subsystem 104 to determine if the stored files have been stored in a correct folder (i.e., an inbox folder or a spam folder) – see Fried, page 4, paragraph 30), a permitted email (email 310, which has been reclassified (by agent 116) as an email in which the user has an interest – see Fried, Fig. 4, element 310; page 4, paragraph 32; agent 116 has caused email 310 to be redirected from spam folder 306 (see Fig. 3) to inbox folder 606 based on input (Fig. 4) – see Fried, page 4, paragraph 34) that was received during the preceding period (email filter may cause an email application to store an incoming email to a particular directory of a storage device. The first input provides a first indication of whether a received email is a junk email, e.g., by the folder (e.g., a spam folder associated with an implemented email application) – see Fried, pages 2-3, paragraph 22) before the instruction time (the agent also receives a second input from an application. The second input provides an indication of information of interest to a user – see Fried, pages 2-3 paragraph 22; the agent then reclassifies the received email based on the first or second indications – see Fried, page 3, paragraph 23) from second-class emails classified into (the first input provides a first indication of whether a received email is a junk email – see Fried, pages 2-3, paragraph 22) the second class (email 310 was saved in spam folder 306 due to the respective content of email 310 – see Fried, Fig. 3, element 310; page 4, paragraph 32).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lu in view of Fried in order to enable a preceding period that starts before the instruction time; an extractor to retroactively extract, based on a reception time, a permitted email that was received during the preceding period before the instruction time from second-class emails that are classified into the second class. One would be motivated to do so in order to enable the use of an email filter that may cause an email application to store an incoming email to a particular directory of a storage device and an agent may examine files on the storage device to determine if the files are stored in a correct directory based on interests of the user (Fried, pages 2-3, paragraph 22).
The combination of Lu and Fried does not explicitly teach when; and is read, made readable via the read.
However, Polis teaches when (implementations of functionality for the above mentioned interfaces also can affect the specific service being used. Similarly, an MSN message marked “unread” on the master server system web site can also cause the message to be marked unread on MSN [one of the above-mentioned services is Mark Message Read, which would suggest a similar functionality that was outlined before for unread messages could also be applied for read messages] – see Polis, col. 11, lines 42-54); and is read, made readable via the read (Mark Message Read – see Polis, col. 11, lines 42-43).
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 combination of Lu and Fried in view of Polis in order to enable when; and is read, made readable via the read. One would be motivated to do so in order to enable the use of an aggregated email account that allows the user to integrate their most commonly used emails into one location and that checks for unwanted messages (SPAM) and automatically apply blacklists. Aggregating across all of the services can bring consistency to an average user’s anti-spam solution (Polis, col. 4, lines 13-48).
With respect to claim 4, the combination of Lu, Fried, and Polis teaches the invention described in claim 2, including the server wherein the following period is updated according to an elapsed time (registration activities 338 are ones in which user 336 desires a relationship with the entity. This relationship may be a continuing relationship in which user 336 may receive information from the entity for some period of time. The continuing relationship may last until the user 336 performs an action to discontinue the relationship – see Lu, col. 8, lines 14-21 and 28-29) from the instruction time (registration activities 338 identified by plug-in 342 are sent to message process 328 in email server process 304 on server computer 306. Registration activities 338 are added to history of registration activities 348 for user 336. Message process 328 uses history of registration activities 348 and may be used to create email processing profile 334. Registration activities 338 also may be used to update email processing profile 334. History of registration activities 348 is used by message process 328 to generate email processing profile 334, update email processing profile 334, or perform a combination of the two – see Lu, col. 8, lines 55-65) to a reading time at which (Mark Message Read – see Polis, col. 11, lines 42-43) the notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) is read (Mark Message Read – see Polis, col. 11, lines 42-43).
The combination of references is made under the same rationale as claim 3 above.
With respect to claim 9, the combination of Lu, Fried, and Polis teaches the invention described in claim 1, including the server wherein the instructions further cause the at least one processor to operate as: a detector detect that (implementations of functionality for the above mentioned interfaces also can affect the specific service being used. Similarly, an MSN message marked “unread” on the master server system web site can also cause the message to be marked unread on MSN [one of the above-mentioned services is Mark Message Read, which would suggest a similar functionality that was outlined before for unread messages could also be applied for read messages] – see Polis, col. 11, lines 42-54) the notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) is read (Mark Message Read – see Polis, col. 11, lines 42-43); and a trainer to cause the classifier to learn a fact that a permitted email that is made readable via the read notice email has to be classified into the first class (at step 504, one or more email messages are received for delivery to the user's inbox. At step 506, the information from the database is examined against the one or more rule-based criteria that have been configured or otherwise specified. In particular, the system and the mail client exchange information (namely, the output of the logic component) to update the email client spam filter(s). Thus, typically, any domain identified by the logic component is added to the whitelist and the associated email (from which that domain originates) is placed in the user's inbox. From this point onward, non-spam mail from this website is placed in the user's inbox – see Lu, col. 12, lines 4-18).
The combination of references is made under the same rationale as claim 3 above.
With respect to claim 10, the combination of Lu, Fried, and Polis teaches the invention described in claim 9, including the server wherein the notice email is (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) a hypertext markup language (HTML) email (parse Email from html retrieved from above mentioned providers [Yahoo, MSN, Gmail, MySpace.com and SquirrelMail] for a particular user – see Polis, col. 12, lines 6-8), and when the notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) is read (Mark Message Read – see Polis, col. 11, lines 42-43) using a reading (email system such as described above may be implemented in known commercial products and systems such as IBM® Notes®, Microsoft® Outlook®, Google® web-based Gmail®, and many others – see Lu, col. 9, lines 30-33) terminal (client computer 316 – see Lu, Fig. 3, element 316; col. 7, line 55), a notification indicative that (implementations of functionality for the above mentioned interfaces also can affect the specific service being used. Similarly, an MSN message marked “unread” on the master server system web site can also cause the message to be marked unread on MSN [one of the above-mentioned services is Mark Message Read, which would suggest a similar functionality that was outlined before for unread messages could also be applied for read messages] – see Polis, col. 11, lines 42-54) the notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) is read is sent from the reading terminal to the server (implementations of functionality for the above mentioned interfaces also can affect the specific service being used. Similarly, an MSN message marked “unread” on the master server system web site can also cause the message to be marked unread on MSN [one of the above-mentioned services is Mark Message Read, which would suggest a similar functionality that was outlined before for unread messages could also be applied for read messages] – see Polis, col. 11, lines 42-54).
The combination of references is made under the same rationale as claim 3 above.
With respect to claim 12, the combination of Lu, Fried, and Polis teaches the invention described in claim 1, including the server wherein the instructions further cause the at least one processor to operate as: a detector to detect that (implementations of functionality for the above mentioned interfaces also can affect the specific service being used. Similarly, an MSN message marked “unread” on the master server system web site can also cause the message to be marked unread on MSN [one of the above-mentioned services is Mark Message Read, which would suggest a similar functionality that was outlined before for unread messages could also be applied for read messages] – see Polis, col. 11, lines 42-54) the notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) is read (Mark Message Read – see Polis, col. 11, lines 42-43); and a third storer to, when the notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) being read is detected (Mark Message Read – see Polis, col. 11, lines 42-43), store the permitted email (the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 11, lines 30-31) in the mailbox for reading (the associated email (from which that domain originates) is placed in the user's inbox – see Lu, col. 12, lines 15-16).
The combination of references is made under the same rationale as claim 3 above.
With respect to claim 13, the combination of Lu, Fried, and Polis teaches the invention described in claim 9, including the server wherein the classifier classifies the received electronic mail into the first class when a source domain of the received electronic mail is included in a permission list (an email filter 408, which typically includes a whitelist (a list of email addresses or domain names from which email is allowed) – see Lu, col. 9, lines 55-57), and the trainer adds (generate one or more email filter update commands that update the email filter in an automated manner, i.e., without user input. Thus, for example, and based on the user's navigation as determined by the tracking component, the logic component may generate an update command to cause an entry in an email filter blacklist (i.e., an entry that was previously considered to be spam) to be moved to the whitelist. In this manner, in effect the system is trained to un-spam (or “de-spam”) a message dynamically and in an automated fashion as the system builds confidence that a particular source (or initiator) of an in-bound email is or can be trusted – see Lu, col. 2, lines 36-47) a source domain of (update the email client spam filter(s). Thus, typically, any domain identified by the logic component is added to the whitelist and the associated email (from which that domain originates) is placed in the user's inbox. From this point onward, non-spam mail from this website is placed in the user's inbox – see Lu, col. 12, lines 4-18) a permitted email (the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 11, lines 30-31) that is made readable via (the system is trained to un-spam (or “de-spam”) a message – see Lu, col. 11, lines 24-28 and 30-31) the read notice email (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) to the permission list (the approach ensures that the user's email client does not block inappropriately email messages that the user expects and wants to receive, such as any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 54-60).
The combination of references is made under the same rationale as claim 3 above.
With respect to claim 14, the combination of Lu, Fried, and Polis teaches the invention described in claim 9, including the server wherein a plurality of addresses managed by the server (an email filter 408, which typically includes both a whitelist (a list of email addresses or domain names from which email is allowed) – see Lu, col. 9, lines 55-57) is associated with the user (registration activities 338 performed by user 336 is detected by plug-in 342 for browser application 340. Registration activities 338 identified by plug-in 342 are sent to message process 328 in email server process 304 on server computer 306. Registration activities 338 are added to history of registration activities 348 for user 336. Message process 328 uses history of registration activities 348 and may be used to create email processing profile 334. Registration activities 338 also may be used to update email processing profile 334. History of registration activities 348 is used by message process 328 to generate email processing profile 334, update email processing profile 334, or perform a combination of the two – see Lu, col. 8, lines 5-7 and 55-65), the server identifies the user associated with a destination address of the received electronic mail (at step 504, one or more email messages are received for delivery to the user's inbox – see Lu, col. 12, lines 4-6), the classifier classifies the received electronic mail into the first class (based on the information collected by the tracking component, the logic component then determines whether one or more email messages should be passed to the user's inbox (whitelisted) – see Lu, col. 12, lines 32-35) when a combination of a destination address and a source domain of the received electronic mail is included in a permission list (based on the information collected by the tracking component, the logic component then determines whether one or more email messages should be passed to the user's inbox (whitelisted) or marked as spam (blacklisted). In particular, if the rule-based criteria are met, then the website from which the email originates is now considered as not specious (or is otherwise trusted); the email client will then be able to successfully receive the email (and future emails) from the site – see Lu, col. 12, lines 32-40), and the trainer adds (generate one or more email filter update commands that update the email filter in an automated manner, i.e., without user input. Thus, for example, and based on the user's navigation as determined by the tracking component, the logic component may generate an update command to cause an entry in an email filter blacklist (i.e., an entry that was previously considered to be spam) to be moved to the whitelist. In this manner, in effect the system is trained to un-spam (or “de-spam”) a message dynamically and in an automated fashion as the system builds confidence that a particular source (or initiator) of an in-bound email is or can be trusted – see Lu, col. 2, lines 36-47) a combination of a destination address and a source domain of a permitted email that is made readable via (update the email client spam filter(s). Thus, typically, any domain identified by the logic component is added to the whitelist and the associated email (from which that domain originates) is placed in the user's inbox. From this point onward, non-spam mail from this website is placed in the user's inbox – see Lu, col. 12, lines 4-18) the read notice email to (any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 59-60) the permission list (the approach ensures that the user's email client does not block inappropriately email messages that the user expects and wants to receive, such as any service subscription that results in email notifications to the subscriber – see Lu, col. 12, lines 54-60).
The combination of references is made under the same rationale as claim 3 above.
With respect to claim 15, the combination of Lu, Fried, and Polis teaches the invention described in claim 14, including the server wherein when an optional character string in a predetermined pattern is removed from user names or domain names of a plurality of addresses associated with the user (the “rule-based criteria” may be based on one or more parameters, such as time (e.g., a time period as measured from when the user initiated a registration action, a particular time-of-day, etc.), recency of a user visit, whether the email results from some other defined user-initiated activity (e.g., a registration), a frequency of user visits, website categorization information (e.g., known newspaper or social networking sites), any prior update to a filter list characterization (i.e., a domain being un-spammed), or any other information (such as a URI-pattern match) or mechanism determining that the initiator of a particular email is a trusted site. Using a simple editor or configuration tool, the user or permitted person preferably specifies the one or more “rule-based criteria” that is then applied by the system as a spam policy. There may be multiple spam policies, and the system may provide one or more “templates” from which the user may choose, or the user may customize his or her spam policy or policies. The following are several sample “rules” that may be pre-configured and/or custom-configured using the interface: “Allow any message received from any [IP address, domain, sub-domain] accessed by user,” “Allow any message received from any IP address accessed by user within the last [time period],” “Allow any message received from a site that the user has visited more than [number] over [a specified time period],” “Allow any message received from [specified domain],” “Allow any message received from a [domain that has been de-spammed] within the last [time period],” “Allow any message received from a domain that has placed a cookie in the user's browser,” “Allow any message received in the last [time period] and that includes a URI string that includes [character string],” “Allow any message sent from a domain to which user has registered,” and so forth – see Lu, col. 10, line 38 – col. 11, line 4), a main character string identifying the user is obtained (user 336 entering an email address into a form at a website. The entry of an email address may be to register for information from a website. The entry of an email address also may be performed to register with the website to receive information about a purchase that user 336 makes – see Lu, col. 8, lines 43-48).
The combination of references is made under the same rationale as claim 3 above.
Allowable Subject Matter
Claim 11 is objected to as being dependent upon rejected base claims, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. 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 extension fee 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 Alicia Baturay whose telephone number is (571) 272-3981. The examiner can normally be reached at 7am – 4pm, Mondays – Thursdays, Eastern Time.
Examiner interviews are available via telephone, in person, or 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) form at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kamal Divecha can be reached at (571) 272-5863. The fax 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.
/Alicia Baturay/
Primary Examiner, Art Unit 2441
May 18, 2026
Prosecution Insights