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 .
Response to Amendment
The Amendment filed 07/08/2026 has been entered.
Claims 1-2, 12-14, 25, 27-28 have been amended.
Claims 1-14 and 25-30 remain pending in the application.
Response to Arguments
Applicant’s arguments with respect to claims 1-14 and 25-30 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 13-14, 25, 27, 28 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Zitnik et al. (US 20140134978 A1) in view of Haque (US 10904038 B1).
Regarding claim 1, Zitnik teaches a method (method of Fig. 5), comprising:
receiving, with one or more processors of a server device and from a first client device, data corresponding to a message (Subscriber 1 sends an INVITE to the CN (acting as the CSCF) to request an RCS session with Subscriber 2, [0083]).
determining, with the one or more processors, a recipient messaging protocol for the message (CN queries the SRDB to determine if the target handset is RCS capable, [0084]).
However, Zitnik does not clearly teach wherein a payload of the message is formatted in a rich communication services (RCS) protocol and wherein the payload is packaged according to the RCS protocol at a transport layer of the message; in response to determining that the recipient messaging protocol for the message is an over-the-top (OTT) protocol, repackaging, with the one or more processors, the payload of the message according to the OTT protocol at a transport layer of a repackaged message to generate the repackaged message having the payload formatted in the RCS protocol; and transmitting, with the one or more processors, data corresponding to the repackaged message to a second client device.
In an analogous art, Haque teaches teach wherein a payload of the message is formatted in a rich communication services (RCS) protocol and wherein the payload is packaged according to the RCS protocol at a transport layer of the message (the transport service of transport layer 250 may receive the payload of a transport event and perform transformation to generate a transport specific protocol message, par 6, lines 59-61; external network 170 may be implemented to include a Rich Communication Service (RCS) network, col 4, lines 29-33); in response to determining that the recipient messaging protocol for the message is an over-the-top (OTT) protocol, repackaging, with the one or more processors, the payload of the message according to the OTT protocol at a transport layer of a repackaged message to generate the repackaged message having the payload formatted in the RCS protocol (the transport service of transport layer 250 may receive a message for reasons that include a response to a command, a response to a wakeup, an acknowledgement of a command received, a monitoring alert trigger, or end device 199 generated event trigger which was not configure monitoring. The transport service may listen to a specific protocol associated with end device 199. Additionally, the transport service may extract the payload from the transport-specific protocol and build a transport event. The transport service may also gather context information from end device configuration information when a message is received and from the message itself. The transport service may populate information in appropriate fields of the transport event, col 7, line 8-20; external network 170 may be implemented to include a Rich Communication Service (RCS) network, col 4, lines 29-33); and
transmitting, with the one or more processors, data corresponding to the repackaged message to a second client device (SMS transport adaptor service may use the Mobile Station International Subscriber Directory Number (MSISDN) assigned to end device 199 to deliver the SMPP message to service device 210 via device gateway, col 7, lines 1-3).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik with the payload of Haque to provide a method and device to allow RCS-based applications to operate seamlessly with an IMS core, thus streamlining the control signaling used to provide RCS features as suggested.
Regarding Claim 2, Zitnik as modified by Haque teaches the method of claim 1, Haque teaches wherein at least one of a serialization layer of the message or an encryption layer of the message is formatted in the RCS protocol (An end device 199, which uses a particular protocol, may have different sequences of steps to have a command ready to be transported to service device 210. For example, an end device 199 that uses the Application Transport Protocol (ATP) may also require additional encryption and digest validation steps for the messages transported over SMS in addition to messages transported via HTTPS, col 9, lines 3-9).
Regarding Claim 13, Zitnik teaches a server device (e.g. RCS agent of Fig. 2 30b) comprising: one or more processors; and a memory coupled to the one or more processors, the memory storing one or more programs that (The functional entities may also be stored in separate memories and executed by separate processors, [0093]), when executed by the one or more processors, cause the one or more processors to:
receive, from a first client device, data corresponding to a message (Subscriber 1 sends an INVITE to the CN (acting as the CSCF) to request an RCS session with Subscriber 2, [0083]);
determine a recipient messaging protocol for the message (CN queries the SRDB to determine if the target handset is RCS capable, [0084]).
However, Zitnik does not clearly teach wherein a payload of the message is formatted in a rich communication services (RCS) protocol and wherein the payload is packaged according to the RCS protocol at a transport layer of the message; in response to determining that the recipient messaging protocol for the message is an over-the-top (OTT) protocol, repackaging, with the one or more processors, the payload of the message according to the OTT protocol at a transport layer of a repackaged message to generate the repackaged message having the payload formatted in the RCS protocol; and transmitting, with the one or more processors, data corresponding to the repackaged message to a second client device.
In an analogous art, Haque teaches teach wherein a payload of the message is formatted in a rich communication services (RCS) protocol and wherein the payload is packaged according to the RCS protocol at a transport layer of the message (the transport service of transport layer 250 may receive the payload of a transport event and perform transformation to generate a transport specific protocol message, par 6, lines 59-61; external network 170 may be implemented to include a Rich Communication Service (RCS) network, col 4, lines 29-33); in response to determining that the recipient messaging protocol for the message is an over-the-top (OTT) protocol, repackaging, with the one or more processors, the payload of the message according to the OTT protocol at a transport layer of a repackaged message to generate the repackaged message having the payload formatted in the RCS protocol (the transport service of transport layer 250 may receive a message for reasons that include a response to a command, a response to a wakeup, an acknowledgement of a command received, a monitoring alert trigger, or end device 199 generated event trigger which was not configure monitoring. The transport service may listen to a specific protocol associated with end device 199. Additionally, the transport service may extract the payload from the transport-specific protocol and build a transport event. The transport service may also gather context information from end device configuration information when a message is received and from the message itself. The transport service may populate information in appropriate fields of the transport event, col 7, line 8-20; external network 170 may be implemented to include a Rich Communication Service (RCS) network, col 4, lines 29-33); and
transmitting, with the one or more processors, data corresponding to the repackaged message to a second client device (SMS transport adaptor service may use the Mobile Station International Subscriber Directory Number (MSISDN) assigned to end device 199 to deliver the SMPP message to service device 210 via device gateway, col 7, lines 1-3).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik with the payload of Haque to provide a method and device to allow RCS-based applications to operate seamlessly with an IMS core, thus streamlining the control signaling used to provide RCS features as suggested.
Regarding Claim 14, Zitnik teaches a non-transitory computer-readable storage medium storing instructions that (e.g. RCS of Fig. 2), when executed by one or more processors of a server device, cause the one or more processors to:
receive, from a first client device, data corresponding to a message (Subscriber 1 sends an INVITE to the CN (acting as the CSCF) to request an RCS session with Subscriber 2, [0083]);
determine a recipient messaging protocol for the message (CN queries the SRDB to determine if the target handset is RCS capable, [0084]).
However, Zitnik does not clearly teach wherein a payload of the message is formatted in a rich communication services (RCS) protocol and wherein the payload is packaged according to the RCS protocol at a transport layer of the message; in response to determining that the recipient messaging protocol for the message is an over-the-top (OTT) protocol, repackaging, with the one or more processors, the payload of the message according to the OTT protocol at a transport layer of a repackaged message to generate the repackaged message having the payload formatted in the RCS protocol; and transmitting, with the one or more processors, data corresponding to the repackaged message to a second client device.
In an analogous art, Haque teaches teach wherein a payload of the message is formatted in a rich communication services (RCS) protocol and wherein the payload is packaged according to the RCS protocol at a transport layer of the message (the transport service of transport layer 250 may receive the payload of a transport event and perform transformation to generate a transport specific protocol message, par 6, lines 59-61; external network 170 may be implemented to include a Rich Communication Service (RCS) network, col 4, lines 29-33); in response to determining that the recipient messaging protocol for the message is an over-the-top (OTT) protocol, repackaging, with the one or more processors, the payload of the message according to the OTT protocol at a transport layer of a repackaged message to generate the repackaged message having the payload formatted in the RCS protocol (the transport service of transport layer 250 may receive a message for reasons that include a response to a command, a response to a wakeup, an acknowledgement of a command received, a monitoring alert trigger, or end device 199 generated event trigger which was not configure monitoring. The transport service may listen to a specific protocol associated with end device 199. Additionally, the transport service may extract the payload from the transport-specific protocol and build a transport event. The transport service may also gather context information from end device configuration information when a message is received and from the message itself. The transport service may populate information in appropriate fields of the transport event, col 7, line 8-20; external network 170 may be implemented to include a Rich Communication Service (RCS) network, col 4, lines 29-33); and
transmitting, with the one or more processors, data corresponding to the repackaged message to a second client device (SMS transport adaptor service may use the Mobile Station International Subscriber Directory Number (MSISDN) assigned to end device 199 to deliver the SMPP message to service device 210 via device gateway, col 7, lines 1-3).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik with the payload of Haque to provide a method and device to allow RCS-based applications to operate seamlessly with an IMS core, thus streamlining the control signaling used to provide RCS features as suggested.
Regarding Claim 25, Zitnik as modified by Haque teaches the server device of claim 13. Haque teaches wherein at least one of a serialization layer of the message or an encryption layer of the message is formatted in the RCS protocol (An end device 199, which uses a particular protocol, may have different sequences of steps to have a command ready to be transported to service device 210. For example, an end device 199 that uses the Application Transport Protocol (ATP) may also require additional encryption and digest validation steps for the messages transported over SMS in addition to messages transported via HTTPS, col 9, lines 3-9).
Regarding Claim 27, Zitnik as modified by Haque teaches the server device of claim 13, wherein the memory storing the one or more programs, when executed by the one or more processors, cause the one or more processors to: in response to registering the second client device, receive data corresponding to one or more capabilities of the second client device and the token, wherein the one or more capabilities of the second client device indicate at least a messaging protocol for the second client device (upon receipt and acknowledgment of the registration event, the RCS core will send an OPTIONS message to the registered handset. This will cause the target handset to return its capabilities, which will be stored in a routing database internal to the system, Zitnik, [0026]); and cache, with the one or more processors, the one or more capabilities of the second client device (upon receipt and acknowledgment of the registration event, the RCS core will send an OPTIONS message to the registered handset. This will cause the target handset to return its capabilities, which will be stored in a routing database internal to the system, Zitnik, [0026]).
Regarding Claim 28, Zitnik as modified by Haque teaches the non-transitory computer-readable storage medium of claim 14. Haque further teaches wherein at least one of a serialization layer of the message or an encryption layer of the message is formatted in the RCS protocol (An end device 199, which uses a particular protocol, may have different sequences of steps to have a command ready to be transported to service device 210. For example, an end device 199 that uses the Application Transport Protocol (ATP) may also require additional encryption and digest validation steps for the messages transported over SMS in addition to messages transported via HTTPS, col 9, lines 3-9).
Regarding Claim 30, Zitnik as modified by Haque teaches the non-transitory computer-readable storage medium of claim 29, wherein the instructions, when executed by the one or more processors of the server device, cause the one or more processors to: in response to registering the second client device, receive data corresponding to one or more capabilities of the second client device and the token, wherein the one or more capabilities of the second client device indicate at least a messaging protocol for the second client device (upon receipt and acknowledgment of the registration event, the RCS core will send an OPTIONS message to the registered handset. This will cause the target handset to return its capabilities, which will be stored in a routing database internal to the system, Zitnik, [0026]); and cache, with the one or more processors, the one or more capabilities of the second client device (upon receipt and acknowledgment of the registration event, the RCS core will send an OPTIONS message to the registered handset. This will cause the target handset to return its capabilities, which will be stored in a routing database internal to the system, Zitnik, [0026]).
Claims 3-6 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Zitnik in view of Haque and further in view of Kim et al. (US 20200267514 A1).
Regarding Claim 3, Zitnik as modified by Haque teaches the method of claim 1.
However, Zitnik and Haque do not teach further comprising: in response to registering the second client device, transmitting, with the one or more processors, a token to the second client device, wherein the token indicates authorization to establish a connection with the server device.
In an analogous art, Kim teaches in response to registering the second client device, transmitting, with the one or more processors, a token to the second client device, wherein the token indicates authorization to establish a connection with the server device (the processor 420 may control the communication module 450 to transmit a service registration request signal including pre-acquired caller identification information (e.g., a sender ID) to a push server 482 (e.g., the push server 122 of FIG. 1) of the first server 480. The processor 420 may receive a signal including a registration token from the push server 482 via the communication module 450 in response to the service registration request signal. The registration token may be authentication information for the second application program, [0074]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik and Haque with the registration of Kim to provide a method and device for processing and managing a message received using a push notification service, as a message received using another message service in an electronic device to reduce the cost as suggested, Kim [0006].
Regarding Claim 4, Zitnik as modified by Haque and Kim teaches the method of claim 3, further comprising: in response to registering the second client device, receiving, with the one or more processors, data corresponding to one or more capabilities of the second client device and the token, wherein the one or more capabilities of the second client device indicate at least a messaging protocol for the second client device (upon receipt and acknowledgment of the registration event, the RCS core will send an OPTIONS message to the registered handset. This will cause the target handset to return its capabilities, which will be stored in a routing database internal to the system. This information will be stored with the purpose of identifying which devices are RCS capable in the operator's network, Zitnik [0026]).
Regarding Claim 5, Zitnik as modified by Haque and Kim teaches the method of claim 4, wherein determining the recipient messaging protocol for the message further comprises: determining, with the one or more processors, the recipient messaging protocol for the message based at least in part on the messaging protocol for the second client device indicated by the cached one or more capabilities of the second client device (CN queries the SRDB to determine whether or not the target handset is RCS capable. (This data is populated per the registration call flow above, Zitnik [0047]).
Regarding Claim 6, Zitnik as modified by Haque and Kim teaches the method claim 4. Kim further teaches further comprising: updating, with the one or more processors, the cached one or more capabilities of the second client device in response to receiving updated data corresponding to the one or more capabilities of the second client device from the second client device (The processor 720 may generate and/or update the rejection list indicating electronic devices having rejected reception of the message, on the basis of the signal indicating whether message reception is allowed, Kim [0102]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik and Haque with the registration of Kim to provide a method and device for processing and managing a message received using a push notification service, as a message received using another message service in an electronic device to reduce the cost as suggested, Kim [0006].
Regarding Claim 8, Zitnik as modified by Haque and Kim teaches the method claim 6. Kim further teaches further comprising: receiving, with the one or more processors and from the first client device, a request to subscribe to updates to the one or more capabilities of the second client device (The first server 480 having received the signal for requesting the reception rejecting configuration may generate and/or update the rejection list 1403. For example, the first server 480 may add the phone number of the electronic device 401 to the rejection list related to the second server 490, Kim [0158]); and in response to updating the cached one or more capabilities of the second client device, sending, with the one or more processors, data corresponding to one or more updated capabilities of the second client device (the first server 480 may transmit, to the second server 490, failure information including a phone number that is not included in the subscriber list from among phone numbers included in the receiver list, for example, a non-subscriber phone number, Kim [0159]).
Regarding Claim 26, Zitnik as modified by Haque teaches the server device of claim 13.
However, Zitnik and Haque do not teach wherein the memory storing the one or more programs, when executed by the one or more processors, cause the one or more processors to: in response to registering the second client device, transmit a token to the second client device, wherein the token indicates authorization to establish a connection with the server device.
In an analogous art, Kim teaches wherein the memory storing the one or more programs, when executed by the one or more processors, cause the one or more processors to: in response to registering the second client device, transmit a token to the second client device, wherein the token indicates authorization to establish a connection with the server device (the processor 420 may control the communication module 450 to transmit a service registration request signal including pre-acquired caller identification information (e.g., a sender ID) to a push server 482 (e.g., the push server 122 of FIG. 1) of the first server 480. The processor 420 may receive a signal including a registration token from the push server 482 via the communication module 450 in response to the service registration request signal. The registration token may be authentication information for the second application program, [0074]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik and Haque with the registration of Kim to provide a method and device for processing and managing a message received using a push notification service, as a message received using another message service in an electronic device to reduce the cost as suggested, Kim [0006].
Regarding Claim 29, Zitnik as modified by Haque teaches the non-transitory computer-readable storage medium of claim 14,
However, Zitnik and Haque do not teach wherein the instructions, when executed by the one or more processors of the server device, cause the one or more processors to: in response to registering the second client device, transmit a token to the second client device, wherein the token indicates authorization to establish a connection with the server device.
In an analogous art, Kim teaches wherein the instructions, when executed by the one or more processors of the server device, cause the one or more processors to: in response to registering the second client device, transmit a token to the second client device, wherein the token indicates authorization to establish a connection with the server device (the processor 420 may control the communication module 450 to transmit a service registration request signal including pre-acquired caller identification information (e.g., a sender ID) to a push server 482 (e.g., the push server 122 of FIG. 1) of the first server 480. The processor 420 may receive a signal including a registration token from the push server 482 via the communication module 450 in response to the service registration request signal. The registration token may be authentication information for the second application program, [0074]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik and Haque with the registration of Kim to provide a method and device for processing and managing a message received using a push notification service, as a message received using another message service in an electronic device to reduce the cost as suggested, Kim [0006].
Claim 7is rejected under 35 U.S.C. 103 as being unpatentable over Zitnik in view of Haque and further in view of Kim et al. (US 20200267514 A1) and Ward et al. (US 20220357939 A1).
Regarding Claim 7, Zitnik as modified by Haque and Kim teaches the method of claim 6.
However, Zitnik, Haque and Kim do not teach further comprising: timestamping, with the one or more processors, the cached one or more capabilities of the second client device at each update; and determining, with the one or more processors, whether the second client device is active based at least in part on a timestamp of a most recent one of the cached one or more capabilities of the second client device.
In an analogous art, Ward teaches timestamping, with the one or more processors, the cached one or more capabilities of the second client device at each update (the device connectivity information may include device RAN mode, PSM timer settings, last connect to network timestamp, [0035]); and determining, with the one or more processors, whether the second client device is active based at least in part on a timestamp of a most recent one of the cached one or more capabilities of the second client device (FOTA agent 110 may subscribe to an SCEF/NEF 210 and/or other device services, such as device management diagnostics and/or location, for device connectivity information 206 pertaining to end device 130, for example, that may be received 208 at a device diagnostic and location service 220 device. For example, the device connectivity information may include device RAN mode, PSM timer settings, last connect to network timestamp, [0035]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik, Haque and Kim the connectivity information of Ward to provide a method and device to enhance existing or add new functionalities, address security vulnerabilities as suggested, Ward [0010].
Claims 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Zitnik in view of Haque and further in view of Kim et al. (US 20200267514 A1) and Wang et al. (US 20240298150 A1).
Regarding Claim 9, Zitnik as modified by Haque and Kim teaches the method of claim 3.
However, Zitnik, Haque and Kim do not teach further comprising: prior to transmitting the data corresponding to the repackaged message, determining, with the one or more processors, that no open connection exists with the second client device; and in response to determining that no open connection exists with the second client device, transmitting, with the one or more processors, data corresponding to a pull available message to the second client device, wherein the pull available message indicates that the repackaged message is available to be pulled by the second client device.
In an analogous art, Wang teaches prior to transmitting the data corresponding to the repackaged message, determining, with the one or more processors, that no open connection exists with the second client device (If the group-sending files acquired for multiple times cannot pass the file verification, the second node sends a receipt message indicating abnormal reception of the group-sending file to the 5G message center, where the receipt message carries node information of faulty seed nodes, [0131]); and in response to determining that no open connection exists with the second client device, transmitting, with the one or more processors, data corresponding to a pull available message to the second client device (When receiving the receipt message indicating that the second node has abnormally received the group-sending file, the 5G message center directly sends the group-sending file to the second node, [0132]; a notification message including a first list and a group-sending notification from a 5G message center is received, where the first list is generated by the 5G message center according to node information of a first node, [0088]), wherein the pull available message indicates that the repackaged message is available to be pulled by the second client device (The group-sending notification is used for informing the second node to receive the group-sending file and triggering the second node to execute the pull operation, [0089]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the present application was made to have modified the RCS message of Zitnik, Haque and Kim the connectivity information of Wang to improve the capability and efficiency of the 5G message center in processing the group-sending task, thereby improving the experience of terminal device users as suggested, Wang [0041].
Regarding Claim 10, Zitnik as modified by Haque, Kim and Wang teaches the method of claim 9, further comprising: receiving, with the one or more processors and from the second client device, data corresponding to both a pull message request and the token (the second node needs to carry the random token when pulling the group-sending file from the first nodes, Wang [0066]), wherein transmitting the data corresponding to the repackaged message comprises transmitting, with the one or more processors, the data corresponding to the repackaged message to the second client device in response to receiving, from the second client device, the data corresponding to both the pull message request and the token (When requesting to pull the group-sending file from the first nodes, the second node sends a file acquisition request carrying the second random token to the first nodes, such that the first nodes compare the first random token with the second random token to determine which group-sending file the second node is to pull or determine whether the second node is allowed to pull the group-sending file, Wang [0101]).
Regarding Claim 11, Zitnik as modified by Haque, Kim and Wang teaches the method of claim 9, further comprising: receiving, with the one or more processors, data corresponding to a second message for the second client device (the second application 514 may include instructions configured to receive a non-SMS format message from the first server via a packet switched network, Kim [0088]); repackaging, with the one or more processors, a payload of the second message according to the OTT protocol at a transport layer of a repackaged second message to generate the repackaged second message (According to various embodiments, the pass converter 522 may include instructions configured to convert a non-SMS format message to an SMS format message. According to an embodiment, the pass converter 522 may include instructions configured to convert at least one piece of TPDU data received from the second application 514 into an SMS format message, Kim [0090]); and in response to determining that an open connection exists with the second client device, transmitting, with the one or more processors, data corresponding to the repackaged second message to the second client device (if the message handler 526 determines that no error has occurred, operation 1860 may be performed. The message handler 526 may provide the SMS format message to the first application, Kim [0196]).
Allowable Subject Matter
Claim 12 is 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.
Regarding claim 12, Zitnik as modified by Haque teaches the method of claim 1.
However, Zitnik and Haque alone or in combination do not teach receiving, with the one or more processors and from the second client device, data corresponding to a third message, wherein a payload of the third message is formatted in the RCS protocol and wherein the payload of the third message is packaged according to the OTT protocol at the transport layer; determining, with the one or more processors, the recipient messaging protocol for the third message; in response to determining that the recipient messaging protocol for the third message is the RCS protocol, repackaging, with the one or more processors, the payload of the third message in the RCS protocol at a transport layer of a repackaged third message to generate the repackaged second third message; and transmitting, with the one or more processors, data corresponding to the repackaged third message to the first client device.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Evans (US 11539757 B1): Methods, systems, and storage media for providing interoperability for advanced messaging features between RCS and proprietary messaging platforms are disclosed. Exemplary implementations may: register a user of a messaging platform with an external network; associate the user with an identifier of the external network; configure an adapter to receive notifications from the identifier of the external network via a subscription; and receive, via the adapter at the messaging platform, the notifications addressed to the identifier of the external network based on the subscription.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICOLE M LOUIS-FILS whose telephone number is (571)270-0671. The examiner can normally be reached Monday-Friday.
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, Charles Appiah can be reached at 571-272-7904. 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.
/NICOLE M LOUIS-FILS/ Examiner, Art Unit 2641
/CHARLES N APPIAH/Supervisory Patent Examiner, Art Unit 2641
