DETAILED ACTION
Claims 1-20 are pending in this application.
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 .
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 21, 22, 26, 27, 29, 30, 31, 33, 34 and 38-40 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013185016 A1 to Sun in view of U.S. Pub. No. 2023/0041924 A1 to Wittstock et al. and further in view of U.S. Pub. No. 2023/0102816 A1 to Lazim et al.
As to claim 21, Sun teaches a computer system-implemented method comprising:
in response to receiving first requests for an application from client devices (wireless client) over a network (Network 830), generating application data that includes a software development kit (SDK) incorporated in the application (data package of a wireless application integrated with an SDK permanent interface layer) (“…In 240, in the event that the acquisition request sent by the wireless client using the wireless application has been received, the server sends the interface implementation of the dynamic implementation layer from the server to the wireless client. The interface implementation of the dynamic implementation layer causes the wireless application in the wireless client to invoke, through the interface defined by the interface protocol in the permanent interface layer, the interface implementation acquired from the server, and to dynamically load the class library for the interface implementation…FIG. 10 is a structural block diagram of an embodiment of a wireless application implementing device. The device 1000 includes an acquiring module 1010 and an implementing module 1020. The wireless application implementing device 1000 can be installed on the wireless client 810 of FIG. 8…The acquiring module 1010 acquires a data package of a wireless application integrated with an SDK permanent interface layer. The implementing module 1020 uses the data package of the wireless application to run the wireless application. The SDK includes the permanent interface layer and a dynamic implementation layer. The permanent interface layer is integrated in the wireless application and includes an interface protocol to be invoked by the wireless application. The dynamic implementation layer is installed on the server and includes an interface implementation corresponding to the interface protocol…In some embodiments, the implementing module 1020 sends an acquisition request to the server. The acquisition request requests acquisition of the interface implementation of the dynamic implementation layer from the server. The wireless application receives the interface implementation of the dynamic implementation layer sent back by the server, and the wireless application uses the interface defined by the interface protocol in the permanent interface layer to invoke the interface implementation acquired from the server…” paragraphs 0041-0046/0058/0086/00106-00108);
generating tracking data that identifies the SDK and the client devices (Step 260) (“…In 260, the server confirms that an updated version of the permanent interface layer, the dynamic implementation layer, or a combination thereof exists and sends the updated version to the wireless client. The wireless client uses the updated version to update the permanent interface layer, the dynamic implementation layer, or a combination thereof of the wireless application of the wireless client…Another situation is while the wireless application is running, the wireless client sends a request to the server querying whether a new version of the SDK dynamic implementation layer exists. In the event that a new version of the SDK dynamic implementation layer exists, the wireless client downloads the new version of the SDK dynamic implementation layer, and then invokes and loads the new version of the SDK dynamic implementation layer. In the event that a new version does not exist, the wireless client finds the version of the SDK dynamic implementation layer (in other words, the original version of the dynamic implementation layer) based on the protocol (for example, based on the path and file name). For example, the original version of the dynamic implementation layer is stored in a specific directory, if successfully upgraded the new version of the dynamic implementation layer replaces the original version of the dynamic implementation layer in the specific directory…” paragraphs 0047/0058/0075-0077); and
providing the application data over the network to each of the client devices, wherein the SDK enables the application of each of the client devices to communicate with the application of another one of the client devices (data package of a wireless application integrated with an SDK permanent interface layer) (“…In 240, in the event that the acquisition request sent by the wireless client using the wireless application has been received, the server sends the interface implementation of the dynamic implementation layer from the server to the wireless client. The interface implementation of the dynamic implementation layer causes the wireless application in the wireless client to invoke, through the interface defined by the interface protocol in the permanent interface layer, the interface implementation acquired from the server, and to dynamically load the class library for the interface implementation…FIG. 10 is a structural block diagram of an embodiment of a wireless application implementing device. The device 1000 includes an acquiring module 1010 and an implementing module 1020. The wireless application implementing device 1000 can be installed on the wireless client 810 of FIG. 8…The acquiring module 1010 acquires a data package of a wireless application integrated with an SDK permanent interface layer. The implementing module 1020 uses the data package of the wireless application to run the wireless application. The SDK includes the permanent interface layer and a dynamic implementation layer. The permanent interface layer is integrated in the wireless application and includes an interface protocol to be invoked by the wireless application. The dynamic implementation layer is installed on the server and includes an interface implementation corresponding to the interface protocol…In some embodiments, the implementing module 1020 sends an acquisition request to the server. The acquisition request requests acquisition of the interface implementation of the dynamic implementation layer from the server. The wireless application receives the interface implementation of the dynamic implementation layer sent back by the server, and the wireless application uses the interface defined by the interface protocol in the permanent interface layer to invoke the interface implementation acquired from the server…” paragraphs 0041-0046/0058/00106-00108).
Sun is silent with reference to identifying a list of applications on the client devices that have the SDK based on the tracking data and
providing a message via the SDK of each application on the list of applications, wherein the message includes a notification to be displayed on each client device through each application.
Wittstock teaches identifying a list of applications on the client devices (User Computer Device A/B/N 132A/B/N) that have the SDK (SDKs 138) based on the tracking data (Depending on whether a message recipient 130 is identified as possessing a user computing device 132, applications 134, and/or SDK 136, the message recipient management engine 210 may also associate the recipientID with one or more of a device identifier, application identifier (which may be in the form of channel identifier), and SDK identifier) (“…The message recipient management engine 210 manages the message recipients 130 to whom the messages are sent. A message publisher 120 may specify a set of intended message recipients 130. A message recipient 130 may be associated with a recipient identifier, recipientID. Depending on whether a message recipient 130 is identified as possessing a user computing device 132, applications 134, and/or SDK 136, the message recipient management engine 210 may also associate the recipientID with one or more of a device identifier, application identifier (which may be in the form of channel identifier), and SDK identifier. For example, each user computing device 132 associated with the message recipient 130 may be associated with a device identifier, deviceID. For some devices, the message recipient management engine 210 may also store application identifier, applicationID, for identifying actions occurred at or related to an application 134 and track in-app messages sent through the application 134. A set of recipientIDs, deviceIDs, and applicationIDs may be associated with a publisherID...” paragraph 00047).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Sun with the teaching of Wittstock because the teaching of Wittstock would improve the system of Sun by providing a technique for tracking user device that requested downloads so that the downloads are appropriated sent to the user device.
Lazim teaches providing a message via the SDK (client application 133 can also incorporate an SDK library) of each application on the list of applications, wherein the message includes a notification to be displayed (figures 2/3) on each client device through each application (Automatic Updating of Application Functionality---Notification/“…Therefore, examples of the disclosure can provide a mechanism to update features within an SDK library utilized by an application without requiring the application developer to update the application. Devices that are enrolled as managed devices with a management service can be provided an updated version of an application with updated SDK libraries without any intervention on behalf of the end-user…In the scenario of FIG. 2, the user can select a feature 201 within the application. Continuing the scenario of FIG. 2, reference is now made to FIG. 3. In FIG. 3, the client application 133 can invoke user authentication capabilities provided by the SDK library in response to the user selecting the feature 201. The SDK library can implement an authentication workflow 302 that performs user authentication on behalf of the client application 133. The authentication workflow 302 can be periodically updated by the SDK library…The authentication workflow 302 can communicate with a single sign-on platform or an identity manager utilizing a single sign-on protocol. The single sign-on protocol may be updated from time to time, which can require the SDK library to be updated. Accordingly, in examples of the disclosure, the SDK library can be updated without requiring the application developer to update the client application 133. Instead, the update repository service 122 and the SDK injection service 124 can update the client application 133, and the application monitoring service 126 can monitor the performance of the client application 133 after updating the SDK library in the event that the update impairs performance of the client application 133…” paragraphs 0012/0021/0022/0048/0049).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Sun and Wittstock with the teaching of Lazim because the teaching of Lazim would improve the system of Sun and Wittstock by providing automatic software updates to varying number of clients.
As to claim 22, Sun teaches the computer system-implemented method of claim 21, further comprises identifying the one or more SDKs based on an operating system of the client device transmitted the first request (depend on the operating system (OS) of the client terminal/Android) (“…In some embodiments, the publish and install operations depend on the operating system (OS) of the client terminal. For example, in an Android app, the Android app will package the dynamic implementation layer of the SDK in the application package file (APK)…” paragraph 0028).
As to claim 26, Witstock teaches the computer system-implemented method of claim 21, wherein the tracking data comprises a user identifier, a client device identifier, an application identifier, and the SDK for the application (Depending on whether a message recipient 130 is identified as possessing a user computing device 132, applications 134, and/or SDK 136, the message recipient management engine 210 may also associate the recipientID with one or more of a device identifier, application identifier (which may be in the form of channel identifier), and SDK identifier) (“…The message recipient management engine 210 manages the message recipients 130 to whom the messages are sent. A message publisher 120 may specify a set of intended message recipients 130. A message recipient 130 may be associated with a recipient identifier, recipientID. Depending on whether a message recipient 130 is identified as possessing a user computing device 132, applications 134, and/or SDK 136, the message recipient management engine 210 may also associate the recipientID with one or more of a device identifier, application identifier (which may be in the form of channel identifier), and SDK identifier. For example, each user computing device 132 associated with the message recipient 130 may be associated with a device identifier, deviceID. For some devices, the message recipient management engine 210 may also store application identifier, applicationID, for identifying actions occurred at or related to an application 134 and track in-app messages sent through the application 134. A set of recipientIDs, deviceIDs, and applicationIDs may be associated with a publisherID...” paragraph 00047).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Sun and Lazim with the teaching of Wittstock because the teaching of Wittstock would improve the system of Sun and Lazim by providing a technique for tracking user device that requested downloads so that the downloads are appropriated sent to the user device.
As to claim 27, Wittstock teaches the computer system-implemented method of claim 21, further comprises providing the message to each of the SDK of each application on each client devices (“…The message management server 110 may transmit messages to message recipients 130 via different channels 150. A channel 150 may be associated with a communication protocol or another non-standard method. A channel 150 may also be referred to as a communication channel Examples of channels 150 include text messaging services (e.g., SMS, MMS), emails (e.g., mobile emails, plain text emails, browser emails), push notification protocols (e.g., APPLE push notification, ANDROID push notification), instant messaging applications (WHATSAPP, WECHAT, TELEGRAM), in-application messages (e.g., messages sent within application 134), social networking systems (e.g., FACEBOOK, TWITTER), RSS feeds, web browser notifications, other suitable protocols such as simply message payloads sent as an Internet packet or a series of packets. The message management server 110 may decide that a message is to be transmitted through one or more channels based on the setting provided by the message publisher 120. The details of the selection of channels will be discussed in further detail below with reference to FIGS. 2 and 3…Additionally, or alternatively, the SDK 136 may receive notifications messages from the message management server 110 through one or more channels external to the application 136 (e.g., a push notification, an email, a text message, etc.) including a deep link to an in-app preference center UI. Embodiments of operations performed by the SDK 136 for rendering in-app preference center UIs are described in greater detail below with reference to FIG. 5…” Col. 9 Ln. 26-45, Col. 14 Ln. 55-63).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Sun and Lazim with the teaching of Wittstock because the teaching of Wittstock would improve the system of Sun and Lazim by providing a technique for tracking user device that requested downloads so that the downloads are appropriated sent to the user device.
As to claim 29, Wittstock teaches the computer system-implemented method of claim 21, further comprises generating a message (push notification protocols /SDK 136 may receive notifications messages from the message management server 110…a text message) to provide to each application on the list of applications (Applications 134) such that each application shares a similar backend server (Message Management Server 110) to enable communications between different applications of similar and different client devices (User Computing Device 132A/B/N) (“…The message management server 110 may transmit messages to message recipients 130 via different channels 150. A channel 150 may be associated with a communication protocol or another non-standard method. A channel 150 may also be referred to as a communication channel Examples of channels 150 include text messaging services (e.g., SMS, MMS), emails (e.g., mobile emails, plain text emails, browser emails), push notification protocols (e.g., APPLE push notification, ANDROID push notification), instant messaging applications (WHATSAPP, WECHAT, TELEGRAM), in-application messages (e.g., messages sent within application 134), social networking systems (e.g., FACEBOOK, TWITTER), RSS feeds, web browser notifications, other suitable protocols such as simply message payloads sent as an Internet packet or a series of packets. The message management server 110 may decide that a message is to be transmitted through one or more channels based on the setting provided by the message publisher 120. The details of the selection of channels will be discussed in further detail below with reference to FIGS. 2 and 3…Additionally, or alternatively, the SDK 136 may receive notifications messages from the message management server 110 through one or more channels external to the application 136 (e.g., a push notification, an email, a text message, etc.) including a deep link to an in-app preference center UI. Embodiments of operations performed by the SDK 136 for rendering in-app preference center UIs are described in greater detail below with reference to FIG. 5…” Col. 9 Ln. 26-45, Col. 14 Ln. 55-63).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Sun and Lazim with the teaching of Wittstock because the teaching of Wittstock would improve the system of Sun and Lazim by providing a technique for push notification using varying messaging formats.
As to claim 30, Wittstock teaches the computer system-implemented method of claim 21, further comprises generating the message to provide to each application on the list of applications to be displayed at a future date and future time (trigger condition for a message may be time-based/The event-based trigger condition may also include a time element such as a delay after the event condition is met) (“…The trigger conditions and channels 150 to be used for each message in the series are rules that are specified by a message publisher 120 indicating conditions for how or when a message will be provided to a user via one of the channels 150. For example, a trigger condition for a message may define conditions that to be met for the message to be transmitted by the message management server 110 via a channel of the channels 150. As another example, a trigger condition for a message may define conditions to be met for the SDK 136 to provide a message to a user of the user computing device 132, such as by displaying an in-app UI or UI element. The trigger condition for a message may be time-based. For example, a second message may be sent 2 days after the first message is sent. The trigger condition for a message may also be event-based, such as when the message management server 110 receives a mobile event notification that matches the trigger condition. The event-based trigger condition may also include a time element such as a delay after the event condition is met. Other trigger conditions discussed in this disclosure are also possible. For each message, a message publisher 120 may also select a channel selection rule based on the discussion above with reference to the orchestration strategy management engine 220…” Col. 17 Ln.7-31, Col. 21 Ln. 43-51).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Sun and Lazim with the teaching of Wittstock because the teaching of Wittstock would improve the system of Sun and Lazim by providing a technique for allowing the client/user to select a preferred date and/or time to push a notification.
As to claim 31, Wittstock teaches the computer system-implemented method of claim 21, further comprises: a user interface that displays (in-app UI elements) (i) the list of applications that incorporates the one or more SDKs (SDKs 136) on each client device (User Computing Device A 132A/B/N), (ii) a number of requests transmitted and received from each of the one or more SDKs on each application of each client device, and (iii) a type of each SDKs ((SDKs 136) (“…In some embodiments, the SDK 136 maintains a set of active in-app UI elements intended for display in the application 134 in response to mobile event-related trigger conditions being met. The SDK 136 may receive in-app UI element messages from the message management server 110 including configuration data for active in-app UI elements including one or more trigger conditions from the message management server 110. In this case, the SDK 136 may update the set of active in-app UI elements based on the received configuration data and/or configure listeners for mobile event notifications corresponding to the one or more trigger conditions. If the SDK 136 determines that the one or more trigger conditions are met, the SDK 136 may communicate with the one or both of the application 134 or the message management server 110 in order to render the in-app UI element for display in the application 134. Embodiments of operations performed by the SDK 136 for rendering in-app UI elements are described in greater detail below with reference to FIG. 4…In some embodiments, the SDK 136 maintains in-app dynamic preference center UIs for display in the application 134. Similarly to active in-app UI elements described above, the SDK 136 may receive configurations for in-app preference center UIs from the message management server 110. Preference center UI configurations describe in-app UI elements that facilitate user configuration of various user preferences (e.g., app settings). Preferences may correspond to user preferences for operations performed by the message management server 110, such as what types or through what channels a user computing device 132 or application 134 receives from the message management server 110. Additionally, or alternatively, preferences may correspond to user preferences for the application 134. The SDK 136 may embed a mechanism for navigating to an in-app preference center UI corresponding to a preference center UI message received from the message management server 110, such as a button or other interactable UI element. Additionally, or alternatively, the SDK 136 may receive notifications messages from the message management server 110 through one or more channels external to the application 136 (e.g., a push notification, an email, a text message, etc.) including a deep link to an in-app preference center UI. Embodiments of operations performed by the SDK 136 for rendering in-app preference center UIs are described in greater detail below with reference to FIG. 5…” Col. 14 Ln. 19-63).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Sun and Lazim with the teaching of Wittstock because the teaching of Wittstock would improve the system of Sun and Lazim by providing a graphical user interface for receiving push notification.
As to claims 33 and 40, see the rejection of claim 1 above, expect for a non-transitory computer-readable medium, processors and one or more storage devices.
Sun teaches a non-transitory computer-readable medium (Computer Readable Storage Medium), processors (Wireless Clients 910/1110) and one or more storage devices (Memory).
As to claim 34, see rejection of claim 22 above.
As to claim 38, see the rejection of claim 26 above.
As to claim 39, see the rejection of claim 27 above.
Claims 23 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013185016 A1 to Sun in view of U.S. Pub. No. 2023/0041924 A1 to Wittstock et al. and further in view of and further in view of U.S. Pub. No. 2023/0102816 A1 to Lazim et al. as applied to claims 21 and 13 above, and further in view of U.S. Pub. No. 2018/0181482 A1 to Cattan et al.
As to claim 23, Sun as modified by Wittstock and Lazim teaches the computer system-implemented method of claim 21, however it is silent with reference to in response to determining that the second application of a second client device includes the SDKs, providing, by the one or more processors, an indication to the first application of a first client device that enables the first application to communicate with the second application, wherein the first application include the SDK.
Cattan teaches in response to determining that the second application of a second client device includes the SDKs, providing, by the one or more processors, an indication to the first application of a first client device that enables the first application to communicate with the second application, wherein the first application include the SDK (invokes/call/callback) (“…Additionally or alternatively, the stack trace may be analyzed in a LIFO order until reaching a first SDK execution unit, or until reaching the end of the stack. Additionally or alternatively, the stack trace may be analyzed in LIFO order from top to bottom, identifying each SDK execution unit in the stack trace. In some cases, more than a single SDK may be identified in the stack trace. Such may be the case if one SDK invokes another SDK. As an example, if a first SDK initiates a call to a second SDK, the call stack trace may comprise an execution unit of the second SDK in a higher location than the execution unit of the first SDK. The higher execution unit may be deemed as the SDK responsible for the activity monitored. However, such may not always be the case. For example, a first SDK may swizzle network calls, and therefore a network call which was initiated by a second SDK may appear in the stack trace as associated with the first SDK. In the stack trace, the execution unit of the first SDK may appear in a higher location than the execution unit of the second SDK. However, the SDK responsible for the activity (e.g., the network call) is the second SDK. As another example, a first SDK may call a callback function of an app, and the app may invoke a second SDK. The highest SDK on the stack will be the first SDK. However, the SDK responsible for the activity, is the second SDK. In some exemplary embodiments, by analyzing the SDK execution units and their relation it may be determined whether the last execution unit (i.e., highest in the stack) is the one responsible for the activity or another SDK due to the use of swizziling mechanism, callbacks, or the like.…” paragraph 0038).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of SU, Wittstock and Lazim with the teaching of Cattan because the teaching of Cattan would improve the system of SU, Wittstock and Lazim by providing a inter-process component for allowing communication between at least two software components.
As to claim 35, see the rejection of claim 23 above.
Claims 24, 25, 36 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013185016 A1 to Sun in view of U.S. Pub. No. 2023/0041924 A1 to Wittstock et al. and further in view of U.S. Pub. No. 2023/0102816 A1 to Lazim et al. as applied to claims 21 and 13 above, and further in view of U.S. Pub. No. 2019/0044928 A1 to Kaipu et al.
As to claim 24, Sun as modified by Wittstock and Lazim teaches the computer system-implemented method of claim 21, however it is silent with reference to in response to determining that the second application of the second client device does not include the one or more SDKs, providing an indication to the first application that precludes the first application of a first client device that precludes the first application from communicating with the second application.
Kaipu teaches in response to determining that the second application of the second client device does not include the one or more SDKs, providing an indication to the first application that precludes the first application of a first client device that precludes the first application from communicating with the second application (a communication key that can indicate that the first application 126a is authorized to request the search) (“…To request the search components 139b-139c to perform the search, the search requester 146a can generate messages for the second application 126b and the third application 126c that make the requests. In particular, the messages for the second application 126b and the third application 126c can include payload data that represents the search query input by the user, the identity of the first application 126a, a communication key that can indicate that the first application 126a is authorized to request the search, the time the search is being requested, and the number of times the search has been requested by the first application 126a. After the search requester 146a has generated the messages, the search requester 146a can provide the generated messages to the second search component 139b and the third search component 139c, respectively, using an interprocess communication service provided by the operating system of the client device 106…When the second application 126b receives the message from the search requester 146a, the second application 126b can extract the payload data and parse the contents of the payload data. In some examples, the second application 126b can determine whether the received message includes a communication key indicating that the first application 126a is authorized to communicate with the second application 126b and request the second application 126b to perform searches. In various embodiments, the second application 126b can compare the received communication key with a stored value to determine whether the communication key is authentic. In other examples, the second application 126b can request the management service 113 to determine whether the received communication key is authentic. If the communication key is not authentic, or if no communication key was received in the message, the second application 126b can conclude that the message is from an unauthorized application and discard the message…” paragraphs 0040/0042).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of SU, Wittstock and Lazim with the teaching of Kaipu because the teaching of Kaipu would improve the system of SU, Wittstock and Lazim by providing authorization process for allowing or disallowing communication between different application.
As to claim 25, Sun as modified by Wittstock and Lazim teaches the computer system-implemented method of claim 21, however it is silent with reference to in response to determining that the second application of a first client device includes the SDK, providing an indication to the first application that enables the first application of the first client device that enables the first application to communicate with the second application on the second client device, wherein the first application includes the SDK.
Kaipu teaches in response to determining that the second application of a first client device includes the SDK, providing an indication to the first application that enables the first application of the first client device that enables the first application to communicate with the second application on the second client device, wherein the first application includes the SDK (a communication key that can indicate that the first application 126a is authorized to request the search) (“…To request the search components 139b-139c to perform the search, the search requester 146a can generate messages for the second application 126b and the third application 126c that make the requests. In particular, the messages for the second application 126b and the third application 126c can include payload data that represents the search query input by the user, the identity of the first application 126a, a communication key that can indicate that the first application 126a is authorized to request the search, the time the search is being requested, and the number of times the search has been requested by the first application 126a. After the search requester 146a has generated the messages, the search requester 146a can provide the generated messages to the second search component 139b and the third search component 139c, respectively, using an interprocess communication service provided by the operating system of the client device 106…When the second application 126b receives the message from the search requester 146a, the second application 126b can extract the payload data and parse the contents of the payload data. In some examples, the second application 126b can determine whether the received message includes a communication key indicating that the first application 126a is authorized to communicate with the second application 126b and request the second application 126b to perform searches. In various embodiments, the second application 126b can compare the received communication key with a stored value to determine whether the communication key is authentic. In other examples, the second application 126b can request the management service 113 to determine whether the received communication key is authentic. If the communication key is not authentic, or if no communication key was received in the message, the second application 126b can conclude that the message is from an unauthorized application and discard the message…” paragraphs 0040/0042).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Sun, Wittstock and Lazim with the teaching of Kaipu because the teaching of Kaipu would improve the system of Sun, Wittstock and Lazim by providing authorization process for allowing or disallowing communication between different application.
As to claim 36, see the rejection of claim 24 above.
As to claim 37, see the rejection of claim 25 above.
Claims 28 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2013185016 A1 to Sun in view of U.S. Pub. No. 2023/0041924 A1 to Wittstock et al. and further in view of U.S. Pub. No. 2023/0102816 A1 to Lazim et al. as applied to claims 21 and 33 above, and further in view of U.S. Pat. No. 7,200,390 B1 issued to Henager et al.
As to claim 28, Sun as modified by Wittstock and Lazim teaches the computer system-implemented method of claim 21, however it is silent with reference to providing the message to each SDK of each application on each client devices when the client device is power off.
Henager teaches the providing the message (push notification message) to each SDK of each application on each client devices when the client device is power off (wake up) (“… The data client wakes up the update client, in response to a notification from a download server…The various software downloading techniques and systems disclosed herein rely on an update client for downloading software updates, sometimes referred to as a device software update or `DSU` client. In the mobile station, this client interfaces to and interacts through a native data communication client, such as an SMS client, a WAP client, an MMS client or a proprietary data client. In a download operation, a server sends a push notification to the data client, which wake up the downloading client. The downloading client interacts with the server, for example, to identify an application to enable a comparison of current firmware in the station against available updates loaded on the server. The server does not need to be pre-provisioned with information as to the software or firmware in the mobile station, as this data can be provided by the update client…” Abstract, Col. 5 Ln. 66-67, Col. 6 Ln. 1-11).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of SU, Wittstock and Lazim with the teaching of Henager because the teaching of Henager would improve the system of SU, Wittstock and Lazim by providing a notification service that notifies clients of software updates when the clients are offline and therefore allowing for computing resource conservation.
As to claim 32, Sun as modified by Wttstock and Lazim teaches the computer system-implemented method of claim 21, however it is silent with reference to enabling a user of the one or more client devices to receive a notification of the message when the one or more of the client devices are power on.
Henager teaches enabling a user of the one or more client devices to receive a notification of the message (push notification message) when the one or more of the client devices are power on (a server sends a push notification to the data client, which wake up the downloading client) (“… The data client wakes up the update client, in response to a notification from a download server…The various software downloading techniques and systems disclosed herein rely on an update client for downloading software updates, sometimes referred to as a device software update or `DSU` client. In the mobile station, this client interfaces to and interacts through a native data communication client, such as an SMS client, a WAP client, an MMS client or a proprietary data client. In a download operation, a server sends a push notification to the data client, which wake up the downloading client. The downloading client interacts with the server, for example, to identify an application to enable a comparison of current firmware in the station against available updates loaded on the server. The server does not need to be pre-provisioned with information as to the software or firmware in the mobile station, as this data can be provided by the update client…” Abstract, Col. 5 Ln. 66-67, Col. 6 Ln. 1-11).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of SU, Wittstock and Lazim with the teaching of Henager because the teaching of Henager would improve the system of SU, Wittstock and Lazim by providing a notification service that notifies clients of software updates when the clients are offline and therefore allowing for computing resource conservation.
As to claim 32, see the rejection of claim 28 above.
Response to Arguments
Applicant’s arguments with respect to claims 21-40 have been considered but are moot because the new ground of rejection relied on additional reference not applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
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 CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
