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 responsive to communication received 07/22/2026. Claims 1-5 and 7-21 are pending and stand as previously presented.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 1 is rejected under 35 U.S.C. 102a1a2 as being anticipated by Avetisov US 2021/044976.
As indicated in the international search report dated 02/04/2026 provided by the applicant in IDS filed 04/20/2026. The examiner hereby incorporates the rejection as presented in the search report.
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-5, 7-13, 15, and 17-21 are rejected under 35 U.S.C. 103 as being unpatentable over Vetter US 2016/0295551, and further in view of Enderwick US 8,918,860.
Regarding claim 1, Vetter teaches a method for managing data performed by a data access service system comprising a processor and a non-transitory computer-readable storage medium storing instructions that, when executed by the processor, cause the data access service system to perform the method, the method comprising: receiving, by the data access service system(private network service) from a querying system(client device/mobile device), a first data access request, the first data access request comprising first identification information and an indication of a first data managed by the data access service system(user client device is authenticated and given authentication token, the client sends the token to access a secured asset via the server to gain access to data , ¶s13, 55)
[0013] The notification event server periodically receives an authorization token from the user's physical device (which is disconnected from the virtual device). When the authorization token is received, the notification event server examines the token to find information that identifies, for example, the user, a group associated with the user, and a location of the physical device. Based on the identification of the user and/or group, the notification event server identifies notifications in the event store that are associated with the user. These notifications are retrieved by the server from the event store. The notification event server also determines, based on the information identified in the authorization token, which of the filters in the filter store are applicable to the notifications. This determination may be based on an identifier of the user or group, an indication of the location of the physical device, the type of notifications that have been retrieved for the user, or other relevant information. The selected filters are then retrieved from the filter store and are applied to the retrieved notifications to produce filtered notification information. The filtered notification information excludes sensitive information as determined by the selected filters. The notification event server then provides the filtered notification information to the physical device.
issuing, by the data access service system, a first access authorization query to an identity and access management service(authentication servers, ¶55), the first access authorization query comprising the first identification information(i.e auth token) and the indication of the first data set(client request for data such as notifications including email data and other notification data where the token grants rights to access content/notifications and specifies filters/rules for what data be accessed and what filters i.e. restrictions are applied based context of the devices, ¶s55, 109,111 124 )
[0055] In some embodiments, authentication servers 361 may be configured to provide authentication and session management services. For example, when a user (via a VC client application running on a mobile device that the user is using) attempts to access an enterprise application, authentication server 361 may connect to one or more directory servers (e.g., active directory 309) to authenticate the user's access to virtual device(s) where the enterprise application can be run and to provision the user with one or more virtual devices. After the user authenticates, authentication server 361 may direct virtual device manager 355 to locate a device server that will host the user's virtual device 359. In some embodiments, it may ensure that virtual device 359 is “powered on” as well as initiate the initial session negotiation (via establishment of security tokens) between the mobile device running the VC client application and virtual device 359.
[0109] These and other virtual drivers support remote access for applications 660 running on application frameworks 650 in the virtual device. Operation of the virtual device, including processes associated with applications 660, as well as user behaviors can be monitored via various components in application frameworks 650 (e.g., resource manager 651, location manger 653, agent 655, notification manager 657, activity manager 659, content providers 661, telephony manager 663, package manager 665, window manager 667, system view 669, Extensible Messaging and Presence Protocol (XMPP) communications service 671, etc.), some of which will be further described below.
[0111] As noted above, embodiments of the invention may include mechanisms to enable notifications that are originated by applications executing on a virtual device to be provided to a physical mobile device that is disconnected from the virtual device. In one embodiment, a notification server is provided in order to implement a publisher/subscriber model for delivering notifications from producers to consumers. In the context of the systems described above for hosting virtual devices, the virtual device is the publisher and the corresponding physical device is the subscriber. The physical device can subscribe to multiple types of notifications or other events, possibly even from multiple virtual devices. It should be noted that this model can be used to deliver notifications and information regarding other noteworthy events from various virtual devices or services within these devices to other types of clients as well, such as management tools, infrastructure monitoring services, or security services.
[0124] Data items such as the user ID and group identifier are used by client subscriber 950 to determine who the client device is associated with and, consequently, which of the notifications should be retrieved from event store 930. Once the notifications are retrieved from event store 930, they will need to be processed by one or more of the filters (e.g., 942) that are maintained in filter store 940. The selection of appropriate filters may be based on one or more of the data items from the authorization token, including the user ID, group identifier, location, and device type. Client subscriber 950 processes the retrieved notifications using the selected filters to produce notification information that can be transmitted from the client subscriber (which lies within a private domain) back to the client device (which is outside the private domain) without allowing sensitive information to escape the private network. “Sensitive” is used here to describe information that an administrator does not wish to have communicated beyond the boundaries of the private network. The definition of sensitive information may therefore vary from one system to another and is set by the administrators of the respective systems.
receiving, from the identity and access management service in response to the first access authorization query, a response validating the first identification information and providing at least one first restriction associated with access to a subset of the first data set based on a requesting execution environment (client request for data processed according to auth token which specifies the filters appropriate to the user when such a client is accessing as secured network as secure/trusted client, ¶36, 55,66 124 token received from authentication servers)
[0036] As illustrated in FIG. 1, embodiments disclosed herein can allow a user of mobile device 110 in network environment 100 to switch between using public network services 130 and using private network services 140. In particular, the user may access public network services 130 via public network 120 such as the Internet over which non-sensitive information may be communicated. However, to access private network services 140, a virtualization cloud client application (referred to hereinafter as a “VC client application”) running on mobile device 110 connects to a virtualized device (e.g., virtual device 160A) hosted in virtualization cloud 150 and brokers access to private network services 140 as well as local device functions.
[0066] Management domain 410 may comprise a plurality of virtual devices 459X, 459Y, 459Z implemented using OpenStack infrastructure 470A on Trusted Platform Module (TPM)-based attestation 460A. Each of the plurality of virtual devices 459X, 459Y, and 459Z may include an agent of management network 450 (e.g., agents 495X, 495Y, 495Z, respectively). In some embodiments, the agent may be referred to as a mobile device management and mobile application management (MDM/MAM) agent. In this example, management domain 410 may further comprise VPN service 456A and storage service 458A.
[0124] Data items such as the user ID and group identifier are used by client subscriber 950 to determine who the client device is associated with and, consequently, which of the notifications should be retrieved from event store 930. Once the notifications are retrieved from event store 930, they will need to be processed by one or more of the filters (e.g., 942) that are maintained in filter store 940. The selection of appropriate filters may be based on one or more of the data items from the authorization token, including the user ID, group identifier, location, and device type. Client subscriber 950 processes the retrieved notifications using the selected filters to produce notification information that can be transmitted from the client subscriber (which lies within a private domain) back to the client device (which is outside the private domain) without allowing sensitive information to escape the private network. “Sensitive” is used here to describe information that an administrator does not wish to have communicated beyond the boundaries of the private network. The definition of sensitive information may therefore vary from one system to another and is set by the administrators of the respective systems.
determining that the subset of the first data set may be transmitted to the querying system based on the identified execution environment and the at least one first restriction(rules on what content can be transmitted are associated with auth token which identifiers the user and rules for accessing content, ¶s118,119,124)
filtering the first data set to generate the subset of the first data set(token specified filters to be applied to data transmitted to client device, ¶s 118,119)
[0118] Notification server 840 is configured to “scrub” or “sanitize” the notification information that is received from virtual device 805 (via spice server 830), and to provide notifications to the user (via physical mobile device 820) that do not contain sensitive information that is intended to be retained within private network 802. Notification server 840 accomplishes this by selecting appropriate filters from filter store 848 based on information associated with the physical device connected to the event server, applying these filters to the notifications in event store 846 and providing the resulting notification information to the physical device via client interface 844. In one embodiment, physical mobile device 820 executes a client application 822 which includes a notification service 826. The notification service is configured to execute a special service thread that pulls notifications from client interface 844 of the notification server. Physical device 820 must authenticate itself to notification server 840 to ensure that notification service 826 can pull the notifications that are associated with the physical device, and with virtual device 805. The scrubbing occurs after the physical device connects and authenticates.
[0119] The embodiment of FIG. 8 utilizes a separate server to filter and deliver notifications and event information to the physical device in order to facilitate interactions with devices that may or may not be connected to the private network. The centralization of the notifications and event information in this server may also make this information more manageable and accessible. This configuration enables the use of a centralized interface that eliminates the need for a management tool that has to separately connect to every virtual device to capture notification and event information. Additionally, since some event information is not generated by the virtual device itself, this information can bypass the virtual device entirely, making the system more efficient. For example, a “BIFF”-type email monitoring service can be implemented to notify the user (via the physical device) that new emails are available, even when the virtual device is not executing.
[0124] Data items such as the user ID and group identifier are used by client subscriber 950 to determine who the client device is associated with and, consequently, which of the notifications should be retrieved from event store 930. Once the notifications are retrieved from event store 930, they will need to be processed by one or more of the filters (e.g., 942) that are maintained in filter store 940. The selection of appropriate filters may be based on one or more of the data items from the authorization token, including the user ID, group identifier, location, and device type. Client subscriber 950 processes the retrieved notifications using the selected filters to produce notification information that can be transmitted from the client subscriber (which lies within a private domain) back to the client device (which is outside the private domain) without allowing sensitive information to escape the private network. “Sensitive” is used here to describe information that an administrator does not wish to have communicated beyond the boundaries of the private network. The definition of sensitive information may therefore vary from one system to another and is set by the administrators of the respective systems.
and transmitting the subset of the first data the querying system based on the determination(application data such as notifications are restricted abased on filters specified for user in token, ¶112)
[0112] Referring to FIG. 7, a flow diagram illustrating one embodiment of a method for providing notifications in such a scenario is shown. In this embodiment, one or more virtual devices are executed on a host server (702). The host server provides a private network environment that is secure and requires authorization in order to allow physical mobile devices to access the network. On each of these virtual devices, a notification manager is executed. The notification manager executing on each of the virtual devices receives notification information from various applications that are also executing on the virtual device (704). The notification information is forwarded to a notification server (706), where it is stored until a client mobile device can connect to the server. After the client mobile device connects to the event server, the notification information is filtered according to applicable rules in order to remove sensitive information (e.g., confidential, proprietary, or other defined types of secure information) that is not authorized to be communicated out of the private network (708). The particular type of filtering that is applied to the notification information (and the type of information that is filtered out of the notifications) is determined in response to the client mobile device connecting to the server, and may be dependent upon a number of factors, such as the identity of the mobile device's user and the location from which the private network is being accessed. After the sensitive information has been filtered out of the notifications, all or part of the notifications may be communicated to the mobile device (710).
Vetter teaches restrictions based on identifying client is as sandboxed secure application client based on a secure connection ( ¶69, 114) but does not teach identifying ports and thus does not teach identifying an execution environment of the querying system associated with the first data access request based on identifying which port of a plurality of ports of the data access service system the first data access request was received over. Enderwick in the same field of endeavor as the invention teaches a system for managing application data access. Enderwick teaches identifying an execution environment of the querying system associated with the first data access request based on identifying which port of a plurality of ports of the data access service system the first data access request was received over(verify that data is being access from a trusted application based on port on which request was made, Col 5 Lines 34-51)
[(21) In some embodiments, the secure link module 120-a may be configured to associate a specific data port with the VPN. Thus, the secure link module 120-a may allow a transmission of data through the associated data port (e.g., a source or destination port) For example an operating system may associate the data port with an application, whereby the application may assert that it is associated with the data port. The secure link module 120-a may identify a data packet received from the associated data port as data sent between a trusted application, such as the second application 130, and a server 105.
(22) In one embodiment, the secure link module 120-a may determine that the first application 125 is an untrusted application. Upon determining the first application 125 on a client 115 is an untrusted application, the blocking module 205 may be configured to continue to block a transmission of at least a portion of data between the untrusted application and a server 105., Col 5 Lines 34-51]
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Vetter’s more simple reliance on an authentication token itself being proof of connection with a secure application with verification of the port upon which a request is made. The reason for this modification would be to provide additional criteria to verify that requested are from a trusted client, resulting in more secure data release.
Regarding claim 2, Vetter teaches wherein the execution environment comprises an open execution environment(client device may access data as public access network, ¶36)
[0036] As illustrated in FIG. 1, embodiments disclosed herein can allow a user of mobile device 110 in network environment 100 to switch between using public network services 130 and using private network services 140. In particular, the user may access public network services 130 via public network 120 such as the Internet over which non-sensitive information may be communicated. However, to access private network services 140, a virtualization cloud client application (referred to hereinafter as a “VC client application”) running on mobile device 110 connects to a virtualized device (e.g., virtual device 160A) hosted in virtualization cloud 150 and brokers access to private network services 140 as well as local device functions.
Regarding claim 3, Vetter teaches wherein the identified port of the plurality of ports comprises a public port of the data access service system(client may access via unsecure public network over standard internet ports, ¶36),
[0036] As illustrated in FIG. 1, embodiments disclosed herein can allow a user of mobile device 110 in network environment 100 to switch between using public network services 130 and using private network services 140. In particular, the user may access public network services 130 via public network 120 such as the Internet over which non-sensitive information may be communicated. However, to access private network services 140, a virtualization cloud client application (referred to hereinafter as a “VC client application”) running on mobile device 110 connects to a virtualized device (e.g., virtual device 160A) hosted in virtualization cloud 150 and brokers access to private network services 140 as well as local device functions.
Regarding claim 4, Vetter teaches wherein the execution environment comprises a secure execution environment(vc client application acts as broker to establish a trusted platform module(TPM) connection using VPN, ¶41,66)
[0041] In one embodiment, a VC client application may comprise software that brokers access to mobile devices' physical interfaces (e.g., soft and hard keyboards, touchscreen, GPS, camera, accelerometer, speakers, microphone, phone dialer, etc.) and Virtual Private Network (VPN) software that connects across a public network such as the Internet to servers in a virtualization cloud (e.g., virtualization cloud 150 of FIG. 1) over encrypted network interfaces. Virtualization cloud 250 may be an embodiment of virtualization cloud 150 described above with reference to FIG. 1.
[0066] Management domain 410 may comprise a plurality of virtual devices 459X, 459Y, 459Z implemented using OpenStack infrastructure 470A on Trusted Platform Module (TPM)-based attestation 460A. Each of the plurality of virtual devices 459X, 459Y, and 459Z may include an agent of management network 450 (e.g., agents 495X, 495Y, 495Z, respectively). In some embodiments, the agent may be referred to as a mobile device management and mobile application management (MDM/MAM) agent. In this example, management domain 410 may further comprise VPN service 456A and storage service 458A.
Regarding claim 5, Vetter teaches wherein the identified port of the plurality of ports comprises a private port of the data access service system associated with requests originating from protected environments(token indicates a secure connection(i.e. VPN) has been established this client request is from secure private environment, ¶115)
[0115] The term “authorization token” is used herein to refer to any such information that is used to authenticate either a device or a user to a private network. It should also be noted that the term user may be used to refer to a person using a physical device to access the private network, or to the device itself when discussing the authentication of the user to the system.
Regarding claim 7, Vetter teaches wherein the first identification information comprises identification information associated with a user of the querying system(token contains user identification information and filters/rules for access, ¶124).
[0124] Data items such as the user ID and group identifier are used by client subscriber 950 to determine who the client device is associated with and, consequently, which of the notifications should be retrieved from event store 930. Once the notifications are retrieved from event store 930, they will need to be processed by one or more of the filters (e.g., 942) that are maintained in filter store 940. The selection of appropriate filters may be based on one or more of the data items from the authorization token, including the user ID, group identifier, location, and device type. Client subscriber 950 processes the retrieved notifications using the selected filters to produce notification information that can be transmitted from the client subscriber (which lies within a private domain) back to the client device (which is outside the private domain) without allowing sensitive information to escape the private network. “Sensitive” is used here to describe information that an administrator does not wish to have communicated beyond the boundaries of the private network. The definition of sensitive information may therefore vary from one system to another and is set by the administrators of the respective systems.
Regarding claim 8, Vetter teaches wherein the first identification information comprises identification information associated with a program executing on the querying system(VC client application implements a TPM based connection access, ¶41)
[0041] In one embodiment, a VC client application may comprise software that brokers access to mobile devices' physical interfaces (e.g., soft and hard keyboards, touchscreen, GPS, camera, accelerometer, speakers, microphone, phone dialer, etc.) and Virtual Private Network (VPN) software that connects across a public network such as the Internet to servers in a virtualization cloud (e.g., virtualization cloud 150 of FIG. 1) over encrypted network interfaces. Virtualization cloud 250 may be an embodiment of virtualization cloud 150 described above with reference to FIG. 1.
Regarding claim 9, Vetter teaches, wherein the first identification information comprises identification information associated with the querying system(device id can be credentials used to identify the device requesting access… group id , device type, location(gps) ¶s123).
[0123] The notifications (e.g., 932) in event store 930 can be retrieved by client subscriber 950. Client subscriber 950 retrieves the notifications in response to receiving a request from client device 960. A notice service 962 executing on the client device transmits an authorization token to client subscriber 950. The authorization token (954) includes several data items that are associated with client device 960, such as a user ID, a group identifier, a device-type identifier, a location (e.g., GPS coordinates) of the device, and various other administrative information.
Regarding claim 10, Vetter teaches wherein the first data set comprises a first virtual data set(data set from various application (i.e. email ). Implemented as virtual devices, ¶85)
[0085] In a variant of the kiosk mode, a virtual device can be set to synchronize certain enterprise data (e.g., recent email) when the user logs into the kiosk mode device, but the virtual device is still deleted when the user logs out. In this way, any new enterprise data is placed back into the enterprise applications that should own each respective data type. This allows the user to move between server node clusters (e.g., moving between countries) without concern about moving or synchronizing virtual device state between the different servers.
Regarding claim 11, Vetter teaches wherein the first virtual data set is associated with data stored in multiple data stores managed by the data access service system(virtual devices implementing data stores for different applications(i.e. email notifications) implemented on one or more databases, ¶142).
[0142] Different programming techniques can be employed such as procedural or object oriented. Any particular routine can execute on a single computer processing device or multiple computer processing devices, a single computer processor or multiple computer processors. Data may be stored in a single storage medium or distributed through multiple storage mediums, and may reside in a single database or multiple databases (or other data storage techniques). Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, to the extent multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments may be performed at the same time. The sequence of operations described herein can be interrupted, suspended, or otherwise controlled by another process, such as an operating system, kernel, etc. The routines can operate in an operating system environment or as stand-alone routines. Functions, routines, methods, steps and operations described herein can be performed in hardware, software, firmware or any combination thereof.
Regarding claim 12, Vetter teaches, wherein the first identification information comprises an access token(credentials in the form a cookie or token, ¶115).
[0115] The term “authorization token” is used herein to refer to any such information that is used to authenticate either a device or a user to a private network. It should also be noted that the term user may be used to refer to a person using a physical device to access the private network, or to the device itself when discussing the authentication of the user to the system.
Regarding claim 13, Vetter teaches wherein the access token is issued by the identity and access management service to the querying system(authentication server generates a token and sends it to the client for subsequent access request with the relying, ¶55)
[0055] In some embodiments, authentication servers 361 may be configured to provide authentication and session management services. For example, when a user (via a VC client application running on a mobile device that the user is using) attempts to access an enterprise application, authentication server 361 may connect to one or more directory servers (e.g., active directory 309) to authenticate the user's access to virtual device(s) where the enterprise application can be run and to provision the user with one or more virtual devices. After the user authenticates, authentication server 361 may direct virtual device manager 355 to locate a device server that will host the user's virtual device 359. In some embodiments, it may ensure that virtual device 359 is “powered on” as well as initiate the initial session negotiation (via establishment of security tokens) between the mobile device running the VC client application and virtual device 359.
Regarding claim 15, the combination of Vetter teaches receiving, by the data access service system(private network service) from the querying system(client device/mobile device),, a second data access request, the second data access request comprising second identification information and an indication of a second data set managed by the data access service system(user client device is authenticated and given authentication token for a respective application each application accessed using token for respective application , the client sends the token to access a secured asset via the server to gain access to data , ¶13)
[0013] The notification event server periodically receives an authorization token from the user's physical device (which is disconnected from the virtual device). When the authorization token is received, the notification event server examines the token to find information that identifies, for example, the user, a group associated with the user, and a location of the physical device. Based on the identification of the user and/or group, the notification event server identifies notifications in the event store that are associated with the user. These notifications are retrieved by the server from the event store. The notification event server also determines, based on the information identified in the authorization token, which of the filters in the filter store are applicable to the notifications. This determination may be based on an identifier of the user or group, an indication of the location of the physical device, the type of notifications that have been retrieved for the user, or other relevant information. The selected filters are then retrieved from the filter store and are applied to the retrieved notifications to produce filtered notification information. The filtered notification information excludes sensitive information as determined by the selected filters. The notification event server then provides the filtered notification information to the physical device.
issuing, by the data access service system, a second access authorization query to the identity and access management service(authentication servers, ¶55), the second access authorization query comprising the second identification information(i.e 2nd auth token for different application content, ¶9 ) and the indication of the second data set((client request for data such as notifications including email data and other notification data where the token grants rights to access content/notifications and specifies filters/rules for what data be accessed and what filters i.e. restrictions are applied based context of the devices, ¶s55, 109,111 124 )
[0055] In some embodiments, authentication servers 361 may be configured to provide authentication and session management services. For example, when a user (via a VC client application running on a mobile device that the user is using) attempts to access an enterprise application, authentication server 361 may connect to one or more directory servers (e.g., active directory 309) to authenticate the user's access to virtual device(s) where the enterprise application can be run and to provision the user with one or more virtual devices. After the user authenticates, authentication server 361 may direct virtual device manager 355 to locate a device server that will host the user's virtual device 359. In some embodiments, it may ensure that virtual device 359 is “powered on” as well as initiate the initial session negotiation (via establishment of security tokens) between the mobile device running the VC client application and virtual device 359.
[0109] These and other virtual drivers support remote access for applications 660 running on application frameworks 650 in the virtual device. Operation of the virtual device, including processes associated with applications 660, as well as user behaviors can be monitored via various components in application frameworks 650 (e.g., resource manager 651, location manger 653, agent 655, notification manager 657, activity manager 659, content providers 661, telephony manager 663, package manager 665, window manager 667, system view 669, Extensible Messaging and Presence Protocol (XMPP) communications service 671, etc.), some of which will be further described below.
[0111] As noted above, embodiments of the invention may include mechanisms to enable notifications that are originated by applications executing on a virtual device to be provided to a physical mobile device that is disconnected from the virtual device. In one embodiment, a notification server is provided in order to implement a publisher/subscriber model for delivering notifications from producers to consumers. In the context of the systems described above for hosting virtual devices, the virtual device is the publisher and the corresponding physical device is the subscriber. The physical device can subscribe to multiple types of notifications or other events, possibly even from multiple virtual devices. It should be noted that this model can be used to deliver notifications and information regarding other noteworthy events from various virtual devices or services within these devices to other types of clients as well, such as management tools, infrastructure monitoring services, or security services.
[0124] Data items such as the user ID and group identifier are used by client subscriber 950 to determine who the client device is associated with and, consequently, which of the notifications should be retrieved from event store 930. Once the notifications are retrieved from event store 930, they will need to be processed by one or more of the filters (e.g., 942) that are maintained in filter store 940. The selection of appropriate filters may be based on one or more of the data items from the authorization token, including the user ID, group identifier, location, and device type. Client subscriber 950 processes the retrieved notifications using the selected filters to produce notification information that can be transmitted from the client subscriber (which lies within a private domain) back to the client device (which is outside the private domain) without allowing sensitive information to escape the private network. “Sensitive” is used here to describe information that an administrator does not wish to have communicated beyond the boundaries of the private network. The definition of sensitive information may therefore vary from one system to another and is set by the administrators of the respective systems.
receiving, from the identity and access management service in response to the second access authorization query, a response validating the second identification information, and providing at least one second restriction associated with access to the second data set in response to the second data access request (client request for data processed according to auth token which specifies the filters appropriate to the user when such a client is accessing a respective application, ¶s 9,36, 66 124 token received via authentication/negotiation with authentication servers, ¶55)
[0009] Typically, a mobile device has a notification manager that executes on the device and manages the notifications. The various applications on the device which may need to have notifications communicated to the user are registered with the notification manager when they are installed. Then, when it is necessary for an application to notify the user of an event, the application communicates the desired information to the notification manager, which then provides a notification to the user (e.g., via displays or sounds). This mechanism works well when the notification manager is executing on a physical device, breaks down when it is executing on a virtual device that is disconnected from the physical device
[0036] As illustrated in FIG. 1, embodiments disclosed herein can allow a user of mobile device 110 in network environment 100 to switch between using public network services 130 and using private network services 140. In particular, the user may access public network services 130 via public network 120 such as the Internet over which non-sensitive information may be communicated. However, to access private network services 140, a virtualization cloud client application (referred to hereinafter as a “VC client application”) running on mobile device 110 connects to a virtualized device (e.g., virtual device 160A) hosted in virtualization cloud 150 and brokers access to private network services 140 as well as local device functions.
[0055] In some embodiments, authentication servers 361 may be configured to provide authentication and session management services. For example, when a user (via a VC client application running on a mobile device that the user is using) attempts to access an enterprise application, authentication server 361 may connect to one or more directory servers (e.g., active directory 309) to authenticate the user's access to virtual device(s) where the enterprise application can be run and to provision the user with one or more virtual devices. After the user authenticates, authentication server 361 may direct virtual device manager 355 to locate a device server that will host the user's virtual device 359. In some embodiments, it may ensure that virtual device 359 is “powered on” as well as initiate the initial session negotiation (via establishment of security tokens) between the mobile device running the VC client application and virtual device 359.
[0066] Management domain 410 may comprise a plurality of virtual devices 459X, 459Y, 459Z implemented using OpenStack infrastructure 470A on Trusted Platform Module (TPM)-based attestation 460A. Each of the plurality of virtual devices 459X, 459Y, and 459Z may include an agent of management network 450 (e.g., agents 495X, 495Y, 495Z, respectively). In some embodiments, the agent may be referred to as a mobile device management and mobile application management (MDM/MAM) agent. In this example, management domain 410 may further comprise VPN service 456A and storage service 458A.
[0124] Data items such as the user ID and group identifier are used by client subscriber 950 to determine who the client device is associated with and, consequently, which of the notifications should be retrieved from event store 930. Once the notifications are retrieved from event store 930, they will need to be processed by one or more of the filters (e.g., 942) that are maintained in filter store 940. The selection of appropriate filters may be based on one or more of the data items from the authorization token, including the user ID, group identifier, location, and device type. Client subscriber 950 processes the retrieved notifications using the selected filters to produce notification information that can be transmitted from the client subscriber (which lies within a private domain) back to the client device (which is outside the private domain) without allowing sensitive information to escape the private network. “Sensitive” is used here to describe information that an administrator does not wish to have communicated beyond the boundaries of the private network. The definition of sensitive information may therefore vary from one system to another and is set by the administrators of the respective systems.
and transmitting at least a subset of the second data set to the querying system, the at least a subset of the second data set being determined based on the indication of the geographic location associated with the second identification information and the at least one second restriction(data such notification are transmitted after filters are applied based on token with different respective application(email app, text app) such filtering based on the device’s geographical location indicated by GPS info in token, ¶s8,13,112), .
[0008] In view of unique challenges in incorporating mobile devices such as smart phones and tablets into secure computing environments, there is room for innovations and improvements. One area in need of improvement relates to the notifications that are provided by mobile devices. When a person is actively using a mobile device, the device may provide notifications of various events that may be of interest to the user. These notifications may include sounds that are made by the device or icons that are displayed by the device to indicate the type of event that has occurred. The most obvious notifications are the ones that are presented to the user of a smart phone when a telephone call is received. These notifications include turning on the display (which may include selected images and the caller's phone number), playing a selected ring tone, and/or causing the device to vibrate. Similarly, a device may present predetermined images or sounds to indicate that emails, text messages or other notifications have been received. Still other types of notifications may be provided by different applications that are executable by the device. Commonly, these notifications are configurable by the user.
[0013] The notification event server periodically receives an authorization token from the user's physical device (which is disconnected from the virtual device). When the authorization token is received, the notification event server examines the token to find information that identifies, for example, the user, a group associated with the user, and a location of the physical device. Based on the identification of the user and/or group, the notification event server identifies notifications in the event store that are associated with the user. These notifications are retrieved by the server from the event store. The notification event server also determines, based on the information identified in the authorization token, which of the filters in the filter store are applicable to the notifications. This determination may be based on an identifier of the user or group, an indication of the location of the physical device, the type of notifications that have been retrieved for the user, or other relevant information. The selected filters are then retrieved from the filter store and are applied to the retrieved notifications to produce filtered notification information. The filtered notification information excludes sensitive information as determined by the selected filters. The notification event server then provides the filtered notification information to the physical device.
[0112] Referring to FIG. 7, a flow diagram illustrating one embodiment of a method for providing notifications in such a scenario is shown. In this embodiment, one or more virtual devices are executed on a host server (702). The host server provides a private network environment that is secure and requires authorization in order to allow physical mobile devices to access the network. On each of these virtual devices, a notification manager is executed. The notification manager executing on each of the virtual devices receives notification information from various applications that are also executing on the virtual device (704). The notification information is forwarded to a notification server (706), where it is stored until a client mobile device can connect to the server. After the client mobile device connects to the event server, the notification information is filtered according to applicable rules in order to remove sensitive information (e.g., confidential, proprietary, or other defined types of secure information) that is not authorized to be communicated out of the private network (708). The particular type of filtering that is applied to the notification information (and the type of information that is filtered out of the notifications) is determined in response to the client mobile device connecting to the server, and may be dependent upon a number of factors, such as the identity of the mobile device's user and the location from which the private network is being accessed. After the sensitive information has been filtered out of the notifications, all or part of the notifications may be communicated to the mobile device (710).
Regarding claim 17, Vetter teaches wherein the method further comprises storing at least a portion of the response validating the second identification information in a cache storage of the data access service system(token for second application stored on notification system for determining filters and storing filter associated with the token, ¶12).
[0012] One embodiment comprises a system for providing notifications from virtual devices to users of corresponding physical devices. The system includes a host server and a notification event server. The host server executes a virtual device which corresponds to a physical device of a user. The virtual device executes a notification manager that receives notifications from one or more notification sources. When the physical device is not connected to the virtual device and cannot receive notifications directly from the notification manager, the notification manager forwards the notifications to the notification event server. The notification event server receives the notifications and stores the notifications in an event store. The notification event server also maintains a filter store in which a set of filters are stored.
Regarding claim 18, Vetter teaches wherein the at least one first restriction and the at least one second restriction comprise a same restriction(both applications email, text can include a filter on sensitive information, ¶125)
[0125] The operation of the notification server in this embodiment is summarized in the flow diagram of FIG. 10. As shown in this figure, the notification server initially receives notifications and stores the notifications in the event store (1002). The notification server continues to receive notifications, store the notifications, and manage the notifications in the event store, while the remainder of the steps in the process of FIG. 10 are performed. At step 1004, a client sends an authorization token to the notification server. The notification server identifies information contained in the authorization token which is relevant to the identification of notifications associated with the client and to the filtering of these notifications (1006). Based on the information identified in the authorization token, the notification server identifies the user associated with the token and retrieves notifications from the event store that are associated with the user (1008). The notification server also determines which filters are applicable to the identified client based on information contained in the token (1010). The notification server then applies the selected filters to the retrieved notifications to produce a sanitized notification output that does not contain sensitive information (1012). The sanitized notification output is then transmitted to the client device, where it can be displayed to the user of the device (1014).
Regarding claim 19, Vetter teaches wherein the second identification information comprises an access token(credentials in the form a cookie or token for second application, ¶115).
[0115] The term “authorization token” is used herein to refer to any such information that is used to authenticate either a device or a user to a private network. It should also be noted that the term user may be used to refer to a person using a physical device to access the private network, or to the device itself when discussing the authentication of the user to the system.
Regarding claim 20, Vetter teaches wherein the method further comprises storing at least a portion of the response validating the first identification information in a cache storage of the data access service system(token stored on notification system for determining filters and storing filter associated with the token, ¶12).
[0012] One embodiment comprises a system for providing notifications from virtual devices to users of corresponding physical devices. The system includes a host server and a notification event server. The host server executes a virtual device which corresponds to a physical device of a user. The virtual device executes a notification manager that receives notifications from one or more notification sources. When the physical device is not connected to the virtual device and cannot receive notifications directly from the notification manager, the notification manager forwards the notifications to the notification event server. The notification event server receives the notifications and stores the notifications in an event store. The notification event server also maintains a filter store in which a set of filters are stored.
Regarding claim 21, Vetter teaches wherein the response received from the identity and access management service further comprises an indication of a geographic location associated with the first identification information and wherein access to the subset of the first data set is further determined based on the indication of the geographic location associated with the first identification information and the at least one first restriction(filtering based upon location of device as identified using GPS, ¶s13,123, 124).
[0013] The notification event server periodically receives an authorization token from the user's physical device (which is disconnected from the virtual device). When the authorization token is received, the notification event server examines the token to find information that identifies, for example, the user, a group associated with the user, and a location of the physical device. Based on the identification of the user and/or group, the notification event server identifies notifications in the event store that are associated with the user. These notifications are retrieved by the server from the event store. The notification event server also determines, based on the information identified in the authorization token, which of the filters in the filter store are applicable to the notifications. This determination may be based on an identifier of the user or group, an indication of the location of the physical device, the type of notifications that have been retrieved for the user, or other relevant information. The selected filters are then retrieved from the filter store and are applied to the retrieved notifications to produce filtered notification information. The filtered notification information excludes sensitive information as determined by the selected filters. The notification event server then provides the filtered notification information to the physical device.
[0123] The notifications (e.g., 932) in event store 930 can be retrieved by client subscriber 950. Client subscriber 950 retrieves the notifications in response to receiving a request from client device 960. A notice service 962 executing on the client device transmits an authorization token to client subscriber 950. The authorization token (954) includes several data items that are associated with client device 960, such as a user ID, a group identifier, a device-type identifier, a location (e.g., GPS coordinates) of the device, and various other administrative information.
[0124] Data items such as the user ID and group identifier are used by client subscriber 950 to determine who the client device is associated with and, consequently, which of the notifications should be retrieved from event store 930. Once the notifications are retrieved from event store 930, they will need to be processed by one or more of the filters (e.g., 942) that are maintained in filter store 940. The selection of appropriate filters may be based on one or more of the data items from the authorization token, including the user ID, group identifier, location, and device type. Client subscriber 950 processes the retrieved notifications using the selected filters to produce notification information that can be transmitted from the client subscriber (which lies within a private domain) back to the client device (which is outside the private domain) without allowing sensitive information to escape the private network. “Sensitive” is used here to describe information that an administrator does not wish to have communicated beyond the boundaries of the private network. The definition of sensitive information may therefore vary from one system to another and is set by the administrators of the respective systems.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Vetter/Enderwick as applied to claim 1 above, and further in view of Khurana US 2021/0173918.
Regarding claim 14, Vetter teaches a sandboxing untrusted applications but not specifically a sandboxed environment. in the same field of endeavor teaches a system for secure access control to a data in a database. Khurana teaches wherein the execution environment comprises a protected sandbox of a secure execution environment of the querying system.
[0011] In yet another embodiment, one or more computer-readable storage media having program instructions stored thereon to facilitate data access environments comprising multiple application services and multiple storage services directs a processing system to, when read and executed by the processing system, receive a user request from a sandbox environment to access a dataset, wherein the sandbox environment is a virtual database environment and the dataset is stored in a database associated with a data access system. The program instructions further direct the processing system to retrieve at least a portion of the dataset from the database, identify at least one sandbox access policy associated with the user request and the dataset, and generate a view of the dataset in the sandbox environment, wherein the view displays one or more enabled elements of the dataset based on the at least one sandbox access policy.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Vetter/Enderwick ‘s trusted application with a sandboxed secure environment as taught by Khurana. The reason for this modification would be to provide secure access to a data repository.
Claim 16 are rejected under 35 U.S.C. 103 as being unpatentable over Vetter/Enderwick as applied to claim 15 above, and further in view of Breeden US 11,388,211.
Regarding claim 16, Vetter/Enderwick does not teach wherein the first data set and the second data set comprise data that at least in part overlaps. Breeden in the same field of endeavor teaches a system for access to data sets. Breeden teaches wherein the first data set and the second data set comprise data that at least in part overlaps.
[(126) In an embodiment, data sets associated with each of the modalities may be persisted in one or more databases 555. As noted previously, the data sets for the respective modalities may be separate data sets, overlapping data sets or a single data set that supports all the modalities. Note that the databases 555 may be a single database that stores data sets corresponding to all three modalities. Alternatively, the databases 555 may represent different respective databases for each of the three modalities. Furthermore, the databases 555 may also represent distributed databases across which relevant information for each of the three modalities is stored., Col 20 Lines 51-62]
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Vetter/Enderwick with Breeden overlapping data set. The reason for this modification would be to allow for aggregation/correlation of data sets
Applicant Remarks
Applicant’s arguments with respect to claims 1-6 and 8-21 have been considered but are unpersuasive as discussed below.
The applicant argues on page 8 of the response that Vetter does not teach “ receiving, from the identity and access management service in response to the first access authorization query, a response validating the first identification information and providing at least one first restriction associated with access to a subset of the first data set based on a requesting execution environment”, because the token of Vetter as presented in the cited paragraphs is not form an identity and access management service.
The examiner contends that the authentication token is provided by an authentication server as discussed in ¶55 specifying initial establishment of security tokens(i.e. auth token). Thus Vetter teaches receiving, from the identity and access management service in response to the first access authorization query, a response validating the first identification information and providing at least one first restriction associated with access to a subset of the first data set based on a requesting execution environment.
The applicant on page 8 of the arguments alleges that Enderwick is deficient to cure the alleged deficiencies of Vetter. The examiner contends that Enderwick not relied upon for teach claim elements attributed to Vetter and thus such arguments are moot.
The applicant further argues on page 8 and 9 of the arguments that the combination of Vetter/Enderwick fail to disclose identifying an execution environment of the querying system associated with the first data access request based on identifying which port of a plurality of ports of the data access service system the first data access request was received over; determining that the subset of the first data set may be transmitted to the querying system based on the identified execution environment and the at least one first restriction;. The applicant argues that Vetter do not teach such limitations. The applicant further argues that Enderwick does not teach such limitations because the applicant alleges that the port identification of Enderwick is a binary blocking or granting of access and does not teach the ports are used to allow access based on a restriction. The examiner contends that Enderwick is not relied upon for teaching determining the subset of data may or may not be transmitted based upon identification of an execution environment by port. Rather the combination of execution environment and a first restriction. The applicants arguments ignore the combination of Vetter and Enderwick as presented in the rejection. The applicant alleges that the deficiency of Enderwick based on an interpretation of the claims not recited. The claim does not require the identification of the port to be the sole basis of determining the subset of data to be transmitted. Rather the claims require that determining the subset of data may be transmitted based on the two conditions executing environment and at least on first restriction. The primary references teaches as presented in the rejection determining that the subset of the first dataset may be transmitted to the querying system based on the identified execution environment and the at least one first restriction. Vetter teaches determining that the subset of the first dataset(filtered notification sent to application¶s115,116)) may be transmitted to the querying system based on the identified execution environment(client application accessing from a secure private environment on the basis of being authenticated to VPN, ¶s59,112,114 ) and the at least one first restriction(restrictions/filters based on token used for access, ¶118 ). Vettner uses authentication to assume that the client application is accessing data from a secure environment and does not verify the port to determine a execution environment, is secure. Enderwick teaches verification that the access of a application is from secure connection(i.e. environment) by associating a client application with a VPN port number as the basis for such verification. Thus the combination of Vetter with Endewick adds the extra step of using a port to determine the application is accessing from a secure location rather than the mere assumption of a access with a VPN. The motivation for the combination would be that verifying the port adds and additional step for verification that provides greater assurance that the application requesting data from the private network can be trusted and should be allowed access to data on a private network.
The applicant argues on page 10 of the arguments, with respect to claim 14 that Khurana fails to cure the alleged deficiencies with respect to Vetter in view of Enderwick. The examiner contends such arguments are moot because Breeden is not relied upon for such teaching such limitations claim 1.
The applicant argues on page 11 of the arguments, with respect to claim 16 that Breeden fails to cure the alleged deficiencies with respect to Vetter in view of Enderwick. The examiner contends such arguments are moot because Breeden is not relied upon for such teaching such limitations claim 1.
For the above reasons the examiner contends the prior art rejections are proper and thus maintains the rejections as presented.
Conclusion
THIS ACTION IS MADE FINAL. 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 Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
