DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 11/08/2024. Claims 1-20 are pending in this examination.
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 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. This examination is in response to US Patent Application No. 18/942,181.
Claim Objection
Claims 18-20 are objected to because of the following informalities: These claims depend on dependent claim 16, however examiner determined this is a typographical error and for the purpose of this examination, claims 18-20 have been interpreted to depend on independent claim 17.
Claims 1-20 are objected to because of the following informalities: These claims contain bullets. Examiner recommend removing the bullets from the claims.
Appropriate correction is required.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure. The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words. The form and legal phraseology often used in patent claims, being “comprise”, "means" and "said," should be avoided. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, "The disclosure concerns," "The disclosure defined by this invention," "The disclosure describes," etc.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0080775) issued to Liebmann and in view of US Patent No. ( US2017/0214641) issued to Mishra.
Regarding claim 1, Liebmann discloses a method comprising: receiving a first electronic communication: sent by a sender; designating a recipient address associated with a recipient [¶23, a first email server A (205) can be used to send, forward, or otherwise process the delivery of an email 210a-b from an email account (and mailbox) accessed through a first client device 215 to other email mailboxes handled by email servers B and C (225 and 230 respectively). For instance, the sender of email 210a-b may have designated multiple recipients for the email, including recipient email mailboxes served or otherwise managed using two different email servers 225, 230.], and [ see FIG 4A, In the example of FIG. 4A, ¶31, an email client device 420 causes as email 430 to be sent using email server A 405. Email server A 405 can identify email servers B (410) and C (415) as corresponding to recipient email accounts (e.g., "abe@xyz.com" and "bob@abc.com") designated in email 430.]; and
in response to association of the recipient address with insufficient communication security [¶2, In some instances, however, once an email has been sent to a recipient, the sender loses a measure of control over the sent email and its contents. In many instances, the sender then relies entirely on the trustworthiness and vigilance of the recipient to protect and guard against the forwarding of the email contents using unsecure channels or to untrusted or unauthorized third parties]; and
initializing an instance of a secure web portal associated with the recipient[¶27, An encryption engine 365 can be used to encrypt emails processed using email server 305. Such encryption techniques can include mail session encryption, public-key encryption techniques, and other suitable encryption techniques. Emails can also be secured through other approaches, such as storing the email on a secure web server and sending the recipients a link to the stored email that prompts the recipients to authenticate themselves before being able to view the email in a web-based mail client.
initializing a secure communication thread accessible within the instance of the secure web portal
[0024] Turning to FIG. 2B, as is typical in modern email (and other text-based electronic) communications, a recipient of email 210a-b can elect to reply to the email 210a-b, causing a reply email to be generated and communicated. In some instances, a recipient of an email (e.g., 210a-b) can elect to reply to the sender of the email as well as one or more additional recipients other than the original sender, including other recipients of the original email.
[¶27, An encryption engine 365 can be used to encrypt emails processed using email server 305. Such encryption techniques can include mail session encryption, public-key encryption techniques, and other suitable encryption techniques. Emails can also be secured through other approaches, such as storing the email on a secure web server and sending the recipients a link to the stored email that prompts the recipients to authenticate themselves before being able to view the email in a web-based mail client.
populating the secure communication thread with contents of the first electronic communication
[¶31, In the example of FIG. 4A, an email client device 420 causes as email 430 to be sent using email server A 405. Email server A 405 can identify email servers B (410) and C (415) as corresponding to recipient email accounts (e.g., "abe@xyz.com" and "bob@abc.com") designated in email 430. Email server A 405 can further determine that email 430 should be encrypted and identify encryption protocols in place between email server A 405 and each of email servers B 410 and C 415, permitting encrypted transmission of email 430 to each of email servers B (410) and C (415).
associating the instance of the secure web portal and the secure communication thread with a hyperlink; generating a notification comprising the hyperlink; transmitting the notification to the recipient address in place of the first electronic communication
[¶27, An encryption engine 365 can be used to encrypt emails processed using email server 305. Such encryption techniques can include mail session encryption, public-key encryption techniques, and other suitable encryption techniques. Emails can also be secured through other approaches, such as storing the email on a secure web server and sending the recipients a link to the stored email that prompts the recipients to authenticate themselves before being able to view the email in a web-based mail client]; and
in response to selection of the hyperlink at a recipient device [¶27, Emails can also be secured through other approaches, such as storing the email on a secure web server and sending the recipients a link to the stored email that prompts the recipients to authenticate themselves before being able to view the email in a web-based mail client]; and
serving the instance of the secure web portal to a web browser at the recipient device; loading the secure communication thread into the instance of the secure web portal.
While Liebmann discloses these limitation as: [0024] Turning to FIG. 2B, as is typical in modern email (and other text-based electronic) communications, a recipient of email 210a-b can elect to reply to the email 210a-b, causing a reply email to be generated and communicated. In some instances, a recipient of an email (e.g., 210a-b) can elect to reply to the sender of the email as well as one or more additional recipients other than the original sender, including other recipients of the original email], and [¶27, An encryption engine 365 can be used to encrypt emails processed using email server 305. Such encryption techniques can include mail session encryption, public-key encryption techniques, and other suitable encryption techniques. Emails can also be secured through other approaches, such as storing the email on a secure web server and sending the recipients a link to the stored email that prompts the recipients to authenticate themselves before being able to view the email in a web-based mail client], and [0054] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification,
Liebmann does not explicitly disclose web-portal to the web browser however, Mishra discloses [0033] Email system 340 can indicate email 361 to user 301 over a graphical user interface or other user interface which can be provided by operating system 320 and user interface 321. User interface 321 can be a graphical user interface of an email application executed by user 301 on a computing device of user 301. User interface 321 can be a web-based interface or portal interface through which user 301 can view email in a browser application executed by user 301 on a computing device of user 301. User interface 321 can include smartphone or tablet apps which include one or more graphical user interfaces or web interfaces. User interface 321 can include a text-based or terminal interface.
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 teaching of Liebmann by incorporating “ web-based interface or portal interface”, as taught by Mishra. One could have been motivated to do so in order to user view email in a browser application executed by user on a computing device of user [ Mishra,0033].
Regarding claim 2, Liebmann discloses receiving a second electronic communication; sent by the sender; designating a second recipient address associated with a second recipient ; response to association of the second recipient address with sufficient secure communications, transmitting the second electronic communication to the second recipient address [¶23, Traditional email systems can provide for encryption and secure communication between email servers and endpoints. For instance, in a first example, shown in FIGS. 2A-2B, a first email server A (205) can be used to send, forward, or otherwise process the delivery of an email 210a-b from an email account (and mailbox) accessed through a first client device 215 to other email mailboxes handled by email servers B and C (225 and 230 respectively). For instance, the sender of email 210a-b may have designated multiple recipients for the email, including recipient email mailboxes served or otherwise managed using two different email servers 225, 230. Accordingly, in this example, delivery of email copy 210a to email server B (225) is sent over a first secured channel between email server A (205) and email server B (225). Further, delivery of email copy 210b to email server C (230) is sent over a first secured channel between email server A (205) and email server C (230). Using such techniques, an email 210a-b can be delivered to recipient clients 235, 240 over a reasonably secured channel.], and [ see FIG 4A, In the example of FIG. 4A, ¶31, an email client device 420 causes as email 430 to be sent using email server A 405. Email server A 405 can identify email servers B (410) and C (415) as corresponding to recipient email accounts (e.g., "abe@xyz.com" and "bob@abc.com") designated in email 430], and [¶44].
[¶13, Email transmissions can be capable of being secured between a first server associated with the first email account and each of a second server associated with the second email account and a third server associated with the third email account].
Regarding claim 4, further comprising, following transmission of the onboarding text message: receiving a second electronic communication from the recipient and designating the sender, the second electronic communication comprising a second text message; generating a third text message comprising the hyperlink; transmitting the third text message to the recipient via the recipient address; and" in response to the recipient selecting the hyperlink: initializing the instance of the secure web portal for access via the web browser at the recipient device; and populating the instance of the secure web portal with the secure communication thread comprising the first electronic communication, the second electronic communication, and the third electronic communication.
While Liebmann discloses these limitation as: [0024] Turning to FIG. 2B, as is typical in modern email (and other text-based electronic) communications, a recipient of email 210a-b can elect to reply to the email 210a-b, causing a reply email to be generated and communicated. In some instances, a recipient of an email (e.g., 210a-b) can elect to reply to the sender of the email as well as one or more additional recipients other than the original sender, including other recipients of the original email], and [¶27, An encryption engine 365 can be used to encrypt emails processed using email server 305. Such encryption techniques can include mail session encryption, public-key encryption techniques, and other suitable encryption techniques. Emails can also be secured through other approaches, such as storing the email on a secure web server and sending the recipients a link to the stored email that prompts the recipients to authenticate themselves before being able to view the email in a web-based mail client. Emails can also be secured through other approaches, such as storing the email on a secure web server and sending the recipients a link to the stored email that prompts the recipients to authenticate themselves before being able to view the email in a web-based mail client…], and [0054] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification,
Liebmann does not explicitly disclose web-portal to the web browser however, Mishra discloses [0033] Email system 340 can indicate email 361 to user 301 over a graphical user interface or other user interface which can be provided by operating system 320 and user interface 321. User interface 321 can be a graphical user interface of an email application executed by user 301 on a computing device of user 301. User interface 321 can be a web-based interface or portal interface through which user 301 can view email in a browser application executed by user 301 on a computing device of user 301. User interface 321 can include smartphone or tablet apps which include one or more graphical user interfaces or web interfaces. User interface 321 can include a text-based or terminal interface.
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 teaching of Liebmann by incorporating “ web-based interface or portal interface”, as taught by Mishra. One could have been motivated to do so in order to user view email in a browser application executed by user on a computing device of user [ Mishra,0033].
Regarding claim 16, Liebmann discloses further comprising associating the recipient address with insufficient communication security in response to detecting absence of end-to-end encryption at a messaging platform associated with the recipient address.
[0025] On the other hand, in the particular example of FIG. 2B, while secured email communication channels existed between server A (205) and each of server B (225) and C (230) (and vice versa), no such arrangement may exist between email servers of the respective recipients (e.g., between email servers B and C). This can present a problem, for instance, when either user 235 or user 240 attempts to reply or reply-all to the email 210a-b. In the present example of FIG. 2B, encryption or security measures may not exist, or be of a lower quality or standard (or a standard not in compliance with policies or preferences of the original sender (e.g., 205)), than that employed during the sending of the original email 210a-b. Accordingly, when user 240 replies-all to email 210a-b and a reply 250b is sent to server B (225), the copy 250b of the reply email may not be adequately encrypted or otherwise secured, relative to the original email 210a-b. This can result in a "hole" in security, potentially resulting in content of email 210a-b being compromised (through reply email 250a-b), notwithstanding the original efforts to encrypt and protect the content of email 210a-b.
Regarding claim 17, this claim is interpreted and rejected for the same rational set forth in claim 1.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0080775) issued to Liebmann and in view of US Patent No. ( US2017/0214641) issued to Mishra, and further in view of ( US2014/0328256) issued to Diukic.
Regarding claim 3, Liebmann discloses wherein receiving the first electronic communication comprises receiving the first electronic communication comprising a text message; and further comprising: in response to absence of a history of communication between the sender and the recipient, transmitting an onboarding text message to the recipient address; associating the recipient address with insufficient messaging security [¶2, In many instances, the sender then relies entirely on the trustworthiness and vigilance of the recipient to protect and guard against the forwarding of the email contents using unsecure channels or to untrusted or unauthorized third parties], and [0024] Turning to FIG. 2B, as is typical in modern email (and other text-based electronic) communications, a recipient of email 210a-b can elect to reply to the email 210a-b, causing a reply email to be generated and communicated].
Liebmann , and Mishra do not explicitly disclose, however, Diukic discloses in response to absence of receiving a delivery receipt within a timeout duration following transmission of the onboarding text message, [0030] The expiration timer is a configurable parameter that is coordinated on both ends of transmission/reception. Therefore, the receiver may indicate to the transmitter the length of its expiration timer after the first reception (e.g., as part of an acknowledgement signal). Alternatively, the transmitter may indicate to the receiver the length of the expiration timer in a first transmission of a traffic session (i.e., a transmission using format type 0 or type 2). The expiration timer may be set to be slightly longer than the expected length of a traffic session. Therefore, the length of the expiration timer may vary depending on the type of various transmissions. For example, if the transmitter/receiver determines the transmissions relate to an internet browsing session or a telephone call, the expiration timer may have a length in the order of minutes. However, if the transmitter/receiver determines the transmissions are text messages, the expiration timer may have a length in the order of seconds. The length of various expiration timers may be defined by a standard, for example, in a table and the transmitter/receiver may determine the type of a transmission (e.g., either through explicit signaling or deduction from transmission contents) and an appropriate expiration timer length from the table.
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 teaching of Liebmann, and Mishra by incorporating “expiration timer on both ends of transmission/reception”, as taught by Diukic. One could have been motivated to do so in order to setup the expiration timer for various transmission such as if the transmitter/receiver determines the transmissions are text messages, the expiration timer may have a length in the order of seconds [ Diukic, 0030].
Claims 5-7, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0080775) issued to Liebmann and in view of US Patent No. ( US2017/0214641) issued to Mishra, and further in view of US2004/0267625) issued to Feng.
Regarding claim 5, Liebmann does not explicitly disclose further comprising: " populating a contact card with the hyperlink and a sender address associated with the sender; and " serving the instance of the secure web portal to the web browser at the recipient device in response to selection of the hyperlink from the contact card at the recipient device
While Mishra discloses web-portal to the web browser however, Mishra discloses [0033] Email system 340 can indicate email 361 to user 301 over a graphical user interface or other user interface which can be provided by operating system 320 and user interface 321. User interface 321 can be a graphical user interface of an email application executed by user 301 on a computing device of user 301. User interface 321 can be a web-based interface or portal interface through which user 301 can view email in a browser application executed by user 301 on a computing device of user 301. User interface 321 can include smartphone or tablet apps which include one or more graphical user interfaces or web interfaces. User interface 321 can include a text-based or terminal interface.
furthermore, Feng discloses :
[0147] FIG. 8A is a schematic screen showing an exemplary address card received in e-mail by a member which was sent by the sender of the address card illustrated in FIGS. 7A, 7B and 7C. The screen 800 includes a hyperlink 801 which invokes the "What Information do You Want to Share" screen 740 as shown in FIG. 7D. The screen also includes a hyperlink 802 which invokes the "address card Added to address book" tab 810 as shown in FIG. 8B.
[0148] When the recipient of the e-mail screen 800 clicks the "accept and share" link 801, and, if he chooses to share his "Personal Information" or "Work Information" and clicks "Send" button 742, the sender of the e-mail screen 800 (i.e. the publisher who sends his address card initially) will receive an e-mail as illustrated in FIG. 9A. The e-mail screen 900 includes an "Internet address card(s)" attachment link 901, which invokes an option screen 910 as shown in FIG. 9B for the e-mail recipient to select the contacts he wants to add to his address book. If only one address card is attached, when the link 901 is clicked, the attached card is automatically added to the recipient's address book and a non-editable receive view is invoked], and [0114] A member/publisher can share his address card with certain designated recipients who may then choose to subscribe. Sharing may take place via e-mail or a new "direct" one-click communication mechanism. He can share an address card with all or part of the address book/"buddy list", leveraging "people lists". He can also share his address card with recipients of mail messages. He can even make his address card public, open to subscription by any member. The publisher may configure an expiration period of time for a publish offer or an invitation to share], and [ 0112-0113] , and [ see Fig. 6H and corresponding text for more details].
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 teaching of Liebmann, and Mishra by incorporating “sender’s address card and a hyperlink in an email”, as taught by Feng. One could have been motivated to do so in order for a member/publisher can share his address card with certain designated recipients who may then choose to subscribe. Sharing may take place via e-mail or a new "direct" one-click communication mechanism [ Feng, 0114, 0147].
Regarding claim 6, the combination of Liebmann, Mishra, and Feng disclose further comprising: " assigning an expiry time to the hyperlink; " at a second time succeeding the expiry time and in response to the recipient selecting the hyperlink: initializing the instance of the secure web portal for access via the web browser at the recipient device; populating the instance of the secure web portal with a prompt indicating selection of the hyperlink past the expiry time; and transmitting a second electronic communication comprising a second hyperlink to the recipient; and" in response to selection of the second hyperlink at the recipient device; initializing the instance of the secure web portal for access via the web browser at the recipient device; and o populating the instance of the secure web portal with the secure communication thread.
Liebmann discloses [ 002, 0013, 0023-0024, 0027,0031, 0044, 0054].
Furthermore , Mishra discloses [0033].
And furthermore, Feng discloses [0074] A sharing relationship defines what and how a specific group of community members can do on the shared resource during the lifespan, i.e. the duration, of the sharing relationship. The life span may be "one-time only" or "ongoing". [0112-0114, A member/publisher can share his address card with certain designated recipients who may then choose to subscribe. Sharing may take place via e-mail or a new "direct" one-click communication mechanism. He can share an address card with all or part of the address book/"buddy list", leveraging "people lists". He can also share his address card with recipients of mail messages. He can even make his address card public, open to subscription by any member. The publisher may configure an expiration period of time for a publish offer or an invitation to share], and [0124] While the address card works best among registered members, it still supports sharing with non-members through the export of standard contact card formats for a seamless sharing experience. Publish/subscribe for non-members includes e-mail-based updates for published modifications. If a member/publisher chooses to publish his address card to a non-member contact, the non-member contact then receives a notification of the publication via e-mail with information embedded and a vCard attached that contains the member's address card information. The publisher can insert a personal note in the e-mail generated on an initial publish (This also applies to any mails sent to members). In the published e-mail sent to a non-member, the non-member can opt-in (subscribe) to future address card modifications via a link in the e-mail. If the non-member opts in, any modification made to the address card then generates an e-mail to him with updated information embedded and the vCard attached. Each update e-mail offers the ability to opt out (unsubscribe).
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 teaching of Liebmann, and Mishra by incorporating “sharing relationship”, as taught by Feng. One could have been motivated to do so in order for defining what and how a specific group of community members can do on the shared resource during the lifespan, i.e. the duration, of the sharing relationship. The life span may be "one-time only" or "ongoing" or predetermined expiration period of time [ Feng, 0074. 0112-0114].
Regarding claim 7, the combination of Liebmann, Mishra, and Feng disclose further comprising identifying a first address type of the recipient address; " wherein populating the contact card with the hyperlink and the sender address comprises populating the contact card with the sender address of the first address type; and " further comprising: generating a prompt comprising a request for a second recipient address of a second address type; populating the secure communication thread with the prompt; and in response to receiving the second recipient address of the second address type from the recipient in the secure communication thread:- updating the contact card with a second sender address of the second address type; and- transmitting the contact card to the recipient address.
Liebmann discloses [ 002, 0013, 0023-0024, 0027,0031, 0044, 0054].
Furthermore , Mishra discloses [0033].
And furthermore, Feng discloses [0147] FIG. 8A is a schematic screen showing an exemplary address card received in e-mail by a member which was sent by the sender of the address card illustrated in FIGS. 7A, 7B and 7C. The screen 800 includes a hyperlink 801 which invokes the "What Information do You Want to Share" screen 740 as shown in FIG. 7D. The screen also includes a hyperlink 802 which invokes the "address card Added to address book" tab 810 as shown in FIG. 8B.
[0148] When the recipient of the e-mail screen 800 clicks the "accept and share" link 801, and, if he chooses to share his "Personal Information" or "Work Information" and clicks "Send" button 742, the sender of the e-mail screen 800 (i.e. the publisher who sends his address card initially) will receive an e-mail as illustrated in FIG. 9A. The e-mail screen 900 includes an "Internet address card(s)" attachment link 901, which invokes an option screen 910 as shown in FIG. 9B for the e-mail recipient to select the contacts he wants to add to his address book. If only one address card is attached, when the link 901 is clicked, the attached card is automatically added to the recipient's address book and a non-editable receive view is invoked], and [0114] A member/publisher can share his address card with certain designated recipients who may then choose to subscribe. Sharing may take place via e-mail or a new "direct" one-click communication mechanism. He can share an address card with all or part of the address book/"buddy list", leveraging "people lists". He can also share his address card with recipients of mail messages. He can even make his address card public, open to subscription by any member. The publisher may configure an expiration period of time for a publish offer or an invitation to share], and [ 0112-0113] , and [ see Fig. 6H and corresponding text for more details].
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 teaching of Liebmann, and Mishra by incorporating “sender’s address card and a hyperlink in an email”, as taught by Feng. One could have been motivated to do so in order for a member/publisher can share his address card with certain designated recipients who may then choose to subscribe. Sharing may take place via e-mail or a new "direct" one-click communication mechanism [ Feng, 0114, 0147].
Regarding claim 19, Liebmann, and Mishra do not explicitly disclose, however, Feng discloses wherein receiving the first electronic communication comprises receiving the first electronic communication designating a recipient phone number; and " wherein querying the recipient profile for the second recipient address of the second communication type comprises querying the recipient profile for a recipient email address
[0111] In an equally preferred embodiment, an Internet based address card service is incorporated with an existing address book service, which enables automatic sharing and updates of address book information. The members of the service can publish personal contact information, work information or/and personal notes with the people they want to stay in touch with. Those members can subscribe to automatically receive changes when the information is updated. The address card provides a link among the members to help them stay in touch, and to keep their address books up to date with all the correct information. The service ensures that the members always have the right contact information for their friends and family whenever they need it. By subscribing to the service, the user's friends and family can always have his current contact information whenever he updates it, and he never has to worry about mistyping a friend's new phone number or e-mail address to copy it into his address book because they can share it with him automatically. Contact information in address cards is available via any interface to the host-based address book. The address card contact information is also available offline.], and [0113] In a typical embodiment, the service provider provides templates from which a user/member selects sets of fields for sub-address cards. For example, the "Business" template may contain First Name, Last Name, Title, Company, Work Address, Work Phone, E-mail, and Web Page. These fields will be pulled from the address card and published as the user's "Business Card". Similarly, a different set of data may be pulled from the address card as the user's "Personal Contact Information".
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 teaching of Liebmann, and Mishra by incorporating “Internet based address card”, as taught by Feng. One could have been motivated to do so in order to incorporate the address card with address book service, which enables automatic sharing and updates of address book information. The members of the service can publish personal contact information, work information or/and personal notes such as First Name, Last Name, Title, Company, Work Address, Work Phone, E-mail, and Web Page [ Feng, 0111, 0113].
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0080775) issued to Liebmann and in view of US Patent No. ( US2017/0214641) issued to Mishra, and further in view of (US2007/0008574) issued to Henry.
Regarding claim 8, Liebmann discloses wherein receiving the first electronic communication comprises receiving the first electronic communication comprising a text message [¶¶23-24, a first email server A (205) can be used to send, forward, or otherwise process the delivery of an email 210a-b from an email account (and mailbox) accessed through a first client device 215 to other email mailboxes handled by email servers B and C (225 and 230 respectively). For instance, the sender of email 210a-b may have designated multiple recipients for the email, including recipient email mailboxes served or otherwise managed using two different email servers 225, 230.], and [ see FIG 4A, In the example of FIG. 4A, ¶31, an email client device 420 causes as email 430 to be sent using email server A 405. Email server A 405 can identify email servers B (410) and C (415) as corresponding to recipient email accounts (e.g., "abe@xyz.com" and "bob@abc.com") designated in email 430.Turning to FIG. 2B, as is typical in modern email (and other text-based electronic) communications, a recipient of email 210a-b can elect to reply to the email 210a-b, causing a reply email to be generated and communicated. In some instances, a recipient of an email (e.g., 210a-b) can elect to reply to the sender of the email as well as one or more additional recipients other than the original sender, including other recipients of the original email.
Liebmann , and Mishra do not explicitly disclose , however, Henry discloses and " further comprising in response to failure of delivery of the text message to the recipient address, retrieving a second recipient address comprising a recipient email address; populating an email with the hyperlink; and transmitting the email to the recipient email address”.
[0170] Other types of syntax checking may also be performed in other embodiments, such as checking the e-mail addresses of the filled-in fields to the sender's address book, or the like. In various embodiments, the syntax checking functionality catches potential errors before the document is transmitted to the transmission server.
[0171] In other embodiments of the present, the transmission server may perform syntax checking, described above, based upon the optical character recognition results, instead of the sending system. For example, if the OCR results read "aol.con," or "mit.com" several options are available. In some embodiments, the transmission server may automatically determine a best guess based upon syntax. As an example, a fax server may change "aol.con" into "aol.com" and/or "mit.com" to "mit.edu." In other examples, correction of data, such as e-mail addresses may be based on part of prior history of the sender. For example, if a sender has previously sent many transmissions to "davidcl@mid.edu," but for a present transmission, the OCR system recognizes "qavidcl@mid.edu," the transmission server may automatically correct it to read "davidcl@mid.edu." In various embodiments, the sender may be recognized by a telephone number which the sender calls-into, based upon the FROM e-mail address, a telephone number of the sender's fax machine, and the like. In other embodiments, automatic correction may be made based upon e-mail addresses or like for an organization a sender is associated with, or the like.
[0173] In other embodiments of the present invention, an "address" book based upon prior transmissions by the sender may be maintained by the transmission server, or the like. In cases where there is a syntax error… the transmission server may alternatively output the syntax error to an operator.
[0174] In still other embodiments, if there is a syntax error, the transmission server may automatically contact the sender via e-mail, instant messenger, or the like, and indicate the syntax error, or the like. In such embodiments, the sender may be invited to provide the corrected data by return communication. In some embodiments, the transmission server may automatically determine the corrected data from the sender and proceed based upon the corrected data. In other embodiments, an operator may review the corrected data from the sender, and make the correction, if appropriate.
[0175] The above syntax checking, and syntax error reporting and handling may also be uses to notify a sender of delivery failure errors for bounced e-mail messages, or the like.
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 teaching of Liebmann, and Mishra by incorporating “Optical character recognition (OCR) data syntax checking”, as taught by Henry. One could have been motivated to do so in order to perform syntax checking and syntax error reporting on the e-mail addresses of the filled-in fields to the sender's address book and notify a sender of delivery failure errors for bounced e-mail messages, [ Henry, 0164-0175].
Regarding claim 9, Liebmann, and Mishra do not explicitly disclose , however Feng discloses further comprising: " in response to failure of delivery of the email to the recipient email address, accessing a phone number associated with the recipient; " generating a prompt to call the recipient at the phone number to communicate contents of the text message to the recipient; and " serving the prompt to an operator associated with the sender.
[0111] In an equally preferred embodiment, an Internet based address card service is incorporated with an existing address book service, which enables automatic sharing and updates of address book information. The members of the service can publish personal contact information, work information or/and personal notes with the people they want to stay in touch with. Those members can subscribe to automatically receive changes when the information is updated. The address card provides a link among the members to help them stay in touch, and to keep their address books up to date with all the correct information. The service ensures that the members always have the right contact information for their friends and family whenever they need it. By subscribing to the service, the user's friends and family can always have his current contact information whenever he updates it, and he never has to worry about mistyping a friend's new phone number or e-mail address to copy it into his address book because they can share it with him automatically. Contact information in address cards is available via any interface to the host-based address book. The address card contact information is also available offline.], and [0113] In a typical embodiment, the service provider provides templates from which a user/member selects sets of fields for sub-address cards. For example, the "Business" template may contain First Name, Last Name, Title, Company, Work Address, Work Phone, E-mail, and Web Page. These fields will be pulled from the address card and published as the user's "Business Card". Similarly, a different set of data may be pulled from the address card as the user's "Personal Contact Information".
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 teaching of Liebmann, and Mishra by incorporating “Internet based address card”, as taught by Feng. One could have been motivated to do so in order to incorporate the address card with address book service, which enables automatic sharing and updates of address book information. The members of the service can publish personal contact information, work information or/and personal notes such as First Name, Last Name, Title, Company, Work Address, Work Phone, E-mail, and Web Page [ Feng, 0111, 0113].
And further Henry discloses:
[0170] Other types of syntax checking may also be performed in other embodiments, such as checking the e-mail addresses of the filled-in fields to the sender's address book, or the like. In various embodiments, the syntax checking functionality catches potential errors before the document is transmitted to the transmission server.
[0171] In other embodiments of the present, the transmission server may perform syntax checking, described above, based upon the optical character recognition results, instead of the sending system. For example, if the OCR results read "aol.con," or "mit.com" several options are available. In some embodiments, the transmission server may automatically determine a best guess based upon syntax. As an example, a fax server may change "aol.con" into "aol.com" and/or "mit.com" to "mit.edu." In other examples, correction of data, such as e-mail addresses may be based on part of prior history of the sender. For example, if a sender has previously sent many transmissions to "davidcl@mid.edu," but for a present transmission, the OCR system recognizes "qavidcl@mid.edu," the transmission server may automatically correct it to read "davidcl@mid.edu." In various embodiments, the sender may be recognized by a telephone number which the sender calls-into, based upon the FROM e-mail address, a telephone number of the sender's fax machine, and the like. In other embodiments, automatic correction may be made based upon e-mail addresses or like for an organization a sender is associated with, or the like.
[0173] In other embodiments of the present invention, an "address" book based upon prior transmissions by the sender may be maintained by the transmission server, or the like. In cases where there is a syntax error, the transmission server may automatically determine if there is a best guess and send the fax to that guess. In other embodiments, the transmission server may alternatively output the syntax error to an operator.
[0174] In still other embodiments, if there is a syntax error, the transmission server may automatically contact the sender via e-mail, instant messenger, or the like, and indicate the syntax error, or the like. In such embodiments, the sender may be invited to provide the corrected data by return communication. In some embodiments, the transmission server may automatically determine the corrected data from the sender and proceed based upon the corrected data. In other embodiments, an operator may review the corrected data from the sender, and make the correction, if appropriate.
[0175] The above syntax checking, and syntax error reporting and handling may also be uses to notify a sender of delivery failure errors for bounced e-mail messages, or the like
[0171] In other embodiments of the present, the transmission server may perform syntax checking, described above, based upon the optical character recognition results, instead of the sending system. For example, if the OCR results read "aol.con," or "mit.com" several options are available. In some embodiments, the transmission server may automatically determine a best guess based upon syntax. As an example, a fax server may change "aol.con" into "aol.com" and/or "mit.com" to "mit.edu." In other examples, correction of data, such as e-mail addresses may be based on part of prior history of the sender. For example, if a sender has previously sent many transmissions to "davidcl@mid.edu," but for a present transmission, the OCR system recognizes "qavidcl@mid.edu," the transmission server may automatically correct it to read "davidcl@mid.edu." In various embodiments, the sender may be recognized by a telephone number which the sender calls-into, based upon the FROM e-mail address, a telephone number of the sender's fax machine, and the like. In other embodiments, automatic correction may be made based upon e-mail addresses or like for an organization a sender is associated with, or the like.
[0186] In some embodiments of the present invention, when a sender selects field 520, the transmission server may initiate an e-mail certification process whereby certification of when an e-mail message, or the like is delivered to the recipient, when the e-mail message is opened by the recipient, and the like. In such embodiments the original transmission is typically stays resident upon the transmission server. Additionally, the recipient receives notification that a transmission has arrived for the recipient in the form of an e-mail, page, cell-phone call, or the like. In response, the recipient logs-into the transmission server with a password to retrieve the transmission.
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 teaching of Liebmann, and Mishra by incorporating “Optical character recognition (OCR) data syntax checking”, as taught by Henry. One could have been motivated to do so in order to perform syntax checking and syntax error reporting on the e-mail addresses of the filled-in fields to the sender's address book and notify a sender of delivery failure errors for bounced e-mail messages, [ Henry, 0164-0175].
Claim 10, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0080775) issued to Liebmann and in view of US Patent No. ( US2017/0214641) issued to Mishra, and further in view of ( US2018/0232441) issued to Lin.
Regarding claim 10, the combination of Liebmann, Mishra, disclose " wherein receiving the first electronic communication comprises receiving the first electronic communication comprising a text message; and " wherein populating the instance of the secure web portal with the secure communication thread comprises: accessing a text message history comprising:- a first set of text messages sent from the recipient address and designating the sender; and- a second set of text messages sent from the sender and designating the recipient address; accessing an email message history comprising:- a first set of emails sent from a second recipient address associated with the recipient and designating the sender; and - a second set of emails sent from the sender and designating the second recipient address; populating the secure communication thread with the text message history and the email message history based on timestamps of each text in the text message history and each email in the email message history.
the combination of Liebmann, Mishra, disclose:
Liebmann discloses [ 002, 0013, 0023-0024, 0027,0031, 0044, 0054].
Furthermore , Mishra discloses [0033].
And furthermore, Lin discloses [0024] Message content may be tagged with a name/tag ID as part of an entity type tagging infrastructure. In one example, an entity type tagging infrastructure may be used for the assignment and management of tags associated with message content (e.g. bundles of emails). That is, an entity type tagging structure may be generated for specific emails included in a bundle of emails. The entity type tagging structure may comprise a plurality of fields that are configured by developers, where data of the entity type tagging infrastructure can be utilized for management of content associated with a bundle including searching and filtering of bundles of content and sharing of bundled content. Attributes and fields associated with an exemplary entity type tagging infrastructure may vary based on the type of email content. In further examples, an entity type tagging infrastructure may be used for classification of any type of emails including emails not included in a bundle of emails as data from an entity type tagging infrastructure may be utilized to increase accuracy in classifying emails as a specific type or category. Examples of data fields that may be included in an exemplary entity type tagging infrastructure comprise but are not limited to: context fields pertaining to specific data of an email, tag/hashtag fields, email type fields, category fields, entity data fields, data source fields, date/timestamp information, hyperlink data fields, domain information fields, formatting/arrangement fields, confidence scores pertaining to classification and specific attributes of an email, data pertaining to specific email content and user triage action history with respect to specific messages (e.g. emails) and/or a category/type for the specific message, among other examples.
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 teaching of Liebmann, and Mishra, by incorporating “entity type tagging infrastructure.”, as taught by Lin. One could have been motivated to do so in order to implement an infrastructure which is used for the assignment and management of tags associated with message content (e.g. bundles of emails). That is, an entity type tagging structure may be generated for specific emails included in a bundle of emails. The entity type tagging structure may comprise a plurality of fields such as: context fields pertaining to specific data of an email, tag/hashtag fields, email type fields, category fields, entity data fields, data source fields, date/timestamp information, hyperlink data fields, domain information fields, formatting/arrangement fields, confidence scores pertaining to classification and specific attributes of an email, data pertaining to specific email content and user triage action history with respect to specific messages (e.g. emails) and/or a category/type for the specific message, among other examples. [ Lin, 0024].
Regarding claim 20, wherein receiving the first electronic communication comprises receiving the first electronic communication comprising a text message; and " wherein populating the instance of the secure web portal with the secure communication thread comprises: accessing a text message history comprising:- a first set of text messages sent from the recipient address and designating the sender; and- a second set of text messages sent from the sender and designating the recipient address; accessing an email message history comprising:- a first set of emails sent from a second recipient address associated with the recipient and designating the sender; and- a second set of emails sent from the sender and designating the second recipient address; and populating the secure communication thread with the text message history and the email message history based on timestamps of each text in the text message history and each email in the email message history.
the combination of Liebmann, Mishra, and Lin disclose:
Liebmann discloses [ 002, 0013, 0023-0024, 0027,0031, 0044, 0054].
Furthermore , Mishra discloses [0033].
And furthermore, Lin discloses [0024] Message content may be tagged with a name/tag ID as part of an entity type tagging infrastructure. In one example, an entity type tagging infrastructure may be used for the assignment and management of tags associated with message content (e.g. bundles of emails). That is, an entity type tagging structure may be generated for specific emails included in a bundle of emails. The entity type tagging structure may comprise a plurality of fields that are configured by developers, where data of the entity type tagging infrastructure can be utilized for management of content associated with a bundle including searching and filtering of bundles of content and sharing of bundled content. Attributes and fields associated with an exemplary entity type tagging infrastructure may vary based on the type of email content. In further examples, an entity type tagging infrastructure may be used for classification of any type of emails including emails not included in a bundle of emails as data from an entity type tagging infrastructure may be utilized to increase accuracy in classifying emails as a specific type or category. Examples of data fields that may be included in an exemplary entity type tagging infrastructure comprise but are not limited to: context fields pertaining to specific data of an email, tag/hashtag fields, email type fields, category fields, entity data fields, data source fields, date/timestamp information, hyperlink data fields, domain information fields, formatting/arrangement fields, confidence scores pertaining to classification and specific attributes of an email, data pertaining to specific email content and user triage action history with respect to specific messages (e.g. emails) and/or a category/type for the specific message, among other examples.
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 teaching of Liebmann, and Mishra, by incorporating “entity type tagging infrastructure.”, as taught by Lin. One could have been motivated to do so in order to implement an infrastructure which is used for the assignment and management of tags associated with message content (e.g. bundles of emails). That is, an entity type tagging structure may be generated for specific emails included in a bundle of emails. The entity type tagging structure may comprise a plurality of fields such as: context fields pertaining to specific data of an email, tag/hashtag fields, email type fields, category fields, entity data fields, data source fields, date/timestamp information, hyperlink data fields, domain information fields, formatting/arrangement fields, confidence scores pertaining to classification and specific attributes of an email, data pertaining to specific email content and user triage action history with respect to specific messages (e.g. emails) and/or a category/type for the specific message, among other examples. [ Lin, 0024].
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0080775) issued to Liebmann and in view of US Patent No. ( US2017/0214641) issued to Mishra, and further in view of ( US 20160232805) issued to Gibson.
Regarding claim 11, Liebmann, and Mishra do not explicitly disclose, however Gibson discloses further comprising, in response to the recipient selecting the hyperlink: " retrieving a recipient medical record associated with the recipient; " retrieving a clinical directory associated with the sender; " receiving a second electronic communication from the recipient in the secure communication thread; " extracting a set of language signals from the second electronic communication; " generating a response based on: the set of language signals; the medical record; and the clinical directory; and" populating the secure communication thread with the response.
[0054] FIG. 4 illustrates an illustrative screen 400 of a third user interface to solicit a patient preference as related to communication modality. FIG. 4 illustrates a plurality of images 410 of various communication modalities, e.g., 1) in-person communication modality, 2) electronic communication modality, and 3) printed communication modality. For example, in-person communication may comprise speaking with a patient in person such as a face-to-face meeting with the patient in a doctor's office or having a phone conversation with the patient over a telephone. In another example, electronic communication may comprise interacting with the patient through email messages, text messages, medical discussion forums hosted on a website, social networking websites, health wellness websites hosted by hospitals, pharmaceutical companies, or doctor groups, websites with medical related videos or short programs that can be viewed by the patients, and the like. Medical information can be communicated electronically, e.g., as enclosures in emails or downloadable files obtained from various websites. In another example, printed communication may comprise letters, pamphlets or brochures sent through the mail (e.g., via a postal service). Again, the above list of communication modalities is only illustrative and not exhaustive.
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 teaching of Liebmann, and Mishra, by incorporating “electronic communication modality”, as taught by Gibson. One could have been motivated to do so in order to implement electronic communication which comprise interacting the patient and doctor group through email messages, text messages for medical information [ Gibson, 0054].
Claims 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0080775) issued to Liebmann and in view of US Patent No. ( US2017/0214641) issued to Mishra, and further in view of ( US2009/0157823) issued to Price.
Regarding claim 13, Liebmann, and Mishra do not explicitly disclose, however, Price discloses wherein receiving the first electronic communication comprises: receiving the first electronic communication comprising a first email encrypted according to a first encryption protocol; and " further comprising: accessing encryption protocols supported by a mail client at the recipient address; and in response to encryption protocols supported by the mail client excluding the first encryption protocol, associating the recipient address with insufficient messaging security.
[¶1, this invention relates to a technique for supporting secure email services using multiple protocols, including proprietary and open protocols], and [¶2, FIG. 1 illustrates a prior art system 100 for facilitating secure email services (e.g., encryption and decryption) using an email server that utilizes a supported protocol. The system 100 includes a client machine 102 that communicates with an email server 106 through a secure email policy enforcement server 104. The secure email policy enforcement server 104 supports the protocol used by the email server 106 and therefore is referred to as a supported secure email machine. The secure email policy enforcement server 104 can be positioned between the email server 106 and the client 102 and can offer secure email policy enforcement services to the client transparently. The email server 106 receives and transmits encrypted messages via the Internet 108]. Examiner Note: Liebmann also discloses this limitation as:[see FIGS.1,2,3,4 and correspond text for more detail, ¶17, a first email server (e.g., 105) can be used to send an email from a first client (e.g., 120) to another email server (e.g., 115) over an encrypted or otherwise secure communication channel. The recipient email server (e.g., 115) can then be used to deliver the email to the email mailbox associated with one or more recipient clients (e.g., 140)], and [¶6] The invention also includes a computer readable storage medium with executable instructions to determine that a security policy cannot be applied by a supported secure email machine to a generated email message and thus the email message is routed to an auxiliary secure email machine. Secure email policies are applied to the email message at the auxiliary secure email machine. The email message is directed from the auxiliary secure email machine to the supported secure email machine for routing to a recipient], and [[see FIG.3 and corresponding text for more detail, block # 316, route email using second protocol]; and [see FIG.4 and corresponding text for more detail, [0027] The message communication module 254 of the auxiliary secure email machine 208 receives the message and passes it to the policy application module 256. The policy application module 256 then applies secure email policies to the email (412). For example, the policy application module 256 includes executable instructions to request the public key for the message recipient. The policy application module 256 then encrypts the message to the recipient's public key. The policy application module 256 then sends the email using the second protocol (414). For example, the email is sent to the supported secure email machine, which then routes the email (416)].
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 teaching of Liebmann, and Mishra, by incorporating “secure email services”, as taught by Price. One could have been motivated to do so in order for facilitating a technique for supporting secure email services (e.g., encryption and decryption) using multiple protocols, including proprietary and open protocols. s [ Price, 0001 0002].
Regarding claim 14, receiving a second electronic communication: sent by the sender; and designating a second recipient address associated with a second recipient; initializing a second instance of a second secure web portal associated with the second recipient; initializing a second secure communication thread accessible within the second instance of the second secure web portal; populating the second secure communication thread with contents of the second electronic communication; associating the second instance of the second secure web portal and the second secure communication thread with a second hyperlink; generating a second notification comprising the second hyperlink; and transmitting the second notification to the second recipient address in place of the second electronic communication.
The combination of Liebmann, and Mishra disclose :
Liebmann discloses [ 002, 0013, 0023-0024, 0027,0031, 0044, 0054].
Furthermore , Mishra discloses [0033].
Liebmann, and Mishra do not explicitly disclose, however, Price discloses:
accessing encryption protocols supported by the second recipient address
[see FIG.3 and corresponding text for more detail, block # 316, route email using second protocol], and [see FIG.4 and corresponding text for more detail, [0027] The message communication module 254 of the auxiliary secure email machine 208 receives the message and passes it to the policy application module 256. The policy application module 256 then applies secure email policies to the email (412). For example, the policy application module 256 includes executable instructions to request the public key for the message recipient. The policy application module 256 then encrypts the message to the recipient's public key. The policy application module 256 then sends the email using the second protocol (414). For example, the email is sent to the supported secure email machine, which then routes the email (416)]
and " in response to a recipient exclusion list excluding the second recipient address and in response to association of the second recipient address with insufficient communication security
[¶6] The invention also includes a computer readable storage medium with executable instructions to determine that a security policy cannot be applied by a supported secure email machine to a generated email message and thus the email message is routed to an auxiliary secure email machine. Secure email policies are applied to the email message at the auxiliary secure email machine. The email message is directed from the auxiliary secure email machine to the supported secure email machine for routing to a recipient], and [see FIG.3 and corresponding text for more detail].
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 teaching of Liebmann, and Mishra, by incorporating “secure email services”, as taught by Price. One could have been motivated to do so in order for facilitating a technique for supporting secure email services (e.g., encryption and decryption) using multiple protocols, including proprietary and open protocols. s [ Price, 0001 0002].
Regarding claim 15, Liebmann discloses further comprising: receiving a third electronic communication: sent by the sender; and designating a third recipient address associated with a third recipient; and" in response to a recipient exclusion list excluding the second recipient address, transmitting the third electronic communication to the third recipient address.
[¶31, Email server A 405 can further determine that email 430 should be encrypted and identify encryption protocols in place between email server A 405 and each of email servers B 410 and C 415, permitting encrypted transmission of email 430 to each of email servers B (410) and C (415)], and [¶27, under some conditions, an email can be encrypted over a channel using a first encryption technique, while under other conditions, an email can be encrypted using a different encryption technique. Indeed, in some instances, email server 305 can adopt and apply a first encryption technique or protocol for emails sent over a channel to a second email server (e.g., server 335), while applying a second, different encryption technique for emails exchanged with a third email server (e.g., server 340)].
Allowable Subject Matter
Claims 12, and 18 are objected to as being dependent upon a rejected base claim but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The reason for allowance will be furnished upon allowance of the application.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See 892 for more relevant references.
Evdokimo ( US206/0148236) [0017] provide an online product research and purchasing web portal having access to its own merchandise database comprised of a multitude of merchants, the web portal also providing a scrolling tickertape display showing emails and texts addressed to the respective web portal user]
Johnson ( US2012/0213126) [0092] FIG. 7 depicts a flowchart illustrating an invitation process of the encryption system for exchanging secured emails, generally shown at 700. User 1 logs in using user credentials (at act 702) and sends an invitation (at act 704) invoking the Window.sup.s.RTM. Communication Foundation (WCF) (at act 706). The invitation electronic mail (email) is stored (shown generally at 708) on the web server database(s) (DB) (shown generally at 710) and the email is processed (shown generally at 712), e.g., by ASYNC Email Service (at 714) (further depicted in FIG. 8), and sent (shown generally at 716) to the email server, generally shown at 718. At the next step, the email is sent to user 2, generally shown at 720. An email sent confirmation is sent (shown generally at 722), e.g., by ASYNC Email Service (at 714) (further depicted in FIG. 8), and the email is deleted, shown generally at 724. The invitation email that was sent to user 2 can be read (at act 726) by user 2, e.g., via a web portal (at 728), wherein the user 2 can login using user 2 credentials and/or request user credentials (at act 730), e.g., by signing up for an account having user credentials unique to user 2, in order to view the content of the email in, e.g., to read the encrypted/decrypted contents of the email of a "linked" user. User 2 can either accept or decline the invitation email, generally shown at 732. It is understood that user 2 does not need to login, have user credentials, and/or sign up for an account having user credentials in order to decline the invitation email.
CHAN, JAWE(TW I734044 B)[ Description, in a possible embodiment, the application software 3140 may be email client software capable of sending and receiving emails. In a possible embodiment, the application software 3140 can store the seller's contact information in another email client's contact information or in itself. In a possible embodiment, the application software 3140 can use another email client or itself to send and receive emails using contact information from the search results. In a possible embodiment, the application software 3140 can access the address book of another email client. In a possible embodiment, the data field can be added to the address book by the application software 3140 or display information to accommodate the identification of the goods for sale. The data field may include a link to the seller's identification in the address book of the email client. The data field can also store the identification information of the product].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496