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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 29th, 2026 has been entered.
Claim Status
Claims 1, 11 and 20 have been amended. Claims 2, 12 and 14 remain cancelled. Claims 1, 3-11, 13 and 15-23 remain pending and are ready for examination.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 4-6, 8-11, 15, 17-21 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhooshan (US Publication No. 2015/0288670 -- "Bhooshan") in view of McEntee (US Publication No. 2018/0013621 -- "McEntee") in further view of Romero et al. (US Publication No. 2020/0145414 – “Romero”) in further view of Gunther et al. (US Publication No. 2024/0372855 – “Gunther”).
Regarding claim 1, Bhooshan teaches A host device comprising: an imaging system; (Bhooshan Fig. 1, Reference #102 and #106, also see Bhooshan paragraphs [0027-0028], With reference to FIG. 1, there is shown a functional block diagram of an environment 100, in which a network device for managing access to a network 110 by a user device 106 may be implemented, according to an example. It should be readily apparent that the diagram depicted in FIG. 1 represents a generalized illustration and that other components may be added or existing components may be removed, modified or rearranged without departing from a scope of the environment 100. FIG. 1 depicts a system 102, which may be referred to as a Simplified Network Access Control (SNAC) system, but other names may be employed as well. The system 102 is depicted as including a network switch 108, an Identity Driven Manager (IDM) server 120 for hosting IDM modules (not shown), a SNAC registration server 122 for hosting SNAC modules (not shown). In addition, the SNAC registration server 122 is depicted as being in communication with an Active Directory (AD) 136 and a guest directory 142. In addition, the SNAC registration server 122 may include a QR code generator 150 for generating QR codes, as is more fully discussed below. The network switch 108 is also depicted as being in communication with a network 110, which may include network servers and devices. The host device may comprise an imaging system and a connection with a user/client device) a wireless interface; and one or more processors configured to: (Bhooshan paragraphs [0083-0084], Subsequent access to the network 110 through the user device 106 will now occur automatically as the user 104 is immediately allowed access with the appropriate access rights based on the their IDM group, profile, etc. In addition, from this point forward, the user 104 is unaware that SNAC is being implemented since the user's 104 access to the network 110 through the user device 106 is transparent to the user 104. As discussed in greater detail below with respect to the method 400 in FIG. 4, when the user's access rights changes, such as, when the user leaves a company, that change is automatically reflected in the database of authorized users 128 since the IDM server 120 is monitoring the directory of active network users 136, 142 for changes. Turning now to FIG. 8, there is shown a schematic representation of a computing device 800, which may be employed to perform various functions of the servers 120, 122 depicted in FIG. 1, according to an example. Similar elements, possibly with some elements omitted or added, may also be employed within an intelligent switch, such as switch 108 in FIG. 1. Computing device 800 includes a processor 802; a display device 804, such as a monitor; a network interface 808, such as a Local Area Network LAN, a wireless 802.11x LAN, a 3G mobile WAN or a WiMax WAN; and a computer-readable medium 810. Each of these components is operatively coupled to a bus 812. For example, the bus 812 may be an EISA, a PCI, a USB, a FireWire, a NuBus, or a PDS) Generating a coded image that encodes credential information (Bhooshan paragraph [0046], In response to a determination that the database of authorized users 128 does include the user device information 106DI, access to the network 110 is granted to the user 104 through the user device 106, as indicated at block 306. Specific access and control rights may be determined by IDM agent 116 in conjunction with IDM policy database 124. However, if a determination that the database of authorized users 128 does not include the user device information 106DI, at block 308, user information 104UI is received. More particularly, for instance, the user 104 may be prompted to input the user information 104UI, such as, a user name, user identification, password, and/or other credentials, and the user 104 may input the requested user information 104UI. Alternatively, this information may be provided based on information encoded in a QR code, as more fully discussed below. In addition, the switch 108 may redirect the user information 104UI to the SNAC registration server 122 as indicated by the line labeled “MAC-AUTH-FAILURE-REDIRECT”.) Transmitting the generated coded image to the first client device over the wireless interface; (Bhooshan paragraph [0092], The set of instructions for facilitating self-registration 918 provides various components for facilitating network access by the user device to the network. The set of instructions 918 may access a QR code, generated by a network device, for example, the SNAC registration server 122. The QR code may be accessed, for example, via a camera at the user device, via internal or external storage at the user device, etc. The set of instructions for facilitating self-registration 918 may read the QR code and extract the information, including a set of credentials of the user of the user device. An address, for example a URL, may further be extracted from the QR code. The information may then be transmitted to a network device, for example, the SNAC registration server 122, for example at the extracted address, in order to facilitate self-registration of the user device in the network. A coded image in the form of a QR code is generated via a user device, and then can be analyzed and transmitted, see Bhooshan claim 13, The non-transitory computer readable storage medium of claim 12, the processor further to enable a device to access a network based on the transmission of the at least one credential from the set of credentials extracted from the QR code and transmitted to the network device. The coded image containing credential information may be generated as a QR code, then transmitted and analyzed/scanned by the client device to authorize said code, see Bhooshan paragraph [0025], According to an example, the information may be extracted from the QR code by the user device and provided to the network device. The network device receives the user self-registration information and determines whether the user self-registration information is listed in the directory of active network users, or in the directory of guest network users. If the user is listed in the directory of active network users or the directory of guest network users, the hardware self-identification information is listed in the list of authorized users, and the user device is granted network access. As a result, when the user device is physically coupled to the network on future occasions, the user device information need not be requested again because the user device information is automatically recognized as being listed in the list of authorized users, and the user device is automatically granted network access) Scanning, using the imaging system, a displayed coded image shown on a display of the first client device (The coded image containing credential information may be generated as a QR code, then transmitted and analyzed/scanned by the client device to authorize said code, see Bhooshan paragraph [0025], According to an example, the information may be extracted from the QR code by the user device and provided to the network device. The network device receives the user self-registration information and determines whether the user self-registration information is listed in the directory of active network users, or in the directory of guest network users. If the user is listed in the directory of active network users or the directory of guest network users, the hardware self-identification information is listed in the list of authorized users, and the user device is granted network access. As a result, when the user device is physically coupled to the network on future occasions, the user device information need not be requested again because the user device information is automatically recognized as being listed in the list of authorized users, and the user device is automatically granted network access).
Bhooshan does not teach Non-volatile memory; Perform an initial in person-authentication of a first client device that requires physical proximity of the first client device to the host device to establish trust between owners of the host device and the first client device, wherein the initial in-person authentication is performed by: associated with a first shared partition in the non-volatile memory; while the first client device is in physical proximity to the host device; and subsequent to performing the initial in-person authentication of the first client device: send a notification to the first client device indicating that the host device is available for communication with the first client device, wherein the notification is sent after the host device has been turned on in response to the owner of the first client device contacting the owner of the host device after trust has been established between owners of the host device and the first client device; perform a remote authentication of the first client device, wherein because trust was previously-established by the initial in-person authentication, the remote person authentication does not require physical proximity of the first client device to the host device; receive, from the first client device, a request for a file stored in the first shared partition; and transfer the file from the first shared partition to the first client device.
However, McEntee teaches Non-volatile memory; associated with a first shared partition in the non-volatile memory; (McEntee paragraph [0022], The first user machine can then be configured to execute the configuration data, including partitioning its local storage device into a private portion and a shared portion. This partitioning may be performed by enabling the first use of the first machine to select one or more local directories (e.g., one or more folders included in the first computer's hard drive) to be mounted (e.g., or otherwise added to) the community internet drive. While the local directories that are mounted to the community internet drive can be considered “a shared portion” of the first machine's local storage device, other directories that are not mounted to the community internet drive can be considered the private portion of the local storage device that is excluded from the community internet drive. The shared portion of storage can include a plurality of shared partitions, see McEntee paragraph [0022], While the local directories that are mounted to the community internet drive can be considered “a shared portion” of the first machine's local storage device, for explicitly non-volatile memory being used, see McEntee paragraph [0060], In some embodiments, storage device 126 may include one or more tangible, non-transitory memory devices such as, for example, volatile and/or non-volatile memory that may be either fixed or removable) receive, from the first client device, a request for a file stored in the first shared partition in the non-volatile memory; and transfer the file from the first shared partition to the first client device (McEntee paragraph [0072-0073], The managed hub can be configured to enable a user to choose a folder, such as mount point 206B, to contain a subtree to publish in association with the user. In response to the user indicating a desire to use a locally stored folder as a mount point in the community internet drive, community machine 116 can be configured to make the data within the chosen folder (and/or any subfolders) shared data. As such, the data within the chosen folder can be considered “transferred” and/or added to the “shared portion” (e.g., local internet drive 122A/B) of the storage device (e.g., storage device 126) from the “private portion” of the storage device (e.g., the portion of the storage device 126 that is excluded from the community internet drive). In the example shown by FIG. 3, the user's published data, in the shared portion of the storage device, includes a link 304 to other content on the community internet drive associated with the user. The link 304 can refer to any other file or folder, whether from the shared portion of the member's storage, or elements of the otherwise private portion of local storage that are shared individually through that reference, or even references to other data within the community internet drive from other members (where the linking member must always have access to the linked content). Link 304 can be implemented in any suitable way or combination thereof, including without limitation using operating system features for writing a file, making an entry in a file containing this and other settings, and/or adding a record to a database, among other things. The shared partition may be accessed in response to a request received from a client/user).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan with those of McEntee. McEntee teaches the specific structure of the device and the related storage components. Specifically, McEntee discloses a process by which a host and client device can utilize a non-volatile memory that contains a shared portion including a plurality of shared directories for access in response to a client device request. The utilization of a shared partition is a common method of improving the processing speed of the memory/storage device as a whole, due to the data being contained within a singular shared storage partition that can be accessed by different components (McEntee paragraph [0073], In the example shown by FIG. 3, the user's published data, in the shared portion of the storage device, includes a link 304 to other content on the community internet drive associated with the user. The link 304 can refer to any other file or folder, whether from the shared portion of the member's storage, or elements of the otherwise private portion of local storage that are shared individually through that reference, or even references to other data within the community internet drive from other members (where the linking member must always have access to the linked content). Link 304 can be implemented in any suitable way or combination thereof, including without limitation using operating system features for writing a file, making an entry in a file containing this and other settings, and/or adding a record to a database, among other things. In some embodiments, software executed by the member's community machine, such as community machine 116, can cause the member's community machine to be configured to connect across path 306, so that the destination point of that symbolic link appears within the published space. The published folders and data in box 210, including the resolved link, are associated with the shared portion of the community machine's local storage device and, therefore, may appear within community internet drive 200. Also see McEntee paragraph [0076], FIG. 5 is a block diagram showing how the community internet drive can be enabled by the managed hub functionality of, for example, server 104 when combined with the storage devices and other circuitry of distributed heterogeneous machines, such as at least one computer 106, personal computer 108, tablet 110, laptop computer 112, and/or cellular device 114, among others. The managed hub machine can be connected to one or more independent publishers via connection 502, which may include, for example, network 102, one or more client-server connections and/or direct connections (such as those between networked peer machines). As such, the community internet drive may be provided and used to store and manage data stored among a plurality of community machines while also (or instead) providing novel data access, security and sharing features similar to those sometimes associated with social-networking systems. In some embodiments, the community internet drive may also provide web publishing and namespace hosting and assigning functionality).
Bhooshan in view of McEntee does not teach Perform an initial in person-authentication of a first client device that requires physical proximity of the first client device to the host device to establish trust between owners of the host device and the first client device, wherein the initial in-person authentication is performed by: while the first client device is in physical proximity to the host device; And subsequent to performing the initial in-person authentication of the first client device: send a notification to the first client device indicating that the host device is available for communication with the first client device, wherein the notification is sent after the host device has been turned on in response to the owner of the first client device contacting the owner of the host device after trust has been established between owners of the host device and the first client device; perform a remote authentication of the first client device, wherein because trust was previously-established by the initial in-person authentication, the remote person authentication does not require physical proximity of the first client device to the host device.
However, Romero teaches Perform an initial in person-authentication of a first client device that requires physical proximity of the first client device to the host device to establish trust between owners of the host device and the first client device, wherein the initial in-person authentication is performed by: (Romero paragraph [0013], FIG. 1 illustrates an exemplary system 100 that employs techniques for proximity-based device authentication when selectively permitting or denying access to a Wi-Fi network 110 generated by an access point 104. The system 100 includes a proximity-based device authenticator 102 stored in memory that is executable to verify personal information provided by each user accessing the Wi-Fi network 110. In different implementations, different aspects of the proximity-based device authenticator 102 may be stored in different locations and/or executed by different processors, including one or more local processors within the access point 104 and remote processors external to the access point 104 (e.g., at one or more cloud-based processors). Initial in person authentication can be performed via physical proximity authentication detection) while the first client device is in physical proximity to the host device; (Romero Figs 2A-2C; Romero paragraph [0004], FIG. 2A illustrates example communications that are performed within a system as part of a proximity-based device authentication process) And subsequent to performing the initial in-person authentication of the first client device: perform a remote authentication of the first client device, wherein because trust was previously-established by the initial in-person authentication, the remote person authentication does not require physical proximity of the first client device (Romero paragraph [0013], FIG. 1 illustrates an exemplary system 100 that employs techniques for proximity-based device authentication when selectively permitting or denying access to a Wi-Fi network 110 generated by an access point 104. The system 100 includes a proximity-based device authenticator 102 stored in memory that is executable to verify personal information provided by each user accessing the Wi-Fi network 110. In different implementations, different aspects of the proximity-based device authenticator 102 may be stored in different locations and/or executed by different processors, including one or more local processors within the access point 104 and remote processors external to the access point 104 (e.g., at one or more cloud-based processors). Remote access can be provided after physical authentication has been performed (i.e., also see Romero Fig. 2B, Ref. #210; access point whitelist), or Romero claim 15, The one or more computer-readable storage media of claim 9, further comprising: receiving a subsequent request from the electronic device to access the Wi-Fi network; determining that the device identifier for the electronic device is included on at least one of a local whitelist or remote whitelist; enabling a connection between the electronic device and the Wi-Fi network without directing the electronic device to the captive portal in response to the determination and Romero paragraph [0026]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan and McEntee with those of Romero. Romero teaches using an in-person authentication to provide later remote access to a device, which can provide a balance between security/reliability as well as convenience (i.e., see Romero paragraph [0061], In one implementation, the processing system 500 is integrated within a Wi-Fi access point and the memory section 508 stores locally-executed software that performs some or all functionality of a proximity-based device authenticator, such as the local authenticator 220 described with respect to FIG. 2A-2C. In another implementation, the processing system 500 is included on a remote server capable of adjusting configuration settings of an access point, such as to perform functions of the cloud-based authenticator 208 described with respect to FIG. 2A-2C and Romero paragraphs [0012] and [0063]).
Bhooshan in view of McEntee in further view of Romero does not teach send a notification to the first client device indicating that the host device is available for communication with the first client device, wherein the notification is sent after the host device has been turned on in response to the owner of the first client device contacting the owner of the host device after trust has been established between owners of the host device and the first client device.
However, Gunther teaches send a notification to the first client device indicating that the host device is available for communication with the first client device, (Gunther paragraph [0007], The security protocol begins when a host device requests a session identifier from a pairing service associated with a relay server. The relay server is utilized to establish a protected communication session between the trusted client device and the host device for sharing the credentials, and the session identifier identifies a particular communication channel, implemented through the relay server, over which the protected communication session is established. Alternatively, the relay server may be bypassed and the protected communication session can be established on a communication channel connecting the trusted client device directly to the host device. A request (i.e., notification of availability) can be sent indicating communication can begin) wherein the notification is sent after the host device has been turned on in response to the owner of the first client device contacting the owner of the host device after trust has been established between owners of the host device and the first client device (Gunther paragraph [0123], Once the keys are exchanged, the protected communication session can be established between the host device 210 and the trusted client device 250 through the relay server 290. Unlike security protocol 300, where a PET is transmitted to the host device 210 to sign in to a user account through a service 282, the security protocol 700 can be utilized to simply exchange generic data payloads encrypted based on the negotiated keys. The data payload can be any type of data that is exchanged in a protected manner between the trusted client device 250 and the host device 210. Thus, the protected communication session enables a variety of different applications to utilize the encrypted channel between the host device 210 and the trusted client device 250. Communication between a host and a client device can be initialized via notification when trust has been established (i.e., the client device is determined to be a trusted device). This can be done in response to a session starting (i.e., host device being turned on/logged in) such as described in Gunther paragraph [0073], In some embodiments, the host device 210 includes one or more sensors 214 that can be utilized to collect biometric data. Once a user has logged onto the service 282 utilizing the trusted client device 250 to exchange the PET, the user may subsequently re-connect with the service 282 (e.g., log on) by utilizing the one or more sensors 214 of the host device 210 to confirm the identity of the user).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan and McEntee and Romero with those of Gunther. Gunther teaches establishing communication between a host and a client device that has determined to be trusted in response to a notification, which can allow for more efficient and secure communication between devices (i.e., see Gunther paragraph [0007], In some embodiments, a host device and a trusted client device implement a security protocol to share credentials for accessing a user account through the established communication session. The user account is maintained by a service provider and associated with a service provided over the Internet. The security protocol includes a number of steps executed by the host device and the trusted client device. The security protocol begins when a host device requests a session identifier from a pairing service associated with a relay server. The relay server is utilized to establish a protected communication session between the trusted client device and the host device for sharing the credentials, and the session identifier identifies a particular communication channel, implemented through the relay server, over which the protected communication session is established. Alternatively, the relay server may be bypassed and the protected communication session can be established on a communication channel connecting the trusted client device directly to the host device).
Claims 11 and 20 are the corresponding device and method claims to independent claim 1. They are rejected with the same references and rationale.
Regarding claim 4, Bhooshan in view of McEntee in further view of Romero in further view of Gunther teach The host device of claim 1, wherein the one or more processors are further configured to transfer the file over a network used by the wireless interface (McEntee paragraphs [0023-0024], Additionally (or alternatively), some embodiments discussed herein provide various solutions to problems related to sharing data between or among users. For example, the managed hub can be configured to cause data to be transferred to a person or place where it is needed. Each user may also identify other users in particular and/or criteria for selecting other users to define a user-selected subset community within the larger community. For example, within a certain user base of the self-selected community, embodiments discussed herein can manage the sharing of data according to the social mapping of the user-selected subset community, while it also feeds the development of the larger community with user-generated content (“UGC”). Embodiments may also be easy to use, provide data security, be fair, be reliable, and provide benefit through the enabled quality of service. Data from user's “in-group” can be inherently more interesting than that published by strangers. Data can be transferred in the form of files over the network when requested, see McEntee paragraph [0027], While the first user machine can be configured to store user data (e.g., files, pictures, movies, websites, and/or other content associated with the first user) in the first user machine's shared portion of the local storage device, all the user data can be encrypted such that only machines associated with in-group users can access the user data. For example, the first user machine may also receive and store a stranger's user data (because the first user machine is part of the community internet drive), but if the stranger user is unassociated with any of the user's in-group(s), the stranger's user data can be encrypted such that the first user machine is unable to decipher the stranger's user data despite the stranger's data being physically stored on the user's computer (e.g., in the local portion of the local storage device)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan with those of McEntee, Romero and Gunther. McEntee teaches the specific structure of the device and the related storage components. Specifically, McEntee discloses a process by which a host and client device can utilize a non-volatile memory that contains a shared portion including a plurality of shared directories for access in response to a client device request. The utilization of a shared partition is a common method of improving the processing speed of the memory/storage device as a whole, due to the data being contained within a singular shared storage partition that can be accessed by different components (McEntee paragraph [0073], In the example shown by FIG. 3, the user's published data, in the shared portion of the storage device, includes a link 304 to other content on the community internet drive associated with the user. The link 304 can refer to any other file or folder, whether from the shared portion of the member's storage, or elements of the otherwise private portion of local storage that are shared individually through that reference, or even references to other data within the community internet drive from other members (where the linking member must always have access to the linked content). Link 304 can be implemented in any suitable way or combination thereof, including without limitation using operating system features for writing a file, making an entry in a file containing this and other settings, and/or adding a record to a database, among other things. In some embodiments, software executed by the member's community machine, such as community machine 116, can cause the member's community machine to be configured to connect across path 306, so that the destination point of that symbolic link appears within the published space. The published folders and data in box 210, including the resolved link, are associated with the shared portion of the community machine's local storage device and, therefore, may appear within community internet drive 200. Also see McEntee paragraph [0076], FIG. 5 is a block diagram showing how the community internet drive can be enabled by the managed hub functionality of, for example, server 104 when combined with the storage devices and other circuitry of distributed heterogeneous machines, such as at least one computer 106, personal computer 108, tablet 110, laptop computer 112, and/or cellular device 114, among others. The managed hub machine can be connected to one or more independent publishers via connection 502, which may include, for example, network 102, one or more client-server connections and/or direct connections (such as those between networked peer machines). As such, the community internet drive may be provided and used to store and manage data stored among a plurality of community machines while also (or instead) providing novel data access, security and sharing features similar to those sometimes associated with social-networking systems. In some embodiments, the community internet drive may also provide web publishing and namespace hosting and assigning functionality).
Regarding claim 5, Bhooshan in view of McEntee in further view of Romero in further view of Gunther teaches The host device of claim 1, wherein the file is transferred without using temporary cloud storage (McEntee paragraphs [0023-0024], Additionally (or alternatively), some embodiments discussed herein provide various solutions to problems related to sharing data between or among users. For example, the managed hub can be configured to cause data to be transferred to a person or place where it is needed. Each user may also identify other users in particular and/or criteria for selecting other users to define a user-selected subset community within the larger community. For example, within a certain user base of the self-selected community, embodiments discussed herein can manage the sharing of data according to the social mapping of the user-selected subset community, while it also feeds the development of the larger community with user-generated content (“UGC”). Embodiments may also be easy to use, provide data security, be fair, be reliable, and provide benefit through the enabled quality of service. Data from user's “in-group” can be inherently more interesting than that published by strangers. Data can be transferred directly without the use of cloud storage in the form of files over the network when requested, see McEntee paragraph [0027], While the first user machine can be configured to store user data (e.g., files, pictures, movies, websites, and/or other content associated with the first user) in the first user machine's shared portion of the local storage device, all the user data can be encrypted such that only machines associated with in-group users can access the user data. For example, the first user machine may also receive and store a stranger's user data (because the first user machine is part of the community internet drive), but if the stranger user is unassociated with any of the user's in-group(s), the stranger's user data can be encrypted such that the first user machine is unable to decipher the stranger's user data despite the stranger's data being physically stored on the user's computer (e.g., in the local portion of the local storage device)).
Claim 15 is the corresponding method claim to claim 5. It is rejected with the same references and rationale.
Regarding claim 6, Bhooshan in view of McEntee in further view of Romero in further view of Gunther teaches The host device of claim 1, wherein the one or more processors are further configured to send a notification to the first client device indicating an estimate of a time that access to the first shared partition will be provided to the first client device (Bhooshan paragraph [0059], In an example second process starting at block 418, a user time limit and/or date limit set in the directory of active network users 136, 142 is noted, and the appropriate time and or date is monitored. For example, a date limit may indicate that a user 104 is only entitled to access to the network for a specific date, such as May 1. The current date is determined, as well as whether or not the corresponding user device 106 is in use. When the authentication is processed, a notification will be sent for a given estimate of time for which the user will be able to access the storage, after which access will be unavailable, see Bhooshan paragraph [0060], At decision block 420, a determination is made if the user time limit or user date boundaries have been exceeded. If yes, then at block 422 network access through the user device 106 is terminated by removing the user information 104UI and the associated user device information 106DI are deleted from the list of authorized users 130 in the database of authorized users 128, preventing future logins through the user device 106).
Regarding claim 8, Bhooshan in view of McEntee in further view of Romero in further view of Gunther teaches The host device of claim 1, wherein the one or more processors are further configured to receive the file from the first client device for storage on the first shared partition (McEntee paragraph [0027], While the first user machine can be configured to store user data (e.g., files, pictures, movies, websites, and/or other content associated with the first user) in the first user machine's shared portion of the local storage device, all the user data can be encrypted such that only machines associated with in-group users can access the user data. For example, the first user machine may also receive and store a stranger's user data (because the first user machine is part of the community internet drive), but if the stranger user is unassociated with any of the user's in-group(s), the stranger's user data can be encrypted such that the first user machine is unable to decipher the stranger's user data despite the stranger's data being physically stored on the user's computer (e.g., in the local portion of the local storage device). A file may be received from a user for storage in a first machine's shared storage partition, as described in McEntee paragraph [0022], The first user machine can then be configured to execute the configuration data, including partitioning its local storage device into a private portion and a shared portion. This partitioning may be performed by enabling the first use of the first machine to select one or more local directories (e.g., one or more folders included in the first computer's hard drive) to be mounted (e.g., or otherwise added to) the community internet drive. While the local directories that are mounted to the community internet drive can be considered “a shared portion” of the first machine's local storage device, other directories that are not mounted to the community internet drive can be considered the private portion of the local storage device that is excluded from the community internet drive).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan with those of McEntee, Romero and Gunther. McEntee teaches a process by which a file can be received from a user device and be stored on the aforementioned shared partition. This allows for certain files to be immediately stored on shared storage, which can allow for greater access for various user devices, as well as operations such as direct file transfers or file data inspections, as well as easier further spreading of the data file or duplicates (McEntee paragraphs [0029-0030], In some embodiments, URI construction can include creating an identifier to an instance of data. The URI can be unique in the sense of identifying one exact instance of data on one particular community machine, but it can be possible to generate more than one URI to that instance of data in some embodiments. In other words, in some embodiments, the URI may not guarantee there are not multiple copies of the data, or that another different URI may not be pointing to an identical copy, or that contents do not change over time. This differs from other types of URIs/UUIDs that may be unique and one-to-one based on file contents, or that are designed to identify the same logical file entity even as it passes through revisions. The centralized management functionality of the community internet drive may be provided by a managed hub, which may be implemented in hardware, firmware and/or software. The managed hub can configure systems to inspect the URI and/or route the request to connect some number of community machines as peers to satisfy the request. The managed hub can also be configured to track duplicates (through, e.g., metadata comparisons, direct file or data inspection, and/or simply tracking associations generated from past successful copy events, among other ways). Each copy made is traceable to the progenitor of initial introduction to the community internet drive, and each duplicate can potentially be used as another available peer).
Claim 17 is the corresponding method claim to claim 8. It is rejected with the same references and rationale.
Regarding claim 9, Bhooshan in view of McEntee in further view of Romero in further view of Gunther teaches The host device of claim 1, wherein the non-volatile memory includes removable storage (McEntee paragraph [0060], In some embodiments, storage device 126 may include one or more tangible, non-transitory memory devices such as, for example, volatile and/or non-volatile memory that may be either fixed or removable. Storage device 126 may be configured to store information, data, applications, instructions or the like for enabling each machine of system 100 to carry out various functions in accordance with exemplary embodiments of the present invention. For example, storage device 126 can be configured to buffer input data for processing by processor 128, community management circuitry 118A and/or community management circuitry 118B. Additionally or alternatively, storage device 126 could be configured to store instructions for execution by processor 128 and/or community management circuitry 118A and/or community management circuitry 118B, such as those discussed in connection with FIGS. 6-11).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan with those of McEntee, Romero and Gunther. McEntee teaches having a storage device containing non-volatile memory which may be removable. Allowing for removable non-volatile memory increases the overall flexibility of the memory and can allow for replacement storage/memory components to be added when optimal, resulting in better performance for specific purposes/operations (McEntee paragraph [0060], In some embodiments, storage device 126 may include one or more tangible, non-transitory memory devices such as, for example, volatile and/or non-volatile memory that may be either fixed or removable. Storage device 126 may be configured to store information, data, applications, instructions or the like for enabling each machine of system 100 to carry out various functions in accordance with exemplary embodiments of the present invention. For example, storage device 126 can be configured to buffer input data for processing by processor 128, community management circuitry 118A and/or community management circuitry 118B. Additionally or alternatively, storage device 126 could be configured to store instructions for execution by processor 128 and/or community management circuitry 118A and/or community management circuitry 118B, such as those discussed in connection with FIGS. 6-11).
Claim 18 is the corresponding method claim to claim 9. It is rejected with the same references and rationale.
Regarding claim 10, Bhooshan in view of McEntee in further view of Romero in further view of Gunther teaches The host device of claim 1, wherein the one or more processors are further configured to: (see claim 1 above) receive a second request for access from a second client device; and provide access to the second shared partition (McEntee paragraph [0072-0073], The managed hub can be configured to enable a user to choose a folder, such as mount point 206B, to contain a subtree to publish in association with the user. In response to the user indicating a desire to use a locally stored folder as a mount point in the community internet drive, community machine 116 can be configured to make the data within the chosen folder (and/or any subfolders) shared data. As such, the data within the chosen folder can be considered “transferred” and/or added to the “shared portion” (e.g., local internet drive 122A/B) of the storage device (e.g., storage device 126) from the “private portion” of the storage device (e.g., the portion of the storage device 126 that is excluded from the community internet drive). In the example shown by FIG. 3, the user's published data, in the shared portion of the storage device, includes a link 304 to other content on the community internet drive associated with the user. The link 304 can refer to any other file or folder, whether from the shared portion of the member's storage, or elements of the otherwise private portion of local storage that are shared individually through that reference, or even references to other data within the community internet drive from other members (where the linking member must always have access to the linked content). Link 304 can be implemented in any suitable way or combination thereof, including without limitation using operating system features for writing a file, making an entry in a file containing this and other settings, and/or adding a record to a database, among other things. The shared partition may be accessed in response to a request received from a client/user) responsive to verifying that the second displayed coded image includes credential information associated with the second shared partition (Bhooshan paragraph [0046], In response to a determination that the database of authorized users 128 does include the user device information 106DI, access to the network 110 is granted to the user 104 through the user device 106, as indicated at block 306. Specific access and control rights may be determined by IDM agent 116 in conjunction with IDM policy database 124. However, if a determination that the database of authorized users 128 does not include the user device information 106DI, at block 308, user information 104UI is received. More particularly, for instance, the user 104 may be prompted to input the user information 104UI, such as, a user name, user identification, password, and/or other credentials, and the user 104 may input the requested user information 104UI. Alternatively, this information may be provided based on information encoded in a QR code, as more fully discussed below. In addition, the switch 108 may redirect the user information 104UI to the SNAC registration server 122 as indicated by the line labeled “MAC-AUTH-FAILURE-REDIRECT”.)
Claim 19 is the corresponding method claim to claim 10. It is rejected with the same references and rationale.
Regarding claim 21, Bhooshan in view of McEntee in further view of Romero in further view of Gunther teaches The host device of claim 1, wherein the one or more processors are further configured to: receive, from the first client device, a request to make the host device available to provide the file to the first client device; and provide a notification to the first client device regarding when the host device is available to provide the file to the first client device (McEntee paragraph [0030], The centralized management functionality of the community internet drive may be provided by a managed hub, which may be implemented in hardware, firmware and/or software. The managed hub can configure systems to inspect the URI and/or route the request to connect some number of community machines as peers to satisfy the request. The managed hub can also be configured to track duplicates (through, e.g., metadata comparisons, direct file or data inspection, and/or simply tracking associations generated from past successful copy events, among other ways). Each copy made is traceable to the progenitor of initial introduction to the community internet drive, and each duplicate can potentially be used as another available peer. The client may request data (i.e., a file) and can provide access to the file via the host, also see McEntee paragraph [0031], The central hub can also be configured to protect the publisher's data and IP addresses by checking access permissions before connecting peers. As yet another example, the central hub can also manage individual point-to-point connections, where the “publisher” (the community member publishing data to the community internet drive) provides keys to specific individuals for specific data or files. Wherein specific keys (i.e., access) can be provided to grant access to specific files).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan with those of McEntee, Romero and Gunther. McEntee teaches having a storage device containing non-volatile memory which may be removable. Allowing for removable non-volatile memory increases the overall flexibility of the memory and can allow for replacement storage/memory components to be added when optimal, resulting in better performance for specific purposes/operations (McEntee paragraph [0060], In some embodiments, storage device 126 may include one or more tangible, non-transitory memory devices such as, for example, volatile and/or non-volatile memory that may be either fixed or removable. Storage device 126 may be configured to store information, data, applications, instructions or the like for enabling each machine of system 100 to carry out various functions in accordance with exemplary embodiments of the present invention. For example, storage device 126 can be configured to buffer input data for processing by processor 128, community management circuitry 118A and/or community management circuitry 118B. Additionally or alternatively, storage device 126 could be configured to store instructions for execution by processor 128 and/or community management circuitry 118A and/or community management circuitry 118B, such as those discussed in connection with FIGS. 6-11).
Claim 23 is the corresponding method claim to device claim 21. It is rejected with the same references and rationale.
Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhooshan in view of McEntee in further view of Romero in further view of Gunther as applied to claim 1 above, and further in view of Heikkinen et al. (US Publication No. 2021/0382587 -- "Heikkinen").
Regarding claim 3, Bhooshan in view of McEntee in further view of Romero in further view of Gunther and further in view of Heikkinen teaches The host device of claim 1, wherein the generated coded image comprises a matrix barcode (Heikkinen paragraph [0020], In certain example embodiments, an encoded image based messaging system (hereinafter referred to as the “system”), is configured to perform operations that include: causing display of a media item within a graphical user interface at a client device, the graphical user interface including a set of graphical elements; receiving a selection of a graphical element from among the set of graphical elements within the graphical user interface; generating a reference to the media item based on the selection of the graphical element; encoding a matrix barcode with the reference to the media item; and generating a presentation of the media item that includes a display of the matrix barcode at a position within the media item. A matrix barcode may be used for the coded/encoded image described above).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan, McEntee, and Romero and Gunther with those of Heikkinen. Heikkinen teaches using a coded image comprising a matrix barcode, which may allow the system to provide the coded image with additional details such as referencing the media item, as well as providing additional instructions and inputs (i.e., URL) to the graphical display of said coded image (Heikkinen paragraph [0020-0021], generating a reference to the media item based on the selection of the graphical element; encoding a matrix barcode with the reference to the media item; and generating a presentation of the media item that includes a display of the matrix barcode at a position within the media item. In some embodiments, the set of graphical elements may comprise graphical icons, or digital “stickers,” which a user may select and position upon a display of media content, such as an image of video, presented within the GUI at the client device. According to certain embodiments, a sticker may include a graphical icon or element which comprises an illustration of a character or object. Users may provide inputs to select and position stickers within media content or messages based on inputs received via the client device 102. In certain embodiments, the set of graphical elements may include a sticker, or graphical element, that depicts a matrix barcode. A user may provide an input to select the graphical element and “drag and drop” the graphical element at a position within media content presented within the GUI. Responsive to receiving the input that selects and positions the graphical element, the system may generate and encode a matrix barcode with one or more instructions. For example, the one or more instructions may include a reference to the media item (i.e., a URL), wherein the reference to the media item may cause a client device to navigate to a position of the media item among a collection of media items (i.e., a story)).
Claim 13 is the corresponding method claim to claim 3. It is rejected with the same references and rationale.
Claim(s) 7 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhooshan in view of McEntee in further view of Romero in further view of Gunther as applied to claim 1 above, and further in view of Niu et al. (US Publication No. 2016/0140041 -- "Niu").
Regarding claim 7, Bhooshan in view of McEntee in further view of Romero in further view of Gunther and further in view of Niu teaches The host device of claim 1, wherein the one or more processors are further configured to dynamically generate the first shared partition of the non-volatile memory (Niu paragraph [0103], In an embodiment, the shared partitions 530 include uniform partitions implemented with uniform partitioning of the memory block 512. The shared partitions 530 can ensure each of the threads 550 is allocated a dedicated amount or capacity of the memory 512. The private partitions 540 can include demand partition implemented with per demand or demand partitioning. The private partitions 540 can accommodate requirements for input and output (I/O) intensive of the threads 550. A ratio of sizes for the shared partitions 530 and the private partitions 540 can be predetermined, dynamic, or active based on a preset value, setting by the interface 504, setting by the system device 240 of FIG. 2, or combination thereof. As stated above, the shared partition for NVM can be generated dynamically if desired).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan, McEntee, and Romero and Gunther with those of Niu. Niu teaches a process of dynamically generating a shared partition for non-volatile memory storage. This is a clear improvement as it allows for a greater degree of flexibility when generating the shared storage, allowing for an altered size depending on how much of the data is intended for private storage and how much is intended to ultimately be shared between devices (Niu paragraphs [0104-0105], In an embodiment, sizes of the private partitions 540 can be determined by the number of the requests 354 for each of the threads 350, and the shared partitions can be uniformly sized or partitioned based on the number of the thread 350, based on system information such as the system information 242 of FIG. 2. The adaptive partitioning of the memory block 512 with both uniform partitioning and demand or per demand partitioning, can provide significantly improved thread-level quality of service (QoS), with the dedicated amount or capacity of the memory 512 and accommodating or meeting requirements for input and output (I/O) intensive threads 550. For example, the ratio of sizes for the shared partitions 530 and the private partitions 540 can be equal to one (1). Thus, the shared partitions 530 and the private partitions 540 will be equal in size. The shared partitions 530 can be equally divided or partitioned into three (3) partitions based on the three threads 530 including the first thread 562, the second thread 564, and the third thread 566).
Claim 16 is the corresponding method claim to claim 7. It is rejected with the same references and rationale.
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bhooshan in view of McEntee in further view of Romero in further view of Gunther as applied to claim 1 above, and further in view of Yu et al. (US Publication No. 2022/0038519 – “Yu”).
Regarding claim 22, Bhooshan in view of McEntee in further view of Romero in further view of Gunther and further in view of Yu teaches The host device of claim 1, wherein the file is transferred using a peer-to-peer file transfer (Yu Fig. 5; Yu paragraphs [0090-0091], Detailed Description of Example Embodiments of System for Sharing a Peripheral Device Over a Peer-to-Peer Connection FIG. 5 shows additional details of the example implementation of the system 100 for sharing a peripheral device over a peer-to-peer connection introduced above in connection with FIGS. 1A-C. In the illustrated system, the first device 104 and the second device 108 may each be a computing system configured like the computing system 246 shown in FIG. 2B. The device sharing system 102 may likewise be embodied by one or more such computing systems. The data can be transferred from a shared partition to a client/user device, which can include the transfer of files, such as in Yu paragraph [0067], The client(s) 202 may be any type of computing devices capable of accessing the resource feed(s) 406 and/or the SaaS application(s) 410, and may, for example, include a variety of desktop or laptop computers, smartphones, tablets, etc. The resource feed(s) 406 may include any of numerous resource types and may be provided from any of numerous locations. In some embodiments, for example, the resource feed(s) 406 may include one or more systems or services for providing virtual applications and/or desktops to the client(s) 202, one or more file repositories and/or file sharing systems, one or more secure browser services, one or more access control services for the SaaS applications 410, one or more management services for local applications on the client(s) 202, one or more internet enabled devices or sensors, etc. Each of the resource management service(s) 402, the resource feed(s) 406, the gateway service(s) 408, the SaaS application(s) 410, and the identity provider 412 may be located within an on-premises data center of an organization for which the system 400 is deployed, within one or more cloud computing environments, or elsewhere).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the teaching of Bhooshan, McEntee, and Romero and Gunther with those of Yu. Yu teaches enabling the transfer of data files utilizing a peer-to-peer transfer system, which can provide access between storage devices, allowing for authorization to be efficiently implemented (i.e., see Yu paragraph [0037], After receiving a request to access the peripheral device 106, the device sharing system 102 may (at a step 116) cause a peer-to-peer connection 118 to be established between the first device 104 and the second device 108. In some embodiments, the device sharing system 102 may also take one or more additional steps to determine whether to allow the second device 108 to access the peripheral device 106 prior to causing the peer-to-peer connection 118 to be established. For example, in implementations in which the second device 108 and/or the user of the second device 108 has not already been granted access privileges for the peripheral device 106, the device sharing system 102 may seek authorization by the user of the first device 104 and/or a system administrator prior to allowing the second device 108 to access the peripheral device 106 over the peer-to-peer connection 118).
Response to Arguments
Applicant’s arguments, see page 1 (numbered page 10), filed January 29th, 2026 with respect to the rejection(s) of claim(s) 1, 11 and 20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Bhooshan (US Publication No. 2015/0288670 -- "Bhooshan") in view of McEntee (US Publication No. 2018/0013621 -- "McEntee") in further view of Romero et al. (US Publication No. 2020/0145414 – “Romero”) in further view of Gunther et al. (US Publication No. 2024/0372855 – “Gunther”).
In response to the applicant’s amendments to independent claims 1, 11 and 20, a new reference has been added. The Gunther reference is targeted towards the amended limitations regarding sending a notification to initiate communication between a host device and a client device that has been determined to be trusted, as described in further detail in the rejection above. In light of the newly added reference, the 35 USC 103 Rejection is maintained.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONAH C KRIEGER whose telephone number is (571)272-3627. The examiner can normally be reached Monday - Friday 8 AM - 5 PM.
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, Rocio Del Mar Perez-Velez can be reached on (571)-270-5935. 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.
/J.C.K./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133