DETAILED ACTION
This Action is responsive to the Application filed on 07/18/2025.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Status
Claims 1-20 are presented. Claims 1-20 are pending and have been examined.
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.
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.
Claims 1, 7, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Caraccio et al. (US 20170083260 A1)(hereafter referred to as Caraccio) further in view of an online public disclosure authored by Rizvi entitled “Introduction to UFS Subsystem” (published at least 07/03/2024)(accessed by examiner via Wayback Machine)(hereafter referred to as Rizvi).
Regarding Claim 1,
Caraccio discloses the following limitations:
A memory system (System 10, Fig. 1), comprising:
one or more memory devices (Non-Volatile Memory 26, Fig.1); and
processing circuitry (Controller 23, Fig. 1) coupled with the one or more memory devices and configured to cause the memory system to:
receive (Fig. 18) a write command (“packed commands” [0128])(“Packed commands allow multiple write operations in a single transaction” [0128]) comprising
one or more header segments (Packed Commands 452 + CMD25 384 + Packed Command Header 454, Fig. 18) and one or more data segments (Data Blocks 46, Fig. 18)(“As the host 12 desires to provide packed operations to the device 14, one or more CMD23 commands 362 are provided to the device 14. The CMD23 commands 362 include packed operations 452 … the host may provide a write command (e.g., a CMD25 command 384), which may trigger the actual data write operation … provision of a packed command header 454 may precede provision of the data blocks 46” [0130-131]) – As shown in Fig. 18, in order to perform a packed write operation on a memory device, a host provides “one or more CMD23 commands” (see Packed Operation 450), a CMD25 command 384, a packed command header 454, and plural data blocks 46 to a memory device in order to communicate write data to the memory device. Examiner accordingly considers the Packed Commands 452, the CMD25 384, and the Packed Command Header 454 as “one or more header segments” transmit to the memory device, and the data blocks 46 as “one or more data segments”--,
the one or more header segments comprising a first set of one or more bits (Packed Commands 452 + CMD25 384) – Examiner considers the bits comprising the plural packed commands 452 and the CMD25 command 384 of Fig. 18 as “a first set of one or more bits” of the one or more header segments-- … and
a second set of one or more bits (Version Field 456 + Attributes 28, Fig. 18) corresponding to one or more storage configurations (“a special write” [0131]) for storing data included in the one or more data segments (“The packed command header 454 may include an version field 456 that may act as an indication 98 that a special write is to be executed (e.g., file-based access). For example, the protocol may define that the version is 0. Thus, the version may be modified from zero to provide the indication 98. When the indication 98 is present, the metadata and/or attributes 28 may be obtained from the packed command header.” [0131-132]) – A “version write field” of the packed command header indicates whether an associated operation should be a “special write” (when version byte is set to 1); and should not be a special write otherwise (when version byte is set to 0). When the version write field bit is set, corresponding attributes 28 (including a file ID and a metadata flag) are additionally included within the packed command header 454. Accordingly, the version write field and attributes bytes 28 of the packed command header 454 correspond to “a second set of one or more bits” which correspond to “one or more storage configurations” (e.g., a “special write” configuration vs. not)--; and
store, in response to receiving (Fig. 18) the write command and based on the second set of one or more bits (CMD25 command 384, Fig. 18), the data of the one or more data segments to a storage location (“a write command start address” [0119]) of the one or more memory devices determined based on the first set of one or more bits. (“a packed command header 454 may precede provision of the data blocks 46” [0131] // “Upon receiving data from the host device 12, the controller 23 may transfer the files 20 to non-volatile memory 26 of the non-volatile managed memory system” [0029] // “the host 12 may provide a write command start address (e.g., a CMD25 command 384), which may trigger the actual data write operation” [0119] // Figs. 1 + 18) – As shown in Figs. 1 + 18 and taught in ¶0029, data blocks 46 received from a host (i.e., files 20 of Fig. 1) are written into non-volatile memory 26 by controller 23. As clarified in ¶0119, the CMD25 384 transmit by the host to the memory device (see Fig. 18) provides “a write command start address” to the memory device (i.e., to a write address “determined based on the first set of one or more bits”).
Although Caraccio Fig. 18 shows several bits (e.g., context ID field 374) which are included within a packed command 452, Caraccio does not explicitly disclose the following limitations:
the one or more header segments comprising a first set of one or more bits corresponding to a host process associated with the write command
However, Rizvi provides an overview of command headers associated with traditional UFS commands. Rizvi discloses the following limitations:
the one or more header segments (UPIU Header, Slides 19 + 20) comprising a first set of one or more bits (Initiator ID, Slide 20) corresponding to a host process (Initiator, Slide 18) associated with the write command (“Transactions consist of packets called UFS Protocol Information Units (IPIU). The host is the Initiator and the device is the Target … Each UPIU contains a 12 bytes header followed by optional fields” [Slide 18] // UPIU Header [Slide 19] // Initiator ID [Slide 20]) – As taught in Rizvi, a host initiator transmits UFS packets to a memory device target, similar to how a host 12 of Caraccio transmits commands to memory device 14 as part of performing packed operations. Examiner accordingly considers the UPIU Header depicted in Rizvi Slide 19 as analogous to the packed commands 452 and CMD25 command 384 of Caraccio Fig. 18 (i.e., “the first set of one or more bits”). As shown in Rizvi Slide 20, the UPIU header comprises an initiator ID (i.e., an ID of “a host process associated with the write command”)--
Caraccio and Rizvi are considered analogous to the claimed invention because they all relate to the same field of formatting command headers of write operations sent from a host to a memory device. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio with the teachings of Rizvi and realize a packed command header which uses a UPIU header including an initiator ID. Doing so enables a host and a memory device to communicate using a UFS protocol and thereby achieve high performance benefits realized by UFS protocols in low power applications, as disclosed in Rizvi Slide 5: “UFS Features … a high performance serial interface designed for low power devices” [Slide 5]
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The memory system of claim 1, wherein, to store the data, the processing circuitry is configured to cause the memory system to: store the data in a physical location with second data associated with the host process. (Caraccio, “Packed commands allow multiple write operations in a single transaction … as illustrated, provision of a packed command header 454 may precede provision of data blocks 46” [0128-131] // Fig. 18) – As previously discussed and as taught in Caraccio, the packed command header enables plural data blocks 46 to be written as a single transaction. In such an embodiment, a first data block 46 would be written with at least a second data block 46 as part of the single, packed transaction. Accordingly, a first data block 46 is written to device 16 as part of the same transaction as a second data block 46 (i.e., is written to device 16 “with second data associated with the host process”)
Regarding Claim 9,
Caraccio discloses the following limitations:
A host system (System 10, Fig. 1), comprising: one or more interfaces comprising one or more signal paths (Memory System Protocol 16, Fig. 1 // ¶0027) operable for communications with one or more memory systems (Memory Device 14, Fig. 1); and
processing circuitry (Host Device 12, Fig. 1) coupled with the one or more interfaces and configured to cause the host system to:
determine (Fig. 18) data to be stored at a memory system (“Packed commands allow multiple write operations in a single transaction” [0128] // Fig. 18) – As shown in Fig. 18, host 12 can send a “packed” type of command to memory device 14 which causes multiple write operations to be performed.-- ;
… and
transmit (Fig. 18), from the host system, a write command (“packed commands” [0128]) comprising one or more header segments (Packed Commands 452 + CMD25 384 + Packed Command Header 454, Fig. 18) and one or more data segments (Data Blocks 46, Fig. 18)(“As the host 12 desires to provide packed operations to the device 14, one or more CMD23 commands 362 are provided to the device 14. The CMD23 commands 362 include packed operations 452 … the host may provide a write command (e.g., a CMD25 command 384), which may trigger the actual data write operation … provision of a packed command header 454 may precede provision of the data blocks 46” [0130-131]) – As shown in Fig. 18, in order to perform a packed write operation on a memory device, a host provides “one or more CMD23 commands” (see Packed Operation 450), a CMD25 command 384, a packed command header 454, and plural data blocks 46 to a memory device in order to communicate write data to the memory device. Examiner accordingly considers the Packed Commands 452, the CMD25 384, and the Packed Command Header 454 as “one or more header segments” transmit to the memory device, and the data blocks 46 as “one or more data segments”--,
the one or more header segments comprising a first set of one or more bits (Packed Commands 452 + CMD25 384) – Examiner considers the bits comprising the plural packed commands 452 and the CMD25 command 384 of Fig. 18 as “a first set of one or more bits” of the one or more header segments-- … and
a second set of one or more bits (Version Field 456 + Attributes 28, Fig. 18) corresponding to one or more storage configurations (“a special write” [0131]) for storing the data included in the data segments (“The packed command header 454 may include an version field 456 that may act as an indication 98 that a special write is to be executed (e.g., file-based access). For example, the protocol may define that the version is 0. Thus, the version may be modified from zero to provide the indication 98. When the indication 98 is present, the metadata and/or attributes 28 may be obtained from the packed command header.” [0131-132]) – A “version write field” of the packed command header indicates whether an associated operation should be a “special write” (when version byte is set to 1); and should not be a special write otherwise (when version byte is set to 0). When the version write field bit is set, corresponding attributes 28 (including a file ID and a metadata flag) are additionally included within the packed command header 454. Accordingly, the version write field and attributes bytes 28 of the packed command header 454 correspond to “a second set of one or more bits” which correspond to “one or more storage configurations” (e.g., a “special write” configuration vs. not).
Although Caraccio Fig. 18 shows several bits (e.g., context ID field 374) which are included within a packed command 452, Caraccio does not explicitly disclose the following limitations:
determine a host process associated with the data;
the one or more header segments comprising a first set of one or more bits corresponding to the host process associated with the data
However, Rizvi provides an overview of command headers associated with traditional UFS commands. Rizvi discloses the following limitations:
determine a host process associated with the data; (“Transactions consist of packets called UFS Protocol Information Units (IPIU). The host is the Initiator and the device is the Target … Each UPIU contains a 12 bytes header followed by optional fields” [Slide 18]) – As taught in Rizvi, each write command including a UPIU is generated by particular host/initiator. Accordingly, generating a write command including a UPIU at least includes “determining a host process associated with the data” (i.e., determining an initiator for a write command)--
the one or more header segments (UPIU Header, Slides 19 + 20) comprising a first set of one or more bits (Initiator ID, Slide 20) corresponding to the host process (Initiator, Slide 18) associated with the data (“Transactions consist of packets called UFS Protocol Information Units (IPIU). The host is the Initiator and the device is the Target … Each UPIU contains a 12 bytes header followed by optional fields” [Slide 18] // UPIU Header [Slide 19] // Initiator ID [Slide 20]) – As taught in Rizvi, a host initiator transmits UFS packets to a memory device target, similar to how a host 12 of Caraccio transmits commands to memory device 14 as part of performing packed operations. Examiner accordingly considers the UPIU Header depicted in Rizvi Slide 19 as analogous to the packed commands 452 and CMD25 command 384 of Caraccio Fig. 18 (i.e., “the first set of one or more bits”). As shown in Rizvi Slide 20, the UPIU header comprises an initiator ID (i.e., an ID of “a host process associated with the write command”)--
Caraccio and Rizvi are considered analogous to the claimed invention because they all relate to the same field of formatting command headers of write operations sent from a host to a memory device. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio with the teachings of Rizvi and realize a packed command header which uses a UPIU header including an initiator ID. Doing so enables a host and a memory device to communicate using a UFS protocol and thereby achieve high performance benefits realized by UFS protocols in low power applications, as disclosed in Rizvi Slide 5: “UFS Features … a high performance serial interface designed for low power devices” [Slide 5]
Regarding Claim 16,
Caraccio discloses the following limitations:
A method by a memory system (System 10, Fig. 1), comprising:
receiving (Fig. 18), at the memory system, a write command (“packed commands” [0128])(“Packed commands allow multiple write operations in a single transaction” [0128]) comprising
one or more header segments (Packed Commands 452 + CMD25 384 + Packed Command Header 454, Fig. 18) and one or more data segments (Data Blocks 46, Fig. 18)(“As the host 12 desires to provide packed operations to the device 14, one or more CMD23 commands 362 are provided to the device 14. The CMD23 commands 362 include packed operations 452 … the host may provide a write command (e.g., a CMD25 command 384), which may trigger the actual data write operation … provision of a packed command header 454 may precede provision of the data blocks 46” [0130-131]) – As shown in Fig. 18, in order to perform a packed write operation on a memory device, a host provides “one or more CMD23 commands” (see Packed Operation 450), a CMD25 command 384, a packed command header 454, and plural data blocks 46 to a memory device in order to communicate write data to the memory device. Examiner accordingly considers the Packed Commands 452, the CMD25 384, and the Packed Command Header 454 as “one or more header segments” transmit to the memory device, and the data blocks 46 as “one or more data segments”--,
the one or more header segments comprising a first set of one or more bits (Packed Commands 452 + CMD25 384) – Examiner considers the bits comprising the plural packed commands 452 and the CMD25 command 384 of Fig. 18 as “a first set of one or more bits” of the one or more header segments-- … and
a second set of one or more bits (Version Field 456 + Attributes 28, Fig. 18) corresponding to one or more storage configurations (“a special write” [0131]) for storing data included in the one or more data segments (“The packed command header 454 may include an version field 456 that may act as an indication 98 that a special write is to be executed (e.g., file-based access). For example, the protocol may define that the version is 0. Thus, the version may be modified from zero to provide the indication 98. When the indication 98 is present, the metadata and/or attributes 28 may be obtained from the packed command header.” [0131-132]) – A “version write field” of the packed command header indicates whether an associated operation should be a “special write” (when version byte is set to 1); and should not be a special write otherwise (when version byte is set to 0). When the version write field bit is set, corresponding attributes 28 (including a file ID and a metadata flag) are additionally included within the packed command header 454. Accordingly, the version write field and attributes bytes 28 of the packed command header 454 correspond to “a second set of one or more bits” which correspond to “one or more storage configurations” (e.g., a “special write” configuration vs. not)--;
and storing, in response to receiving (Fig. 18) the write command and based on the second set of one or more bits (CMD25 command 384, Fig. 18), the data of the one or more data segments to a storage location (“a write command start address” [0119]) of the one or more memory devices determined based on the first set of one or more bits. (“a packed command header 454 may precede provision of the data blocks 46” [0131] // “Upon receiving data from the host device 12, the controller 23 may transfer the files 20 to non-volatile memory 26 of the non-volatile managed memory system” [0029] // “the host 12 may provide a write command start address (e.g., a CMD25 command 384), which may trigger the actual data write operation” [0119] // Figs. 1 + 18) – As shown in Figs. 1 + 18 and taught in ¶0029, data blocks 46 received from a host (i.e., files 20 of Fig. 1) are written into non-volatile memory 26 by controller 23. As clarified in ¶0119, the CMD25 384 transmit by the host to the memory device (see Fig. 18) provides “a write command start address” to the memory device (i.e., to a write address “determined based on the first set of one or more bits”).
Although Caraccio Fig. 18 shows several bits (e.g., context ID field 374) which are included within a packed command 452, Caraccio does not explicitly disclose the following limitations:
the one or more header segments comprising a first set of one or more bits corresponding to a host process associated with the write command
However, Rizvi provides an overview of command headers associated with traditional UFS commands. Rizvi discloses the following limitations:
the one or more header segments (UPIU Header, Slides 19 + 20) comprising a first set of one or more bits (Initiator ID, Slide 20) corresponding to a host process (Initiator, Slide 18) associated with the write command (“Transactions consist of packets called UFS Protocol Information Units (IPIU). The host is the Initiator and the device is the Target … Each UPIU contains a 12 bytes header followed by optional fields” [Slide 18] // UPIU Header [Slide 19] // Initiator ID [Slide 20]) – As taught in Rizvi, a host initiator transmits UFS packets to a memory device target, similar to how a host 12 of Caraccio transmits commands to memory device 14 as part of performing packed operations. Examiner accordingly considers the UPIU Header depicted in Rizvi Slide 19 as analogous to the packed commands 452 and CMD25 command 384 of Caraccio Fig. 18 (i.e., “the first set of one or more bits”). As shown in Rizvi Slide 20, the UPIU header comprises an initiator ID (i.e., an ID of “a host process associated with the write command”)--
Caraccio and Rizvi are considered analogous to the claimed invention because they all relate to the same field of formatting command headers of write operations sent from a host to a memory device. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio with the teachings of Rizvi and realize a packed command header which uses a UPIU header including an initiator ID. Doing so enables a host and a memory device to communicate using a UFS protocol and thereby achieve high performance benefits realized by UFS protocols in low power applications, as disclosed in Rizvi Slide 5: “UFS Features … a high performance serial interface designed for low power devices” [Slide 5]
Claims 2, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Caraccio further in view of Rizvi and Xu et al. (US 20250370627 A1)(hereafter referred to as Xu).
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above), wherein the write command comprises a universal flash storage (UFS) protocol information unit (UPIU) (Rizvi, “Transactions consists of packets called UFS Protocol Information Units (UPIU)” [Slide 18]), and
the one or more header segments comprise an initiator identifier (IID) field (Rizvi, Reserved, Slide 19 // Initiator ID, Slide 20)
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
the one or more header segments comprise an initiator identifier (IID) field and an extended IID field in accordance with the UPIU.
However, Xu discloses the following limitations:
the one or more header segments (Fig. 13) comprise an initiator identifier (IID) field (Byte 4, Fig. 3) and an extended IID field (Bytes 5-7, Fig. 13) in accordance with the UPIU. (Fig. 13 // “the CMD UPIU includes a frame header … a most significant bit of the 4th byte is an initiator identity (IID) … a most significant bit of the 7th byte is an EXD initiator identity (EXD_IID)” [0074]) – As shown in Fig. 13, a CMD UPIU header includes an IID field included in the 4th byte and an EXD_IID field included in the 5-7th bytes.
Caraccio, Rizvi, and Xu are all considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Xu and realize a UPIU header including both an IID field and an extended IID field. Formatting reserved bits of an UPIU header in the manner disclosed in Xu enables end-to-end data protection to be implemented for in-vehicle applications, as disclosed in Xu ¶¶0004-05: “With rapid development of a UFS technology, there may be increased requirements on data security … However, a current UFS protocol does not provide a mechanism for transferring channel-associated information of data, thereby limiting use and efficiency of UFS. This disclosure provides a channel-associated information transfer method and apparatus, and a device, to provide a UFS protocol-based channel-associated information transfer mechanism, thereby resolving a problem of limited use and efficiency of a UFS in another technology.” [0004-05]
Regarding Claim 10,
The same motivation to combine provided in Claim 9 is equally applicable to Claim 10. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The host system of claim 9 (see Claim 9 limitation mappings above), wherein the write command comprises a universal flash storage (UFS) protocol information unit (UPIU) (Rizvi, “Transactions consists of packets called UFS Protocol Information Units (UPIU)” [Slide 18]), and
the one or more header segments comprise an initiator identifier (IID) field (Rizvi, Reserved, Slide 19 // Initiator ID, Slide 20)
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
the one or more header segments comprise an initiator identifier (IID) field and an extended IID field in accordance with the UPIU.
However, Xu discloses the following limitations:
the one or more header segments (Fig. 13) comprise an initiator identifier (IID) field (Byte 4, Fig. 3) and an extended IID field (Bytes 5-7, Fig. 13) in accordance with the UPIU. (Fig. 13 // “the CMD UPIU includes a frame header … a most significant bit of the 4th byte is an initiator identity (IID) … a most significant bit of the 7th byte is an EXD initiator identity (EXD_IID)” [0074]) – As shown in Fig. 13, a CMD UPIU header includes an IID field included in the 4th byte and an EXD_IID field included in the 5-7th bytes.
Caraccio, Rizvi, and Xu are all considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Xu and realize a UPIU header including both an IID field and an extended IID field. Formatting reserved bits of an UPIU header in the manner disclosed in Xu enables end-to-end data protection to be implemented for in-vehicle applications, as disclosed in Xu ¶¶0004-05: “With rapid development of a UFS technology, there may be increased requirements on data security … However, a current UFS protocol does not provide a mechanism for transferring channel-associated information of data, thereby limiting use and efficiency of UFS. This disclosure provides a channel-associated information transfer method and apparatus, and a device, to provide a UFS protocol-based channel-associated information transfer mechanism, thereby resolving a problem of limited use and efficiency of a UFS in another technology.” [0004-05]
Regarding Claim 17,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 17. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The method of claim 16 (see Claim 16 limitation mappings above), wherein the write command comprises a universal flash storage (UFS) protocol information unit (UPIU) (Rizvi, “Transactions consists of packets called UFS Protocol Information Units (UPIU)” [Slide 18]), and
the one or more header segments comprise an initiator identifier (IID) field (Rizvi, Reserved, Slide 19 // Initiator ID, Slide 20)
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
the one or more header segments comprise an initiator identifier (IID) field and an extended IID field in accordance with the UPIU.
However, Xu discloses the following limitations:
the one or more header segments (Fig. 13) comprise an initiator identifier (IID) field (Byte 4, Fig. 3) and an extended IID field (Bytes 5-7, Fig. 13) in accordance with the UPIU. (Fig. 13 // “the CMD UPIU includes a frame header … a most significant bit of the 4th byte is an initiator identity (IID) … a most significant bit of the 7th byte is an EXD initiator identity (EXD_IID)” [0074]) – As shown in Fig. 13, a CMD UPIU header includes an IID field included in the 4th byte and an EXD_IID field included in the 5-7th bytes.
Caraccio, Rizvi, and Xu are all considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Xu and realize a UPIU header including both an IID field and an extended IID field. Formatting reserved bits of an UPIU header in the manner disclosed in Xu enables end-to-end data protection to be implemented for in-vehicle applications, as disclosed in Xu ¶¶0004-05: “With rapid development of a UFS technology, there may be increased requirements on data security … However, a current UFS protocol does not provide a mechanism for transferring channel-associated information of data, thereby limiting use and efficiency of UFS. This disclosure provides a channel-associated information transfer method and apparatus, and a device, to provide a UFS protocol-based channel-associated information transfer mechanism, thereby resolving a problem of limited use and efficiency of a UFS in another technology.” [0004-05]
Claims 3, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Caraccio further in view of Rizvi, Xu, and Jung et al. (US 20250165162 A1)(hereafter referred to as Jung).
Regarding Claim 3,
The same motivation to combine provided in Claim 2 is equally applicable to Claim 3. The combined teachings of Caraccio, Rizvi, and Xu disclose the following limitations:
The memory system of claim 2 (see Claim 2 limitation mappings above), wherein … the second set of one or more bits (Xu, Channel-associated control information, Fig. 13 // ¶0012) are located within a second portion of the extended IID field. (Xu, Fig. 13 // “channel-associated control information is carried in the reserved field in the frame header … the channel-associated control information may indicate different information to control a transfer mode of the channel-associated information“ [0011-12]) – As taught in Xu, “channel-associated control information” which impacts a transfer mode of data (analogous to “the second set of one or more bits”) is encoded within the reserved fields of bytes 5-6 (i.e., within “a second portion of the extended IID field”).
Xu does not provide explicit detail relating how an initiator identity IID stored into the IID field of byte 4 relates to an EXD initiator identity stored in the EXD_IID field of byte 7. Accordingly, the combined teachings of Caraccio, Rizvi, and Xu do not explicitly disclose the following limitations:
wherein the first set of one or more bits are located within the IID field and a first portion of the extended IID field
However, Jung discloses the following limitations:
wherein the first set of one or more bits are located within the IID field (IID Byte 4, Fig. 4) and a first portion of the extended IID field (EXT_IID byte 7, Fig. 4)(“The command UPIU CMD UPIU may include … an initiator ID (IID)” [0059] // “Referring to FIG. 4, … an identifier EXT_ID indicating a MSB nibble of an initiator identifier Nexus may be included in a field of address 7” [0061]) – As shown in Jung Fig. 4, the MSB of an initiator ID (analogous to “the first set of one or more bits”) is stored in the EXT_IID field. One of ordinary skill in the art would accordingly understand that the bits comprising the initiator ID of Fig. 4 are included both within the IID field 4 and the EXT_IID field 7 (i.e., “located within the IID field and a first portion of the extended IID field”).
Caraccio, Rizvi, Xu, and Jung are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio, Rizvi, and Xu with the teachings of Jung and realize a UPIU header whereby an initiator identifier is stored within both an IID field and in an extended IID field. Doing so is a feature of an improved UPIU header which helps prevent replay attacks, as disclosed in Jung ¶¶0004-05: “A storage device such as the UFS device may store data sensitive to users … In order to reflect measures to prevent a replay attack to the UFS standard, specific technologies preventing the replay attack have been researched. The disclosure provides a universal flash storage (UFS) device for preventing a replay attack, a method of operating the same, and a UFS system.” [0004-05]
Regarding Claim 11,
The same motivation to combine provided in Claim 10 is equally applicable to Claim 11. The combined teachings of Caraccio, Rizvi, and Xu disclose the following limitations:
The host system of claim 10 (see Claim 10 limitation mappings above), wherein … the second set of one or more bits (Xu, Channel-associated control information, Fig. 13 // ¶0012) are located within a second portion of the extended IID field. (Xu, Fig. 13 // “channel-associated control information is carried in the reserved field in the frame header … the channel-associated control information may indicate different information to control a transfer mode of the channel-associated information“ [0011-12]) – As taught in Xu, “channel-associated control information” which impacts a transfer mode of data (analogous to “the second set of one or more bits”) is encoded within the reserved fields of bytes 5-6 (i.e., within “a second portion of the extended IID field”).
Xu does not provide explicit detail relating how an initiator identity IID stored into the IID field of byte 4 relates to an EXD initiator identity stored in the EXD_IID field of byte 7. Accordingly, the combined teachings of Caraccio, Rizvi, and Xu do not explicitly disclose the following limitations:
wherein the first set of one or more bits are located within the IID field and a first portion of the extended IID field
However, Jung discloses the following limitations:
wherein the first set of one or more bits are located within the IID field (IID Byte 4, Fig. 4) and a first portion of the extended IID field (EXT_IID byte 7, Fig. 4)(“The command UPIU CMD UPIU may include … an initiator ID (IID)” [0059] // “Referring to FIG. 4, … an identifier EXT_ID indicating a MSB nibble of an initiator identifier Nexus may be included in a field of address 7” [0061]) – As shown in Jung Fig. 4, the MSB of an initiator ID (analogous to “the first set of one or more bits”) is stored in the EXT_IID field. One of ordinary skill in the art would accordingly understand that the bits comprising the initiator ID of Fig. 4 are included both within the IID field 4 and the EXT_IID field 7 (i.e., “located within the IID field and a first portion of the extended IID field”).
Caraccio, Rizvi, Xu, and Jung are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio, Rizvi, and Xu with the teachings of Jung and realize a UPIU header whereby an initiator identifier is stored within both an IID field and in an extended IID field. Doing so is a feature of an improved UPIU header which helps prevent replay attacks, as disclosed in Jung ¶¶0004-05: “A storage device such as the UFS device may store data sensitive to users … In order to reflect measures to prevent a replay attack to the UFS standard, specific technologies preventing the replay attack have been researched. The disclosure provides a universal flash storage (UFS) device for preventing a replay attack, a method of operating the same, and a UFS system.” [0004-05]
Regarding Claim 18,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 18. The combined teachings of Caraccio, Rizvi, and Xu disclose the following limitations:
The method of claim 17 (see Claim 17 limitation mappings above), wherein … the second set of one or more bits (Xu, Channel-associated control information, Fig. 13 // ¶0012) are located within a second portion of the extended IID field. (Xu, Fig. 13 // “channel-associated control information is carried in the reserved field in the frame header … the channel-associated control information may indicate different information to control a transfer mode of the channel-associated information“ [0011-12]) – As taught in Xu, “channel-associated control information” which impacts a transfer mode of data (analogous to “the second set of one or more bits”) is encoded within the reserved fields of bytes 5-6 (i.e., within “a second portion of the extended IID field”).
Xu does not provide explicit detail relating how an initiator identity IID stored into the IID field of byte 4 relates to an EXD initiator identity stored in the EXD_IID field of byte 7. Accordingly, the combined teachings of Caraccio, Rizvi, and Xu do not explicitly disclose the following limitations:
wherein the first set of one or more bits are located within the IID field and a first portion of the extended IID field
However, Jung discloses the following limitations:
wherein the first set of one or more bits are located within the IID field (IID Byte 4, Fig. 4) and a first portion of the extended IID field (EXT_IID byte 7, Fig. 4)(“The command UPIU CMD UPIU may include … an initiator ID (IID)” [0059] // “Referring to FIG. 4, … an identifier EXT_ID indicating a MSB nibble of an initiator identifier Nexus may be included in a field of address 7” [0061]) – As shown in Jung Fig. 4, the MSB of an initiator ID (analogous to “the first set of one or more bits”) is stored in the EXT_IID field. One of ordinary skill in the art would accordingly understand that the bits comprising the initiator ID of Fig. 4 are included both within the IID field 4 and the EXT_IID field 7 (i.e., “located within the IID field and a first portion of the extended IID field”).
Caraccio, Rizvi, Xu, and Jung are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio, Rizvi, and Xu with the teachings of Jung and realize a UPIU header whereby an initiator identifier is stored within both an IID field and in an extended IID field. Doing so is a feature of an improved UPIU header which helps prevent replay attacks, as disclosed in Jung ¶¶0004-05: “A storage device such as the UFS device may store data sensitive to users … In order to reflect measures to prevent a replay attack to the UFS standard, specific technologies preventing the replay attack have been researched. The disclosure provides a universal flash storage (UFS) device for preventing a replay attack, a method of operating the same, and a UFS system.” [0004-05]
Claims 4, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Caraccio further in view of Rizvi and Lee (US 20250356063 A1)(hereafter referred to as Lee).
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
wherein, to store the data, the processing circuitry is configured to cause the memory system to: store the data to a set of single-level memory cells of the one or more memory devices in response to a first bit of the second set of one or more bits corresponding to whether the data is high performance data.
However, Lee discloses the following limitations:
wherein, to store the data, the processing circuitry is configured to cause the memory system to: store the data to a set of single-level memory cells (RPMB 110a, Fig. 1 // ¶0042) of the one or more memory devices (Memory Device 100, Fig. 1)(“The memory device 100 may include a memory cell array … Each of the memory cells may be configured as a Single Level Cell (SLC) … The memory blocks included in the memory device 100 may include a Replay Protected Memory Block (RPMB) 110a and a normal block (Normal BLK) 110b. The RPMB 110a may be a memory block accessed through a predetermined specific command or authentication” [0042-45]) – Examiner considers the storage environment depicted in Lee Fig. 1 as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Lee, data is written to a RPMB 110a region of memory device 100. Each memory cell in memory device 100 can be configured as an SLC cell. Accordingly, storing data to the RPMB 110a corresponds to storing “the data to a set of single-level memory cells of the one or more memory devices” (i.e., storing data into a particular SLC cell which is located within a memory device).--
in response to a first bit (RPMB ON, Fig. 16) of the second set of one or more bits corresponding to whether the data is high performance data. (Fig. 16 // “whether the high speed RPMB mode is to be used may be checked using a fifth byte included in the basic header segment. That is, the host 400 and the storage device 50 may determine whether the value of the fifth byte included in the basic header segment of the Response UPIU is a non-zero value, and check that the high speed RPMB mode is used when a value that is not 0 is included in the basic header segment” [0233] // “In an embodiment, an access mode of the RPMB 110a may be set as the normal RPMB mode, the advanced RPMB mode, or the high speed RPMB mode” [0055]) – As shown in Fig. 16, RPMB ON of Byte 5 of a UPIU header communicates whether or not data should be stored to the RPMB 110a according to a “high speed” mode; similar to how the Version Field 456 and Attributes 28 of Caraccio Fig. 18 specify a storage configuration for corresponding data blocks. Examiner accordingly considers the RPMB ON byte of Lee Fig. 16 as analogous to “the second set of one or more bits” included within a header. As taught in Lee, data is written into RPMB 110a in a “high speed” mode (as opposed to a “normal” or “advanced” mode; see ¶0055) when the byte 5 RPMB ON indicates that high speed mode should be used. Examiner considers data which is stored according to a high speed mode as reading on the claimed concept of “high performance data”. Accordingly, when the RPMB ON byte 5 of a UPIU basic header segment indicates a high speed RPMB mode, the corresponding data associated with the header is recognized as being high performance (via indication of the high speed mode) and is written into the RPMB 110a region of memory.
Caraccio, Rizvi, and Lee are all considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Lee and realize a UPIU header which indicates high performance data to be written to a particular set of memory cells including within a memory device. Using a command header to signal high performance data enables a storage device to support multiple modes of operation without requiring a hardware change by repurposing data of a previously defined command, which is advantageous as disclosed in Lee ¶0240: “However, in the high speed RPMB mode in accordance with embodiments of the present disclosure, a data segment included in a previously defined command is used, and therefore, a change to the design of hardware is not required. That is, the storage device 50 supporting an existing normal RPMB mode can support a high speed RPMB mode only by updating software, which is advantageous.” [0240]
Regarding Claim 12,
The same motivation to combine provided in Claim 9 is equally applicable to Claim 12. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The host system of claim 9 (see Claim 9 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
wherein a value of a first bit of the second set of one or more bits indicates to store the data to a set of single-level memory cells of the memory system based on the data being high performance data.
However, Lee discloses the following limitations:
wherein, a value of a first bit (RPMB ON, Fig. 16) of the second set of one or more bits indicates to store the data to a set of single-level memory cells (RPMB 110a, Fig. 1 // ¶0042) of the memory system (Memory Device 100, Fig. 1)(“The memory device 100 may include a memory cell array … Each of the memory cells may be configured as a Single Level Cell (SLC) … The memory blocks included in the memory device 100 may include a Replay Protected Memory Block (RPMB) 110a and a normal block (Normal BLK) 110b. The RPMB 110a may be a memory block accessed through a predetermined specific command or authentication” [0042-45]) – Examiner considers the storage environment depicted in Lee Fig. 1 as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Lee, data is written to a RPMB 110a region of memory device 100. Each memory cell in memory device 100 can be configured as an SLC cell. Accordingly, storing data to the RPMB 110a corresponds to storing “the data to a set of single-level memory cells of the one or more memory devices” (i.e., storing data into a particular SLC cell which is located within a memory device).--
based on the data being high performance data. (Fig. 16 // “whether the high speed RPMB mode is to be used may be checked using a fifth byte included in the basic header segment. That is, the host 400 and the storage device 50 may determine whether the value of the fifth byte included in the basic header segment of the Response UPIU is a non-zero value, and check that the high speed RPMB mode is used when a value that is not 0 is included in the basic header segment” [0233] // “In an embodiment, an access mode of the RPMB 110a may be set as the normal RPMB mode, the advanced RPMB mode, or the high speed RPMB mode” [0055]) – As shown in Fig. 16, RPMB ON of Byte 5 of a UPIU header communicates whether or not data should be stored to the RPMB 110a according to a “high speed” mode; similar to how the Version Field 456 and Attributes 28 of Caraccio Fig. 18 specify a storage configuration for corresponding data blocks. Examiner accordingly considers the RPMB ON byte of Lee Fig. 16 as analogous to “the second set of one or more bits” included within a header. As taught in Lee, data is written into RPMB 110a in a “high speed” mode (as opposed to a “normal” or “advanced” mode; see ¶0055) when the byte 5 RPMB ON indicates that high speed mode should be used. Examiner considers data which is stored according to a high speed mode as reading on the claimed concept of “high performance data”. Accordingly, when the RPMB ON byte 5 of a UPIU basic header segment indicates a high speed RPMB mode, the corresponding data associated with the header is recognized as being high performance (via indication of the high speed mode) and is written into the RPMB 110a region of memory.
Caraccio, Rizvi, and Lee are all considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Lee and realize a UPIU header which indicates high performance data to be written to a particular set of memory cells including within a memory device. Using a command header to signal high performance data enables a storage device to support multiple modes of operation without requiring a hardware change by repurposing data of a previously defined command, which is advantageous as disclosed in Lee ¶0240: “However, in the high speed RPMB mode in accordance with embodiments of the present disclosure, a data segment included in a previously defined command is used, and therefore, a change to the design of hardware is not required. That is, the storage device 50 supporting an existing normal RPMB mode can support a high speed RPMB mode only by updating software, which is advantageous.” [0240]
Regarding Claim 19,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 19. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The method of claim 16 (see Claim 16 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
storing the data comprises: storing the data to a set of single-level memory cells of the memory system in response to a first bit of the second set of one or more bits corresponding to whether the data is high performance data.
However, Lee discloses the following limitations:
storing the data to a set of single-level memory cells (RPMB 110a, Fig. 1 // ¶0042) of the one or more memory devices (Memory Device 100, Fig. 1)(“The memory device 100 may include a memory cell array … Each of the memory cells may be configured as a Single Level Cell (SLC) … The memory blocks included in the memory device 100 may include a Replay Protected Memory Block (RPMB) 110a and a normal block (Normal BLK) 110b. The RPMB 110a may be a memory block accessed through a predetermined specific command or authentication” [0042-45]) – Examiner considers the storage environment depicted in Lee Fig. 1 as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Lee, data is written to a RPMB 110a region of memory device 100. Each memory cell in memory device 100 can be configured as an SLC cell. Accordingly, storing data to the RPMB 110a corresponds to storing “the data to a set of single-level memory cells of the one or more memory devices” (i.e., storing data into a particular SLC cell which is located within a memory device).--
in response to a first bit (RPMB ON, Fig. 16) of the second set of one or more bits corresponding to whether the data is high performance data. (Fig. 16 // “whether the high speed RPMB mode is to be used may be checked using a fifth byte included in the basic header segment. That is, the host 400 and the storage device 50 may determine whether the value of the fifth byte included in the basic header segment of the Response UPIU is a non-zero value, and check that the high speed RPMB mode is used when a value that is not 0 is included in the basic header segment” [0233] // “In an embodiment, an access mode of the RPMB 110a may be set as the normal RPMB mode, the advanced RPMB mode, or the high speed RPMB mode” [0055]) – As shown in Fig. 16, RPMB ON of Byte 5 of a UPIU header communicates whether or not data should be stored to the RPMB 110a according to a “high speed” mode; similar to how the Version Field 456 and Attributes 28 of Caraccio Fig. 18 specify a storage configuration for corresponding data blocks. Examiner accordingly considers the RPMB ON byte of Lee Fig. 16 as analogous to “the second set of one or more bits” included within a header. As taught in Lee, data is written into RPMB 110a in a “high speed” mode (as opposed to a “normal” or “advanced” mode; see ¶0055) when the byte 5 RPMB ON indicates that high speed mode should be used. Examiner considers data which is stored according to a high speed mode as reading on the claimed concept of “high performance data”. Accordingly, when the RPMB ON byte 5 of a UPIU basic header segment indicates a high speed RPMB mode, the corresponding data associated with the header is recognized as being high performance (via indication of the high speed mode) and is written into the RPMB 110a region of memory.
Caraccio, Rizvi, and Lee are all considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Lee and realize a UPIU header which indicates high performance data to be written to a particular set of memory cells including within a memory device. Using a command header to signal high performance data enables a storage device to support multiple modes of operation without requiring a hardware change by repurposing data of a previously defined command, which is advantageous as disclosed in Lee ¶0240: “However, in the high speed RPMB mode in accordance with embodiments of the present disclosure, a data segment included in a previously defined command is used, and therefore, a change to the design of hardware is not required. That is, the storage device 50 supporting an existing normal RPMB mode can support a high speed RPMB mode only by updating software, which is advantageous.” [0240]
Claims 5-6, 13-14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Caraccio further in view of Rizvi and Park et al. (US 20230072721 A1)(hereafter referred to as Park).
Regarding Claim 5,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 5. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
wherein, to store the data, the processing circuitry is configured to cause the memory system to: store the data to a location of the one or more memory devices associated with a low write amplification factor in response to a second bit of the second set of one or more bits corresponding to whether the data is high-stress data.
However, Park discloses the following limitations:
wherein, to store the data, the processing circuitry is configured to cause the memory system to: store the data to a location (UST, Fig. 2) of the one or more memory devices (NV Memory Device 1220, Fig. 1) associated with a low write amplification factor (“When the turbo write procedure is enabled, the UFS device may accelerate write speed by preferentially writing data received from the host in the SLC space. The term “preferentially write” refers to a policy for writing data (e.g., to a first or second area) if an area is available for writing data, and if not, writing to a different area (e.g., a third area)” [0036] // “FIG. 14 illustrates an example in which the storage device 1200 moves data based on the fore level information FL … When a force level is a first level … the storage device 1200 may move a portion of data as much as the free capacity of the destination area. The storage device 1200 may be prohibited from evicting data that may be stored in the destination area.” [0205-206] // Fig. 14 // ¶¶0051;0205-213)– Examiner considers the storage environment depicted in Park Fig. 1 as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Park, when operating in a “first level” of a plurality of “force levels”, data is preferentially written into SLC turbo write buffers (TWB) (see ¶0051) and any data which does not fit into the turbo write buffer is written into a separate UST area comprised of TLC cells. Data located in the TWB is precluded from being evicted by the storage device while operating in the first level; whereas data eviction and invalidation is permitted while operating in the second and third levels (see Fig. 14). One of ordinary skill in the art would understand that a storage device writing data according to the first force level would incur less write amplification as compared to the second and third force levels because no data eviction is permitted in the first force level and therefore the number of writes required to effectuate storage of the same amount of data would be fewer, resulting in a smaller write amplification as compared to the second and third force levels. Therefore, writing data into the UST area while operating in a first force level corresponds to writing data to a memory area (e.g., the UST) which is “associated with a low write amplification factor” (i.e., as compared to if the data were instead written to the TWB in the second or third force levels).--
in response to a second bit (Force Level Information (FL), Fig. 12) of the second set of one or more bits (CDB, Fig. 12) corresponding to whether the data is high-stress data. (“the command UPIU CU may include a basic header BH, additional information AI describing a command, and a command descriptor block (CDB)” [0186] // “The move information MA may describe ways to move data. For example, the move attributes MA may include … force level information FL” [0189]) -- As shown in Fig. 12, CDB bits of a UPIU provide information about how to store data into NV memory, similar to how the Version Field 456 and Attributes 28 of Caraccio Fig. 18 specify a storage configuration for corresponding data blocks. Examiner accordingly considers the CDB of Park Fig. 12 as analogous to “the second set of one or more bits”. As clarified in Park, a UPIU containing move information includes a FL information field (i.e., at least “a second bit”) which specifies when data should be written according to the first force level. As shown in Fig. 14 and as discussed above, the first force level corresponds to a configuration where the storage device is precluded from evicting data from a TWB area. Accordingly, data written into the UST area according to the first force level, as indicated by the FL information in the UPIU of Fig. 12, can be considered as “high-stress data” because the host specifies that it should be stored to an area which incurs the least write amplification.
Caraccio, Rizvi, and Park are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Park and realize a UPIU header including bits which specify whether data should be written to an area of memory incurring low write amplification. Doing so is a method of preferential writing using turbo write buffers which enables a storage system to realize the benefits of a turbo write buffer, such as accelerated write speed, as disclosed in Park ¶0036: “A UFS device may enable or disable the turbo write procedure based on a request of the host. When the turbo write procedure is enabled, the UFS device may accelerate write speed by preferentially writing data received from the host in the SLC space. The term “preferentially write” refers to a policy for writing data (e.g., to a first or second area) if an area is available for writing data, and if not, writing to a different area (e.g., a third area)” [0036]
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
wherein, to store the data, the processing circuitry is configured to cause the memory system to: store the data to one or more blocks of NAND memory cells of the one or more memory devices having a program/erase cycle count that satisfies a threshold in response to a third bit of the second set of one or more bits corresponding to whether the data is cold data.
However, Park discloses the following limitations:
wherein, to store the data, the processing circuitry is configured to cause the memory system to: store the data to one or more blocks of NAND (¶0043) memory cells (Turbo Write Buffer (TWB), Fig. 2) of the one or more memory devices (NV Memory Device 1220, Fig. 1) having a program/erase cycle count that satisfies a threshold (“the physical storage space PS of the storage device 1200 may include a turbo write buffer area (TWB) .. and a user storage area (UST)” [0049] // “How to write the data may be determined based on various factors, such as … a status of the physical storage space” [0055] // “the storage device 1200 may provide information about a lifetime of the turbo write buffer TWB based on the number of program/erase (P/E) cycles of a physical storage space (or a memory block) assigned or used for the turbo write buffer TWB.” [0089] // Fig. 15) – Examiner considers the storage environment depicted in Park Fig. 1 as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Park, data can be written into either a TWB area or a UST area of NAND device 1220. A host uses “a status of the physical storage space”; including “the number of program erase (P/E) cycles”, to determine how to write (e.g., whether to the TWB or the UST) data to the storage device. Accordingly, instances where a host considers the P/E cycles of physical storage and determines to write data to the UST (e.g., via a MV command UPIU as shown in Fig. 15) corresponds to an instance where data is written to “one or more memory devices” (e.g., device 1220) “having a program/erase cycle count that satisfies a threshold” (i.e., as determined by the host affirmatively moving data into the UST based on the P/E cycle count).--
in response to a third bit (Destination Information (DST), Fig. 12) of the second set of one or more bits (CDB, Fig. 12) corresponding to whether the data is cold data. (“the command UPIU CU may include a basic header BH, additional information AI describing a command, and a command descriptor block (CDB)” [0186] // “the command UPIU CU including the move information MV may specify and move target data with a combination of at least two attributes. The destination information DST may indicate one of the pinned turbo write buffer TWP-p, the non-pinned turbo write buffer TWP-np, and the user storage area UST. The storage device may move the move target data specified by the source information SRI and the source identifier SD to a destination area specified by the destination information DST” [0198-199] // “by moving data to the user storage UST through move information MV, the storage device 1200 may provide a function of moving cold data of a low read frequency to the user storage UST and securing a capacity of the turbo write buffer TWB.” [0183]) – As shown in Fig. 12, CDB bits of a UPIU provide information about how to store data into NV memory, similar to how the Version Field 456 and Attributes 28 of Caraccio Fig. 18 specify a storage configuration for corresponding data blocks. Examiner accordingly considers the CDB of Park Fig. 12 as analogous to “the second set of one or more bits”. As clarified in Park, a UPIU containing move information includes a DST information field (i.e., at least “a third bit”) specifies a particular location, such as the UST area, for where data should be written. As clarified in ¶0183, cold data is moved into the UST area to free up capacity in the TWB. Accordingly, the DST information specifying the UST area of a move command indicates “whether the data is cold data” because cold data is moved into the UST.
Caraccio, Rizvi, and Park are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Park and realize a UPIU header including bits which specify whether data is cold data. Doing so enables a host to instruct a storage device to move cold data into a user area, thereby freeing up capacity in a turbo write butter and thereby enabling a storage system to realize the benefits of a turbo write buffer, such as accelerated write speed, as disclosed in Park ¶¶ 0183 // 0036: “by moving data to the user storage UST through move information MV, the storage device 1200 may provide a function of moving cold data of a low read frequency to the user storage UST and securing a capacity of the turbo write buffer TWB.” [0183] // “A UFS device may enable or disable the turbo write procedure based on a request of the host. When the turbo write procedure is enabled, the UFS device may accelerate write speed by preferentially writing data received from the host in the SLC space.” [0036]
Regarding Claim 13,
The same motivation to combine provided in Claim 9 is equally applicable to Claim 13. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The host system of claim 9 (see Claim 9 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
wherein a value of a second bit of the second set of one or more bits indicates to store the data to a location of the memory system associated with a low write amplification factor based on the data being stressful data.
However, Park discloses the following limitations:
wherein a value of a second bit (Force Level Information (FL), Fig. 12) of the second set of one or more bits (CDB, Fig. 12) indicates to store the data to a location (UST, Fig. 2) of the one or more memory devices (NV Memory Device 1220, Fig. 1) associated with a low write amplification factor (“When the turbo write procedure is enabled, the UFS device may accelerate write speed by preferentially writing data received from the host in the SLC space. The term “preferentially write” refers to a policy for writing data (e.g., to a first or second area) if an area is available for writing data, and if not, writing to a different area (e.g., a third area)” [0036] // “FIG. 14 illustrates an example in which the storage device 1200 moves data based on the fore level information FL … When a force level is a first level … the storage device 1200 may move a portion of data as much as the free capacity of the destination area. The storage device 1200 may be prohibited from evicting data that may be stored in the destination area.” [0205-206] // Fig. 14 // ¶¶0051;0205-213)– Examiner considers the storage environment depicted in Park Fig. 1 as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Park, when operating in a “first level” of a plurality of “force levels”, data is preferentially written into SLC turbo write buffers (TWB) (see ¶0051) and any data which does not fit into the turbo write buffer is written into a separate UST area comprised of TLC cells. Data located in the TWB is precluded from being evicted by the storage device while operating in the first level; whereas data eviction and invalidation is permitted while operating in the second and third levels (see Fig. 14). One of ordinary skill in the art would understand that a storage device writing data according to the first force level would incur less write amplification as compared to the second and third force levels because no data eviction is permitted in the first force level and therefore the number of writes required to effectuate storage of the same amount of data would be fewer, resulting in a smaller write amplification as compared to the second and third force levels. Therefore, writing data into the UST area while operating in a first force level corresponds to writing data to a memory area (e.g., the UST) which is “associated with a low write amplification factor” (i.e., as compared to if the data were instead written to the TWB in the second or third force levels).--
based on the data being stressful data. (“the command UPIU CU may include a basic header BH, additional information AI describing a command, and a command descriptor block (CDB)” [0186] // “The move information MA may describe ways to move data. For example, the move attributes MA may include … force level information FL” [0189]) -- As shown in Fig. 12, CDB bits of a UPIU provide information about how to store data into NV memory, similar to how the Version Field 456 and Attributes 28 of Caraccio Fig. 18 specify a storage configuration for corresponding data blocks. Examiner accordingly considers the CDB of Park Fig. 12 as analogous to “the second set of one or more bits”. As clarified in Park, a UPIU containing move information includes a FL information field (i.e., at least “a second bit”) which specifies when data should be written according to the first force level. As shown in Fig. 14 and as discussed above, the first force level corresponds to a configuration where the storage device is precluded from evicting data from a TWB area. Accordingly, data written into the UST area according to the first force level, as indicated by the FL information in the UPIU of Fig. 12, can be considered as “high-stress data” because the host specifies that it should be stored to an area which incurs the least write amplification.
Caraccio, Rizvi, and Park are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Park and realize a UPIU header including bits which specify whether data should be written to an area of memory incurring low write amplification. Doing so is a method of preferential writing using turbo write buffers which enables a storage system to realize the benefits of a turbo write buffer, such as accelerated write speed, as disclosed in Park ¶0036: “A UFS device may enable or disable the turbo write procedure based on a request of the host. When the turbo write procedure is enabled, the UFS device may accelerate write speed by preferentially writing data received from the host in the SLC space. The term “preferentially write” refers to a policy for writing data (e.g., to a first or second area) if an area is available for writing data, and if not, writing to a different area (e.g., a third area)” [0036]
Regarding Claim 14,
The same motivation to combine provided in Claim 9 is equally applicable to Claim 13. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The host system of claim 9 (see Claim 9 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
wherein a value of a third bit of the second set of one or more bits indicates to store the data to one or more blocks of NAND memory cells of the memory system having a program/erase cycle count that satisfies a threshold value based on the data being cold data.
However, Park discloses the following limitations:
wherein a value of a third bit (Destination Information (DST), Fig. 12) of the second set of one or more bits indicates to store the data to one or more blocks of NAND (¶0043) memory cells (Turbo Write Buffer (TWB), Fig. 2) of the one or more memory devices (NV Memory Device 1220, Fig. 1) having a program/erase cycle count that satisfies a threshold (“the physical storage space PS of the storage device 1200 may include a turbo write buffer area (TWB) .. and a user storage area (UST)” [0049] // “How to write the data may be determined based on various factors, such as … a status of the physical storage space” [0055] // “the storage device 1200 may provide information about a lifetime of the turbo write buffer TWB based on the number of program/erase (P/E) cycles of a physical storage space (or a memory block) assigned or used for the turbo write buffer TWB.” [0089] // Fig. 15) – Examiner considers the storage environment depicted in Park Fig. 1 as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Park, data can be written into either a TWB area or a UST area of NAND device 1220. A host uses “a status of the physical storage space”; including “the number of program erase (P/E) cycles”, to determine how to write (e.g., whether to the TWB or the UST) data to the storage device. Accordingly, instances where a host considers the P/E cycles of physical storage and determines to write data to the UST (e.g., via a MV command UPIU as shown in Fig. 15) corresponds to an instance where data is written to “one or more memory devices” (e.g., device 1220) “having a program/erase cycle count that satisfies a threshold” (i.e., as determined by the host affirmatively moving data into the UST based on the P/E cycle count).--
based on the data being cold data. (“the command UPIU CU may include a basic header BH, additional information AI describing a command, and a command descriptor block (CDB)” [0186] // “the command UPIU CU including the move information MV may specify and move target data with a combination of at least two attributes. The destination information DST may indicate one of the pinned turbo write buffer TWP-p, the non-pinned turbo write buffer TWP-np, and the user storage area UST. The storage device may move the move target data specified by the source information SRI and the source identifier SD to a destination area specified by the destination information DST” [0198-199] // “by moving data to the user storage UST through move information MV, the storage device 1200 may provide a function of moving cold data of a low read frequency to the user storage UST and securing a capacity of the turbo write buffer TWB.” [0183]) – As shown in Fig. 12, CDB bits of a UPIU provide information about how to store data into NV memory, similar to how the Version Field 456 and Attributes 28 of Caraccio Fig. 18 specify a storage configuration for corresponding data blocks. Examiner accordingly considers the CDB of Park Fig. 12 as analogous to “the second set of one or more bits”. As clarified in Park, a UPIU containing move information includes a DST information field (i.e., at least “a third bit”) specifies a particular location, such as the UST area, for where data should be written. As clarified in ¶0183, cold data is moved into the UST area to free up capacity in the TWB. Accordingly, the DST information specifying the UST area of a move command indicates “whether the data is cold data” because cold data is moved into the UST.
Caraccio, Rizvi, and Park are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Park and realize a UPIU header including bits which specify whether data is cold data. Doing so enables a host to instruct a storage device to move cold data into a user area, thereby freeing up capacity in a turbo write butter and thereby enabling a storage system to realize the benefits of a turbo write buffer, such as accelerated write speed, as disclosed in Park ¶¶ 0183 // 0036: “by moving data to the user storage UST through move information MV, the storage device 1200 may provide a function of moving cold data of a low read frequency to the user storage UST and securing a capacity of the turbo write buffer TWB.” [0183] // “A UFS device may enable or disable the turbo write procedure based on a request of the host. When the turbo write procedure is enabled, the UFS device may accelerate write speed by preferentially writing data received from the host in the SLC space.” [0036]
Regarding Claim 20,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 20. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The method of claim 16 (see Claim 16 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not explicitly disclose the following limitations:
wherein, storing the data comprises: storing the data to a location of the one or more memory devices associated with a low write amplification factor in response to a second bit of the second set of one or more bits corresponding to whether the data is high-stress data.
However, Park discloses the following limitations:
wherein storing the data comprises: storing the data to a location (UST, Fig. 2) of the one or more memory devices (NV Memory Device 1220, Fig. 1) associated with a low write amplification factor (“When the turbo write procedure is enabled, the UFS device may accelerate write speed by preferentially writing data received from the host in the SLC space. The term “preferentially write” refers to a policy for writing data (e.g., to a first or second area) if an area is available for writing data, and if not, writing to a different area (e.g., a third area)” [0036] // “FIG. 14 illustrates an example in which the storage device 1200 moves data based on the fore level information FL … When a force level is a first level … the storage device 1200 may move a portion of data as much as the free capacity of the destination area. The storage device 1200 may be prohibited from evicting data that may be stored in the destination area.” [0205-206] // Fig. 14 // ¶¶0051;0205-213)– Examiner considers the storage environment depicted in Park Fig. 1 as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Park, when operating in a “first level” of a plurality of “force levels”, data is preferentially written into SLC turbo write buffers (TWB) (see ¶0051) and any data which does not fit into the turbo write buffer is written into a separate UST area comprised of TLC cells. Data located in the TWB is precluded from being evicted by the storage device while operating in the first level; whereas data eviction and invalidation is permitted while operating in the second and third levels (see Fig. 14). One of ordinary skill in the art would understand that a storage device writing data according to the first force level would incur less write amplification as compared to the second and third force levels because no data eviction is permitted in the first force level and therefore the number of writes required to effectuate storage of the same amount of data would be fewer, resulting in a smaller write amplification as compared to the second and third force levels. Therefore, writing data into the UST area while operating in a first force level corresponds to writing data to a memory area (e.g., the UST) which is “associated with a low write amplification factor” (i.e., as compared to if the data were instead written to the TWB in the second or third force levels).--
in response to a second bit (Force Level Information (FL), Fig. 12) of the second set of one or more bits (CDB, Fig. 12) corresponding to whether the data is high-stress data. (“the command UPIU CU may include a basic header BH, additional information AI describing a command, and a command descriptor block (CDB)” [0186] // “The move information MA may describe ways to move data. For example, the move attributes MA may include … force level information FL” [0189]) -- As shown in Fig. 12, CDB bits of a UPIU provide information about how to store data into NV memory, similar to how the Version Field 456 and Attributes 28 of Caraccio Fig. 18 specify a storage configuration for corresponding data blocks. Examiner accordingly considers the CDB of Park Fig. 12 as analogous to “the second set of one or more bits”. As clarified in Park, a UPIU containing move information includes a FL information field (i.e., at least “a second bit”) which specifies when data should be written according to the first force level. As shown in Fig. 14 and as discussed above, the first force level corresponds to a configuration where the storage device is precluded from evicting data from a TWB area. Accordingly, data written into the UST area according to the first force level, as indicated by the FL information in the UPIU of Fig. 12, can be considered as “high-stress data” because the host specifies that it should be stored to an area which incurs the least write amplification.
Caraccio, Rizvi, and Park are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Park and realize a UPIU header including bits which specify whether data should be written to an area of memory incurring low write amplification. Doing so is a method of preferential writing using turbo write buffers which enables a storage system to realize the benefits of a turbo write buffer, such as accelerated write speed, as disclosed in Park ¶0036: “A UFS device may enable or disable the turbo write procedure based on a request of the host. When the turbo write procedure is enabled, the UFS device may accelerate write speed by preferentially writing data received from the host in the SLC space. The term “preferentially write” refers to a policy for writing data (e.g., to a first or second area) if an area is available for writing data, and if not, writing to a different area (e.g., a third area)” [0036]
Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Caraccio further in view of Rizvi and Sela et al. (US 20190102114 A1)(hereafter referred to as Sela).
Regarding Claim 8,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 8. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The memory system of claim 1 (see Claim 1 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not disclose an embodiment whereby plural CPU cores of a host system access the same storage device, and thus do not disclose the following limitations:
wherein the first set of one or more bits indicate a central processing unit (CPU) core of a plurality of CPU cores of a host system.
However, Sela discloses the following limitations:
wherein the first set of one or more bits (Initiator ID 606, Fig. 6A) indicate a central processing unit (CPU) core of a plurality of CPU cores (Host Sub-Systems 4A-4C, Fig. 1A) of a host system. (Host 2, Fig. 1A)(“The initiator ID field 606 is used to specify the initiator of the command” [0090] // “The initiator may be one of the host subsystems 4, as depicted in FIG. 1A” [0086] // “Host 2 also includes sub-systems 4A, 4B, and 4C … In one embodiment, the different subsystems are different processors” [0026-28] // Fig. 1A // Fig. 5) – Examiner considers the storage environment depicted in Sela Fig. 1A as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Sela, the initiator ID field of an UPIU identifies the particular host sub-system processor (i.e., “a central processing unit (CPU) core of a plurality of CPU cores of a host system”) which initiates an access to non-volatile memory 24 (see Fig. 5).
Caraccio, Rizvi, and Sela are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Sela and realize a UPIU header including an initiator ID which identifies a particular initiating processor of a host device. Doing so enables access control to a non-volatile memory device to be performed in applications such as vehicle systems where distinct processors of a host have varying access rights to the same non-volatile memory, as disclosed in Sela ¶¶0026; 0079 : “Host 2 also includes sub-systems 4A, 4B, and 4C, which are connected to bus 12 … The various sub-systems 4A-4C may share access to the non-volatile memory 24 … Thus, memory controller 24 may enforce access control restrictions that prevent a sub-system 4 from accessing a region in the non-volatile memory 24 that is allocated to another sub-system 4.” [0026] // “the access control logic 420 is configured to access an initiator identifier in a memory access message from the host 2 and grant or deny access to the non-volatile memory 24 based on the initiator identifier.” [0079].
Regarding Claim 15,
The same motivation to combine provided in Claim 9 is equally applicable to Claim 15. The combined teachings of Caraccio and Rizvi disclose the following limitations:
The host system of claim 9 (see Claim 9 limitation mappings above),
The combined teachings of Caraccio and Rizvi do not disclose an embodiment whereby plural CPU cores of a host system access the same storage device, and thus do not disclose the following limitations:
wherein determining the host process associated with the data is based on determining a central processing unit (CPU) core, from a plurality of CPU cores of the host system, associated with the write command
However, Sela discloses the following limitations:
wherein determining the host process associated with the data is based on determining a central processing unit (CPU) core, from a plurality of CPU cores (Host Sub-Systems 4A-4C, Fig. 1A) of the host system, associated with the write command (“The initiator ID field 606 is used to specify the initiator of the command” [0090] // “The initiator may be one of the host subsystems 4, as depicted in FIG. 1A” [0086] // “Host 2 also includes sub-systems 4A, 4B, and 4C … In one embodiment, the different subsystems are different processors” [0026-28] // Fig. 1A // Fig. 5) – Examiner considers the storage environment depicted in Sela Fig. 1A as analogous to the storage environment depicted in Caraccio Fig. 1. As taught in Sela, the initiator ID field of an UPIU identifies the particular host sub-system processor (i.e., “a central processing unit (CPU) core, from of a plurality of CPU cores of the host system”) which initiates an access to non-volatile memory 24 (see Fig. 5).
Caraccio, Rizvi, and Sela are considered analogous to the claimed invention because they all relate to the same field of formatting UPIU headers in memory systems which employ the UFS protocol. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caraccio and Rizvi with the teachings of Sela and realize a UPIU header including an initiator ID which identifies a particular initiating processor of a host device. Doing so enables access control to a non-volatile memory device to be performed in applications such as vehicle systems where distinct processors of a host have varying access rights to the same non-volatile memory, as disclosed in Sela ¶¶0026; 0079 : “Host 2 also includes sub-systems 4A, 4B, and 4C, which are connected to bus 12 … The various sub-systems 4A-4C may share access to the non-volatile memory 24 … Thus, memory controller 24 may enforce access control restrictions that prevent a sub-system 4 from accessing a region in the non-volatile memory 24 that is allocated to another sub-system 4.” [0026] // “the access control logic 420 is configured to access an initiator identifier in a memory access message from the host 2 and grant or deny access to the non-volatile memory 24 based on the initiator identifier.” [0079].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm EST.
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, Rocío del Mar Pérez-Vélez can be reached at 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.S.M./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights