CN102970209A - 一种电子邮件状态更新方法、装置及*** - Google Patents
一种电子邮件状态更新方法、装置及*** Download PDFInfo
- Publication number
- CN102970209A CN102970209A CN2012104214693A CN201210421469A CN102970209A CN 102970209 A CN102970209 A CN 102970209A CN 2012104214693 A CN2012104214693 A CN 2012104214693A CN 201210421469 A CN201210421469 A CN 201210421469A CN 102970209 A CN102970209 A CN 102970209A
- Authority
- CN
- China
- Prior art keywords
- state
- sign
- server
- task status
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明公开了一种电子邮件状态更新方法、装置及***。一种电子邮件状态更新方法包括:服务器获得第一客户端发送的事件状态更新请求,所述更新请求中携带邮件标识和任务状态标识;根据邮件标识和任务状态标识,更新对应邮件的当前状态;以及向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,所述更新请求中携带所述邮件标识和所述任务状态标识。应用本发明所提供的技术方案,仅需要很小的数据传输量,就可以把事件状态变更的情况向所有相关用户说明,提高了传输效率和存储效率。并且更新状态的操作可以在同一封邮件的基础上进行,不需要生成新的邮件,从而有效地减少了邮件的数量,使得用户可以更方便地对邮件进行浏览和管理。
Description
技术领域
本发明涉及互联网应用技术领域,特别是涉及一种电子邮件状态更新方法、装置及***。
背景技术
电子邮件(electronic mail,简称E-mail),是—种用电子手段提供信息交换的通信方式。电子邮件综合了电话通信和邮政信件的特点,它传送信息的速度和电话一样快,又能像信件一样使收信者在接收端收到文字记录。以上特点,使得电子邮件成为了互联网中应用最广的服务之一,通过网络的电子邮件***,用户可以以非常快捷的方式,与世界上任何一个位置的网络用户进行联系。
电子邮件的方便性和快捷性,使其成为一种用于发布通知的常用手段,在一些情况下,如果所发布的通知是布置任务性质的,那么对于任务执行者而言,后续有报告任务进展的需求,而任务布置者则需要了解任务进展。更为复杂的情况是:任务布置者或任务执行者都可能有多个人,当其中一人对任务状态做出变更时,要求所有相关人员都能够了解该状态。
上述需求可以进一步引申为:对某一事件的状态不断进行变更的需求,根据现有电子邮件***的实现方案,针对上述需求,一旦某名用户对事件状态做出了变更,需要向所有相关人员都发送一封新邮件,以便其他相关人员都能够了解该事件状态的变化。可以想象:如果一个事件从最初发起到最终完成,共经历了n次状态变化,那么在这个过程中,对于该事件的每个相关人员,都需要对该事件进行共n次的收/发工作。也就是说,在邮件服务器中国,至少包含n封关于同一事件的邮件;相应地,在每个相关人员的收件箱和发件箱中,也都会总共包含至少n封关于同一事件的邮件,当邮件数量增大时,既不利于浏览,也不利于管理。
另外,为了让所有相关人员都能够了解到整个事件的进展,用户在更新事件状态时,一般会采用“在之前最后一封邮件的基础上全部回复”的操作方式,这使得每封新邮件实质上都包含了大量之前邮件中的内容,这些重复的邮件内容既不利于用户快速找到真正有用的信息,也对邮件传输效率造成影响、为电子邮件***带来了不必要的存储负担。
发明内容
为解决上述技术问题,本发明实施例提供一种电子邮件状态更新方法、装置及***,以提高电子邮件***对同一事件主题的多封邮件的处理效率,并且方便用户的浏览和管理,技术方案如下:
本发明提供一种电子邮件状态更新方法,该方法包括:
服务器获得第一客户端发送的事件状态更新请求,所述更新请求中携带邮件标识和任务状态标识;
根据邮件标识和任务状态标识,更新对应邮件的当前状态;以及
向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,所述更新请求中携带所述邮件标识和所述任务状态标识。
根据本发明的一种实施方式,所述根据邮件标识和任务状态标识,更新对应邮件的当前状态;以及向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,包括:
根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态;以及向所述对应邮件所涉及的用户邮箱发送事件状态更新指示。
根据本发明的一种实施方式,该方法还包括:
服务器记录所述对应邮件更新前的状态。
根据本发明的一种实施方式,该方法还包括:
服务器根据所述第一客户端的邮箱地址,记录所述对应邮件的更新发起用户。
根据本发明的一种实施方式,该方法还包括:
服务器将所述更新发起用户的信息携带于事件状态更新指示中。
根据本发明的一种实施方式,该方法还包括:
服务器为邮件分配唯一的标识,并将标识携带于该邮件中,用于后续的传输过程。
本发明提供一种电子邮件状态更新方法,该方法包括:
第二客户端获得服务器发送的事件状态更新指示,所述更新请求中携带邮件标识和任务状态标识;
根据邮件标识和任务状态标识,更新对应邮件的当前状态。
根据本发明的一种实施方式,所述根据邮件标识和任务状态标识,更新对应邮件的当前状态,包括:
根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态。
根据本发明的一种实施方式,该方法还包括:
第二客户端记录所述对应邮件更新前的状态。
根据本发明的一种实施方式,
所述更新请求中还携带有更新发起用户的信息;
所述方法还包括:第二客户端记录所述更新发起用户的信息。
本发明提供一种电子邮件服务器,该服务器包括:
更新请求接收单元,用于获得第一客户端发送的事件状态更新请求,所述更新请求中携带邮件标识和任务状态标识;
邮件状态更新单元,用于根据邮件标识和任务状态标识,更新对应邮件的当前状态;
更新指示发送单元,用于根据邮件标识和任务状态标识,向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,所述更新请求中携带所述邮件标识和所述任务状态标识。
根据本发明的一种实施方式,所述邮件状态更新单元,具体用于根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态;
所述更新指示发送单元,具体用于根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则向所述对应邮件所涉及的用户邮箱发送事件状态更新指示。
根据本发明的一种实施方式,所述邮件状态更新单元还用于:
记录所述对应邮件更新前的状态。
根据本发明的一种实施方式,所述邮件状态更新单元还用于:
根据所述第一客户端的邮箱地址,记录所述对应邮件的更新发起用户。
根据本发明的一种实施方式,所述更新指示发送单元还用于:
将所述更新发起用户的信息携带于事件状态更新指示中。
根据本发明的一种实施方式,该服务器还包括:
标识分配单元,用于服务器为邮件分配唯一的标识,该并将标识用于在后续的传输过程中携带于该邮件中。
本发明提供一种电子邮件客户端,该客户端包括:
更新指示接收单元,用于获得服务器发送的事件状态更新指示,所述更新请求中携带邮件标识和任务状态标识;
邮件状态更新单元,用于根据邮件标识和任务状态标识,更新对应邮件的当前状态。
根据本发明的一种实施方式,所述邮件状态更新单元,具体用于:
根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态。
根据本发明的一种实施方式,所述邮件状态更新单元,还用于:
记录所述对应邮件更新前的状态。
根据本发明的一种实施方式,
所述更新请求中还携带有更新发起用户的信息;
所述邮件状态更新单元,还用于:
记录所述更新发起用户的信息。
本发明提供一种电子邮件***,该***包括如前所述的电子邮件服务器以及电子邮件客户端。
根据本发明实施例提供的技术方案,每封电子邮件在邮件***中都具有一个全局唯一的标识,以及一个任务状态标识,当一名用户对事件的状态进行变更后,该变更情况可以和邮件标识一起发送至服务器,服务器根据邮件标识找到该邮件的原始状态,并且进一步该把变更情况发送给所有相关人员。应用上述方案,仅需要很小的数据传输量,就可以把事件状态变更的情况向所有相关用户说明,避免多名用户反复发送重复的邮件内容,提高了传输效率和存储效率。另一方面,由于同一事件对应的邮件都具有相同的全局标识,因此更新状态的操作可以在同一封邮件的基础上进行,不需要生成新的邮件,从而有效地减少了邮件的数量,使得用户可以更方便地对邮件进行浏览和管理。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1为本发明实施例电子邮件***的结构示意图;
图2为本发明实施例的一种邮件头示意图;
图3为本发明实施例电子地图数据存储电子邮件状态更新方法的一种流程图;
图4a为本发明实施例的事件状态更新请求或事件状态更新指示的格式示意图;
图4b为本发明实施例的一种更新后的邮件头格式示意图;
图5为本发明实施例电子邮件状态更新方法的另一种流程图;
图6为本发明实施例电子邮件状态更新方法的第三种流程图;
图7为本发明实施例电子邮件服务器的结构示意图;
图8为本发明实施例电子邮件客户端的结构示意图。
具体实施方式
首先对本发明所涉及的电子邮件***进行简单介绍,电子邮件***包括客户端和服务器两种基本设备,如图1所示,根据在邮件收发过程中的角色不同,又可以进一步分为:发件客户端11、发件服务器21、收件客户端12、收件服务器22。
电子邮件的发送接收过程可以形象地用日常生活中邮寄包裹的过程来形容:当我们要寄一个包裹时,我们首先要找到任何一个有这项业务的邮局,在填写完收件人姓名、地址等等之后包裹就寄出而到了收件人所在地的邮局,那么对方取包裹的时候就必须去这个邮局才能取出。类似地,当我们发送电子邮件时,首先由发件客户11端生成邮件并将该邮件发送给发件服务器21,发件服务器21根据收件人的邮箱地址,将邮件发送至收件服务器22,收件客户端12通过访问收件服务器22收取邮件。
在电子邮件的实际应用中,如果发件人和收件人的地址位于相同的邮件域中,那么在邮件传输过程中,发件服务器和收件服务器是相同的。另外,在一次邮件传输过程中,可以指定多个收件人地址(包括抄送地址),即收件人可以有多个,收件人地址既可以与发件人地址处于相同的邮件域,也可以处于不同的邮件域。
需要说明的是,在本发明中,“客户端”的区分是基于当前在该客户端上登录的电子邮箱账号,而不是基于物理上的不同实体。例如:对于同一台计算机,可以在使用发件人邮箱登录时成为发件客户端、在使用收件人邮箱登录时成为收件客户端。
根据现有一些电子邮件***的功能,收件人为了避免遗忘邮件中的通知待办事项,可以给含有待办事项的邮件打上各种标签,以标识对应事件的进展状态,从而达到提醒自己的目的。这种方案,相当于收件人对自己已经收到的包裹进行各种处理,却无法让发件人或其他收件人也了解到这些变化的情况。
采用“回复邮件”的方式尽管可以实现让其他相关人员了解事件进展,但是在实际应用中,用户往往并不能从回复邮件中很直接地找到最关键的信息(即事件进展信息),当一封初始邮件经过多次回复后,该问题变得尤其严重,所产生的多封邮件同样不利于浏览和管理。从***的角度来看,在用户不断“回复邮件”的过程中,产生了大量的冗余信息(用户本身不会去关注这些信息),从而严重影响***的传输效率和存储效率。
为解决上述技术问题,本发明所提供的方案是,在邮件***中,为每封邮件分配一个标识,称为EId;同时为每封邮件设置一个状态标识,称为Status,该标识可供用户修改,用于反映事件的进展状态。
其中,EId是由邮件服务器分配、在***全局中具有唯一性的标识,例如,对于同一邮件域(内网)的邮件***应用而言,可以采用预置的命名规则得到EId,保证在该邮件域中的邮件标识的唯一性,如果***涉及多个邮件域的交互,则可以采用通用的唯一性算法生成EId,例如根据邮件标题、收/发件人地址、生成时间戳等信息采用哈希算法生成邮件的EId,保证该邮件在不同域邮件服务器中的唯一性。
Status是用于标识事件状态的字段,该字段由用户进行添加或修改,在实际应用中,可以由***预置一些固定的字段值供用户选择,例如“进行中”、“暂停”、“结束”等;当然也可以允许用户自行编辑该字段的内容,以便实现更为灵活的表意,本发明对此并不需要进行限定。
可见,Status类似现有技术中的“为邮件打标签”功能,与现有技术不同的是,本发明的“标签”不只针对打标签用户本人,而是可以通过网络传输,让邮件涉及的其他用户都能看到该“标签”。
根据本发明所提供的方案,对于一个确定事件A,如果用户发送了一封关于事件A的邮件X,那么在后续的过程中,如果其他用户需要不断更新该事件A的状态并且让所有相关人员了解该事件状态的变化,可以直接对邮件X的Status字段进行修改,邮件***会根据邮件X的EId定位服务器中相应邮件,更新相应的Status字段,并且进一步通知其他用户邮件X的Status字段变化情况。在整个过程中,由于邮件X具有相同的全局标识,因此无论是在服务器还是在客户端上,更新状态的操作都可以在同一封邮件X的基础上进行,不需要生成新的邮件,从而有效地避免了“回复邮件”方式所带来的各种问题。
为了使本领域技术人员更好地理解本发明中的技术方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于本发明保护的范围。
本发明所提供的电子邮件状态更新方案,包含邮件服务器和客户端两部分的实现方案,为方便说明,定义在一次更新过程中:第一客户端为更新发起客户端,第二客户端为需要查看更新状态的客户端,其中第二客户端可以对应一个或多个邮箱地址。
另外,为方便说明,本发明的方案将发件服务器和收件服务器统一为一个装置“邮件服务器”,对于相同邮件域的情况,二者原本就是是统一的,而对于不同邮件域的情况,也并不需要特别区分“邮件服务器”所执行的操作是由发件服务器完成还是由收件服务器完成,因此可以将二者看做是统一的,发件服务器和收件服务器之间的交互则看做是“邮件服务器”内部的操作。
根据本发明方案,邮件需要包括两种标识:EId和Status。对于首次在发件客户端生成的邮件,发件客户端需要请求邮件服务器为邮件分配一个唯一的标识EId,Status字段可以由用户手工设置,例如“启动”、“立案”等等,如果用户不进行设置,则由客户端设置为缺省值,例如“无状态”等。获得EId和Status之后,客户端将EId和Status保存在邮件头中,然后发送给邮件服务器。
可以理解的是,对于首次在客户端生成的邮件,客户端也可以先将不携带Eid信息的邮件发送给邮件服务器,服务器分配Eid之后再将Eid通知给客户端。
在完成以上操作后,邮件就具有了EId和Status两种标识,并且发件客户端和邮件服务器中都保存了这两种标识,进一步地,收件客户端收取邮件X之后也获得了这两种标识。
图2所示为本发明实施例的一种邮件头示意图,其中:
发件人1名:aaa.com;
收件人3名:aca.com;aba.com;bab.com;
“关于X项目”是邮件标题,由发件人任意填写,该字段并不是必要的;
“a.com_823421121982725”为邮件服务器分配的Eid;
“启动”为该邮件的Status。
可以理解的是,Eid属于***内部参数,因此在实际应用中,邮件的EId信息也可以对用户隐藏,而Status则需要用户查看和修改,因此需要设置为用户可见状态。
在一封邮件具备Eid和Status字段之后,用户就可以在不回复邮件的情况下,直接对邮件的状态进行更新,并且让其他相关用户都了解到更新情况。例如,根据上面的例子,aaa.com、aca.com、aba.com、bab.com四名用户成为项目X的相关人员,后续这4名用户都可以各种根据自己在项目X上进展,修改Status字段,并且其他相关人员都可以得知该进展。
下面首先从邮件服务器的角度,对本发明所提供的电子邮件状态更新方法进行说明,参见图3所示,该方法可以包括以下步骤:
S101,服务器获得第一客户端发送的事件状态更新请求;
这里接续前面的例子进行说明,假设在首次邮件发送之后、所有3名收件人都已收到该邮件。其中,收件人aca.com根据邮件内容开始了项目进程,并且需要将该情况通知给其他人,则该用户可以直接在已接收的邮件“关于项目X”上,对邮件的Status字段进行修改,例如修改为“进行中”。
当aca.com在第一客户端上完成Status字段修改并确认保存后,第一客户端向服务器发送一条事件状态更新请求消息,该请求中需要携带EId和修改后的Status,为便于说明,后续将修改后的Status称为OriginalStatus、将修改后的Status称为NewStatus。
图4a所示,为本发明实施例的一种事件状态更新请求的格式示意图,其中,仅有NewStatus和EId字段是必须的。如果需要了解项目状态更新的发起者,则可以在更新请求中进一步携带From字段,以便根据邮件aca.com确定更新的发起者。至于图4a中所示出的其他字段,默认情况下都可以根据EId从之前保存的邮件信息中查到,因此在实际应用中可以携带在请求消息中,也可以不携带在请求消息中,图4a仅用于示意性说明,而不应该理解为对本发明方案的限制。
上述的事件状态更新请求消息,在实际传输过程中,可以采用传统邮件协议进行发送。
S102,根据邮件标识和任务状态标识,更新对应邮件的当前状态;
邮件服务器在接收到事件状态更新请求消息后,首先根据EId找之前所存储的对应邮件,然后进一步根据NewStatus的内容,对之前保存的邮件的Status字段进行更新。
在本实施例中,邮件服务器将Eid为a.com_823421121982725的邮件(即带有图2所示邮件头的邮件)的Status字段从“启动”更新为“进行中”。
在本发明的一种实施方式中,邮件服务器也可以先对之前所保存邮件的Status字段值与待更新的字段值(即NewStatus)进行比较,如果没有变化,则不会发起更新的操作。这种情况适用于多名收件人都发出了回应、并且回应内容相同的情况,可以避免无意义的重复更新。
S103,根据邮件标识和任务状态标识,向所述对应邮件所涉及的用户邮箱发送事件状态更新指示。
邮件服务器在接收到事件状态更新请求消息后,还需要将该更新情况进一步告知其他相关用户。具体地,邮件服务器可以根据EId找之前所存储的对应邮件,然后对该邮件中所有涉及的相关人员都发送一条事件状态更新指示消息,当然,这里也可以根据在S101中所接收的事件状态更新请求消息中的To字段,确定事件状态更新指示消息的接收方。在本实施例中,事件状态更新指示消息的接收方为aaa.com、aba.com和bab.com三人,对于更新的发起人aca.com,可以向其发送消息,也不可以不向其发送消息,这些并不影响本发明方案的实施。
在实际应用中,也可以理解为:邮件服务器将事件状态更新请求消息直接转发给相应的接收方,因此事件状态更新指示消息的格式可以与事件状态更新请求消息类似,参见图4a所示,其中必要的部分仍然是EId和Status字段,其作用是告知接收方当前对哪一封邮件做了状态修改,并且指示客户端对相应的邮件的Status也进行修改。
在本发明的一种实施方式中,邮件服务器也可以先对之前所保存邮件的Status字段值与待更新的字段值(即NewStatus)进行比较,如果没有变化,则不发送事件状态更新指示消息,从而避免无意义的重复更新指示。
上述的事件状态更新指示消息,在实际传输过程中,可以采用传统邮件协议进行发送。
应用本实施所提供的方法,服务器根据第一客户端(更新发起者)发送的状态更新请求,将自身保存的邮件状态进行更新,同时向事件的其他相关用户发送更新指示。可以理解的是,上述的S102和S103并不需要限定执行顺序的先后。
其中,对于图2所示的邮件格式,在更新之后的邮件头格式可以参见图4b所示,值得注意的是,Status字段的值从“启动”变成了“进行中”。
在本发明的一种实施方式中,邮件服务器除了对Status字段进行修改之外,还可以可以进一步记录以下一种或多种附加信息:
a)邮件更新前的状态,即OriginalStatus,值得注意的是,在实际应用中下,该状态并不一定是客户端所发送的OriginalStatus(因为可能有多个客户端分别发送了更新请求),而是应该以服务器中所记录的Status更新前的字段值为准;
b)本次更新的发起用户,该信息可以根据第一客户端的邮箱地址,即From字段记录;
c)本次更新的时刻,可以记录为成功完成更新的时刻。
根据上述信息,可以生成整个事件的历史记录,以便用户随时查询,例如,项目X从启动到完成,共经历了n次状态更新,那么,根据所记录的附加信息,可以针对项目X生成以下形式的历史记录:
最新状态 | 更新用户 | 更新时间 |
启动 | aaa.com | 时刻1 |
阶段一 | aca.com | 时刻2 |
阶段二 | aba.com | 时刻3 |
...... | ...... | ...... |
完成 | aaa.com | 时刻n |
上述历史记录,除了保存在邮件服务器中之外,还可以进一步作为邮件的附加信息发送至客户端,当然,服务器也可以根据客户端发送的查询请求,向客户端反馈相应的信息,本发明对此并不需要进行限定。
可见,如果采用现有技术的实现方式,在邮件服务器中,针对同一事件X,需要存储n封邮件,而且这n封邮件彼此包含了大量的重复内容,而应用本发明方案,在邮件服务器中从始至终都只有1封邮件,每次修改的实际只有Status字段,即便需要进一步存储历史记录的附加信息,也能够显著地提升存储效率。
除了在服务器中的实现方案之外,本发明还提供在客户端中的实现方案,下面从客户端的的角度,对本发明所提供的电子邮件状态更新方法进行说明,参见图5所示,该方法可以包括以下步骤:
S201,第二客户端获得服务器发送的事件状态更新指示,所述更新请求中携带邮件标识和任务状态标识;
这里仍然接续前面的例子进行说明,服务器发送事件状态更新指示后,对于任意一个接收方(aaa.com、aba.com和bab.com)的客户端都会接收到该指示消息。
图4a所示,为本发明实施例的一种事件状态更新指示的格式示意图,其中,仅有NewStatus和EId字段是必须的。如果需要了解项目状态更新的发起者,则可以在更新请求中进一步携带From字段,以便根据邮件aca.com确定更新的发起者。至于图4a中所示出的其他字段,默认情况下都可以根据EId从之前保存的邮件信息中查到,因此在实际应用中可以携带在指示消息中,也可以不携带在指示消息中,图4a仅用于示意性说明,而不应该理解为对本发明方案的限制。
上述的事件状态更新指示消息,在实际传输过程中,可以采用传统邮件协议进行发送。
S202,根据邮件标识和任务状态标识,更新对应邮件的当前状态。
任一个接收方所对应的第二客户端在接收到事件状态更新指示消息后,首先根据EId找之前所存储的对应邮件,然后进一步根据NewStatus的内容,对之前保存的邮件的Status字段进行更新。
在本实施例中,第二客户端将Eid为a.com_823421121982725的邮件(即带有图2所示邮件头的邮件)的Status字段从“启动”更新为“进行中”。
在本发明的一种实施方式中,第二客户端也可以先对之前所保存邮件的Status字段值与待更新的字段值(即NewStatus)进行比较,如果没有变化,则不会发起更新的操作。这种情况适用于多名收件人都发出了回应、并且回应内容相同的情况,或者在本机发送更新请求到服务器后,服务器对所有的相关人员都发送了更新指示的情况,从而避免无意义的重复更新。
应用本实施所提供的方法,第二客户端根据服务器发送的状态更新指示,将自身保存的邮件状态进行更新,其中,对于图2所示的邮件头格式,在更新之后的邮件头格式可以参见图4b所示。
在本发明的一种实施方式中,第二客户端除了对Status字段进行修改之外,还可以可以进一步记录以下一种或多种附加信息:
a)邮件更新前的状态,即OriginalStatus,值得注意的是,在实际应用中下,该状态可以根据第二客户端本地所记录的更新前的字段值进行记录,也可以根据邮件服务器发送的OriginalStatus进行记录。
b)本次更新的发起用户,该信息可以根据更新指示中的第一客户端的邮箱地址,即From字段记录;
c)本次更新的时刻,可以记录为成功完成更新的时刻,为了避免各个客户端的实际更新时刻不一致,一般应统一记录为服务器上的成功更新时刻。
根据上述信息,可以生成整个事件的历史记录,以便用户随时查询,例如,项目X从启动到完成,共经历了n次状态更新,那么,根据所记录的附加信息,可以针对项目X生成以下形式的历史记录:
最新状态 | 更新用户 | 更新时间 |
启动 | aaa.com | 时刻1 |
阶段一 | aca.com | 时刻2 |
阶段二 | aba.com | 时刻3 |
...... | ...... | ...... |
完成 | aaa.com | 时刻n |
上述历史记录,可以存储在第二客户端中,以邮件的附加信息保存,以便用户随时查询。与前一实施例相比,在客户端本地生成历史记录的方式,可以降低服务器的负担,并且减少网络传输占用。
可见,如果采用现有技术的实现方式,在每个客户端中,针对同一事件X,需要存储n封邮件(可能是在发件箱中,也可能是在收件箱中),而且这n封邮件彼此包含了大量的重复内容,而应用本发明方案,在客户端中从始至终都只有1封邮件(例如,对于初始的发送者而言,该邮件存储在发件箱中,对于其他人员而言则是存储在收件箱中),每次修改的实际只有Status字段,即便需要进一步存储历史记录的附加信息,也能够显著地提升存储效率。
以上分别从服务器和客户端的角度对本发明的电子邮件状态更新方法做了介绍,需要说明的是,这两种方案本身可以是独立的,也可以是合成为一个整体方案,其中,在作为独立方案时,两种方案都可以避免“回复邮件”的方式,以更小的数据传输量实现事件状态的广播,还可以减少邮件的存储数量,无论是在服务器还是在客户端,都能够有效提高存储效率。
从用户的使用的角度,由于针对同一事件仅会保存一封邮件,客户端用户和服务器的管理员都可以更直接地进行浏览和查找等工作,有效地降低了管理成本。进一步地,根据附加记录的历史记录信息,也可以更清晰地看到整个事件的进程,与现有技术相比,不需要人工在多封邮件中寻找、记忆、梳理这些信息,大大方便了用户的使用。作为在客户端中的实现方案,还可以方便用户直接修改事件状态,避免“回复邮件”的复杂操作。
当然,根据本发明所提供的方案,在服务器的实现部分和在客户端的实现部分可以整合为一个方案,从而达到更优的效果,图6所示为本发明整合后的邮件状态更新方法的流程图,各个步骤步骤的详细实现可以参考前面的实施例,这里不再做详细说明。
S301,服务器获得第一客户端发送的事件状态更新请求,所述更新请求中携带邮件标识和任务状态标识;
S302,根据邮件标识和任务状态标识,更新对应邮件的当前状态;
S303,向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,所述更新请求中携带所述邮件标识和所述任务状态标识;
S304,第二客户端获得服务器发送的事件状态更新指示;
S305根据邮件标识和任务状态标识,更新对应邮件的当前状态。
需要说明的是,上述的“第一客户端”和“第二客户端”仅是根据在一次状态更新中的角色进行区分,而不应该简单理解为物理上的区分。作为一个物理上独立的客户端,应该既能够实现“第一客户端”的功能,也能够实现“第二客户端”的功能。
相应于上面的方法实施例,本发明还提供一种电子邮件服务器,参见图7所示,该服务器包括:
更新请求接收单元310,用于获得第一客户端发送的事件状态更新请求,所述更新请求中携带邮件标识和任务状态标识;
假设在首次邮件发送之后、所有3名收件人都已收到该邮件。其中,收件人aca.com根据邮件内容开始了项目进程,并且需要将该情况通知给其他人,则该用户可以直接在已接收的邮件“关于项目X”上,对邮件的Status字段进行修改,例如修改为“进行中”。
当aca.com在第一客户端上完成Status字段修改并确认保存后,第一客户端向服务器发送一条事件状态更新请求消息,该请求中需要携带EId和修改后的Status,为便于说明,后续将修改后的Status称为OriginalStatus、将修改后的Status称为NewStatus。
图4a所示,为本发明实施例的一种事件状态更新请求的格式示意图,其中,仅有NewStatus和EId字段是必须的。如果需要了解项目状态更新的发起者,则可以在更新请求中进一步携带From字段,以便根据邮件aca.com确定更新的发起者。至于图4a中所示出的其他字段,默认情况下都可以根据EId从之前保存的邮件信息中查到,因此在实际应用中可以携带在请求消息中,也可以不携带在请求消息中,图4a仅用于示意性说明,而不应该理解为对本发明方案的限制。
上述的事件状态更新请求消息,在实际传输过程中,可以采用传统邮件协议进行发送。
邮件状态更新单元320,用于根据邮件标识和任务状态标识,更新对应邮件的当前状态;
邮件状态更新单元320在接收到事件状态更新请求消息后,首先根据EId找之前所存储的对应邮件,然后进一步根据NewStatus的内容,对之前保存的邮件的Status字段进行更新。
在本实施例中,邮件状态更新单元320将Eid为a.com_823421121982725的邮件(即带有图2所示邮件头的邮件)的Status字段从“启动”更新为“进行中”。
在本发明的一种具体实施方式中,所述邮件状态更新单元320,具体用于根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态;在本实施例中,邮件服务器先对之前所保存邮件的Status字段值与待更新的字段值(即NewStatus)进行比较,如果没有变化,则不会发起更新的操作。这种情况适用于多名收件人都发出了回应、并且回应内容相同的情况,可以避免无意义的重复更新。
更新指示发送单元330,用于根据邮件标识和任务状态标识,向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,所述更新请求中携带所述邮件标识和所述任务状态标识。
邮件服务器在接收到事件状态更新请求消息后,还需要将该更新情况进一步告知其他相关用户。具体地,更新指示发送单元330可以根据EId找之前所存储的对应邮件,然后对该邮件中所有涉及的相关人员都发送一条事件状态更新指示消息,当然,这里也可以根据所接收的事件状态更新请求消息中的To字段,确定事件状态更新指示消息的接收方。在本实施例中,事件状态更新指示消息的接收方为aaa.com、aba.com和bab.com三人,对于更新的发起人aca.com,可以向其发送消息,也不可以不向其发送消息,这些并不影响本发明方案的实施。
在实际应用中,也可以理解为:邮件服务器将事件状态更新请求消息直接转发给相应的接收方,因此事件状态更新指示消息的格式可以与事件状态更新请求消息类似,参见图4a所示,其中必要的部分仍然是EId和Status字段,其作用是告知接收方当前对哪一封邮件做了状态修改,并且指示客户端对相应的邮件的Status也进行修改。
在本发明的一种实施方式中,更新指示发送单元330可以先对之前所保存邮件的Status字段值与待更新的字段值(即NewStatus)进行比较,如果没有变化,则不发送事件状态更新指示消息,从而避免无意义的重复更新指示。
上述的事件状态更新指示消息,在实际传输过程中,可以采用传统邮件协议进行发送。
在本发明一种具体实施方式中,所述邮件状态更新单元320还用于:
记录所述对应邮件更新前的状态。
或者
根据所述第一客户端的邮箱地址,记录所述对应邮件的更新发起用户。
或者
对邮件状态更新时刻进行记录。
根据上述信息,可以生成整个事件的历史记录,以便用户随时查询,例如,项目X从启动到完成,共经历了n次状态更新,那么,根据所记录的附加信息,可以针对项目X生成以下形式的历史记录:
最新状态 | 更新用户 | 更新时间 |
启动 | aaa.com | 时刻1 |
阶段一 | aca.com | 时刻2 |
阶段二 | aba.com | 时刻3 |
...... | ...... | ...... |
完成 | aaa.com | 时刻n |
在本发明一种具体实施方式中,所述更新指示发送单元330还用于:
将所述更新发起用户的信息携带于事件状态更新指示中。
在本发明一种具体实施方式中,该服务器还包括标识分配单元,用于服务器为邮件分配唯一的标识,该并将标识用于在后续的传输过程中携带于该邮件中。
本发明还提供一种电子邮件客户端,参见图8所示,其特征在于,该客户端包括:
更新指示接收单元410,用于获得服务器发送的事件状态更新指示,所述更新请求中携带邮件标识和任务状态标识;
服务器发送事件状态更新指示后,对于任意一个接收方(aaa.com、aba.com和bab.com)的客户端都会接收到该指示消息。
图4a所示,为本发明实施例的一种事件状态更新指示的格式示意图,其中,仅有NewStatus和EId字段是必须的。如果需要了解项目状态更新的发起者,则可以在更新请求中进一步携带From字段,以便根据邮件aca.com确定更新的发起者。至于图4a中所示出的其他字段,默认情况下都可以根据EId从之前保存的邮件信息中查到,因此在实际应用中可以携带在指示消息中,也可以不携带在指示消息中,图4a仅用于示意性说明,而不应该理解为对本发明方案的限制。
上述的事件状态更新指示消息,在实际传输过程中,可以采用传统邮件协议进行发送。
邮件状态更新单元420,用于根据邮件标识和任务状态标识,更新对应邮件的当前状态。
任一个接收方所对应的客户端在接收到事件状态更新指示消息后,邮件状态更新单元420首先根据EId找之前所存储的对应邮件,然后进一步根据NewStatus的内容,对之前保存的邮件的Status字段进行更新。
在本实施例中,邮件状态更新单元420将Eid为a.com_823421121982725的邮件(即带有图2所示邮件头的邮件)的Status字段从“启动”更新为“进行中”。
在本发明一种具体实施方式中,所述邮件状态更新单元420,也可以先对之前所保存邮件的Status字段值与待更新的字段值(即NewStatus)进行比较,如果没有变化,则不会发起更新的操作。这种情况适用于多名收件人都发出了回应、并且回应内容相同的情况,或者在本机发送更新请求到服务器后,服务器对所有的相关人员都发送了更新指示的情况,从而避免无意义的重复更新。
在本发明一种具体实施方式中,所述邮件状态更新单元,还可以用于:
记录所述对应邮件更新前的状态。
或者
根据所述更新请求中携带的更新发起用户的信息,记录所述更新发起用户的信息。
或者
对邮件状态更新时刻进行记录。
根据上述信息,可以生成整个事件的历史记录,以便用户随时查询,例如,项目X从启动到完成,共经历了n次状态更新,那么,根据所记录的附加信息,可以针对项目X生成以下形式的历史记录:
最新状态 | 更新用户 | 更新时间 |
启动 | aaa.com | 时刻1 |
阶段一 | aca.com | 时刻2 |
阶段二 | aba.com | 时刻3 |
...... | ...... | ...... |
完成 | aaa.com | 时刻n |
上述历史记录,可以存储在客户端中,以邮件的附加信息保存,以便用户随时查询。与前一实施例相比,在客户端本地生成历史记录的方式,可以降低服务器的负担,并且减少网络传输占用。
以上分别从服务器和客户端的角度对本发明所提供的方案做了介绍,需要说明的是,这两种方案本身可以是独立的,也可以是合成为一个整体方案,其中,在作为独立方案时,两种方案都可以避免“回复邮件”的方式,以更小的数据传输量实现事件状态的广播,还可以减少邮件的存储数量,无论是在服务器还是在客户端,都能够有效提高存储效率。
从用户的使用的角度,由于针对同一事件仅会保存一封邮件,客户端用户和服务器的管理员都可以更直接地进行浏览和查找等工作,有效地降低了管理成本。进一步地,根据附加记录的历史记录信息,也可以更清晰地看到整个事件的进程,与现有技术相比,不需要人工在多封邮件中寻找、记忆、梳理这些信息,大大方便了用户的使用。作为在客户端中的实现方案,还可以方便用户直接修改事件状态,避免“回复邮件”的复杂操作。
当然,根据本发明所提供的电子邮件服务器和电子邮件客户端,也可以整合为一个电子邮件***,从而达到更优的效果,其中,在该***中的客户端,应该既具有“发起邮件状态更新”的功能,也具有“接受邮件状态”的功能。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置或***实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置及***实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本发明的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (21)
1.一种电子邮件状态更新方法,其特征在于,该方法包括:
服务器获得第一客户端发送的事件状态更新请求,所述更新请求中携带邮件标识和任务状态标识;
根据邮件标识和任务状态标识,更新对应邮件的当前状态;以及
根据邮件标识和任务状态标识,向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,所述更新请求中携带所述邮件标识和所述任务状态标识。
2.根据权利要求1所述的方法,其特征在于,
所述根据邮件标识和任务状态标识,更新对应邮件的当前状态,包括:
根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态;
所述根据邮件标识和任务状态标识,向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,包括:
根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则向所述对应邮件所涉及的用户邮箱发送事件状态更新指示。
3.根据权利要求1所述的方法,其特征在于,该方法还包括:
服务器记录所述对应邮件更新前的状态。
4.根据权利要求1所述的方法,其特征在于,该方法还包括:
服务器根据所述第一客户端的邮箱地址,记录所述对应邮件的更新发起用户。
5.根据权利要求4所述的方法,其特征在于,该方法还包括:
服务器将所述更新发起用户的信息携带于事件状态更新指示中。
6.根据权利要求1所述的方法,其特征在于,该方法还包括:
服务器为邮件分配唯一的标识,并将标识携带于该邮件中,用于后续的传输过程。
7.一种电子邮件状态更新方法,其特征在于,该方法包括:
第二客户端获得服务器发送的事件状态更新指示,所述更新请求中携带邮件标识和任务状态标识;
根据邮件标识和任务状态标识,更新对应邮件的当前状态。
8.根据权利要求7所述的方法,其特征在于,所述根据邮件标识和任务状态标识,更新对应邮件的当前状态,包括:
根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态。
9.根据权利要求7所述的方法,其特征在于,该方法还包括:
第二客户端记录所述对应邮件更新前的状态。
10.根据权利要求7所述的方法,其特征在于,
所述更新请求中还携带有更新发起用户的信息;
所述方法还包括:第二客户端记录所述更新发起用户的信息。
11.一种电子邮件服务器,其特征在于,该服务器包括:
更新请求接收单元,用于获得第一客户端发送的事件状态更新请求,所述更新请求中携带邮件标识和任务状态标识;
邮件状态更新单元,用于根据邮件标识和任务状态标识,更新对应邮件的当前状态;
更新指示发送单元,用于根据邮件标识和任务状态标识,向所述对应邮件所涉及的用户邮箱发送事件状态更新指示,所述更新请求中携带所述邮件标识和所述任务状态标识。
12.根据权利要求11所述的服务器,其特征在于,
所述邮件状态更新单元,具体用于根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态;
所述更新指示发送单元,具体用于根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则向所述对应邮件所涉及的用户邮箱发送事件状态更新指示。
13.根据权利要求11所述的服务器,其特征在于,所述邮件状态更新单元还用于:
记录所述对应邮件更新前的状态。
14.根据权利要求11所述的服务器,其特征在于,所述邮件状态更新单元还用于:
根据所述第一客户端的邮箱地址,记录所述对应邮件的更新发起用户。
15.根据权利要求14所述的服务器,其特征在于,所述更新指示发送单元还用于:
将所述更新发起用户的信息携带于事件状态更新指示中。
16.根据权利要求11所述的服务器,其特征在于,该服务器还包括:
标识分配单元,用于服务器为邮件分配唯一的标识,该并将标识用于在后续的传输过程中携带于该邮件中。
17.一种电子邮件客户端,其特征在于,该客户端包括:
更新指示接收单元,用于获得服务器发送的事件状态更新指示,所述更新请求中携带邮件标识和任务状态标识;
邮件状态更新单元,用于根据邮件标识和任务状态标识,更新对应邮件的当前状态。
18.根据权利要求17所述的客户端,其特征在于,所述邮件状态更新单元,具体用于:
根据邮件标识和任务状态标识,判断对应邮件的当前任务状态与待更新任务状态是否一致,如果否,则更新对应邮件的当前状态。
19.根据权利要求17所述的客户端,其特征在于,所述邮件状态更新单元,还用于:
记录所述对应邮件更新前的状态。
20.根据权利要求17所述的客户端,其特征在于,
所述更新请求中还携带有更新发起用户的信息;
所述邮件状态更新单元,还用于:
记录所述更新发起用户的信息。
21.一种电子邮件***,其特征在于,该***包括如权利要求11-16任一项所述的电子邮件服务器以及如权利要求17-20任一项所述的电子邮件客户端。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2012104214693A CN102970209A (zh) | 2012-10-29 | 2012-10-29 | 一种电子邮件状态更新方法、装置及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2012104214693A CN102970209A (zh) | 2012-10-29 | 2012-10-29 | 一种电子邮件状态更新方法、装置及*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102970209A true CN102970209A (zh) | 2013-03-13 |
Family
ID=47800097
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2012104214693A Pending CN102970209A (zh) | 2012-10-29 | 2012-10-29 | 一种电子邮件状态更新方法、装置及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102970209A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103490977A (zh) * | 2013-08-27 | 2014-01-01 | 新浪网技术(中国)有限公司 | 电子邮件发送状态的查询方法及*** |
CN104219136A (zh) * | 2013-06-05 | 2014-12-17 | 北京国信冠群技术有限公司 | 一种电子邮件在流转过程中附件实时更新的***及方法 |
CN105359176A (zh) * | 2013-05-03 | 2016-02-24 | 思杰***有限公司 | 更新先前递送的电子消息的接收者 |
CN107146064A (zh) * | 2017-03-13 | 2017-09-08 | 广州视源电子科技股份有限公司 | 待办事项提醒方法及服务器 |
CN108462625A (zh) * | 2017-02-20 | 2018-08-28 | 阿里巴巴集团控股有限公司 | 回复电子邮件过程中确定收件人的方法和装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101237335A (zh) * | 2007-02-02 | 2008-08-06 | 阿里巴巴公司 | 实时通知事件状态变化的方法和*** |
US20080288322A1 (en) * | 2007-05-10 | 2008-11-20 | Kevin Kennedy & Associates, Inc. | Methods and systems for project management |
US20100293278A1 (en) * | 2009-05-18 | 2010-11-18 | Microsoft Corporation | Synchronizing Tasks between Servers |
CN102170405A (zh) * | 2010-02-25 | 2011-08-31 | 腾讯科技(深圳)有限公司 | 一种邮件处理方法、邮件服务器及*** |
CN102567801A (zh) * | 2010-12-08 | 2012-07-11 | 微软公司 | 提供有机项目的方法和装置 |
-
2012
- 2012-10-29 CN CN2012104214693A patent/CN102970209A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101237335A (zh) * | 2007-02-02 | 2008-08-06 | 阿里巴巴公司 | 实时通知事件状态变化的方法和*** |
US20080288322A1 (en) * | 2007-05-10 | 2008-11-20 | Kevin Kennedy & Associates, Inc. | Methods and systems for project management |
US20100293278A1 (en) * | 2009-05-18 | 2010-11-18 | Microsoft Corporation | Synchronizing Tasks between Servers |
CN102170405A (zh) * | 2010-02-25 | 2011-08-31 | 腾讯科技(深圳)有限公司 | 一种邮件处理方法、邮件服务器及*** |
CN102567801A (zh) * | 2010-12-08 | 2012-07-11 | 微软公司 | 提供有机项目的方法和装置 |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105359176A (zh) * | 2013-05-03 | 2016-02-24 | 思杰***有限公司 | 更新先前递送的电子消息的接收者 |
CN104219136A (zh) * | 2013-06-05 | 2014-12-17 | 北京国信冠群技术有限公司 | 一种电子邮件在流转过程中附件实时更新的***及方法 |
CN104219136B (zh) * | 2013-06-05 | 2017-12-26 | 北京国信冠群技术有限公司 | 一种电子邮件在流转过程中附件实时更新的***及方法 |
CN103490977A (zh) * | 2013-08-27 | 2014-01-01 | 新浪网技术(中国)有限公司 | 电子邮件发送状态的查询方法及*** |
CN103490977B (zh) * | 2013-08-27 | 2017-11-03 | 新浪网技术(中国)有限公司 | 电子邮件发送状态的查询方法及*** |
CN108462625A (zh) * | 2017-02-20 | 2018-08-28 | 阿里巴巴集团控股有限公司 | 回复电子邮件过程中确定收件人的方法和装置 |
CN108462625B (zh) * | 2017-02-20 | 2021-10-12 | 阿里巴巴集团控股有限公司 | 回复电子邮件过程中确定收件人的方法和装置 |
CN107146064A (zh) * | 2017-03-13 | 2017-09-08 | 广州视源电子科技股份有限公司 | 待办事项提醒方法及服务器 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108416683B (zh) | 移动终端的保单确认方法、装置、设备及存储介质 | |
CA2952419C (en) | Directory generation and messaging | |
US9177292B2 (en) | Cautious auto-entry for messaging systems | |
US20040054733A1 (en) | E-mail management system and method | |
US20020087646A1 (en) | System and method for group electronic mailbox | |
CN101997894A (zh) | 一种信息推送方法及其***和网络*** | |
KR100841697B1 (ko) | 수신자들에 대한 일반 수신자 메시지들의 전달을 급송 및우선순위화하는 방법, 장치 및 컴퓨터 프로그램 생성물 | |
CA2263903A1 (en) | System for supplying automatic status updates using electronic mail | |
US20080098071A1 (en) | Method and process to unsubscribe from on-going electronic message threads | |
CN107341527B (zh) | 一种物流新增订单管理方法及*** | |
CN102970209A (zh) | 一种电子邮件状态更新方法、装置及*** | |
CN102422275A (zh) | 用于使得任务能够在企业环境中聚合的方法、计算机程序产品及设备 | |
CN105847059B (zh) | 信息发送管理方法和装置 | |
US20100121673A1 (en) | Message notification method, work management device, and computer program | |
CN105260881A (zh) | 一种基于任务的信息管理方法、装置及*** | |
CN109327496A (zh) | 数据推送方法、装置、计算机设备及存储介质 | |
US20080155030A1 (en) | Systems and methods for conveying information to an instant messaging client | |
CN110570155A (zh) | 一种快递寄件下单的方法、装置、服务器及存储介质 | |
CN103516581A (zh) | 添加即时通信好友的方法及装置 | |
JP4782619B2 (ja) | 電子メールに対する対応管理の管理支援装置、管理支援方法及びコンピュータプログラム | |
US20030233336A1 (en) | System to retate personal information to a unique identifier | |
US11093125B1 (en) | Email conversation linking | |
CN100425041C (zh) | 一种企业即时通信方法及*** | |
JP2020166434A (ja) | 通知方法選択装置、通知方法選択方法、及びプログラム | |
CN109921985B (zh) | 邮件群组发送方法、装置、服务器及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
EXSB | Decision made by sipo to initiate substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20130313 |