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 .
This action is based on the Preliminary Amendment filed on 02/29/2024.
Claims 15-24 have been canceled.
Claims 1-14 and 25-30 remain pending in the application.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 12-14, 25, 27, 28 and 30 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Stafford et al. (US 20210014182 A1).
Regarding Claim 1, Stafford teaches a method (Method 106 for automatically RCS interoperability services of Figs. 7A-B), comprising:
receiving, with one or more processors of a server device and from a first client device, data corresponding to a message, 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 (receiving an electronic message on a Rich Communication Suite (RCS) message application on a server network device with one or more processors on a first communications channel via a communications network from a first target network device with one or more processors for a second target network device with one or more processors, wherein RCS messaging includes two-way person-to-person (P2P) and application-to-person (A2P) messaging, [0178]);
determining, with the one or more processors, a recipient messaging protocol for the message (RCS message application conducts a test to determine if the second target network device can receive RCS messages, [0178]);
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 (If at Step 110, the second target network device cannot receive RCS messages, in FIG. 7B at Step 114, the electronic message is modified on an RCS message application on the server network device to include an electronic link to an RCS interoperability application on the server network device creating a modified electronic message, [0178]); and
transmitting, with the one or more processors, data corresponding to the repackaged message to a second client device (RCS message application sends the modified electronic message to the second target network device on another communications channel that does not include RCS functionality via the communications network, thereby providing RCS functionality via the RCS interoperability application on the server network device to the second network device, [0178]).
Regarding Claim 2, Stafford teaches the method of claim 1, wherein the payload of the message is formatted in the RCS protocol such that at least one of a serialization layer of the message or an encryption layer of the message is formatted in the RCS protocol (The electronic link includes a first encrypted portion including a phone number, user name, unique network identifier (e.g., Globally Unique Identifier (GUID), Universally Unique Identifier (UUID), etc.) to uniquely identify the second target network device on the communications network and a second non-encrypted portion that provides RCS functionality via the RCS interoperability application on the server network device, [0178]).
Regarding Claim 12, Stafford teaches the method of claim 1, further comprising: receiving, with the one or more processors and from the second client device, data corresponding to a third message (receiving an electronic message on a Rich Communication Suite (RCS) message application on a server network device with one or more processors on a first communications channel via a communications network from a first target network device with one or more processors for a second target network device with one or more processors, wherein RCS messaging includes two-way person-to-person (P2P) and application-to-person (A2P) messaging, [0178])), wherein a payload of the third message is formatted in a rich communication services (RCS) protocol (wherein RCS messaging includes two-way person-to-person (P2P) and application-to-person (A2P) messaging, [0178]) and wherein the payload of the third message is packaged according to the OTT protocol at the transport layer (One or more server network devices (e.g., 20, 22, 24, 26, etc.) store portions 13′, 15′ of the electronic message content 13, 15 (e.g., SMS, [0149]); determining, with the one or more processors, the recipient messaging protocol for the third message (RCS message application conducts a test to determine if the second target network device can receive RCS messages, [0178]); 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 message (If at Step 110, the second target network device cannot receive RCS messages, in FIG. 7B at Step 114, the electronic message is modified on an RCS message application on the server network device to include an electronic link to an RCS interoperability application on the server network device creating a modified electronic message, [0178]; RCS interoperability application 30b is provided as a chat bot application and/or other multimedia chat application and/or other multi-media messenger application reachable by a web browser and/or other multi-media application reachable directly from an electronic messaging application (e.g., SMS, [0196]); and transmitting, with the one or more processors, data corresponding to the repackaged third message to the first client device 9 (RCS message application sends the modified electronic message to the second target network device, [0178]; the second communications channel 25 includes a SMS communications channel, [0199]).
Regarding Claim 13, Stafford teaches a server device (e.g. RCS 30b) comprising: one or more processors; and a memory coupled to the one or more processors, the memory storing one or more programs that (network devices 12, 14, 16, etc. each with one or more processors and each with a non-transitory computer readable medium, [0035]), 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, 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 (receiving an electronic message on a Rich Communication Suite (RCS) message application on a server network device with one or more processors on a first communications channel via a communications network from a first target network device with one or more processors for a second target network device with one or more processors, wherein RCS messaging includes two-way person-to-person (P2P) and application-to-person (A2P) messaging, [0178]);
determine a recipient messaging protocol for the message (RCS message application conducts a test to determine if the second target network device can receive RCS messages, [0178]);
in response to determining that the recipient messaging protocol for the message is an over-the-top (OTT) protocol, repackage the payload of the message according to the OTT protocol at a transport layer of a repackaged message to generate the repackaged message (If at Step 110, the second target network device cannot receive RCS messages, in FIG. 7B at Step 114, the electronic message is modified on an RCS message application on the server network device to include an electronic link to an RCS interoperability application on the server network device creating a modified electronic message, [0178]); and
transmit data corresponding to the repackaged message to a second client device (RCS message application sends the modified electronic message to the second target network device on another communications channel that does not include RCS functionality via the communications network, thereby providing RCS functionality via the RCS interoperability application on the server network device to the second network device, [0178]).
Regarding Claim 14, Stafford teaches a non-transitory computer-readable storage medium storing instructions that (e.g. RCS 30b of Fig. 1), 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, 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 (receiving an electronic message on a Rich Communication Suite (RCS) message application on a server network device with one or more processors on a first communications channel via a communications network from a first target network device with one or more processors for a second target network device with one or more processors, wherein RCS messaging includes two-way person-to-person (P2P) and application-to-person (A2P) messaging, [0178]);
determine a recipient messaging protocol for the message (RCS message application conducts a test to determine if the second target network device can receive RCS messages, [0178]);
in response to determining that the recipient messaging protocol for the message is an over-the-top (OTT) protocol, repackage the payload of the message according to the OTT protocol at a transport layer of a repackaged message to generate the repackaged message (If at Step 110, the second target network device cannot receive RCS messages, in FIG. 7B at Step 114, the electronic message is modified on an RCS message application on the server network device to include an electronic link to an RCS interoperability application on the server network device creating a modified electronic message, [0178]); and
transmit data corresponding to the repackaged message to a second client device (RCS message application sends the modified electronic message to the second target network device on another communications channel that does not include RCS functionality via the communications network, thereby providing RCS functionality via the RCS interoperability application on the server network device to the second network device, [0178]).
Regarding Claim 25, Stafford teaches the server device of claim 13, wherein the payload of the message is formatted in the RCS protocol such that at least one of a serialization layer of the message or an encryption layer of the message is formatted in the RCS protocol (The electronic link includes a first encrypted portion including a phone number, user name, unique network identifier (e.g., Globally Unique Identifier (GUID), Universally Unique Identifier (UUID), etc.) to uniquely identify the second target network device on the communications network and a second non-encrypted portion that provides RCS functionality via the RCS interoperability application on the server network device, [0178]).
Regarding Claim 27, Stafford 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 (For example, in one specific embodiment, the RCS message application 30a sends a device capability request to a third-party (e.g., GOOGLE, etc.) and receives a response as to whether the second target network device 14 has access to RCS functionality, Stafford [0184]); and cache, with the one or more processors, the one or more capabilities of the second client device (RCS message application 30a maintains a list of communications networks 18, 18′ that do not support RCS functionality, Stafford [0185]).
Regarding Claim 28, Stafford teaches the non-transitory computer-readable storage medium of claim 14, wherein the payload of the message is formatted in the RCS protocol such that at least one of a serialization layer of the message or an encryption layer of the message is formatted in the RCS protocol (The electronic link includes a first encrypted portion including a phone number, user name, unique network identifier (e.g., Globally Unique Identifier (GUID), Universally Unique Identifier (UUID), etc.) to uniquely identify the second target network device on the communications network and a second non-encrypted portion that provides RCS functionality via the RCS interoperability application on the server network device, [0178]).
Regarding Claim 30, Stafford teaches the non-transitory computer-readable storage medium of claim 14, 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 (For example, in one specific embodiment, the RCS message application 30a sends a device capability request to a third-party (e.g., GOOGLE, etc.) and receives a response as to whether the second target network device 14 has access to RCS functionality, Stafford [0184]); and cache, with the one or more processors, the one or more capabilities of the second client device (RCS message application 30a maintains a list of communications networks 18, 18′ that do not support RCS functionality, Stafford [0185]).
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 3-6 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Stafford et al. (US 20210014182 A1) in view of Kim et al. (US 20200267514 A1).
Regarding Claim 3, Stafford teaches the method of claim 1.
However, Stafford does 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 Stafford 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, Stafford as modified by 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 (For example, in one specific embodiment, the RCS message application 30a sends a device capability request to a third-party (e.g., GOOGLE, etc.) and receives a response as to whether the second target network device 14 has access to RCS functionality, Stafford [0184]); and caching, with the one or more processors, the one or more capabilities of the second client device (RCS message application 30a maintains a list of communications networks 18, 18′ that do not support RCS functionality, Stafford [0185]).
Regarding Claim 5, Stafford as modified by 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 (RCS message application 30a maintains a list of target network devices (e.g., by phone number, etc.) that do not support RCS functionality. In such a specific embodiment, if the second target network device 14 is on a communications network already known not to support RCS functionality, then the test at Step 110 is skipped as it is not necessary, Stafford [0186]).
Regarding Claim 6, Stafford as modified by 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 Stafford 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, Stafford as modified by 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, Stafford teaches the server device of claim 13.
However, Stafford does 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 Stafford 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, Stafford teaches the non-transitory computer-readable storage medium of claim 14,
However, Stafford does 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 Stafford 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].
Claims 7 are rejected under 35 U.S.C. 103 as being unpatentable over Stafford et al. (US 20210014182 A1) in view of Kim et al. (US 20200267514 A1) and further in view of Ward et al. (US 20220357939 A1).
Regarding Claim 7, Stafford as modified by Kim teaches the method of claim 6.
However, Stafford 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 Stafford 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 Stafford et al. (US 20210014182 A1) in view of Kim et al. (US 20200267514 A1) and further in view of Wang et al. (US 20240298150 A1).
Regarding Claim 9, Stafford as modified by Kim teaches the method of claim 3.
However, Stafford 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 Stafford 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, Stafford as modified by 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, Stafford as modified by 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]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Haque (US 20210160103 A1): A method, a device, and a non-transitory storage medium are described in which a micro-adapter architecture for a device gateway service is provided. The micro-adapter architecture for a device gateway service may be included in a cloud native backend gateway. The cloud native backend gateway may include a set of adapters that are logically grouped in layers for providing device gateway services. The device gateway services may include an application layer, a device layer, and a transport layer. The device gateway services may include bounded contexts based on rules that define the application layer, the device layer, and the transport layer. The device gateway services may be microservices that are distributed within the defined layers.
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
Prosecution Insights